YUKI Hiroshi
null+****@clear*****
Sat Jun 28 04:25:16 JST 2014
YUKI Hiroshi 2014-06-28 04:25:16 +0900 (Sat, 28 Jun 2014) New Revision: 6c544ff980e4d079f375584bf79d14f9a7abe836 https://github.com/droonga/droonga.org/commit/6c544ff980e4d079f375584bf79d14f9a7abe836 Message: Rewrite tutorial based on new utility commands Modified files: _po/ja/tutorial/1.0.4/add-replica/index.po ja/tutorial/1.0.4/add-replica/index.md tutorial/1.0.4/add-replica/index.md Modified: _po/ja/tutorial/1.0.4/add-replica/index.po (+73 -223) =================================================================== --- _po/ja/tutorial/1.0.4/add-replica/index.po 2014-06-27 22:26:10 +0900 (e0c2d45) +++ _po/ja/tutorial/1.0.4/add-replica/index.po 2014-06-28 04:25:16 +0900 (0c49817) @@ -140,23 +140,34 @@ msgid "" " # apt-get install -y ruby ruby-dev build-essential nodejs nodejs-legacy np" "m\n" " # gem install droonga-engine\n" -" # npm install -g droonga-http-server\n" -" # mkdir ~/droonga" +" # npm install -g droonga-http-server" msgstr "" msgid "" -"For the new node, you have to setup a `catalog.json` includes only one node, b" -"ased on the existing one on another node." +"For the new node, you have to copy the `catalog.json` from existing node of th" +"e cluster." +msgstr "新しいノードには、クラスタの既存のノードから `catalog.json` をコピーする必要があります。" + +msgid "" +" (on 192.168.0.12)\n" +" # mkdir ~/droonga\n" +" # scp 192.168.0.10:~/droonga/catalog.json ~/droonga/" msgstr "" -"新しいノード用には、他のノードにある既存の `catalog.json` を元にして、構成ノードが1つだけの新しい `catalog.json` を用意する" -"必要があります。" + +msgid "" +"Note, you cannot add a non-empty node to an existing cluster.\n" +"If the computer was used as a Droonga node in old days, then you must clear ol" +"d data at first." +msgstr "" +"注意点として、空でないノードを既存のクラスタに追加することはできません。\n" +"もしそのコンピュータがかつてDroongaノードとして使われていた事があった場合には、最初に古いデータを消去する必要があります。" msgid "" " (on 192.168.0.12)\n" -" # scp 192.168.0.10:~/droonga/catalog.json ~/droonga/\n" -" # droonga-engine-catalog-modify --source=~/droonga/catalog.json \\\n" -" --update \\\n" -" --hosts=192.168.0.12" +" # kill $(cat $PWD/droonga-engine.pid)\n" +" # rm -rf ~/droonga\n" +" # mkdir ~/droonga\n" +" # scp 192.168.0.10:~/droonga/catalog.json ~/droonga/" msgstr "" msgid "Let's start the server." @@ -181,30 +192,20 @@ msgid "" "id" msgstr "" -msgid "Then there are two separate Droonga clusters on this time." -msgstr "この時点で、2つの別々のDroongaクラスタが存在するようになりました。" - msgid "" -" * The existing cluster including two replicas.\n" -" Let's give a name *\"alpha\"* to it, for now.\n" -" * `192.168.0.10`\n" -" * `192.168.0.11`\n" -" * The new cluster including just one replica.\n" -" Let's give a name *\"beta\"* to it, for now.\n" -" * `192.168.0.12`" +"Currently, the new node doesn't work as a node of the cluster, because it does" +"n't appear in the `catalog.json`.\n" +"Even if you send requests to the new node, it just forwards all of them to oth" +"er existing members of the cluster." msgstr "" -" * 2つのreplicaを含む既存のクラスタ。以下、*「alpha」*と仮称します。\n" -" * `192.168.0.10`\n" -" * `192.168.0.11`\n" -" * 1つのreplicaを含む新しいクラスタ。以下、*「beta」*と仮称します。\n" -" * `192.168.0.12`" +"この時点では、ノードの情報が `catalog.json` に含まれていないため、この新しいノードはクラスタのノードとしては動作していません。\n" +"新しいノードにリクエストを送っても、それらはすべてクラスタ内の既存のノードに転送されます。" msgid "You can confirm that, via the `system.status` command:" msgstr "この事は、`system.status` コマンドの結果を見ると確認できます:" msgid "" "~~~\n" -"(for the cluster alpha)\n" "# curl \"http://192.168.0.10:10041/droonga/system/status\"\n" "{\n" " \"nodes\": {\n" @@ -227,28 +228,13 @@ msgid "" " }\n" " }\n" "}\n" -"~~~" -msgstr "" - -msgid "" -"`192.168.0.10` and `192.168.0.11` are members of the cluster alpha, so they re" -"turn same result.\n" -"`192.168.0.12` doesn't appear in the result because it is not a member of the " -"cluster alpha." -msgstr "" -"`192.168.0.10` と `192.168.0.11` は共にクラスタ alpha を構成しているため、両ノードは同じ結果を返します。\n" -"`192.168.0.12` はクラスタ alpha の構成ノードではないため、この結果には登場しません。" - -msgid "On the other hand, `192.168.0.12` returns a result like:" -msgstr "他方、`192.168.0.12` は以下のような結果を返します：" - -msgid "" -"~~~\n" -"(for the cluster beta)\n" "# curl \"http://192.168.0.12:10041/droonga/system/status\"\n" "{\n" " \"nodes\": {\n" -" \"192.168.0.12:10031/droonga\": {\n" +" \"192.168.0.10:10031/droonga\": {\n" +" \"live\": true\n" +" },\n" +" \"192.168.0.11:10031/droonga\": {\n" " \"live\": true\n" " }\n" " }\n" @@ -256,26 +242,20 @@ msgid "" "~~~" msgstr "" -msgid "" -"It is a result for the cluster beta, so `192.168.0.10` and `192.168.0.11` don'" -"t appear." -msgstr "これはクラスタ beta の結果なので、今度は `192.168.0.10` と `192.168.0.11` が登場しません。" - msgid "### Suspend inpouring of \"write\" requests" msgstr "### 書き込みを伴うリクエストの流入を一時的に停止する" msgid "" -"Before starting duplication of data, you must suspend inpouring of \"write\" re" -"quests to the cluster alpha, because we have to synchronize data in clusters a" -"lpha and beta completely.\n" -"Otherwise, the new added replica node will contain incomplete data.\n" -"Because data in replicas will be inconsistent, results for any request to the " -"cluster become unstable." +"Before starting to change cluster composition, you must suspend inpouring of \"" +"write\" requests to the cluster, because we have to synchronize data to the new" +" replica.\n" +"Otherwise, the new added replica will contain incomplete data and results for " +"requests to the cluster become unstable." msgstr "" -"クラスタ alpha とクラスタ beta のデータを完全に同期する必要があるので、データの複製を始める前に、クラスタ alphaへのデータの書き込みを行う" -"リクエストの流入を一時停止する必要があります。\n" -"そうしないと、新しく追加したreplicaが中途半端なデータしか持たない状態となってしまいます。\n" -"replica同士の内容に矛盾があると、リクエストに対してクラスタが返す処理結果が不安定になります。" +"新しいreplicaとの間でデータを完全に同期する必要があるので、クラスタの構成を変更する前に、クラスタへのデータの書き込みを行うリクエストの流入を一時停止" +"する必要があります。\n" +"そうしないと、新しく追加したreplicaが中途半端なデータしか持たない矛盾した状態となってしまい、リクエストに対してクラスタが返す処理結果が不安定になりま" +"す。" msgid "" "What's \"write\" request?\n" @@ -310,145 +290,45 @@ msgstr "" "[前項](../dump-restore/)から順番にチュートリアルを読んでいる場合、クラスタに流入しているリクエストはありませんので、ここでは特に何もする" "必要はありません。" -msgid "### Duplicate data from the existing cluster to the new replica" -msgstr "### 既存のクラスタから新しいreplicaへデータを複製する" - -msgid "" -"Duplicate data from the cluster alpha to the cluster beta.\n" -"It can be done by the command `droonga-engine-absorb-data`.\n" -"Run it *on the new replica node*, like:" -msgstr "" -"クラスタ alpha からクラスタ beta へデータを複製します。\n" -"これは `droonga-engine-absorb-data` コマンドを使って行います。\n" -"*新しいreplicaノード上で*、以下のようにコマンドを実行して下さい:" - -msgid "" -" (on 192.168.0.12)\n" -" # droonga-engine-absorb-data --source-host=192.168.0.10 \\\n" -" --receiver-host=192.168.0.12" -msgstr "" - -msgid "" -"Note that you must specify the host name or the IP address of the new replica " -"node itself, via the `--receiver-host` option." -msgstr "`--receiver-host` オプションに新しいreplicaノード自身のホスト名またはIPアドレスを指定しておく必要がある事に注意して下さい。" - -msgid "### Join the new replica to the cluster" +msgid "### Joining a new replica node to the cluster" msgstr "### 新しいreplicaをクラスタに参加させる" msgid "" -"After the duplication is successfully done, join the new replica to the existi" -"ng clster.\n" -"Update the `catalog.json` on the newly joining node `192.168.0.12`, like:" +"To add a new replica node to an existing cluster, you just run a command `droo" +"nga-engine-join` *on the new replica node itself*, like:" msgstr "" -"データを正しく複製できたら、新しいreplicaを既存のクラスタに参加させます。\n" -"新たにクラスタに参加するノード `192.168.0.12` 上で、以下のようにして `catalog.json` を更新して下さい:" +"新しいreplicaノードを既存のクラスタに追加するには、*新しいreplicaノード自身の上で*`droonga-engine-join`コマンドを実行し" +"ます:" msgid "" " (on 192.168.0.12)\n" -" # droonga-engine-catalog-modify --source=~/droonga/catalog.json \\\n" -" --update \\\n" -" --add-replica-hosts=192.168.0.10,192.168.0" -".11" -msgstr "" - -msgid "" -"The server process detects new `catalog.json` and restats itself automatically" -"." -msgstr "すると、サーバのプロセスが新しい `catalog.json` を検知して、自動的に自分自身を再起動させます。" - -msgid "Then there are two overlapping Droonga clusters theoretically on this time." -msgstr "この時点で、理論上、部分的に重なり合う2つのDroongaクラスタが存在するようになりました。" - -msgid "" -" * The existing cluster \"alpha\", including two replicas.\n" -" * `192.168.0.10`\n" -" * `192.168.0.11`\n" -" * The new cluster including three replicas.\n" -" Let's give a name *\"charlie\"* to it, for now.\n" -" * `192.168.0.10`\n" -" * `192.168.0.11`\n" -" * `192.168.0.12`" -msgstr "" -" * 2つのreplicaを含む既存のクラスタ「alpha」。\n" -" * `192.168.0.10`\n" -" * `192.168.0.11`\n" -" * 3つのreplicaを含む新しいクラスタ。以下、*「charlie」*と仮称します。\n" -" * `192.168.0.10`\n" -" * `192.168.0.11`\n" -" * `192.168.0.12`" - -msgid "You can confirm that, via the `system.status` command for each cluster:" -msgstr "この事は、各クラスタに対する `system.status` コマンドの実行結果を見ると確認できます:" - -msgid "" -"Because `catalog.json` on nodes `192.168.0.10` and `192.168.0.11` have no chan" -"ge, the result says that there is still the cluster alpha with only two nodes." -"\n" -"Any incoming request to the cluster alpha is never delivered to the new replic" -"a `192.168.0.12` yet." -msgstr "" -"`192.168.0.10` と `192.168.0.11` の `catalog.json` には何も変更がないため、コマンドの実行結果は依然として2つ" -"のノードから構成されるクラスタ alpha の情報を返します。\n" -"クラスタ alpha へ流入するリクエストは、まだ新しい replica である `192.168.0.12` には配送されません。" - -msgid "" -"However, the new node `192.168.0.12` has a new `catalog.json`.\n" -"It knows the cluster charlie includes three nodes, even if other two existing " -"nodes don't know that:" -msgstr "" -"しかし、新しいノード `192.168.0.12` は新しい `catalog.json` を持っています。\n" -"他の2つの既存ノードがその事を知らなくても、このノードはクラスタ charlie が3つのノードを含んでいる事を知っています：" - -msgid "" -"~~~\n" -"(for the cluster charlie)\n" -"# curl \"http://192.168.0.12:10041/droonga/system/status\"\n" -"{\n" -" \"nodes\": {\n" -" \"192.168.0.10:10031/droonga\": {\n" -" \"live\": true\n" -" },\n" -" \"192.168.0.11:10031/droonga\": {\n" -" \"live\": true\n" -" },\n" -" \"192.168.0.12:10031/droonga\": {\n" -" \"live\": true\n" -" }\n" -" }\n" -"}\n" -"~~~" +" # droonga-engine-join --replica-source-host=192.168.0.10 \\\n" +" --my-host=192.168.0.12" msgstr "" -msgid "Note that the temporary cluster named \"beta\" is gone." -msgstr "「beta」と仮称した一時的なクラスタが姿を消している事に注意してください。" - -msgid "Next, update existing `catalog.json` on other nodes, like:" -msgstr "次に、他のノードの既存の `catalog.json` を以下のようにして更新します:" +msgid "Note, you must specify two options for the command always." +msgstr "以下の2つのオプションの指定が必須である事に注意して下さい。" msgid "" -" (on 192.168.0.10, 192.168.0.11)\n" -" # droonga-engine-catalog-modify --source=~/droonga/catalog.json \\\n" -" --update \\\n" -" --add-replica-hosts=192.168.0.12" +" * You must specify the host name or the IP address of an existing node of the" +" cluster, via the `--replica-source-host` option.\n" +" * You must specify the host name or the IP address of the new replica node it" +"self, via the `--my-host` option." msgstr "" - -msgid "Servers detect new `catalog.json` and restart themselves automatically." -msgstr "コピー先のノードのサーバが新しい `catalog.json` を認識して、自動的に再起動します。" - -msgid "Then there is just one Droonga clusters on this time." -msgstr "この時点で、Droongaクラスタは1つだけ存在する状態となっています。" +" * `--replica-source-host` オプションで、クラスタ中の既存のノードの1つのホスト名またはIPアドレスを指定して下さい。\n" +" * `--my-host` オプションで、その新しいreplicaノード自身のホスト名またはIPアドレスを指定して下さい。" msgid "" -" * The new cluster \"charlie\",including three replicas.\n" -" * `192.168.0.10`\n" -" * `192.168.0.11`\n" -" * `192.168.0.12`" +"Then the command automatically starts to synchronize all data of the cluster t" +"o the new replica node.\n" +"After data is successfully synchronized, the node restarts and joins to the cl" +"uster automatically.\n" +"All nodes' `catalog.json` are also updated, and now, yes, the new node starts " +"working as a replica in the cluster." msgstr "" -" * 3つのreplicaを含む新しいクラスタ「charlie」。\n" -" * `192.168.0.10`\n" -" * `192.168.0.11`\n" -" * `192.168.0.12`" +"コマンドを実行すると、自動的に、クラスタのデータが新しいdeplicaノードへと同期され始めます。\n" +"データの同期が完了すると、ノードが自動的に再起動してクラスタに参加します。\n" +"すべてのノードの`catalog.json`も同時に更新され、この時点をもって、新しいノードは晴れてそのクラスタのreplicaノードとして動作し始めます。" msgid "" "~~~\n" @@ -466,48 +346,9 @@ msgid "" " }\n" " }\n" "}\n" -"# curl \"http://192.168.0.11:10041/droonga/system/status\"\n" -"{\n" -" \"nodes\": {\n" -" \"192.168.0.10:10031/droonga\": {\n" -" \"live\": true\n" -" },\n" -" \"192.168.0.11:10031/droonga\": {\n" -" \"live\": true\n" -" },\n" -" \"192.168.0.12:10031/droonga\": {\n" -" \"live\": true\n" -" }\n" -" }\n" -"}\n" -"# curl \"http://192.168.0.12:10041/droonga/system/status\"\n" -"{\n" -" \"nodes\": {\n" -" \"192.168.0.10:10031/droonga\": {\n" -" \"live\": true\n" -" },\n" -" \"192.168.0.11:10031/droonga\": {\n" -" \"live\": true\n" -" },\n" -" \"192.168.0.12:10031/droonga\": {\n" -" \"live\": true\n" -" }\n" -" }\n" -"}\n" "~~~" msgstr "" -msgid "Any node returns same result." -msgstr "いずれのノードも同じ結果を返します。" - -msgid "" -"Note that the old cluster named \"alpha\" is gone.\n" -"Now the new cluster \"charlie\" with three replicas works perfectly, instead of " -"the old one with two replicas." -msgstr "" -"「alpha」と仮称した古いクラスタが姿を消している事に注意してください。\n" -"この時、2つのreplicaからなる古いクラスタの代わりとして、新しいクラスタ「charlie」は3つのreplicaのもとで完璧に動作しています。" - msgid "### Resume inpouring of \"write\" requests" msgstr "### 書き込みを伴うリクエストの流入を再開する" @@ -572,6 +413,9 @@ msgid "" " --remove-replica-hosts=192.168.0.12" msgstr "" +msgid "Then there are two overlapping Droonga clusters theoretically on this time." +msgstr "この時点で、理論上、部分的に重なり合う2つのDroongaクラスタが存在するようになりました。" + msgid "" " * The existing cluster \"charlie\" including three replicas.\n" " * `192.168.0.10`\n" @@ -590,6 +434,9 @@ msgstr "" " * `192.168.0.10`\n" " * `192.168.0.11`" +msgid "You can confirm that, via the `system.status` command for each cluster:" +msgstr "この事は、各クラスタに対する `system.status` コマンドの実行結果を見ると確認できます:" + msgid "" "~~~\n" "(for the cluster charlie)\n" @@ -662,6 +509,9 @@ msgstr "" "そのため、ノード `192.168.0.10` へ流入してくるメッセージは、既に存在しないものと認識されているノード `192.168.0.12` へは決し" "て配送されません。" +msgid "Next, update existing `catalog.json` on other nodes, like:" +msgstr "次に、他のノードの既存の `catalog.json` を以下のようにして更新します:" + msgid "" " (on 192.168.0.11, 192.168.0.12)\n" " # droonga-engine-catalog-modify --source=~/droonga/catalog.json \\\n" Modified: ja/tutorial/1.0.4/add-replica/index.md (+27 -157) =================================================================== --- ja/tutorial/1.0.4/add-replica/index.md 2014-06-27 22:26:10 +0900 (a480cf5) +++ ja/tutorial/1.0.4/add-replica/index.md 2014-06-28 04:25:16 +0900 (133a419) @@ -68,15 +68,21 @@ Droongaのノードの集合には、「replica」と「slice」という2つの # apt-get install -y ruby ruby-dev build-essential nodejs nodejs-legacy npm # gem install droonga-engine # npm install -g droonga-http-server + +新しいノードには、クラスタの既存のノードから `catalog.json` をコピーする必要があります。 + + (on 192.168.0.12) # mkdir ~/droonga + # scp 192.168.0.10:~/droonga/catalog.json ~/droonga/ -新しいノード用には、他のノードにある既存の `catalog.json` を元にして、構成ノードが1つだけの新しい `catalog.json` を用意する必要があります。 +注意点として、空でないノードを既存のクラスタに追加することはできません。 +もしそのコンピュータがかつてDroongaノードとして使われていた事があった場合には、最初に古いデータを消去する必要があります。 (on 192.168.0.12) + # kill $(cat $PWD/droonga-engine.pid) + # rm -rf ~/droonga + # mkdir ~/droonga # scp 192.168.0.10:~/droonga/catalog.json ~/droonga/ - # droonga-engine-catalog-modify --source=~/droonga/catalog.json \ - --update \ - --hosts=192.168.0.12 では、サーバを起動しましょう。 @@ -96,18 +102,12 @@ Droongaのノードの集合には、「replica」と「slice」という2つの --daemon \ --pid-file=$DROONGA_BASE_DIR/droonga-http-server.pid -この時点で、2つの別々のDroongaクラスタが存在するようになりました。 - - * 2つのreplicaを含む既存のクラスタ。以下、*「alpha」*と仮称します。 - * `192.168.0.10` - * `192.168.0.11` - * 1つのreplicaを含む新しいクラスタ。以下、*「beta」*と仮称します。 - * `192.168.0.12` +この時点では、ノードの情報が `catalog.json` に含まれていないため、この新しいノードはクラスタのノードとしては動作していません。 +新しいノードにリクエストを送っても、それらはすべてクラスタ内の既存のノードに転送されます。 この事は、`system.status` コマンドの結果を見ると確認できます: ~~~ -(for the cluster alpha) # curl "http://192.168.0.10:10041/droonga/system/status" { "nodes": { @@ -130,33 +130,23 @@ Droongaのノードの集合には、「replica」と「slice」という2つの } } } -~~~ - -`192.168.0.10` と `192.168.0.11` は共にクラスタ alpha を構成しているため、両ノードは同じ結果を返します。 -`192.168.0.12` はクラスタ alpha の構成ノードではないため、この結果には登場しません。 - -他方、`192.168.0.12` は以下のような結果を返します： - -~~~ -(for the cluster beta) # curl "http://192.168.0.12:10041/droonga/system/status" { "nodes": { - "192.168.0.12:10031/droonga": { + "192.168.0.10:10031/droonga": { + "live": true + }, + "192.168.0.11:10031/droonga": { "live": true } } } ~~~ -これはクラスタ beta の結果なので、今度は `192.168.0.10` と `192.168.0.11` が登場しません。 - - ### 書き込みを伴うリクエストの流入を一時的に停止する -クラスタ alpha とクラスタ beta のデータを完全に同期する必要があるので、データの複製を始める前に、クラスタ alphaへのデータの書き込みを行うリクエストの流入を一時停止する必要があります。 -そうしないと、新しく追加したreplicaが中途半端なデータしか持たない状態となってしまいます。 -replica同士の内容に矛盾があると、リクエストに対してクラスタが返す処理結果が不安定になります。 +新しいreplicaとの間でデータを完全に同期する必要があるので、クラスタの構成を変更する前に、クラスタへのデータの書き込みを行うリクエストの流入を一時停止する必要があります。 +そうしないと、新しく追加したreplicaが中途半端なデータしか持たない矛盾した状態となってしまい、リクエストに対してクラスタが返す処理結果が不安定になります。 データの書き込みを伴うリクエストとは、具体的には、クラスタ内のデータを変更する以下のコマンドです: @@ -174,109 +164,22 @@ cronjobとして実行されるバッチスクリプトによって `load` コ [前項](../dump-restore/)から順番にチュートリアルを読んでいる場合、クラスタに流入しているリクエストはありませんので、ここでは特に何もする必要はありません。 -### 既存のクラスタから新しいreplicaへデータを複製する - -クラスタ alpha からクラスタ beta へデータを複製します。 -これは `droonga-engine-absorb-data` コマンドを使って行います。 -*新しいreplicaノード上で*、以下のようにコマンドを実行して下さい: - - (on 192.168.0.12) - # droonga-engine-absorb-data --source-host=192.168.0.10 \ - --receiver-host=192.168.0.12 - -`--receiver-host` オプションに新しいreplicaノード自身のホスト名またはIPアドレスを指定しておく必要がある事に注意して下さい。 - ### 新しいreplicaをクラスタに参加させる -データを正しく複製できたら、新しいreplicaを既存のクラスタに参加させます。 -新たにクラスタに参加するノード `192.168.0.12` 上で、以下のようにして `catalog.json` を更新して下さい: +新しいreplicaノードを既存のクラスタに追加するには、*新しいreplicaノード自身の上で*`droonga-engine-join`コマンドを実行します: (on 192.168.0.12) - # droonga-engine-catalog-modify --source=~/droonga/catalog.json \ - --update \ - --add-replica-hosts=192.168.0.10,192.168.0.11 + # droonga-engine-join --replica-source-host=192.168.0.10 \ + --my-host=192.168.0.12 -すると、サーバのプロセスが新しい `catalog.json` を検知して、自動的に自分自身を再起動させます。 +以下の2つのオプションの指定が必須である事に注意して下さい。 -この時点で、理論上、部分的に重なり合う2つのDroongaクラスタが存在するようになりました。 - - * 2つのreplicaを含む既存のクラスタ「alpha」。 - * `192.168.0.10` - * `192.168.0.11` - * 3つのreplicaを含む新しいクラスタ。以下、*「charlie」*と仮称します。 - * `192.168.0.10` - * `192.168.0.11` - * `192.168.0.12` - -この事は、各クラスタに対する `system.status` コマンドの実行結果を見ると確認できます: + * `--replica-source-host` オプションで、クラスタ中の既存のノードの1つのホスト名またはIPアドレスを指定して下さい。 + * `--my-host` オプションで、その新しいreplicaノード自身のホスト名またはIPアドレスを指定して下さい。 -~~~ -(for the cluster alpha) -# curl "http://192.168.0.10:10041/droonga/system/status" -{ - "nodes": { - "192.168.0.10:10031/droonga": { - "live": true - }, - "192.168.0.11:10031/droonga": { - "live": true - } - } -} -# curl "http://192.168.0.11:10041/droonga/system/status" -{ - "nodes": { - "192.168.0.10:10031/droonga": { - "live": true - }, - "192.168.0.11:10031/droonga": { - "live": true - } - } -} -~~~ - -`192.168.0.10` と `192.168.0.11` の `catalog.json` には何も変更がないため、コマンドの実行結果は依然として2つのノードから構成されるクラスタ alpha の情報を返します。 -クラスタ alpha へ流入するリクエストは、まだ新しい replica である `192.168.0.12` には配送されません。 - -しかし、新しいノード `192.168.0.12` は新しい `catalog.json` を持っています。 -他の2つの既存ノードがその事を知らなくても、このノードはクラスタ charlie が3つのノードを含んでいる事を知っています： - -~~~ -(for the cluster charlie) -# curl "http://192.168.0.12:10041/droonga/system/status" -{ - "nodes": { - "192.168.0.10:10031/droonga": { - "live": true - }, - "192.168.0.11:10031/droonga": { - "live": true - }, - "192.168.0.12:10031/droonga": { - "live": true - } - } -} -~~~ - -「beta」と仮称した一時的なクラスタが姿を消している事に注意してください。 - -次に、他のノードの既存の `catalog.json` を以下のようにして更新します: - - (on 192.168.0.10, 192.168.0.11) - # droonga-engine-catalog-modify --source=~/droonga/catalog.json \ - --update \ - --add-replica-hosts=192.168.0.12 - -コピー先のノードのサーバが新しい `catalog.json` を認識して、自動的に再起動します。 - -この時点で、Droongaクラスタは1つだけ存在する状態となっています。 - - * 3つのreplicaを含む新しいクラスタ「charlie」。 - * `192.168.0.10` - * `192.168.0.11` - * `192.168.0.12` +コマンドを実行すると、自動的に、クラスタのデータが新しいdeplicaノードへと同期され始めます。 +データの同期が完了すると、ノードが自動的に再起動してクラスタに参加します。 +すべてのノードの`catalog.json`も同時に更新され、この時点をもって、新しいノードは晴れてそのクラスタのreplicaノードとして動作し始めます。 この事は、`system.status` コマンドの結果を見ると確認できます: @@ -295,41 +198,8 @@ cronjobとして実行されるバッチスクリプトによって `load` コ } } } -# curl "http://192.168.0.11:10041/droonga/system/status" -{ - "nodes": { - "192.168.0.10:10031/droonga": { - "live": true - }, - "192.168.0.11:10031/droonga": { - "live": true - }, - "192.168.0.12:10031/droonga": { - "live": true - } - } -} -# curl "http://192.168.0.12:10041/droonga/system/status" -{ - "nodes": { - "192.168.0.10:10031/droonga": { - "live": true - }, - "192.168.0.11:10031/droonga": { - "live": true - }, - "192.168.0.12:10031/droonga": { - "live": true - } - } -} ~~~ -いずれのノードも同じ結果を返します。 - -「alpha」と仮称した古いクラスタが姿を消している事に注意してください。 -この時、2つのreplicaからなる古いクラスタの代わりとして、新しいクラスタ「charlie」は3つのreplicaのもとで完璧に動作しています。 - ### 書き込みを伴うリクエストの流入を再開する さて、準備ができました。 Modified: tutorial/1.0.4/add-replica/index.md (+28 -161) =================================================================== --- tutorial/1.0.4/add-replica/index.md 2014-06-27 22:26:10 +0900 (0a423c6) +++ tutorial/1.0.4/add-replica/index.md 2014-06-28 04:25:16 +0900 (d0863a9) @@ -59,15 +59,21 @@ First, prepare a new computer, install required softwares and configure them. # apt-get install -y ruby ruby-dev build-essential nodejs nodejs-legacy npm # gem install droonga-engine # npm install -g droonga-http-server + +For the new node, you have to copy the `catalog.json` from existing node of the cluster. + + (on 192.168.0.12) # mkdir ~/droonga + # scp 192.168.0.10:~/droonga/catalog.json ~/droonga/ -For the new node, you have to setup a `catalog.json` includes only one node, based on the existing one on another node. +Note, you cannot add a non-empty node to an existing cluster. +If the computer was used as a Droonga node in old days, then you must clear old data at first. (on 192.168.0.12) + # kill $(cat $PWD/droonga-engine.pid) + # rm -rf ~/droonga + # mkdir ~/droonga # scp 192.168.0.10:~/droonga/catalog.json ~/droonga/ - # droonga-engine-catalog-modify --source=~/droonga/catalog.json \ - --update \ - --hosts=192.168.0.12 Let's start the server. @@ -87,20 +93,12 @@ Let's start the server. --daemon \ --pid-file=$DROONGA_BASE_DIR/droonga-http-server.pid -Then there are two separate Droonga clusters on this time. - - * The existing cluster including two replicas. - Let's give a name *"alpha"* to it, for now. - * `192.168.0.10` - * `192.168.0.11` - * The new cluster including just one replica. - Let's give a name *"beta"* to it, for now. - * `192.168.0.12` +Currently, the new node doesn't work as a node of the cluster, because it doesn't appear in the `catalog.json`. +Even if you send requests to the new node, it just forwards all of them to other existing members of the cluster. You can confirm that, via the `system.status` command: ~~~ -(for the cluster alpha) # curl "http://192.168.0.10:10041/droonga/system/status" { "nodes": { @@ -123,33 +121,23 @@ You can confirm that, via the `system.status` command: } } } -~~~ - -`192.168.0.10` and `192.168.0.11` are members of the cluster alpha, so they return same result. -`192.168.0.12` doesn't appear in the result because it is not a member of the cluster alpha. - -On the other hand, `192.168.0.12` returns a result like: - -~~~ -(for the cluster beta) # curl "http://192.168.0.12:10041/droonga/system/status" { "nodes": { - "192.168.0.12:10031/droonga": { + "192.168.0.10:10031/droonga": { + "live": true + }, + "192.168.0.11:10031/droonga": { "live": true } } } ~~~ -It is a result for the cluster beta, so `192.168.0.10` and `192.168.0.11` don't appear. - - ### Suspend inpouring of "write" requests -Before starting duplication of data, you must suspend inpouring of "write" requests to the cluster alpha, because we have to synchronize data in clusters alpha and beta completely. -Otherwise, the new added replica node will contain incomplete data. -Because data in replicas will be inconsistent, results for any request to the cluster become unstable. +Before starting to change cluster composition, you must suspend inpouring of "write" requests to the cluster, because we have to synchronize data to the new replica. +Otherwise, the new added replica will contain incomplete data and results for requests to the cluster become unstable. What's "write" request? In particular, these commands modify data in the cluster: @@ -168,110 +156,22 @@ If you put a fluentd as a buffer between crawler or loader and the cluster, stop If you are reading this tutorial sequentially after the [previous topic](../dump-restore/), there is no incoming requests, so you have nothing to do. -### Duplicate data from the existing cluster to the new replica - -Duplicate data from the cluster alpha to the cluster beta. -It can be done by the command `droonga-engine-absorb-data`. -Run it *on the new replica node*, like: +### Joining a new replica node to the cluster - (on 192.168.0.12) - # droonga-engine-absorb-data --source-host=192.168.0.10 \ - --receiver-host=192.168.0.12 - -Note that you must specify the host name or the IP address of the new replica node itself, via the `--receiver-host` option. - -### Join the new replica to the cluster - -After the duplication is successfully done, join the new replica to the existing clster. -Update the `catalog.json` on the newly joining node `192.168.0.12`, like: +To add a new replica node to an existing cluster, you just run a command `droonga-engine-join` *on the new replica node itself*, like: (on 192.168.0.12) - # droonga-engine-catalog-modify --source=~/droonga/catalog.json \ - --update \ - --add-replica-hosts=192.168.0.10,192.168.0.11 - -The server process detects new `catalog.json` and restats itself automatically. - -Then there are two overlapping Droonga clusters theoretically on this time. - - * The existing cluster "alpha", including two replicas. - * `192.168.0.10` - * `192.168.0.11` - * The new cluster including three replicas. - Let's give a name *"charlie"* to it, for now. - * `192.168.0.10` - * `192.168.0.11` - * `192.168.0.12` - -You can confirm that, via the `system.status` command for each cluster: - -~~~ -(for the cluster alpha) -# curl "http://192.168.0.10:10041/droonga/system/status" -{ - "nodes": { - "192.168.0.10:10031/droonga": { - "live": true - }, - "192.168.0.11:10031/droonga": { - "live": true - } - } -} -# curl "http://192.168.0.11:10041/droonga/system/status" -{ - "nodes": { - "192.168.0.10:10031/droonga": { - "live": true - }, - "192.168.0.11:10031/droonga": { - "live": true - } - } -} -~~~ + # droonga-engine-join --replica-source-host=192.168.0.10 \ + --my-host=192.168.0.12 -Because `catalog.json` on nodes `192.168.0.10` and `192.168.0.11` have no change, the result says that there is still the cluster alpha with only two nodes. -Any incoming request to the cluster alpha is never delivered to the new replica `192.168.0.12` yet. +Note, you must specify two options for the command always. -However, the new node `192.168.0.12` has a new `catalog.json`. -It knows the cluster charlie includes three nodes, even if other two existing nodes don't know that: + * You must specify the host name or the IP address of an existing node of the cluster, via the `--replica-source-host` option. + * You must specify the host name or the IP address of the new replica node itself, via the `--my-host` option. -~~~ -(for the cluster charlie) -# curl "http://192.168.0.12:10041/droonga/system/status" -{ - "nodes": { - "192.168.0.10:10031/droonga": { - "live": true - }, - "192.168.0.11:10031/droonga": { - "live": true - }, - "192.168.0.12:10031/droonga": { - "live": true - } - } -} -~~~ - -Note that the temporary cluster named "beta" is gone. - -Next, update existing `catalog.json` on other nodes, like: - - (on 192.168.0.10, 192.168.0.11) - # droonga-engine-catalog-modify --source=~/droonga/catalog.json \ - --update \ - --add-replica-hosts=192.168.0.12 - -Servers detect new `catalog.json` and restart themselves automatically. - -Then there is just one Droonga clusters on this time. - - * The new cluster "charlie",including three replicas. - * `192.168.0.10` - * `192.168.0.11` - * `192.168.0.12` +Then the command automatically starts to synchronize all data of the cluster to the new replica node. +After data is successfully synchronized, the node restarts and joins to the cluster automatically. +All nodes' `catalog.json` are also updated, and now, yes, the new node starts working as a replica in the cluster. You can confirm that, via the `system.status` command: @@ -290,41 +190,8 @@ You can confirm that, via the `system.status` command: } } } -# curl "http://192.168.0.11:10041/droonga/system/status" -{ - "nodes": { - "192.168.0.10:10031/droonga": { - "live": true - }, - "192.168.0.11:10031/droonga": { - "live": true - }, - "192.168.0.12:10031/droonga": { - "live": true - } - } -} -# curl "http://192.168.0.12:10041/droonga/system/status" -{ - "nodes": { - "192.168.0.10:10031/droonga": { - "live": true - }, - "192.168.0.11:10031/droonga": { - "live": true - }, - "192.168.0.12:10031/droonga": { - "live": true - } - } -} ~~~ -Any node returns same result. - -Note that the old cluster named "alpha" is gone. -Now the new cluster "charlie" with three replicas works perfectly, instead of the old one with two replicas. - ### Resume inpouring of "write" requests OK, it's the time. -------------- next part -------------- HTML����������������������������...Download