mongosync 動作

クラスターの独立性

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

構成ファイル

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

$ mongosync --config /etc/mongosync.conf

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

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

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

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

複数のクラスター

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

上限付きコレクション

1.3.0 以降、Mongosync は、Cappedコレクション を一部制限付きでサポートしています。

• convertToCapped is not supported. If you run convertToCapped, mongosync exits with an error.

• 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 を起動するときに二重書込みブロックを有効にする必要があります。

読み取りと書き込み保証

By default, mongosync sets the read concern level to "majority" for reads on the source cluster. For writes on the destination cluster, mongosync sets the write concern level to "majority" with j: true.

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

読み込み設定 (read preference)

mongosync requires the primary read preference when connecting to the source and destination clusters. For more information, see Read Preference Options.

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

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

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

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

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

mongosync does not support rolling index builds during migration. To avoid building indexes in a rolling fashion during migration, use one of the following methods to ensure that your destination indexes match your source indexes:

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

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

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

mongosync Metadata

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

• mongosync_reserved_for_internal_use

• で始まるのもの mongosync_internal_

• で始まるのもの mongosync_reserved_for_verification_

移行を成功させた後、すべてのメタデータデータベースを削除する必要があります。メタデータを削除した後は、移行 を元に戻すことはできません。

整合性

mongosync は、宛先クラスターで結果整合性をサポートします。コミットするまで、宛先クラスターでは読み取り整合性が保証されません。コミットする前に、ソースクラスターと宛先クラスターは特定の点で異なる場合があります。詳細については、同期中の考慮事項 を参照してください。

mongosyncが同期している間に、 mongosyncはソースから宛先に中継されるときに、書き込みの順序を変更したり、まとめたりすることができます。 特定のドキュメントの場合、書込みの合計数がソースと宛先で異なる場合があります。

トランザクションは、宛先クラスター上でアトミックに表示されない場合があります。 再試行可能な書き込みは、宛先クラスターでは再試行できない場合があります。

プロファイリング

ソースデータベースでプロファイリングが有効になっている場合、 MongoDB<db>.system.profile という名前の特別なコレクションが作成されます。同期が完了した後、ソースデータベースが後で削除された場合であっても、Mongosyncは宛先から<db>.system.profileコレクションを削除しません。<db>.system.profileコレクションによって宛先のユーザー データの精度が変わることはありません。

ビュー

ビューを含むデータベースをソース上で削除すると、宛先では当該のデータベースに空の system.views コレクションが表示される場合があります。空のsystem.viewsコレクションによって宛先のユーザー データの精度が変わることはありません。

システム コレクション

Mongosync は、システム コレクションを宛先クラスターにレプリケートしません。

If you issue a dropDatabase command on the source cluster, this change is not directly applied on the destination cluster. Instead, Mongosync drops user collections and views in the database on the destination cluster, but it does not drop system collections on that database.

たとえば、送信先クラスターでは、次のようになります。

• The drop operation does not affect a user-created system.js collection.

• If you enable profiling, the system.profile collection remains.

• If you create views on the source cluster and then drop the database, replicating the drop removes the views, but leaves an empty system.views collection.

このような場合、dropDatabase を複製すると、ユーザーが作成したコレクションはすべてデータベースから削除されますが、そのシステム コレクションは宛先クラスターに残ります。

UUID

mongosync creates collections with new UUIDs on the destination cluster. There is no relationship between UUIDs on the source cluster and the destination cluster. If applications contain hard-coded UUIDs (which MongoDB does not recommend), you may need to update those applications before they work properly with the migrated cluster.

ソート

mongosync 未定義の順序で宛先クラスターにドキュメントを挿入します。ソースクラスターからの自然なソート順序は保持されません。アプリケーションがドキュメントの順序に依存するにもかかわらずソート方法が未定義の場合、移行したクラスターで正しく動作させるには、当該のアプリケーションを更新して、期待されるソート順序を指定しなければならない場合があります。

MongoDB Atlas内部データベース

MongoDB Atlasやその他のクラウドサービスでは、クラスター内の専用の内部データベースに重要なデータを保存します。これらのデータベースは __mdb_internal1で始まります。. 以降、18 はmongosync __mdb_internalで始まるすべてのデータベースを無視します。

回復力

mongosync 回復力があり、致命的でないエラーを処理できます。"error" ないしは "failure"という単語を含むログは、 mongosyncの障害やデータの破損を示すものではありません。たとえば、ネットワーク エラーが発生した場合、 mongosyncログに”error”という単語が含まれることがありますが、 mongosyncの同期は完了可能です。同期が完了しない場合は、mongosyncによって致命的なログエントリが書込まれます。

データ定義言語（DDL）操作

Using DDL operations (operations that act on collections or databases such as db.createCollection() and db.dropDatabase()) during sync increase the risk of migration failure and may negatively impact mongosync performance. For best performance, refrain from performing DDL operations on the source cluster while the sync is in progress.

DDL 操作について詳しくは、「保留中の DDL 操作とトランザクション」を参照してください。

ネットワーク レイテンシ

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

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

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

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

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

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

mongosync uses "majority" writes and "majority" reads, which require acknowledgement from multiple nodes in a replica set, including shard-backing replica sets. If the majority of these nodes aren't in the same region, there will be negative performance implications.

エラーとクラッシュ

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

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

クラスターの可用性

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

一時停止した同期

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

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

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

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