TiDB データ移行 (DM) のベストプラクティス

TiDB データ移行 (DM)はPingCAPが開発したデータ移行ツールです。MySQL、Percona MySQL、MariaDB、Amazon RDS for MySQL、Amazon AuroraなどのMySQL互換データベースからTiDBへの完全および増分データ移行をサポートします。

DM は次のシナリオで使用できます。

• 単一のMySQL互換データベースインスタンスからTiDBへの完全および増分データ移行を実行します。
• 小さなデータセット（1 TiB 未満）の MySQL シャードを TiDB に移行してマージする
• データハブのシナリオでは、ビジネスデータの中間プラットフォームやビジネスデータのリアルタイム集約など、データ移行のミドルウェアとしてDMを使用します。

このドキュメントでは、DM をエレガントかつ効率的に使用する方法と、DM を使用する際によくある間違いを避ける方法について説明します。

パフォーマンスの制限

• DMは1000台のワークノードの同時管理をサポートし、タスクの最大数は600です。ワークノードの高可用性を確保するには、一部のワークノードをスタンバイノードとして確保する必要があります。スタンバイノードの推奨数は、移行タスクが実行中のワークノード数の20%～50%です。
• 単一のワークノードは、理論上、ワーカーあたり最大30K QPSのレプリケーションQPSをサポートできます。これはスキーマやワークロードによって異なります。アップストリームのバイナリログ処理能力は、ワーカーあたり最大20MB/秒です。
• DMをデータレプリケーションミドルウェアとして長期的に使用する場合は、DMコンポーネントのデプロイメントアーキテクチャを慎重に設計する必要があります。詳細については、 DMマスターとDMワーカーをデプロイ参照してください。

データ移行前

データ移行を行う前に、ソリューション全体の設計が非常に重要です。以下のセクションでは、ビジネスと実装の観点から、ベストプラクティスとシナリオを説明します。

ビジネス側のベストプラクティス

ワークロードを複数のノードに均等に分散させるため、分散データベースの設計は従来のデータベースとは異なります。このソリューションでは、移行コストの低減と移行後のロジックの正確性の両方を確保する必要があります。以下のセクションでは、データ移行前のベストプラクティスについて説明します。

スキーマ設計におけるAUTO_INCREMENTのビジネスへの影響

TiDBのAUTO_INCREMENTはMySQLのAUTO_INCREMENTと互換性があります。ただし、分散データベースであるTiDBは、通常複数のコンピューティングノード（クライアント側のエントリ）を備えています。アプリケーションデータの書き込み時には、ワークロードが均等に分散されます。そのため、テーブルにAUTO_INCREMENT列目がある場合、その列の自動インクリメントIDが不連続になる可能性があります。詳細については、 自動インクリメント参照してください。

ビジネスで自動増分 ID に大きく依存している場合は、 MySQL互換のAUTO_INCREMENTモードまたはSEQUENCE関数使用を検討してください。

クラスター化インデックスの使用

テーブルを作成する際に、主キーをクラスター化インデックスまたは非クラスター化インデックスのいずれかに宣言できます。以下のセクションでは、それぞれの選択肢の長所と短所について説明します。

• クラスター化インデックス

  クラスター化インデックス 、データstorageのハンドルID（行ID）として主キーを使用します。主キーを使用してクエリを実行すると、テーブル参照を回避できるため、クエリのパフォーマンスが効果的に向上します。ただし、テーブルが書き込み中心で、主キーにAUTO_INCREMENT使用している場合、 書き込みホットスポットの問題発生する可能性が高く、クラスターのパフォーマンスが低下し、単一のstorageノードのパフォーマンスボトルネックが発生します。

• 非クラスター化インデックス + shard row id bit

  非クラスター化インデックスとshard row id bit使用すると、 AUTO_INCREMENT使用時の書き込みホットスポット問題を回避できます。ただし、このシナリオでは、主キーを使用してクエリを実行する際にテーブル参照がクエリパフォーマンスに影響を与える可能性があります。

• クラスター化インデックス + 外部分散IDジェネレータ

  クラスター化インデックスを使用し、IDの連続性を維持したい場合は、SnowflakeアルゴリズムやLeafなどの外部分散IDジェネレータの使用を検討してください。アプリケーションプログラムがシーケンスIDを生成するため、IDの連続性がある程度保証されます。また、クラスター化インデックスを使用する利点も維持されます。ただし、アプリケーションをカスタマイズする必要があります。

