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

このドキュメントでは、シャードマージシナリオにおける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 NOT NULL,
  `uk_c2` bigint 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 NOT NULL,
  `uk_c2` bigint 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 NOT NULL,
  `uuid_c2` bigint 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列目にPRIMARY KEY属性を指定せず、 auto_pk_c1列目とuuid_c2列目を使用して複合主キーを構成してください。
```
CREATE TABLE `tbl_multi_pk_c2` (
  `auto_pk_c1` bigint NOT NULL,
  `uuid_c2` bigint 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は部分的に自動化されたトラフィックフロー制御をサポートする予定です。