MongoDB FAQ #5: レプリケーションおよびレプリカセット

MongoDB はレプリカセットをサポートしており、50ノードまで保持できます。

MongoDB はマスタースレーブ・レプリケーションもサポートしていますが、レプリケーショントポロジーとしてお勧めするのはレプリカセットです。しかしながら、デプロイが50ノード以上を必要とする場合はマスタースレーブ・レプリケーションを使用しなくてはなりません。

はい。

例えば、デプロイが（米国）東海岸のデータセンターにプライマリー（ストレージ）およびセカンダリー（ストレージ）を保持しつつ、西海岸のデータセンターにディザスタリカバリーとしてセカンダリーメンバーを保持できます。

こちらもご覧ください： Deploy a Geographically Redundant Replica Set

はい。しかし接続失敗や待ち時間が長い場合はレプリケーションできません。

ネットワークが不安定な場合、セットメンバーは他のセットメンバーに再接続を試みます。これには管理者の介入は不要です。しかしながら、レプリカセットのノード間のネットワーク接続が大変遅い場合、ノードのメンバーがレプリケーションについていけず、レプリケーションが完了しない可能性があります。

こちらもご参照ください: Replica Set Elections

ジャーナリングは、クラッシュした際のリカバリーを促進します。ジャーナリング以前は、クラッシュ時にはdatabase repairs もしくはデータ全体の再同期が通常必要でした。いずれの場合も速度は遅く、database repairs は不確実でした。

ジャーナリングは(サーバの)電源喪失の対策として特に有益です。レプリカセットが一つのデータセンターもしくは一つの(電源ユニットに依存する)サーバにある場合、大変役に立ちます。

ジャーナリング付きでレプリカセットを実行すると、(レプリカセットの同期を健全に保つための)追加の操作なしで mongod インスタンスを安全に再起動できます。

注： ジャーナリングは書込み操作用にリソースオーバーヘッドを必要としますが、　読込み操作には影響を与えません。

ジャーナリングは、MongoDB v2.0 以上の全64-bit ビルドでデフォルトで有効化されています。

アービターはコレクションのコンテンツを受け取ることはありませんが、レプリカセットと以下のデータを交換します：

• レプリカセットとアービターを認証するのに使用される証明書。これらの情報交換は暗号化されています。
• レプリカセットの設定データおよび voting データ。この情報は暗号化されません。証明書の交換のみ暗号化されています。

MongoDB デプロイがTLS/SSL を使用している場合、アービターとレプリカセットの他のメンバーとのコミュニケーションは暗号化通信によって安全に行われます。

詳細は、「mongod および mongos をTLS/SSL 用に設定する」をご参照ください。

こちらもご参照ください: The overview of Arbiter Members of Replica Sets.

はい。

oplogサイズの違い、ストレージフラグメンテーションのレベルの違い、MongoDBデータファイルの事前割り当て等によって、ノード間のストレージ使用率が異なります。ストレージ使用率の差は、異なる時間にメンバーを追加するときに最も顕著になります。

いいえ、できません。

the Restore a Replica Set from MongoDB Backups チュートリアルに記載されているバックアップおよびリストア手順を使用することで、お好みのネームで新規レプリカセットを作成できます。元のレプリカセットと新規レプリカセットの同等性を担保するために、ダウンタイムが発生します。