节点被标记为 blocked 是 pacemaker 主动拒绝其参与投票或调度的信任标记，需先修复 corosync 通信、fencing 状态或清除 inhibit 标记（如 pcs node unclean nodex），再同步集群配置，而非简单重启服务。
直接解除 Pacemaker 中被阻断（blocked）状态的节点，不能靠 pcs cluster start 或重启服务——它本质是集群对节点“不信任”的标记，必须先清除阻断原因、再显式解除状态。
为什么节点会进入 blocked 状态
节点被标记为 blocked 通常不是因为宕机，而是 Pacemaker 主动拒绝其参与投票或资源调度，常见触发点包括：
- Corosync 成员关系异常：比如
corosync进程未运行、心跳网段不通、bindnetaddr配错导致无法加入 quorum - 节点曾因隔离（fencing）失败而被挂起，但 fencing 设备未真正执行或未反馈成功
- 手动执行过
pcs node ban或pcs resource unmanage后未清理，残留了 inhibit 标记 -
pcs status显示Online: [ node1 node2 ]但某节点实际在crm_mon -1中显示blocked，说明 CIB 记录与本地状态不一致
检查 blocked 节点的真实状态和原因
先确认是不是真被 block，以及 block 的来源：
- 运行
pcs status --full，查找含blocked字样的行，注意看是节点名后标blocked，还是某个资源实例显示Blocked - 查 Corosync 实时成员视图：
corosync-cfgtool -s，输出中Membership information下该节点状态是否为Member；若为Lost或空白，说明底层通信已断 - 查日志定位源头：
journalctl -u corosync -n 100 --no-pager | grep -i "block\|fence\|quorum"，重点关注fence_node: nodeX failed或Quorum lost类错误 - 确认 fencing 是否卡住：
pcs stonith show查设备配置，再用pcs stonith cleanup nodeX尝试清除 fencing 挂起状态（仅当 fencing 已实际完成但未上报时有效）
解除 blocked 状态的实操步骤
解除动作分两层：先修复底层通信或 fencing 状态，再刷新集群认知。顺序错了会反复 block：
- 如果
corosync-cfgtool -s显示节点不在成员列表中：先确保corosync进程运行（systemctl start corosync），再检查/etc/corosync/corosync.conf中bindnetaddr是否为心跳网段网络地址（如网卡是192.168.31.186/24，则必须填192.168.31.0，不是0.0.0.0或本机 IP） - 如果 fencing 失败残留：
pcs stonith cleanup nodeX，然后立刻验证 fencing 可达性：pcs stonith fence nodeX（测试用，需确保 fencing 设备真实可用） - 如果节点在线但 CIB 误标 blocked：
pcs node unclean nodeX—— 这是关键命令，它清除节点的 inhibit 标记并重置其状态为未知，后续 Pacemaker 会在下一轮选举中重新接纳 - 最后强制同步状态：
pcs cluster sync（确保所有节点 CIB 一致），再等 30 秒观察pcs status是否变为Online
容易被忽略的细节
blocked 状态常被当成“服务没起来”去 restart pacemaker，但真正卡点往往在更底层：
-
pcs node unclean不等于pcs cluster start：前者改 CIB 标记，后者只拉起本地进程；若 Corosync 本身不通，unclean后仍会立刻 re-block - 双节点集群无仲裁设备时，
quorum默认策略可能拒绝单节点运行，导致节点即使在线也被 block；此时需临时调no-quorum-policy=ignore（仅调试用，生产慎开） - 某些云环境（如 Azure）中，
blocked实际是平台维护导致的网络抖动引发，corosync日志会出现Token has not been received in 30000 ms，这种情况下等网络恢复比硬操作更稳妥
