mongosync 動作
項目一覧
mongosync バイナリーは、Cluster-to-Cluster Sync で使用されるプライマリ プロセスです。mongosync は、あるクラスターから別のクラスターにデータを移行し、クラスターを継続的に同期させることができます。
mongosyncプロセスの概要については、「 mongosyncについて 」を参照してください。
mongosync を使い始めるには、「クイック スタート ガイド」を参照してください。
詳細については、状況に応じてインストールまたはmongosyncの接続のページを参照してください。
設定
クラスターの独立性
mongosync は、ソースクラスターと宛先クラスター間で収集データを同期します。 mongosyncはユーザーまたはロール を同期しません。 その結果、各クラスターで異なるアクセス権限を持つユーザーを作成できます。
構成ファイル
mongosyncのオプションは、YAML 構成ファイルで設定できます。 --configオプションを使用します。 例:
$ mongosync --config /etc/mongosync.conf
利用可能な設定の詳細については、「構成」を参照してください。
クラスターとコレクションのタイプ
シャーディングされたクラスター
Cluster-to-Cluster Syncは、シャーディングされたクラスター間のレプリケーションをサポートします。個々のシャードはソースクラスターから宛先クラスターに並列で複製されますが、チャンクの移行または同様のソース更新により、レプリケーション中にドキュメントが新しいソースシャードに移動される可能性があります。
レプリケーション中にドキュメントがソース シャード間で移動した場合でも、Cluster-to-Cluster Sync により、宛先クラスターで結果整合性保証が維持されます。 詳細については、「シャーディングされたクラスターの同期 」を参照してください。
複数のクラスター
ソースクラスターを複数の宛先クラスターと同期するには、宛先クラスターごとに 1 つの mongosync インスタンスを使用します。詳細については、「複数クラスターの制限事項」を参照してください。
上限付きコレクション
1.3.0 以降、Cluster-to-Cluster Sync では、上限付きコレクションが一部制限付きでサポートされます。
convertToCappedはサポートされていません。convertToCappedを実行すると、mongosyncはエラーで終了します。cloneCollectionAsCappedはサポートされていません。
ソースクラスター上の上限付きコレクションは、同期中に正常に動作します。
同期中に、宛先クラスター上の上限付きコレクションに一時的な変更が加えられます。
ドキュメントの数に制限はありません。
最大コレクション サイズは 1 PB です。
mongosync は、コミット時に最大ドキュメント数と最大ドキュメント サイズの元の値を復元します。
読み取りと書込み
書き込みブロッキング
mongosync デフォルトでは書込みブロックは有効になりません。書込みブロックを有効にすると、 mongosyncでは以下の書き込みがブロックされます。
同期中の宛先クラスター上。
ソースクラスターで
commitを受信したとき
書込みブロックを有効にするには、start APIを使用してenableUserWriteBlockingをtrueに設定します。同期開始後に書込みブロックを有効にすることはできません。
後でリバース同期を使用する場合は、 mongosyncを起動するときに書込みブロックを有効にする必要があります。
ユーザー権限
enableUserWriteBlocking を設定するには、 mongosync ユーザーに、setUserWriteBlockMode および bypassWriteBlockingMode ActionTypes を含んだロールが必要です。
注意
enableUserWriteBlockingを使用する場合、書込み (write) は bypassWriteBlockingMode ActionType を持たないユーザーに対してのみブロックされます。この ActionType を持つユーザーは書き込みを実行できます。
許容される読み取り
ソースクラスターでの読み取り操作は常に許可されます。
/progress エンドポイントから canWrite が true というレポートがあった場合、ソースクラスターと宛先クラスターのデータはコンシステントです。
許容される書込み
mongosyncの状態を確認するには、 /progress API エンドポイントを呼び出します。/progress出力には、ブール値 canWriteが含まれます。
canWriteがtrueの場合、宛先クラスターは安全に書込み可能です。canWriteがfalseの場合、宛先クラスターには書込みを行わないでください。
mongosyncの同期中、ソースクラスターには安全に書込み可能です。canWriteがtrueである場合を除き、宛先クラスターには書込みを行わないでください。
読み取りと書き込み保証
デフォルトでは、 mongosyncソース クラスターの読み取りに対する読み取り懸念レベルを"majority"に設定します。宛先クラスターへの書き込みの場合、 mongosyncは書込み保証レベルを"majority"に j: true を用いて設定します
読み取り保証と書込み保証の構成と動作の詳細については、「読み取り保証（read concern）」と「書込み保証（write concern）」を参照してください。
読み込み設定 (read preference)
mongosync では、ソースクラスターと宛先クラスターに接続するときに primary 読み込み設定（read preference）が必要です。詳しくは、「読み込み設定（read preference）オプション」を参照してください。
継続的な同期に関する考慮事項
mongosyncを使用した継続的な同期のユースケースでは、ソースから宛先に切り替える前にmongosyncがコミットすることを確認します。
障害発生など、 mongosyncがコミットする前にソースクラスターがシャットダウンした場合、宛先クラスターはソースデータの一貫したスナップショットを持たない可能性があります。 詳細については、「整合性 」を参照してください。
注意
シャーディングされたクラスター
シャーディングされたクラスターで継続的な同期を実行している場合は、コミットされるまで同期の有効期間中にソースと宛先の両方でバランサーを停止する必要があります。
コレクションの特性に対する一時的な変更
mongosync は、同期中に次のコレクションの特性を一時的に変更します。 元の値はコミット プロセス中に復元されます。
変更 | 説明 |
|---|---|
Unique Indexes | ソースクラスター上のユニークインデックスは、デスティネーションクラスターでは非一意なインデックスとして同期されます。 |
TTL Indexes | 同期により、宛先クラスターの MAX_INTの値にexpireAfterSecondsが設定されます。 |
Hidden Indexes | 同期では、非表示のインデックスを非表示でないものとして複製します。 |
書き込みブロッキング | 書込みブロックを有効にすると、
詳しくは、「書込みブロック 」を参照してください。 |
上限付きコレクション | 同期により、Cappedコレクションが最大許容サイズに設定されます。 |
ダミー インデックス | 場合によっては、シャーディングされたコレクションや照合されたコレクションへの書込みをサポートするために、同期によって宛先にダミーのインデックスが作成される場合があります。 |
ローリング処理によるインデックスビルド
mongosync では、移行中にローリングインデックスのビルドはサポートされません。移行中にローリング方式でインデックスをビルドしないようにするには、次のいずれかの方法を使用して、宛先インデックスがソース インデックスと一致することを確認します。
移行する前に、ソースにインデックスをビルドします。
移行中にデフォルトのインデックス構築を使用してソースにインデックスをビルドします。
移行後に、宛先でインデックスをビルドします。
宛先クラスター
整合性
mongosync は、宛先クラスターで結果整合性をサポートします。 コミットするまで、宛先クラスターでは読み取り整合性が保証されません。 コミットする前に、ソースクラスターと宛先クラスターは特定の時点で異なる場合があります。 詳しくは、「継続的な同期に関する考慮事項 」を参照してください。
mongosyncが同期している間に、 mongosyncはソースから宛先に中継されるときに、書き込みの順序を変更したり、まとめたりすることができます。 特定のドキュメントの場合、書込みの合計数がソースと宛先で異なる場合があります。
トランザクションは、宛先クラスター上でアトミックに表示されない場合があります。 再試行可能な書き込みは、宛先クラスターでは再試行できない場合があります。
プロファイリング
ソース データベースでプロファイリングが有効になっている場合、MongoDB では <db>.system.profile という名前の特別なコレクションが作成されます。同期が完了した後、ソース データベースが後で削除された場合であっても、Cluster-to-Cluster Syncでは宛先から<db>.system.profileコレクションは削除されません。<db>.system.profileコレクションによって宛先のユーザー データの精度が変わることはありません。
ビュー
ビューを含むデータベースをソース上で削除すると、宛先では当該のデータベースに空の system.views コレクションが表示される場合があります。空のsystem.viewsコレクションによって宛先のユーザー データの精度が変わることはありません。
システム コレクション
Cluster-to-Cluster Sync では、システム コレクションは宛先クラスターにレプリケートされません。
ソース クラスターで dropDatabase コマンドを発行しても、この変更が宛先クラスターに直接適用されることはありません。代わりに、Cluster-to-Cluster Sync により、宛先クラスターのデータベース内のユーザー コレクションとビューが削除されます。ただし、そのデータベース上のシステム コレクションは削除されません。
たとえば、送信先クラスターでは、次のようになります。
削除操作は、ユーザーが作成した
system.jsコレクションには影響しません。プロファイリングを有効にすると、
system.profileコレクションは残ります。ソースクラスターでビューを作成してからデータベースを削除すると、レプリケートされた削除操作によりビューが削除されますが、空の
system.viewsコレクションが残ります。
このような場合、dropDatabase を複製すると、ユーザーが作成したコレクションはすべてデータベースから削除されますが、そのシステム コレクションは宛先クラスターに残ります。
UUID
mongosync 宛先クラスターに新しい UUIDを持つコレクションを作成します。ソースクラスターと宛先クラスターの UUID の間に関係はありません。アプリケーションにハードコードされた UUID が含まれている場合（MongoDB では非推奨）、移行したクラスターで適切に動作させるには、当該のアプリケーションのアップデートが必要になる場合があります。
ソート
mongosync 未定義の順序で宛先クラスターにドキュメントを挿入します。ソースクラスターからの自然なソート順序は保持されません。アプリケーションがドキュメントの順序に依存するにもかかわらずソート方法が未定義の場合、移行したクラスターで正しく動作させるには、当該のアプリケーションを更新して、期待されるソート順序を指定しなければならない場合があります。
パフォーマンス
回復力
mongosync 回復力があり、致命的でないエラーを処理できます。"error" ないしは "failure"という単語を含むログは、 mongosyncの障害やデータの破損を示すものではありません。たとえば、ネットワーク エラーが発生した場合、 mongosyncログに”error”という単語が含まれることがありますが、 mongosyncの同期は完了可能です。同期が完了しない場合は、mongosyncによって致命的なログエントリが書込まれます。
データ定義言語（DDL）操作
同期中に DDL 操作（db.createCollection() や db.dropDatabase() などのコレクションまたはデータベースに対して実行される操作）を使用すると、移行が失敗するリスクが高まり、mongosync のパフォーマンスに悪影響を及ぼす可能性があります。パフォーマンスを最大限高めるには、同期の進行中にソースクラスターで DDL 操作を実行しないようにします。
DDL 操作について詳しくは、「保留中の DDL 操作とトランザクション」を参照してください。