Temuduga Data: Bagaimanakah PostgreSQL 18 meneruskan replikasi logikal selepas failover?

Gesaan dan kes penggunaan

Nod utama (primary) PostgreSQL 18 menghantar perubahan melalui replikasi logikal ke kluster analitik dan pelanggan luar. Nod utama mungkin mengalami failover ke nod tunggu sedia (standby) fizikal. Reka bentuk slot, tetapan, semakan pelanggan, dan susunan peralihan (cutover) supaya replikasi logikal disambung semula dari kedudukan yang betul tanpa mengelirukan "standby disegerakkan" dengan "pelanggan telah mengejar (caught up)."

Perkara yang diuji oleh penemuduga

Sama ada anda membezakan slot logikal, slot fizikal, pengekalan WAL, dan kedudukan yang disahkan oleh pelanggan.
Sama ada anda memahami bahawa penyegerakan slot failover adalah tak segerak dan mesti dibuktikan sedia sebelum peralihan.
Sama ada anda boleh menggunakan pg_replication_slots, LSN, dan keadaan langganan untuk membuktikan pertukaran yang selamat.
Sama ada anda mengendalikan slot yang tidak sah, pelanggan yang ketinggalan, peralihan terancang, dan kegagalan yang tidak dijangka.

Soalan untuk dijelaskan sebelum menjawab

Adakah pelanggan merupakan PostgreSQL atau sistem luar, dan bolehkah mereka menyambung semula ke nod utama yang baharu?
Adakah RPO yang dibenarkan adalah sifar, jurang LSN yang terhad, atau snapshot langganan yang boleh dibina semula?
Adakah slot replikasi fizikal dan kekangan standby segerak dikonfigurasikan antara nod utama dan standby?
Adakah peralihan dilakukan secara automatik atau manual, dan siapakah yang membekukan penulisan serta mengemas kini penghalaan sambungan?

Rangka kerja jawapan 30 saat

Saya akan mendayakan failover bagi setiap slot logikal yang mesti kekal selepas pertukaran supaya keadaannya disegerakkan ke hot standby. Saya juga akan mengkonfigurasi kekangan penyegerakan fizikal supaya pelanggan tidak dapat melihat kemajuan yang belum dikekalkan oleh standby yang mengambil alih. Sebelum peralihan, sahkan setiap slot yang diperlukan pada standby adalah synced, bukan sementara (non-temporary), dan tidak dibatalkan. Naikkan taraf (promote) standby, kemas kini sambungan, sahkan pelanggan menggunakan data daripada nod utama yang baharu, dan kemudian nyahbekukan penulisan. Jika penyegerakan tak segerak ketinggalan, tangguhkan pertukaran atau terima RPO yang didokumenkan serta kos pembinaan semula.

Panduan mendalam langkah demi langkah

1. Perkara yang disimpan oleh slot replikasi logikal

Slot logikal menyimpan kemajuan penyahkodan dan sempadan pengekalan WAL yang belum disahkan oleh pelanggan. Slot bukanlah isyarat kesihatan untuk pelanggan; pelanggan yang terhenti boleh menyebabkan nod utama mengekalkan WAL dan menggunakan ruang cakera.

2. Mencipta slot failover

PostgreSQL 18 menyokong penetapan failover semasa mencipta slot logikal, dan pilihan yang sepadan semasa mencipta langganan. SQL di bawah adalah sebagai ilustrasi; sahkan argumen dan keistimewaan yang tepat terhadap versi sasaran dan kaedah penggunaan.

sql

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

Bendera failover membolehkan keadaan slot disegerakkan ke standby, tetapi ia tidak membuktikan bahawa penyegerakan telah selesai.

3. Tetapan penyegerakan standby

Standby mesti mendayakan penerimaan dan penggunaan penyegerakan slot logikal, seperti sync_replication_slots. Nod utama boleh menggunakan synchronized_standby_slots untuk memerlukan slot fizikal tertentu mengejar terlebih dahulu, menghalang kemajuan pelanggan logikal daripada mendahului standby yang akan mengambil alih.

4. Mengapa kesediaan tak segerak memerlukan semakan berasingan

Penyegerakan slot menyalin keadaan secara tak segerak. Semasa kegagalan nod utama, standby mungkin mempunyai halaman data tetapi tidak mempunyai kedudukan slot yang terkini. Menaikkan taraf secara serta-merta boleh menyebabkan pelanggan ketiadaan titik permulaannya atau mengakibatkan duplikasi dan jurang data.

5. Menyemak keadaan slot sebelum peralihan

