シャードマージシナリオにおけるデータ移行のベストプラクティス

このドキュメントでは、シャードマージシナリオにおけるTiDB データ移行 (DM)の機能と制限について説明し、アプリケーションのデータ移行のベストプラクティスガイドを提供します (デフォルトの「悲観的」モードが使用されます)。

別のデータ移行タスクを使用する

シャードテーブルからのデータのマージと移行ドキュメントでは、「シャーディンググループ」の定義が次のように示されています。シャーディンググループは、同じダウンストリームテーブルにマージおよび移行する必要があるすべてのアップストリームテーブルで構成されます。

現在のシャーディング DDL メカニズムには、異なるシャーディングされたテーブルでの DDL 操作によってもたらされるスキーマ変更を調整するための使用制限あります。予期しない理由によりこれらの制限に違反した場合は、 DMでシャーディングDDLロックを手動で処理するを実行するか、データ移行タスク全体をやり直す必要があります。

例外が発生した場合にデータ移行への影響を軽減するには、各シャーディンググループを個別のデータ移行タスクとしてマージして移行することをお勧めします。これにより、少数のデータ移行タスクのみを手動で処理し、他のタスクには影響を与えないようにすることができます。

シャーディングDDLロックを手動で処理する

シャードテーブルからのデータのマージと移行から、DM のシャーディング DDL ロックは、複数の上流シャーディングされたテーブルから下流への DDL 操作の実行を調整するためのメカニズムであることが簡単にわかります。

したがって、 DM-master ～ shard-ddl-lockコマンドでシャーディング DDL ロックが見つかった場合、またはquery-statusコマンドで一部の DM ワーカーにunresolvedGroupsまたはblockingDDLsが見つかった場合は、 shard-ddl-lock unlockコマンドでシャーディング DDL ロックを手動で解除しようと急いではいけません。

代わりに、次のことができます。

シャーディング DDL ロックの自動解放の失敗が 1 の異常なシナリオを列挙つである場合は、対応する手動ソリューションに従ってシナリオを処理します。
サポートされていないシナリオの場合は、データ移行タスク全体をやり直します。まず、ダウンストリームデータベースのデータと移行タスクに関連付けられているdm_meta情報を空にし、次に、完全および増分データレプリケーションを再実行します。

複数のシャードテーブル間の主キーまたは一意のインデックス間の競合を処理する

複数のシャードテーブルのデータにより、主キーまたは一意のインデックス間で競合が発生する可能性があります。これらのシャードテーブルのシャーディングロジックに基づいて、各主キーまたは一意のインデックスを確認する必要があります。主キーまたは一意のインデックスに関連する 3 つのケースを次に示します。

シャードキー: 通常、同じシャードキーは 1 つのシャードテーブルにのみ存在するため、シャードキーでデータの競合は発生しません。
自動増分主キー: 各シャードテーブルの自動増分主キーは個別にカウントされるため、範囲が重複する可能性があります。この場合、次のセクション自動増分主キーの競合を処理するを参照して解決する必要があります。
その他の主キーまたは一意のインデックス: ビジネスロジックに基づいて分析する必要があります。データが競合する場合は、次のセクション自動増分主キーの競合を処理するを参照して解決することもできます。

自動増分主キーの競合を処理する

このセクションでは、自動インクリメント主キーの競合を処理するための 2 つの推奨ソリューションを紹介します。

列から`PRIMARY KEY`属性を削除します

アップストリームスキーマが次のとおりであると仮定します。

