一、驗證postgresql增量合并的方案

結果：沒有有效可行的增量合并方案，暫時放棄

二、梳理postgresql基于wal的增量備份

物理備份與還原適用于跨小版本的恢復但是不能跨平臺

邏輯備份與還原備份數(shù)據(jù)適用于跨版本和跨平臺的恢復

postgersql增量備份步驟

1.首先創(chuàng)建歸檔目錄

例如:歸檔目錄為/archive_pg_xlog/xlog

1>mkdir -p /archive_pg_xlog/xlog
2>chown -R postgres:postgres /archive_pg_xlog/xlog
3>chmod 700 /archive_pg_xlog/xlog

2.修改postgresql.conf配置文件

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ù)庫服務

systemctl restart postgresql（使配置生效）

4.做全量備份

 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)停止，如果還未停止需要停止

mkdir data;chown postgres:postgres data;chmod 700 data

將備份的base.tar全量包拷貝到data目錄，解壓

cp /usr/share/psql/recovery.conf.sample ./data
vim 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ù)，模擬災難，正?；謴?/p>

第二次全量時，是在第一次模擬災難后的場景，即第二次全量備份時有兩百萬條數(shù)據(jù)，再次插入十萬條數(shù)據(jù)，模擬災難，正常恢復

測試2.

再次模擬災難，在第二次全備份新增十萬條數(shù)據(jù)后，直接刪掉data目錄

用第一次的全備份數(shù)據(jù)結合產(chǎn)生的增量來進行恢復，結果，只有兩百萬條數(shù)據(jù)，說明該增量不可合并

測試3.

模擬某個xlog文件丟失時

結果：丟失的xlog文件只影響該丟失的xlog文件依賴的全量備份（會導致數(shù)據(jù)丟失），但是不會影響xlog文件丟失后面的全量備份

對于丟失這種情況暫時還沒有找到恢復的辦法

如果要還原到最近的那一次,也就是不是因為誤操作的等原因的恢復，則不需要配置還原點

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ù)庫運行活動日志的默認保存目錄，它包括錯誤信息，查詢?nèi)罩疽约皢?關閉數(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)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。如有錯誤或未考慮完全的地方，望不吝賜教。

最新評論