Buat pertanyaan pg_replication_slots pada calon standby. Sahkan setiap slot yang diperlukan telah disegerakkan, bukan sementara, dan tiada sebab pembatalan (invalidation reason), kemudian padankan hasilnya dengan inventori pelanggan.

sql

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

Hanya apabila setiap slot yang diperlukan lulus, barulah standby ditandakan sedia untuk mengambil alih.

6. Semakan tambahan untuk pelanggan PostgreSQL

Bagi pelanggan PostgreSQL, sahkan juga bahawa pelanggan telah menggunakan kedudukan yang serasi dengan slot yang disegerakkan. Lag fizikal dari nod utama ke standby sahaja tidak mencukupi; gabungkan keadaan langganan, LSN terakhir yang diterima, dan lag perniagaan.

7. Menukar pelanggan luar

Sistem luar biasanya tidak dapat mentafsir keadaan slot PostgreSQL secara automatik. Pengatur (orchestrator) peralihan harus membekukan atau menjeda penggunaan data, menaikkan taraf standby, mengemas kini sambungan dan nama slot, kemudian menggunakan peristiwa idempoten dan ofset aplikasi untuk membuktikan tiada data yang terlepas.

8. Laluan kegagalan dan pemulihan

Pertukaran terancang boleh menunggu sehingga semua slot disegerakkan. Kegagalan yang tidak dijangka memerlukan keputusan RPO: menerima jurang, menangguhkan trafik, atau membina semula langganan. Nod utama lama yang telah pulih tidak boleh menyertai semula laluan penulisan secara serta-merta; asingkannya, bina semula replikasi fizikal, dan semak semula keadaan slot serta langganan.

Pertukaran kompromi (trade-offs) dan sempadan

Slot failover meningkatkan kebolehsuaian pemulihan replikasi logikal tetapi menambah kerumitan penyegerakan slot dan pemantauan WAL.
Menunggu penyegerakan slot penuh mengurangkan jurang tetapi boleh memanjangkan masa failover.
synchronized_standby_slots mengekang kemajuan logikal berbanding standby fizikal; ia tidak menyediakan sifar kehilangan menyeluruh (end-to-end zero loss) untuk setiap pelanggan luar.
Slot yang tidak sah, storan yang hampir penuh, dan pelanggan yang lama terhenti memerlukan amaran dan pembersihan, bukan hanya skrip peralihan.

Pelan pelaksanaan dan bukti

Cipta slot logikal failover dalam kluster ujian PostgreSQL 18 dan sahkan tetapan serta keistimewaan nod utama/standby.
Suntik situasi pelanggan terhenti, pengumpulan WAL, slot yang tidak disegerakkan, dan kehilangan nod utama secara tiba-tiba; rekod LSN dan keputusan pemulihan.
Automatikkan pertanyaan pra-peralihan pg_replication_slots dan bandingkan inventori slotnya dengan pelanggan.
Latih tubi jeda, kenaikan taraf, sambung semula, pengejaran data, dan pengunduran (rollback) pada laluan terancang dan kegagalan tidak dijangka.
Semak parameter dan had terhadap dokumentasi PostgreSQL 18 Logical Replication Failover, Logical Decoding, dan Streaming Replication.

Kesilapan biasa dan soalan susulan

Kesilapan 1: Menganggap data standby bermakna pengambilalihan logikal sudah sedia

Keadaan slot disegerakkan secara tak segerak. Halaman data yang telah mengejar tidak membuktikan kedudukan slot boleh digunakan; periksa medan penyegerakan dan pembatalan.

Kesilapan 2: Hanya memantau lag replikasi fizikal

Pantau juga penggunaan pelanggan, LSN slot yang disahkan, WAL yang dikekalkan, dan lag perniagaan. Backlog logikal boleh berkembang sementara replikasi fizikal kelihatan sihat.

Kesilapan 3: Menganggap pilihan failover sebagai pertukaran automatik

Ia mendayakan penyegerakan keadaan slot; ia tidak menaikkan taraf standby, mengemas kini sambungan, atau mengesahkan pelanggan luar. Peralihan masih memerlukan pengaturan (orchestration) dan latihan.

Susulan: Bolehkah anda menaikkan taraf sebelum slot disegerakkan?

Hanya dengan keputusan RPO, jurang, atau pembinaan semula yang eksplisit. Pintu kawalan (gate) lalai harus menunggu penyegerakan dan merekodkan hasilnya.

Susulan: Bagaimanakah anda mengelakkan penggunaan data pendua?

Kekalkan id peristiwa atau sumber LSN, sambung semula dari kedudukan yang boleh disahkan selepas peralihan, dan gunakan pengendalian idempoten serta penyesuaian (reconciliation) untuk memainkan semula (replay).