心跳检测失败时日志报“Cannot initialize crypto”是密钥不匹配或权限错误所致；authkey须用corosync-keygen生成、权限400且root:root属主、各节点完全一致；crm_mon -1显示offline而pcs status显示active是因二者查询层级不同，前者反映真实运行态；DRBD切换后挂载点残留需显式配置RA并禁用静态fstab；move迁移后资源不回原节点是因cli-prefer约束未清除，应手动remove或改用ban命令。
心跳检测失败时，corosync 日志里反复出现 ERROR: Cannot initialize crypto
这是密钥不匹配或权限错误的典型表现，不是配置语法问题。Corosync 启动时会校验 /etc/corosync/authkey 的完整性与可读性，但不会明确告诉你缺了哪一环。
-
authkey必须由corosync-keygen生成，手动生成的二进制文件（比如用dd或openssl rand）大概率触发该错误 - 该文件权限必须是
400，且属主为root:root；任何组/其他用户可读都会被拒绝加载 - 所有节点上的
authkey必须完全一致——复制时别用scp -p，它可能保留源端时间戳但改不了权限，建议手动chmod 400再验证
crm_mon -1 显示资源 offline，但 pcs status 却显示 active
这不是状态不一致，而是两个命令查的是不同层级：前者看 Pacemaker 实际调度结果，后者看 pcs 自己缓存的配置快照。真实运行态以 crm_mon -1 为准。
- 常见诱因是资源代理（RA）脚本退出码异常，比如
ocf:heartbeat:IPaddr2在绑定 VIP 失败时返回OCF_ERR_GENERIC（即 1），Pacemaker 会标记为 failed 并尝试迁移，但pcs status还没刷新 - 检查具体资源日志用
journalctl -u pacemaker --since "2 hours ago" | grep -A5 -B5 "resource-name"，别只盯pcs status输出 - 若频繁发生，确认网卡是否存在
NOARP设置冲突，或内核参数net.ipv4.conf.all.arp_ignore是否干扰了 VIP 响应
DRBD 主从切换后，mount 挂载点残留导致服务启动失败
DRBD 状态切换本身不触发文件系统卸载，Pacemaker 也默认不自动 umount —— 它只管调用 RA 脚本里的 stop 方法，而很多 RA 并未在 stop 阶段做清理。
- 务必在资源定义中显式添加
meta is-managed=true allow-unmanaged-disk=false，否则 Pacemaker 可能跳过磁盘状态校验直接启动服务 - 推荐用
ocf:heartbeat:FilesystemRA 替代裸mount命令，并设置op start timeout=60s on-fail=fence，避免挂载卡住拖垮整个 failover 流程 - 切忌在
/etc/fstab里静态声明 DRBD 设备，Pacemaker 不会读它，反而会在 reboot 后造成设备忙（busy）无法接管
使用 pcs resource move 强制迁移后，资源回不去原节点
这是因为 move 实际是给资源加了临时位置约束（cli-prefer- 开头的 constraint），它不会自动清除，也不会被 pcs resource cleanup 删除。
- 查看残留约束用
pcs constraint location show --full，里面带cli-prefer-前缀的就是手动 move 留下的 - 清除指定资源的临时约束：
pcs constraint remove cli-prefer-resource-name（注意替换 resource-name） - 更稳妥的做法是不用
move，改用pcs resource ban --node node1 resource-name，它生成的是时效性约束，默认 30 分钟后自动失效
高可用运维最耗时间的往往不是配置写对，而是这些“看起来动了、其实没生效”或“动过了、但没清干净”的中间态。每次操作后，多看一眼 crm_mon -1 和 pcs constraint location show，比反复重启服务有用得多。
