Pertanyaan dan konteks
Publisher PostgreSQL 18 melayani langganan analitik, konsumen audit, dan pekerjaan backfill sementara. Beberapa konsumen tetap offline, mencegah daur ulang WAL dan menghabiskan ruang disk dengan cepat. Rancang peluncuran (rollout), observabilitas, pembatalan, dan pemulihan untuk idle_replication_slot_timeout.
Hal yang dievaluasi pewawancara
- Apakah Anda menjelaskan mengapa slot menahan WAL dan kapan batas waktu tidak aktif (idle timeout) benar-benar berlaku.
- Apakah Anda membedakan slot logis dan fisik, pemulihan langganan, dan batasan pembangunan ulang (rebuild boundaries).
- Apakah Anda merancang perlindungan penghapusan, peringatan, auditabilitas, dan kontrol tekanan disk.
- Apakah Anda menyediakan jalur snapshot ulang (resnapshot), pembangunan ulang, atau konfirmasi manusia setelah pemulihan konsumen.
Pertanyaan klarifikasi terlebih dahulu
Semantik konsumen
Apa yang dilayani oleh setiap slot? Apakah data saat downtime boleh hilang, atau konsumen harus melanjutkan dari suatu batasan? Apakah slot backfill sementara memiliki masa pakai maksimum yang eksplisit?
Sumber daya dan jendela waktu
Berapa banyak WAL dan disk yang tersisa, dan berapa restart_lsn serta lag konsumen pada masing-masing slot? Seberapa sering checkpoint berjalan? Bisakah langganan atau konsumen dibangun kembali selama jendela pemeliharaan (maintenance window)?
Otoritas perubahan
Siapa yang menyetujui pembatalan otomatis? Apakah konfirmasi konsumen, tiket, atau persetujuan ganda (dual approval) diperlukan terlebih dahulu? Slot mana yang harus dilindungi secara permanen untuk pemulihan bencana (disaster recovery) atau audit kepatuhan?
Jawaban 30 detik
Saya akan menginventarisasi pemilik, tujuan, aktivitas, dan WAL yang ditahan oleh setiap slot, kemudian mengklasifikasikan slot ke dalam kategori kritis, dapat dipulihkan (recoverable), dan sementara. Slot yang dapat dipulihkan mendapatkan idle timeout dengan peringatan dini; slot kritis memicu peringatan tanpa pembatalan otomatis. Karena pembatalan terjadi selama checkpoint, catat status slot, alasan, dan metrik disk dalam jejak audit. Saat pemulihan, pilih lanjutkan (resume), snapshot ulang, atau pemulihan cadangan (backup restore) sesuai dengan kontrak kehilangan data.
Solusi mendalam
1. Jelaskan retensi slot
Slot replikasi membuat publisher menahan WAL yang dibutuhkan oleh konsumen yang belum mengakuinya (acknowledge). Slot logis yang restart_lsn-nya tertinggal akan memperpanjang masa pakai WAL; konsumen yang offline dapat mengubah pertumbuhan normal menjadi risiko yang tidak terbatas. Catat nama slot, database, plugin, konsumen, dan pemilik sebelum menetapkan kebijakan.
2. Klasifikasikan slot
Gunakan kelas kritis, dapat dipulihkan, dan sementara. Slot kritis memerlukan tindakan manusia dan anggaran kapasitas yang lebih besar. Slot yang dapat dipulihkan dapat kedaluwarsa setelah peringatan. Slot sementara menerima waktu kedaluwarsa saat pembuatan. Simpan daftar yang dilindungi di luar konfigurasi yang dikirimkan konsumen sehingga aplikasi tidak dapat menandai slot kritis sebagai slot sekali pakai.
3. Gunakan idle timeout dengan benar
idle_replication_slot_timeout pada PostgreSQL 18 membatalkan slot yang belum digunakan oleh koneksi replikasi lebih lama dari durasi yang dikonfigurasi; nilai nol menonaktifkannya. Pembatalan dipicu saat checkpoint, sehingga waktu sebenarnya dapat melebihi ambang batas. Pengaturan ini berada di tingkat server dan tidak menggantikan klasifikasi bisnis per-slot.
4. Bangun observabilitas dan peringatan
Baca pg_replication_slots secara berkala untuk jenis slot, database, restart_lsn, status aktif, alasan pembatalan, serta status failover atau sinkronisasi. Hitung byte WAL yang ditahan dan usia slot tertua. Berikan peringatan pada tingkat pertumbuhan, sisa ruang disk, durasi idle, dan pembatalan yang akan segera terjadi, termasuk pemilik dan runbook pemulihan.
5. Tangani checkpoint dan race condition
Evaluasi timeout berjalan selama checkpoint, sehingga ambang batas yang dikonfigurasi bukanlah batas waktu yang pasti. Konsumen mungkin terhubung kembali mendekati ambang batas; catat waktu penggunaan terakhir, waktu checkpoint, dan alasan pembatalan akhir. Sebelum mengubah kebijakan atau menghapus slot, periksa pembuatan dengan nama yang sama, sinkronisasi standby, atau pemulihan langganan yang sedang berlangsung.
6. Rancang pemulihan
Setelah pembatalan, konsumen tidak dapat menganggap batasan lamanya masih tersedia. Jika kehilangan data selama downtime dapat diterima, buat slot baru dan ambil snapshot awal. Jika kehilangan data tidak dapat diterima, pulihkan dari cadangan atau WAL yang ditahan dan bangun kembali langganan. Catat slot lama, batasan data, waktu snapshot, dan bukti validasi.
7. Hubungkan kapasitas dan kontrol perubahan
Ketika direktori WAL mendekati batasnya, jeda backfill berprioritas rendah, batasi pekerjaan batch yang menghasilkan WAL, dan lindungi ketersediaan primary; jangan menghapus slot yang tidak dikenal. Luncurkan perubahan batas waktu secara bertahap, amati pertumbuhan WAL, checkpoint, lag replikasi, dan kesalahan konsumen, lalu sesuaikan kebijakannya.
Contoh jawaban yang kuat
Saya akan mengelola katalog slot beserta pemiliknya dan mengklasifikasikan slot sebagai kritis, dapat dipulihkan, atau sementara. Slot yang dapat dipulihkan dan sementara mendapatkan idle timeout; slot kritis hanya memicu peringatan. Karena pembatalan terjadi selama checkpoint, pemantauan mencatat waktu checkpoint dan alasan sebenarnya. Laporan harian menghitung WAL yang ditahan, durasi idle, dan risiko disk; ambang batas menjeda backfill dan memberi tahu pemilik. Setelah pembatalan, jalur pemulihan memilih snapshot ulang, pemulihan cadangan, atau pembangunan ulang yang disetujui sesuai dengan kontrak kehilangan data, dengan setiap tindakan diaudit.
Kesalahan umum
- Menganggap slot dibatalkan tepat saat batas waktu berakhir dan mengabaikan checkpoint.
- Menerapkan timeout singkat ke setiap slot dan menghapus slot pemulihan bencana atau audit.
- Hanya memantau
activealih-alih menghitung WAL yang ditahan darirestart_lsn. - Menghubungkan kembali konsumen tanpa memutuskan apakah batasan data atau snapshot telah hilang.
- Menghapus slot yang tidak dikenal selama insiden disk dan memutus jalur replikasi yang aktif.
- Tidak memiliki pemilik, daftar yang dilindungi, atau runbook pemulihan yang dapat dieksekusi.
Pertanyaan lanjutan dan jawaban
Kapan idle_replication_slot_timeout mulai berlaku?
Setelah slot tidak digunakan oleh koneksi replikasi lebih lama dari pengaturan, pembatalan dipicu selama checkpoint berikutnya, sehingga mungkin tertunda.
Haruskah slot fisik kedaluwarsa secara otomatis juga?
Itu tergantung pada kontrak pemulihan bencana. Slot fisik mungkin diperlukan oleh standby; konfirmasikan mekanisme perlindungan lain sebelum mengizinkan pembatalan otomatis.
Bagaimana Anda menghitung WAL yang ditahan oleh satu slot?
Bandingkan posisi WAL saat ini dengan restart_lsn milik slot, kemudian kumpulkan posisi tertua, tingkat pertumbuhan, dan sisa ruang disk per slot. active saja tidak menggambarkan risiko ruang.
Bisakah konsumen melanjutkan setelah kembali online?
Hanya jika WAL yang diperlukan masih ada dan slot tetap valid. Setelah pembatalan atau penghapusan WAL, diperlukan snapshot ulang, pemulihan cadangan, atau celah data (data gap) yang eksplisit.
Bagaimana Anda mencegah kebocoran slot backfill sementara?
Catat masa kedaluwarsa dan pemilik saat pembuatan, beri peringatan secara terpisah, pindahkan ke status konfirmasi sebelum pembatalan, dan verifikasi bahwa daur ulang WAL pulih setelahnya.