YUKI Piro Hiroshi
null+****@clear*****
Thu May 22 13:08:52 JST 2014
YUKI "Piro" Hiroshi 2014-05-22 13:08:52 +0900 (Thu, 22 May 2014) New Revision: c55de7ab0d747e8a18d0810219c90ae2b8040c0a https://github.com/droonga/wikipedia-search/wiki/Droonga%E3%82%AF%E3%83%A9%E3%82%B9%E3%82%BF%E3%81%AB%E3%83%8E%E3%83%B3%E3%82%B9%E3%83%88%E3%83%83%E3%83%97%E3%81%A7%E3%83%8E%E3%83%BC%E3%83%89%E3%82%92%E8%BF%BD%E5%8A%A0%E3%81%99%E3%82%8B%E6%89%8B%E9%A0%86/c55de7ab0d747e8a18d0810219c90ae2b8040c0a Message: Updated Droongaクラスタにノンストップでノードを追加する手順 (markdown) Modified files: Droongaクラスタにノンストップでノードを追加する手順.md Modified: Droongaクラスタにノンストップでノードを追加する手順.md (+17 -5) =================================================================== --- Droongaクラスタにノンストップでノードを追加する手順.md 2014-05-20 19:19:33 +0900 (ac64c53) +++ Droongaクラスタにノンストップでノードを追加する手順.md 2014-05-22 13:08:52 +0900 (d6b4f0e) @@ -32,6 +32,17 @@ droonga-engineは以下の挙動になるよう変更を行っておく。 * 新しいcatalog.jsonが監視対象ディレクトリ(staging-catalog)以下に配置されたら、即座にそれを検知する。 * effectiveDateが現在時刻より前であれば、監視対象ディレクトリに置かれたstagingなcatalog.jsonの内容を、メモリ上のcatalog.jsonの内容に即座に反映する。と同時に、ファイルへの書き込み権限がある場合は、本番のcatalog.jsonにも変更を反映する。 +### 最後に受け取ったメッセージのtimestamp + + * droonga-engineは、最後に自分が受け取ったメッセージのtimestampを保持する。 + （last_message_timestamp） + * この情報はメモリ上の揮発性の情報としてのみではなく、不揮発性の情報として保持する。 + * droonga-engineは、「これ以後のtimestampのメッセージのみ有効と見なす」「これ以前のtimestampのメッセージが来ても無視する」と判断する基準となるtimestampを保持できる。 + （effective_message_timestamp：初期値=nil） + * この情報はメモリ上の揮発性の情報としてのみではなく、不揮発性の情報として保持する。 + * effective_message_timestampが設定されている場合、入ってきたメッセージのtimestampをチェックして、古いメッセージであれば破棄する。 + * effective_message_timestampよりも新しいtimestampのメッセージが来たら、メッセージを受け入れると同時に、effective_message_timestampをnilに戻す。 + ### バッファ ノードの状態に応じて挙動を帰るバッファを実装する。 @@ -56,13 +67,14 @@ droonga-engineは以下の挙動になるよう変更を行っておく。 --add-hosts=192.168.100.52 \ --remove-hosts="" \ --source=~/droonga/catalog.json \ - --output=~/droonga/staging-catalog/catalog.json + --output=~/tmp/catalog.json node0% scp catalog.json 192.168.100.52:/tmp/ node2% droonga-catalog-modify-replicas --dataset=Starbucks \ --add-hosts="" \ --remove-hosts="192.168.100.50,192.168.100.51" \ --source=/tmp/catalog.json \ --output=~/droonga/staging-catalog/catalog.json + node0% cp /tmp/catalog.json ~/droonga/staging-catalog/ この時点で、 @@ -109,10 +121,10 @@ drndumpでデータを複製する。 --datasets=Starbacks \ --tag=starbacks -この時、 +データの複製が終わったら、node1のlast_message_timestampをnode2のeffective_message_timestampに設定する。 - * node1は、drndumpの結果の一部として、drndumpの開始時刻を送出する。 - * node2は、drndumpから受け取った「drndumpの開始時刻」を、「有効期限切れと見なすメッセージの時刻」として保持する。 + node1% timestamp=$(droonga-get-status --name=last_message_timestamp) + node2% droonga-set-status --name=effective_message_timestamp --value=$timestamp ## step4: node1, node2を元のクラスタに戻す。 @@ -126,7 +138,7 @@ droonga-engineが自動的に新しいcatalog.jsonを認識する。 ここで、node1とnode2は、生存ノードから見た時に、ステータスが「死んでいるノード」から「復帰中のノード」に切り替わる。 * 生存ノードはバッファに溜め込んでおいたwriteなメッセージを、復帰中のノード（node1とnode2）に配送し始める。 - * node2は、保持している「有効期限切れと見なすメッセージの時刻」に基づいて、バッファから配送されてきたメッセージのうち、node1には渡されていないがnode2には渡されていたというメッセージ（＝すでにdrndumpを通じてnode1から結果を受け取っているメッセージ）を破棄する。 + * node2は、effective_message_timestampに基づいて、バッファから配送されてきたメッセージのうち、node1には渡されていないがnode2には渡されていたというメッセージ（＝すでにdrndumpを通じてnode1から結果を受け取っているメッセージ）を破棄する。 * バッファが空になるまでは、復帰中のノード宛のメッセージはバッファに貯まっていく。 * バッファが空になったら、復帰中のノードは「生きている」状態に戻る。 * 生存ノードの状態に戻った後は、通常通りメッセージが流れてくるようになる。 -------------- next part -------------- HTML����������������������������...Download
