Corosync 连接失败如何通过日志定位与修复？

Corosync 是 Pacemaker 高可用集群的底层消息与成员关系层，当它发生连接失败时，即使上层资源看起来仍在本机运行，集群也可能进入分裂状态。排查这类问题时，直接查看 Corosync 自身的日志是最有效的方式，因为大多数连接失败都会在日志中留下 TOTEM、FAILED TO RECEIVE、Token was lost 等关键字。本文围绕日志现象、状态命令和配置修复三个层面展开，帮助快速恢复节点间的稳定通信。

一、从日志中识别连接失败的关键信号

Corosync 的日志通常写入 /var/log/corosync/corosync.log，如果系统使用 journald，也可以用 journalctl -u corosync -f 持续查看。日志是否详细取决于 /etc/corosync/corosync.conf 中 logging 段的 logfile_priority 设置，建议至少在排查阶段把级别调整为 debug，这样可以看到 TOTEM 协议在成员协商过程中的重传和超时记录。日志文件本身不会主动清理，可以放心保留几天数据用于时间线对照。

连接失败的典型日志关键字包括 FAILED TO RECEIVE、TOTEM Retransmit List、Token was lost、A processor failed, forming new configuration 以及 sync member left。如果日志中频繁出现 retransmit 字样，通常说明节点发出的组播或单播消息没有按时到达其他节点，于是协议层启动重传，重传次数过多最终会导致成员被移除。如果看到 Token was lost 和 forming new configuration，则往往与 token 超时、CPU 饥饿或网络瞬时中断有关，需要结合系统负载和交换机日志一起判断。

下面这条命令可以快速过滤最近一小时内的关键错误，适合在节点刚掉线时使用：

journalctl -u corosync --since "1 hour ago" | grep -E 'FAILED|retransmit|Token|processor failed'
# 如果使用 corosync.log
grep -E 'FAILED|retransmit|Token|processor failed' /var/log/corosync/corosync.log

需要注意的是，单行日志只能说明协议层发生了问题，不能直接判定根因。比如 FAILED TO RECEIVE 在组播模式下可能是交换机没有转发组播流量，在单播模式下可能是防火墙丢弃了某条 UDP 报文，因此下一步要通过状态命令确认当前链路模式以及节点是否仍留在 ring 中。

二、定位连接失败根因的常用命令与排查顺序

先确认本节点当前在 Corosync 中的 ring 状态，推荐使用 corosync-cfgtool -s。该命令会打印 ring ID、状态以及所有已知成员地址。如果只能看到本机，其他节点完全不出现，基本可以判定是网络层不通，而不是上层投票逻辑问题。另一个常用命令 corosync-quorumtool -s 可以查看 quorum 是否满足，两节点集群如果 quorum 不满足，资源会被 fence 或者进入停止状态。

corosync-cfgtool -s
corosync-quorumtool -s

接着检查本地监听端口与网络地址。Corosync 默认使用 UDP 5405 作为 totem 协议端口，5404 用于旧版或部分通信场景。执行 ss -lunp | grep -E '5404|5405' 可以看到进程是否正常监听。然后用 ip addr show 核对 bindnetaddr 对应的网段是否与实际网卡一致。很多连接失败的根因并不是防火墙，而是 bindnetaddr 配置成了具体主机地址或者写错了网段，导致 Corosync 没有在预期接口上绑定。

ss -lunp | grep -E '5404|5405'
ip addr show
cat /etc/corosync/corosync.conf

如果状态命令和端口都正常，但仍看不到其他节点，可以在两台节点上同时抓包。下面命令假设组播端口为 5405，抓取本机所有接口上的 UDP 5405 报文。若源节点有大量发送而无接收，说明流量被中间设备丢弃；若目标节点完全看不到报文，则要检查交换机是否启用 IGMP snooping 或是否允许该组播地址。

tcpdump -i any -nn udp port 5405

有一个容易忽略的点：云主机、部分虚拟化平台默认禁止二层组播，即使配置了 mcastaddr 也无法建立稳定连接。此时日志不会明确提示组播不可用，只表现为间歇性 retransmit 和成员反复加入退出。判断方法是切换为 udpu 单播传输后是否立刻恢复。若恢复，则说明原链路不适合组播，应保留单播配置。

三、典型连接失败的修复方案

第一种常见修复是修改 bindnetaddr。注意该字段要求填写接口所在的网络地址，而不是某个节点的 IP。例如节点 IP 为 192.168.1.10/24，那么网络地址应写 192.168.1.0，而不是 192.168.1.10。配置片段如下：

totem {
    version: 2
    secauth: off
    interface {
        ringnumber: 0
        bindnetaddr: 192.168.1.0
        mcastaddr: 226.94.1.1
        mcastport: 5405
        ttl: 1
    }
}
logging {
    to_logfile: yes
    logfile: /var/log/corosync/corosync.log
    logfile_priority: debug
    to_syslog: yes
}

第二种情况是交换机、云环境或跨网段链路不允许组播，这时需要改为单播传输。单播依赖 nodelist 明确列出每个节点的 ring0_addr 和 nodeid。配置片段如下，transport 必须设为 udpu，nodeid 在所有节点上要唯一。

Corosync日志连接失败高可用集群修改时间：2026-08-29 01:54:26