Docs Menu
Docs Home
/
MongoDB Cluster-to-Cluster Sync

よくある質問

項目一覧

このページでは、これまでに発生したよくある質問への回答を提供します。 さらに質問がある場合は、MongoDB サポートにお問い合わせください。

はい、 同期中に を再構成する mongosyncの手順に従って、移行中にクラスターのワークロードレベルを調整できます。

mongosync 同期中にソースから宛先への書込み (write) を結合し、順序を変更し、コレクションの特性を一時的に変更します。その結果、mongosync は、同期が一時停止されている場合でも、同期が実行中の任意の点で、宛先がソースと一致することを保証できません(ソースの古いバージョンを含む)。宛先クラスターへのトラフィックを安全に受け入れるには、commit への移行を待ちます。詳しくは、「 継続的な同期に関する考慮事項 」を参照してください。

同期中に宛先クラスターへの書き込みを実行すると、未定義の動作が発生します。 mongosync はデフォルトで 宛先クラスターへの書込みをブロックします。 書込みブロックの詳細については、「 書込みブロックと startを参照してください。

コミット時に、宛先クラスターは、canWritetrue の場合にのみ安全に書込み可能です。 の値を確認するには、canWrite progressエンドポイントを実行します。

同期中に許可される読み取りと書込みの詳細については、「 読み取りと書込み 」を参照してください。

注意

宛先クラスターでのインデックスビルドは、mongosync の同期中は書込みとして扱われます。

次の要因により、宛先クラスターのインデックスサイズが増加する可能性があります。

  • mongosync は、移行中にデータを挿入および削除するため、ディスクにデータを非効率的に保存する可能性があります。

  • デフォルトでは 、mongosync はデータをコピーする前にインデックスをビルドします。 mongosync_id の順序でデータをコピーします。 インデックスが _id と相関しない場合、インデックスのサイズが大きくなる可能性があります。 詳細については、 MongoDBマニュアル FAQ: インデックス のページを参照してください。

インデックスサイズの増加を軽減するには、次の方法を使用します。

  • パラメータをbuildIndexes neverに設定して移行を再開始します。移行が完了したら、宛先クラスターにインデックスを手動でビルドします。

  • 移行後、宛先クラスターでローリングの最初の同期を実行します。

  • 移行後、宛先クラスターで 圧縮を実行します。これにより、インデックスが再ビルドされ、不要なディスク領域が OS に解放されますが、クラスターのパフォーマンスに影響可能性があります。

はい、 mongosyncは独自のハードウェアで実行できます。 MongoDB インスタンスをホストするサーバーではmongosyncを実行する必要はありません。 mongosyncが独自のハードウェアで実行される場合、ソースクラスターまたは宛先クラスターの OS とは異なるオペレーティング システム(OS)を使用できます。

ほとんどの移行では、宛先クラスターはソースクラスターよりも高いハードウェア仕様であり、次のプロパティが含まれている必要があります。

  • CPU

  • メモリ

  • Disk I/O

これらのハードウェア仕様により、宛先クラスターが mongosync の書込みを処理でき、同期がソースクラスターのワークロードに追いつくことができます。

宛先クラスターには、移行される論理データ サイズと最初の同期の宛先oplogエントリーに十分対応できるディスクストレージが必要です。 例、10 GBのデータを移行するには、宛先クラスターでデータには少なくとも 10 GBが使用可能であり、最初の同期からの挿入oplogエントリ用にはさらに 10 GB が必要です。

重要

埋め込み検証 を使用するには、宛先のoplogがより大きくなければなりません。埋め込み検証子を有効にして宛先oplogのサイズを減らすと、埋め込み検証子が追いつけない可能性があり、mongosync がエラーを発生させる可能性があります。

宛先oplogエントリのオーバーヘッドを減らす必要があり、埋め込み検証子が無効になっている場合は、次の操作を実行できます。

  • oplogSizeMB宛先クラスターのoplogサイズを小さくするには、 設定を使用します。

  • oplogMinRetentionHoursを使用して 設定を解除し、宛先クラスターの最小oplog保持期間を短縮または削除します。

mongosync は、ソースクラスターのoplogの操作を宛先クラスターのデータに適用します。 mongosyncが適用していなかった操作がソースクラスターのoplogをロールオフすると、同期は失敗し、 mongosyncは終了します。

注意

mongosync は、宛先クラスターへの同期中にソースクラスターで行われたapplyOps操作を複製しません。

