騰訊雲TDSQL PostgreSQL WAL日誌清理

語言: CN / TW / HK

作者崔鵬,曾獲得中國PostgreSQL數據庫管理高級工程師(PGCM),是PostgreSQL官方認證講師,Mysql 5.7/8.0 OCP,Oracle 11g OCM。

WAL是Write Ahead Log的簡寫,10版本以後在$PGDATA/pg_wal目錄中 10之前的版本在$PGDATA/pg_xlog.

wal相關參數

#wal_compression = off 如果當全頁寫成為io瓶頸時,可以設置為on

#wal_log_hints = off 如果使用pg_rewind,需要設置為on

#wal_buffers = -1 默認-1會根據shared_buffers自動調整

打開這個選項的時候,PostgreSQL服務器在檢查點之後對頁面的第一次寫入時將整個頁面寫到 WAL 裏面。這麼做是因為在操作系統崩潰過程中可能只有部分頁面寫入磁盤, 從而導致在同一個頁面中包含新舊數據的混合。在崩潰後的恢復期間, 由於在WAL裏面存儲的行變化信息不夠完整,因此無法完全恢復該頁。把完整的頁面影像保存下來就可以保證正確存儲頁面, 代價是增加了寫入WAL的數據量。因為WAL重放總是從一個檢查點開始的, 所以在檢查點後每個頁面第一次改變的時候做WAL備份就足夠了。因此,一個減小全頁面寫開銷的方法是增加檢查點的間隔參數值。

#wal_writer_delay = 200ms wal writer進程的間歇時間,過大的話,可能會造成wal buffer不足,過小的話wal會不斷寫入,可能會有io瓶頸

#commit_delay = 0 至少有commit_siblings個併發事務時,該事務提交後,wal日誌將延遲commit_delay時間後再寫入磁盤。可以合併其他事務進行組提交,所以當有大量事務的時候會延遲,而如果事務很稀少就不會再被延遲了。非0值的影響:減少IO,提高性能:事務執行commit後不會立即寫入磁盤,而存放在WAL buffer中,崩潰數據面臨着丟失的危險,可能引起WAL buffer內存不足,尤其是提交事務較多的高峯期

#commit_siblings = 5 延遲提交wal日誌的最小併發事務數,決定參數commit_delay是否生效。假設值是5,表示數據庫中正在執行的事務數大於或等於5,該事務提交後,wal日誌將會存入wal buffer中,延遲commit_delay時間後再寫入磁盤。如果數據庫中正在執行的事務數小於5,這個事務提交後將wal日誌直接寫入磁盤。

自動清理wal條件

1.做檢查點的時候

2.數據庫啟動的時候,或者修改了相關參數後重啟數據庫。

手動清理WAL

postgres@pgexp1-> pg_controldata pg_control version number: 1201 Catalog version number: 201909212 Database system identifier: 6931137589662892022 Database cluster state: in production pg_control last modified: Wed 03 Mar 2021 07:54:25 AM CST Latest checkpoint location: 0/163CBD0 Latest checkpoint's REDO location: 0/163CB98 Latest checkpoint's REDO WAL file: 000000010000000000000003 #當前的時間線位置 Latest checkpoint's TimeLineID: 1 Latest checkpoint's PrevTimeLineID: 1 Latest checkpoint's full_page_writes: on 這裏表示0/163CBD0檢查點已經執行,已經包含在000000010000000000000003日誌文件中,這個日誌之前的日誌是可以清理的。

可以手動使用系統命令rm -f清理

也可以使用pg_archivecleanup清理

保留000000010000000000000002之後的日誌

pg_archivecleanup /opt/pg_root/pg_wal/ 000000010000000000000002

文章來源:雲貝學院