YUKI Piro Hiroshi
null+****@clear*****
Thu May 8 17:43:25 JST 2014
YUKI "Piro" Hiroshi 2014-05-08 17:43:25 +0900 (Thu, 08 May 2014) New Revision: 5e7567ebbd7800913aa407ee42d95ed4b599fe40 https://github.com/droonga/wikipedia-search/wiki/Droonga%E3%83%8E%E3%83%BC%E3%83%89%E3%81%AE%E6%AD%BB%E6%B4%BB%E7%AE%A1%E7%90%86%E3%82%92Serf%E3%81%A7%E8%A1%8C%E3%81%86%E6%89%8B%E9%A0%86/5e7567ebbd7800913aa407ee42d95ed4b599fe40 Message: Updated Droongaノードの死活管理をSerfで行う手順 (markdown) Modified files: Droongaノードの死活管理をSerfで行う手順.md Modified: Droongaノードの死活管理をSerfで行う手順.md (+10 -3) =================================================================== --- Droongaノードの死活管理をSerfで行う手順.md 2014-05-07 18:23:29 +0900 (94e0a43) +++ Droongaノードの死活管理をSerfで行う手順.md 2014-05-08 17:43:25 +0900 (752166d) @@ -75,7 +75,7 @@ 1. どれか1つのノード（例えばnode1）でSerfのプロセスを終了してみる。 するとイベントが自動的にメンバーに通知されて、各メンバーが持つメンバーリストが更新される。 - * `serf leave`を実行しても、自動的にプロセスが終了するので、結局はkillするのと変わりない。 + * `serf leave`を実行しても、自動的にプロセスが終了する。 * この時、クラスタに残されたノードではイベントハンドラに以下の情報が渡される（以下はnode0の場合）。 * $SERF_EVENT: `member-leave` * stdin: `node1 192.168.100.51` @@ -124,7 +124,7 @@ ### 障害によるクラスタからの離脱と再参加（すぐに再接続できるパターン） - 1. どれか1つのノード（例えばnode1）のVMを一時停止してみる。 + 1. どれか1つのノード（例えばnode1）で、serfのプロセスを強制終了してみる。 すると、残ったノードに対してイベントが自動的に通知されて、各メンバーが持つメンバーリストが更新される。 * この時、クラスタに残されたノードではイベントハンドラに以下の情報が渡される（以下はnode0の場合）。 * $SERF_EVENT: `member-failed.` @@ -138,10 +138,11 @@ node2 192.168.100.52:7946 alive failedとなっているのが、障害発生により暗黙的に離脱中のノードである。 - 3. 離脱したノードのVMを再開する。 + 3. 離脱したノードのserfをもう一度起動する。 * この時、クラスタに残っていたノードでは一定時間ごとのポーリングによりノードの復帰が検知され、自動的に、イベントハンドラに以下の情報が渡される（以下はnode0の場合）。 * $SERF_EVENT: `member-join` * stdin: `node1 192.168.100.51` + * serfを起動し直したノードでは、「自分がjoin」のイベントが発生した後、しばらく経ってから「クラスタに残っていたほか野ノードがjoin」のイベントが発生する。 5. クラスタへの復帰に成功したかどうか、`serf members`コマンドで確認する。 % serf members @@ -216,6 +217,12 @@ * `user`, `query`イベントの受信時：ノードの死活状態の変更に関するものであった場合、liveなノードのリスト（ファイル）を更新する。 * ノードのリストのファイルの位置は、以下のようにしてコマンドライン引数で指定する。 `serf agent -event-handler="droonga-handle-serf-event --list=/path/to/list-file"` + * 自分自身に関するjoin/leaveのイベントが発生した時は、ノードのリストを破棄する。 + （それまで持っていたリストは有効期限切れと見なす。） + 何故なら、以下のいずれのパターンであっても、自分自身に関するイベントがまず最初に発生し、その後他のノードに関するイベントが発生する、という順番になっているからである。 + * 通常通り起動した時は、自分のjoinのイベントが最初に発生し、その後で他のノードのjoinが発生する。 + * 通常通り終了した時は、自分のleaveのイベントが発生する。その後再参加した時は、自分のjoinが発生し、その後で他のノードのjoinが発生する。 + * 異常終了からの復帰時は、自分のjoinのイベントがまず発生し、その後で他のノードのjoinが発生する。 * Droonga Engineは、初期状態で、catalog.jsonに記述されているすべてのノードがliveであると想定したliveなノードのリストを持つ。 * Droonga Engineは、メッセージを配送する必要が生じた時は、メモリ上にあるliveなノードのリストに基づいて配送先を決定する。 * Droonga Engineは、liveなノードのリスト（ファイル）が書き換えられたことを何らかの方法で検知して、メモリ上にあるliveなノードのリストを破棄し、ファイルから最新のliveなノードのリストを読み込む。 -------------- next part -------------- HTML����������������������������...ダウンロード
