postgresql減少wal日誌生成量的操作
1、在繁忙的系統中，如果需要降低checkpoint發生的頻率，減少WAL日誌的生成量，減輕對系統IO的壓力，可以通過以下兩種方法。
1) 調整WAL segment大小，最高可以調整到64MB，不過只能通過編譯來調整。對於已有系統不太方便；
2) 增大checkpoint_segments設定，使得checkpoint不會過於頻繁地被觸發；
2、在9.5中，checkpoint_segments被廢棄，可以通過新增引數max_wal_size來調整，該引數預設為1GB，已經是9.4的2倍。但如果9.4中手工設定了checkpoint_segments，如本例，則以下的公式可以做為9.5設定max_wal_size的參考。
max_wal_size = (3 * checkpoint_segments) * 16MB
補充：PostgreSQL利用全備與WAL日誌恢復資料庫
一般情況全備只能做到備份時刻的恢復，在全備操作過後的資料庫資訊無法同步，此時就需要利用wal日誌來進行時間點的恢復
基礎備份——全備
使用pg_basebackup
pg_basebackup是postgresql提供的一個方便基礎備份的工具（9.1開始提供），這個工具會把整個資料庫例項的資料都拷貝出來，而不只是把例項中的部分（如某個資料庫或表）單獨備份出來，該工具使用replication協議連線到資料庫例項上，所以主資料庫中的pg_hba.conf必須允許replication連線，類似如下：
local replication postgre ident
在9.2之後支援級連複製，所以在之後的版本中，pg_basebackup也可以從另外一個standby庫上做基礎備份，都需注意如下幾方面：
1、備份中沒有備份歷史檔案；
2、不確保所有需要的WAL檔案都備份了，如果想確保，需要加命令列引數 ”-x";
3、如果在備份過程中standby被提升為主庫，則備份會失敗；
4、要求主庫中打開了“full_page_writes"引數，WAL檔案不能被類似pg_compresslog的工具去掉full_page_writes資訊。
引數
-Ft F表示輸出格式，t為tar包的格示，p，預設值，輸出為目錄。
-X fetch X表示收集wal日誌的方式 fetch表示收集wal日誌，stream為不收集，以備庫streaming的方式追趕主庫，none一般不使用
-h 要備份資料庫的所在的IP
-p 資料庫埠號
-P 備份進度，以百分制顯示
-v 輸出備份資訊，如上面pg_basebackup:等類似語句。
-W 輸入密碼選項
-D 要備份到的目錄
其他選項 比如-R 備份備庫時儲存recover.conf檔案
WAL日誌的的備份
測試流程
將被資料檔案全備
一臺是已執行的主庫，一臺是安裝好資料庫但是沒有初始化的預恢復庫
將主庫的資料檔案全備到備庫的的資料目錄中
繼續操作主庫
在表中插入幾行資料，並留下時間
postgres=# insert into test08 values (6666666,'asdfg'); INSERT 0 1 postgres=# insert into test08 values (6666666,'asdfg'); INSERT 0 1
postgres=# select now();
now
-------------------------------
2018-07-18 15:03:28.969495+08
(1 row)
postgres=#
切換wal日誌
postgres=# select pg_switch_wal(); pg_switch_wal --------------- 5/EF0009D8 (1 row) postgres=#
####將wal日誌歸檔到備庫
這邊是直接將日誌傳過去，到備庫的/backup 目錄
配置recovery.conf檔案
在pgdata目錄裡，建立檔案
[postgres@mdw pgdata]$ cat recovery.conf recovery_target_time = ' 2018-07-18 11:00:18.526347+08 ' restore_command = 'cp /backup/pg_wal/%f %p'
啟動恢復例項
[postgres@mdw pgdata]$ pg_ctl start waiting for server to start....2018-07-18 15:07:52.420 CST [3353] LOG: listening on IPv4 address "0.0.0.0",port 5432 2018-07-18 15:07:52.420 CST [3353] LOG: listening on IPv6 address "::",port 5432 2018-07-18 15:07:52.426 CST [3353] LOG: listening on Unix socket "/tmp/.s.PGSQL.5432" 2018-07-18 15:07:52.468 CST [3354] LOG: database system was interrupted; last known up at 2018-07-18 15:00:09 CST 2018-07-18 15:07:52.950 CST [3354] LOG: starting point-in-time recovery to 2018-07-18 15:03:28.969495+08 2018-07-18 15:07:52.987 CST [3354] LOG: restored log file "0000000100000005000000F8" from archive 2018-07-18 15:07:53.247 CST [3354] LOG: redo starts at 5/F8000028 2018-07-18 15:07:53.308 CST [3354] LOG: consistent recovery state reached at 5/F8000B08 2018-07-18 15:07:53.308 CST [3353] LOG: database system is ready to accept read only connections done server started [postgres@mdw pgdata]$ 2018-07-18 15:07:53.343 CST [3354] LOG: restored log file "0000000100000005000000F9" from archive 2018-07-18 15:07:53.626 CST [3354] LOG: restored log file "0000000100000005000000FA" from archive 2018-07-18 15:07:54.192 CST [3354] LOG: invalid record length at 5/FA000140: wanted 24,got 0 2018-07-18 15:07:54.192 CST [3354] LOG: redo done at 5/FA000108 2018-07-18 15:07:54.192 CST [3354] LOG: last completed transaction was at log time 2018-07-18 15:03:20.200594+08 2018-07-18 15:07:54.397 CST [3354] LOG: restored log file "0000000100000005000000FA" from archive cp: cannot stat `/backup/pg_wal/00000002.history': No such file or directory 2018-07-18 15:07:54.633 CST [3354] LOG: selected new timeline ID: 2 cp: cannot stat `/backup/pg_wal/00000001.history': No such file or directory 2018-07-18 15:07:55.160 CST [3354] LOG: archive recovery complete 2018-07-18 15:07:55.263 CST [3353] LOG: database system is ready to accept connections
檢視恢復情況
發現已經將之後的操作在備庫上進行恢復了
postgres=# select * from test08 where id=6666666; id | n ---------+------- 6666666 | asdfg 6666666 | asdfg 6666666 | asdfg 6666666 | asdfg 6666666 | asdfg 6666666 | asdfg (6 rows)
以上為個人經驗，希望能給大家一個參考，也希望大家多多支援我們。如有錯誤或未考慮完全的地方，望不吝賜教。