ペシミスティック モードでのシャード テーブルからのデータのマージと移行

このドキュメントでは、ペシミスティック モード (既定のモード) でデータ移行 (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 ステートメントを上流のすべてのシャード テーブルで実行する必要があります。
  • たとえば、 DDL ステートメントが 1 に対応するDM-worker-2つ以上のアップストリーム シャード テーブルで実行されない場合、DDL ステートメントを実行した他の DM ワーカーは移行タスクを一時停止し、アップストリーム DDL ステートメントを受信するまでDM-worker-2を待ちます。
• シャーディング グループの移行タスクはDROP DATABASEをサポートしていませDROP TABLE 。
  • DM-worker の同期ユニットは、アップストリームのシャード テーブルのDROP DATABASE / DROP TABLEステートメントを自動的に無視します。
• シャーディング グループの移行タスクはTRUNCATE TABLEをサポートしていません。
  • DM-worker の同期ユニットは、アップストリームのシャード テーブルのTRUNCATE TABLEのステートメントを自動的に無視します。
• シャーディング グループ移行タスクはRENAME TABLEをサポートしますが、次の制限があります (オンライン DDL は別のソリューションでサポートされます)。
  • テーブルの名前は、他のテーブルで使用されていない新しい名前にのみ変更できます。
  • 単一のRENAME TABLEステートメントは、単一の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-worker はタスクを一時停止して、他の DM-worker が DDL ステートメントを受信するのを待つため、データ移行の遅延が増加します。

バックグラウンド

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

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

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

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

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

1. 移行が開始されると、DM-worker の同期ユニットは 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 からもschema V2の DML イベントを受信します。

シャード テーブルの DDL ステートメントは、移行プロセス中に処理されないとします。インスタンス 1 の DDL ステートメントがダウンストリームに移行された後、ダウンストリーム テーブル スキーマはschema V2に変更されます。しかし、インスタンス 2 の場合、DM-worker の同期ユニットはschema V1からt2からt3の 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 移行プロセスは次のように簡素化されます。

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は後続の ( t2の binlog から始まる) DML ステートメントの移行を続行します。
7. DM-masterは、DDL が正常に実行されたというロック所有者からの応答を受信し、DDL ロックを待機している他のすべての DM-worker ( DM-worker-2 ) に、この DDL ステートメントを無視してから、後続の移行を続行するように要求します (次の binlog から開始)。 t4 ) DML ステートメント。

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

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

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

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

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

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

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

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

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

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

1. table_1のt1の DDL ステートメントを受け取ると、DM-worker は DDL 情報と binlog の現在の位置を記録します。
2. DM-worker はt2とt3の間でバイナリログの解析を続けます。
3. DM-worker は、 table_1に属するschema V2スキーマの DML ステートメントを無視し、 table_2に属するschema V1スキーマの DML ステートメントを下流に移行します。
4. table_2のt3の DDL ステートメントを受け取ると、DM-worker は 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 は主に 2 レベルのシャーディング グループを使用して、シャーディング DDL の移行を処理する際の調整と制御を行うと結論付けることができます。簡単なプロセスは次のとおりです。

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