Dua Bulan Menjelang Akhir Dukungan PostgreSQL 14: Latih Pemulihan Sebelum Melakukan Peningkatan
Ada tim yang telah menetapkan jadwal untuk meningkatkan versi basis data mereka, tetapi tidak mengetahui berapa lama waktu yang dibutuhkan untuk kembali ke kondisi semula jika terjadi kegagalan. Jika Anda menjalankan PostgreSQL 14, hasil kerja yang dibutuhkan saat ini bukanlah sekadar nama versi baru, melainkan rencana transisi yang memungkinkan pemulihan. Per 14 September 2026, tersisa sekitar dua bulan hingga tanggal resmi berakhirnya dukungan.
Fakta yang Terverifikasi: Dukungan Komunitas dan Kontrak Hosting Berbeda
Kebijakan versi resmi PostgreSQL mendukung versi mayor selama 5 tahun, dan mencantumkan 12 November 2026 sebagai tanggal rilis terakhir untuk versi 14. Ini adalah jadwal dukungan komunitas. Periode jendela peningkatan, dukungan perpanjangan terpisah, dan biaya untuk layanan terkelola harus dikonfirmasi secara terpisah dalam dokumentasi dan kontrak penyedia terkait.
Pembaruan minor dan peningkatan mayor dalam versi mayor yang sama juga harus dibedakan. Menerapkan versi perbaikan terbaru dari 14 tidak menggantikan tugas migrasi ke versi 15 atau yang lebih baru. Sebaliknya, terus menunda penerapan perbaikan yang diperlukan pada versi saat ini hanya karena ada rencana transisi mayor juga tidak tepat.
Hasil Kerja Pertama: Daftar Ketergantungan, Bukan Ukuran Data
Mulai bagian ini, isinya merupakan saran operasional praktis dan bukan kebijakan dukungan resmi itu sendiri. Pertama, catat dalam satu lembar mengenai versi DB per layanan, ekstensi beserta versinya, driver koneksi, tugas batch, lokasi penyimpanan cadangan, dan konfigurasi replikasi. Jangan menentukan versi target hanya karena itu yang terbaru, tetapi periksa juga cakupan dukungan dari lingkungan hosting sebenarnya dan modul ekstensi.
Asumsi bahwa prosesnya akan cepat karena ukuran DB kecil tidaklah memadai. Jika ekstensi atau kueri yang digunakan pada jalur penting bisnis—seperti kueri pertama setelah login atau pembaruan status pembayaran—berubah, transisi dapat gagal meskipun penyalinan data berlangsung singkat. Tujuan dari daftar ini adalah menemukan ketergantungan yang tidak memiliki penanggung jawab.
Hasil Kerja Kedua: Hasil Pemulihan, Bukan Pesan Keberhasilan Pencadangan
Pulihkan cadangan terbaru ke lingkungan yang terisolasi dan jalankan alur baca-tulis representatif aplikasi Anda. Dalam latihan ini, periksa tujuan koneksi terlebih dahulu agar tidak mengirimkan operasi tulis ke DB produksi. Salinan pemulihan yang berisi data sebenarnya harus ditangani dalam cakupan kontrol akses yang ada.
Memisahkan waktu mulai pencadangan, waktu selesai pemulihan, dan waktu selesai verifikasi akan mencegah kebingungan antara waktu mengambil berkas dan waktu layanan dapat menulis kembali. Daripada hanya meloloskan sampel kecil yang cepat secara semu, ukur waktunya menggunakan salinan pemulihan yang mendekati ukuran produksi, dan catat pula batasan biaya serta ruang penyimpanan.
Lolos Pemeriksaan pg_upgrade Tidak Menggantikan Verifikasi Layanan
Dokumentasi resmi pg_upgrade menjelaskan bahwa pemeriksaan kompatibilitas dapat dilakukan sebelum peningkatan sebenarnya menggunakan opsi --check. Kompatibilitas modul eksternal harus diperiksa secara terpisah, dan pustaka bersama yang sesuai untuk server baru juga diperlukan. Jangan menafsirkan keberhasilan perintah pemeriksaan saja sebagai bukti bahwa seluruh kueri dan performa aplikasi telah terverifikasi.
Secara khusus, metode --link memiliki batasan di mana kluster lama tidak dapat lagi digunakan begitu saja setelah kluster baru dimulai. Memilih metode hanya berdasarkan kecepatan dapat menghilangkan jalur pembatalan (rollback) yang telah diperkirakan. Lakukan gladi bersih dengan kondisi yang sama persis seperti metode transisi sebenarnya, dan tentukan secara eksplisit kapan titik pemulihan berbasis cadangan diperlukan.
Kriteria yang Harus Diputuskan Sebelum Melanjutkan Penulisan
Tuliskan kriteria keberhasilan terlebih dahulu agar tidak perlu berunding secara mendadak pada hari transisi. Sebagai contoh, Anda dapat menghubungkan penanggung jawab dengan penyelesaian baca/tulis API inti, pelanjutan batch tanpa pemrosesan ganda, kesesuaian agregasi bisnis pada tabel utama, serta pemeriksaan status replikasi. Ini bukan contoh yang memaksakan nilai kriteria yang sama untuk semua layanan.
Jika Anda harus kembali ke cadangan sebelumnya setelah mulai menulis ke DB baru, bagaimana mempertahankan perubahan yang terjadi di antaranya juga akan menjadi masalah. Menghidupkan kembali server lama tidak dapat diperlakukan sama dengan prosedur pengembalian tanpa kehilangan data. Batas kehilangan data dan durasi henti yang dapat ditoleransi harus disepakati oleh penanggung jawab layanan.
Tugas Pekan Ini dan Sanggahan
Jika sulit untuk memindahkan semua DB sekaligus, ukur waktu pemulihan, verifikasi, dan pembatalan pada satu layanan yang memiliki ketergantungan paling sedikit, lalu gunakan hasilnya sebagai masukan bagi rencana layanan lainnya. Mengumpulkan penanggung jawab, tanggal kandidat transisi, dan kriteria penghentian jika verifikasi gagal ke dalam satu dokumen akan mengubah proyek yang tadinya hanya berupa jadwal menjadi tugas yang dapat dieksekusi.
Sanggahan bahwa pengembangan produk lebih mendesak saat ini dapat dipahami. Namun, jika Anda tetap tidak mengetahui metode pemulihan hingga menjelang tenggat waktu, waktu pemeriksaan yang dapat dipilih akan semakin sempit. Artikel ini tidak mengklaim peningkatan performa versi tertentu maupun mewakili opini komunitas secara keseluruhan. Ini adalah saran operasional yang berfokus pada kesiapan menangani kegagalan transisi, bukan pada kecepatan mengadopsi fitur-fitur terbaru.