Petakan setiap pembaca dan penulis
Bekerja pada skema terisolasi dengan data tersanitasi yang representatif. Anda memerlukan versi aplikasi saat ini dan berikutnya, pengetahuan tentang kerangka migrasi Anda, strategi pencadangan yang ditinjau, dan visibilitas ke transaksi panjang. Sertakan worker, tugas terjadwal, laporan, dan instans aplikasi lama. API mungkin diperbarui dengan cepat sementara worker yang berjalan lama masih menulis ke kolom lama.
Layanan pelaporan ilustratif kami menyimpan label ekspor di label dan menginginkan display_name. Ini adalah contoh desain, bukan SQL yang dapat dijalankan secara universal. Konfirmasi versi PostgreSQL dan kerangka kerja Anda yang tepat sebelum memilih sintaks migrasi atau pengaturan kunci.
Perluas tanpa menonaktifkan representasi lama
Perkenalkan bidang nullable baru terlebih dahulu. Terapkan rilis kompatibilitas yang menulis kedua nilai dalam satu transaksi dan membaca dengan fallback yang diperlukan saat data belum lengkap. Tentukan apa yang terjadi ketika pelanggan mengedit catatan selama pengisian ulang. Percobaan ulang tidak boleh membuat ekspor logis kedua.
PostgreSQL ALTER TABLE operasi memperoleh kunci, dengan tingkat yang bergantung pada subperintah. Perubahan kecil dapat menunggu di belakang transaksi panjang dan kemudian menghalangi pekerjaan lain. Tinjau operasi spesifik dan amati waktu tunggu selama latihan; aditif tidak berarti bebas kunci.
Referensi teknis: PostgreSQL ALTER TABLE · Penguncian eksplisit PostgreSQL.
Buat batas kompatibilitas terlihat
| Skema dan penulis | Perilaku pembaca | Keputusan pemulihan |
|---|---|---|
| Hanya label yang ada | Kode lama didukung | Tambahkan bidang baru terlebih dahulu |
| Kedua bidang; penulis hanya lama tetap ada | Baca label sebagai otoritatif | Jangan beralih pembaca dulu |
| Semua penulis menulis ganda; pengisian ulang terverifikasi | Bidang baru dapat menjadi otoritatif | Kembalikan hanya ke kode penulisan ganda yang kompatibel |
| Bidang lama dihapus | Tidak ada kode yang boleh mereferensikan label | Artefak lama tidak kompatibel |
Fallback untuk nilai yang hilang tidak dapat mendeteksi nilai baru yang bukan null tetapi sudah usang. Sebelum beralih pembaca, pensiunkan penulis khusus lama dan verifikasi konsistensi. Mengembalikan ke kode khusus lama setelah peralihan pembaca dapat menciptakan kembali divergensi. Pertahankan rilis kompatibilitas sebagai artefak pemulihan yang telah ditinjau sebagai gantinya.
Isi ulang secara bertahap dan dapat dimulai ulang
Temukan baris yang perlu disalin tanpa menimpa edit pelanggan yang lebih baru. Gunakan pengurutan yang stabil, kondisi pembaruan yang aman untuk konkurensi, dan ukuran batch yang dipilih sesuai beban kerja. Simpan progres agar kegagalan dapat dilanjutkan pada batas yang diketahui. Pantau volume penulisan, waktu tunggu kunci, latensi permintaan, dan replikasi jika ada.
Tidak ada ukuran batch yang aman untuk setiap aplikasi. Dalam latihan, bandingkan batch kecil dengan lalu lintas biasa, lalu pilih aturan jeda atau hentikan. Jika batch gagal, periksa apa yang sudah ter-commit sebelum mencoba lagi. Loop percobaan ulang tanpa batas dapat mengubah ketidakcocokan yang dapat dipulihkan menjadi tekanan database yang berkepanjangan.
Periksa semantik, bukan hanya baris yang terisi
Verifikasi nilai yang hilang, label representatif, catatan baru, dan pembaruan pada ekspor yang ada. Menghitung baris non-null dapat terlihat benar padahal nilai disalin dari sumber yang salah. Uji artefak kompatibilitas terhadap data yang terisi sebagian dan jalankan worker yang dimulai sebelum deployment.
Catat versi skema, revisi migrasi, kriteria penyelesaian, dan kombinasi yang tidak kompatibel. Periksa penggunaan fallback dan konsistensi sebelum menghapus salah satunya. Jika pemeriksaan gagal, hentikan backfill atau promosi, simpan bukti, dan pilih artefak yang kompatibel atau perbaikan maju yang telah ditinjau. Jangan mengklaim bahwa rollback aplikasi merekonstruksi data yang sudah ter-commit.
Nonaktifkan bidang lama di rilis lain yang ditinjau
Hapus pembacaan dan penulisan lama setelah backfill dan periode observasi memenuhi kriteria Anda. Periksa juga job yang jarang berjalan serta rute interaktif. Menghapus bidang lama termasuk dalam perubahan berikutnya dengan keputusan pemulihannya sendiri, sehingga masalah rilis tidak memaksa Anda menggabungkan perbaikan kode dengan rekonstruksi data.
Jika data buruk muncul setelah penghapusan, hentikan kerusakan lebih lanjut dan gunakan rencana pemulihan atau perbaikan yang disetujui. Jangan menerapkan down migration yang destruktif hanya karena tooling menampilkan tombol rollback. Lampirkan matriks ke catatan rilis dan latih pemulihan data sebelum mengubah produksi. Hasil yang berguna adalah batas kompatibilitas yang eksplisit, bukan jaminan zero-downtime.
Referensi resmi
Dokumentasi telah ditinjau untuk artikel ini. Contoh adalah latihan perencanaan, bukan perintah yang diuji pada server PrivacyNodes. Periksa dokumentasi untuk versi yang terpasang.