ペシミスティックモードでシャードテーブルからデータをマージおよび移行する

このドキュメントでは、ペシミスティックモード（デフォルトモード）でデータ移行（DM）によって提供されるシャーディングサポート機能を紹介します。この機能を使用すると、アップストリームのMySQLまたはMariaDBインスタンスの同じテーブルスキーマを持つテーブルのデータを、ダウンストリームのTiDBの1つの同じテーブルにマージして移行できます。

制限

DMには、ペシミスティックモードでの次のシャーディングDDL使用制限があります。

論理シャーディンググループ（1つの同じダウンストリームテーブルにマージおよび移行する必要があるすべてのシャードテーブルで構成される）の場合、移行を実行するためにシャードテーブルのソースを正確に含む1つのタスクを使用するように制限されます。
論理シャーディンググループでは、すべてのアップストリームシャーディングテーブルで同じDDLステートメントを同じ順序で実行する必要があり（スキーマ名とテーブル名は異なる場合があります）、現在のDDL操作が完全に行われない限り次のDDLステートメントを実行できません。終了した。
- たとえば、 column Bを追加する前にcolumn Aからtable_1を追加した場合、 column Aを追加する前にcolumn Bからtable_2を追加することはできません。 DDLステートメントを別の順序で実行することはサポートされていません。
シャーディンググループでは、対応するDDLステートメントをすべてのアップストリームシャードテーブルで実行する必要があります。
- たとえば、1に対応するDM-worker-2つ以上のアップストリームシャードテーブルでDDLステートメントが実行されない場合、DDLステートメントを実行した他のDMワーカーは、移行タスクを一時停止し、 DM-worker-2がアップストリームDDLステートメントを受信するのを待ちます。
シャーディンググループの移行タスクはDROP DATABASEをサポートしていませDROP TABLE 。
- DM-workerの同期ユニットは、アップストリームシャードテーブルのDROP DATABASEステートメントを自動的に無視しDROP TABLE 。
シャーディンググループの移行タスクはTRUNCATE TABLEをサポートしていません。
- DM-workerの同期ユニットは、アップストリームシャードテーブルのTRUNCATE TABLEステートメントを自動的に無視します。
シャーディンググループ移行タスクはRENAME TABLEをサポートしますが、次の制限があります（オンラインDDLは別のソリューションでサポートされています）。
- テーブルの名前を変更できるのは、他のテーブルで使用されていない新しい名前のみです。
- 1つのRENAME TABLEステートメントには、1つのRENAME操作のみを含めることができます。
シャーディンググループの移行タスクでは、各DDLステートメントに1つのテーブルのみに対する操作が含まれている必要があります。
各シャードテーブルのテーブルスキーマは、インクリメンタルレプリケーションタスクの開始点で同じである必要があります。これにより、異なるシャードテーブルのDMLステートメントを、明確なテーブルスキーマと、それに続くシャーディングDDLを使用してダウンストリームに移行できるようになります。ステートメントは正しく照合および移行できます。
テーブルルーティングのルールを変更する必要がある場合は、すべてのシャーディングDDLステートメントの移行が完了するのを待つ必要があります。
- シャーディングDDLステートメントの移行中に、 dmctlを使用してrouter-rulesを変更すると、エラーが報告されます。
DDLステートメントが実行されているシャーディンググループに新しいテーブルをCREATE追加する必要がある場合は、テーブルスキーマが新しく変更されたテーブルスキーマと同じであることを確認する必要があります。
- たとえば、元のtable_1とtable_2の両方に最初は2つの列（a、b）があり、シャーディングDDL操作後に3つの列（a、b、c）があるため、移行後、新しく作成されたテーブルにも3つの列（ a、b、c）。
DDLステートメントを受信したDMワーカーは、他のDMワーカーがDDLステートメントを受信するのを待つためにタスクを一時停止するため、データ移行の遅延が増加します。

バックグラウンド

現在、DMはROW形式のbinlogを使用して移行タスクを実行します。 binlogには、テーブルスキーマ情報は含まれていません。 ROWのbinlogを使用してデータを移行する場合、複数のアップストリームテーブルを同じダウンストリームテーブルに移行していない場合、ダウンストリームテーブルのテーブルスキーマを更新できる1つのアップストリームテーブルのDDL操作のみが存在します。 ROWのbinlogは、自己記述の性質を持っていると見なすことができます。移行プロセス中に、DMLステートメントは、列の値とダウンストリームのテーブルスキーマに応じて作成できます。

ただし、シャーディングされたテーブルをマージおよび移行するプロセスで、アップストリームテーブルでDDLステートメントを実行してテーブルスキーマを変更する場合は、生成されたDMLステートメント間の不整合を回避するために、追加の操作を実行してDDLステートメントを移行する必要があります。列の値と実際のダウンストリームテーブルスキーマによって。

簡単な例を次に示します。

上記の例では、マージプロセスが簡略化されており、アップストリームには2つのMySQLインスタンスのみが存在し、各インスタンスには1つのテーブルしかありません。移行が開始されると、2つのシャーディングされたテーブルのテーブルスキーマバージョンはschema V1としてマークされ、DDLステートメントの実行後のテーブルスキーマバージョンはschema V2としてマークされます。

