PingCAP Education：
 TiDB Data Migrationのご紹介
 〜基本操作から動作原理の理解まで
 藤嶋 茂行
 Technical support engineer at PingCAP Japan 


本日の位置づけ ● https://pingcap.co.jp/event/ ● https://pingcap.co.jp/category/webinar/ 
 
 2022年9月9日(金) 14:00-15:00 PingCAP Education：TiKV-トランザクション＆MVCC 2022年9月30日(金) 14:00-15:00 PingCAP Education：TiDBでのSQL実行の仕組み 2022年10月21日(金) 14:00-15:00 PingCAP Education：TiKV-データの整合性 2022年10月28日(金) 14:00-15:00 PingCAP Education：TiDB でのロック競合のトラブルシューティング 2022年11月25日(金) 14:00-15:00 PingCAP Education：TiDBでのスロークエリの特定と対応方法 2022年12月9日(金) 14:00-15:00 PingCAP Education：TiDB Data Migrationのご紹介 2022年12月22日(木) 14:00-15:00 PingCAP Education：TiDBでの索引設計 2023年1月13日(金) 14:00-15:00 PingCAP Education：インデックスに基づいたチューニング ※過去開催アーカイブ　：　https://pingcap.co.jp/event-video/

アジェンダ
 ● TiDBにおけるデータ移行ツールのご紹介
 ● TiDB Data Migrationのご紹介
 ● TiDB Data Migrationの基本操作
 ● DMLの処理を例にしたTiDB Data Migrationの動作原理について


TiDBにおけるデータ移行ツールのご紹介

TiDBが提供するデータ管理ツール群
 ● TiDB Data Migration (DM)
 ○ MySQL/MariaDBからTiDBへ完全データ移行および差分データ移行をサポー トする
 ● Dumpling
 ○ MySQLまたはTiDBからの完全なデータエクスポートをサポートする
 ● TiDB Lightning
 ○ 大規模データセットのTiDBへのインポートをサポートする
 ● TiCDC
 ○ TiKVから変更ログを取り出し、TiDBの増分データをレプリケートする
 https://docs.pingcap.com/tidb/stable/ecosystem-tool-user-guide#data-management-tools

TiDBが提供するデータ管理ツール群
 ● Backup & Restore (BR)
 ○ TiDBクラスタのデータを分散バックアップおよびリストアするコマンドライン ツール
 ● TiDB Binlog
 ○ TiDBクラスタのbinlogを収集し、ほぼリアルタイムのデータレプリケートとバック アップを提供する
 ● sync-diff-inspector
 ○ MySQLまたはTiDBのデータベースにあるデータを比較し、検出する
 https://docs.pingcap.com/tidb/stable/ecosystem-tool-user-guide#data-management-tools

各ツールの比較 Tool Scenario Source Target/Output Supported TiDB versions Kubernetes support TiDB Data Migration (DM) - MySQL/MariaDBからTiDBへ移 行する - 1TB以上のデータを扱う場合は Dumpling/Lightningの利用を検 討する - MySQL - MariaDB TiDBクラスタ 全バージョン Yes Dumpling MySQL/MariaDBからデータをエ クスポートする - MySQL - TiDBクラスタ SQL/CSVファイル 全バージョン No TiDB Lightning TiDBへデータをインポートする - Dumplingで出力したファイル - CSV ファイル - Amazon Aurora または Apache Hiveからエクスポートした Parquet ファ イル - v2.1またはそれ以上 Yes TiCDC TiDBの増分データをレプリケート する TiDBクラスタ - TiDBクラスタ - MySQL - Kafka - Confluent v4.0.6またはそれ以上 Yes

TiDBが提供するデータ管理ツール
 ● TiDB Data Migration (DM)
 ○ MySQL/MariaDBからTiDBへ完全データ移行および差分データ移行をサポー トする
 ● Dumpling
 ○ MySQLからTiDBへ完全なデータエクスポートをサポートする
 ● TiDB Lightning
 ○ 大規模データセットのTiDBへのインポートをサポートする
 ● TiCDC
 ○ TiKVから変更ログを取り出し、TiDBの増分データをレプリケートする
 https://docs.pingcap.com/tidb/stable/ecosystem-tool-user-guide#data-management-tools 本セッションのターゲット

TiDBが提供するデータ管理ツール
 ● TiDB Data Migration (DM)
 ○ MySQL/MariaDBからTiDBへ完全データ移行および差分データ移行をサポー トする
 ● Dumpling
 ○ MySQLからTiDBへ完全なデータエクスポートをサポートする
 ● TiDB Lightning
 ○ 大規模データセットのTiDBへのインポートをサポートする
 ● TiCDC
 ○ TiKVから変更ログを取り出し、TiDBの増分データをレプリケートする
 https://docs.pingcap.com/tidb/stable/ecosystem-tool-user-guide#data-management-tools 来年１月Webinar予定

