このページでは、これまでに発生したよくある質問への回答を提供します。 さらに質問がある場合は、MongoDB サポートにお問い合わせください。
が同期している間に負荷レベルを変更できますか。mongosync
はい、 同期中に を再構成する mongosyncの手順に従って、移行中にクラスターのワークロードレベルを調整できます。
mongosyncの同期中に宛先クラスターへの読み取りまたは書込みを実行できますか。
mongosync は、同期中にソースから宛先への書込みを組み合わせて順序を変更し、コレクションの特性を一時的に変更します。その結果、mongosync は、同期が一時停止されている場合でも、同期が実行中の任意の点で、宛先がソースと一致することを保証できません（ソースの古いバージョンを含む）。宛先クラスターの移行されたコレクションへのトラフィックを安全に受け入れるには、commit への移行を待ちます。詳細については、「 同期中の考慮事項 」を参照してください。
同期中に宛先クラスター上の移行されたコレクションへの書き込みを実行すると、未定義の動作が発生します。mongosync はデフォルトで 宛先クラスターへの書込みをブロックします。書込みブロックの詳細については、「 書込みブロックと startを参照してください。
コミット時に、canWrite がtrue である場合にのみ、宛先クラスター上の移行されたコレクションに安全に書込み可能です。 の値を確認するには、canWrite progressエンドポイントを実行します。
同期中に許可される読み取りと書込みの詳細については、「 読み取りと書込み 」を参照してください。
注意
宛先クラスターでのインデックスビルドは、mongosync の同期中は書込みとして扱われます。
mongosyncMongoDB の2 つのクラスター間の継続的な同期に を使用できますか。
例、 は、障害復旧、分析、またはその他の同様のユースケースのためにセカンダリ クラスターを維持できますか。
いいえ、mongosync は 1mongosync commit回限りの移行をサポートするように設計されています。 は、宛先クラスターで移行されたコレクションへの読み取りまたは書込みトラフィックを安全に受け入れるために、 である必要があります。したがって、障害復旧、分析、およびその他の同様のユースケースは、mongosync ではサポートされていないワークフローです。
詳しくは、「 mongosyncが同期している間に宛先クラスターへの読み取りまたは書込みを実行できますか？ 」を参照してください。
宛先クラスターのインデックスがソースクラスターのインデックスよりも大きいのはなぜですか?
次の要因により、宛先クラスターのインデックスサイズが増加する可能性があります。
mongosyncは、移行中にデータを挿入および削除するため、ディスクにデータを非効率的に保存する可能性があります。デフォルトでは 、
mongosyncはデータをコピーする前にインデックスをビルドします。mongosyncは_idの順序でデータをコピーします。 インデックスが_idと相関しない場合、インデックスのサイズが大きくなる可能性があります。 詳細については、「 MongoDBマニュアルFAQ: インデックス 」ページを参照してください。
インデックスサイズの増加を軽減するには、次の方法を使用します。
パラメータを
buildIndexesneverに設定して移行を再開始します。移行が完了したら、宛先クラスターにインデックスを手動でビルドします。移行後、宛先クラスターで圧縮（データベースコマンド）を実行します。これにより、インデックスが再ビルドされ、不要なディスク領域が OS に解放されますが、クラスターのパフォーマンスに影響可能性があります。
mongosyncは独自のハードウェアで実行できますか。
はい、 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保持期間を短縮または削除します。
ソースクラスターの のサイズを増やす必要がありますか。oplog
mongosync oplogは、コレクションコピー フェーズの後に、ソースクラスターの の操作を宛先クラスターのデータに適用します。mongosync が適用していなかった操作がソースクラスターの oplog をロールオフすると、同期は失敗し、mongosync は終了します。
注意
mongosync は、宛先クラスターへの同期中にソースクラスターで行われたapplyOps操作を複製しません。
大規模なデータセットの同期が予想される場合、または同期を長期間にわたって一時停止する予定の場合、 oplog windowを超える可能性があります。 ソースクラスター上のoplogのサイズを増やすには、 oplogSizeMB設定を使用します。
stringmongosyncで許可される接続文字列オプションはどれですか。
mongosync にはreadConcern: "majority"とwriteConcern: "majority" が必要です。
readConcernがmajorityでない場合、 mongosyncはエラーを返します。
Invalid URI option, read concern must be majority
writeConcernがmajorityでない場合、 mongosyncはエラーを返します。
Invalid URI option, write concern must be majority
mongosync は、他のすべての接続文字列オプションを受け入れます。
mongosync はネットワーク圧縮をサポートしていますか。
mongosync はネットワーク圧縮をサポートしており、デフォルトで有効になっています。ただし、クラスター構成では少なくとも 1 つの共通コンプレッサーを共有する必要があります。
ネットワーク圧縮構成オプションの詳細については、 データベース マニュアルの --networkMessageCompressors オプションを参照してください。
どのセキュリティと認証オプションがサポートされていますか?
mongosync 標準の MongoDB 接続文字列を使用して、ソースクラスターと宛先クラスターに接続します。
LDAPとX 509がサポートされています。 利用可能な認証オプションについては、「自己管理型配置での認証 」を参照してください。
mongosyncエラーが発生した場合、 は自動的に再起動しますか？
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」という単語が含まれている場合は、移行を停止する必要がありますか。
いいえ、「error」または「failure」という単語を含むログは致命的でないエラーを表示し、 mongosyncを早期に停止する必要があることを示すものではありません。 これらのログは、 mongosyncの障害やデータの破損を示すものではありません。 致命的なエラーが発生した場合、 mongosyncは同期を停止し、致命的なログエントリを書込みます。
ログに重複キー エラーが多数表示される場合はどうなりますか。
重複キー エラーは、同期プロセスの通常の一部です。 このようなエラーは、次の場合に発生する可能性があります。
mongosyncの起動後にソースクラスターにドキュメントを挿入します。mongosyncはドキュメントを直接コピーし、後でドキュメントの挿入変更イベントを冗長に適用できます。mongosyncを停止して再開します。 これにより、mongosyncの再起動時に重複挿入が発生する可能性があります。mongosync一時的なエラーが発生し、すでに成功している可能性のある挿入を再試行します。
mongosync が致命的なエラーを返した場合、どうすればよいですか。
致命的なエラーは修正する必要がある問題を示し、移行を再開する必要があります。 エラーに対処した後、 mongosync_reserved_for_internal_useデータベースを含む宛先クラスター上のすべての移行データを削除します。 次に、 mongosyncを再起動し、新しい移行を開始します。
mongosyncは TTL インデックスをサポートしていますか
Mongosync は、ソースクラスターから宛先クラスターへのTTL インデックスの同期をサポートしています。
シャーディングされたクラスターに同期するときに、チャンクの分散をカスタマイズできますか。
いいえ、宛先シャーディングされたクラスターでのチャンク分散をカスタマイズするように mongosync を構成することはできません。 mongosync は初期化中に各コレクションをサンプリングし、移行後に宛先クラスターのシャード全体にドキュメントを効率的に分散する方法を判断します。