Wawancara Data: Bagaimana PostgreSQL 18 Melanjutkan Replikasi Logis Setelah Failover?

Prompt dan kasus penggunaan

Primary PostgreSQL 18 mengirimkan perubahan melalui replikasi logis ke kluster analitik dan subscriber eksternal. Primary dapat melakukan failover ke standby fisik. Rancang slot, pengaturan, pemeriksaan subscriber, dan urutan cutover sehingga replikasi logis dilanjutkan dari posisi yang benar tanpa membingungkan antara "standby tersinkronisasi" dengan "subscriber telah mengejar ketinggalan (caught up)."

Apa yang sedang diuji oleh pewawancara

Apakah Anda membedakan slot logis, slot fisik, retensi WAL, dan posisi yang dikonfirmasi subscriber.
Apakah Anda memahami bahwa sinkronisasi failover slot bersifat asinkron dan harus terbukti siap sebelum cutover.
Apakah Anda dapat menggunakan pg_replication_slots, LSN, dan status subscription untuk membuktikan pengalihan yang aman.
Apakah Anda menangani slot yang tidak valid, subscriber yang tertinggal, cutover terencana, dan kegagalan tak terduga.

Pertanyaan untuk diklarifikasi sebelum menjawab

Apakah subscriber berupa PostgreSQL atau sistem eksternal, dan apakah mereka dapat terhubung kembali ke primary baru?
Apakah RPO yang diizinkan adalah nol, celah LSN terbatas, atau snapshot subscription yang dapat dibangun kembali?
Apakah slot replikasi fisik dan batasan standby sinkron dikonfigurasi antara primary dan standby?
Apakah cutover otomatis atau manual, dan siapa yang membekukan penulisan serta memperbarui perutean koneksi?

Kerangka kerja jawaban 30 detik

Saya akan mengaktifkan failover untuk setiap slot logis yang harus bertahan setelah pengalihan sehingga statusnya disinkronkan ke hot standby. Saya juga akan mengonfigurasi batasan sinkronisasi fisik sehingga subscriber tidak dapat melihat progres yang belum dipersistensikan oleh standby yang akan mengambil alih. Sebelum cutover, verifikasi setiap slot yang diperlukan pada standby berstatus synced, non-sementara (non-temporary), dan tidak diinvalidasi. Promosikan standby, perbarui koneksi, verifikasi subscriber mengonsumsi dari primary baru, lalu cairkan penulisan (unfreeze writes). Jika sinkronisasi asinkron tertinggal, tunda pengalihan atau terima RPO yang terdokumentasi serta biaya pembangunan ulang.

Pembahasan mendalam langkah demi langkah

1. Apa yang disimpan oleh slot replikasi logis

Slot logis menyimpan progres decoding dan batas retensi WAL yang belum dikonfirmasi oleh subscriber. Slot bukanlah sinyal kesehatan untuk subscriber; subscriber yang terhenti dapat membuat primary mempertahankan WAL dan menghabiskan ruang disk.

2. Membuat slot failover

PostgreSQL 18 mendukung pengaturan failover saat membuat slot logis, dan opsi terkait saat membuat subscription. SQL di bawah ini bersifat ilustratif; verifikasi argumen dan hak akses yang tepat terhadap versi target dan metode penerapan.

sql

SELECT *
FROM pg_create_logical_replication_slot('analytics_slot', 'pgoutput', false, true);

Flag failover memungkinkan status slot untuk disinkronkan ke standby, namun ini tidak membuktikan bahwa sinkronisasi telah selesai.

3. Pengaturan sinkronisasi standby

Standby harus mengaktifkan penerimaan dan penerapan sinkronisasi slot logis, seperti sync_replication_slots. Primary dapat menggunakan synchronized_standby_slots untuk mewajibkan slot fisik tertentu mengejar ketinggalan terlebih dahulu, mencegah progres subscriber logis melampaui standby yang akan mengambil alih.

4. Mengapa kesiapan asinkron memerlukan pemeriksaan terpisah

Sinkronisasi slot menyalin status secara asinkron. Pada saat terjadi kegagalan primary, standby mungkin memiliki halaman data tetapi tidak memiliki posisi slot terbaru. Mempromosikan secara langsung dapat membuat subscriber kehilangan titik awalnya atau menyebabkan duplikasi dan celah data.

5. Memeriksa status slot sebelum cutover

Kueri pg_replication_slots pada kandidat standby. Konfirmasikan setiap slot yang diperlukan telah disinkronkan, bukan sementara, dan tidak memiliki alasan pembatalan (invalidation reason), lalu cocokkan hasilnya dengan inventaris subscriber.

