主节点重启后配置异常引发脑裂问题求助

针对你遇到的2主2从经典复制架构下的脑裂问题，可从以下几个方面排查：

• 集群通信配置验证
  检查所有节点的cluster-connection配置，确认：

  • 配置了正确的connector-ref，指向节点对外通信的连接器；
  • 静态集群成员列表（static-connectors）包含所有节点的连接器地址，或广播/发现组（broadcast-groups/discovery-groups）在Windows环境下正常工作（Windows多播可能需开放防火墙，或改用静态发现避免多播依赖）；
  • 集群通信端口（默认如5445）未被防火墙拦截，节点之间能互相ping通并建立连接。

• HA组标识与配对配置
  确认原master和对应的slave节点配置了相同的group-name（在ha-policy的replication节点下）。group-name用于标识同一HA组的节点，若配置不一致，重启后的原master会认为自己属于独立HA组，从而启动为master。

• master节点的活跃检测逻辑
  你已配置<check-for-live-server>true</check-for-live-server>，需验证：

  • 原master重启时，是否能通过集群通信检测到已升级为master的原slave；
  • Windows环境下，Artemis的进程检测机制是否正常工作——若依赖进程ID检测，强制杀死的进程可能残留无效PID，导致检测失效，可尝试启用基于网络的检测（确保节点间通信正常）。

• failback机制的触发条件
  slave节点配置了<allow-failback>true</allow-failback>，但failback需要：

  • 原master与当前master（原slave）之间通信正常；
  • 当前master未处理过无法回滚的事务或消息。
    若通信中断，原master无法触发failback流程，会直接启动为master，引发脑裂。

• 存储状态一致性检查
  原master被强制杀死后，本地data目录可能处于不一致状态。重启前需确认：

  • 原master的data目录是否保留了故障前的状态，导致它无法识别新master的最新数据；
  • 是否配置了clean-shutdown（默认开启），强制杀死进程会导致非干净关闭，存储元数据可能损坏，需删除data目录后再重启（注意备份数据）。

• 日志分析
  查看原master和新master的启动日志，重点关注：

  • 集群发现阶段的日志，是否有“无法发现集群节点”“连接被拒绝”等错误；
  • HA状态切换的日志，原master启动时是否检测到活跃master，新master是否收到原master的连接请求。

内容的提问来源于stack exchange，提问作者Katya Gorshkova