暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

PostgreSQL数据库wal进程故障处理

IT那活儿 2024-12-13
223

点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享,不管IT什么活儿,干就完了!!!




故障现象



在监控信息里看到pg数据库的同步进程挂掉了:
登录主库查看信息,这边查询到空白,证明主从已经断掉了:
select client_addr,sync_state from pg_stat_replication;
\x on
select * from pg_stat_replication;

在从库的主机上查看进程,也是没有的:

ps -ef | grep wal


故障处理

故障处理



由于环境问题,一小时产生的wal日志量超过100G以上,由于断开时间太久,只能重建主从,否则会丢数据。
这里的话从库数据已经跟主库不一致且wal日志追不上,先把从库的数据目录整个删除:
su - postgres
pg_ctl stop
rm -rf data/pgsql/data/*

然后直接使用pg_basebackup工具把主库整个拉过来有点类似myslq的克隆插件):
pg_basebackup -h 10.51.x.1x -D /data/pgsql/data -p 5432 -U repl -Fp -Xs -Pv -R --checkpoint=fast
拉去完成后会在数据目录生成文件,跟主库的一模一样:
完成后需要修改配置文件里面的内容:
vim /data/pgsql/data/postgresql.conf
###修改连接数,一定要比主库大
max_connections = 2000
#从机信息和连接用户
primary_conninfo = 'host=10.51.0.109 user=repl password=123456'
#说明恢复到最新状态
recovery_target_timeline = latest
#大于主节点,正式环境重新考虑此值的大小
max_connections = 120
#说明这台机器不仅可以用户数据归档,还可以用于数据查询
hot_standby = on
#流备份的最大延迟时间
max_standby_archive_delay = 30s
#向主机汇报本地状态的间隔时间
wal_receiver_status_interval = 10s
#出现错误复制,向主机反馈
hot_standby_feedback = on
logging_collector = on
log_directory = 'pg_log'
log_filename = 'postgresql-%Y-%m-%d.log'

#
在data下创建一个standby.signal文件 (默认情况刚刚发备份复制命令已经默认创建这个文件了只需要修改就行)

vim standby.signal
standby_mode = 'on'

修改完后启动:
su - postgres
pg_ctl start

启动后会有以下提示,表示需要等待回放wal日志:
但是我这边出现了一些小的故障问题,回放到某个部分的wal日志的时候提示已经被主库删除了:
去主库上查看,搜索这个wal日志,确实没有:
find /data/pgsql/data/pg_wal/xxxxxxxxxxxxxxxx
主要原因是主库默认情况下会自动删除wal日志,如果有配置上边的归档设置,只能去归档目录把wal日志拉回去pg_wal的目录下边archive_commandcp %/data/pgsql/data/pg_archive/%f'是归档的配置。
由于我这边的业务场景的原因,每小时产生的wal日志实在太多,此办法并不是最佳方法。
这个时候只能调整参数,让主库wal日志保留一定的数量,在主库的配置文件添加一下参数:
vim /data/pgsql/data/postgresql.conf
max_wal_senders = 10
wal_keep_size = 400GB
#让主库的pg_wal目录下的wal日志保留400G,按照我这边的业务增长,每小时100+G,400可以保留接近3小时,够时间恢复了
full_page_writes = on
wal_log_hints = on

#
##保存,然后重新加载一下配置文件
su - postgres
pg_ctl reload

操作后,重复上述操作,从删除从库的数据目录文件开始重新执行上述步骤。
特别注意的是复制完成后,记得配置文件把wal保留的配置给去掉在启动,启动成功后看日志文件,会看到正常回放,系统层面查看wal进程是否启动。
[root@bds-prd-pg-s data]# ps -ef | grep wal
root 5308 32711  0 11:02 pts/1    00:00:00 grep --color=auto wal
postgres 9131  8233  8 Feb07 ? 01:23:19 postgres: walreceiver streaming 2D593/28B7E000

数据库层面:
etl=#select pg_is_in_recovery();
pg_is_in_recovery
-------------------
f
(1 row)
####显示f为主库 t为从库
etl=# \x
Expanded display is on.
etl=#select * from pg_stat_replication;
-[ RECORD 1 ]----+------------------------------
pid | 8057
usesysid |
 16384
usename | repl
application_name |
 walreceiver
client_addr | XX.XX.0.108
client_hostname |

client_port | 43306
backend_start |
 2024-02-07 18:26:30.129682+08
backend_xmin | 62649322
state |
 streaming
sent_lsn | 2D596/48FA000
write_lsn |
 2D596/48FA000
flush_lsn | 2D596/48FA000
replay_lsn |
 2D596/48F9A70
write_lag | 00:00:00.023841
flush_lag |
 00:00:00.030618
replay_lag | 00:00:00.249837
sync_priority |
 0
sync_state | async
reply_time |
 2024-02-08 11:05:57.224484+08

从库查看:
etl=# \x
Expanded display is on.
etl=#select * from pg_stat_wal_receiver;
-[ RECORD 1 ]
pid | 9131
status |
 streaming
receive_start_lsn | 2D23C/7D000000
receive_start_tli |
 2
written_lsn | 2D59B/1BA50000
flushed_lsn |
 2D59B/1BA50000
received_tli | 2
last_msg_send_time |
 2024-02-08 11:12:09.260339+08
last_msg_receipt_time | 2024-02-08 11:12:09.263823+08
latest_end_lsn |
 2D59B/1BA50000
latest_end_time | 2024-02-08 11:12:09.002218+08
slot_name |

sender_host | XX.XX.0.109
sender_port |
 5432
conninfo | user=repl password=******** channel_binding=prefer dbname=replication host=10.51.0.109 port=5432 fallback_application_name=walreceiver sslmode=prefer sslcompression=0 sslsni=1 ssl_min_protocol_version=TLSv1.2 gssencmode=disable krbsrvname=postgres target_session_attrs=any


END


本文作者:事业二部(上海新炬中北团队)

本文来源:“IT那活儿”公众号

文章转载自IT那活儿,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论