我在node1和node3上配置了repmgr复制(分别是主复制和备用复制),并且设置成功地按照预期在备用上创建了新的记录和对象。但是几周后,我注意到复制不再工作了,但是一些repmgr命令会在复制工作时返回结果。我尝试重新启动并再次注册备用节点,但是它没有工作。
我怎样才能继续复制?
以下是节点的状态:
-bash-4.2$ psql -V
psql (PostgreSQL) 10.3NODE1 -初级
-bash-4.2$ repmgr node check
Node "node1":
Server role: OK (node is primary)
Replication lag: OK (N/A - node is primary)
WAL archiving: OK (0 pending archive ready files)
Downstream servers: OK (this node has no downstream nodes)
Replication slots: OK (node has no replication slots)
-bash-4.2$NODE3 -备用
-bash-4.2$ repmgr -f /etc/repmgr/10/repmgr.conf node check
Node "node3":
Server role: OK (node is standby)
Replication lag: OK (0 seconds)
WAL archiving: OK (0 pending archive ready files)
Downstream servers: CRITICAL (1 of 1 downstream nodes not attached; missing: node3 (ID: 3))
Replication slots: OK (node has no replication slots)
-bash-4.2$ repmgr node status
Node "node3":
PostgreSQL version: 10.3
Total data size: 2393 MB
Conninfo: host=node3 user=repmgr dbname=repmgr connect_timeout=2
Role: standby
WAL archiving: disabled (on standbys "archive_mode" must be set to "always" to be effective)
Archive command: /bin/true
WALs pending archiving: 0 pending files
Replication connections: 0 (of maximal 10)
Replication slots: 0 (of maximal 10)
Upstream node: node3 (ID: 3)
Replication lag: 0 seconds
Last received LSN: 4/AC000000
Last replayed LSN: 4/AC000140发布于 2018-06-13 12:49:34
您可能应该提高wal限制,以便将更多的文件保存在周围,同样,使用archive_command将其放在一边也不失为一个好主意。
archive_command = 'test ! -f /postgres/archive/%f && cp -n %p /postgres/archive/%f'
wal_keep_segments = 256为您的用例提高它足够高,256只是这里的一个例子,路径需要调整以匹配您的安装。
其次,使用cluster show来验证集群的健康性,它比检查节点更加清晰。
最后:您是否在克隆后注册待机?你不能在你的命令列表中显示这个。克隆之后,您需要启动并注册它。
repmgr standby register如果它已经存在于repmgr.nodes表中,则添加--force
发布于 2018-04-24 19:41:33
一些需要复制的wal文件在主文件中找不到。然后我又恢复了备用克隆。
在备用服务器上提交的命令:
pg_ctl stop
repmgr -f /etc/repmgr/10/repmgr.conf --force --rsync-only -h node1 -d repmgr -U repmgr --verbose standby clone
pg_ctl start
repmgr node status
repmgr node checkhttps://dba.stackexchange.com/questions/204819
复制相似问题