PostgreSQL pg_archivecleanup與清理archivelog的操作
pg_archivecleanup 和 pg_rewind 是PG 中兩個重要的功能,一個是為了清理過期的 archive log 使用的命令,另一個是你可以理解為物理級別的 wal log的搬運工。
我們先說第一個 pg_archivecleanup 命令,這個命令主要是用於使用了archive log 功能的 postgresql 但在 archive log 堆積如山的情況下,你怎麼來根據某些規則,清理這些日誌呢?
這裡面就要使用 pg_archivecleanup 這個命令了,可以定時的來執行它,將已經移動到archivecleanup 的目錄的archivelog 根據要求開始清理。
當然我們先的說說如果不定期清理會出什麼問題
1 如果不定期清理archive 如果存放archivelog 的位置無法在接受新的日誌,則大量WAL日誌會滯留在 wal_log 目錄中,則整體資料庫系統都會受到影響。
2 佔用大量的儲存空間,儲存無效的資料
那一般來說如果沒有第三方的備份工具的情況下,怎麼來通過pg_archivecleanup 來進行archivelog 的清理。
需要關注幾個點
1 清理的時,清理的WAL_LOG 是否已經是包含在最後一次的備份中,保證清理的WAL_LOG 也可以從備份檔案中恢復資料庫
2 清理的時候,對於儲存在非主庫的wal_log 怎麼辦
一般來說,設定自動清理archive_log 可以在配置檔案中新增
archive_cleanup_command = 'pg_archivecleanup archivelocation %r'
來操作。
但一般來說這樣做好處少,弊病多,我比較喜歡寫相關的指令碼,定時去執行的方式,並且可以記錄相關的LOG 日誌等等。
可以寫一個指令碼,來輔助定時清理相關的archive_log
當然這樣的方法也是有弊端的,如果由於備份的原因的故障,而直接使用天數來清理會有因為沒有備份而直接將 wal_log 給清理掉,所以更加靠譜的方法是通過某些命令來獲得需要截止的清理的Wal_log 名稱。
例如 備份後的
會在wal_log 裡面有backup 的標記,這說明這個WAL log 以前的資料已經備份了,如果清理這個WAL LOG 之前的log 是安全的。
000000010000000300000030.00000060.backup
使用下面的指令碼可以來更安全的清理
#!/bin/bash ARCHIVEDIR='/pgdata/archive' CHK_SAFE=$(find $ARCHIVEDIR -type f -mtime +3 -name '*backup' -printf '%f\n' | sort -r | head -1) cd $ARCHIVEDIR /usr/local/postgres/bin/pg_archivecleanup $ARCHIVEDIR $CHK_SAFE find $ARCHIVEDIR -type f -mtime +3 -a -name '*backup' -a ! -newer $CHKPOINT -delete
補充:postgresql流日誌誤刪處理(xlog)
今天同事誤刪postgresql庫資料檔案下的pg_xlog資料夾,導致所有流日誌丟失,資料庫無法啟動,觀察警告日誌:
2018-03-12 18:45:54 CST LOG: database system shutdown was interrupted; last known up at 2018-03-12 17:48:27 CST 2018-03-12 18:45:54 CST LOG: could not open file "pg_xlog/000000010000001400000060" (log file 20,segment 96): No such file or directory 2018-03-12 18:45:54 CST LOG: invalid primary checkpoint record 2018-03-12 18:45:54 CST LOG: could not open file "pg_xlog/000000010000001400000060" (log file 20,segment 96): No such file or directory 2018-03-12 18:45:54 CST LOG: invalid secondary checkpoint record 2018-03-12 18:45:54 CST PANIC: could not locate a valid checkpoint record 2018-03-12 18:45:54 CST LOG: startup process (PID 32680) was terminated by signal 6: Aborted 2018-03-12 18:45:54 CST LOG: aborting startup due to startup process failure
用postgresql自帶的pg_resetxlog工具可以跳過對WAL log的恢復。不過會丟失一些事務。恢復命令也很簡單如下:
pg_resetxlog -f /var/lib/pgsql/9.6/data
然後啟動postgrsql,資料庫就可正常進入
參考:pg_resetxlog官方文件
以上為個人經驗,希望能給大家一個參考,也希望大家多多支援我們。如有錯誤或未考慮完全的地方,望不吝賜教。