YUKI Piro Hiroshi
null+****@clear*****
Tue May 20 19:09:49 JST 2014
YUKI "Piro" Hiroshi 2014-05-20 19:09:49 +0900 (Tue, 20 May 2014) New Revision: 99457482ee62140b1998f11749c8560f0d0ce02b 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/99457482ee62140b1998f11749c8560f0d0ce02b Message: Updated Droongaクラスタにノンストップでノードを追加する手順 (markdown) Modified files: Droongaクラスタにノンストップでノードを追加する手順.md Modified: Droongaクラスタにノンストップでノードを追加する手順.md (+40 -48) =================================================================== --- Droongaクラスタにノンストップでノードを追加する手順.md 2014-05-20 18:56:56 +0900 (27240a0) +++ Droongaクラスタにノンストップでノードを追加する手順.md 2014-05-20 19:09:49 +0900 (cda61d6) @@ -18,95 +18,87 @@ ## 事前実装 +### Serfによる死活管理 + serfを利用したクラスタの死活監視の仕組みについて、以下の挙動になるよう変更を行っておく。 * serfの各ノードは、タグ情報として「自分が属しているクラスタ」の情報（全ノードの名前を連結した文字列、またはそのハッシュ値）を持つ。 * `sert members` の結果のうち、状態が「live」で且つタグ情報に含まれている所属クラスタの情報が自分と一致するノードだけを、「生存しているノード」と判断する。 -また、droonga-engineは以下の挙動になるよう変更を行っておく。 +### catalog.jsonの更新 + +droonga-engineは以下の挙動になるよう変更を行っておく。 * 新しいcatalog.jsonが監視対象ディレクトリ(staging-catalog)以下に配置されたら、即座にそれを検知する。 * effectiveDateが現在時刻より前であれば、監視対象ディレクトリに置かれたstagingなcatalog.jsonの内容を、メモリ上のcatalog.jsonの内容に即座に反映する。と同時に、ファイルへの書き込み権限がある場合は、本番のcatalog.jsonにも変更を反映する。 +### バッファ +ノードの状態に応じて挙動を帰るバッファを実装する。 -## 基本方針 - - 1. node2をクラスタに仮追加する - 2. node1, node2をクラスタから一旦切り離す。 - 3. node1, node2それぞれでサブクラスタを形成する。 - 4. node1からnode2へデータを複製する。 - 5. node1, node2を元のクラスタに戻す。 - -## step1: node2をクラスタに仮追加する - -複製作業に関わらないノード（生存ノード、ここではnode0のみ）のcatalog.jsonに、node2の情報を加えて、最終的な構成の状態にあたるcatalog.jsonを用意する。 - - node0% droonga-catalog-modify-replicas --dataset=Starbucks \ - --add-hosts=192.168.100.52 \ - --catalog=~/droonga/catalog.json + * readなメッセージが来た場合、生存ノード同士だけで配送先を決める。 + * writeなメッセージが来た場合、「配送するだけで、結果を待たない」という設定のメッセージを、生死に関わらずすべてのノードに送る。 + * 死んでいるノードへ配送するように指示されたメッセージは、内蔵のバッファに溜め込まれる。 -この時、node2はまだクラスタのための設定が行われていないので、実際にはノードとして動作しない。 -そのため、生存ノードから見た時、node2は「死んでいるノード」として扱われる。 +## 基本方針 -## step2: node1, node2をクラスタから切り離す + 1. node1をクラスタから切り離す。 + 2. node2をクラスタに仮追加する。 + 3. node1からnode2へデータを複製する。 + 4. node1, node2を元のクラスタに戻す。 -node1, node2のcatalog.jsonのノード構成を変更し、クラスタから切り離す。 +## step1: node1をクラスタから切り離す -node1, node2のcatalog.jsonを更新する。 +node1のcatalog.jsonのノード構成を変更し、クラスタから切り離す。 node1% droonga-catalog-modify-replicas --dataset=Starbucks \ --add-hosts="" \ --remove-hosts=192.168.100.50,192.168.100.52 \ --source=~/droonga/catalog.json \ --output=~/droonga/staging-catalog/catalog.json - node2% droonga-catalog-modify-replicas --dataset=Starbucks \ - --add-hosts="" \ - --remove-hosts=192.168.100.51,192.168.100.52 \ - --source=~/droonga/catalog.json \ - --output=~/droonga/staging-catalog/catalog.json - - * この時点で、node1, node2はクラスタから切り離される。 - （生存ノードから見た時は、node1は死んだノードとして扱われる。） - * node1/node2自身から見た時は、node1/node2だけのクラスタとなっている。 +この時点で、 -この時、生存ノードは以下のモードに切り替わる。 - - * readなメッセージが来た場合、生存ノード同士だけで配送先を決める。 - * writeなメッセージが来た場合、「配送するだけで、結果を待たない」という設定のメッセージを、生死に関わらずすべてのノードに送る。 - * 死んでいるノードへ配送するように指示されたメッセージは、内蔵のバッファに溜め込まれる。 + * node1は、生存ノードから見た時は死んだノードとして扱われるようになる。 + * node1自身から見た時は、node1だけのクラスタとなっている。 + * 生存ノードからnode1へ配送される予定だったwriteなメッセージが、バッファに溜まり始める。 -## step3: node1, node2それぞれでサブクラスタを形成する。 +## step2: node2をクラスタに仮追加する -node1, node2だけのクラスタを作る。 +複製作業に関わらないノード（生存ノード、ここではnode0のみ）のcatalog.jsonに、node2の情報を加えて、最終的な構成の状態にあたるcatalog.jsonを用意する。 - node1% scp catalog.json 192.168.100.52:/tmp/ - node1% droonga-catalog-modify-replicas --dataset=Starbucks \ - --add-hosts="" \ - --remove-hosts=192.168.100.50,192.168.100.52 \ - --source=/tmp/catalog.json \ + node0% droonga-catalog-modify-replicas --dataset=Starbucks \ + --add-hosts=192.168.100.52 \ + --remove-hosts="" \ + --source=~/droonga/catalog.json \ --output=~/droonga/staging-catalog/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 \ + --remove-hosts="192.168.100.50,192.168.100.51" \ --source=/tmp/catalog.json \ --output=~/droonga/staging-catalog/catalog.json -これで、node1, node2だけのクラスタができた。 +この時点で、 + + * node2はまだクラスタのための設定が行われていないので、実際にはノードとして動作しない。 + * node2は、生存ノードから見た時はは死んだノードとして扱われるようになる。 + * node2自身から見た時は、node2だけのクラスタとなっている。 + * 生存ノードからnode2へ配送される予定だったwriteなメッセージが、バッファに溜まり始める。 + -## step4: node1からnode2へデータを複製する。 +## step3: node1からnode2へデータを複製する。 drndumpでデータを複製する。 node1% drndump --host=192.168.100.51 \ - --dataset=Starbacks \ + --dataset=Starbacks | \ droonga-client --host=192.168.100.52 ※droonga-requestコマンドが標準入力からjsonsを受け取れる前提。 -※step3, step4を1操作で行うコマンドの案 +※step2, step3を1操作で行うコマンドの案 node1% droonga-replicate --from-host=192.168.100.51 \ --from-port=10031 \ @@ -115,7 +107,7 @@ drndumpでデータを複製する。 --datasets=Starbacks \ --tag=starbacks -## step5: node1, node2を元のクラスタに戻す。 +## step4: node1, node2を元のクラスタに戻す。 最終的な構成のクラスタのためのcatalog.jsonをnode1, node2に展開する。 -------------- next part -------------- HTML����������������������������...Descargar
