Wawancara data engineering: Bagaimana Anda menetapkan gerbang evaluasi peningkatan versi PostgreSQL 19 Beta 2?

Konteks dan pertanyaan

Sebuah tim SaaS menjalankan PostgreSQL 18 dan ingin memperoleh bukti awal tentang PostgreSQL 19 Beta 2. Beban kerjanya mencakup transaksi berdurasi panjang, replikasi logis, ekstensi, pencadangan, dan tugas batch pada jam sibuk. Rancang evaluasi yang menggunakan bukti representatif tanpa membiarkan kluster beta menangani lalu lintas produksi. Jika hasilnya tidak stabil, bagaimana Anda menghentikannya dan kembali ke versi saat ini?

Proyek PostgreSQL mendeskripsikan versi beta sebagai pratinjau fitur yang detailnya dapat berubah sebelum rilis final dan tidak menyarankan untuk menjalankannya di lingkungan produksi. Dokumentasi resmi pg_upgrade menyatakan bahwa alat tersebut dapat meningkatkan ke rilis utama saat ini, termasuk snapshot beta, tetapi kompatibilitas biner modul eksternal tidak dapat diperiksa sepenuhnya oleh alat tersebut. Wawancara ini menguji rantai bukti dan tata kelola peningkatan versi.

Hal yang dinilai oleh pewawancara

Pewawancara mencari pemisahan yang jelas antara eksplorasi, kandidat peningkatan versi, dan rilis produksi. Jelaskan baseline yang dapat direproduksi, pemeriksaan pra-peningkatan, batas anggaran performa, dan kondisi penghentian. Jawaban yang kuat mencakup ketidakpastian versi beta, kompatibilitas ekstensi dan klien, latihan pemulihan cadangan (backup-restore drills), sinyal yang dapat diamati, serta kepemilikan keputusan.

Pertanyaan klarifikasi yang perlu diajukan

• Apakah tujuannya untuk memvalidasi fitur baru, mengurangi biaya, meningkatkan latensi, atau memastikan kompatibilitas ekstensi dan toolchain?
• Beban kerja mana yang harus diputar ulang secara setara? Apakah transaksi berdurasi panjang, jeda replikasi (replication lag), dan pemulihan termasuk dalam cakupan?
• Berapa versi saat ini, daftar ekstensi, driver klien, metode pencadangan, RPO, dan RTO?
• Apakah kluster beta sepenuhnya terisolasi, apakah data perlu dide-identifikasi, dan tim mana yang menyetujui hasilnya?
• Jika versi beta tidak lolos gerbang pengujian, apakah rencana keamanan dan kapasitas versi saat ini tetap valid?

Jawaban 30 detik

“Saya akan memperlakukan versi beta sebagai eksperimen terisolasi, bukan komitmen produksi. Pertama, saya akan membekukan baseline PostgreSQL 18, menyalin data yang telah dide-identifikasi, dan memutar ulang beban kerja representatif. Di kluster terpisah, saya akan menjalankan pg_upgrade --check, pemeriksaan ekstensi dan driver, latihan pemulihan cadangan, serta uji kegagalan, kemudian membandingkan latensi, throughput, antrean kunci (lock waits), jeda replikasi, tingkat kesalahan, dan penggunaan sumber daya. Setiap sinyal diberi ambang batas kelulusan dan ambang batas penghentian; kerusakan data, pemulihan yang gagal, atau kendala kompatibilitas berarti penghentian seketika. Hanya rilis final, bukti yang berulang, dan jalur rollback yang dapat membenarkan penerapan canary terkontrol.”

Jawaban mendalam langkah demi langkah

1. Ubah tujuan menjadi hipotesis yang dapat diuji (falsifiable)

