postgres standby实现同步流复制

本文介绍如何使用PostgreSQL通过同步复制实现数据库高可用性。详细讲述了配置过程,包括设置master和standby节点、配置同步复制参数及用户权限,并演示了如何验证同步状态。

postgres可以实现基于流传递wal日志然后实现standby,从而实现数据库的高可用。在创建standby的过程中,有两种方式,一种是同步的方式,另外一种方式是异步的方式。同步和异步的差别在于,异步的方式为当master将wal日志传递给slave端之后,不需要standby端进行确认就进行了返回。这样如果数据发生了崩溃会导致数据有误差。而同步的方式则是需要standby对master端穿过来的wal日志进行确认,知道确认成功才会进行返回,这就保证了两边数据的完全的一直。但是这种模式会存在一个问题,如果standby出现问题,然后一直不能对master的请求进行确认,就会导致master主机将会被hang住,从而导致数据库不能写。所以我们在搭建同步的数据库集群的时候,要求standby的数量在两个以上。

环境说明:(为了方便下面的实验环境一共采用了一个standby,不过正式的环境中一定要注意)

master:

192.168.8.4

192.168.8.147

 

更改master端的配置文件(postgres.conf)

wal_level =hot_standby

max_wal_senders =5

listen_addresses ='*'

synchronous_standby_names= 'standby01' (此处的名字一定要写,多个名字利用逗号分开,代表的是standby的名字)

创建用户并且对登录情况进行限制(pg_hba.conf)

在配置文件中添加如下的行

host     replication     all             all          md5

在standby进行数据文件的拷贝

pg_basebackup  -U replicaiton  -h 192.168.8.4 -F p -P -x -R -D/data/postgresdata_backup/ -l backup20170611

之后修改数据目录下面的recovery.conf配置文件

primary_conninfo ='application_name=name user=replication password=*** host=192.168.8.4 port=5432sslmode=disable sslcompression=1'

注意此处的需要添加application_name=name(此时的name和在主配置中的synchronous_standby_names保持一致)

修改配置文件打开standby

hot_standby = on

然后就可以对数据库进行重启了

之后可以在master端进行查看同步情况

selectpid,state,client_addr,sync_priority,sync_state from pg_stat_replication;

  pid |   state   | client_addr  | sync_priority |sync_state

-------+-----------+---------------+---------------+------------

 32379 | streaming | 192.168.8.147 |             1 | sync

表示现在同步正常,如果有多台standby的话另外的standby也会出现在这个列表中,不过他的状态为potential,表示他可以成为sync状态。

另外hang住的情况也可以自行测试,在此处我就不测试了。


 

 

 

 

### PostgreSQL 复制中的回复延迟诊断与优化 #### 日志分析 当遇到复制的回复延迟时,日志文件提供了重要的线索。错误信息表明,在恢复过程中遇到了冲突,这可能是由于主节点上的某些操作试图访问正在被移除的数据版本所致[^2]。 ```sql FATAL,40001,"terminating connection due to conflict with recovery", "User query might have needed to see row versions that must be removed.", "In a moment you should be able to reconnect to the database and repeat your command." ``` 上述致命错误提示用户尝试执行的操作可能依赖于已被删除的日志记录版本,从而导致连接终止并建议稍后再试。 #### WAL接收器状态监控 通过检查`walreceiver`进程的状态可以进一步了解问题所在。正常情况下,WAL接收器会持续从主服务器获取更新,并将其应用于备库。如果存在长时间停滞,则说明可能存在网络传输瓶颈或是磁盘写入性能不足等问题[^3]。 ```bash ps aux | grep walreceiver ``` 此命令可以帮助确认`walreceiver`是否处于活动状态以及是否有任何异常情况发生。 #### 参数调整 为了降低因并发控制机制引发的冲突频率,可考虑适当增大`max_standby_streaming_delay`参数值,默认单位为毫秒。增加该数值允许备用数据库有更多的缓冲时间来完成必要的清理工作而不至于立即中断客户端连接: ```postgresql ALTER SYSTEM SET max_standby_streaming_delay TO '30s'; SELECT pg_reload_conf(); ``` 此外,还可以启用热 standby反馈功能(`hot_standby_feedback`)以防止主节点上过早回收旧版本元组,进而减少潜在的竞争条件。 ```postgresql ALTER SYSTEM SET hot_standby_feedback TO on; SELECT pg_reload_conf(); ``` #### 性能调优 对于硬件资源有限的情况,应重点审查I/O子系统的健康状况,确保有足够的带宽供WAL日志同步使用;同时也要关注CPU利用率和内存分配策略,避免不必要的争用现象影响整体效率。 最后值得注意的是,虽然提高容忍度可以在一定程度上缓解症状,但从长远来看还是应该找出根本原因并对症下药——比如优化应用程序设计模式、改进索引结构等措施都能有效提升系统稳定性。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值