Tatsuya Watanabe
tatsu****@gmail*****
2013年 8月 26日 (月) 09:56:42 JST
渡辺です。おはようございます。 > ちなみに、同期がNGかどうか、はｄｒｂｄのログ（あるか > どうかもわかっていませんが。。。）を見ればわかります > か？ 現時点での状態を確認したいのであれば、cat /proc/drbd コマンドを 実行してみて、csがConnectedでdsがUpToDate/UpToDateであれば、 同期が取れています(厳密には後述のケース3のような場合もありますが)。 障害時に同期が取れていたのかを後からログで確認したいのであれば、 少し手間がかかりますが、障害発生時点からさかのぼって一番直近にある conn(接続状態)やdisk(自ディスク状態)、pdsk(peerのディスク状態)が 以下の状態に合致するか確認してみてください。 左側が状態変化前(色々な状態がありそうなのでxxxxとしています)、 右側が状態変化後ですので、右側だけ確認すれば問題ありません。 conn( xxxx -> Connected ) disk( xxxx -> UpToDate ) pdsk( xxxx -> UpToDate ) どれかひとつでも異なるようであれば同期されていない可能性が ありますので全て確認してください。また、Primaryが突然落ちて しまったような場合もありますので、両系で確認してみてください。 ちなみに、プロトコルCを使っているにもかかわらず、プライマリで作成した データがフェイルオーバ後に書き込まれていなかったという今回の事象の 原因について、私が思いついたのは以下のケースです。 ケース1： DRBDのコネクションが切れた状態でPrimary側だけにデータが書き込まれ、 その後、Primaryがクラッシュしてフェイルオーバした場合。 このケースでは、上記のログの確認では、connがUnconnectedになっていると思います。 ただし、fence-peerスクリプト(下記URL参照)が適切に設定されていれば、 Pacemakerの制約によりSecondary側の昇格が抑止され、データ喪失は防がれます。 (その代わりフェイルオーバはしませんが・・・) fence-peerスクリプトについて http://www.drbd.jp/users-guide/s-pacemaker-fencing.html ケース2： PrimaryからSecondaryへの同期中にPrimaryがクラッシュしてフェイルオーバした場合。 このケースでは、pdskがInconsistentになっていると思います。 ケース3： DRBDは同期が取れていると思っている(dsがUpToDate/UpToDate)にもかかわらず、 実際には下位デバイスのブロック間でプライマリとセカンダリに差分が生じてしまっている場合。 これは、オペレーションミス(例えばDRBDが起動していないのにDRBDで使用する パーティションをマウントしてファイルを作成した場合や、ブロックデバイスにddなどで 直接書き込んだ場合)、DRBD-8.3.13以前であったバグ(プロトコルAでbarrier設定を 行っている場合)などで発生します。 この事象を検出する方法については以下のURLなどを参照してください。 http://www.drbd.jp/users-guide/s-use-online-verify.html その他、8.3.11を使用されていることに起因する何らかのバグを踏んでいる可能性もありますので、 バグフィックスされている最新バージョンの8.3.15 (もうすぐ8.3.16が出そうな雰囲気ですが)を 使用されることをお勧めします。 以上、よろしくお願いします。 -------------- next part -------------- HTMLの添付ファイルを保管しました...Descargar
Fork