备注:
PG版本:14.3

Table of Contents

• 一. 问题描述
• 二. 解决方案
• 参考:

一. 问题描述

今天早上到公司，突然发现备库停了，然后主库这边没找到报错日志，备库这般看到的日志是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左右

最高峰TPS居然高达30W+

疑问:
真的有这么高的TPS吗，后面我运行sql脚本查看，没有这么高的并发，TPS大概在250上下。

PG服务器配置:
PG服务器的硬件配置还不错

二. 解决方案

因为主库没有设置归档(历史遗留问题)，无奈只能重建备库了。

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)

另外现在主库和从库的资源不对等，从库同步压力较大，可以考虑给现有从库增加资源。
复制

参考:

1. https://www.modb.pro/db/484613