Mengapa Migrasi Database Membutuhkan Checklist Sendiri

Seorang developer melakukan push perubahan yang menghapus sebuah kolom. Pipeline deployment berjalan hijau. Aplikasi berhasil di-deploy. Namun migrasi database sudah tereksekusi, dan kolom itu sudah hilang. Sekarang versi lama aplikasi, yang masih mereferensi kolom tersebut, tidak bisa dijalankan. Tim menyadari bahwa mereka tidak bisa sekadar me-rollback aplikasi tanpa mengembalikan database juga. Dan mengembalikan database berarti kehilangan data apa pun yang ditulis setelah migrasi berjalan.

Skenario ini terjadi di tim yang memperlakukan perubahan database sama seperti perubahan kode aplikasi. Profil risikonya fundamental berbeda. Ketika kode aplikasi rusak, Anda bisa deploy ulang versi sebelumnya. Ketika migrasi database rusak, Anda tidak selalu bisa membatalkan apa yang sudah dilakukan. Data mungkin hilang. Constraint mungkin dilanggar. Skema mungkin sudah berubah dengan cara yang membuat rollback sederhana tidak mungkin dilakukan tanpa restore penuh dari backup.

Itulah mengapa migrasi database membutuhkan template sendiri. Bukan checklist deployment generik. Sesuatu yang spesifik untuk sifat perubahan skema, transformasi data, dan konsekuensi ireversibel dari mengubah data produksi.

Masalah dengan Memperlakukan Migrasi Seperti Deployment Kode

Deployment kode relatif aman karena bersifat reversibel. Anda deploy versi 2, ada bug, Anda deploy versi 1 lagi. Aplikasi restart dengan kode lama, dan pengguna terus bekerja.

Migrasi database tidak bekerja seperti itu. Begitu migrasi berjalan:

• Kolom yang dihapus tidak bisa dikembalikan tanpa restore
• Tabel yang diganti namanya memutus query yang masih menggunakan nama lama
• Transformasi data yang menghapus atau mengubah nilai tidak bisa dibalikkan dengan menjalankan migrasi lagi
• Pembuatan atau penghapusan indeks dapat mengubah performa query selama berjam-jam atau berhari-hari

Risikonya tidak hanya teknis. Ini operasional. Migrasi yang gagal bisa menghentikan seluruh aplikasi, mengunci tabel untuk waktu yang lama, dan membutuhkan koordinasi antara developer, DBA, dan tim operasi untuk memulihkannya.

Template Migrasi Database Lima Langkah

Template migrasi yang baik bukanlah skrip yang kaku. Ini adalah urutan pemeriksaan dan tindakan yang mengurangi kemungkinan kejutan. Setiap langkah memiliki tujuan yang jelas, dan melewatkan langkah mana pun meningkatkan risiko.

Diagram alir berikut mengilustrasikan template lima langkah dan titik keputusan utama:

Langkah 1: Backup Sebelum Apa Pun

Sebelum migrasi apa pun berjalan, database harus di-backup. Ini bukan sekadar centang untuk kepatuhan. Ini adalah jaring pengaman terakhir ketika semuanya gagal.

Backup harus dapat digunakan untuk restore ke kondisi persis sebelum migrasi. Itu berarti:

Skrip migrasi yang reversibel memasangkan perubahan maju dengan rollback, sehingga jelas cara membatalkannya jika diperlukan:

-- Up: Menambahkan kolom dengan nilai default
ALTER TABLE users ADD COLUMN last_login_at TIMESTAMP DEFAULT NULL;

-- Down: Menghapus kolom (hanya aman jika tidak ada kode yang bergantung padanya)
ALTER TABLE users DROP COLUMN last_login_at;

• File backup harus diuji validitasnya, bukan hanya dibuat
• Prosedur restore harus didokumentasikan dan dilatih
• Untuk migrasi berisiko tinggi, backup manual yang diambil segera sebelum migrasi lebih baik daripada mengandalkan backup otomatis harian

Beberapa tim menyimpan backup otomatis setiap malam. Itu baik untuk operasi rutin. Tetapi untuk migrasi yang menghapus tabel atau memodifikasi jutaan baris, ambil backup tepat sebelum migrasi dimulai. Backup harus disimpan di lokasi yang tidak terpengaruh oleh migrasi itu sendiri.

Langkah 2: Dry-Run di Lingkungan yang Realistis