CREATE TABLE `tbl_no_pk` (
  `auto_pk_c1` bigint(20) NOT NULL,
  `uk_c2` bigint(20) NOT NULL,
  `content_c3` text,
  PRIMARY KEY (`auto_pk_c1`),
  UNIQUE KEY `uk_c2` (`uk_c2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

以下の要件を満たしている場合:

auto_pk_c1列目はアプリケーションに影響を与えず、列目のPRIMARY KEY属性に依存しません。
uk_c2列にはUNIQUE KEY属性があり、すべての上流のシャードテーブル内でグローバルに一意です。

次に、次の手順を実行して、シャードされたテーブルをマージするときにauto_pk_c1番目の列によって発生する可能性のあるERROR 1062 (23000): Duplicate entry '***' for key 'PRIMARY'エラーを修正できます。

完全なデータ移行の前に、ダウンストリームデータベースにデータをマージおよび移行するためのテーブルを作成し、 auto_pk_c1列目のPRIMARY KEY属性を通常のインデックスに変更します。
```
CREATE TABLE `tbl_no_pk_2` (
  `auto_pk_c1` bigint(20) NOT NULL,
  `uk_c2` bigint(20) NOT NULL,
  `content_c3` text,
  INDEX (`auto_pk_c1`),
  UNIQUE KEY `uk_c2` (`uk_c2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
```
自動インクリメント主キーの競合のチェックをスキップするには、 task.yamlに次の構成を追加します。
```
ignore-checking-items: ["auto_increment_ID"]
```
完全および増分データレプリケーションタスクを開始します。
実行query-status 、データ移行タスクが正常に処理されたかどうか、および上流のデータがすでにマージされて下流のデータベースに移行されているかどうかを確認します。

複合主キーを使用する

アップストリームスキーマが次のとおりであると仮定します。

CREATE TABLE `tbl_multi_pk` (
  `auto_pk_c1` bigint(20) NOT NULL,
  `uuid_c2` bigint(20) NOT NULL,
  `content_c3` text,
  PRIMARY KEY (`auto_pk_c1`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

以下の要件を満たしている場合:

アプリケーションは、 auto_pk_c1列目のPRIMARY KEY属性に依存しません。
auto_pk_c1列目とuuid_c2列目で構成される複合主キーはグローバルに一意です。
アプリケーションでは複合主キーを使用することが可能です。

次に、次の手順を実行して、シャードされたテーブルをマージするときにauto_pk_c1列によって発生する可能性のあるERROR 1062 (23000): Duplicate entry '***' for key 'PRIMARY'エラーを修正できます。

完全なデータ移行の前に、ダウンストリームデータベースに、データのマージと移行のためのテーブルを作成します。3 列目にPRIMARY KEY属性を指定せず、 auto_pk_c1列目とuuid_c2列目をauto_pk_c1して複合主キーを構成します。
```
CREATE TABLE `tbl_multi_pk_c2` (
  `auto_pk_c1` bigint(20) NOT NULL,
  `uuid_c2` bigint(20) NOT NULL,
  `content_c3` text,
  PRIMARY KEY (`auto_pk_c1`,`uuid_c2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
```
完全および増分データ移行タスクを開始します。
実行query-status 、データ移行タスクが正常に処理されたかどうか、および上流のデータがすでにマージされて下流のデータベースに移行されているかどうかを確認します。

アップストリーム RDS にシャードテーブルが含まれている場合の特別な処理

アップストリームデータソースが RDS であり、シャードテーブルが含まれている場合、SQL クライアントに接続するときに MySQL binlog内のテーブル名が表示されないことがあります。たとえば、アップストリームが UCloud 分散データベースである場合、 binlog内のテーブル名に追加のプレフィックス_0001が付くことがあります。したがって、SQL クライアント内のテーブル名ではなく、 binlog内のテーブル名に基づいてテーブルルーティングを構成する必要があります。

アップストリームでテーブルを作成/削除する

シャードテーブルからのデータのマージと移行では、シャーディング DDL ロックの調整は、下流データベースがすべての上流シャードテーブルの DDL ステートメントを受信するかどうかに依存することは明らかです。また、DM は現在、上流でのシャードテーブルの動的な作成または削除をサポートしていません。したがって、上流でシャードテーブルを作成または削除するには、次の手順を実行することをお勧めします。

アップストリームにシャードテーブルを作成する

アップストリームに新しいシャードテーブルを作成する必要がある場合は、次の手順を実行します。

アップストリームのシャードテーブルで実行されたすべてのシャーディング DDL の調整が完了するまで待機します。
データ移行タスクを停止するには、 stop-task実行します。
アップストリームに新しいシャードテーブルを作成します。
task.yamlファイルの構成で、新しく追加されたシャードテーブルを他の既存のシャードテーブルと 1 つのダウンストリームテーブルにマージできることを確認します。
タスクを開始するにはstart-task実行します。
実行query-status 、データ移行タスクが正常に処理されたかどうか、および上流のデータがすでにマージされて下流のデータベースに移行されているかどうかを確認します。

アップストリームのシャードテーブルを削除する

アップストリームでシャードされたテーブルを削除する必要がある場合は、次の手順を実行します。

シャード化されたテーブルを削除し、 SHOW BINLOG EVENTS実行して、 binlogイベント内のDROP TABLEのステートメントに対応するEnd_log_posを取得し、それをPos-Mとしてマークします。
query-status実行して、DMによって処理されたbinlogイベントに対応する位置（ syncerBinlog ）を取得し、それをPos-Sとしてマークします。
Pos-SがPos-Mより大きい場合、DM がDROP TABLEのステートメントをすべて処理し、ドロップ前のテーブルのデータが下流に移行されているため、後続の操作を実行できることを意味します。それ以外の場合は、DM がデータの移行を完了するまで待機します。
タスクを停止するにはstop-task実行します。
task.yamlファイル内の構成で、アップストリーム内の削除されたシャードテーブルが無視されることを確認します。
タスクを開始するにはstart-task実行します。
query-statusを実行して、データ移行タスクが正常に処理されたかどうかを確認します。

速度制限と交通流制御

複数の上流 MySQL または MariaDB インスタンスからのデータが下流の同じ TiDB クラスターにマージされて移行されると、各上流インスタンスに対応するすべての DM ワーカーが、フルデータレプリケーションと増分データレプリケーションを同時に実行します。つまり、DM ワーカーの数が増えるにつれて、デフォルトの同時実行度 (フルデータ移行ではpool-size 、増分データレプリケーションではworker-count ) が蓄積され、下流データベースに過負荷がかかる可能性があります。この場合、TiDB と DM の監視メトリックに基づいて予備的なパフォーマンス分析を実施し、各同時実行パラメータの値を調整する必要があります。将来的には、DM は部分的に自動化されたトラフィックフロー制御をサポートする予定です。