Jangan mulai dengan “versi baru harus lebih cepat.” Nyatakan hipotesis seperti pengurangan 10% pada p95 batch, waktu pemulihan tidak lebih buruk dari baseline, atau setiap ekstensi yang ada berhasil dikompilasi dan lolos regresi pada versi target. Setiap hipotesis memerlukan sumber data, jendela pengukuran, dan definisi kegagalan agar sampel yang berhasil tidak dipilih secara bias (cherry-picked).

2. Bekukan baseline yang dapat direproduksi

Pada PostgreSQL 18, catat persentil latensi, throughput, CPU, memori, IO, antrean kunci, volume WAL, jeda replikasi, tingkat kesalahan, dan waktu pemulihan di bawah perangkat keras, pengaturan, ukuran data, dan beban kerja yang sama. Ambil rencana kueri dan versi statistik, serta tetapkan pengaturan driver klien dan connection pool. Tanpa baseline, suatu perubahan tidak dapat dikaitkan dengan perbedaan versi melainkan bisa jadi karena variasi eksperimen.

3. Isolasi kluster beta dan jalur data

Gunakan jaringan, kredensial, bucket pencadangan, dan namespace pemantauan yang terpisah. Lakukan de-identifikasi data produksi sebelum mengimpornya melalui snapshot, salinan replika logis, atau log yang dapat diputar ulang. Jangan biarkan kluster beta menulis ke instans utama produksi, berbagi VIP failover, atau menjadi satu-satunya sumber pencadangan. Pertahankan urutan, konkurensi, dan lalu lintas khusus sambil menerapkan pembatasan laju (rate-limiting) untuk melindungi eksperimen.

4. Jalankan pemeriksaan peningkatan versi dan kompatibilitas terlebih dahulu

Jalankan pg_upgrade --check dan simulasi (dry run). Verifikasi biner lama dan baru, direktori data, locale, checksum, tablespace, ekstensi, modul eksternal, dan driver klien. Karena pg_upgrade tidak dapat memvalidasi setiap modul eksternal, instal ulang atau bangun ulang ekstensi pada target dan jalankan pengujian migrasi aplikasi. Pemeriksaan awal yang bersih bukanlah jaminan lolosnya regresi bisnis.

pg_upgrade --check \
  --old-bindir=/opt/postgresql/18/bin \
  --new-bindir=/opt/postgresql/19/bin \
  --old-datadir=/data/pg18 \
  --new-datadir=/data/pg19

5. Putar ulang beban kerja secara bertahap

Mulailah dengan kompatibilitas SQL, skrip migrasi, dan pengujian ORM. Kemudian jalankan batch offline, operasi baca dan tulis campuran, transaksi berdurasi panjang, replikasi logis, dan pemulihan cadangan. Bandingkan p50, p95, p99, dan error pada tail alih-alih hanya nilai rata-rata. Buat peringatan untuk perubahan rencana kueri, antrean kunci, VACUUM, WAL, slot replikasi, dan log ekstensi; jangan sembunyikan regresi pada jalur kritis di balik rata-rata agregat.

6. Tetapkan gerbang, rollback, dan catatan keputusan

Tentukan hasil untuk lanjut, jeda, dan keluar sejak awal. Kegagalan validasi data, kegagalan latihan pemulihan, ekstensi penting yang tidak tersedia, atau tingkat kesalahan dan jeda replikasi yang melebihi anggaran berarti keluar; jangan melonggarkan gerbang hanya untuk mengejar target kalender. Simpan cadangan PostgreSQL 18 yang dapat di-boot, skrip rollback, laporan perbedaan data, versi konfigurasi, dan daftar masalah yang diketahui. Hasil beta menginformasikan rencana pengujian berikutnya, bukan janji tentang rilis final.

Contoh jawaban berkualitas tinggi