• クラスター化インデックス + AUTO_RANDOM

  このソリューションは、クラスター化インデックスの利点を維持しながら、書き込みホットスポットの問題を回避できます。カスタマイズの手間も少なくて済みます。書き込みデータベースとしてTiDBを使用するように切り替える際に、スキーマ属性を変更できます。後続のクエリでID列を使用してデータをソートする必要がある場合は、 AUTO_RANDOM ID列を使用し、6ビット（符号ビット1つとシャードビット5つ）を左シフトすることで、クエリデータの順序を確保できます。例：

  CREATE TABLE t (a bigint PRIMARY KEY AUTO_RANDOM, b varchar(255));
  Select a, a<<6 ,b from t order by a <<6 desc
  

次の表は、各ソリューションの長所と短所をまとめたものです。

MySQLシャードの重要なポイント

分割と結合

小さなデータセットのMySQLシャードをTiDBに移行してマージするには DM を使用することをお勧めします。

データのマージに加えて、もう一つの典型的なシナリオはデータのアーカイブです。データは絶えず書き込まれており、時間の経過とともに、大量のデータはホットデータからウォームデータ、さらにはコールドデータへと徐々に変化していきます。幸いなことに、TiDBではデータごとに異なる配置ルール設定できます。ルールの最小粒度はパーティションです。

したがって、書き込み集中型のシナリオでは、データをアーカイブし、ホットデータとコールドデータを異なるメディアに別々に保存する必要があるかどうかを最初から評価することをお勧めします。データをアーカイブする必要がある場合は、移行前にパーティションルールを設定できます（TiDBはまだテーブルの再構築操作をサポートしていません）。これにより、将来的にテーブルを再作成してデータをインポートする必要がなくなります。

悲観的モードと楽観的モード

DMはデフォルトで悲観的モードを使用します。MySQLシャードの移行とマージのシナリオでは、上流シャードのスキーマの変更によって下流データベースへのDML書き込みがブロックされる可能性があります。すべてのスキーマが変更され、同じ構造になるまで待ってから、ブレークポイントから移行を続行する必要があります。

• アップストリームのスキーマ変更に時間がかかる場合、アップストリームのBinlogがクリーンアップされる可能性があります。この問題を回避するには、リレーログを有効にしてください。詳細については、 リレーログを使用する参照してください。

• 上流のスキーマ変更によるデータ書き込みのブロックを避けたい場合は、楽観的モードの使用を検討してください。この場合、DMは上流のシャードスキーマの変更を検出してもデータ移行をブロックせず、データの移行を継続します。ただし、上流と下流で互換性のないフォーマットが検出された場合は、移行タスクが停止します。この問題は手動で解決する必要があります。

次の表は、楽観的モードと悲観的モードの長所と短所をまとめたものです。

その他の制限と影響

上流と下流のデータ型

TiDBはMySQLのほとんどのデータ型をサポートしています。ただし、一部の特殊な型（ SPATIALなど）はまだサポートされていません。データ型の互換性については、 データ型参照してください。

文字セットと照合順序

TiDB v6.0.0以降、新しい照合順序フレームワークがデフォルトで使用されます。以前のバージョンでは、TiDBでutf8_general_ci、utf8mb4_general_ci、utf8_unicode_ci、utf8mb4_unicode_ci、gbk_chinese_ci、gbk_binをサポートするには、クラスター作成時にnew_collations_enabled_on_first_bootstrapをtrueに設定して明示的に宣言する必要がありました。詳細については、 照合のための新しいフレームワーク参照してください。

TiDBのデフォルトの文字セットはutf8mb4です。上流および下流のデータベースとアプリケーションではutf8mb4を使用することをお勧めします。上流データベースで文字セットまたは照合順序が明示的に指定されている場合は、TiDBがそれをサポートしているかどうかを確認する必要があります。

TiDB v6.0.0以降、GBKがサポートされています。詳細については、以下のドキュメントをご覧ください。

• 文字セットと照合順序
• GBK互換性

展開のベストプラクティス

DMマスターとDMワーカーをデプロイ

DM は DM マスター ノードと DM ワーカー ノードで構成されます。

• DMマスターは、移行タスクのメタデータを管理し、DMワーカーノードのスケジュールを管理します。これはDMプラットフォーム全体の中核です。そのため、DMマスターをクラスターとして展開することで、DMプラットフォームの高可用性を確保できます。

