Selama jam sibuk, sejumlah besar log WAL dihasilkan di PostgreSQL. WAL adalah singkatan dari Write-Ahead Logging. Proses checkpointer menghapus log WAL yang kedaluwarsa pada interval tertentu. Namun, dalam lingkungan produksi, log WAL mungkin gagal dihapus karena operasi yang tidak tepat. Dalam hal ini, sejumlah besar penyimpanan terpakai. Topik ini menjelaskan cara memecahkan masalah akumulasi log WAL di database utama atau database baca-saja.
Informasi latar belakang
WAL adalah komponen kunci PostgreSQL untuk memastikan keamanan data dan meningkatkan keandalan serta kinerja sistem. WAL membantu mencegah kehilangan data dan memastikan bahwa data dapat dipulihkan dengan cara yang andal bahkan jika beberapa titik kegagalan terjadi.
Akumulasi log di database utama
Jika log WAL terakumulasi di database utama, Anda dapat mengidentifikasi dan memecahkan masalah tersebut dari aspek-aspek berikut.
Slot replikasi tidak aktif atau LSN tidak dilaporkan oleh konsumen
Slot replikasi adalah alat kunci di PostgreSQL untuk menerapkan ketersediaan tinggi dan pemulihan bencana. Anda dapat menggunakan slot replikasi untuk mencegah log WAL dihapus dan mencegah gangguan replikasi. Namun, jika slot replikasi tidak aktif, log WAL yang terkait dengan slot tersebut tidak dihapus dan terus menumpuk.
Jika LSN tidak dilaporkan oleh konsumen secara tepat waktu, ukuran log WAL terus bertambah.
Anda dapat menggunakan tampilan sistem pg_replication_slots untuk melihat informasi tentang slot replikasi, seperti LSN. Sebagai contoh, Anda dapat menggunakan pernyataan SQL berikut untuk menanyakan ukuran log WAL yang terakumulasi untuk sebuah slot replikasi. Akumulasi menyebabkan latensi replikasi antara database utama dan sekunder. Dalam hal ini, log WAL yang terakumulasi harus dihapus.
SELECT slot_name, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_insert_lsn(), restart_lsn)) AS delay_size
FROM pg_replication_slots;Jika ukuran yang ditampilkan dalam hasil kueri besar atau sama dengan jumlah log WAL yang terakumulasi, evaluasi dan hapus slot replikasi berdasarkan kebutuhan bisnis Anda.
Pengaturan parameter yang salah
Jika nilai parameter wal_keep_segments, wal_keep_size, dan max_wal_size terlalu besar, sejumlah besar log WAL akan terakumulasi. Periksa dan ubah nilai-nilai parameter ini berdasarkan kebutuhan bisnis Anda.
VACUUM badai dan sejumlah besar penulisan
Dalam banyak kasus, badai VACUUM mengacu pada sejumlah besar operasi VACUUM otomatis atau manual yang dilakukan pada database pada saat yang bersamaan. Saat operasi ini dilakukan, sejumlah besar log WAL mungkin dihasilkan. Hal ini menyebabkan peningkatan signifikan beban I/O dan mempengaruhi kinerja database. Selain itu, log WAL mungkin tidak dihapus secara tepat waktu. Kami merekomendasikan agar Anda mengonfigurasi parameter dalam pernyataan VACUUM dan menjadwalkan eksekusi pernyataan VACUUM berdasarkan kebutuhan bisnis Anda.
Skenario di mana sejumlah besar penulisan terjadi mirip dengan badai VACUUM. Anda harus menjadwalkan penulisan data berdasarkan kebutuhan bisnis Anda.
Akumulasi log di database baca-saja
Jika log WAL terakumulasi di database baca-saja, Anda dapat mengidentifikasi dan memecahkan masalah tersebut dari aspek-aspek berikut.
Latensi replikasi
Daftar berikut menjelaskan kemungkinan penyebab masalah umum di mana latensi terjadi ketika log WAL diputar ulang pada instance baca-saja.
Transaksi jangka panjang ada di database baca-saja dan bertentangan dengan pemutaran ulang log WAL. Dalam hal ini, Anda harus mengevaluasi dan mengubah nilai parameter hot_standby_feedback dan max_standby_streaming_delay berdasarkan kebutuhan bisnis Anda.
Sebagai contoh, jika parameter hot_standby_feedback disetel ke off dan parameter max_standby_streaming_delay disetel ke nilai besar, pelaksanaan transaksi jangka panjang pada database baca-saja dapat menyebabkan latensi pemutaran ulang.
Spesifikasi database utama dan baca-saja berbeda. Jika spesifikasi komputasi dan penyimpanan database baca-saja lebih rendah daripada database utama, latensi replikasi mungkin terjadi. Akibatnya, log WAL yang belum diputar ulang tidak dapat dihapus. Dalam hal ini, Anda harus mengevaluasi dan memilih spesifikasi yang sesuai untuk database baca-saja berdasarkan kebutuhan bisnis Anda.
Langkah selanjutnya
Untuk instance ApsaraDB RDS for PostgreSQL, jika masalah akumulasi log WAL tetap ada setelah Anda melakukan operasi pemecahan masalah di atas, hubungi dukungan teknis ApsaraDB RDS for PostgreSQL.
Referensi
Anda dapat menghapus slot replikasi yang tidak aktif secara manual untuk memungkinkan AliPG menghapus log WAL secara otomatis. Untuk informasi lebih lanjut, lihat Gunakan Fitur Manajemen Log WAL.