Apa yang Terjadi Setelah Migrasi Database Berhasil Dijalankan

Sebuah migrasi database selesai tanpa error. Pipeline menunjukkan warna hijau. Tim pun bernapas lega. Namun satu jam kemudian, pengguna mulai melaporkan bahwa halaman dimuat dengan lambat. Beberapa query mengalami timeout. Beberapa panggilan API mengembalikan error 500. Migrasi berhasil secara teknis, tetapi ada sesuatu yang salah di bawah permukaan.

Skenario ini lebih umum dari yang diperkirakan sebagian besar tim. Migrasi yang selesai tanpa melempar exception tidak sama dengan migrasi yang meninggalkan sistem dalam kondisi sehat. Perbedaan antara kedua hasil inilah yang ingin ditangkap oleh verifikasi pasca-migrasi.

Mengapa Kode Sukses Saja Tidak Cukup

Sebagian besar alat migrasi mengembalikan kode keluar nol ketika selesai tanpa error. Itu memberi tahu Anda bahwa SQL telah dieksekusi dan tabel pelacakan internal alat telah diperbarui. Itu tidak memberi tahu Anda apakah skema baru berfungsi dengan baik dengan aplikasi, apakah performa query berubah, atau apakah migrasi meninggalkan lock.

Sebuah migrasi bisa berhasil secara teknis namun tetap menyebabkan kerusakan nyata. Menambahkan kolom dengan nilai default bisa mengunci tabel besar selama beberapa menit. Mengubah tipe kolom bisa memaksa database menulis ulang baris, yang memperlambat query konkuren. Menambahkan indeks bisa membantu satu query tetapi merusak rencana eksekusi untuk query lain. Tidak satu pun dari masalah ini muncul dalam kode keluar alat migrasi.

Verifikasi pasca-migrasi adalah praktik memeriksa keadaan aktual database dan aplikasi setelah migrasi dijalankan. Ini mengubah deployment buta menjadi deployment yang berdasarkan informasi.

Periksa Status Migrasi dengan Benar

Hal pertama yang perlu diverifikasi adalah apakah migrasi benar-benar selesai atau berhenti di tengah jalan. Beberapa alat menerapkan migrasi dalam batch. Jika migrasi gagal pada batch ketiga, dua batch pertama sudah mengubah database. Kode keluar mungkin non-zero, tetapi kerusakan sudah terjadi sebagian.

Lihat tabel pelacakan alat migrasi atau log detailnya. Cari tahu persis pernyataan mana yang diterapkan dan di mana proses berhenti. Informasi ini memberi tahu Anda apakah database dalam keadaan konsisten atau apakah diperlukan pembersihan manual sebelum mencoba lagi.

Jangan hanya mengandalkan kode keluar. Beberapa migrasi menghasilkan peringatan yang tidak fatal tetapi menunjukkan potensi masalah, seperti sintaks yang tidak digunakan lagi atau konversi tipe implisit. Catat peringatan tersebut dan sertakan dalam laporan pipeline.

Bandingkan Latensi Query Sebelum dan Sesudah

Perubahan skema dapat mengubah cara database mengeksekusi query. Kolom yang ditambahkan ke tabel bisa menyebabkan query planner memilih indeks yang berbeda atau full table scan. Perubahan tipe data bisa menonaktifkan penggunaan indeks untuk perbandingan tertentu.

Pipeline harus menjalankan serangkaian query representatif terhadap database sebelum dan sesudah migrasi. Bandingkan latensi untuk setiap query. Jika ada query yang menunjukkan peningkatan signifikan, itu adalah sinyal bahwa migrasi mengubah rencana eksekusi dengan cara yang merugikan performa.

Fokus pada query yang paling sering digunakan aplikasi atau yang diketahui sensitif terhadap performa. Jangan jalankan query analitis berat untuk pemeriksaan ini. Jaga agar query verifikasi tetap ringan sehingga tidak menambah beban pada database selama jendela deployment.

Periksa Lock yang Tidak Dilepaskan

Migrasi yang mengubah skema seringkali perlu memperoleh lock pada tabel atau baris. Sebagian besar lock dilepaskan saat migrasi selesai, tetapi tidak selalu. Transaksi yang berjalan lama, koneksi yang tidak ditutup dengan benar, atau migrasi yang timeout dapat meninggalkan lock.

Setelah migrasi selesai, periksa database untuk lock yang aktif. Jika lock masih dipegang, aplikasi akan mengalami timeout atau penumpukan antrian saat mencoba mengakses tabel yang terpengaruh. Pipeline juga harus mencatat berapa lama lock dipegang selama migrasi. Jika lock dipegang lebih dari beberapa detik pada tabel produksi, itu layak diselidiki meskipun akhirnya dilepaskan.