最初の同期中に、ドキュメントが同時にコピーされるため、 mongosyncは操作を遅くする可能性があります。 最初の同期後、 mongosyncは変更をより速く適用し、ソースクラスターで発生しているリアルタイム書込みに近いoplog内の位置を維持する可能性が高くなります。

大規模なデータセットの同期が予想される場合、または同期を長期間にわたって一時停止する予定の場合、 oplog windowを超える可能性があります。 ソースクラスター上のoplogのサイズを増やすには、 oplogSizeMB設定を使用します。

mongosync にはreadConcern: "majority"writeConcern: "majority" が必要です。

readConcernmajorityでない場合、 mongosyncはエラーを返します。

Invalid URI option, read concern must be majority

writeConcernmajorityでない場合、 mongosyncはエラーを返します。

Invalid URI option, write concern must be majority

mongosync は、他のすべての接続文字列オプションを受け入れます。

mongosync 標準の MongoDB 接続文字列を使用して、ソースクラスターと宛先クラスターに接続します。

LDAPX 509がサポートされています。 利用可能な認証オプションについては、「自己管理型配置での認証 」を参照してください。

mongosync は、エラーが発生した場合に自動的に再起動しません。 ただし、スクリプトを作成したり、オペレーティング システムのプロセス マネージャー( systemdを使用してmongosyncプロセスを再起動したりすることはできます。

mongosyncバイナリはステートレスです。 再起動用のメタデータは宛先クラスターに保存されています。

同期中にmongosyncが利用できなくなった場合には、 mongosync操作を再開できます。 mongosyncが再度使用可能になったら、同じパラメータでmongosyncプロセスを再起動します。 mongosyncは、 mongosyncが使用できなくなったときに停止した場所から操作を再開します。

注意

mongosync 1.7.3以降、 同期操作を再開または再開する際に、 mongosyncが応答するまでに少なくとも 2 分かかる場合があります。 この間、 progressエンドポイントへの呼び出しが失敗する可能性があります。 progress呼び出しが失敗した場合は、安全に再試行できます。

はい、レプリカセットはアービタを使用できます。ソース レプリカセットには 2 以上の非アービタ ノードが必要で、非アービタ ノードから同期する必要があります。 ソースクラスターの接続文字列を使用して、アービタ以外のデータを保持しているノードの読み込み設定(read preference)を指定します。

ソース クラスターで読み取り操作が低速、または宛先クラスターで書込み (write) 操作が低速な場合、 最初の同期 または 変更イベント の適用中に低速操作警告が表示されることがあります。 この警告は、ソースクラスターまたは宛先クラスターでネットワークの競合やリソースの負荷が増大していることを示している場合があります。

これらの警告自体は失敗を示すものではありませんが、低速操作によりmongosyncで操作タイムアウト エラーが発生したり、移行が失敗したりする可能性があります。

低速操作の警告が表示される場合は、ソースクラスターと宛先クラスターの CPU、メモリ、ネットワーク使用量を確認してください。 ニーズに対してクラスターのプロビジョニングが不十分な場合は、クラスター ハードウェアのアップグレードを検討してください。

いいえ、「error」または「failure」という単語を含むログは致命的でないエラーを表示し、 mongosyncを早期に停止する必要があることを示すものではありません。 これらのログは、 mongosyncの障害やデータの破損を示すものではありません。 致命的なエラーが発生した場合、 mongosyncは同期を停止し、致命的なログエントリを書込みます。

重複キー エラーは、同期プロセスの通常の一部です。 このようなエラーは、次の場合に発生する可能性があります。

  • mongosyncの起動後にソースクラスターにドキュメントを挿入します。 mongosyncはドキュメントを直接コピーし、後でドキュメントの挿入変更イベントを冗長に適用できます。

  • mongosyncを停止して再開します。 これにより、 mongosyncの再起動時に重複挿入が発生する可能性があります。

  • mongosync 一時的なエラーが発生し、すでに成功している可能性のある挿入を再試行します。

致命的なエラーは修正する必要がある問題を示し、移行を再開する必要があります。 エラーに対処した後、 mongosync_reserved_for_internal_useデータベースを含む宛先クラスター上のすべての移行データを削除します。 次に、 mongosyncを再起動し、新しい移行を開始します。

Cluster-to-Cluster Sync は、ソースクラスターから宛先クラスターへのTTL インデックスの同期 をサポートしています。

いいえ、宛先シャーディングされたクラスターでのチャンク分散をカスタマイズするように mongosync を構成することはできません。 mongosync は初期化中に各コレクションをサンプリングし、移行後に宛先クラスターのシャード全体にドキュメントを効率的に分散する方法を判断します。

戻る

0.9