Temu Duga Backend: Bagaimanakah Anda Mereka Bentuk Failover Replikasi Logikal PostgreSQL?

Skop dan pertanyaan

Anda mengendalikan pengguna CDC yang membaca perubahan daripada pangkalan data PostgreSQL pengeluaran. Semasa pertukaran terancang (switchover) atau kegagalan yang tidak dijangka, bagaimanakah anda membolehkan nod utama (primary) baharu terus menyediakan slot replikasi logikal yang sama tanpa menyembunyikan pendua, jurang (gaps), pengumpulan WAL atau tuntutan sifar kehilangan yang tidak berasas? Terangkan slot failover PostgreSQL 18, pemeriksaan penyelarasan, penyambungan semula pengguna, pemantauan dan rollback.

Dokumentasi PostgreSQL menyatakan bahawa slot replikasi logikal boleh diselaraskan ke nod siap sedia (standby) fizikal, tetapi penyelarasan slot adalah secara tidak segerak (asynchronous). Sebelum menaikkan pangkat standby, slot yang diperlukan mesti wujud dan dilaporkan sebagai failover_ready. Soalan kebolehpercayaan backend ini menguji sama ada anda boleh menghubungkan keupayaan pangkalan data, semantik pengguna dan orkestrasi failover ke dalam proses yang boleh disahkan.

Perkara yang dinilai oleh penemu duga

• Membezakan replikasi WAL fizikal, slot replikasi logikal dan perakuan (acknowledgements) pengguna.
• Menerangkan batasan pilihan slot failover dan synchronized_standby_slots.
• Mengendalikan pertukaran terancang dan kegagalan mendadak dengan tetingkap kehilangan dan penduaan yang berbeza.
• Mengetahui bahawa standby yang aktif bukan bukti bahawa setiap slot logikal telah bersedia.
• Mereka bentuk amaran untuk pengekalan WAL, kelengahan (lag) slot, penyambungan semula dan kelewatan pengguna.
• Menetapkan penemuan sambungan (connection discovery), pemagaran (fencing) dan keidempotetan hiliran kepada komponen yang jelas.

Soalan penjelasan untuk ditanya

1. Adakah pengguna merupakan pelanggan PostgreSQL lain atau klien CDC bukan PostgreSQL seperti Debezium? Pemeriksaan kesediaan adalah berbeza.
2. Adakah sasarannya pertukaran terancang dengan kehilangan hampir sifar atau titik pemulihan terikat selepas nahas (crash)?
3. Bolehkah sistem hiliran menyahduplikasi mengikut LSN, ID transaksi, ID peristiwa atau kunci perniagaan?
4. Adakah nod utama dan standby menggunakan versi utama PostgreSQL dan pemalam output yang sama?
5. Penyelaras manakah yang menaikkan pangkat standby, menukar penemuan, memagar nod utama lama dan menghalang masalah split-brain?

Jawapan 30 saat

Saya akan mentakrifkan titik pemulihan dan toleransi pendua terlebih dahulu, kemudian memodelkan penyelarasan slot, kenaikan pangkat, penyambungan semula dan keidempotetan hiliran sebagai mesin keadaan (state machine). Saya akan mendayakan failover untuk setiap slot logikal yang mesti bertahan selepas kenaikan pangkat dan mengesahkan setiap slot pada standby, termasuk kewujudannya, keadaan penyelarasan dan nilai failover_ready. Semasa pertukaran, saya akan memagar nod utama lama sebelum menukar penemuan sambungan. Pengguna akan menyambung semula dari LSN yang direkodkan; transaksi yang dimainkan semula akan dineutralkan melalui keidempotetan berasaskan LSN atau kunci perniagaan. Saya akan memantau kelengahan slot, WAL yang dikekalkan, kelewatan pengguna dan hasil sambungan semula, serta tidak menganggap penyelarasan slot tidak segerak sebagai jaminan sifar kehilangan.

Panduan mendalam langkah demi langkah

1. Tentukan semantik data

Sertakan RPO, RTO dan pengendalian pendua ke dalam reka bentuk. Pertukaran terancang boleh menunggu slot yang diperlukan diselaraskan; kegagalan mendadak hanya boleh dipulihkan daripada WAL yang telah sampai ke standby yang dinaikkan pangkat. Pengguna harus mengekalkan LSN terakhir yang disahkan atau kedudukan yang setara, dan kesan sampingan harus menggunakan kunci keidempotetan.

