説明
コミットされた同期操作の方向を逆にします。
以下に例を挙げます。
COMMITTED
同期操作があります。cluster0
がソースで、cluster1
が宛先です。同期操作が
COMMITTED
後、新しい書込み (write) は宛先クラスターでのみ発生します。 ソースクラスターは新しい書込み (write) を受け入れません。
このシナリオでは、 reverse
エンドポイントを使用して、 cluster1
からcluster0
への書込み(write)を同期できます。これには、 mongosync
がcanWrite=true
に達した後にcluster1
で発生した書込みも含まれます。 同期中にcanWrite
ステータスを確認するには、 /progressエンドポイントを使用します。
reverse
エンドポイントの使用に関する詳細とチュートリアルについては、「 逆同期方向 」を参照してください。
要件
reverse
エンドポイントを使用するには:
mongosync
最初の同期を開始するときに構成する必要があります。 /start API エンドポイントの呼び出しでは、以下を設定する必要があります。reversible
次の行動をします:true
enableUserWriteBlocking
"sourceAndDestination"
に設定されている場合にのみ使用できます。
注意
二重書込みブロックは reverse
を実行中ための前提条件です。
同期の開始後に、これらのオプションを更新することはできません。
mongosync
はCOMMITTED
状態である必要があります。宛先クラスターの oplog は、
mongosync
がcanWrite=true
に達してから/reverse
リクエストの受信までの間、ロールオーバーされないようにする必要があります。
警告
ソースクラスター上のユニークインデックスでは、レガシー形式を使用してはなりません。
ソースクラスターのコレクションインデックスが適切な形式を使用していることを検証するには、「 一意なインデックスの検証 」を参照してください。
ソースクラスターと宛先クラスターは同じ数のシャードを持つ必要があります。 クラスターのトポロジーまたはメジャー バージョンが異なる場合、逆同期はできません。
mongosync
接続文字列で指定されたユーザーには、ソースクラスターと宛先クラスターで必要な権限が必要です。 権限は、書込みブロック設定を変更するか、逆同期を使用するかによって、環境によって異なります。
注意
シャーディングされたクラスター間で同期するように複数のmongosync
インスタンスを構成する場合は、各mongosync
インスタンスに同一の API エンドポイント コマンドを送信する必要があります。
詳細については、「複数の Mongosync を元に戻す 」を参照してください。
Validate Unique Indexes
方向を逆にするには、mongosync
ではソースクラスター上のすべての一意のインデックス(_id
を除く)にレガシーユニークインデックスキーが ない 必要があります。
始める前に
集計ステージを使用すると、ソースクラスター上で _id
$collStats
以外の一意のインデックスが正しい形式で使用されるようにします。コレクションでこの集計パイプラインを実行するには、例コードをコピーして貼り付け、<collection>
をコレクション名に、 をインデックスフィールドの名前に置き換えます。一意なインデックスを持つすべてのコレクションの、すべてのノードでこれを実行する必要があります。非<field_name>
_id
一意なインデックスのみにformatVersion13
または が必要であることに注意してください。14
db.<collection>.aggregate( [ { $collStats: { storageStats: { } } }, { $project: { "storageStats.indexDetails.<field_name>.metadata.formatVersion": 1 } } ] )
[ { storageStats: { indexDetails: { <field_name>: { metadata: { formatVersion: 14 } } } } } ]
formatVersion 13
または 14
を持つ一意のインデックスには、レガシーキーがないことが保証されます。
異なる形式Versionの一意のインデックスがある場合は、db.collection.validate()
とfull = false
メソッドを使用して、レガシーインデックスキーがあるかどうかを確認することもできます。これは、一意なインデックスを持つすべてのコレクションのすべてのノードで実行する必要があります。validate()
は、レガシー形式のインデックスキーが検出された場合に警告を返します。
手順
mongosync
との互換性があるインデックスの形式バージョンを更新するには、 元のソースクラスター内のすべてのノードを再同期する必要があります。すべてのノードを再同期するには:
すべてのセカンダリを 1 つずつ再同期します。
ノードの再同期のチュートリアルについては、「レプリカセットのノードの再同期 」を参照してください。
リクエスト
POST /api/v1/reverse
リクエスト ボディ パラメータ
このエンドポイントは、HTTP リクエスト本体のパラメータを使用しません。 ただし、空のオブジェクト{ }
を使用して--data
オプションを指定する必要があります。
応答
フィールド | タイプ | 説明 |
---|---|---|
| ブール値 | リクエストが成功した場合、この値は |
| string | エラーが発生した場合、 はエラーの名前を示します。 このフィールドは、 |
| string | 発生したエラーの詳細な説明。 このフィールドは、 |
例
次の例では、コミットされた同期操作の方向を逆にします。
リクエスト
curl localhost:27182/api/v1/reverse -XPOST --data '{ }'
応答
{"success":true}
動作
reverse
エンドポイントにより REVERSING
状態が開始されます。 mongosync
はソースクラスターと宛先クラスターをスワップし、変更イベントの適用を再開します。
reverse
の同期が成功すると、 mongosync
はRUNNING
状態になります。 同期は、元の同期ジョブとは逆方向に続行されます。 元のデータをコピーするために、同期プロセス全体を再起動する必要はありません。
ソースクラスターと宛先クラスターの同期のマッピング方向を表示するには、進行状況エンドポイントを使用し、 directionMapping
オブジェクトを確認します。
埋め込み検証子
レプリカセットの移行に対して埋め込み検証子はデフォルトで有効になっています。
エンドポイント保護
mongosync
は、 reverse
エンドポイントを保護しません。 ただし、デフォルトでは、API は localhost のみにバインドされ、他のソースからの呼び出しは受け入れません。 さらに、 reverse
呼び出しでは接続認証情報やユーザー データは公開されません。
制限
reverse
エンドポイントは次のサポートをサポートしていません。
より前のソースクラスターからの移行6.0