Bagi Pentadbir Pangkalan Data (DBA) dan jurutera DevOps yang menguruskan PostgreSQL dalam persekitaran pengeluaran (production), mencapai Objektif Titik Pemulihan (RPO) yang hampir sifar adalah mandat utama. Teras kepada keupayaan pemulihan bencana dan Pemulihan Titik-dalam-Masa (PITR) PostgreSQL ialah Write-Ahead Logging (WAL). Walaupun WAL memastikan pematuhan ACID dengan merekodkan transaksi sebelum ia ditulis ke dalam fail data, pengarkiban WAL adalah mekanisme yang memelihara log ini untuk sandaran jangka panjang dan replikasi.
Walau bagaimanapun, mengkonfigurasi pengarkiban WAL bukanlah operasi “tetapkan dan lupakan”. Salah konfigurasi, kegagalan senyap, dan salah faham seni bina boleh membawa kepada kehilangan data yang dahsyat, senario “split-brain”, atau gangguan pangkalan data sepenuhnya.
Dalam panduan komprehensif ini, kami akan meneroka seni bina pengarkiban WAL PostgreSQL, mengenal pasti perangkap paling biasa yang membawa kepada kehilangan data, dan menggariskan amalan terbaik gred pengeluaran untuk memastikan pangkalan data anda kekal berdaya tahan.
Memahami Seni Bina WAL PostgreSQL
Sebelum mendalami perangkap yang ada, adalah penting untuk memahami cara PostgreSQL mengendalikan log transaksi.
PostgreSQL menulis semua pengubahsuaian ke segmen WAL (lalai kepada fail 16MB) yang terletak dalam direktori pg_wal (dahulunya pg_xlog dalam versi sebelum 10). Setiap transaksi direkodkan secara berurutan, ditandakan dengan Nombor Urutan Log (LSN).
Apabila segmen WAL penuh, PostgreSQL bertukar kepada segmen baharu. Untuk mengelakkan direktori pg_wal daripada berkembang tanpa had, PostgreSQL mengitar semula atau membuang segmen WAL lama sebaik sahaja ia tidak lagi diperlukan untuk pemulihan nahas atau replikasi.
Pengarkiban WAL memintas proses kitar semula ini. Apabila archive_mode didayakan, PostgreSQL melaksanakan archive_command yang ditentukan pengguna (atau menggunakan archive_library dalam PostgreSQL 15+) untuk menyalin segmen WAL yang lengkap ke lokasi sekunder yang selamat sebelum ia dipadam atau ditimpa.
Untuk melakukan Pemulihan Titik-dalam-Masa (PITR), anda memerlukan dua komponen:
1. Sandaran asas (base backup) yang sah.
2. Rantaian fail WAL yang diarkibkan tanpa putus dari masa sandaran asas sehingga masa pemulihan sasaran anda.
Jika rantaian WAL itu terputus, PITR anda akan gagal.
Mengkonfigurasi Pengarkiban WAL untuk Pengeluaran
Untuk mendayakan pengarkiban WAL, anda mesti mengubah suai fail postgresql.conf anda. Konfigurasi asas memerlukan penetapan wal_level, mendayakan archive_mode, dan mentakrifkan archive_command.
# postgresql.conf
wal_level = replica # 'replica' atau 'logical' diperlukan untuk pengarkiban
archive_mode = on # Mendayakan proses pengarkib
archive_command = 'test ! -f /mnt/nfs/archive/%f && cp %p /mnt/nfs/archive/%f'
archive_timeout = 600 # Paksa pertukaran WAL setiap 10 minit
Dalam archive_command:
* %p mewakili laluan penuh ke fail WAL untuk diarkibkan.
* %f mewakili nama fail bagi fail WAL tersebut.
Walaupun konfigurasi di atas kelihatan mudah, bergantung pada arahan shell yang ringkas dalam persekitaran perusahaan membawa risiko yang ketara.
Perangkap Biasa dalam Pengarkiban WAL
Perangkap 1: “Kejayaan Senyap” bagi archive_command
PostgreSQL bergantung sepenuhnya pada kod keluar (exit code) bagi archive_command. Jika arahan mengembalikan 0, PostgreSQL menganggap fail WAL telah diarkibkan dengan selamat dan meneruskan proses kitar semula fail asal.
Kesilapan biasa ialah menggunakan arahan yang mengembalikan 0 walaupun data tidak disalurkan (flushed) dengan selamat ke storan kekal. Sebagai contoh, arahan cp yang ringkas mungkin mengembalikan kejayaan sebaik sahaja data sampai ke cache halaman OS pada pelayan destinasi. Jika pelayan destinasi kehilangan kuasa sebelum cache disalurkan ke cakera, fail WAL akan hilang, tetapi PostgreSQL telah pun memadam salinan tempatannya.
Risiko: Rantaian WAL yang terputus dan ketidakupayaan untuk melakukan PITR, yang hanya ditemui semasa senario pemulihan bencana.
Mitigasi: Pastikan skrip pengarkiban anda menguatkuasakan penulisan segerak (synchronous writes). Jika menggunakan arahan shell standard, gunakan alat yang menjamin data disalurkan, atau tulis skrip pembungkus yang mengesahkan saiz fail dan checksum selepas pemindahan.
Perangkap 2: Kehabisan Partisi pg_wal (WAL Bloat)
Jika archive_command gagal (mengembalikan kod keluar bukan sifar)—disebabkan gangguan rangkaian, kebenaran yang salah, atau cakera destinasi penuh—PostgreSQL akan mengekalkan fail WAL dalam direktori pg_wal dan mencuba semula arahan tersebut selama-lamanya.
Walaupun ini menghalang kehilangan data dengan tidak memadam WAL yang belum diarkibkan, ia memperkenalkan risiko ketersediaan yang serius. Jika direktori pg_wal berada pada partisi yang penuh sehingga 100%, PostgreSQL akan mengeluarkan PANIC dan ranap. Pangkalan data tidak akan bermula semula sehingga ruang dikosongkan.
Risiko: Masa henti pangkalan data sepenuhnya disebabkan oleh partisi pg_wal yang penuh.
Mitigasi:
1. Sentiasa letakkan pg_wal pada partisi cakera khusus.
2. Laksanakan pemantauan agresif pada saiz direktori pg_wal.
3. Pantau paparan pg_stat_archiver untuk mengesan arahan arkib yang gagal dengan serta-merta.
Perangkap 3: Sandaran Asas Tidak Lengkap
Sandaran asas tidak berguna tanpa fail WAL yang dijana semasa proses sandaran. Jika anda mengambil syot kilat (snapshot) peringkat sistem fail atau menggunakan pg_basebackup tanpa menstrim WAL (-X stream), anda mesti memastikan bahawa fail WAL yang dijana antara permulaan dan akhir sandaran telah berjaya diarkibkan.
Jika pengarkib anda ketinggalan atau gagal, dan fail WAL khusus tersebut hilang, sandaran asas tidak boleh dibawa ke keadaan yang konsisten.
Risiko: Sandaran asas yang rosak atau tidak boleh dipulihkan.
Mitigasi: Gunakan pg_basebackup -X stream untuk menyertakan fail WAL yang diperlukan dalam muatan sandaran itu sendiri, atau gunakan penyelesaian sandaran perusahaan yang menguruskan kebergantungan antara sandaran asas dan segmen WAL secara automatik.
Perangkap 4: Kekeliruan Garis Masa dan Senario “Split-Brain”
Apabila pelayan sedia (standby) dinaik taraf kepada pelayan utama (primary), PostgreSQL menambah “ID Garis Masa” (bahagian pertama nama fail WAL, contohnya 0000000200000001000000A4). Ini menghalang pelayan utama baharu daripada menimpa sejarah WAL pelayan utama lama.
Walau bagaimanapun, jika pelayan utama lama dimulakan secara tidak sengaja tanpa dipagar dengan betul (senario split-brain), ia mungkin cuba menolak fail WAL ke lokasi arkib yang sama menggunakan garis masa lama. Jika archive_command anda menimpa fail secara membuta tuli, anda boleh merosakkan repositori arkib anda.
Risiko: Fail WAL yang tertimpa, arkib yang rosak, dan pangkalan data yang tidak boleh dipulihkan.
Mitigasi: archive_command anda tidak boleh sekali-kali menimpa fail sedia ada. Perhatikan dalam konfigurasi asas tadi, kami menggunakan test ! -f /mnt/nfs/archive/%f untuk gagal secara eksplisit jika fail sudah wujud.
Mengurangkan Risiko Kehilangan Data: Amalan Terbaik Pengeluaran
Untuk mengukuhkan strategi pengarkiban PostgreSQL anda, laksanakan amalan terbaik berikut.
1. Pantau Proses Pengarkib Secara Asli
PostgreSQL menyediakan paparan terbina dalam, pg_stat_archiver, yang menjejaki kejayaan dan kegagalan proses pengarkiban anda. Anda harus menyepadukan paparan ini ke dalam timbunan pemerhatian anda (contohnya, Prometheus, Datadog, atau Zabbix).
SELECT
archived_count,
last_archived_wal,
last_archived_time,
failed_count,
last_failed_wal,
last_failed_time,
stats_reset
FROM pg_stat_archiver;
Ambang amaran untuk dikonfigurasikan:
* Beri amaran jika failed_count meningkat.
* Beri amaran jika perbezaan masa antara now() dan last_archived_time melebihi ambang RPO anda (contohnya, 15 minit), dengan mengambil kira bahawa pangkalan data trafik rendah mungkin mempunyai kelewatan secara semula jadi melainkan archive_timeout ditetapkan.
2. Manfaatkan archive_timeout
Dalam pangkalan data dengan volum penulisan yang rendah, fail WAL 16MB mungkin mengambil masa berjam-jam untuk penuh. Sehingga ia penuh, ia tidak akan diarkibkan. Jika pelayan ranap dan cakera tempatan hilang, anda kehilangan transaksi selama berjam-jam.
Menetapkan archive_timeout = 600 (10 minit) memaksa PostgreSQL bertukar kepada fail WAL baharu dan mengarkibkan fail semasa, walaupun ia tidak penuh. Ini menjamin bahawa RPO anda tidak melebihi 10 minit, dengan kos penggunaan storan yang sedikit lebih tinggi disebabkan oleh fail WAL yang separa penuh.
3. Peralihan kepada archive_library (PostgreSQL 15+)
Secara sejarah, archive_command menjana proses shell baharu untuk setiap fail WAL. Dalam persekitaran throughput tinggi yang menjana ratusan fail WAL seminit, beban kerja untuk melakukan “forking” proses shell menjadi kesesakan prestasi.
PostgreSQL 15 memperkenalkan parameter archive_library, yang membolehkan pengarkiban WAL dikendalikan oleh modul C yang dimuatkan secara dinamik. Ini menghapuskan beban kerja shell-forking dan menyediakan mekanisme pengarkiban berprestasi tinggi yang jauh lebih mantap. Jika anda menggunakan PostgreSQL 15 atau lebih tinggi, cari alat sandaran yang menyokong modul arkib tersuai.
4. Uji Pemulihan Titik-dalam-Masa Secara Berkala
Sandaran yang tidak diuji bukanlah sandaran; ia hanyalah harapan. Satu-satunya cara untuk mengesahkan bahawa pengarkiban WAL anda berfungsi dengan betul, rantaian WAL anda tidak terputus, dan sandaran asas anda konsisten, adalah dengan melakukan ujian PITR automatik secara rutin.
Jalankan tika (instance) sementara, pulihkan sandaran asas, konfigurasikan restore_command untuk menarik dari arkib anda, dan pulihkan ke cap masa tertentu. Sahkan bahawa pangkalan data mencapai keadaan yang konsisten dan dibuka untuk sambungan.
Sandaran dan Pemulihan Perusahaan dengan CloudSave
Menguruskan skrip shell tersuai untuk archive_command, mengendalikan penyahduplikasian WAL, dan memastikan storan luar tapak yang selamat untuk log transaksi boleh menjadi beban operasi yang berat bagi pasukan IT.
Di sinilah CloudSave memberikan nilai yang signifikan untuk persekitaran PostgreSQL perusahaan. CloudSave disepadukan secara terus dengan API sandaran dan pengarkiban WAL asli PostgreSQL untuk menghapuskan perangkap manual yang dibincangkan di atas.
Daripada menulis skrip bash yang rapuh, CloudSave menyediakan penyepaduan berasaskan ejen atau tanpa ejen yang mantap yang:
* Menjamin Penghantaran: Menggantikan arahan shell standard dengan pemindahan yang disahkan dan divalidasi checksum ke storan luar tapak atau awan yang selamat.
* Menghalang WAL Bloat: Memantau direktori pg_wal secara aktif dan memberi amaran kepada pentadbir jauh sebelum kehabisan partisi berlaku.
* Mengautomasikan PITR: Memudahkan Pemulihan Titik-dalam-Masa melalui antara muka yang intuitif. Anda memilih minit tepat yang anda ingin pulihkan, dan CloudSave secara automatik mendapatkan semula sandaran asas yang betul dan menstrim urutan fail WAL yang tepat yang diperlukan untuk mencapai keadaan tersebut.
* Mengendalikan Garis Masa: Menguruskan sejarah garis masa PostgreSQL dengan bijak, memastikan bahawa failover dan senario split-brain tidak merosakkan repositori sandaran anda.
Dengan memindahkan beban kerja pengurusan WAL kepada CloudSave, DBA boleh memberi tumpuan kepada pengoptimuman pertanyaan dan prestasi pangkalan data, dengan mengetahui bahawa SLA RPO dan RTO mereka dilindungi oleh platform gred perusahaan.
Kesimpulan
Pengarkiban WAL PostgreSQL adalah tulang belakang kepada pemulihan bencana pangkalan data. Walaupun konsep menyalin fail dari satu direktori ke direktori lain kelihatan mudah, kes-kes pinggiran—kegagalan senyap, kehabisan cakera, dan perbezaan garis masa—menimbulkan risiko serius kepada integriti data.
Dengan memahami seni bina pg_wal, mengelakkan konfigurasi archive_command yang merosakkan secara ketat, memantau pg_stat_archiver, dan memanfaatkan platform sandaran perusahaan seperti CloudSave, anda boleh membina infrastruktur PostgreSQL yang berdaya tahan yang mampu bertahan daripada kegagalan perkakasan, kesilapan manusia, dan gangguan bencana tanpa kehilangan satu pun transaksi yang telah disahkan.
Temui perangkap biasa pengarkiban WAL PostgreSQL yang membawa kepada kehilangan data. Pelajari amalan terbaik DBA pakar, petua konfigurasi, dan cara memastikan Pemulihan Titik-dalam-Masa (PITR) yang boleh dipercayai untuk pangkalan data perusahaan.
