Corosync 启动失败主因是 bindnetaddr 配置为具体IP而非网段地址（如192.168.1.0）及 quorum.provider 缺失或错误；Pacemaker 资源不切换需先确认 crm_mon 中 Quorum 为 Yes，两节点集群须配 expected_votes: 2 和 auto_tie_breaker: 0；QDevice 失效常因证书未同步或节点与 qnetd 时间不同步。
Corosync 启动失败：检查 corosync.conf 语法和绑定地址
Corosync 启动即退出或日志里反复出现 Cannot initialize interface，大概率是配置文件写错。最常踩的坑是 bindnetaddr 设成了具体 IP（比如 192.168.1.10），而它实际需要填的是「所在网段的网络地址」（如 192.168.1.0）——Corosync 会自动探测该网段下可用的本机接口。
另一个高频问题是 quorum.provider 缺失或拼错。现代 Corosync（3.x）默认用 qdevice 或 corosync-qnetd，但若没配仲裁设备，必须显式写 provider: corosync_votequorum，否则服务起不来。
- 用
corosync-cfgtool -s查看当前识别的接口和网络状态 - 用
corosync-cfgtool -t校验/etc/corosync/corosync.conf语法（注意不是corosync -f -e，后者已弃用） - 确保所有节点的
nodeid唯一且为非零正整数，不要用主机名或 UUID 替代
Pacemaker 资源不切换：确认 crm_mon 显示的 quorum 状态
Corosync 只管通信和成员管理，真正做故障转移的是 Pacemaker。如果节点宕机后资源没自动漂移，先别急着调 pcs resource move，先看 crm_mon -1 输出里 Quorum: 是否为 Yes。Quorum 丢失（No）时 Pacemaker 会主动停掉所有资源，这是安全机制，不是 bug。
两节点集群尤其容易掉 Quorum：默认 two_node: 1 并不等价于“允许双机无仲裁运行”，它只是启用两节点优化，仍需配合 expected_votes: 2 和 auto_tie_breaker: 0 才能避免脑裂停服。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 查实时状态：
pcs status比crm_mon更直观，会标出Quorum:行 - 临时恢复 Quorum（仅调试用）：
pcs quorum unblock，但生产环境必须配qdevice或奇数节点 - 不要依赖
no-quorum-policy=ignore，它绕过保护逻辑，可能引发双主写冲突
QDevice 仲裁失效：检查 qnetd 证书同步和端口连通性
加了 qdevice 还是频繁失联？常见原因是证书没更新或时间不同步。qnetd 要求所有节点与仲裁服务器之间 NTP 时间差 pcs qdevice sync-certificates 主动拉取最新证书，不能只靠首次初始化。
另外，qnetd 默认监听 22222/tcp，但很多用户只开了防火墙的 corosync 端口（5404/5405 udp），忘了放行这个 TCP 端口，导致心跳包超时断开。
- 验证连接：
curl -k https://qnetd-host:22222/health应返回{"status":"ok"} - 查证书有效期：
openssl x509 -in /etc/corosync/qnetd-certs/qnetd.crt -text -noout | grep Not - 强制重同步证书：
pcs qdevice sync-certificates --debug（加--debug看具体哪步卡住）
服务启动顺序错误：确保 corosync 先于 pacemaker 启动且设为依赖
Systemd 下如果手动 systemctl start pacemaker，而 corosync 还没 ready，Pacemaker 会报 Could not connect to cluster infrastructure 并退守 standby。这不是配置问题，是依赖关系没声明。
新版 pcs 初始化集群时会自动写好 Wants=corosync.service 和 After=corosync.service，但如果手工改过 service 文件、或用旧版脚本部署，很可能漏掉。别信 systemctl enable pacemaker 自动处理依赖——它只管开机自启，不管启动时序。
- 检查依赖：
systemctl list-dependencies --reverse pacemaker应含corosync.service - 手动修复：
systemctl edit pacemaker，插入[Unit] After=corosync.service Wants=corosync.service
- 永远用
pcs cluster start --all启集群，而不是分别起两个服务
corosync.log 里每条 INFO 级以上的消息，比翻文档更快定位真实瓶颈。 
