Wawancara Backend: Bagaimana Anda Merancang Failover Replikasi Logis PostgreSQL?

Konteks dan cakupan

Anda mengoperasikan consumer CDC yang membaca perubahan dari database PostgreSQL produksi. Selama switchover terencana atau kegagalan tak terduga, bagaimana Anda memastikan primary baru dapat terus melayani logical replication slot yang sama tanpa menyembunyikan duplikat, gap, penumpukan WAL, atau klaim zero-loss yang tidak berdasar? Jelaskan failover slot PostgreSQL 18, pemeriksaan sinkronisasi, penyambungan ulang consumer, pemantauan, dan rollback.

Dokumentasi PostgreSQL menyatakan bahwa logical replication slot dapat disinkronkan ke standby fisik, tetapi sinkronisasi slot bersifat asinkron. Sebelum mempromosikan standby, slot yang diperlukan harus ada dan dilaporkan sebagai failover_ready. Pertanyaan keandalan backend ini menguji apakah Anda dapat menghubungkan kapabilitas database, semantik consumer, dan orkestrasi failover ke dalam proses yang dapat diverifikasi.

Hal yang dievaluasi oleh pewawancara

• Membedakan replikasi WAL fisik, logical replication slot, dan acknowledgement consumer.
• Menjelaskan batasan opsi slot failover dan synchronized_standby_slots.
• Menangani switchover terencana dan kegagalan mendadak dengan jendela kehilangan dan duplikasi yang berbeda.
• Mengetahui bahwa standby yang aktif bukanlah bukti bahwa setiap logical slot telah siap.
• Merancang peringatan untuk retensi WAL, lag slot, penyambungan ulang, dan keterlambatan consumer.
• Menetapkan connection discovery, fencing, dan idempotensi downstream ke komponen yang eksplisit.

Pertanyaan klarifikasi yang perlu diajukan

1. Apakah consumer merupakan subscriber PostgreSQL lain atau klien CDC non-PostgreSQL seperti Debezium? Pemeriksaan kesiapan berbeda.
2. Apakah targetnya adalah switch terencana dengan near-zero-loss atau batas recovery point tertentu setelah crash?
3. Bisakah downstream melakukan deduplikasi berdasarkan LSN, transaction ID, event ID, atau business key?
4. Apakah primary dan standby menggunakan versi mayor PostgreSQL dan plugin output yang sama?
5. Koordinator mana yang mempromosikan standby, mengubah discovery, melakukan fencing pada primary lama, dan mencegah split-brain?

Jawaban 30 detik

Saya akan menentukan recovery point dan toleransi duplikat terlebih dahulu, lalu memodelkan sinkronisasi slot, promosi, penyambungan ulang, dan idempotensi downstream sebagai sebuah state machine. Saya akan mengaktifkan failover untuk setiap logical slot yang harus bertahan setelah promosi dan memverifikasi setiap slot di standby, termasuk keberadaannya, status sinkronisasi, dan nilai failover_ready. Saat pengalihan, saya akan melakukan fencing pada primary lama sebelum mengubah discovery. Consumer akan melanjutkan dari LSN yang tercatat; transaksi yang di-replay akan dinetralkan oleh idempotensi berbasis LSN atau business-key. Saya akan memantau lag slot, WAL yang tertahan, keterlambatan consumer, dan hasil reconnect, serta tidak memperlakukan sinkronisasi slot asinkron sebagai jaminan zero-loss.

Pembahasan mendalam langkah demi langkah

1. Tentukan semantik data

Cantumkan RPO, RTO, dan penanganan duplikat ke dalam rancangan. Switchover terencana dapat menunggu hingga slot yang diperlukan tersinkronisasi; kegagalan mendadak hanya dapat memulihkan dari WAL yang telah mencapai standby yang dipromosikan. Consumer harus menyimpan LSN terakhir yang dikonfirmasi atau posisi yang setara, dan efek samping harus menggunakan idempotency key.

2. Konfigurasikan logical slot yang mendukung failover

