mongosync バイナリは Mongosync で使用されるプライマリ プロセスです。mongosync は、あるクラスターから別のクラスターにデータを移行します。
mongosyncプロセスの概要については、「 mongosyncについて 」を参照してください。
mongosync を使い始めるには、「クイック スタート ガイド」を参照してください。
詳細については、状況に応じてインストールまたはmongosyncの接続のページを参照してください。
埋め込み検証子無効化
1.9 以降、mongosync には、宛先クラスターでサポートされているすべてのコレクションに対して一連の検証チェックを実行し、ソースクラスターから宛先へのドキュメントの転送が成功したことを確認するための埋め込み検証子が含まれています。
mongosync プロセスを開始すると、次の資格が提供されます。
Embedded verification is enabled by default. Verification checks for data consistency between the source and destination clusters. Verification will cause mongosync to fail if any inconsistencies are detected, but it does not check for all possible data inconsistencies. Please see the documentation at https://www.mongodb.com/ja-jp/docs/cluster-to-cluster-sync/current/reference/verification/embedded for more details. Verification requires approximately 0.5 GB of memory per 1 million documents on the source cluster and will fail if insufficient memory is available. Accepting this disclaimer indicates that you understand the limitations and memory requirements for this tool. To skip this disclaimer prompt, use –-acceptDisclaimer. To disable the embedded verifier, specify 'verification: false' when starting mongosync. Please see https://www.mongodb.com/ja-jp/docs/cluster-to-cluster-sync/current/reference/verification/ for alternative verification methods. Do you want to continue? (y/n):
すでに読み取りを完了してから、ディスクの区切り文字をスキップするために、 オプションを使用してmongosync --acceptDisclaimerを起動することで、この通知をスキップできます。
設定
クラスターの独立性
mongosync は、ソースクラスターと宛先クラスター間で収集データを同期します。mongosync ユーザーまたはロールを同期しません。その結果、各クラスターで異なるアクセス権限を持つユーザーを作成できます。
構成ファイル
mongosyncのオプションは、YAML 構成ファイルで設定できます。 --configオプションを使用します。 例:
mongosync --config /etc/mongosync.conf
利用可能な設定の詳細については、「構成」を参照してください。
クラスターとコレクションのタイプ
シャーディングされたクラスター
Mongosync はシャーディングされたクラスター間のレプリケーションをサポートしています。mongosync は、ソースクラスターから宛先クラスターに個々のシャードを並列に複製します。ただし、mongosync はソースクラスターのシャーディング構成を保持しません。
重要
ソースクラスターまたは宛先クラスターがシャーディングされたクラスターである場合は、移行中に両方のクラスターでバランサーを停止し、 コマンドまたはmoveChunk moveRangeコマンドを実行しないでください。バランサー を停止するには、balancerStop コマンドを実行し、コマンドが完了するまで待ちます。
事前分割 チャンク
mongosync がシャーディングされた宛先クラスターに同期する場合、宛先クラスター上のシャーディングされたコレクション用にチャンクが事前に分割されます。シャーディングされたコレクションごとに、mongosync は宛先クラスターにシャードがある数の 2 倍のチャンクを作成します。
チャンク分散
重要
ソースクラスターがバランシングされていても、mongosync は宛先クラスターのバランスを保証しません。mongosync は移行中にシャーディング操作の実行をサポートしていないため、宛先クラスターを再バランス化するための書込み (write) を安全に受け入れるまで待つ必要があります。のシャーディングシャーディングされたクラスターシャーディングされたクラスターの制限に関する情報については、クラスターを再バランスするガイダンスについては「 シャーディングされたシャードクラスタのバランサー 」を参照してください。mongosync
mongosync では、mongosync インスタンスが複数ある場合でも、ソースから宛先へのチャンク分散は保持されません。 宛先クラスターのソースクラスターから、特定の事前分割されたチャンクを複製することはできません。
mongosyncシャーディング構成のうちソースクラスターから宛先クラスターまで保持するシャーディング構成は、シャーディングキーのみです。移行が完了したら、宛先クラスターのバランサーを有効にして、ソースクラスターのディストリビューションとは独立してドキュメントを分散できます。
プライマリシャード
シャーディングされた宛先クラスターに同期する場合、mongosync は 1 つのラウンドログを使用して各データベースにプライマリシャードを割り当てます。
警告
movePrimary移行中にソースクラスターまたは宛先クラスターで を実行すると、致命的なエラーが発生したり、移行を最初から再開したりする必要がある可能性があります。詳細については、「 シャーディングされたクラスター 」を参照してください。
コンフィギュレーションシャード クラスター
8.0 以降、MongoDB、埋め込みコンフィギュレーションサーバークラスターとも呼ばれるコンフィギュレーションシャードクラスターのサポートが導入されています。
mongosync は、専用コンフィギュレーションサーバーのシャーディングされたクラスターから埋め込みコンフィギュレーションサーバーのシャーディングされたクラスターへの同期をサポートしており、その逆も同様です。さらに、mongosync はレプリカセットから構成シャーディングされたクラスターへの同期をサポートしていますが、その逆はサポートされていません。
埋め込みコンフィギュレーションサーバーの詳細については、コンフィギュレーションシャードを参照してください。
複数のクラスター
ソースクラスターを複数の宛先クラスターと同期するには、宛先クラスターごとに 1 つの mongosync インスタンスを使用します。詳細については、「複数クラスターの制限事項」を参照してください。
上限付きコレクション
1.3.0 以降、Mongosync は、Cappedコレクション を一部制限付きでサポートしています。
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 0 や空の文字列などのレガシーインデックス値を宛先の 1 に書き換えます。 mongosync は宛先の無効なインデックスオプションも排除します。
同期中の考慮事項
mongosync レプリケーションは、レプリカセット内のデータのレプリケーションとは異なります。mongosync は、同期中にソース クラスターから宛先クラスターへの書き込みを組み合わせて順序を変更し、さまざまなコレクションの特性も一時的に変更します。
その結果、同期が一時停止されているときを含め、同期の実行中の任意の点で宛先がソースクラスターと一致することが保証されません。切り替える前に宛先クラスターとソースクラスターが一致していることを確認するには、コミットエンドポイントを呼び出します。
逆機能を使用しない限り、ソースクラスターと宛先クラスター間の関係は、コミット時に終了します。同期中の制約の詳細については、制限については、「 制限 」を参照してください。
重要
mongosync で commit を呼び出し、canWrite が正常に true を返すまで、デスティネーションクラスターはアプリケーションの読み取りまたは書き込みトラフィックを受け付けることができません。障害復旧クラスターの維持にはmongosyncを使用しないでください。
コレクションの特性に対する一時的な変更
mongosync は、同期中に次のコレクションの特性を一時的に変更します。 元の値はコミット プロセス中に復元されます。
変更 | 説明 |
|---|---|
Unique Indexes | ソースクラスター上のユニークインデックスは、デスティネーションクラスターでは非一意なインデックスとして同期されます。 |
TTL Indexes | 同期により、宛先クラスターの |
Hidden Indexes | 同期では、非表示のインデックスを非表示でないものとして複製します。 |
書き込みブロッキング | 書込みブロックを有効にすると、
詳しくは、「 書込みブロック 」を参照してください。 |
上限付きコレクション | 同期により、Cappedコレクションが最大許容サイズに設定されます。 |
ダミー インデックス | 場合によっては、シャーディングされたコレクションや照合されたコレクションへの書込みをサポートするために、同期によって宛先にダミーのインデックスが作成される場合があります。 |
ローリング処理によるインデックスビルド
mongosync では、移行中にローリングインデックスのビルドはサポートされません。移行中にローリング方式でインデックスをビルドしないようにするには、次のいずれかの方法を使用して、宛先インデックスがソース インデックスと一致することを確認します。
移行する前に、ソースにインデックスをビルドします。
移行後に、宛先でインデックスをビルドします。
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 は、システム コレクションを宛先クラスターにレプリケートしません。
ソースクラスターで dropDatabase コマンドを発行した場合、この変更は宛先クラスターには直接適用されません。代わりに、Mongosync は宛先クラスターのデータベース内のユーザー コレクションとビューを削除しますが、そのデータベース上のシステム コレクションは削除されません 。
たとえば、送信先クラスターでは、次のようになります。
削除操作は、ユーザーが作成した
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が一時停止状態にある場合、mongosync は次のアクションをサポートしていません。
ソースクラスターまたは宛先クラスターのMongoDBバージョンのアップグレード
バランサーを有効にしてから無効にする
PAUSED 状態のときに mongosync をアップグレードできます。