TiDB Data Migrationのご紹介

TiDB Data Migrationの特長
 ● MySQL/MariaDBからTiDBへ完全データ移行および差分データ移行をサポート する
 ○ MySQL5.7のプロトコルと互換性がある
 ○ MySQL8.0とは実験的な互換性を持つ
 ● MySQL binlog内のDMLとDDLイベントをレプリケートする
 ○ 任意のフィルタを定義し、任意のイベントのみをレプリケートすることが可 能
 ● 複数ノードでクラスタを構成することが可能
 ○ ノード故障に対する高可用性を持つ
 https://docs.pingcap.com/tidb/stable/dm-overview

TiDB Data Migrationの特長
 移行元データベースに求める要件の例
 ● binlogが有効になっていること
 ● MySQL > 5.5 (8.0以降はexperimental feature扱い）
 ● MariaDB >= 10.1.2
 ● TiDBがサポートしている文字セットと照合順序であること
 ● 主キーまたはユニークキーがあること
 ● 実行ユーザーがレプリケーションに必要な権限を持っていること
 その他、詳細な要件は https://docs.pingcap.com/tidb/stable/dm-precheck をご参照くだ さい


https://docs.pingcap.com/tidb/stable/dm-arch TiDB Data Migrationのアーキテクチャ
 ● DM-master
 ○ データ移行タスクの管理とスケジューリン グをする
 ○ masterノードが複数ある場合は自前の etcdを用いてクラスタを構成する 
 ● DM-worker
 ○ データ移行タスクを実行する 
 ○ １つのソースDBに対して１つのworker ノードが割り当てられる 
 ○ masterノードから孤立するとタスクは自 動的に停止する
 ● dmctl
 ○ DMクラスタを操作するためのコマンドラ インツール


TiDB Data Migrationの基本操作

TiDB Data Migrationのワークフロー
 1. DMクラスタをデプロイする
 2. データソースをDMクラスタに追加する
 3. データ移行タスクを作成する
 4. タスクの進行状況を確認する
 5. (Optional) タスクを監視し、ログを確認する
 6. (Optional) データ移行タスクを停止する


TiDB Data Migrationのワークフロー
 1. DMクラスタをデプロイする
 a. インフラ構成を記述したファイルを作る 
 b. デプロイを実行する 
 tiup dm deploy ${name} ${version} ./topology.yaml \ -u ${ssh_user} [-p] [-i /home/root/.ssh/gcp_rsa]
 c. クラスタを起動する
 tiup dmctl start ${cluster-name} 2. データソースをDMクラスタに追加する
 3. データ移行タスクを作成する
 4. タスクの進行状況を確認する
 5. (Optional) タスクを監視し、ログを確認する
 6. (Optional) データ移行タスクを停止する
 topology.yamlの例

TiDB Data Migrationのワークフロー
 1. DMクラスタをデプロイする
 2. データソースをDMクラスタに追加する
 a. ソースDBへの接続情報を記述したファイルを作る 
 b. ソースDBの情報をクラスタに登録する 
 tiup dmctl --master-addr ${masternode_ip}:${port} \ operate-source create datasource.yaml 3. データ移行タスクを作成する
 4. タスクの進行状況を確認する
 5. (Optional) タスクを監視し、ログを確認する
 6. (Optional) データ移行タスクを停止する
 datasource.yamlの例

TiDB Data Migrationのワークフロー
 1. DMクラスタをデプロイする
 2. データソースをDMクラスタに追加する
 3. データ移行タスクを作成する
 a. タスク定義を記述した設定ファイルを作成する 
 b. タスクを開始する
 tiup dmctl --master-addr ${masternode_ip}:${port} \ start-task task.yaml
 4. タスクの進行状況を確認する
 5. (Optional) タスクを監視し、ログを確認する
 6. (Optional) データ移行タスクを停止する
 task.yamlの例

TiDB Data Migrationのワークフロー
 1. DMクラスタをデプロイする
 2. データソースをDMクラスタに追加する
 3. データ移行タスクを作成する
 4. タスクの進行状況を確認する
 a. tiup dmctl --master-addr ${masternode_ip}:${port} \ query-status ${task_name}
 5. (Optional) タスクを監視し、ログを確認する
 6. (Optional) データ移行タスクを停止する
 query-statusの出力例

1. DMクラスタをデプロイする
 2. データソースをDMクラスタに追加する
 3. データ移行タスクを作成する
 4. タスクの進行状況を確認する
 5. (Optional) タスクを監視し、ログを確認する
 a. Grafana: http://${server_ip}:3000 
 i. https://docs.pingcap.com/tidb/stable/monitor-a-d m-cluster
 b. masterノードおよびworkerノード内Logディレクトリ 
 6. (Optional) データ移行タスクを停止する
 TiDB Data Migrationのワークフロー
 Grafanaの表示例

TiDB Data Migrationのワークフロー
 1. DMクラスタをデプロイする
 2. データソースをDMクラスタに追加する
 3. データ移行タスクを作成する
 4. タスクの進行状況を確認する
 5. (Optional) タスクを監視し、ログを確認する
 6. (Optional) データ移行タスクを停止する
 a. tiup dmctl --master-addr ${masternode_ip}:${port} stop-task ${task_name}


DMLの処理を例にした TiDB Data Migrationの動作原理について

DMでのbinlogレプリケーションのワークフロー
 1. MySQL/MariaDBからbinlogまたはリレーログを読み取る
 2. binlogイベントを変換する
 a. イベントやSQLのフィルタリングなど
 3. DMLステートメントを最適化する
 a. 複数操作を１つにまとめるなど
 4. 移行先データベースへDMLを実行する
 5. binlogポジションまたはGTIDをチェックポイントとして定期的に保存する
 syncのフロー

DMLステートメントの最適化ロジック 1. Compactor
 2. Causality
 3. Merger


DMLステートメントの最適化ロジック 1. Compactor
 a. 一定期間内に１つの行に複数回の変更を検出した場合、同じ行（同じ 主キー）に対する操作を１つにまとめる 
 i. INSERT + UPDATE => INSERT ii. INSERT + DELETE => DELETE iii. UPDATE + UPDATE => UPDATE iv. UPDATE + DELETE => DELETE v. DELETE + INSERT => UPDATE b. syncer.global.compactパラメータをtrueにすると有効になる 2. Causality
 3. Merger


DMLステートメントの最適化ロジック 1. Compactor
 2. Causality
 a. Binlogイベントの競合状況に応じてグループ化し、競合しないbinlog イベントを並列実行する。 
 i. 例えば、A・B・Cという３つのイベントがあったとする。イベントBがAに依存する場合、AはB に先行しなければならない。よって、イベントAとBは同じグループになる。このグループを G1とする。イベントCはAとBとは無関係である場合、CはG1とは異なるグループとなる。こ れをG2とする。グループG1とG2は互いに無関係であるため、同時に実行することができ る。
 3. Merger


DMLステートメントの最適化ロジック 1. Compactor
 2. Casuality
 3. Merger
 a. 複数のbinlogイベントを１つのDMLステートメントにまとめる 
 i. INSERT tb(a,b) VALUES(1,1); + INSERT tb(a,b) VALUES(2,2); = INSERT tb(a,b) VALUES(1,1),(2,2); ii. UPDATE tb SET a=1, b=1 WHERE a=1; + UPDATE tb SET a=2, b=2 WHERE a=2; = INSERT tb(a,b) VALUES(1,1),(2,2) ON DUPLICATE UPDATE a=VALUES(a), b=VALUES(b) iii. DELETE tb WHERE a=1 + DELETE tb WHERE a=2 = DELETE tb WHERE (a) IN (1),(2); b. syncer.global.multiple-rowsパラメータをtrueにすると有効になる

DMLステートメントの生成ロジック ● 移行先データベースで実行されるDMLはスキーマトラッカー内のテーブル構造に従っ て生成される
 ○ スキーマトラッカーは移行元と移行先のテーブルスキーマを保持している 
 ● 完全レプリケーションと差分レプリケーション（task-modeがall）の場合、移行元のテー ブルスキーマをDMLの列に使用する
 ● 差分レプリケーションのみ（task-modeがincremental）の場合は移行先のテーブルス キーマを移行元テーブルスキーマとみなしてDMLの列に使用する
 ● binlogに記録された列の値をDMLの列の値に利用する
 ● 移行先テーブルスキーマの主キーとユニークキーをDMLのWHERE条件に利用する
 ○ 移行先テーブルに主キーもユニークキーも無い場合はbinlogに記録されている列の値をすべてWHERE 条件に追加する


DMLステートメントの生成ロジックの実行例 移行元で以下のUPDATE文を実行すると、 UPDATE t2 SET number = 1 WHERE number = 49; binlogには以下のように記録される ### UPDATE `test`.`t2` ### WHERE ### @1=2 /* LONG… ### @2='b1f742d6-7612-11ed-93c7-0242ac130002' /* VARSTRING… ### @3=49 /* INT meta=0 nullable=1 is_null=0 */ ### SET ### @1=2 /* LONGINT meta=0 nullable=0 is_null=0 */ ### @2='b1f742d6-7612-11ed-93c7-0242ac130002' /* VARSTRING… ### @3=1 /* INT … DMは移行元（であるとみなした）テーブルスキーマに従ってDML文に設定す る列を特定し、対応する値をbinlogから取得する。 移行元テーブル 移行先に主キーまたはユニークキーがある場合 移行先の主キーまたはユニークキーを利用する（ここでは移行元と同じ主キーとする）。 よって、DMが生成するDMLは以下のようになる。 UPDATE t2 SET id = 2, uuid = ‘b1f742d6-7612…’, number = 1 WHERE id = 2; 移行先に主キーもユニークキーも無い場合 binlogのWHERE文をそのまま利用する。 よって、DMが生成するDMLは以下のようになる。 UPDATE t2 SET id = 2, uuid = ‘b1f742d6-7612…’ number = 1 WHERE id = 2 AND uuid = 'b1f742d6-7612…' AND number = 49;

DMLステートメントの実行ロジック ● 生成されたDMLはDMワーカーにキャッシュされる
 ● 一定時間あるいはDMLが一定数キャッシュされると移行先に対してDMLがバッチ 実行される
 ● syncer.global.worker-countで同時実行スレッド数を指定できる
 ● syncer.global.batchでキャッシュするステートメント数を指定できる
 


セーフモードについて ● DMはat-least-onceであるため、タスクが中断した状況によってはセーフモードに 入り、データが複数回処理される（重複する）可能性がある
 ● セーフモードではDMLステートメントが以下のように書き換えられる
 ○ INSERT -> REPLACE ○ UPDATE -> DELETE + INSERT ● Syncerの処理ループの最後に移行元テーブルの最新のbinlogポジションが safemode_exit_point（セーフモードの終了点）として記録される
 ● セーフモードは以下のいずれかの条件を満たすと終了する
 ○ 最新のbinlogの開始位置がsafemode_exit_pointと同じか通過したとき 
 ○ チェックポイントが２回リフレッシュされたとき 
 ○ syncers.global.safe-mode-durationで設定された時間を経過したとき（v6.3以降） 
 https://docs.pingcap.com/tidb/v6.0/dm-glossary#safe-mode

セーフモードについて ● タスクがgracefulに中断した場合、チェックポイントはリフレッシュされ、セーフモー ドには入らないので重複処理は発生しない
 ● タスクがエラーで中断した場合、safemode_exit_pointとチェックポイントを比較し、 その結果に応じて動作が変わる
 ○ チェックポイントの位置が終了点と同じ であれば、タスクがgracefulに中断した場合と同じで、セー フモードには入らない 
 ○ チェックポイントの位置が終了点よりも早い 場合、チェックポイントと終了点の間のbinlogイベント は重複する可能性がある 
 ○ safemode_exit_pointに値がない 場合、DMはセーフモードの終了点を特定することができないた め、タスク再開時に、DMは2回のチェックポイントの間にデフォルトで1分間のセーフモードを有効 にする


まとめ

まとめ ● TiDBエコシステムのデータ管理ツールを紹介しました
 ○ データ移行やバックアップ、リストアをサポートするツールが提供されていま す
 ● DMの特長とアーキテクチャを紹介しました
 ○ MySQLとMariaDBからデータを移行することができます
 ○ DMにはMasterとWorkerがあり、それぞれを複数ノードで構成して高可用性を 実現することができます
 ● DMLを処理する際の動作原理を紹介しました
 ○ DMは移行元および移行先のテーブルスキーマを保持し、binlogの内容に基 づいてDMLを生成します
 ○ タスク中断後はセーフモードにより、少なくとも１度はデータが書き込まれるこ とを保証します


Q&A

Thank You!
 https://www.pingcap.com/
 [email protected]


Appendix
 ● TiDB Data Migration公式ドキュメント https://docs.pingcap.com/tidb/stable/dm-overview
 ● トポロジー設定ファイルのテンプレート https://github.com/pingcap/tiup/blob/master/embed/examples/dm/topology. example.yaml
 ● タスク設定ファイルのテンプレート https://docs.pingcap.com/tidb/stable/task-configuration-file-full#task-configu ration-file-template-advanced
 ● FAQ https://docs.pingcap.com/tidb/stable/dm-faq
 ● データ移行におけるTiDBのDMLの処理方法について https://pingcap.co.jp/how-tidb-processes-dml-in-data-migration/