Jalankan query ini untuk melihat apakah masih ada lock yang dipegang pada tabel yang Anda migrasi:

SELECT
    pg_locks.pid,
    pg_locks.mode,
    pg_locks.granted,
    pg_class.relname,
    pg_stat_activity.query,
    pg_stat_activity.state,
    pg_stat_activity.wait_event_type || ': ' || pg_stat_activity.wait_event AS wait
FROM pg_locks
JOIN pg_class ON pg_locks.relation = pg_class.oid
JOIN pg_stat_activity ON pg_locks.pid = pg_stat_activity.pid
WHERE pg_class.relname = 'your_table_name'
  AND pg_locks.granted = true;

Jika ada baris yang dikembalikan, migrasi meninggalkan lock. Selidiki kolom query dan state untuk memahami alasannya.

Verifikasi Jumlah Baris untuk Migrasi yang Mengubah Data

Beberapa migrasi melakukan lebih dari sekadar mengubah skema. Mereka mengisi kolom baru dengan nilai default, memindahkan data antar tabel, atau membersihkan duplikat. Operasi ini bisa secara diam-diam melewatkan baris jika logika migrasi memiliki kasus tepi atau jika data tidak sesuai dengan format yang diharapkan.

Setelah migrasi semacam itu, bandingkan jumlah baris aktual dengan jumlah baris yang diharapkan. Misalnya, jika migrasi seharusnya mengisi kolom baru untuk semua baris yang ada, periksa apakah jumlah baris dengan nilai non-null di kolom tersebut cocok dengan jumlah total baris. Jika ada ketidakcocokan, migrasi tidak diterapkan ke semua baris.

Jalankan pemeriksaan ini dengan query count sederhana. Hindari join atau agregasi yang bisa menambah beban tidak perlu pada database.

Pantau Log Aplikasi untuk Error Database

Langkah verifikasi yang paling penting adalah memeriksa apakah aplikasi masih bisa bekerja dengan database setelah migrasi. Kode aplikasi yang sedang berjalan ditulis untuk skema lama. Jika migrasi mengubah skema dengan cara yang merusak kode yang berjalan, error akan muncul di log aplikasi.

Cari error yang menyebutkan kolom yang hilang, ketidakcocokan tipe, atau query yang gagal. Error ini berarti aplikasi dan database tidak sinkron. Tim perlu memutuskan dengan cepat apakah akan melakukan rollback migrasi atau menerapkan perbaikan kode yang sesuai dengan skema baru.

Jangan menunggu pengguna melaporkan error ini. Pipeline harus mengambil log aplikasi dari sistem monitoring dan memindainya untuk error terkait database secara otomatis.

Daftar Periksa Pasca-Migrasi yang Praktis

Jika Anda baru pertama kali menyiapkan verifikasi pasca-migrasi, mulailah dengan pemeriksaan berikut di pipeline Anda:

Diagram alir berikut mengilustrasikan urutan langkah verifikasi yang direkomendasikan:

flowchart TD A[Migrasi selesai sukses] --> B[Periksa status migrasi] B --> C[Bandingkan latensi query] C --> D[Periksa lock] D --> E[Verifikasi jumlah baris] E --> F[Pantau log aplikasi] F --> G{Semua pemeriksaan lulus?} G -- Ya --> H[Aman untuk dipertahankan] G -- Tidak --> I[Alert tim]
  • Status migrasi: Apakah selesai sepenuhnya, dan di mana berhenti jika gagal?
  • Latensi query: Apakah lima query kritis masih dalam rentang yang dapat diterima?
  • Lock: Apakah ada lock aktif yang tersisa setelah migrasi?
  • Jumlah baris: Apakah angkanya sesuai dengan ekspektasi untuk migrasi yang mengubah data?
  • Error aplikasi: Apakah ada error terkait database baru di log?

Jalankan pemeriksaan ini secara otomatis setelah setiap migrasi. Kirim hasilnya ke tim sebagai laporan. Jika semua pemeriksaan lulus, migrasi aman untuk dipertahankan. Jika ada pemeriksaan yang gagal, tim memiliki informasi yang cukup untuk memutuskan langkah selanjutnya.

Kesimpulan

Status migrasi hijau bukan jaminan keamanan. Tes sebenarnya adalah apakah database dan aplikasi masih bekerja sama dengan baik setelah perubahan. Verifikasi pasca-migrasi menjembatani kesenjangan antara "migrasi berjalan" dan "sistem sehat." Tanpa itu, Anda melakukan deployment secara buta dan berharap yang terbaik.