Memilih Strategi Pemulihan Database yang Tepat untuk Tim Anda

Anda baru saja mendeploy migrasi database ke production. Lima menit kemudian, dashboard monitoring menunjukkan lonjakan query yang gagal. Tim Anda kini berada dalam posisi yang sudah tidak asing: Anda harus memperbaikinya, dan cepat. Namun cara Anda memperbaikinya tidak hanya bergantung pada kemampuan teknis. Ini tergantung pada siapa Anda, seberapa sering Anda melakukan deploy, dan jenis aplikasi yang Anda jalankan.

Tidak ada jawaban universal untuk pemulihan database. Strategi yang berhasil untuk tim kecil yang melakukan deploy seminggu sekali akan gagal untuk tim yang melakukan deploy sepuluh kali sehari. Triknya bukanlah menemukan strategi yang sempurna. Triknya adalah menemukan strategi yang dapat Anda jalankan secara konsisten di bawah tekanan.

Ukuran Tim dan Frekuensi Deployment Itu Penting

Tim yang terdiri dari tiga orang yang melakukan deploy seminggu sekali memiliki masalah pemulihan yang sangat berbeda dengan tim yang terdiri dari dua puluh orang yang melakukan deploy beberapa kali sehari.

Saat Anda jarang melakukan deploy, Anda tahu persis apa yang berubah. Hanya ada beberapa migrasi dalam seminggu terakhir, dan semua orang di tim mengingatnya. Jika terjadi kesalahan, Anda dapat mempertimbangkan untuk menjalankan down migration guna mengembalikan perubahan skema. Risiko bertabrakan dengan pekerjaan anggota tim lain rendah karena tidak ada orang lain yang melakukan deploy pada waktu yang sama.

Sekarang bayangkan sebuah tim yang melakukan deploy setiap beberapa jam. Saat Anda menyadari ada masalah dengan migrasi Anda, tiga pengembang lain mungkin sudah mendorong migrasi baru di atas migrasi Anda. Menjalankan down migration di lingkungan seperti ini berbahaya. Anda mungkin mengembalikan perubahan Anda, tetapi Anda juga bisa menghapus migrasi orang lain yang sebenarnya baik-baik saja. Risiko tabrakan tinggi, dan konsekuensinya berantakan.

Untuk tim dengan frekuensi tinggi, down migration menjadi beban. Mereka bekerja dalam teori tetapi menyebabkan kekacauan dalam praktik. Tim-tim ini membutuhkan strategi pemulihan yang tidak mengasumsikan mereka adalah satu-satunya yang melakukan perubahan.

Toleransi Downtime Menentukan Pilihan Anda

Tidak semua aplikasi mampu mati sementara Anda memperbaiki masalah database. Toleransi Anda terhadap downtime secara langsung menentukan strategi pemulihan mana yang tersedia untuk Anda.

Jika Anda menjalankan aplikasi internal yang digunakan oleh lima puluh orang selama jam kerja, Anda mungkin bisa mematikan sistem selama lima menit. Itu memberi Anda ruang untuk memulihkan dari backup atau menjalankan down migration yang membutuhkan waktu untuk selesai. Pengguna akan kesal, tetapi dampak bisnisnya terbatas.

Sekarang pertimbangkan aplikasi publik yang menangani ribuan permintaan per detik. Setiap menit downtime menghabiskan pendapatan dan mengikis kepercayaan pengguna. Memulihkan dari backup bisa memakan waktu dua puluh menit atau lebih. Itu tidak dapat diterima. Dalam skenario ini, roll-forward hampir menjadi keharusan. Anda menulis migrasi baru yang memperbaiki masalah, mendeploynya, dan melanjutkan. Perbaikan membutuhkan waktu detik untuk diterapkan, bukan menit.

Logika yang sama berlaku untuk compensating script. Jika Anda tahu Anda sedang mengerjakan perubahan berisiko tinggi, siapkan compensating script sebelum Anda mendeploy migrasi asli. Jangan menunggu sampai sesuatu rusak. Saat tekanan meningkat, kemampuan Anda untuk menulis SQL yang benar di bawah tenggat waktu menurun drastis. Skrip yang sudah ditulis sebelumnya menghilangkan beban kognitif itu.

Jenis Perubahan Menentukan Tingkat Risiko

Tidak semua perubahan database membawa risiko yang sama. Menambahkan kolom nullable atau membuat tabel baru adalah risiko rendah. Perubahan ini mudah di-roll-forward karena tidak merusak query yang ada. Anda dapat menambahkan kolom, mendeploy kode aplikasi yang menggunakannya, dan semuanya berjalan.

