存储主备切换需确保DRBD状态同步（UpToDate/UpToDate）、角色变更与挂载强绑定（仅Primary节点可mount）、VIP漂移与存储切换联动，并统一分区路径、文件系统类型及挂载点目录。

存储层面的主备切换，核心目标是让业务在主节点故障时，能快速、安全地在备节点挂载同一份数据卷并继续服务。这不单是“换个节点挂载”，而是一整套协同机制——既要确保数据一致性，又要避免挂载冲突和脑裂。

确保 DRBD 设备状态严格同步

DRBD 是块级主备同步的常用方案，挂载前必须确认其复制状态已就绪：

• 主节点执行 drbdadm role r0 应返回 Primary/Secondary；备节点应为 Secondary/Primary
• 两节点均执行 drbdadm status r0，同步状态必须显示 UpToDate/UpToDate（非 Inconsistent 或 OutOfDate）
• 若显示 SyncSource 或 SyncTarget，说明仍在同步中，此时挂载会导致数据不完整或写入失败

挂载动作必须与角色变更强绑定

挂载不是独立操作，它只允许发生在被提升为主角色的节点上，且需前置校验：

• 仅在成功执行 drbdadm primary r0 后，才可对 /dev/drbd0 执行 mount
• 备节点严禁提前挂载——即使设备可见，也必须保持 unmounted 状态，否则触发 DRBD 的 disk { on-io-error detach; } 保护机制，导致连接中断
• 建议在切换脚本中将 drbdadm primary → mkfs（首次）→ mount 串成原子步骤，避免人工遗漏格式化或挂载

通过 Keepalived 实现 VIP + 挂载联动

应用不直接访问物理节点 IP，而是连向浮动 VIP。挂载高效的关键在于 VIP 漂移与存储角色切换同步：

• Keepalived 的 vrrp_script 必须检测 drbdadm role r0 | grep Primary，而非仅 ping 或端口存活
• 当 VIP 漂移到备节点时，notify_master 脚本应包含：
  　　→ drbdadm primary r0
  　　→ mount /dev/drbd0 /data
  　　→ 启动业务服务（如 Neo4j、GitLab）
• 同理，原主节点降级时，notify_backup 脚本应执行：
  　　→ umount /data
  　　→ drbdadm secondary r0

规避常见挂载失败点

很多“切换后无法挂载”问题其实源于前期配置疏漏：

• 两节点裸分区路径必须完全一致（如都是 /dev/sdb1），DRBD 不接受别名或符号链接
• 文件系统类型需统一：主节点用 mkfs.xfs 格式化后，备节点不可再尝试 mkfs.ext4；首次格式化只在主节点做一次
• 挂载点目录（如 /data/neo4j）需在两节点预先创建，权限一致，但内容无需同步——由 DRBD 块层保证