ShardingとFailover

based on v9 (2010/12/31 更新) - オリジナル

適切な設定の元ではMongoDBのshardクラスターは単一障害点を持ちません。

このドキュメントでは、shardクラスターのコンポーネント内で潜在的に起こりうる障害のシナリオをいくつか記述し、各シチュエーションにおいてそれをどうハンドリングするかを提案します。

1. mongos ルーティングプロセスにおける障害

mongos ルーティングプロセスは各アプリケーションサーバー内でも動作しますので、アプリケーションサーバーは（同サーバー内の）単独に mongos プロセスを通じて通信を行うようになります。 mongos プロセスは永続的ではなく、むしろ起動時に指定したconfigサーバーのconfigデータに完全に依存します。

これはアプリケーションサーバーの1つに障害があり mongos プロセスの1つが機能しなくなった場合でもshardクラスタ全体には影響を与えない事、そして他の全てのアプリケーションサーバーは変わらず機能し続けることを意味します。復旧は単純に新しいアプリケーションサーバーと mongos プロセスをスタートさせれば良いだけです。

2. Shard内の mongod サーバーの単一障害点

各shardは1グループ n サーバーからなるReplica set を含みます。もしReplica set内の1台のサーバーに障害が起こっても、shard上の読み/書きは許可されたままです。さらには、replicaはオプションでReturnを返す前にReplicationへの書き込み強制的に行う事ができますので、1つのサーバーの障害によってデータが失われることもありません。これはAmazonのDynamoにおける W to 2セッティングに似ています。

Replica setはMongoDB v1.6. で利用できるようになりました。詳細はreplica set internalsかjira issueをフォローするようにして下さい。

3. shard内の全ての mongod サーバーの障害

もしshard内の全てのReplicaがダウンしてしまった場合、そのshard内のデータは利用不可能になります。しかしながら、他のshardにおけるオペレーションは正常に動作します。なぜそのような動作をするのかはglobal and targeted operationsを読んで下さい。

もしshardに対してReplica setを構成している場合、少なくとも1つ以上のメンバーは別のデータセンターに置くようにして下さい。そうすれば完全にshardがダウンしてしまう可能性は大幅に減少します。これは最大限の冗長性を確保するためのconfigurationとして推奨される方法です。

4. Configサーバーの障害

A production shard cluster will have three config server processes, each existing on a separate machine. Writes to config servers use a two-phase commit to ensure an atomic and replicated transaction of the shard cluster's metadata.

障害の起きたconfigサーバー上では、システムのメタデータはリードオンリーになります。システムは機能し続けますが、chunkの分割や移動は行われなくなります。ただほとんどのユースケースにおいて、chunkのメタデータが変更される事はほとんどありませんので、この障害によるダメージはそれほど大きくありません。

ダウンしたconfigサーバーが管理者によって、適度な時間で（1日とか）復旧するのは重要です。そうしないと、migrateできないために、アンバランスなshardができてしまう可能性があります（前述しましたが、この状況は多くのプロダクション環境において希にしか起こりません）。