Shardingの設定

based on v72 (2010/12/29 更新) - オリジナル

Introduction

このドキュメントでは基本的なshardingクラスターのセットアップ手順を紹介していきます。shardingクラスターは最小構成でも3つのコンポーネントが必要です；

1. 2つ以上のshard
2. 1つ以上のconfigサーバー
3. mongos ルーティングプロセス

テストの目的では、上記の全てのコンポーネントを1つのサーバーに集約させることも可能です。プロダクション環境では、いくつかのserver configurationsを持つことが出来ます。

1度、shards・configサーバー・ mongos プロセスが起動すれば、shardingを可能にするためにconfigurationを行いますが、簡単な一連のコマンドを発行するだけで済みます。ここまでのクラスターの構築が完了すれば、個々のコレクションをshardingすることができます。

このドキュメントは詳細まで述べられています。もしより簡単な説明を好むのならばサンプルコードを読んで理解するのが適切です、sample shard configurationを参照して下さい。もしシングルマシンでテストクラスターを素早く構築してみたいと思っているならば、python sharding scriptがそれを実現してくれるでしょう。

Shardingコンポーネント

始めに、shards・configサーバー・ mongos プロセスを起動します。

Shardサーバー

コマンドラインから mongod をshardサーバー上で起動する際に --shardsvr オプションを付けて下さい。また自動フェイルオーバー機能をサポートする場合はReplica setが必要になります。 replica setsによって詳しい情報を確認して下さい。

Replica pairsはshardingをサポートしていない事に注意して下さい。

簡単なテストを行うには自動フェイルオーバー機能は必要としませんので、shardサーバーごとに1つの mongod プロセスをを稼働させる事をお薦めします。

Configサーバー

configサーバー上で mongod を立ち上げます。この際には --configsvr オプションを使用します。もしテスト環境であるばらば、configサーバーは1つで良いでしょう。プロダクション環境では複数ある内の3つのconfigサーバーを立ち上げると良いでしょう。

Note: configサーバーは互いにデータを同期する独自のプロトコル（もし用意するconfigサーバーの台数を気にするなら3台が適切です、synchronous replication protocolはその数で最適化されています。）を備えています。ですので --replSet オプションは使用しないで下さい。

mongos ルーター

選択したサーバー群に mongos を起動します。その際に --configdb オプションによって、configデータベースの場所を指定します。

Shardクラスターの設定

以上のshardコンポーネントが全て稼働すれば、shardingコマンドを発行します。この一連のコマンドはjsスクリプトで記述することで自動化することが可能です。

mongos プロセスの1つに接続し、コマンドを発行する前に admin データベースに接続します。

mongos は発行されたコマンドをクラスター上の全てのマシンに伝搬します。そしてその後もコマンドがメタデータを変更した場合は、mongosは全てのconfigサーバーを更新します。ですので、 mongos プロセスがいくつ立ち上がっているのに関わらず、コマンドはそれらの内のたった1台のみに発行すれば良いことになります。

mongos 上でadminデータベースに接続方法は以下になります：

./mongo <mongos-hostname>:<mongos-port>/admin 
> db 
admin 

Shardsの追加

各々のshardは1つ以上のサーバーから構成されますが（replica setsを参照して下さい）、テスト環境では1つの mongod プロセスだけが必要になります。

shardを追加する場合はクラスターのconfigurationで明示的に addshard コマンドを使用します：

> db.runCommand( { addshard : "<serverhostname>[:<port>]" } ); 
{"ok" : 1 , "added" : ...} 

このコマンドはクラスター内の各shardで1度だけ実行します。

もし1つ以上のshardがreplica setsを構成している場合は、replicaSetName/<serverhostname>[:port][,serverhostname2[:port],...]のようにreplica setの名前を特定してそのメンバーを記述します：

> db.runCommand( { addshard : "foo/<serverhostname>[:<port>]" } ); 
{"ok" : 1 , "added" : "foo"} 

