web-dev-qa-db-ja.com

DRBDノードを接続状態のStandAlone（およびWFConnection）から抜け出す方法は？

私のDebian 8.9 DRBD 8.4.3セットアップは、どういうわけか2つのノードがネットワーク経由で接続できなくなった状態になりました。単一のリソース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

2番目のノード：

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

2つのノードは、/etc/drbd.d/r1.resで引用されたIPアドレスを介して相互にpingできます。netstatは、両方が引用されたポートでリッスンしていることを示しています。

2つのノードが Connected になり、DRBDを介して再度複製できるようにするには、どうすれば（さらに診断して）この状況から抜け出すことができますか？

ところで、抽象化のレベルが高い場合、この問題は現在systemctl start drbdで立ち往生しているために終了しないdrbdadm wait-connect allによって明らかになります（/lib/systemd/system/drbd.serviceで示唆されているように）。

debiandrbdlinux-ha
4
rookie09

状況は明らかにスプリットブレインのケースによって引き起こされました。

drbd.service（Sudo journalctl -u drbd）の最近のジャーナルエントリのみを調査したため、これに気づかなかったが、問題は明らかに他のカーネルログおよび少し前の（Sudo journalctl | grep Split-Brain）で報告された。

これにより、スプリットブレインを手動で解決すると（ here または here のように）、問題のある状況が次のように解決されました。

スプリットブレインの犠牲者（DRBDリソースがr1であると想定）：

drbdadm disconnect r1
drbdadm secondary r1
drbdadm connect --discard-my-data r1

スプリットブレインの生存者について：

drbdadm disconnect r1
drbdadm primary r1
drbdadm connect r1
10
rookie09