暂无图片
暂无图片
暂无图片
暂无图片
暂无图片
首页 / PostgreSQL物理复制搭建主从环境(二)

PostgreSQL物理复制搭建主从环境(二)

长河的笔记 2020-08-16
435

接上篇文档，说一说物理复制环境下几点注意：


同步流复制的配置

上面的方式配置的是异步复制，如想配置为同步复制，需要将数据库参数synchronous_commit设置为on, 表示流复制主库提交事务时，需等待备库接收主库发送的wal日志流并写入wal文件，之后才向客户端返回成功，简单来说on表示本地wal已落盘，备库的wal也已落盘，有两份持久化的wal，但备库此时还没有完成重做。此参数的另外2个值是remote_write和remote_apply，具体含义请参考文档。


采用同步流复制架构推荐至少使用3台机器，如果只有2台机器，由于同步复制要求wal日志必须写到备库主机上，当备库宕机的时，主库上所有的事务将被hang住，会严重影响主库的可用性。如果是1主2从的架构，则其中一个备库宕机之后，另一个备库还能够正常接收wal日志，主库完全不受影响。


1.修改主备库的postgresql.conf
synchronous_commit = on    # synchronization level;
synchronous_standby_names = '*'  # standby servers that provide sync rep


[postgres@pghost01 data]$ pg_ctl reload  -->重新载入配置


2.修改备库的recovery.conf，添加application_name
primary_conninfo = 'host=10.0.2.110 port=5432 user=repuser password=rep12345 application_name=pghost1'
Pg_ctl restart -m fast


--主库上确定复制状态为同步
postgres=# select usename,application_name,client_addr,sync_state from pg_stat_replication;
 usename | application_name |  client_addr  | sync_state 
---------+------------------+---------------+------------
 repuser | pghost1          | 192.168.28.75 | sync


使用复制槽防止主库清除还未复制到备库的WAL文件

如果备库因为种种原因造成长时间未与主库同步，那么根据wal日志清除策略主库可能会清除掉还未复制到备库的wal日志文件，这时备库就不得不重新初始化。复制槽的作用就是为了防止主库清除还未复制到备库的wal日志而设计的。

  1. 设置max_replications_slots>0 on each sending node, 此设置需要重启生效
  max_replication_slots = 2
  
  2. 创建slot on each sending node.
  SELECT pg_create_physical_replication_slot('pghost00_pghost01_1');
  SELECT * FROM pg_replication_slots;
  
  3. In the recovery.conf file in the data directory on the standby
  primary_slot_name = 'pghost00_pghost01_1'


  4. 用于清除slot的sql
  SELECT pg_drop_physical_replication_slot('alpha_beta_1');
  
  postgres=# SELECT * FROM pg_replication_slots;
        slot_name      | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn
  ---------------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------
   pghost00_pghost01_1 |        | physical  |        |          | f         | t      |       3459 |      |              | 2/60000D0   |
(1 row)


备库设置延时恢复

有时设置延时复制是有用的，它能提供机会纠正数据丢失错误。这个参数允许你将恢复延迟一段时间，可以按秒，分钟，小时，天为单位设置，默认以毫秒为单位。

--在备库的recovery.conf中设置recovery_min_apply_delay,修改后需要重启 standby节点才能生效：
recovery_min_apply_delay = 10min  # 这里设置10分钟的延迟
#默认的支持时间单位为 ms 、s、min、h、d 即 毫秒 秒 分钟 小时 天


--设置完参数后，就可以在主库上看到延时了, 可以看到这里的延时是replay延时，write_lag没有延时。
postgres=# select * from pg_stat_replication;
-[ RECORD 1 ]----+------------------------------
pid              | 3560
usesysid         | 82970
usename          | repuser
application_name | walreceiver
client_addr      | 10.0.2.111
client_hostname  |
client_port      | 41560
backend_start    | 2019-12-22 14:00:37.740224+08
backend_xmin     |
state            | streaming
sent_lsn         | 2/7000B68
write_lsn        | 2/7000B68
flush_lsn        | 2/7000B68
replay_lsn       | 2/70008C8
write_lag        | 00:00:00.000432
flush_lag        | 00:00:00.00141
replay_lag       | 00:09:48.221432
sync_priority    | 0
sync_state       | async


Time: 1.197 ms




暂停和恢复备库复制

select pg_wal_replay_pause();
SELECT pg_is_wal_replay_paused();
SELECT pg_wal_replay_resume();
--注意暂停和恢复只能在备库上操作，主库上操作会报如下错误:
postgres=# select pg_wal_replay_pause();
ERROR:  recovery is not in progress
HINT:  Recovery control functions can only be executed during recovery.
Time: 4.799 ms


END





postgresql
文章转载自长河的笔记，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论