PostgreSQL 18 mendukung logical slot yang dapat disinkronkan ke standby. Aktifkan opsi failover saat membuat slot atau subscription, dan pelihara inventaris setiap slot yang dibutuhkan armada consumer. Jangan lupakan slot sinkronisasi tabel atau consumer sekunder.

-- Illustrative only: allow a logical slot to synchronize to a standby
SELECT *
FROM pg_create_logical_replication_slot('cdc_orders', 'pgoutput', false, true);

Signature dan izin yang tepat harus cocok dengan versi PostgreSQL dan plugin yang di-deploy. Contoh ini tidak dapat menggantikan pemeriksaan konfigurasi dan kompatibilitas.

3. Teruskan state slot melalui replikasi fisik

Konfigurasikan standby fisik untuk menerima WAL dan gunakan synchronized_standby_slots jika alur kerja failover yang terdokumentasi memerlukannya. Sebelum promosi, periksa pg_replication_slots di standby dan pastikan setiap slot yang diperlukan ada, tersinkronisasi, dan berstatus failover_ready. Penyalinan slot bersifat asinkron, sehingga koneksi streaming yang sehat saja tidak cukup.

4. Switchover terencana

Jeda atau drain consumer CDC dan catat posisi terakhir yang dikonfirmasi. Hentikan penulisan pada primary lama dan tunggu replikasi fisik serta sinkronisasi slot. Rekonsiliasi inventaris slot pada kedua node, promosikan hanya setelah semua slot yang diperlukan siap, lalu ubah connection discovery dan lanjutkan consumer dari logical slot yang sama. Jika batas tersebut di-replay, pemeriksaan LSN downstream atau idempotensi akan menghilangkan efek duplikat.

5. Kegagalan mendadak dan perlindungan split-brain

Crash tidak dapat menunggu sinkronisasi slot. Lakukan fencing pada primary lama sebelum dapat pulih dan menulis kembali, lalu hitung recovery point yang dibuktikan oleh node yang dipromosikan. Koordinator harus memastikan bahwa hanya satu node yang dapat ditulis. Setelah perubahan DNS, VIP, atau service discovery, consumer harus memvalidasi identitas server dan keberadaan slot. Slot yang tidak tersinkronisasi harus dilaporkan sebagai handoff yang tidak lengkap, dengan pemulihan manual atau pembuatan ulang subscription sebagai opsi eksplisit.

6. Pantau retensi WAL dan progres consumer

Lacak restart_lsn, confirmed_flush_lsn, lag slot, WAL yang tertahan, jumlah reconnect, dan keterlambatan end-to-end dari setiap slot. Slot yang ditinggalkan dapat mencegah daur ulang WAL dan memenuhi disk. Pisahkan peringatan untuk "slot ada" dari "consumer telah memproses hingga LSN target", serta tetapkan batas waktu, throttle, dan ambang batas intervensi manusia untuk pemulihan.

7. Rollback, rebuild, dan penerimaan

Jika pemeriksaan kesiapan gagal, jangan melakukan promosi otomatis; pertahankan primary lama atau masuk ke mode degraded yang dideklarasikan. Lakukan simulasi switchover terencana, pemadaman listrik mendadak, pemutusan consumer, keterlambatan sinkronisasi slot, dan restart primary lama. Catat commit terakhir, event pertama di primary baru, jumlah duplikat, jumlah gap, RTO, dan penggunaan disk puncak. Lacak setiap gap hingga ke LSN.

Contoh jawaban berkualitas tinggi

Saya akan memodelkan alur kerja menjadi enam status: slot siap, primary lama di-fence, standby dipromosikan, discovery dialihkan, consumer dilanjutkan, dan posisi downstream dikonfirmasi. Saya akan mengaktifkan failover untuk logical slot yang diperlukan dan memeriksa synchronized_standby_slots serta pg_replication_slots di standby hingga setiap slot ada dan berstatus failover_ready. Karena sinkronisasi bersifat asinkron, standby yang aktif bukanlah bukti yang cukup untuk promosi yang aman.

