DRBD仅负责块级数据同步，不提供故障转移能力；自动切换必须由Pacemaker等集群管理器通过OCF脚本封装drbdadm promote操作实现，且需严格配置protocol C、克隆资源及Master约束。
DRBD 本身不负责故障转移，它只做数据同步；自动切换必须靠 Heartbeat 或 Pacemaker 管理资源状态和角色升降级。直接把 DRBD 设备挂载后写数据，主节点宕机时从节点仍处于 Secondary 状态，无法自动接管——这是最常被忽略的前提。
DRBD 资源必须注册进集群管理器才能触发自动升降级
Heartbeat 和 Pacemaker 都不能“感知” DRBD 状态变化，它们依赖你显式定义一个 drbd 类型的资源，并绑定其主从关系（master-slave）。
- Heartbeat 时代用
haresources文件声明drbd::r0 Filesystem::/dev/drbd0::/data::ext4，但这种方式已淘汰，不支持动态角色切换 - Pacemaker（推荐）必须用
pcs resource create创建带master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true的ms_drbd克隆资源 - 关键点：DRBD 资源名（如
r0）必须和/etc/drbd.d/r0.res中的resource r0 { ... }完全一致，否则pcs启动失败并报错DRBD status unknown - pacemaker 不会自动调用
drbdadm primary r0，它只通过 OCF 脚本ocf:linbit:drbd封装的start/promote操作来完成，所以必须确保该脚本存在且可执行
协议 C + 同步块设备是自动切换的前提条件
如果 DRBD 配置成协议 A（异步），主节点崩溃瞬间未同步到从节点的数据就永久丢失，此时即使 Pacemaker 把从节点升为 Primary，数据也不一致——自动切换反而放大风险。
- 检查当前配置：
cat /etc/drbd.d/r0.res | grep -A5 "syncer"，确认含protocol C; - 同步模式下，
drbdadm adjust r0后执行drbdadm cstate r0应返回Connected，drbdadm role r0在主节点显示Primary/Secondary，从节点为Secondary/Primary - 若
cstate是WFConnection或StandAlone，Pacemaker 会拒绝 promote，日志中出现not connected to peer - 不要在未同步完成时强行
pcs resource enable，否则资源反复尝试 promote/fail，填满/var/log/cluster/corosync.log
Heartbeat 与 Pacemaker 的资源依赖链写法差异极大
Heartbeat 的 haresources 是线性顺序执行，而 Pacemaker 的约束是显式声明的，漏掉任一环都会导致切换卡住。
- Heartbeat（已过时）：一行写死顺序，例如
node1 IPaddr::192.168.1.100/24/eth0 drbddisk::r0 Filesystem::/dev/drbd0::/data::ext4 mysqld，其中drbddisk必须在Filesystem前启动 - Pacemaker（必需）：需三步约束 ——
pcs constraint colocation add fs-data-with-drbd inf: fs-data ms-drbd:Master（位置约束）、pcs constraint order promote ms-drbd then start fs-data（顺序约束）、pcs constraint order start fs-data then start mysqld - 常见错误：忘记加
:Master后缀，导致 Pacemaker 把ms-drbd当普通克隆资源处理，不会触发promote操作 - 验证约束是否生效：
pcs constraint show --full，输出中应含Master字样和score=INFINITY
真正难调试的不是 DRBD 同步本身，而是 Pacemaker 对 ms-drbd 的 promote 超时判定和 STONITH 配置冲突——比如网络抖动时 corosync 认为节点失联，但 STONITH 未能成功 fence，Pacemaker 就会卡在“等待旧主释放资源”状态，此时 pcs status 显示 unmanaged 或 blocked，而不是直观的错误信息。