ここで、移行プロセスで、2つのアップストリームシャードテーブルから受信したbinlogデータの時系列が次のようになっていると仮定します。

移行が開始されると、DM-workerの同期ユニットは、2つのシャーディングされたテーブルからschema V1のDMLイベントを受け取ります。
t1で、インスタンス1からのシャーディングDDLイベントが受信されます。
t2以降、同期ユニットはインスタンス1からschema V2のDMLイベントを受信します。ただし、インスタンス2からは、 schema V1のDMLイベントを引き続き受信します。
t3で、インスタンス2からのシャーディングDDLイベントが受信されます。
t4以降、同期ユニットはインスタンス2からもschema V2のDMLイベントを受信します。

シャードテーブルのDDLステートメントは移行プロセス中に処理されないと想定します。インスタンス1のDDLステートメントがダウンストリームに移行された後、ダウンストリームテーブルスキーマがschema V2に変更されます。ただし、たとえば2の場合、DM-workerの同期ユニットはまだt2からt3までのschema V1のDMLイベントを受信しています。したがって、 schema V1のDMLステートメントがダウンストリームにマイグレーションされると、DMLステートメントとテーブル・スキーマの間の不整合がエラーを引き起こし、データを正常にマイグレーションできない可能性があります。

原則

このセクションでは、ペシミスティックモードでの上記の例に基づいて、シャーディングされたテーブルをマージするプロセスでDMがDDLステートメントを移行する方法を示します。

この例では、 DM-worker-1はMySQLインスタンス1からデータを移行し、 DM-worker-2はMySQLインスタンス2からデータを移行しますDM-masterは複数のDMワーカー間のDDL移行を調整します。 DDLステートメントを受信するDM-worker-1から開始して、DDL移行プロセスは次のように簡略化されます。

DM-worker-1はMySQLインスタンス1からt1でDDLステートメントを受信し、対応するDDLおよびDMLステートメントのデータ移行を一時停止し、DDL情報をDM-masterに送信します。
DM-masterは、受信したDDL情報に基づいてこのDDLステートメントの移行を調整する必要があると判断し、このDDLステートメントのロックを作成し、DDLロック情報をDM-worker-1に送り返し、同時にDM-worker-1をこのロックの所有者としてマークします。
DM-worker-2は、MySQLインスタンス2からt3でDDLステートメントを受信するまでDMLステートメントの移行を続行し、このDDLステートメントのデータ移行を一時停止し、DDL情報をDM-masterに送信します。
DM-masterは、受信したDDL情報に基づいて、このDDLステートメントのロックがすでに存在していると判断し、ロック情報をDM-worker-2に直接送信します。
タスク開始時の構成情報、アップストリームMySQLインスタンスのシャードテーブル情報、およびデプロイメントトポロジ情報に基づいて、 DM-masterは、マージするすべてのアップストリームシャードテーブルのこのDDLステートメントを受信したと判断し、このDDLステートメントをダウンストリームに移行するためのDDLロック（ DM-worker-1 ）。
DM-worker-1は、ステップ2で受信したDDLロック情報に基づいてDDLステートメント実行要求を検証し、このDDLステートメントをダウンストリームに移行して、結果をDM-masterに送信します。この操作が成功すると、 DM-worker-1は後続の（ t2のbinlogから開始して）DMLステートメントの移行を続行します。
DM-masterは、DDLが正常に実行されたというロック所有者からの応答を受信し、DDLロックを待機している他のすべてのDMワーカー（ DM-worker-2 ）に、このDDLステートメントを無視して、後続の（binlogから開始して）移行を続行するように要求します。 t4 ）DMLステートメント。

複数のDMワーカー間でのシャーディングDDL移行を処理するDMの特性は、次のように結論付けることができます。

タスク構成とDMクラスタ展開トポロジー情報に基づいて、論理シャーディング・グループがDM-masterに組み込まれ、DDL移行を調整します。グループメンバーは、移行タスクから分割された各サブタスクを処理するDMワーカーです）。
binlogイベントからDDLステートメントを受信した後、各DMワーカーはDDL情報をDM-masterに送信します。
DM-masterは、各DMワーカーから受信したDDL情報とシャーディンググループ情報に基づいて、DDLロックを作成または更新します。
シャーディンググループのすべてのメンバーが同じ特定のDDLステートメントを受け取った場合、これは、アップストリームシャードテーブルでのDDL実行前のすべてのDMLステートメントが完全に移行され、このDDLステートメントを実行できることを示します。その後、DMは後続のDMLステートメントの移行を続行できます。
テーブルルーターによって変換された後、アップストリームシャードテーブルのDDLステートメントは、ダウンストリームで実行されるDDLステートメントと一致している必要があります。したがって、このDDLステートメントはDDL所有者が1回だけ実行する必要があり、他のすべてのDMワーカーはこのDDLステートメントを無視できます。

