DRBD故障转移后节点卡在WFBitMapS/Connected状态如何解决？

异常状态含义 #

你遇到的两个节点状态分别代表如下含义：

• 当前主节点（故障转移后升主的原从节点）输出0:r0/0 WFBitMapS Primary/Secondary UpToDate/Consistent：
  • WFBitMapS是Wait For BitMap Sender的缩写，代表当前节点正在等待对端发送数据位图，用于计算两端差异数据的增量同步范围
  • 磁盘状态UpToDate/Consistent表示本地数据为最新有效状态，对端刚恢复上线的节点数据处于一致但未校验有效性的状态
• 当前从节点（恢复上线的原主节点）输出0:r0/0 Connected Secondary/Primary Negotiating/UpToDate：
  • Negotiating表示该节点正和对端主节点协商同步参数、校验数据位图，但协商流程卡住无法推进
  • 磁盘状态Negotiating/UpToDate表示本地数据为最新状态，但和对端的同步协商流程未完成

触发原因 #

该问题是DRBD 8.9.x版本适配大容量磁盘的常见问题，核心触发原因有3个：

• DRBD 8.9.10存在已知内核层bug，针对4TB以上的大容量磁盘，位图协商的默认超时时间过短，大体积位图还没完成传输就被超时中断，导致协商流程循环重试无法推进
• DRBD配置中未适配大容量磁盘的活动日志参数，默认的活动日志扩展块数量不足以支撑6.7TB磁盘的位图校验，导致两端数据差异对比流程卡住
• 未配置故障转移节点回归的fence策略，原主节点恢复后检测到对端已经处于Primary状态，出现角色协商冲突，无法自动触发同步流程

修复方案 #

永久修复 #

修改两台节点的/etc/drbd.conf配置，对应资源块或全局common块添加以下参数：

common {
    net {
        timeout 180;
        ping-int 10;
        ping-timeout 15;
        max-buffers 36864;
        max-epoch-size 8192;
    }
    disk {
        al-extents 6433;
    }
    handlers {
        fence-peer "/usr/lib/drbd/crm-fence-peer.9.sh";
        after-resync-target "/usr/lib/drbd/crm-unfence-peer.9.sh";
    }
    startup {
        wfc-timeout 120;
        degr-wfc-timeout 120;
        outdated-wfc-timeout 120;
    }
}

配置修改完成后，在两台节点执行drbdadm adjust r0加载新配置即可，后续故障转移不会再复现该问题。

临时应急方案 #

如果后续再出现该卡滞状态，不需要重启整个从节点，执行drbdadm disconnect r0 && drbdadm connect r0手动重连DRBD资源即可触发正常同步。

内容的提问来源于stack exchange，提问作者oT2