Dry-run berarti mengeksekusi migrasi di lingkungan non-produksi yang semirip mungkin dengan produksi. Tujuannya adalah untuk menangkap masalah sebelum mencapai produksi.

Kata kuncinya adalah "realistis." Menjalankan migrasi di database dengan sepuluh baris tidak memberi tahu Anda apa pun tentang bagaimana perilakunya di database dengan sepuluh juta baris. Migrasi yang selesai dalam dua detik di database kosong mungkin membutuhkan waktu dua puluh menit pada data produksi. Selama dua puluh menit itu, tabel mungkin terkunci, query mungkin mengantre, dan aplikasi mungkin menjadi tidak responsif.

Lingkungan dry-run yang tepat harus memiliki:

• Skema identik dengan produksi
• Volume data mendekati produksi, atau setidaknya representatif dari tabel terbesar yang dimodifikasi
• Hardware atau batasan sumber daya yang serupa, terutama untuk CPU dan I/O

Jalankan migrasi. Catat berapa lama setiap pernyataan berlangsung. Perhatikan lock contention. Periksa error. Jika dry-run mengungkapkan masalah, perbaiki sebelum menyentuh produksi.

Langkah 3: Eksekusi Migrasi di Produksi

Ini adalah momen kritis. Migrasi harus berjalan selama jam lalu lintas rendah. Bukan karena migrasi itu sendiri akan gagal, tetapi karena dampak dari masalah apa pun lebih kecil ketika lebih sedikit pengguna yang terpengaruh.

Selama eksekusi, pantau secara aktif:

• Berapa lama setiap pernyataan selesai?
• Apakah ada lock yang memblokir query lain?
• Apakah aplikasi masih melayani permintaan, atau koneksi mengalami timeout?
• Apakah tingkat error meningkat di log aplikasi?

Jika migrasi memakan waktu lebih lama dari yang diharapkan, jangan berasumsi bahwa migrasi pada akhirnya akan selesai. Miliki rencana untuk membatalkan atau menjeda. Beberapa migrasi dapat dipecah menjadi batch yang lebih kecil. Yang lain mungkin memerlukan penempatan aplikasi dalam mode pemeliharaan sementara.

Langkah 4: Verifikasi Hasil

Jangan percaya kode keluar hijau. Migrasi dapat selesai tanpa error dan masih meninggalkan database dalam keadaan rusak. Verifikasi berarti memeriksa bahwa skema sesuai dengan harapan dan bahwa aplikasi dapat terhubung dan berfungsi.

Verifikasi dengan:

• Memeriksa bahwa kolom baru ada dengan tipe data yang benar
• Mengonfirmasi bahwa transformasi data menghasilkan nilai yang diharapkan
• Menjalankan query uji yang menggunakan skema yang diubah
• Menghubungkan aplikasi ke database dan memeriksa error koneksi

Jika migrasi menambahkan constraint, verifikasi bahwa data yang ada memenuhinya. Jika migrasi menghapus constraint, verifikasi bahwa aplikasi masih berfungsi dengan benar tanpanya.

Langkah 5: Pantau Efek Jangka Pendek

Perubahan skema tidak berhenti memengaruhi sistem setelah migrasi selesai. Mereka dapat mengubah rencana eksekusi query, mengubah penggunaan indeks, dan memperkenalkan pola penguncian baru. Efek ini mungkin tidak muncul segera.

Pantau selama beberapa jam ke depan:

• Apakah ada slow query baru di database?
• Apakah tingkat error di aplikasi lebih tinggi dari sebelumnya?
• Apakah ada deadlock yang tidak ada sebelumnya?
• Apakah aplikasi merespons dalam rentang latensi normal?

Gunakan alat monitoring yang ada. Jangan mengandalkan pemeriksaan log secara manual. Siapkan alert untuk setiap degradasi yang berkorelasi dengan waktu migrasi.

Checklist Praktis untuk Migrasi Database

Kesimpulan

Migrasi database bukanlah deployment kode. Mereka membawa konsekuensi ireversibel yang membutuhkan pendekatan berbeda. Template lima langkah - backup, dry-run, eksekusi, verifikasi, pantau - memberikan tim Anda cara terstruktur untuk mengurangi risiko. Gunakan untuk setiap migrasi, sekecil apa pun. Migrasi yang tampak terlalu sederhana untuk membutuhkan checklist sering kali yang menyebabkan kerusakan paling besar.