2. Konfigurasikan slot logikal yang menyokong failover

PostgreSQL 18 menyokong slot logikal yang boleh diselaraskan ke standby. Dayakan pilihan failover semasa mencipta slot atau langganan, dan kekalkan inventori setiap slot yang diperlukan oleh kumpulan pengguna. Jangan lupa slot penyelarasan jadual atau pengguna sekunder.

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

Tandatangan dan kebenaran yang tepat mesti sepadan dengan versi PostgreSQL dan pemalam yang digunakan. Contoh ini tidak boleh menggantikan pemeriksaan konfigurasi dan keserasian.

3. Bawa keadaan slot melalui replikasi fizikal

Konfigurasikan standby fizikal untuk menerima WAL dan gunakan synchronized_standby_slots di mana aliran kerja failover yang didokumentasikan memerlukannya. Sebelum kenaikan pangkat, periksa pg_replication_slots pada standby dan sahkan bahawa setiap slot yang diperlukan wujud, diselaraskan dan berstatus failover_ready. Menyalin slot adalah tidak segerak, jadi sambungan penstriman yang sihat sahaja tidak mencukupi.

4. Pertukaran terancang (switchover)

Jeda atau alirkan (drain) pengguna CDC dan rekodkan kedudukan terakhir mereka yang disahkan. Hentikan penulisan pada nod utama lama dan tunggu replikasi fizikal serta penyelarasan slot. Selaraskan inventori slot pada kedua-dua nod, naikkan pangkat hanya selepas semua slot yang diperlukan sedia, kemudian tukar penemuan sambungan dan sambung semula pengguna dari slot logikal yang sama. Jika sempadan dimainkan semula, pemeriksaan LSN hiliran atau keidempotetan akan menghapuskan kesan pendua.

5. Kegagalan mendadak dan perlindungan split-brain

Nahas tidak boleh menunggu penyelarasan slot. Pagar nod utama lama sebelum ia boleh kembali dan menulis, kemudian kira titik pemulihan yang dibuktikan oleh nod yang dinaikkan pangkat. Penyelaras mesti memastikan bahawa hanya satu nod boleh ditulis. Selepas perubahan DNS, VIP atau penemuan perkhidmatan, pengguna harus mengesahkan identiti pelayan dan kewujudan slot. Slot yang tidak diselaraskan mesti dilaporkan sebagai penyerahan yang tidak lengkap, dengan pemulihan manual atau pembinaan semula langganan sebagai pilihan yang jelas.

6. Pantau pengekalan WAL dan kemajuan pengguna

Jejak restart_lsn, confirmed_flush_lsn, kelengahan slot, WAL yang dikekalkan, bilangan sambungan semula dan kelewatan hujung ke hujung bagi setiap slot. Slot yang terbiar boleh menghalang kitar semula WAL dan memenuhkan cakera. Asingkan amaran untuk "slot wujud" daripada "pengguna telah memproses sehingga LSN sasaran", dan tetapkan had masa tamat, pendikit (throttles) serta ambang campur tangan manusia untuk pemulihan.

7. Rollback, bina semula dan penerimaan

Jika pemeriksaan kesediaan gagal, jangan naikkan pangkat secara automatik; kekalkan nod utama lama atau masuki mod terdegradasi yang diisytiharkan. Lakukan latihan pertukaran terancang, kehilangan kuasa secara tiba-tiba, pemutusan sambungan pengguna, kelewatan penyelarasan slot dan permulaan semula nod utama lama. Rekodkan komit terakhir, peristiwa pertama pada nod utama baharu, bilangan pendua, bilangan jurang, RTO dan penggunaan cakera puncak. Jejak setiap jurang kembali ke LSN.

Contoh jawapan berkualiti tinggi

Saya akan memodelkan aliran kerja kepada enam keadaan: slot sedia, nod utama lama dipagar, standby dinaikkan pangkat, penemuan ditukar, pengguna disambung semula dan kedudukan hiliran disahkan. Saya akan mendayakan failover untuk slot logikal yang diperlukan dan memeriksa synchronized_standby_slots serta pg_replication_slots pada standby sehingga setiap slot wujud dan berstatus failover_ready. Oleh kerana penyelarasan adalah tidak segerak, standby yang aktif bukan bukti yang mencukupi untuk kenaikan pangkat yang selamat.

