说明
pg12流复制搭建主要方式和之前没有太大区别，改变的地方在于pg12将recovery.conf文件合并到了postgresql.conf中，相关的配置需要进行修改。
主库配置
同样需要在主库配置接受流复制的连接，修改pg_hba.conf文件，添加另一个备库的信息
- # TYPE ?DATABASE ? ? ? ?USER ? ? ? ? ? ?ADDRESS ? ? ? ? ? ? ? ? METHOD
- ? host ?replication ? ? all ? ? ? ? ? ? 192.168.7.180/24 ? ? ? ?trust
在postgresql.conf文件添加
- listen_addresses = '*'
- max_wal_senders = 5
- wal_level = hot_standby
- synchronous_standby_names = ''ANY 1(standby01,standby02)'
备库配置
在两个备库执行同样操作
备份数据：
- pg12@dmdb01-> pg_basebackup -h 192.168.7.180 -U bill -F p -P -R -D /home/pg12/pgdata/bk_data/ -l backup191227
修改postgresql.conf文件,添加：
- primary_conninfo = 'application_name=standby01 user=bill passfile=''/home/pg12/.pgpass'' host=192.168.7.180 port=1921 sslmode=disable sslcompression=1 target_session_attrs=any'
然后需要在新的$PGDATA目录下生成一个standby.signal文件。
最后启动数据库即可(这里需要注意要使用新的数据目录启动)，接着在另一台备库执行同样的操作。
主库验证：
- bill=# select * from pg_stat_replication;
- ? pid ?| usesysid | usename | application_name | ?client_addr ?| client_hostname | client_port | ? ? ? ? backend_start ? ? ? ? | backend_xmin | ? state ? | ?sent_lsn ? | ?write_lsn ?| ?flush_lsn ?| re
- play_lsn ?| write_lag | flush_lag | replay_lag | sync_priority | sync_state | ? ? ? ? ?reply_time ? ? ? ? ?
- -------+----------+---------+------------------+---------------+-----------------+-------------+-------------------------------+--------------+-----------+-------------+-------------+-------------+---
- ----------+-----------+-----------+------------+---------------+------------+------------------------------
- ?25632 | ? ?16384 | bill ? ?| walreceiver ? ? ?| 192.168.7.193 | ? ? ? ? ? ? ? ? | ? ? ? 59454 | 2019-12-27 08:56:35.237088+08 | ? ? ? ? ? ? ?| streaming | 1E/72000060 | 1E/72000060 | 1E/72000060 | 1E
- /72000060 | ? ? ? ? ? | ? ? ? ? ? | ? ? ? ? ? ?| ? ? ? ? ? ? 0 | async ? ? ?| 2019-12-27 17:08:44.95124+08
- ?27191 | ? ?16384 | bill ? ?| walreceiver ? ? ?| 192.168.7.192 | ? ? ? ? ? ? ? ? | ? ? ? 10306 | 2019-12-27 08:59:33.259722+08 | ? ? ? ? ? ? ?| streaming | 1E/72000060 | 1E/72000060 | 1E/72000060 | 1E
- /72000060 | ? ? ? ? ? | ? ? ? ? ? | ? ? ? ? ? ?| ? ? ? ? ? ? 0 | async ? ? ?| 2019-12-27 17:08:43.24504+08
- (2 rows)
至此，完成同步流复制standby数据库的搭建！
主备切换
当主库出现故障时，我们需要将备库提升为主库进行读写操作。在pg12之前我们一般使用2种方式：
pg_ctl 方式: 在备库主机执行 pg_ctl promote shell 脚本
触发器文件方式: 备库配置 recovery.conf 文件的 trigger_file 参数，之后在备库主机上创建触发器文件
pg12开始新增了一个pg_promote()函数，让我们可以通过SQL命令激活备库。
pg_promote()语法：
- pg_promote(wait boolean DEFAULT true, wait_seconds integer DEFAULT 60)
两个参数：
wait: 表示是否等待备库的 promotion 完成或者 wait_seconds 秒之后返回成功，默认值为 true。wait_seconds: 等待时间，单位秒，默认 60
切换举例：
关闭主库，模拟主库故障：
- pg12@test180-> pg_ctl stop -m fast
- waiting for server to shut down.... done
- server stopped
激活备库：
- bill=# select pg_promote(true,60);
- ?pg_promote?
- ------------
- ?t
- (1 row)
验证：
- pg12@dmdb02-> pg_controldata | grep 'Database cluster state'
- Database cluster state: ? ? ? ? ? ? ? in production
至此便完成备库的激活，当原主库修复完后，我们可重复之前步骤将原主库作为新的备库使用。
总结
以上为个人经验，希望能给大家一个参考，也希望大家多多支持w3xue。
经验首页