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% です。
• 理論的には、単一の作業ノードはワーカーあたり最大 30,000 QPS のレプリケーション QPS をサポートできます。これはスキーマやワークロードによって異なります。アップストリームのバイナリログを処理できる能力は、ワーカーあたり最大 20 MB/秒です。
• DM をデータ レプリケーション ミドルウェアとして長期間使用する場合は、DM コンポーネントのデプロイメントアーキテクチャを慎重に設計する必要があります。詳細については、 DM マスターと DM ワーカーをデプロイを参照してください。

データ移行前

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

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

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

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

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

ビジネスが自動インクリメント ID に強く依存している場合は、 シーケンス機能の使用を検討してください。

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

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

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

  クラスター化インデックスデータ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 列を使用して 5 ビット左シフトし、クエリ データの順序を確保できます。例えば：

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

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

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

分割と結合

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

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

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

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

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

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

• 上流のスキーマ変更によりデータ書き込みをブロックしたくない場合は、楽観的モードの使用を検討してください。この場合、DM は上流のシャード スキーマの変更を検出した場合でもデータ移行をブロックせず、データの移行を続行します。ただし、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 ワーカー接続を切り替えるを参照してください。

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

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

  このシナリオでは、構成ファイルmydumpers.global.extra-args: "--consistency none"で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 ワーカーはリレー ログの受信を開始します。これにより、増分タスクの失敗が回避されます。

• 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 でインデックスが変更または追加されたか、ダウンストリームに列が増えたことが原因で発生します。このようなエラーが発生した場合は、上流と下流のスキーマに矛盾がないか確認してください。

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

下流にさらに多くの列がある場合は、 より多くの列を含むダウンストリーム TiDB テーブルにデータを移行するを参照してください。

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

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

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

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

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

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

長期的なデータレプリケーション

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