Bagi pertukaran terancang, saya akan menjeda pengguna, membekukan penulisan pada nod utama lama, menunggu replikasi fizikal dan penyelarasan slot, dan kemudian menaikkan pangkat. Bagi nahas, saya akan memagar nod utama lama dan menyatakan RPO yang boleh dipulihkan dan bukannya mendakwa sifar kehilangan. Pengguna akan menyambung semula dan meneruskan dari LSN yang disimpan; keidempotetan hiliran akan menyerap main semula. Akhir sekali, saya akan memantau kelengahan slot, pengekalan WAL, kelewatan pengguna, penyambungan semula dan jurang, serta mengesahkan RPO dan RTO melalui latihan kehilangan kuasa dan kelewatan penyelarasan.

Kesilapan lazim

• Menaikkan pangkat hanya kerana standby berada dalam talian → penyelarasan slot mungkin masih belum lengkap → periksa kewujudan setiap slot, keadaan penyelarasan dan failover_ready.
• Menganggap slot logikal sebagai bukti bahawa pengguna telah memproses data → keadaan slot berbeza daripada perakuan hiliran → jejak LSN dan kedudukan pengguna secara berasingan.
• Menjanjikan sifar kehilangan untuk nahas → WAL yang tidak diselaraskan mungkin tidak tersedia → nyatakan RPO terancang dan tidak terancang secara berasingan.
• Menukar DNS tanpa memagar nod utama lama → penulisan split-brain masih boleh berlaku → pagar dahulu, kemudian naikkan pangkat dan tukar penemuan.
• Mengabaikan slot yang terhenti → WAL yang dikekalkan boleh menghabiskan ruang cakera → sediakan amaran untuk kelengahan, cakera dan umur pengekalan maksimum.
• Hanya menguji kenaikan pangkat pangkalan data → pengguna, pemalam dan kesan hiliran boleh gagal → jalankan latihan main semula dari hujung ke hujung.

Soalan susulan dan jawapan

Adakah failover_ready membuktikan bahawa tiada peristiwa akan hilang?

Tidak. Ia menyatakan bahawa slot logikal yang berkaitan diselaraskan ke standby sasaran dan boleh diteruskan selepas kenaikan pangkat. Kehilangan masih bergantung pada replikasi fizikal pada masa kegagalan, kedudukan perakuan pengguna dan semantik pemprosesan hiliran.

Mengapakah pengguna perlu dijeda semasa pertukaran terancang?

Menjeda menetapkan kedudukan terakhir yang disahkan dan mengelakkan pengguna membaca daripada nod utama lama dan baharu secara serentak. Penyelaras yang lebih canggih boleh digunakan, tetapi ia mesti membuktikan bahawa ia menghalang split-brain, penyusunan semula dan perakuan yang samar-samar.

Bagaimanakah klien CDC bukan PostgreSQL harus mengesahkan kesediaan?

Ia tidak boleh menggunakan semula pertanyaan langganan PostgreSQL secara langsung. Ia harus mengekalkan inventori slot dan pemeriksaan kesihatannya sendiri, mengesahkan slot yang diselaraskan pada standby, dan kemudian mengesahkan sambungan baharu serta kesinambungan kedudukan menggunakan protokol kliennya.

Bagaimana jika slot tidak diselaraskan tetapi operasi perniagaan mesti dipulihkan?

Nyatakan RPO sebenar dan pilih titik pemulihan yang konservatif. Bina semula slot, ambil snapshot baharu atau buat pampasan daripada sandaran jika perlu. Jangan bentangkan keadaan replikasi yang tidak disahkan sebagai pemulihan tanpa kehilangan data.

Bagaimanakah anda menghalang nod utama lama daripada kembali aktif?

Gunakan pemagaran penyelaras atau awan, pengasingan rangkaian dan penggiliran kelayakan penulisan. Perubahan DNS sahaja tidak dapat menghalang nod utama lama daripada menerima penulisan.

Bagaimanakah anda membuktikan bahawa main semula tidak menyebabkan kesan sampingan pendua?

Nyahduplikasi mengikut LSN transaksi, ID peristiwa atau kunci keidempotetan, kemudian rekodkan kiraan main semula, jumlah akhir perniagaan dan kekangan susunan semasa latihan. Bandingkan kedudukan yang boleh diaudit sebelum dan selepas pertukaran.