mongod/replica set内に存在するデータベースやコレクションはクラスターに含まれることになります。それらのデータベースはshardingよりもmongod/replica setとして"優先的に"登録されますので、これらのコレクションに対してはshardingは行われません。 (しかしshardCollectionコマンドを発行することができます。）

オプションパラメーター

name
各々のshardは name オプションによって名前を付けることができます。名前が与えられなかった場合は自動でそれが割り振られます。

maxSize
addshard コマンドは maxSize オプションパラメーターを持ちます。このパラメーターによってshardに割り振るディスクスペースの上限をMB単位で指定する事が出来ます。もし指定しない場合は全てのディスクスペースを使用します。このパラメーターは特定のshardサーバーに大量のデータが保存されるのを防止したい場合に有用です。

例：

> db.runCommand( { addshard : "sf103", maxSize:100000 } ); 

登録されているshardの列挙

現在設定されているshardを確認したい場合は、 listshards コマンドを実行します：

> db.runCommand( { listshards : 1 } ); 

これによってシステムに登録されている全てのサーバーを確認することができます。

Shardの削除

Shardが完全に削除される前に、そのshardに保存されている全てのchunkを残りのshardに移動させなければなりません。'removeshard' コマンドは全てのchunkが移動されるまで "draining" 状態になっています。shardの削除を行うには次のコマンドを発行します：

> db.runCommand( { removeshard : "localhost:10000" } ); 
{ msg : "draining started succesfully" , state: "started" , shard :"localhost:10000" , ok : 1 

その後"draining mode"に入ります。chunkはゆっくり時間をかけてshardから取り除かれていきますので、その間にシステムにそれを阻害するような操作は行わないで下さい。"draining mode"はバックグラウンドで実行されていて、この状態の内に'removeshard'コマンドを再度発行すると現在の進行状況のレポートが表示されます：

> db.runCommand( { removeshard : "localhost:10000" } ); 
{ msg: "draining ongoing" ,  state: "ongoing" , remaining : { chunks :23 , dbs : 1 }, ok : 1 } 

削除対象のshardのchunkは自動的に削除されますが、chunk内に含まれるをデータベース --'dbs'キーの値がその数をカウントしています – は手動で移動しなければなりません。（これは現在の制約となっており、将来的にこの制約は無くなる予定です。）もし'removeshard'の出力が参照する場所を確認したい場合は、printShardingStatusコマンドを実行します。その中のshardの"primary"の値が分割されていないデータベースの場所を表示してくれます。そこでshardの削除（chunkの移動）には次のコマンドが必要になります：

> db.runCommand( { moveprimary : "test", to : "localhost:10001" } ); 
{ "primary" : "localhost:10001", "ok" : 1 } 

shardが空になった後に'removeshard'コマンドを再度発行すると、全てのメタデータがクリーンアップされた事を通知する情報が表示されます：

> db.runCommand( { removeshard : "localhost:10000" } ); 
{ msg: "remove shard completed succesfully" , stage: "completed", host: "localhost:10000", ok : 1 } 

"removeshard"コマンドがこの状態をレポートした場合は処理が完了したことになります。

データベース単位でのshardingの開始

1つ以上のshardを追加すれば、データベース単位でのshardingが可能になります。これは重要なステップで、これ無しにはそのデータベース上の全てのデータは同じshardに保存されてしまうことになります。

> db.runCommand( { enablesharding : "<dbname>" } ); 

一度データベースのshardingを実行すれば、 mongos はデータベース内の異なるコレクションを異なるshardに配置します。しかし同じコレクション内のデータは全て1つのshardに存在することになります。データ単位での完全なshardingを可能にするためには、個々のコレクション単位でのshardingを行う必要があります。

コレクション単位でのshardingの開始

shardcollection コマンドがコレクションのshardingを可能にします。コレクションをshardingする場合にはshardキーを指定する必要があります。もしコレクション内にデータが存在する場合は、mongoは事前のインデックスの作成を必要とします。（これによってchunkingプロセスが高速になります。）このインデックス作成を手動で行わない場合は自動で作成してくれます。

 > db.runCommand( { shardcollection : "<namespace>", 
key : <shardkeypatternobject> }); 

重要な警告： "shardcollection"コマンドを実行すると、対象となったコレクションを指定したshardキーで「shardingされたコレクション」として記録されます。このコマンドが一度実行されると、例えまだ全てのデータが同じshardにあったとしても、shardingを止める方法もshardキーを変更すること方法も存在しません。もしshardingを解除したい場合は、コレクションをdropしてから（バックアップを忘れないで下さい）、再作成してバックアップしたデータをロードし直して下さい。

例えば、 test データベースに保存されたGridFS chunks コレクションをshardingしたい場合を考えます。 files_id をshardキーにしたい時には shardcollection コマンドを以下のように実行します：

 > db.runCommand( { shardcollection : "test.fs.chunks", key : { files_id : 1 } } ) 
{"ok" : 1} 

shardingされたコレクションには1つだけユニークなインデックスを持つ事が可能です。そのコレクションには他のユニークなインデックスは存在しません。（_id を除く）

もちろん、ユニークなshardキーはGridFS chunks コレクションでは意味をなしませんが、例えばshardingキー：emailでshardingされたusersコレクションには必要になります：

db.runCommand( { shardcollection : "test.users" , key : { email : 1 } , unique : true } ); 

関連する例とドキュメント

例

• Sample configuration session
• 次の例はテストの目的で1つのマシンで構成される単純なshardのセットアップを実行するスクリプトです：Sharding JS Test.

ドキュメント

• Sharding Administration
• Notes on TCP Port Numbers