Saya akan menyatakan hipotesis dan risiko yang tidak dapat diterima terlebih dahulu, lalu membekukan perangkat keras, konfigurasi, ukuran data, dan beban kerja pada baseline PostgreSQL 18. Kluster beta akan menggunakan data yang dide-identifikasi, jaringan terpisah, dan pencadangan terpisah. Saya akan menjalankan pg_upgrade --check, lalu memverifikasi ekstensi, driver, tablespace, dan klien. Setelah itu, saya akan memutar ulang SQL, batch, transaksi berdurasi panjang, replikasi, pemulihan kegagalan, dan pemulihan cadangan, membandingkan p95/p99, throughput, antrean kunci, WAL, jeda replikasi, tingkat kesalahan, dan RTO. Setiap sinyal akan memiliki ambang batas lulus dan berhenti; kerusakan data, kegagalan pemulihan, atau masalah kompatibilitas kritis akan langsung diarahkan ke jalur rollback versi 18. Hanya rilis final, pengujian berulang yang berhasil, dan persetujuan pemilik bisnis yang memungkinkan rilis canary berisiko rendah yang dipantau dan dapat dihentikan sewaktu-waktu.

Kesalahan umum

• Memperlakukan beta sebagai kandidat produksi → Detail fitur masih bisa berubah → Jaga agar tetap terisolasi dan tunggu rilis final serta bukti yang teruji berulang kali.
• Hanya menjalankan pg_upgrade --check → Pemeriksaan alat tidak mencakup perilaku bisnis atau semua modul eksternal → Tambahkan regresi untuk ekstensi, driver, aplikasi, dan pemulihan.
• Hanya membandingkan latensi rata-rata → Regresi tail latency menjadi tidak terlihat → Lacak p95/p99, kesalahan, dan antrean kunci.
• Memutar ulang operasi tulis produksi secara langsung → Kegagalan pada beta dapat memengaruhi lalu lintas nyata → Gunakan salinan yang dide-identifikasi, jaringan terpisah, dan pemutaran ulang terkontrol.
• Tidak menentukan kondisi penghentian di awal → Jadwal mendesak bukti teknis → Tulis gerbang keluar dan kepemilikan keputusan sebelum pengujian.

Pertanyaan lanjutan dan respons

Bisakah langsung beralih setelah pg_upgrade --check berhasil?

Tidak. Alat tersebut hanya mencakup sebagian dari kondisi pra-peningkatan. Modul eksternal, driver, SQL aplikasi, beban kerja bisnis, dan pemulihan tetap memerlukan validasi terpisah.

Mengapa harus mempertahankan baseline PostgreSQL 18 dan jalur rollback?

Tanpa baseline, perubahan versi tidak dapat dibedakan dari variasi eksperimen. Tanpa jalur pemulihan versi lama yang dapat di-boot, eksperimen yang gagal dapat berubah menjadi insiden migrasi yang tidak terkendali.

Bagaimana cara menghindari pengujian yang hanya condong pada skenario beta yang menguntungkan?

Pilih skenario lalu lintas puncak, transaksi berdurasi panjang, lalu lintas abnormal, replikasi, dan pemulihan sebelumnya. Tetapkan urutan pemutaran ulang dan ukuran data, serta catat kegagalan dan metrik tail bersama dengan hasil yang berhasil.

Bagaimana cara memverifikasi kompatibilitas biner ekstensi?

Instal ulang atau bangun ulang setiap ekstensi pada target dengan opsi build yang sesuai, lalu jalankan pengujian ekstensi tersebut dan regresi aplikasi. Jangan menganggap lolosnya pemeriksaan pg_upgrade sebagai jaminan untuk ekstensi.

Kapan evaluasi dapat dilanjutkan ke tahap canary di produksi?

Hanya setelah rilis final tersedia, beban kerja kritis berhasil lolos berulang kali, latihan pemulihan cadangan dan rollback berhasil, masalah kompatibilitas memiliki penanggung jawab serta mitigasi, dan pemilik bisnis serta pemilik basis data menyetujui penerapan canary berisiko rendah yang dipantau dan dapat dihentikan sewaktu-waktu.