我的 Debian 8.9 DRBD 8.4.3 设置不知何故进入了两个节点无法再通过网络连接的状态。它们应该复制单个资源r1，但紧接着drbdadm down r1; drbadm up r1两个节点上的/proc/drbd情况如下：
在第一个节点上（连接状态为 或WFConnection）StandAlone：
1: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown C r-----
ns:0 nr:0 dw:0 dr:912 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:20
在第二个节点上：
1: cs:StandAlone ro:Secondary/Unknown ds:UpToDate/DUnknown r-----
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:48
两个节点可以通过 中引用的 IP 地址互相 ping 通/etc/drbd.d/r1.res，并netstat表明两个节点都在监听引用的端口。
我怎样才能（进一步诊断并）摆脱这种情况，以便两个节点能够成为连接的并再次通过 DRBD 复制？
顺便说一句，在更高的抽象层次上，这个问题目前表现为systemctl start drbd永远不会退出，显然是因为它卡在了那里drbdadm wait-connect all（如所建议的那样/lib/systemd/system/drbd.service）。
答案1
这种情况显然是由脑裂引起的。
我没有注意到这一点，因为我只检查了drbd.service（sudo journalctl -u drbd）的近期日记条目，但该问题显然已在其他内核日志中以及稍早的（sudo journalctl | grep Split-Brain）中得到报告。
这样，手动解决裂脑问题（如上所述这里或者这里) 也解决了这个麻烦的情况，如下所示。
对于裂脑受害者（假设 DRBD 资源为r1）：
drbdadm disconnect r1
drbdadm secondary r1
drbdadm connect --discard-my-data r1
关于裂脑幸存者：
drbdadm primary r1
drbdadm connect r1
答案2
我使用以下模式：在故障节点（不是当前 DC）上运行电脑状态）
drbdadm dump all
drbdadm disconnect resource
drbdadm secondary resource
drbdadm connect resource
在健康节点（即当前 DC）上运行电脑状态）
drbdadm dump all
drbdadm disconnect resource
drbdadm primary resource
drbdadm connect resource