pacemaker资源卡在unmanaged需执行pcs Resource manage；corosync authkey须为root:root/0400且二进制随机密钥；pcs cluster setup失败多因corosync进程残留或配置文件冲突；资源迁移延迟高需调低stickiness、增大batch-limit并检查cib同步。
pacemaker 资源不启动，crm_mon 显示 unmanaged 或 blocked
资源卡在 unmanaged 状态，说明 Pacemaker 主动放弃了对该资源的控制权——不是挂了，是“被停权”了。常见于手动执行过 crm_resource --cleanup 后忘记重新启用，或资源定义里写了 meta target-role=Stopped 却没改回来。
实操建议：
- 先查资源当前元属性：
pcs resource show <resource_name> --full</resource_name>，重点看target-role和is-managed两个字段 - 若
is-managed=false，立刻执行：pcs resource manage <resource_name></resource_name> - 若
target-role=Stopped，改回：pcs resource meta <resource_name> target-role=Started</resource_name> - 注意：修改后必须触发重计算（
pcs resource cleanup <resource_name></resource_name>），否则状态不会刷新
corosync 启动失败，日志报 Cannot initialize crypto layer
这是 Corosync 2.x+ 的经典加密初始化失败，根本原因几乎都是 /etc/corosync/authkey 权限不对或内容损坏。Corosync 要求该文件严格为 root:root、权限 0400，且必须是二进制随机密钥（不能是文本、不能带换行、不能用 base64 编码后直接存）。
实操建议：
- 检查权限：
ls -l /etc/corosync/authkey，如果不是-r--------. 1 root root，立刻修复：chmod 0400 /etc/corosync/authkey && chown root:root /etc/corosync/authkey - 确认内容是否有效：用
hexdump -C /etc/corosync/authkey | head -n 2看前几字节是不是乱码；如果是可读 ASCII，说明生成方式错了 - 正确生成方式只有一种：
dd if=/dev/urandom of=/etc/corosync/authkey bs=128 count=1（别用openssl rand或pwgen替代） - 所有节点 authkey 必须完全一致，复制时用
scp -p保留权限
pcs cluster setup 失败，提示 Unable to create corosync.conf
这个错误表面是配置写入失败，实际多因 Corosync 进程已在运行，或 /etc/corosync/corosync.conf 被其他工具（比如旧版 ccs 或手动编辑）锁住、格式错乱。Pacemaker 2.x 默认用 pcs 管理，但底层仍依赖 Corosync 原生配置，二者对文件格式敏感度不同。
实操建议：
- 先停掉所有相关服务：
pcs cluster stop --all，再确认corosync和pacemaker进程已消失（ps aux | grep -E "(corosync|pacemaker)"） - 备份并清空原配置：
mv /etc/corosync/corosync.conf /etc/corosync/corosync.conf.bak，然后删掉/etc/corosync/corosync.conf - 确保
/etc/corosync/目录属主是root:root，且无不可写子文件（如残留的.lock） - 重新运行
pcs cluster setup；若仍失败，加--debug看具体哪一行写入出错，大概率是 DNS 解析失败导致节点名无法 resolve
资源故障转移延迟高，crm_simulate 显示 transition delay 很大
这不是网络或硬件问题，而是 Pacemaker 内部状态机在等待“安全窗口”：默认启用 default-resource-stickiness 和 default-threshold 策略，加上资源迁移需跨节点同步 CIB（Cluster Information Base），若集群规模大或 CIB 变更频繁，就会排队等锁。
实操建议：
- 降低非关键资源的粘性值：
pcs resource defaults resource-stickiness=1（默认是INFINITY，等于禁止迁移） - 禁用不必要的监控间隔：比如 postgresql 资源若设了
monitor interval=10s，但实际健康检查要 8s，就容易堆积 pending transition - 检查
pcs Property set batch-limit=10是否过小（默认是1），适当调高能减少串行等待 - 真正影响延迟的是 CIB 同步耗时，可通过
corosync-quorumtool -s查看 quorum 投票延迟，超过 500ms 就得查网络抖动或防火墙丢包
复杂点在于：authkey 权限、CIB 锁竞争、资源 stickiness 三者会叠加放大问题，而日志里往往只报最表层现象。调试时别只盯一个错误码，得顺着 journalctl -u corosync -u pacemaker -n 100 往上翻三屏，找最早出现的 WARN 行。