上記の例では、各DMワーカーに対応するアップストリームのMySQLインスタンスにマージする必要があるシャードテーブルは1つだけです。ただし、実際のシナリオでは、複数のシャードスキーマに複数のシャードテーブルがあり、1つのMySQLインスタンスにマージされる場合があります。そして、これが発生すると、シャーディングDDL移行の調整がより複雑になります。

1つのMySQLインスタンスにマージされる2つのシャードテーブル、つまりtable_1とtable_2があると仮定します。

データは同じMySQLインスタンスから取得されるため、すべてのデータは同じbinlogストリームから取得されます。この場合、時系列は次のようになります。

DM-workerの同期ユニットは、移行の開始時に両方のシャーディングされたテーブルからschema V1のDMLステートメントを受け取ります。
t1で、DM-workerの同期ユニットはtable_1のDDLステートメントを受け取ります。
t2からt3まで、受信したデータには、 table_1からschema V2のDMLステートメントとtable_2からschema V1のDMLステートメントが含まれます。
t3で、DM-workerの同期ユニットはtable_2のDDLステートメントを受け取ります。
t4以降、DM-workerの同期ユニットは両方のテーブルからschema V2のDMLステートメントを受け取ります。

特にデータ移行中にDDLステートメントが処理されない場合、 table_1のDDLステートメントがダウンストリームに移行され、ダウンストリームテーブルスキーマが変更されると、 table_2からschema V1のDMLステートメントは正常に移行できません。したがって、単一のDMワーカー内に、 DM-master内と同様の論理シャーディンググループが作成されます。ただし、このグループのメンバーは、同じアップストリームMySQLインスタンス内の異なるシャーディングテーブルです。

ただし、DMワーカーがシャーディンググループの移行をそれ自体の中で調整する場合、 DM-masterによって実行されるものと完全に同じではありません。その理由は次のとおりです。

DMワーカーがtable_1のDDLステートメントを受信すると、移行を一時停止することはできず、後続のtable_2のDDLステートメントを取得するためにbinlogの解析を続行する必要があります。これは、 t2からt3の間で解析を継続する必要があることを意味します。
t2からt3までのbinlog解析プロセス中、シャーディングDDLステートメントが移行されて正常に実行されるまで、 table_1からschema V2のDMLステートメントをダウンストリームに移行することはできません。

DMでは、DMワーカー内でDDLステートメントをシャーディングする単純化された移行プロセスは次のとおりです。

table_1 at t1のDDLステートメントを受信すると、DMワーカーはDDL情報とbinlogの現在の位置を記録します。
DM-workerは、 t2からt3の間でbinlogの解析を続行します。
DM-workerは、 table_1に属するschema V2スキーマのDMLステートメントを無視し、 table_2に属するschema V1スキーマのDMLステートメントをダウンストリームに移行します。
table_2 at t3のDDLステートメントを受信すると、DMワーカーはDDL情報とbinlogの現在の位置を記録します。
DMワーカーは、移行タスクの構成とアップストリームスキーマおよびテーブルの情報に基づいて、MySQLインスタンス内のすべてのシャーディングテーブルのDDLステートメントが受信されたと判断し、それらをダウンストリームに移行してダウンストリームテーブルスキーマを変更します。
DM-workerは、新しいbinlogストリームを解析する開始点を、ステップ1で保存された位置に設定します。
DM-workerは、binlogの解析をt2からt3の間で再開します。
DM-workerは、 table_1に属するschema V2スキーマのDMLステートメントをダウンストリームに移行し、 table_2に属するschema V1スキーマのDMLステートメントを無視します。
ステップ4で保存されたbinlog位置を解析した後、DMワーカーは、ステップ3で無視されたすべてのDMLステートメントが再びダウンストリームにマイグレーションされたと判断します。
DM-workerは、binlogの位置t4から移行を再開します。

上記の分析から、DMは、シャーディングDDLの移行を処理する際の調整と制御に、主に2レベルのシャーディンググループを使用していると結論付けることができます。簡略化されたプロセスは次のとおりです。

各DMワーカーは、アップストリームMySQLインスタンス内の複数のシャーディングテーブルで構成される対応するシャーディンググループのDDLステートメントの移行を個別に調整します。
DM-workerは、すべてのシャーディングされたテーブルのDDLステートメントを受信した後、DDL情報をDM-masterに送信します。
DM-masterは、受信したDDL情報に基づいて、DMワーカーで構成されるシャーディンググループのDDL移行を調整します。
すべてのDMワーカーからDDL情報を受信した後、 DM-masterはDDLロック所有者（特定のDMワーカー）にDDLステートメントの実行を要求します。
DDLロックの所有者はDDLステートメントを実行し、結果をDM-masterに返します。次に、所有者は、DDL移行の内部調整中に、以前に無視されたDMLステートメントの移行を再開します。
DM-masterは、所有者がDDLステートメントを正常に実行したことを確認した後、他のすべてのDMワーカーに移行を続行するように要求します。
他のすべてのDMワーカーは、DDL移行の内部調整中に、以前に無視されたDMLステートメントの移行を個別に再開します。
無視されたDMLステートメントの移行が再度終了すると、すべてのDMワーカーは通常の移行プロセスを再開します。