Skip to content
This repository
Browse code

update doc/*

git-svn-id: svn+ssh://code.etolabo.org/usr/etolabo/var/svn/ficia/kumofs/trunk@2562 b300df90-00d7-44b1-9271-3fa3ef26909a
  • Loading branch information...
commit c0d6621a03c7f85f2ba25a5a336ee8dc2515b3e3 1 parent 3959e05
authored August 19, 2009
2  doc/user.css
@@ -2,7 +2,7 @@
2 2
 body {
3 3
 	margin: 0 auto;
4 4
 	font-size: 94%;
5  
-	line-height: 150%;
  5
+	line-height: 180%;
6 6
 	max-width: 50em;
7 7
 }
8 8
 
2  doc/user.html
@@ -359,7 +359,7 @@ <h2 id="chapter_7">トラブルと復旧</h2>
359 359
     <h3 id="section_7_1">kumo-serverが1台か2台ダウンした</h3>
360 360
     <p>kumo-serverが1台ダウンすると、一部のkey-valueペアの複製が1つ減った状態のまま動作し続けます。2台ダウンすると、1つか2つ減った状態のままになります。この状態から複製の数を3つに戻すには、kumo-serverを復旧させたあとkumoctlコマンドを使って再度登録するか、ダウンしたkumo-serverを完全に切り離します。</p>
361 361
     <p>まずはkumoctlコマンドを使ってどのkumo-serverに障害が発生しているのかを確認します:</p>
362  
-    <pre class="code_sh">[xx]$ kumoctl m1 status    # kumo-managerのアドレスを指定して状態を取得
  362
+    <pre class="code_sh">[xx]$ kumoctl m1 status    # m1はkumo-managerのアドレス
363 363
 hash space timestamp:
364 364
   Wed Dec 03 22:15:35 +0900 2008 clock 50
365 365
 attached node:
BIN  doc/user.pdf
Binary file not shown
7  doc/wiki.ja.md
Source Rendered
@@ -228,7 +228,7 @@ kumofsはデータを複数のkumo-serverに分散して保存します。ある
228 228
 -3台以上のkumo-serverのHDDが同時に壊れた
229 229
 -そのほか何らかの原因でデータが消失した
230 230
 
231  
-バックアップを作成するには、*kumoctl* コマンドの **backup** サブコマンドを使います。するとそれぞれのkumo-serverでデータベースファイルのバックアップが作成されるので、これをscpなどを使って1台のホストに集め、**kumomergedb** コマンドを使って1つのデータベースファイルに結合します。
  231
+バックアップを作成するには、*kumoctl* コマンドの **backup** サブコマンドを使います。するとそれぞれのkumo-serverでデータベースファイルのバックアップが作成されるので、これをscpコマンドなどを使って1台のホストに集め、**kumomergedb** コマンドを使って1つのデータベースファイルに結合します。
232 232
 
233 233
 バックアップから復旧するときは、バックアップしておいたデータベースファイルをすべてのサーバーに配り、kumo-serverを起動します。このときすべてのkumo-serverは同じデータを持っており、そのkumo-serverが持っている必要が無いデータまで持っています。その後 *kumoctl* コマンドの **attach** サブコマンドを使ってkumo-serverを登録すると、不要なデータが削除され、整合性のある状態に回復します。
234 234
 
@@ -254,7 +254,7 @@ kumo-serverが1台ダウンすると、一部のkey-valueペアのレプリカ
254 254
 
255 255
 **(fault)** と表示されているkumo-serverに障害が発生しています。
256 256
 
257  
-kumo-serverを復旧させて元の台数に戻すときは、まずデータベースファイルを削除するか移動させておき、その後でkumo-serverプロセスを再起動します。古いデータベースファイルが残っていると削除したはずのデータが復活してしまう可能性があります。
  257
+kumo-serverを復旧させて元の台数に戻すときは、**まずデータベースファイルを削除するか移動させておき、その後でkumo-serverプロセスを再起動します**。古いデータベースファイルが残っていると削除したはずのデータが復活してしまう可能性があります。
258 258
 kumo-serverを再起動するとkumoctlの表示は以下のようになります:
259 259
 
260 260
     [       ]$ kumoctl m1 status
@@ -307,7 +307,7 @@ kumo-serverが3台以上ダウンすると、一部のデータにアクセス
307 307
 
308 308
 ### kumo-managerがダウンした
309 309
 
310  
-2台で冗長構成を取っているときに片方のkumo-managerがダウンしまった場合は、まずkumo-managerを再起動してください。kumo-managerのIPアドレスは障害発生前と同じにしておく必要があります。次に残っていた方のkumo-managerに対して*kumoctl*コマンドの**replace**サブコマンドを発行してください。これで2台のkumo-managerの情報が同期されます。
  310
+2台で冗長構成をとっているときに片方のkumo-managerがダウンしまった場合は、まずダウンしたkumo-managerを再起動してください。kumo-managerのIPアドレスは障害発生前と同じにしておく必要があります。次に残っていた方のkumo-managerに対して*kumoctl*コマンドの**replace**サブコマンドを発行してください。これで2台のkumo-managerの情報が同期されます。
311 311
 
312 312
 kumo-managerがすべてダウンしてしまってもシステムを止めることなく復旧できます。この場合は、まずダウンしているkumo-serverがいるときは再起動してください。次にkumo-managerをすべて再起動させてください。最後に*kumoctl*コマンドの**attach**サブコマンドを使ってkumo-serverを登録します。これで整合性のある状態に回復します。
313 313
 
@@ -356,6 +356,7 @@ Tokyo Cabinetのハッシュデータベースのチューニングによって
356 356
 
357 357
 Tokyo Cabinetのパラメータのうち、拡張メモリマップのサイズ(xmsiz)とキャッシュ機構(rcnum)はkumo-serverのコマンドライン引数で指定します。kumo-serverの **-s** オプションで、データベースファイル名の後ろに **#xmsiz=XXX** と指定すると拡張メモリマップのサイズを指定できます。**#rcnum=XXX** と指定するとキャッシュ機構を有効化できます。
358 358
 
  359
+    [on svr1]$ tchmgr create database.tch 1000000
359 360
     [on svr1]$ kumo-server -v -m mgr -l svr1 -s "database.tch#xmsiz=600m#rcnum=4k"
360 361
 
361 362
 

0 notes on commit c0d6621

Please sign in to comment.
Something went wrong with that request. Please try again.