备注:
PG版本:14.3
一. 问题描述
今天早上到公司，突然发现备库停了，然后主库这边没找到报错日志，备库这般看到的日志是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脚本查看，没有这么高的并发，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空间参数
因为TPS较高，目前参数设置的是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多日志
后面发现问题依旧存在，又重新调整了一次参数；
我看了下官网:
checkpoint如果太频繁会导致WAL日志较多
因为每次checkpoint完成后，第一个DML发生，会将整个数据块写入到WAL，后面再进行增量更新，所以checkpoint太频繁，会导致WAL较多。
PG参数调整:
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)
另外现在主库和从库的资源不对等，从库同步压力较大，可以考虑给现有从库增加资源。
网友评论