このページでは、これまでに発生したよくある質問への回答を提供します。 さらに質問がある場合は、MongoDB サポートにお問い合わせください。
mongosync が同期している間に負荷レベルを変更できますか。
はい、 同期中に を再構成する mongosyncの手順に従って、移行中にクラスターのワークロードレベルを調整できます。
mongosync の同期中に宛先クラスターへの読み取りまたは書き込みを実行できますか。
mongosync 同期中にソースから宛先への書き込みを組み合わせて順序を変更し、コレクションの特性を一時的に変更します。その結果、mongosync は、同期が一時停止されている場合でも、同期が実行中の任意の点で、宛先がソースと一致することを保証できません（ソースの古いバージョンを含む）。宛先クラスターの移行されたコレクションへのトラフィックを安全に受け入れるには、commit への移行を待ちます。詳細については、「同期中の考慮事項」を参照してください。
同期中に宛先クラスター上の移行されたコレクションへの書き込み (write)を実行すると、未定義の動作が発生します。mongosync はデフォルトで宛先クラスターへの書き込みをブロックします。書き込み (write)ブロックの詳細については、書き込み (write)ブロック と start. を参照してください。
コミット時に、canWrite が true である場合にのみ、宛先クラスター上の移行されたコレクションに安全に書き込み可能です。canWrite の値を確認するには、progress エンドポイントとなる接続されたデバイスを実行します。
同期中に許可される読み取りと書込みの詳細については、「 読み取りと書込み 」を参照してください。
注意
宛先クラスターでのインデックスビルドは、mongosync の同期中は書込みとして扱われます。
MongoDB の2 つのクラスター間の継続的な同期に mongosync を使用できますか。
例、 は、障害復旧、分析、またはその他の同様のユースケースのためにセカンダリ クラスターを維持できますか。
いいえ、mongosync は 1 回限りの移行をサポートするように設計されています。mongosync は、宛先クラスターで移行されたコレクションへの読み取りまたは書き込みトラフィックを安全に受け入れるために、commit である必要があります。したがって、障害復旧、分析、およびその他の同様のユースケースは、mongosync ではサポートされていないワークフローです。
For more information, see Can I perform reads or writes to my destination cluster while mongosync is syncing?.
宛先クラスターのインデックスがソースクラスターのインデックスよりも大きいのはなぜですか?
次の要因により、宛先クラスターのインデックスサイズが増加する可能性があります。
mongosyncは、移行中にデータを挿入および削除するため、ディスクにデータを非効率的に保存する可能性があります。デフォルトでは 、
mongosyncはデータをコピーする前にインデックスをビルドします。mongosyncは_idの順序でデータをコピーします。 インデックスが_idと相関しない場合、インデックスのサイズが大きくなる可能性があります。 詳細については、「 MongoDBマニュアルFAQ: インデックス 」ページを参照してください。
インデックスサイズの増加を軽減するには、次の方法を使用します。
After the migration, perform a rolling initial sync on the destination cluster.
移行後、宛先クラスターで圧縮（データベースコマンド）を実行します。これにより、インデックスが再ビルドされ、不要なディスク領域が 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エントリのオーバーヘッドを減らす必要があり、埋め込み検証子が無効になっている場合は、次の操作を実行できます。
Use the
oplogSizeMBsetting to lower the destination cluster's oplog size.Use to
oplogMinRetentionHourssetting to lower or remove the destination cluster's minimum oplog retention period.
ソースクラスター内の oplog のサイズを増やす必要がありますか。
mongosync oplogは、コレクションコピー フェーズの後に、ソースクラスターの の操作を宛先クラスターのデータに適用します。mongosync が適用していなかった操作がソースクラスターの oplog をロールオフすると、同期は失敗し、mongosync は終了します。
注意
mongosync does not replicate applyOps operations made on the source cluster during sync to the destination cluster.
If you anticipate syncing a large data set, or if you plan to pause synchronization for an extended period of time, you might exceed the oplog window. Use the oplogSizeMB setting to increase the size of the oplog on the source cluster.
mongosync で許可される接続文字列オプションはどれですか。
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 と X509 はサポートされています。利用可能な認証オプションについては、「 自己管理型配置での認証 」を参照してください。
エラーが発生した場合、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 は初期化中に各コレクションをサンプリングし、移行後に宛先クラスターのシャード全体にドキュメントを効率的に分散する方法を判断します。