悲観モードでシャードテーブルからデータをマージおよび移行する

このドキュメントでは、データ移行（DM）の悲観的モード（デフォルトモード）で提供されるシャーディングサポート機能について説明します。この機能を使用すると、上流のMySQLまたはMariaDBインスタンスにある同じテーブルスキーマを持つテーブルのデータを、下流のTiDBにある同じテーブルにマージして移行できます。

制限

DM には、悲観的モードでのシャーディング DDL の使用に関する次の制限があります。

• 論理シャーディング グループ(1 つの同じダウンストリーム テーブルにマージおよび移行する必要があるすべてのシャード テーブルで構成) の場合、移行を実行するには、シャード テーブルのソースを正確に含む 1 つのタスクを使用するように制限されます。
• 論理シャーディング グループでは、上流のすべてのシャーディングされたテーブルで同じ DDL ステートメントを同じ順序で実行する必要があり (スキーマ名とテーブル名は異なる場合があります)、現在の DDL 操作が完全に終了しない限り次の DDL ステートメントは実行できません。
  • 例えば、 column B加算する前にtable_1にcolumn A加算した場合、 column A加算する前にcolumn Bにtable_2を加算することはできません。DDL文を異なる順序で実行することはサポートされていません。
• シャーディング グループでは、対応する DDL ステートメントをすべての上流のシャーディングされたテーブルで実行する必要があります。
  • たとえば、 DM-worker-2に対応する 1 つ以上のアップストリーム シャード テーブルで DDL ステートメントが実行されない場合、DDL ステートメントを実行した他の DM ワーカーは移行タスクを一時停止し、 DM-worker-2アップストリーム DDL ステートメントを受信するまで待機します。
• シャーディング グループ移行タスクはDROP DATABASE DROP TABLEしていません。
  • DM-worker の同期ユニットはDROP TABLE DROP DATABASEを自動的に無視します。
• シャーディング グループ移行タスクはTRUNCATE TABLEサポートしていません。
  • DM ワーカーの同期ユニットは、上流のシャード テーブルの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にはテーブルスキーマ情報は含まれていません。3 ROWbinlogを使用してデータを移行する場合、複数の上流テーブルを同じ下流テーブルに移行していない限り、下流テーブルのテーブルスキーマを更新できるDDL操作は1つの上流テーブルに対してのみ存在します。5 ROWのbinlogは自己記述的な性質を持つと考えられます。移行プロセス中、列値と下流テーブルスキーマに基づいてDML文を作成できます。

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

以下に簡単な例を示します。

上記の例では、上流にMySQLインスタンスが2つしか存在せず、各インスタンスにはテーブルが1つしかないため、マージプロセスが簡略化されています。移行開始時に、2つのシャードテーブルのテーブルスキーマバージョンはschema V1とマークされ、DDL文実行後のテーブルスキーマバージョンはschema V2とマークされます。

ここで、移行プロセスで、2 つの上流のシャード テーブルから受信したbinlogデータが次の時間順序になっていると仮定します。

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

シャードテーブルのDDL文が移行プロセス中に処理されないと仮定します。インスタンス1のDDL文がダウンストリームに移行された後、ダウンストリームのテーブルスキーマはschema V2に変更されます。しかし、インスタンス2では、DMワーカーの同期ユニットがt2からt3までの間、 schema V1のDMLイベントを受信し続けています。そのため、 schema V1のDML文がダウンストリームに移行されると、DML文とテーブルスキーマの不整合によりエラーが発生し、データが正常に移行されない可能性があります。

原則

このセクションでは、上記の悲観的モードの例に基づいて、DM がシャード テーブルをマージするプロセスで DDL ステートメントを移行する方法を示します。

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

1. DM-worker-1 、 t1で MySQL インスタンス 1 から DDL ステートメントを受信し、対応する DDL および DML ステートメントのデータ移行を一時停止し、 DDL 情報をDM-masterに送信します。
2. DM-master 、受信した DDL 情報に基づいてこの DDL ステートメントの移行を調整する必要があることを判断し、この DDL ステートメントのロックを作成し、DDL ロック情報をDM-worker-1に送り返し、同時にDM-worker-1このロックの所有者としてマークします。
3. DM-worker-2 、 t3で MySQL インスタンス 2 から DDL ステートメントを受信するまで DML ステートメントの移行を継続し、この DDL ステートメントのデータ移行を一時停止し、 DDL 情報をDM-masterに送信します。
4. DM-master 、受信した DDL 情報に基づいて、この DDL ステートメントのロックがすでに存在すると判断し、ロック情報を直接DM-worker-2に送信します。
5. タスク開始時の設定情報、上流MySQLインスタンス内のシャードテーブル情報、デプロイメントトポロジ情報に基づいて、 DM-master 、マージ対象となる上流シャードテーブルすべてのこのDDL文を受信したと判断し、DDLロックの所有者（ DM-worker-1 ）にこのDDL文を下流に移行するように要求します。
6. DM-worker-1 、ステップ 2 で受信した DDL ロック情報に基づいて DDL 文の実行要求を検証し、この DDL 文を下流へ移行し、その結果をDM-masterに送信します。この操作が成功した場合、 DM-worker-1後続の DDL 文（binlogのt2から開始）の移行を継続します。
7. DM-masterロック所有者からDDLが正常に実行されたという応答を受け取り、DDLロックを待機している他のすべてのDMワーカー（ DM-worker-2 ）にこのDDL文を無視して、後続の（binlogのt4から始まる）DML文の移行を続行するように要求します。

複数の DM ワーカー間でのシャーディング DDL 移行を処理する DM の特性は、次のようにまとめられます。

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

上記の例では、各DMワーカーに対応する上流MySQLインスタンスでマージする必要があるシャードテーブルは1つだけです。しかし、実際のシナリオでは、複数のシャードスキーマにある複数のシャードテーブルを1つのMySQLインスタンスにマージする必要がある場合があります。このような場合、シャーディングDDLの移行の調整はより複雑になります。

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

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

1. 移行が開始されると、DM ワーカーの同期ユニットは、両方のシャード テーブルからschema V1の DML ステートメントを受け取ります。
2. t1では、 DM ワーカーの同期ユニットがtable_1の DDL ステートメントを受信します。
3. t2からt3まで、受信データにはtable_1からschema V2の DML 文とtable_2からschema V1の DML 文が含まれます。
4. t3では、 DM ワーカーの同期ユニットがtable_2の DDL ステートメントを受信します。
5. t4以降、DM ワーカーの同期ユニットは、両方のテーブルから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 ステートメントのシャーディングの簡略化された移行プロセスは次のとおりです。

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

上記の分析から、DMはシャーディングDDLの移行処理において、主に2階層のシャーディンググループを調整と制御に使用していることがわかります。簡略化したプロセスは以下のとおりです。

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