mongosync 動作

クラスターの独立性

mongosync は、ソースクラスターと宛先クラスター間で収集データを同期します。 mongosyncはユーザーまたはロール を同期しません。 その結果、各クラスターで異なるアクセス権限を持つユーザーを作成できます。

構成ファイル

mongosyncのオプションは、YAML 構成ファイルで設定できます。 --configオプションを使用します。 例:

$ mongosync --config /etc/mongosync.conf

利用可能な設定の詳細については、「構成」を参照してください。

シャーディングされたクラスター

Cluster-to-Cluster Syncは、シャーディングされたクラスター間のレプリケーションをサポートします。 mongosync は、ソースクラスターから宛先クラスターに個々のシャードを並列に複製します。ただし、mongosync はソースクラスターのシャーディング構成を保持しません。

db.adminCommand(
  {
    setAllowMigrations: “<db>.<collection>”,
    allowMigrations: false
  }
)

複数のクラスター

ソースクラスターを複数の宛先クラスターと同期するには、宛先クラスターごとに 1 つの mongosync インスタンスを使用します。詳細については、「複数クラスターの制限事項」を参照してください。

上限付きコレクション

1.3.0 以降、Cluster-to-Cluster Sync では、上限付きコレクションが一部制限付きでサポートされます。

• convertToCapped はサポートされていません。convertToCapped を実行すると、mongosync はエラーで終了します。

• cloneCollectionAsCapped はサポートされていません。

ソースクラスター上の上限付きコレクションは、同期中に正常に動作します。

同期中に、宛先クラスター上の上限付きコレクションに一時的な変更が加えられます。

• ドキュメントの数に制限はありません。

• 最大コレクション サイズは 1 PB です。

mongosync は、コミット時に最大ドキュメント数と最大ドキュメント サイズの元の値を復元します。

書き込みブロッキング

デフォルトでは 、mongosync は宛先クラスターで宛先のみの書込みブロックを有効にします。 mongosync/progress canWriteエンドポイントが をtrue であると報告する直前に、 は書込みブロックを解除します。/start enableUserWriteBlockingエンドポイントを使用して を"destinationOnly" に設定することで、宛先専用書込みブロックを明示的に有効にすることができます。

二重書込み (write) ブロックを有効にできます。 二重書込みブロックを有効にすると、mongosync は以下の書込みをブロックします。

• 移行中の宛先クラスターで。 mongosync は、canWrite を true に設定する直前に書込みのブロックを解除します。

• 次を呼び出した後のソースクラスターで: /commit

二重書込みブロックを有効にするには、 /start enableUserWriteBlockingを使用して を"sourceAndDestination" に設定します。

/start enableUserWriteBlockingを使用して、 を"none" に設定できます。

同期開始後に、二重書込みブロックを有効にしたり、書込みブロックを無効にしたりすることはできません。

後で逆同期を使用する場合は、mongosync を起動するときに二重書込みブロックを有効にする必要があります。

読み取りと書き込み保証

デフォルトでは、 mongosyncソース クラスターの読み取りに対する読み取り懸念レベルを"majority"に設定します。宛先クラスターへの書き込みの場合、 mongosyncは書込み保証レベルを"majority"に j: true を用いて設定します

読み取り保証と書込み保証の構成と動作の詳細については、「読み取り保証（read concern）」と「書込み保証（write concern）」を参照してください。

読み込み設定 (read preference)

mongosync では、ソースクラスターと宛先クラスターに接続するときに primary 読み込み設定（read preference）が必要です。詳しくは、「読み込み設定（read preference）オプション」を参照してください。

レガシーインデックスの取り扱い

mongosync 0 や空の文字列などのレガシーインデックス値を宛先の 1 に書き換えます。 mongosync は宛先の無効なインデックスオプションも排除します。

コレクションの特性に対する一時的な変更

mongosync は、同期中に次のコレクションの特性を一時的に変更します。 元の値はコミット プロセス中に復元されます。

ローリング処理によるインデックスビルド

mongosync では、移行中にローリングインデックスのビルドはサポートされません。移行中にローリング方式でインデックスをビルドしないようにするには、次のいずれかの方法を使用して、宛先インデックスがソース インデックスと一致することを確認します。

• 移行する前に、ソースにインデックスをビルドします。

• 移行中にデフォルトのインデックス構築を使用してソースにインデックスをビルドします。

• 移行後に、宛先でインデックスをビルドします。

mongosync Metadata

mongosync は、移行中にデータベースつまたは複数のデータベースにメタデータを保存します。メタデータデータベースには、次のいずれかの名前を付けることができます。

• mongosync_reserved_for_internal_use

• で始まるのもの mongosync_internal_

• で始まるのもの mongosync_reserved_for_verification_

移行が 成功 した後、すべてのメタデータデータベースを削除する必要があります。

整合性

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 操作とトランザクション」を参照してください。

ネットワーク レイテンシ

移行コンポーネント間のネットワークレイテンシや物理的な距離が長い場合、同期速度に悪影響を与える可能性があります。

mongosync と宛先シャード間のレイテンシ

ソースクラスターの各操作では、mongosync は宛先サーバーへの 2 回の往復を実行します。 レイテンシ が大きいほど、同期は遅くなります。

宛先シャード間のレイテンシ

mongosync は、宛先クラスターのトランザクション内で操作を実行し、独自のメタデータをバッチで更新します。 これにより、クロスシャード トランザクションが発生する可能性があり、シャードが離れている場合はコストが高くなる可能性があります。

ソースクラスターまたは宛先クラスター上のレプリカセットのノード間のレイテンシ

mongosync は"majority" 書込みと"majority" 読み取りを使用します。これには、シャード バッキングレプリカセットを含むレプリカセット内の複数のノードからの確認応答が必要です。これらのノードの過半数が同じリージョンにない場合、パフォーマンスに悪影響が生じます。

エラーとクラッシュ

同期中に mongosync でエラーが発生したり、使用できなくなった場合は、停止した場所から mongosync操作を再開できます。 mongosync バイナリはステートレスで、宛先クラスターの再起動用メタデータを保存します。

同期を続行するには、mongosync が再度利用可能になったら再起動し、中断した同期と同じパラメータを使用します。 mongosync を再起動すると、プロセスは停止した場所から再開されます。

クラスターの可用性

ソースクラスターまたは宛先クラスターが予期せずクラッシュした場合は、中断された場所からmongosyncを安全に再起動できます。 クラスターが再度使用可能になったら、mongosync を再起動し、中断した同期と同じパラメータを使用します。

一時停止した同期

mongosyncが一時停止状態にある場合、mongosync は次のアクションをサポートしていません。

• ソースクラスターまたは宛先クラスターのMongoDBバージョンのアップグレード

• バランサーを有効にしてから無効にする

PAUSED 状態のときに mongosync をアップグレードできます。