sql

SELECT slot_name,
       synced,
       temporary,
       invalidation_reason,
       confirmed_flush_lsn
FROM pg_replication_slots
WHERE slot_type = 'logical';

Hanya ketika setiap slot yang diperlukan lolos, standby boleh ditandai siap untuk mengambil alih.

6. Pemeriksaan ekstra untuk subscriber PostgreSQL

Untuk subscriber PostgreSQL, konfirmasikan juga bahwa subscriber telah mengonsumsi posisi yang kompatibel dengan slot yang disinkronkan. Lag fisik dari primary ke standby saja tidak cukup; gabungkan status subscription, LSN terakhir yang diterima, dan lag bisnis.

7. Mengalihkan subscriber eksternal

Sistem eksternal biasanya tidak dapat menginterpretasikan status slot PostgreSQL secara otomatis. Orkestrator cutover harus membekukan atau menjeda konsumsi, mempromosikan standby, memperbarui koneksi dan nama slot, lalu menggunakan event yang idempoten serta offset aplikasi untuk membuktikan tidak ada data yang terlewati.

8. Jalur kegagalan dan pemulihan

Pengalihan terencana dapat menunggu hingga semua slot disinkronkan. Kegagalan tak terduga memerlukan keputusan RPO: menerima celah, menunda lalu lintas, atau membangun kembali subscription. Primary lama yang telah pulih tidak boleh langsung bergabung kembali ke jalur penulisan; isolasi node tersebut, bangun kembali replikasi fisik, dan periksa ulang status slot serta subscription.

Pertukaran (trade-off) dan batasan

Slot failover meningkatkan keterpulihan replikasi logis tetapi menambah kompleksitas sinkronisasi slot dan pemantauan WAL.
Menunggu sinkronisasi slot penuh mengurangi celah data tetapi dapat memperpanjang waktu failover.
synchronized_standby_slots membatasi progres logis relatif terhadap standby fisik; ini tidak memberikan kehilangan nol (zero loss) menyeluruh (end-to-end) untuk setiap subscriber eksternal.
Slot yang tidak valid, penyimpanan yang hampir penuh, dan subscriber yang berhenti lama memerlukan peringatan dan pembersihan, bukan hanya skrip cutover.

Rencana implementasi dan bukti

Buat slot logis failover di kluster uji PostgreSQL 18 dan verifikasi pengaturan serta hak akses primary/standby.
Simulasikan penghentian subscriber, penumpukan WAL, slot yang tidak tersinkronisasi, dan hilangnya primary secara tiba-tiba; catat LSN dan hasil pemulihan.
Otomatiskan kueri pra-cutover pg_replication_slots dan bandingkan inventaris slotnya dengan subscriber.
Lakukan latihan jeda, promosi, penyambungan ulang, pengejaran data, dan rollback pada jalur kegagalan terencana maupun tak terduga.
Tinjau parameter dan batasan terhadap dokumentasi PostgreSQL 18 Logical Replication Failover, Logical Decoding, dan Streaming Replication.

Kesalahan umum dan pertanyaan lanjutan

Kesalahan 1: Mengasumsikan data standby berarti pengambilalihan logis siap

Status slot disinkronkan secara asinkron. Halaman data yang telah mengejar ketertinggalan tidak membuktikan bahwa posisi slot dapat digunakan; periksa kolom sinkronisasi dan pembatalan (invalidation).

Kesalahan 2: Hanya memantau lag replikasi fisik

Pantau juga konsumsi subscriber, LSN slot yang dikonfirmasi, WAL yang tertahan, dan lag bisnis. Backlog logis dapat bertambah sementara replikasi fisik terlihat sehat.

Kesalahan 3: Memperlakukan opsi failover sebagai pengalihan otomatis

Opsi ini mengaktifkan sinkronisasi status slot; ini tidak mempromosikan standby, memperbarui koneksi, atau memvalidasi subscriber eksternal. Cutover tetap membutuhkan orkestrasi dan latihan.

Lanjutan: Bisakah Anda mempromosikan sebelum slot disinkronkan?

Hanya dengan keputusan RPO, celah data, atau pembangunan ulang yang eksplisit. Gerbang (gate) default harus menunggu sinkronisasi dan mencatat hasilnya.

Lanjutan: Bagaimana cara menghindari konsumsi ganda?

Persistensikan id event atau LSN sumber, lanjutkan dari posisi yang dapat diverifikasi setelah cutover, dan gunakan penanganan yang idempoten ditambah rekonsiliasi untuk pemutaran ulang (replay).