• DMワーカーは、上流および下流の移行タスクを実行します。DMワーカーノードはステートレスです。最大1000個のDMワーカーノードをデプロイできます。DMを使用する場合は、高可用性を確保するために、アイドル状態のDMワーカーをいくつか確保することをお勧めします。

移行タスクを計画する

MySQLシャードの移行とマージを行う際、上流のシャードの種類に応じて移行タスクを分割できます。例えば、シャードusertable_1~50とLogtable_1~50 2種類のシャードである場合、2つの移行タスクを作成できます。これにより、移行タスクテンプレートが簡素化され、データ移行の中断による影響を効果的に抑制できます。

大規模なデータセットの移行については、次の提案を参照して移行タスクを分割できます。

• アップストリームで複数のデータベースを移行する必要がある場合は、データベースの数に応じて移行タスクを分割できます。

• 上流の書き込み負荷に応じてタスクを分割します。つまり、上流でDML操作が頻繁に実行されるテーブルを別の移行タスクに分割します。DML操作が頻繁に実行されないテーブルは、別の移行タスクで移行します。この方法は、特に上流のテーブルに大量のログが書き込まれている場合、移行の進行を高速化できます。ただし、大量のログを含むテーブルが業務全体に影響を与えない場合は、この方法も有効です。

移行タスクを分割することで保証されるのは、最終的なデータの整合性のみであることにご注意ください。リアルタイムの整合性は、様々な理由により大きく変動する可能性があります。

次の表は、さまざまなシナリオにおける DM マスターと DM ワーカーの推奨される展開計画を示しています。

アップストリームデータソースを選択して構成する

DM は、フルデータ移行を実行する際にデータベース全体のデータをバックアップし、並列論理バックアップ方式を採用しています。MySQL のバックアップ中に、グローバル読み取りロックFLUSH TABLES WITH READ LOCKが追加されます。上流データベースの DML および DDL 操作は短時間ブロックされます。そのため、上流のバックアップ データベースを使用してフルデータ バックアップを実行し、データ ソースの GTID 機能を有効にすることを強くお勧めします ( enable-gtid: true )。これにより、上流からの影響を回避し、上流のマスター ノードに切り替えて増分移行中のレイテンシーを削減できます。上流の MySQL データ ソースを切り替える手順については、 アップストリーム MySQL インスタンス間の DM ワーカー接続を切り替える参照してください。

次の点に注意してください。

• 完全なデータ バックアップは、アップストリーム データベースのマスター ノードでのみ実行できます。

  このシナリオでは、設定ファイル内のconsistencyパラメータをnone mydumpers.global.extra-args: "--consistency none" ）に設定することで、マスターノードへのグローバル読み取りロックの追加を回避できます。ただし、これはフルバックアップのデータ整合性に影響を与え、アップストリームとダウンストリーム間でデータの不整合が生じる可能性があります。

• バックアップ スナップショットを使用して完全なデータ移行を実行します (AWS 上の MySQL RDS およびAurora RDS の移行にのみ適用されます)

  移行対象のデータベースがAWS MySQL RDSまたはAurora RDSの場合、RDSスナップショットを使用してAmazon S3のバックアップデータをTiDBに直接移行し、データの整合性を確保できます。詳細については、 Amazon Auroraから TiDB へのデータ移行ご覧ください。

構成の詳細

大文字の使用

TiDBスキーマ名はデフォルトでは大文字と小文字を区別しません（つまりlower_case_table_names:2 ）。しかし、アップストリームのMySQLデータベースのほとんどは、デフォルトで大文字と小文字を区別するLinuxシステムを使用しています。この場合、スキーマがアップストリームから正しく移行されるようにするには、DMタスク設定ファイルでcase-sensitiveからtrueに設定する必要があります。

特殊なケースとして、たとえば、アップストリームにTableなどの大文字のテーブルとtableなどの小文字のテーブルの両方を持つデータベースがある場合、スキーマの作成時にエラーが発生します。

ERROR 1050 (42S01): Table '{tablename}' already exists

フィルタールール

データソースの設定を開始するとすぐに、フィルタールールを設定できます。詳細については、 データ移行タスクコンフィグレーションガイド参照してください。フィルタールールを設定することの利点は次のとおりです。

• ダウンストリームで処理する必要があるBinlogイベントの数を減らし、移行の効率を向上させます。
• 不要なリレーログのstorageを削減し、ディスク領域を節約します。

注記：

