pg_archivecleanup 和 pg_rewind 是PG 中兩個(gè)重要的功能,一個(gè)是為了清理過期的 archive log 使用的命令,另一個(gè)是你可以理解為物理級(jí)別的 wal log的搬運(yùn)工。
我們先說第一個(gè) pg_archivecleanup 命令,這個(gè)命令主要是用于使用了archive log 功能的 postgresql 但在 archive log 堆積如山的情況下,你怎么來根據(jù)某些規(guī)則,清理這些日志呢?
這里面就要使用 pg_archivecleanup 這個(gè)命令了,可以定時(shí)的來運(yùn)行它,將已經(jīng)移動(dòng)到archivecleanup 的目錄的archivelog 根據(jù)要求開始清理。
當(dāng)然我們先的說說如果不定期清理會(huì)出什么問題
1 如果不定期清理archive 如果存放archivelog 的位置無法在接受新的日志,則大量WAL日志會(huì)滯留在 wal_log 目錄中,則整體數(shù)據(jù)庫系統(tǒng)都會(huì)受到影響。
2 占用大量的存儲(chǔ)空間,存儲(chǔ)無效的數(shù)據(jù)
那一般來說如果沒有第三方的備份工具的情況下,怎么來通過pg_archivecleanup 來進(jìn)行archivelog 的清理。
需要關(guān)注幾個(gè)點(diǎn)
1 清理的時(shí),清理的WAL_LOG 是否已經(jīng)是包含在最后一次的備份中,保證清理的WAL_LOG 也可以從備份文件中恢復(fù)數(shù)據(jù)庫
2 清理的時(shí)候,對(duì)于保存在非主庫的wal_log 怎么辦
一般來說,設(shè)置自動(dòng)清理archive_log 可以在配置文件中添加
archive_cleanup_command = 'pg_archivecleanup archivelocation %r'
來操作。
但一般來說這樣做好處少,弊病多,我比較喜歡寫相關(guān)的腳本,定時(shí)去運(yùn)行的方式,并且可以記錄相關(guān)的LOG 日志等等。
![](/d/20211018/312a17e89cf6ff5651c51c8e1c898795.gif)
可以寫一個(gè)腳本,來輔助定時(shí)清理相關(guān)的archive_log
![](/d/20211018/ee8e843a1041e1117e94ff128c8f11af.gif)
當(dāng)然這樣的方法也是有弊端的,如果由于備份的原因的故障,而直接使用天數(shù)來清理會(huì)有因?yàn)闆]有備份而直接將 wal_log 給清理掉,所以更加靠譜的方法是通過某些命令來獲得需要截止的清理的Wal_log 名稱。
例如 備份后的
![](/d/20211018/90b202453d6945db2e00b9d66e94a9ca.gif)
會(huì)在wal_log 里面有backup 的標(biāo)記,這說明這個(gè)WAL log 以前的數(shù)據(jù)已經(jīng)備份了,如果清理這個(gè)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
補(bǔ)充:postgresql流日志誤刪處理(xlog)
今天同事誤刪postgresql庫數(shù)據(jù)文件下的pg_xlog文件夾,導(dǎo)致所有流日志丟失,數(shù)據(jù)庫無法啟動(dòng),觀察警告日志:
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工具可以跳過對(duì)WAL log的恢復(fù)。不過會(huì)丟失一些事務(wù)?;謴?fù)命令也很簡(jiǎn)單如下:
pg_resetxlog -f /var/lib/pgsql/9.6/data
然后啟動(dòng)postgrsql ,數(shù)據(jù)庫就可正常進(jìn)入
參考:pg_resetxlog官方文檔
以上為個(gè)人經(jīng)驗(yàn),希望能給大家一個(gè)參考,也希望大家多多支持腳本之家。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教。
您可能感興趣的文章:- Postgresql排序與limit組合場(chǎng)景性能極限優(yōu)化詳解
- 解決postgresql無法遠(yuǎn)程訪問的情況
- 淺談Postgresql默認(rèn)端口5432你所不知道的一點(diǎn)
- postgresql修改完端口后直接psql連接數(shù)據(jù)庫報(bào)錯(cuò)的解決
- postgresql 實(shí)現(xiàn)啟動(dòng)、狀態(tài)查看、關(guān)閉
- postgresql連續(xù)歸檔及時(shí)間點(diǎn)恢復(fù)的操作
- 解決PostgreSQL日志信息占用磁盤過大的問題
- 關(guān)于PostgreSQL 行排序的實(shí)例解析