Untuk switch terencana, saya akan menjeda consumer, membekukan penulisan di primary lama, menunggu replikasi fisik dan sinkronisasi slot, lalu melakukan promosi. Untuk crash, saya akan mem-fence primary lama dan menyatakan RPO yang dapat dipulihkan daripada mengklaim zero-loss. Consumer akan menyambung kembali dan melanjutkan dari LSN yang tersimpan; idempotensi downstream akan menyerap replay. Terakhir, saya akan memantau lag slot, retensi WAL, keterlambatan consumer, reconnect, dan gap, serta memvalidasi RPO dan RTO dengan simulasi pemadaman listrik dan penundaan sinkronisasi.

Kesalahan umum

• Mempromosikan hanya karena standby sedang online → sinkronisasi slot mungkin belum selesai → periksa keberadaan setiap slot, status sinkronisasi, dan failover_ready.
• Menganggap logical slot sebagai bukti bahwa consumer telah memproses data → status slot berbeda dari acknowledgement downstream → lacak LSN dan posisi consumer secara terpisah.
• Menjanjikan zero-loss saat crash → WAL yang belum tersinkronisasi mungkin tidak tersedia → nyatakan RPO terencana dan tidak terencana secara terpisah.
• Mengubah DNS tanpa mem-fence primary lama → penulisan split-brain tetap mungkin terjadi → lakukan fencing terlebih dahulu, lalu promosikan dan alihkan discovery.
• Mengabaikan slot yang macet → WAL yang tertahan dapat menghabiskan ruang disk → beri peringatan pada lag, disk, dan usia retensi maksimum.
• Hanya menguji promosi database → consumer, plugin, dan efek downstream bisa gagal → jalankan simulasi replay end-to-end.

Pertanyaan lanjutan dan tanggapan

Apakah failover_ready membuktikan bahwa tidak ada event yang hilang?

Tidak. Ini hanya menyatakan bahwa logical slot yang relevan telah disinkronkan ke standby target dan dapat dilanjutkan setelah promosi. Kehilangan data tetap bergantung pada replikasi fisik pada saat kegagalan, posisi acknowledgement consumer, dan semantik pemrosesan downstream.

Mengapa menjeda consumer selama switch terencana?

Menjeda akan mengunci posisi terakhir yang dikonfirmasi dan mencegah consumer membaca dari primary lama dan baru secara bersamaan. Koordinator yang lebih rumit dimungkinkan, tetapi harus membuktikan bahwa ia mencegah split-brain, perubahan urutan, dan acknowledgement yang ambigu.

Bagaimana klien CDC non-PostgreSQL harus memverifikasi kesiapan?

Klien tersebut tidak dapat menggunakan kembali kueri subscription PostgreSQL secara langsung. Klien harus mengelola inventaris slot dan pemeriksaan kesehatannya sendiri, memverifikasi slot yang disinkronkan di standby, lalu memvalidasi koneksi baru dan kontinuitas posisi menggunakan protokol kliennya.

Bagaimana jika slot tidak tersinkronisasi tetapi bisnis harus segera pulih?

Nyatakan RPO aktual dan pilih recovery point yang konservatif. Buat ulang slot, buat snapshot baru, atau lakukan kompensasi dari cadangan jika diperlukan. Jangan menampilkan status replikasi yang belum diverifikasi sebagai pemulihan tanpa kehilangan data.

Bagaimana cara mencegah primary lama aktif kembali?

Gunakan koordinator atau cloud fencing, isolasi jaringan, dan rotasi kredensial penulisan. Perubahan DNS saja tidak dapat menghentikan primary lama untuk menerima penulisan.

Bagaimana Anda membuktikan bahwa replay tidak menimbulkan efek samping duplikat?

Lakukan deduplikasi berdasarkan LSN transaksi, event ID, atau idempotency key, lalu catat jumlah replay, total akhir bisnis, dan batasan pengurutan selama simulasi. Bandingkan posisi yang dapat diaudit sebelum dan sesudah pengalihan.