備注:
PG版本:14.3
一. 問題描述
今天早上到公司，突然發(fā)現(xiàn)備庫停了，然后主庫這邊沒找到報錯日志，備庫這般看到的日志是WAL日志的缺失
2023-06-15 01:50:56.778 UTC [55410] FATAL: 08P01: could not receive data from WAL stream: ERROR: requested WAL segment 0000000200005B5C000000A8 has already been removed
TPS
pgAmin工具上看到，TPS在3000左右
image.png
最高峰TPS居然高達30W+
image.png
疑問:
真的有這么高的TPS嗎，后面我運行sql腳本查看，沒有這么高的并發(fā)，TPS大概在250上下。
PG服務器配置:
PG服務器的硬件配置還不錯
image.png
二. 解決方案
因為主庫沒有設置歸檔(歷史遺留問題)，無奈只能重建備庫了。
PG重建完成后，需做如下操作:
1. 需要開啟歸檔模式:
archive_mode = on
archive_command ='cp %p /data/pgsql/14/data/pg_wal/archive_status/%f'
archive_timeout = 1800s
2. 調整WAL空間參數(shù)
因為TPS較高，目前參數(shù)設置的是20GB，只能保存2個小時不到的WAL
max_wal_size = 500GB
3. 開啟復制槽
開啟復制槽后，如主庫WAL日志未被備庫應用，則不會被主庫刪除
https://www.modb.pro/db/484613
https://www.postgresql.org/docs/14/warm-standby.html#STREAMING-REPLICATION-SLOTS
4. 定期清理WAL日志
我看備庫下WAL目錄有2000多日志
WAL目錄下的archive_status 也有2000多日志
后面發(fā)現(xiàn)問題依舊存在，又重新調整了一次參數(shù)；
我看了下官網:
checkpoint如果太頻繁會導致WAL日志較多
因為每次checkpoint完成后，第一個DML發(fā)生，會將整個數(shù)據(jù)塊寫入到WAL，后面再進行增量更新，所以checkpoint太頻繁，會導致WAL較多。
PG參數(shù)調整:
shared_buffers = 128GB （25%內存,之前是8G）
checkpoint_timeout = 30min (之前是20分鐘)
max_wal_size = 256GB （shared buffers的兩倍）
min_wal_size = 64GB (shared buffer的一半)
wal_keep_size = 128GB (之前是100GB)
checkpoint_completion_target = 0.9 (之前是0,5)
另外現(xiàn)在主庫和從庫的資源不對等，從庫同步壓力較大，可以考慮給現(xiàn)有從庫增加資源。
