データ移行の概要
TiDBデータ移行 (DM)は統合データ移行タスク管理プラットフォームであり、MySQL互換データベース(MySQL、MariaDB、 Aurora MySQLなど)からTiDBへの完全なデータ移行と増分データ複製をサポートします。データ移行の運用コストを削減し、トラブルシューティングプロセスを簡素化するのに役立ちます。データ移行にDMを使用する場合は、次の操作を実行する必要があります。
- DMクラスターをデプロイする
- アップストリームデータソースを作成し、データソースアクセス情報を保存します
- データ移行タスクを作成して、データをデータソースからTiDBに移行します
データ移行タスクには、完全なデータ移行と増分データレプリケーションの2つの段階があります。
- 完全なデータ移行:対応するテーブルのテーブル構造をデータソースからTiDBに移行してから、データソースに格納されているデータを読み取り、TiDBクラスタに書き込みます。
- インクリメンタルデータレプリケーション:完全なデータ移行が完了すると、データソースからの対応するテーブルの変更が読み取られ、TiDBクラスタに書き込まれます。
DMバージョン
このドキュメントは、DMの最新の安定バージョンであるDMv5.4に適用されます。
v5.4より前では、DMドキュメントはTiDBドキュメントから独立しています。これらの以前のバージョンのDMドキュメントにアクセスするには、次のリンクのいずれかをクリックします。
- DMv5.3のドキュメント
- DMv2.0のドキュメント
- DMv1.0のドキュメント (DMの最も初期の安定バージョンであるため、お勧めしません)
ノート:
- 2021年10月以降、DMのGitHubリポジトリはpingcap / tiflowに移動されました。 DMに問題がある場合は、フィードバックのために
pingcap/tiflow
リポジトリに問題を送信してください。- 以前のバージョン(v1.0およびv2.0)では、DMはTiDBに依存しないバージョン番号を使用します。 v5.3以降、DMはTiDBと同じバージョン番号を使用します。 DMv2.0の次のバージョンはDMv5.3です。 DM v2.0からv5.3への互換性の変更はなく、アップグレードプロセスは通常のアップグレードと同じで、バージョン番号が増えるだけです。
基本的な機能
このセクションでは、DMが提供する基本的なデータ移行機能について説明します。
スキーマおよびテーブルレベルでのリストの移行をブロックおよび許可する
リストのフィルタリングルールをブロックして許可するは、MySQLのreplication-rules-db
機能に似ており、一部のデータベースのみまたは一部のテーブルのみのすべての操作をフィルタリングまたは複製するために使用できreplication-rules-table
。
Binlogイベントフィルタリング
binlogイベントフィルタリングつの機能は、DMがソースデータベース内の特定のテーブルから特定のタイプのSQLステートメントをフィルタリングできることを意味します。たとえば、表test
のINSERT
のステートメントすべてをフィルタリングできます。 sbtest
または、スキーマtest
のTRUNCATE TABLE
のステートメントすべてをフィルタリングします。
スキーマとテーブルのルーティング
スキーマとテーブルのルーティングの機能は、DMがソースデータベースの特定のテーブルをダウンストリームの指定されたテーブルに移行できることを意味します。たとえば、テーブル構造とデータをテーブルtest
から移行できます。ソースデータベースのsbtest1
を表test
に追加します。 TiDBではsbtest2
。これは、シャーディングされたデータベースとテーブルをマージおよび移行するためのコア機能でもあります。
高度な機能
シャードのマージと移行
DMは、元のシャーディングされたインスタンスとテーブルをソースデータベースからTiDBにマージおよび移行することをサポートしていますが、いくつかの制限があります。詳細については、 ペシミスティックモードでのDDL使用制限のシャーディングおよびオプティミスティックモードでのDDL使用制限のシャーディングを参照してください。
移行プロセスにおけるサードパーティのオンラインスキーマ変更ツールの最適化
MySQLエコシステムでは、gh-ostやpt-oscなどのツールが広く使用されています。 DMは、これらのツールをサポートして、不要な中間データの移行を回避します。詳しくはオンラインDDLツールをご覧ください
SQL式を使用して特定の行の変更をフィルタリングする
インクリメンタルレプリケーションのフェーズでは、DMはSQL式の構成をサポートして、特定の行の変更を除外します。これにより、データをより詳細にレプリケートできます。詳細については、 SQL式を使用して特定の行の変更をフィルタリングするを参照してください。
使用制限
DMツールを使用する前に、次の制限に注意してください。
データベースのバージョン要件
MySQLバージョン>5.5
MariaDBバージョン>=10.1.2
ノート:
アップストリームのMySQL/MariaDBサーバー間にプライマリ-セカンダリ移行構造がある場合は、次のバージョンを選択します。
- MySQLバージョン>5.7.1
- MariaDBバージョン>=10.1.3
DDL構文の互換性
現在、TiDBはMySQLがサポートするすべてのDDLステートメントと互換性があるわけではありません。 DMはTiDBパーサーを使用してDDLステートメントを処理するため、TiDBパーサーでサポートされているDDL構文のみをサポートします。詳細については、 MySQLの互換性を参照してください。
DMは、互換性のないDDLステートメントを検出すると、エラーを報告します。このエラーを解決するには、このDDLステートメントをスキップするか、指定されたDDLステートメントに置き換えることにより、dmctlを使用して手動で処理する必要があります。詳細については、 異常なSQLステートメントをスキップまたは置換しますを参照してください。
シャーディングは競合とマージします
シャーディングされたテーブル間に競合が存在する場合は、 自動インクリメント主キーの競合の処理を参照して競合を解決します。それ以外の場合、データ移行はサポートされていません。競合するデータは互いにカバーし合い、データの損失を引き起こす可能性があります。
その他のシャーディングDDL移行の制限については、 ペシミスティックモードでのDDL使用制限のシャーディングおよびオプティミスティックモードでのDDL使用制限のシャーディングを参照してください。
データソースのMySQLインスタンスの切り替え
DM-workerが仮想IP(VIP)を介してアップストリームMySQLインスタンスに接続する場合、VIP接続を別のMySQLインスタンスに切り替えると、DMは異なる接続で同時に新しいMySQLインスタンスと古いMySQLインスタンスに接続する可能性があります。この状況では、DMに移行されたbinlogは、DMが受け取る他のアップストリームステータスと一致しないため、予測できない異常やデータの損傷が発生します。 DMに必要な変更を手動で行うには、 仮想IPを介したDM-worker接続の切り替えを参照してください。
GBK文字セットの互換性
- DMは、v5.4.0より前のTiDBクラスターへの
charset=GBK
のテーブルの移行をサポートしていません。
- DMは、v5.4.0より前のTiDBクラスターへの