一、驗證postgresql增量合并的方案
結果：沒有有效可行的增量合并方案，暫時放棄
二、梳理postgresql基于wal的增量備份
物理備份與還原適用于跨小版本的恢復但是不能跨平臺
邏輯備份與還原備份數(shù)據(jù)適用于跨版本和跨平臺的恢復
postgersql增量備份步驟
1.首先創(chuàng)建歸檔目錄
例如:歸檔目錄為/archive_pg_xlog/xlog
|
1
2
3
|
1>mkdir -p /archive_pg_xlog/xlog2>chown -R postgres:postgres /archive_pg_xlog/xlog3>chmod 700 /archive_pg_xlog/xlog |
2.修改postgresql.conf配置文件
|
1
2
3
|
1>wal_level=archive(配置wal的級別)2>archive_mode=on(開啟歸檔)3>archive_command='DATE=`date +%Y%m%d`;DIR="/archive_pg_xlog/xlog/$DATE";(test -d $DIR || mkdir -p $DIR) && cp %p $DIR/%f'(配置歸檔路徑) |
3.重新啟動數(shù)據(jù)庫服務
|
1
|
systemctl restart postgresql（使配置生效） |
4.做全量備份
|
1
2
3
|
1>psql -c 'select pg_start_backup(now()::text);'，#執(zhí)行該命令表示開始備份2>tar -cf base.tar /var/lib/pgsql/data/*3>psql -c 'select pg_stop_backup();'#tar結束后要關閉備份 |
5.如果表空間存在，還需要備份表空間，沒有則不需要
6.以上操作完成后，增量備份就自動開始了
當xlog寫滿后，就自動歸檔到我們指定的目錄了
postgresql利用xlog進行還原
模擬災難，直接刪除data目錄（或者是data目錄下的所有文件丟失）
先檢查數(shù)據(jù)庫是否已經(jīng)停止，如果還未停止需要停止
|
1
|
mkdir data;chown postgres:postgres data;chmod 700 data |
將備份的base.tar全量包拷貝到data目錄，解壓
|
1
2
3
|
cp /usr/share/psql/recovery.conf.sample ./datavim recovery.conf.sample配置restore_command=''chown postgres:postgres recovery.conf.sample;chmod 700 recovery.conf.sample;mv recovery.conf.sample recovery.conf |
啟動數(shù)據(jù)庫，當recovery.conf變成了recovery.done時即表示恢復完成
注:xlog文件名由時間線TimeLineID（8位16進制）、邏輯日志文件號（8位16進制）和段文件ID（8位16進制）組成
測試1.
第一次全量時，db有一百萬條數(shù)據(jù)，然后再次插入一百萬條數(shù)據(jù)，模擬災難，正常恢復
第二次全量時，是在第一次模擬災難后的場景，即第二次全量備份時有兩百萬條數(shù)據(jù)，再次插入十萬條數(shù)據(jù)，模擬災難，正常恢復
測試2.
再次模擬災難，在第二次全備份新增十萬條數(shù)據(jù)后，直接刪掉data目錄
用第一次的全備份數(shù)據(jù)結合產(chǎn)生的增量來進行恢復，結果，只有兩百萬條數(shù)據(jù)，說明該增量不可合并
測試3.
模擬某個xlog文件丟失時
結果：丟失的xlog文件只影響該丟失的xlog文件依賴的全量備份（會導致數(shù)據(jù)丟失），但是不會影響xlog文件丟失后面的全量備份
對于丟失這種情況暫時還沒有找到恢復的辦法
如果要還原到最近的那一次,也就是不是因為誤操作的等原因的恢復，則不需要配置還原點
|
1
2
3
|
recovery_target_name=''(這個是還原點的名字)recovery_target_time=''(這個是要還原到的具體時間點)recovery_target_xid='' (以最后結束時的id為準) |
創(chuàng)建還原點,也就是還原點的名字select pg_create_restore_point('pitr_test');
創(chuàng)建基于時間的還原點,select now();
創(chuàng)建基于xid的還原點,select txid_current();
補充：PostgreSQL中的log, xlog和clog
pg_log
$PGDATA/pg_log是數(shù)據(jù)庫運行活動日志的默認保存目錄，它包括錯誤信息，查詢日志以及啟動/關閉數(shù)據(jù)庫的信息。當PostgreSQL啟動失敗時，這里應該是你第一個應該查看的信息。一些Linux發(fā)行版以及其他的軟件包管理系統(tǒng)會將這個日志目錄移到某些地方，比如：/var/log/postgresql
你可以在pg_log目錄里自由地刪除、重命名、壓縮或者移動文件而不會有什么不好的結果，只要Postgres用戶仍然有權限寫該目錄。如果pg_log隨著許多大文件而膨脹，你可能需要在postgresql.conf里減小你想記錄日志的事件。
pg_xlog
$PGDATA/pg_xlog是PostgreSQL的事務日志。 這是一些二進制日志文件的集合，文件名類似00000001000000000000008E，它包含最近事務的一些描述數(shù)據(jù)。這些日志也被用于二進制復制。如果復制、歸檔或者PITR失敗了，當歸檔正在恢復時，這個目錄保存的數(shù)據(jù)庫日志可能會膨脹數(shù)GB。這可能會導致你用完你的磁盤空間。不像pg_log，你不能自由地刪除、移動或者壓縮這個目錄的文件。你甚至不能在沒有符號鏈接到該目錄的情況下移動這個目錄。刪除pg_xlog的文件可能會導致不可恢復的數(shù)據(jù)庫損壞。
如果你發(fā)現(xiàn)自己處在這樣的情況：你發(fā)現(xiàn)有100G大小的文件在pg_xlog目錄并且數(shù)據(jù)也啟動不了，并且你已經(jīng)禁止歸檔/復制并且嘗試清理磁盤空間等任何其他的方式，請做以下兩個步驟：
1、從pg_xlog目錄里移動文件到一個備份磁盤或者共享網(wǎng)絡驅動器中，也不要刪除它們。
2、移動一些最老的文件，直到足夠允許PostgreSQL啟動起來。
pg_clog
$PGDATA/pg_clog包含了事務的元數(shù)據(jù)。這種日志用于告訴PostgreSQL哪個事務已經(jīng)完成、哪個還沒有完成。clog是比較小的并且沒有任何理由會膨脹，所以，你應該沒有任何理由去碰觸它。在任何時候你都不應該從pg_clog里刪除文件，如果你這樣子做，還不如完全地刪除整個數(shù)據(jù)庫目錄。缺少clog是不可恢復的。請注意，這意味著，如果你在$PGDATA目錄里備份文件，你應該確定同時包含pg_clog和pg_xlog，否則你可能會發(fā)現(xiàn)你的備份是不可用的。
以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持服務器之家。如有錯誤或未考慮完全的地方，望不吝賜教。
原文鏈接：https://blog.csdn.net/mingtiannihaoabc/article/details/86534221
