Salah satu fitur menarik di PostgreSQL sejak versi 9.4 adalah kemampuan untuk mengontrol penghapusan file WAL menggunakan slot replikasi. Sisi gelapnya adalah bahwa slot replikasi dapat menyebabkan disk terisi dengan WAL lama, mematikan server produksi utama. Dalam artikel ini saya menjelaskan slot replikasi PostgreSQL, dan bagaimana fitur baru di PostgreSQL 13 membantu mencegah masalah ini.

Produksi WAL

Seperti yang Anda ketahui, WAL diproduksi untuk perubahan basis data di server utama:penyisipan, pembaruan, dan lain-lain . Basis data yang lebih aktif akan menghasilkan lebih banyak WAL — di server yang sangat aktif, bisa ada banyak gigabyte WAL yang dihasilkan setiap menitnya. WAL ditulis ke file dengan nama dalam urutan numerik yang meningkat, dan file selalu berukuran sama (16 MB default dan tipikal). Setelah data dalam file tidak lagi diperlukan, file tersebut dapat didaur ulang , yang artinya mengganti namanya ke posisi yang bernomor lebih tinggi dalam urutan agar nantinya bisa diisi dengan data baru.

(Ada situasi khusus seperti lonjakan aktivitas yang mengarah pada pembuatan file tambahan; ketika lonjakan tersebut kemudian mereda, file tambahan tersebut akan dihapus alih-alih didaur ulang.)

Karena semua aktivitas penulisan basis data menghasilkan WAL, ruang disk harus tersedia. Ketika disk yang menyimpan WAL penuh, server tidak akan dapat memproses transaksi baru dan dapat macet, atau lebih buruk:mungkin jatuh sepenuhnya. Jadi ini adalah situasi yang harus dihindari dengan segala cara.

Slot Replikasi

Replikasi di PostgreSQL bekerja dengan memproses file WAL. Agar ini berfungsi, semua file WAL harus tersedia untuk sementara hingga diproses. Oleh karena itu diperlukan suatu mekanisme untuk memberitahu manajemen WAL utama untuk tidak mendaur ulang atau menghapus file.

Masukkan slot replikasi. Slot adalah mekanisme yang menunjukkan bahwa ini cadangan yang kami ambil akan membutuhkan itu file WAL, dan bisakah Anda tidak menghapusnya dulu; atau ini replika masih belum memproses itu File WAL, jadi bisakah dibiarkan sebentar.

Dengan sendirinya, slot replikasi menempati ruang disk yang sangat sedikit. Mereka hanya menyimpan sedikit metadata, termasuk penunjuk ke posisi di WAL. Tetapi data WAL yang dilindunginya adalah masalah lain:di server yang sangat aktif, data tersebut dapat diukur dalam gigabyte atau lebih buruk.

Konsumsi WAL

Memberi makan data ke replika fisik berarti menyalin data WAL dari server utamanya. Demikian pula, replika logis perlu membaca data WAL (dan mengirimkan versi yang ditafsirkan ke replika). Posisi WAL yang sedang dibaca adalah apa yang dilacak oleh slot. Setelah replika mengamankan data WAL, slot dapat dimajukan; ini memberitahu manajemen WAL di primer bahwa file WAL kemudian tersedia untuk dihapus. Hal ini terjadi terus menerus saat replika aktif, sehingga WAL di server utama akan menggunakan jumlah ruang disk yang sama atau mungkin hanya sedikit lebih banyak. Bahkan dua kali lipat atau sepuluh kali lipat mungkin bisa diterima, tergantung kondisi.

Masalahnya adalah jika replika mati total dan tidak pulih untuk waktu yang lama; atau replika dihancurkan dan DBA lupa menghapus slot replikasi; atau slot adalah sisa eksperimen yang terlupakan; atau bahkan replika dimasukkan melalui tautan jaringan yang lambat, maka WAL yang dicadangkan akan tumbuh tanpa batas. Dan itu menjadi bom waktu.

Membatasi Ukuran Slot

Untuk mengatasi masalah ini, Kyotaro Horiguchi telah bekerja sejak Februari 2017 di patch PostgreSQL untuk membatasi ukuran WAL yang dicadangkan oleh sebuah slot. Setelah proses peninjauan dan pengerjaan ulang yang sangat panjang, saya mengintegrasikannya untuk PostgreSQL 13, meningkatkan pengelolaan farm PostgreSQL dengan ketersediaan tinggi.

Prinsip utamanya adalah lebih baik membunuh replika (dengan cara membuat slotnya tidak valid; lebih lanjut tentang itu di bawah) daripada mematikan server utama yang memberi makan replika itu dan menghentikan semua produksi bersamanya.

Cara kerjanya cukup mudah:atur max_slot_wal_keep_size (dokumentasi) di postgresql.conf ke jumlah maksimum ruang disk WAL yang diizinkan untuk dicadangkan oleh slot replikasi. Jika slot mencapai titik tersebut dan terjadi checkpoint, slot tersebut akan ditandai tidak valid dan beberapa file WAL dapat dihapus. Jika slot digunakan secara aktif oleh walsender proses, proses itu akan diberi sinyal sehingga berhenti. Jika walsender dimulai lagi, file WAL yang diperlukan tidak akan ada lagi. Replika yang menggunakan slot itu harus dikloning ulang.

Jika max_slot_wal_keep_size adalah nol, yang merupakan nilai default, maka tidak ada batasan. Saya tidak menyarankan ini, karena ini menyebabkan kegagalan ketika slot mengisi disk.

Memantau Kesehatan Slot

Juga termasuk beberapa fitur pemantauan. Dua kolom di pg_replication_slots relevan. Yang paling kritis adalah wal_status . Jika kolom itu reserved , lalu slot menunjuk ke data di dalam max_wal_size; jika extended maka melebihi max_wal_size , tetapi masih dilindungi oleh wal_keep_size atau max_slot_wal_keep_size (termasuk saat max_slot_wal_keep_size adalah nol). Kedua negara itu baik dan normal. Namun, saat slot melebihi batas, slot tersebut akan menjadi unreserved , yang berarti dalam bahaya, tetapi masih dapat pulih jika cukup cepat. Akhirnya statusnya menjadi lost ketika file WAL telah dihapus dan pemulihan tidak dapat dilakukan.

Kolom lainnya adalah safe_wal_size :ini menunjukkan jumlah byte WAL yang dapat ditulis sebelum slot ini terancam dihapusnya file WAL. Kami menyarankan untuk terus mengawasi kolom ini di sistem pemantauan Anda, dan aktifkan peringatan saat hampir habis. Nol atau negatif berarti replika Anda akan mati segera setelah pos pemeriksaan terjadi:

SELECT slot_name, active, wal_status, safe_wal_size
  FROM pg_catalog.pg_replication_slots;

Kami percaya bahwa fitur baru ini membuat pemeliharaan replika lebih mudah dan lebih kuat; semoga kita tidak akan melihat bencana lagi dengan produksi turun karena masalah ini.

(Catatan:safe_wal_size diperkenalkan di 13beta3, jadi pastikan untuk membaca dokumentasi terbaru, atau Anda akan melihat min_safe_lsn sebagai gantinya. Abaikan itu.)

Terima kasih

Terima kasih khusus kepada Kyotaro Horiguchi karena telah berupaya memecahkan masalah ini. Beberapa pengulas mendalami hal ini, di antaranya saya ingin mengucapkan terima kasih terutama Masahiko Sawada, Fujii Masao, Jehan-Guillaume de Rorthais, dan Amit Kapila (tanpa urutan tertentu).