MySQLシャードを移行およびマージする際に、データソースにフィルタルールを設定している場合は、データソースと移行タスクの間でルールが一致していることを確認する必要があります。一致していない場合、移行タスクが長時間にわたって増分データを受信できないという問題が発生する可能性があります。

リレーログを使用する

MySQLのマスター/スタンバイメカニズムでは、非同期レプリケーションの信頼性と効率性を確保するために、スタンバイノードがリレーログのコピーを保存します。DMは、DMワーカーへのリレーログのコピーの保存もサポートしています。storage場所や有効期限などの情報を設定できます。この機能は、以下のシナリオに適用されます。

• 完全データ移行および増分データ移行において、完全データの量が多い場合、上流のバイナリログのアーカイブにかかる時間よりも、全体の処理に時間がかかります。その結果、増分レプリケーションタスクが正常に開始されないことがあります。リレーログを有効にすると、完全移行の開始時にDM-workerがリレーログの受信を開始します。これにより、増分タスクの失敗を回避できます。

• DMを使用して長時間のデータレプリケーションを実行する場合、様々な理由により移行タスクが長時間ブロックされることがあります。リレーログを有効にすると、移行タスクのブロックによって上流のバイナリログが再利用される問題を効果的に解決できます。

リレーログの使用にはいくつかの制限があります。DMは高可用性をサポートしています。DMワーカーに障害が発生すると、アイドル状態のDMワーカーインスタンスを稼働中のインスタンスに昇格させようとします。アップストリームのバイナリログに必要な移行ログが含まれていない場合、中断が発生する可能性があります。リレーログを新しいDMワーカーノードにできるだけ早く手動でコピーし、対応するリレーメタファイルを変更する必要があります。詳細については、 トラブルシューティング参照してください。

アップストリームでPT-osc/GH-ostを使用する

MySQLの日常的な運用・保守では、業務への影響を最小限に抑えるため、通常、PT-osc/GH-ostなどのツールを使用してオンラインでスキーマを変更します。しかし、このプロセス全体はMySQL Binlogに記録されます。このようなデータを下流のTiDBに移行すると、不要な書き込み操作が大量に発生し、効率的でも経済的でもありません。

この問題を解決するため、DMは移行タスクの設定時にPT-oscやGH-ostなどのサードパーティ製データツールをサポートしています。これらのツールを使用すると、DMは冗長データを移行せず、データの整合性を確保します。詳細については、 GH-ost/PT-osc を使用するデータベースからの移行参照してください。

移行中のベストプラクティス

このセクションでは、移行中に発生する可能性のある問題のトラブルシューティング方法について説明します。

上流と下流のスキーマの不一致

よくあるエラーは次のとおりです:

• messages: Column count doesn't match value count: 3 (columns) vs 2 (values)
• Schema/Column doesn't match

このような問題は通常、下流TiDBのインデックスの変更または追加、あるいは下流TiDBの列数の増加によって発生します。このようなエラーが発生した場合は、上流と下流のスキーマに不整合がないか確認してください。

このような問題を解決するには、DMにキャッシュされたスキーマ情報を下流のTiDBスキーマと一致するように更新します。詳細については、 移行するテーブルのテーブルスキーマを管理する参照してください。

下流にさらに列がある場合は、 より多くの列を持つ下流の TiDB テーブルにデータを移行する参照してください。

DDL の失敗により移行タスクが中断されました

DMは、移行タスクの中断を引き起こすDDL文のスキップまたは置換をサポートしています。詳細については、 失敗したDDL文の処理参照してください。

データ移行後のデータ検証

データ移行後にデータの整合性を検証することをお勧めします。TiDB は、データ検証を完了するために役立つ同期差分インスペクター提供します。

sync-diff-inspector は、DM タスクを通じてデータ整合性チェック対象のテーブルリストを自動管理できるようになりました。以前の手動設定と比較して、より効率的です。詳細はDM レプリケーション シナリオにおけるデータ チェックご覧ください。

DM v6.2.0以降、DMは増分レプリケーションにおける継続的なデータ検証をサポートしています。詳細については、 DMにおける継続的なデータ検証参照してください。

長期データ複製

DMを使用して長期的なデータレプリケーションタスクを実行する場合、メタデータのバックアップは必須です。メタデータのバックアップは、移行クラスタの再構築を確実にする一方で、移行タスクのバージョン管理を実現できます。詳細については、 データソースのエクスポートとインポート、およびクラスターのタスクコンフィグレーション参照してください。