DRBD脏节点需先执行disconnect、secondary、--force delete-md、create-md四步清空元数据，再由健康主节点用primary --force触发全量同步，过程中须用drbdsetup status监控进度。
drbdadm disconnect 后必须用 --force 才能弃用脏节点
当从节点因网络中断、IO错误或手动强制降级导致其 disk 状态变为 Outdated 或 Inconsistent，而主节点仍为 UpToDate 时，DRBD 默认拒绝重建——它会卡在 Connecting 或 StandAlone 状态，报错类似 Can not attach to outdated disk。此时不能直接 drbdadm connect，必须先断开并强制清除从节点的旧元数据。
操作顺序固定：先在**脏节点（计划丢弃数据的那台）**执行：
-
drbdadm disconnect r0—— 断开连接，进入StandAlone状态 -
drbdadm secondary r0—— 确保不是 Primary（否则下一步失败） -
drbdadm --force delete-md r0—— 强制删除本地元数据（⚠️此操作不可逆，原磁盘数据将被覆盖） -
drbdadm create-md r0—— 重建空元数据（仅初始化，不写业务数据）
做完这四步，该节点才真正“清白”，可作为干净的同步目标重新接入。
drbdadm primary --force 是触发全量重构的唯一入口
健康节点（即数据完好的那台）必须是当前 Primary 且 disk: UpToDate；脏节点完成上一步后处于 StandAlone 状态。此时，在**健康节点**上执行：
-
drbdadm connect r0—— 恢复网络连接（状态变WFConnection） -
drbdadm primary --force r0—— 关键动作：--force告诉 DRBD 忽略对端disk状态，以本机为基准发起全量同步（FullSync）
若省略 --force，DRBD 会检测到对端是 Outdated 并拒绝同步，日志里出现 Refusing to be Primary while peer is not UpToDate。注意：--force 只在首次重建时需要，后续正常同步不再需要。
同步过程中 watch drbdsetup status 而非 drbdadm status
drbdadm status r0 只显示角色和粗略状态（如 Primary/Secondary），无法反映同步进度。真正要看是否在跑全量重构，得用：
-
drbdsetup status r0 --statistics—— 查看rs-in-flight（正在同步的数据块）、out-of-sync（待同步字节数）是否从大值持续下降 -
watch -n1 'drbdsetup status r0 | grep -E "(role|disk|out-of-sync)"'—— 实时盯住关键字段变化
常见误判点：drbdadm status 显示 UpToDate/Outdated 是初始状态，不代表同步已完成；只有 out-of-sync: 0 且 rs-in-flight: 0 才算真正完成。同步速率受 syncer { rate; } 配置限制，默认可能只有几 MB/s，大容量盘需耐心等待。
protocol C 下全量重构会阻塞主节点写入吗
不会完全阻塞，但有显著影响。protocol C 要求每次写入都等对端落盘成功，而全量重构本身是大批量顺序写，会抢占磁盘 IO 和网络带宽。结果是：
- 主节点应用写入延迟明显升高（
latency spikes），尤其小文件随机写场景 - 同步速度反而可能下降（因与业务 IO 争抢资源）
- 若未配置
syncer { al-extents; }，AL（Activity Log）频繁刷盘会进一步拖慢
生产环境建议：避开业务高峰执行重构；或临时调高 syncer { rate 2G; } 加速完成，但需确认网络和磁盘能承受；重构完成后务必恢复合理限速值，避免长期压垮链路。
真正麻烦的不是操作步骤，而是判断“哪个节点数据可信”——DRBD 不自动仲裁，全靠人眼确认 drbdsetup status --verbose 中每个节点的 disk 和 peer-disk 字段。一旦选错基准节点，就是把坏数据同步给好节点。
