☰

repmgr - 故障转移切换后，两个节点都充当主节点

tag-icon • tag-icon postgresql replication failover database-replication
repmgr - 故障转移切换后，两个节点都充当主节点

我有一个通过 配置的双节点 PostgreSQL 集群repmgr。
数据库拓扑如下所示：

db1 - 10.10.10.50 ( master )
db2 - 10.10.10.60 ( standby )
wit - 10.10.10.70 ( witness )

集群的创建（如复制和自动故障转移）按预期工作，但问题如下。

假设我的集群中的db1节点发生故障，那么预期的行为是该db2节点被提升为新的主节点。一切都很好，日志证明了这一点：

[WARNING] connection to upstream has been lost, trying to recover... 60 seconds before failover decision
[WARNING] connection to upstream has been lost, trying to recover... 50 seconds before failover decision
[WARNING] connection to upstream has been lost, trying to recover... 40 seconds before failover decision
[WARNING] connection to upstream has been lost, trying to recover... 30 seconds before failover decision
[WARNING] connection to upstream has been lost, trying to recover... 20 seconds before failover decision
[WARNING] connection to upstream has been lost, trying to recover... 10 seconds before failover decision
[ERROR] unable to reconnect to upstream after 60 seconds...
[ERROR] connection to database failed: could not connect to server: No route to host
        Is the server running on host "10.10.10.50" and accepting
        TCP/IP connections on port 5432?

[ERROR] connection to database failed: could not connect to server: No route to host
        Is the server running on host "10.10.10.50" and accepting
        TCP/IP connections on port 5432?

[NOTICE] promoting standby
[NOTICE] promoting server using '/usr/lib/postgresql/9.3/bin/pg_ctl -D /var/lib/postgresql/9.3/main promote'
[NOTICE] STANDBY PROMOTE successful.  You should REINDEX any hash indexes you have.

该db2节点现已提升为新的主节点，并且一切正常，直到db1节点重新启动。

在这种情况下，预计会db1成为新的备用节点，但事实并非如此，因为我最终让两个节点都充当主节点？！

所以我的问题是，故障转移后，如何防止两个节点都充当主节点（文档中说包括第三个节点作为见证节点 - 我有），但没有达到预期的效果。

这是我的 repmgr.conf 文件的一个示例：

cluster=test_cluster
node=1
node_name=db1
conninfo='host=10.10.10.50 dbname=repmgr user=repmgr'
master_response_timeout=60
reconnect_attempts=6
reconnect_interval=10
failover=automatic
promote_command='repmgr standby promote -f /etc/repmgr/repmgr.conf'
follow_command='repmgr standby follow -f /etc/repmgr/repmgr.conf'
pg_bindir=/usr/lib/postgresql/9.3/bin

db1节点恢复后的集群状态：

repmgr -f /etc/repmgr/repmgr.conf cluster show
Role      | Connection String
* master  | host=10.10.10.50 dbname=repmgr user=repmgr
* master  | host=10.10.10.60 dbname=repmgr user=repmgr
  witness | host=10.10.10.70 dbname=repmgr user=repmgr port=5499

非常感谢，
谨致问候

答案1

几个月前，我使用 repmgr 研究了自动故障转移。看来 repmgr 运行正常。

IIRC repmgr 不会将旧主节点作为新的备用节点启动，您需要运行--force standby clone。如果发生故障转移，您可以设置其他备用节点来跟随新的主节点（repmgr standby follow）。

  • 你会期望你的主人意外康复吗？
  • 您如何处理应用程序中的故障转移？
  • 您不是正在将所有数据库流量重定向到新的主服务器吗？

答案2

通常，将发生故障的主服务器作为备用服务器重新加入复制是可取的。首先，确保主服务器的 PostgreSQL 服务器不再运行；然后使用它将repmgr standby clone其数据目录与当前主服务器重新同步，例如：

repmgr -f /etc/repmgr/repmgr.conf --force --rsync-only  -h node2 -d repmgr -U repmgr --verbose  standby clone

这里必须使用命令行选项--force，以确保 repmgr 将重新使用现有的数据目录，和--rsync-only，这导致 repmgr 使用rsync而不是pg_basebackup，因为后者只能用于克隆新的备用。

然后可以重新启动节点。然后需要使用 repmgr 重新注册该节点；再次--force需要该选项来更新现有记录：

repmgr -f /etc/repmgr/9.5/repmgr.conf --force standby register

相关内容