Tetapi menghapus kolom, mengubah tipe data, atau memigrasikan data antar tabel adalah risiko tinggi. Perubahan ini dapat merusak query yang masih berjalan di production. Mereka bisa mengunci tabel selama menit atau jam. Mereka bisa merusak data jika logika migrasi memiliki bug.

Untuk perubahan berisiko tinggi, Anda tidak boleh mengandalkan pemulihan reaktif. Anda perlu merencanakan jalur pemulihan sebelum menjalankan migrasi. Itu berarti menulis compensating script terlebih dahulu. Itu berarti menguji jalur roll-forward di lingkungan staging. Itu berarti mengetahui persis apa yang akan Anda lakukan jika migrasi memakan waktu lebih lama dari yang diharapkan atau jika berhasil tetapi menghasilkan data yang salah.

Strategi Default: Roll-Forward Terlebih Dahulu

Setelah bekerja dengan banyak tim, sebuah pola yang jelas muncul. Tim yang matang menggunakan roll-forward sebagai default. Down migration disediakan untuk lingkungan staging atau tahap pengembangan awal. Backup diperlakukan sebagai jaring pengaman untuk kegagalan bencana, bukan sebagai mekanisme rollback harian. Compensating script digunakan ketika data perlu diperbaiki tanpa mengubah skema.

Alasan pola ini berhasil adalah konsistensi. Ketika Anda selalu menggunakan roll-forward, Anda mengembangkan kebiasaan yang membuat pemulihan lebih mudah. Anda menulis migrasi yang lebih kecil dan lebih sering. Anda menguji jalur roll-forward setiap saat. Anda menjadi nyaman dengan gagasan bahwa memperbaiki masalah berarti mendeploy perubahan lain, bukan membatalkan perubahan terakhir.

Tim yang mencampur strategi sering kesulitan. Satu minggu mereka menggunakan down migration, minggu berikutnya mereka memulihkan dari backup, minggu berikutnya mereka menulis compensating script dengan tergesa-gesa. Setiap insiden membutuhkan keputusan baru di bawah tekanan. Saat itulah kesalahan terjadi.

Daftar Periksa Praktis untuk Memilih Strategi Pemulihan

  • Seberapa sering tim Anda melakukan deploy? Jika lebih dari sekali sehari, hindari down migration di production.

Daftar periksa di atas adalah awal yang baik, tetapi diagram pohon keputusan visual dapat membuat pilihan lebih jelas di bawah tekanan. Berikut adalah diagram alir sederhana untuk memandu pemilihan strategi pemulihan tim Anda:

flowchart TD A[Mulai] --> B{Ukuran tim?} B -->|Kecil| C{Frekuensi deploy?} B -->|Besar| D{Frekuensi deploy?} C -->|Rendah| E{Toleransi downtime?} C -->|Tinggi| F{Toleransi downtime?} D -->|Rendah| G{Toleransi downtime?} D -->|Tinggi| H{Toleransi downtime?} E -->|Tinggi| I[Down migration] E -->|Rendah| J[Roll-forward] F -->|Tinggi| K[Restore backup] F -->|Rendah| L[Roll-forward] G -->|Tinggi| M[Down migration] G -->|Rendah| N[Roll-forward] H -->|Tinggi| O[Restore backup] H -->|Rendah| P[Roll-forward]
  • Bisakah aplikasi Anda mentolerir downtime lima menit? Jika tidak, roll-forward harus menjadi default Anda.
  • Apakah migrasi Anda menambahkan kolom atau menghapusnya? Perubahan berisiko tinggi membutuhkan compensating script yang ditulis sebelumnya.
  • Apakah Anda memiliki lingkungan staging yang mirip dengan production? Uji jalur pemulihan Anda di sana terlebih dahulu.
  • Apakah tim Anda telah menyetujui strategi default? Konsistensi lebih penting daripada kesempurnaan.

Kesimpulan

Strategi pemulihan database Anda bukanlah keputusan teknis. Ini adalah keputusan tim yang dibentuk oleh cara Anda bekerja, seberapa sering Anda mengirimkan perubahan, dan apa yang dapat ditoleransi oleh pengguna Anda. Strategi terbaik adalah strategi yang dapat dijalankan tim Anda tanpa ragu-ragu ketika terjadi kesalahan. Pilih satu, latih, dan jadikan itu default Anda. Konsistensi itu akan menghemat lebih banyak waktu Anda daripada alat atau skrip apa pun.