Motoharu Kubo
mkubo****@3ware*****
2015年 2月 17日 (火) 23:15:55 JST
Fork久保です。
>> なお、貼り付けていただいたログの範囲内では、スプリットブレインは起こって
>> いません。単に一時的にネットワーク障害か何かの原因で、レプリケーションが
>> 途切れただけです。
> セカンダリ側のログがプライマリの内容になっていました。申し訳ございません。
> 以下の「Split-Brain detected but unresolved, dropping connection!」より
> スプリットブレインと判断しました。
なるほど。たしかに18:00:27にSplit-Brain...が表示されていますね。
時系列に追いかけると、次のような状態になっていたことになります。
18:00:05頃 ネットワークの通信障害が起きて両ノードのDRBDはともにいったん
接続を切って、再度相手との接続待ちに入った。
その後ネットワーク障害が続き、両ノードとも相手との接続待ち状
態のまま待ち続けることになってしまった(WFConnection)
18:00:26頃 セカンダリ側のCorosync/Pacemakerがフェールオーバすることを決
断。server2のPacemakerはDRBDをプライマリに昇格させた。DRBDは
相手とのコネクションが切れたままなので、実際にプライマリに切
り替わった(role(Secondary -> Primary))。
たまたまプライマリに切り替わった直後に、両ノード間の通信が可
能になった(Handshake successful)。
この時点でserver1とserver2の両方が、相手と無関係にプライマリになってしま
い、スプリットブレインが発生してしまったわけです。
ただし実際にDRBDがスプリットブレインを検出するには、相互のコネクションが
再度確立する必要があり、18:00:27にSplit-Brain ....が表示されました。
原因は、ネットワークの疎通が一時的になくなっていたことです。これは、cs:
(ログではconn)がWFConnectionの状態が20秒近く続いたことから明らかです。
ネットワークの疎通が正常な場合、WFConnection->WFReportParams->....という
状態遷移が通常1秒以下のうちに進み、Connectedになるはずです。
正常に動作していたときのログのconn(...)の遷移を追いかけて比較するとよく
わかるんじゃないかと思いますよ。
--
久保 元治 (株)サードウェア