Soalan dan konteks
Penerbit PostgreSQL 18 menyediakan langganan analitik, pengguna audit, dan tugas backfill sementara. Sesetengah pengguna kekal luar talian, menghalang kitar semula WAL dan menggunakan cakera dengan pantas. Reka bentuk pelancaran (rollout), kebolehcerapan, pembatalan, dan pemulihan untuk idle_replication_slot_timeout.
Perkara yang dinilai oleh penemu duga
- Sama ada anda menerangkan mengapa slot mengekalkan WAL dan bila had masa melahu (idle timeout) benar-benar berkuat kuasa.
- Sama ada anda membezakan slot logikal dan fizikal, pemulihan langganan, dan sempadan binaan semula (rebuild boundaries).
- Sama ada anda mereka bentuk perlindungan pemadaman, amaran, kebolehauditan, dan kawalan tekanan cakera.
- Sama ada anda menyediakan laluan tangkap gambar semula (resnapshot), binaan semula, atau pengesahan manusia selepas pemulihan pengguna.
Soalan penjelasan terlebih dahulu
Semantik pengguna
Apakah yang disediakan oleh setiap slot? Bolehkah data semasa masa henti (downtime) hilang, atau adakah pengguna mesti menyambung semula dari sempadan tertentu? Adakah slot backfill sementara mempunyai jangka hayat maksimum yang jelas?
Sumber dan tetingkap masa
Berapakah baki WAL dan cakera, dan apakah restart_lsn serta kelengahan (lag) pengguna bagi setiap slot? Berapa kerap checkpoint dijalankan? Bolehkah langganan atau pengguna dibina semula semasa tetingkap penyelenggaraan?
Kuasa perubahan
Siapakah yang meluluskan pembatalan automatik? Adakah pengesahan pengguna, tiket, atau kelulusan dwi-pihak diperlukan terlebih dahulu? Slot manakah yang mesti dilindungi secara kekal untuk pemulihan bencana (disaster recovery) atau audit pematuhan?
Jawapan 30 saat
Saya akan menginventori pemilik, tujuan, aktiviti, dan WAL yang dikekalkan bagi setiap slot, kemudian mengklasifikasikan slot kepada kritikal, boleh dipulihkan, dan sementara. Slot yang boleh dipulihkan menerima had masa melahu dengan amaran awal; slot kritikal memberi amaran tanpa pembatalan automatik. Memandangkan pembatalan berlaku semasa checkpoint, rekodkan keadaan slot, sebab, dan metrik cakera dalam jejak audit. Semasa pemulihan, pilih sambung semula, tangkap gambar semula, atau pemulihan sandaran (backup restore) mengikut kontrak kehilangan data.
Penyelesaian mendalam
1. Terangkan pengekalan slot
Slot replikasi menyebabkan penerbit mengekalkan WAL yang diperlukan oleh pengguna yang belum memperakuinya (acknowledge). Slot logikal yang restart_lsn-nya ketinggalan akan memanjangkan jangka hayat WAL; pengguna luar talian boleh mengubah pertumbuhan normal menjadi risiko tanpa batas. Rekodkan nama slot, pangkalan data, pemalam, pengguna, dan pemilik sebelum menetapkan dasar.
2. Klasifikasikan slot
Gunakan kelas kritikal, boleh dipulihkan, dan sementara. Slot kritikal memerlukan tindakan manusia dan belanjawan kapasiti yang lebih besar. Slot yang boleh dipulihkan mungkin tamat tempoh selepas amaran. Slot sementara menerima masa tamat tempoh semasa penciptaan. Simpan senarai yang dilindungi di luar konfigurasi yang dihantar oleh pengguna supaya aplikasi tidak boleh menandakan slot kritikal sebagai boleh dibuang.
3. Gunakan had masa melahu dengan betul
idle_replication_slot_timeout PostgreSQL 18 membatalkan slot yang tidak digunakan oleh sambungan replikasi lebih lama daripada tempoh yang dikonfigurasikan; sifar menyahdayakannya. Pembatalan dicetuskan semasa checkpoint, jadi masa sebenar boleh melebihi ambang. Tetapan ini adalah pada peringkat pelayan dan tidak menggantikan klasifikasi perniagaan bagi setiap slot.
4. Bina kebolehcerapan dan amaran
Baca pg_replication_slots secara kerap untuk jenis slot, pangkalan data, restart_lsn, keadaan aktif, sebab pembatalan, dan keadaan failover atau disegerakkan. Kira bait WAL yang dikekalkan dan usia slot tertua. Berikan amaran tentang kadar pertumbuhan, ruang simpanan cakera (headroom), tempoh melahu, dan pembatalan yang bakal berlaku, termasuk pemilik dan runbook pemulihan.
5. Kendalikan checkpoint dan keadaan perlumbaan (race conditions)
Penilaian had masa dijalankan semasa checkpoint, jadi ambang yang dikonfigurasikan bukanlah tarikh akhir yang tepat. Pengguna mungkin menyambung semula berhampiran ambang; rekodkan masa penggunaan terakhir, masa checkpoint, dan sebab pembatalan muktamad. Sebelum menukar dasar atau memadamkan slot, periksa penciptaan nama yang sama, penyegerakan standby, atau pemulihan langganan yang sedang berjalan.
6. Reka bentuk pemulihan
Selepas pembatalan, pengguna tidak boleh menganggap sempadan lamanya masih tersedia. Jika kehilangan semasa masa henti boleh diterima, buat slot baharu dan ambil tangkapan gambar awal. Jika kehilangan tidak boleh diterima, pulihkan daripada sandaran atau WAL yang dikekalkan dan bina semula langganan. Rekodkan slot lama, sempadan data, masa tangkapan gambar, dan bukti pengesahan.
7. Hubungkan kapasiti dan kawalan perubahan
Apabila direktori WAL menghampiri hadnya, jeda backfill berkeutamaan rendah, hadkan kerja kelompok yang menghasilkan WAL, dan lindungi ketersediaan utama (primary); jangan padamkan slot yang tidak diketahui. Lancarkan perubahan had masa secara berperingkat, perhatikan pertumbuhan WAL, checkpoint, kelengahan replikasi, dan ralat pengguna, kemudian laraskan dasar.
Contoh jawapan yang kukuh
Saya akan mengekalkan katalog slot dengan pemilik dan mengklasifikasikan slot sebagai kritikal, boleh dipulihkan, atau sementara. Slot yang boleh dipulihkan dan sementara mendapat had masa melahu; slot kritikal hanya memberi amaran. Memandangkan pembatalan berlaku semasa checkpoint, pemantauan merekodkan masa checkpoint dan sebab sebenar. Laporan harian mengira WAL yang dikekalkan, tempoh melahu, dan risiko cakera; ambang menjeda backfill dan memberitahu pemilik. Selepas pembatalan, laluan pemulihan memilih tangkap gambar semula, pemulihan sandaran, atau binaan semula yang diluluskan mengikut kontrak kehilangan data, dengan setiap tindakan diaudit.
Kesilapan biasa
- Menganggap slot terbatal tepat pada masa had masa tamat dan mengabaikan checkpoint.
- Mengenakan had masa yang pendek pada setiap slot dan memadamkan slot pemulihan bencana atau audit.
- Hanya memantau
activedan bukannya mengira WAL yang dikekalkan daripadarestart_lsn. - Menyambung semula pengguna tanpa memutuskan sama ada data atau sempadan tangkapan gambar telah hilang.
- Memadamkan slot yang tidak diketahui semasa insiden cakera dan memutuskan laluan replikasi yang aktif.
- Tidak mempunyai pemilik, senarai yang dilindungi, atau runbook pemulihan yang boleh dilaksanakan.
Soalan susulan dan jawapan
Bilakah idle_replication_slot_timeout berkuat kuasa?
Selepas slot tidak digunakan oleh sambungan replikasi lebih lama daripada tetapan, pembatalan dicetuskan semasa checkpoint seterusnya, jadi ia mungkin tertangguh.
Patutkah slot fizikal tamat tempoh secara automatik juga?
Itu bergantung pada kontrak pemulihan bencana. Slot fizikal mungkin diperlukan oleh standby; sahkan mekanisme perlindungan lain sebelum membenarkan pembatalan automatik.
Bagaimanakah anda mengira WAL yang dikekalkan oleh satu slot?
Bandingkan kedudukan WAL semasa dengan restart_lsn slot tersebut, kemudian agregatkan kedudukan tertua, kadar pertumbuhan, dan ruang simpanan cakera bagi setiap slot. active sahaja tidak menggambarkan risiko ruang.
Bolehkah pengguna menyambung semula selepas kembali dalam talian?
Hanya jika WAL yang diperlukan masih wujud dan slot kekal sah. Selepas pembatalan atau penyingkiran WAL, tangkapan gambar semula, pemulihan sandaran, atau jurang data yang jelas diperlukan.
Bagaimanakah anda menghalang kebocoran slot backfill sementara?
Rekodkan tamat tempoh dan pemilik semasa penciptaan, beri amaran secara berasingan, beralih kepada keadaan pengesahan sebelum pembatalan, dan sahkan bahawa kitar semula WAL pulih selepas itu.