mongosync
には、サポートされているコレクションの同期を検証するために宛先クラスターで一連のチェックを実行するための埋め込み検証子が含まれています。
重要
検証子は、次の名前空間はチェックしません。
上限付きコレクション
TTL インデックスを持つコレクション(移行中に追加または削除される TTL インデックスを含む)
デフォルトの照合を使用しないコレクション
ビュー
検証子は、次のコレクション機能をチェックしません。
コレクションメタデータ
Indexes
上記のデータとメタデータを確認するには、これらのコレクションとコレクション機能の追加チェックをスクリプト。 詳しくは、「 データ転送を確認する 」を参照してください。
バージョン 1.9 の新機能。
このタスクについて
互換性
埋め込み検証子は mongosync 1.8 以前では使用できません。
別の検証方法については、「 データ転送の検証 」を参照してください。
制限
埋め込み検証子には次の制限があります。
検証子はシャーディングされたクラスターをサポートしていません。 移行にシャーディングされたクラスターが含まれている場合、
mongosync
は検証子を無効にします。mongosync
は検証子の状態をメモリに保存するため、大幅なメモリ オーバーヘッドが発生する可能性があります。 検証子を実行するには、mongosync
は約 10 GBのメモリに加えて、100 万ドキュメントごとに追加の 500 MB を必要とします。検証子は再開できません。 ユーザーが同期を停止または一時停止した後、何らかの理由で
mongosync
を再度開始した場合、検証プロセスは最初から再開されます。 これにより検証が移行より大幅に遅れる可能性があります。/reverse エンドポイントは検証子を無効にします。
/reverse
エンドポイントへの追加呼び出し後も無効のままになります。検証を有効にして同期を開始し、
buildIndexes
をnever
に設定している場合、mongosync
がソースクラスターで TTLコレクションを見つけると、移行は失敗します。 これは、/start
エンドポイントを呼び出した後に発生する可能性があり、移行の進行中にユーザーがソースクラスターに TTLインデックスを作成する場合などです。宛先クラスターでインデックスを構築せずに TTL コレクションを同期するには、 検証子を無効にして同期を開始する必要があります。
1.9.0 より前のバージョンからライブアップグレードする場合、
mongosync
は埋め込み検証を無効にします。
サポートされていない検証チェック
検証子は、次の名前空間はチェックしません。
上限付きコレクション
TTL インデックスを持つコレクション(移行中に追加または削除される TTL インデックスを含む)
デフォルトの照合を使用しないコレクション
ビュー
検証子は、次のコレクション機能をチェックしません。
コレクションメタデータ
Indexes
上記のデータとメタデータを確認するには、これらのコレクションとコレクション機能の追加チェックをスクリプト。 詳細については、「 データ転送を確認する 」を参照してください。
手順
初期化 mongosync
mongosync
プロセスを初期化します。
./bin/mongosync \ --logPath /var/log/mongosync \ --cluster0 "mongodb://clusterAdmin:superSecret@clusterOne01.fancyCorp.com:20020,clusterOne02.fancyCorp.com:20020,clusterOne03.fancyCorp.com:20020" \ --cluster1 "mongodb://clusterAdmin:superSecret@clusterTwo01.fancyCorp.com:20020,clusterTwo02.fancyCorp.com:20020,clusterTwo03.fancyCorp.com:20020"
同期の開始
ソースクラスターから宛先クラスターへのデータの同期を開始するには、 /start エンドポイントを使用します。
curl localhost:27182/api/v1/start -XPOST \ --data ' { "source": "cluster0", "destination": "cluster1", } '
出力例:
{"success":true}
レプリカセットの移行では 検証子はデフォルトで有効になっていることに注意してください。
進捗状況の確認
同期のステータスを調べるには、 /progress エンドポイントを使用します。
curl localhost:27182/api/v1/progress -XGET
出力例:
{ "progress": { "state":"RUNNING", "canCommit":true, "canWrite":false, "info":"change event application", "lagTimeSeconds":0, "collectionCopy": { "estimatedTotalBytes":694, "estimatedCopiedBytes":694 }, "directionMapping": { "Source":"cluster0: localhost:27017", "Destination":"cluster1: localhost:27018" }, "verification": { "source": { "estimatedDocumentCount": 42, "hashedDocumentCount": 42, "lagTimeSeconds": 2, "totalCollectionCount": 42, "scannedCollectionCount": 10, "phase": "stream hashing" }, "destination": { "estimatedDocumentCount": 42, "hashedDocumentCount": 42, "lagTimeSeconds": 2, "totalCollectionCount": 42, "scannedCollectionCount": 10, "phase": "stream hashing" } } }, "success": true }
埋め込み検証子のステータスに関する情報については、verification
レスポンスフィールドを調べます。
動作
検証チェック
埋め込み検証子は、宛先クラスターに対して一連のチェックを実行します。 サポートされているすべてのコレクションをチェックして、mongosync
がソースクラスターから宛先にドキュメントを正常に転送したことを確認します。
検証子が エラーを発生させると、エラーとなり移行は失敗します。 検証子がエラーを 見つけられない場合 、/progress
エンドポイントは canWrite: true
を返します。 canWrite
フィールドの詳細については、 canWrite と Committed を参照してください。
メモリ要件
検証には、10 GBのメモリと、移行内の 100 万ドキュメントごとに追加の 500 MB が必要です。
使用可能なメモリが不足している場合、/start
エンドポイントはエラーを返します。 この状況が発生した場合、 検証子とともに mongosync
を使用するには、まずサーバーのメモリを増やして移行を再開 する必要があります。
サーバーメモリの増加がオプションでない場合は、検証子を無効にしてmongosync
を再起動します。