PingCAP Education： TiCDC、Dumpling、Lightningの紹介 藤嶋 茂行 Technical support engineer at PingCAP Japan

本日の位置づけ ● https://pingcap.co.jp/event/ ● https://pingcap.co.jp/category/webinar/ 
 
 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：インデックスに基づいたチューニング 2023年1月20日(金) 14:00-15:00 PingCAP Education：TiCDC、Dumpling、Lightningの紹介 2023年2月3日(金) 14:00-15:00 TiDB 6.5 LTS新機能の紹介 2023年2月17日(金) 14:00-15:00 PingCAP Education：TiDB CloudのIntegration機能の紹介 - Datadog、 Prometheus、Vercelとの統合 ※過去開催アーカイブ　：　https://pingcap.co.jp/event-video/

アジェンダ ● TiDBにおけるデータ移行ツールのご紹介 ● Dumpling、Lightningの紹介 ● TiCDCの紹介 ● TiCDCを利用したTiDBクラスタのDR環境構築例

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 2022/12/9にウェビナー実施 https://youtu.be/NHNrD9jSH0E

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 本日のターゲット

Dumpling、Lightningの紹介

Dumplingの特長 ● TiDBやMySQLのデータをSQLまたはCSV形式で出力するCLIツール ● 完全バックアップデータを出力する ○ バックアップ用途での差分データ取得であれば BRを、システム間連携のための差分データ取得 はTiCDCを使うと良い ○ 出力形式がSQLの場合、テーブルスキーマ情報も出力対象に含まれる ● mydumper（をforkしたもの）をTiDB向けに最適化しており、細かなチューニングや フィルタリングの調整が可能となっている https://docs.pingcap.com/tidb/stable/dumpling-overview

Dumplingの利用 - コマンド実行例 tiup dumpling -u root -P 4000 -h 127.0.0.1 -p${MYSQL_PWD} \ --filetype sql -t 8 -o /data/export -r 200000 -F 256MiB
 ● dumplingコマンドのインストールは tiup install dumpling で行う ● DBへの接続はmysqlコマンドと同様のオプションを用いて行う ● オプションでは同時実行スレッド数（-tオプション）、1ファイルあたりの最大行数（-rオプ ション）や上限ファイルサイズ（-Fオプション）などを指定することが可能 ● 出力するファイルの圧縮（gzip, snappy, zstd）やAmazon S3への出力も可能 ● 出力対象となるデータベースやテーブルの絞り込み、データに対する条件式の設定も 可能 https://docs.pingcap.com/tidb/stable/dumpling-overview

Dumplingの利用 - データ出力例(SQL形式の場合) $ ls -lah /data/export ... -rw-rw-r-- 1 ec2-user ec2-user 146 12月 20 04:47 metadata -rw-rw-r-- 1 ec2-user ec2-user 95 12月 20 04:47 test-schema-create.sql -rw-rw-r-- 1 ec2-user ec2-user 175 12月 20 04:47 test.t-schema.sql -rw-rw-r-- 1 ec2-user ec2-user 112 12月 20 04:47 test.t.0000000010000.sql ... ● metadata: 出力の開始と終了日時、binlogポジションの記録 ● ${db}-schema-create.sql: 出力したデータベースのCREATE DATABASE文 ● ${db}.${table}-schema.sql: 出力したテーブルのCREATE TABLE文 ● ${db}.${table}.0000000010000.sql: 出力したデータを追加するINSERT文 https://docs.pingcap.com/tidb/stable/dumpling-overview

出力データのフィルタリング 2種類のフィルタリングオプションが利用可能 ● “--where” : SQLのwhere句の式でデータの絞り込みを行う ● “--filter”: 対象のデータベースやテーブルを絞り込む https://docs.pingcap.com/tidb/stable/dumpling-overview

出力データのフィルタリング 2種類のフィルタリングオプションが利用可能 ● “--where” : SQLのwhere句の式でデータの絞り込みを行う ○ --where "id < 10" のようにしてフィルタリング条件を設定する ○ 条件を満たさない場合は出力対象とならない ■ 指定したカラムが無いテーブルがあると処理がエラーとなるため、 ”--filter” も併用して該当す るカラムがあるテーブルのみを含むようにすると良い ● “--filter”: 対象のデータベースやテーブルを絞り込む https://docs.pingcap.com/tidb/stable/dumpling-overview

出力データのフィルタリング 2種類のフィルタリングオプションが利用可能 ● “--where” : SQLのwhere句の式でデータの絞り込みを行う ● “--filter”: 対象のデータベースやテーブルを絞り込む ○ ワイルドカード（”*”）や文字の範囲指定（ [0-9], [a-z]など）などを利用したパターンマッチングによる絞り 込みが可能 ■ 例1: employees.*: “employees”データベース内のテーブル全て ■ 例2: *.users: 全てのデータベース内にある ”users”テーブル ○ Go言語で利用可能な正規表現での絞り込みも可能 https://docs.pingcap.com/tidb/stable/dumpling-overview

出力データにおける一貫性 ● データの一貫性の保証をオプションで調整可能 ○ 通常のユースケースではデフォルトのままでも問題ないが、一部のクラウドプロバイダーの DBサービ スでは調整が必要となる場合がある ● flush ● snapshot ● lock ● none ● auto https://docs.pingcap.com/tidb/stable/dumpling-overview

出力データにおける一貫性 ● データの一貫性の保証をオプションで調整可能 ○ 通常のユースケースではデフォルトのままでも問題ないが、一部のクラウドプロバイダーの DBサービ スでは調整が必要となる場合がある ● flush ○ MySQLまたはMariaDBが対象の場合のデフォルト設定 ■ TiDBに対しては利用できない ○ FLUSH TABLES WITH READ LOCKを実行してデータを出力する ● snapshot ● lock ● none ● auto https://docs.pingcap.com/tidb/stable/dumpling-overview

出力データにおける一貫性 ● データの一貫性の保証をオプションで調整可能 ○ 通常のユースケースではデフォルトのままでも問題ないが、一部のクラウドプロバイダーの DBサービ スでは調整が必要となる場合がある ● flush ● snapshot ○ TiDBが対象の場合に利用可能であり、 TiDB向けのデフォルトオプション ○ TSO(Timestamp Oracle)または日時を指定し、該当するスナップショットデータを出力する ○ TiDBでは、SHOW MASTER STATUSのPositionにTSOが表示されている ● lock ● none ● auto https://docs.pingcap.com/tidb/stable/dumpling-overview

出力データにおける一貫性 ● データの一貫性の保証をオプションで調整可能 ○ 通常のユースケースではデフォルトのままでも問題ないが、一部のクラウドプロバイダーの DBサービ スでは調整が必要となる場合がある ● flush ● snapshot ● lock ○ 出力対象のテーブルに READ LOCKをかける ○ MySQLとTiDBのどちらに対しても使うことはできるが、 TiDBの場合はデフォルト設定では TABLE LOCK が利用できないため、 enable-table-lockをtrueに設定する必要がある ● none ● auto https://docs.pingcap.com/tidb/stable/dumpling-overview

出力データにおける一貫性 ● データの一貫性の保証をオプションで調整可能 ○ 通常のユースケースではデフォルトのままでも問題ないが、一部のクラウドプロバイダーの DBサービ スでは調整が必要となる場合がある ● flush ● snapshot ● lock ● none ○ 一貫性を保証しない ○ テーブルにLOCKをかけず、過去のスナップショットではなく出力時点のデータとなる ● auto https://docs.pingcap.com/tidb/stable/dumpling-overview

出力データにおける一貫性 ● データの一貫性の保証をオプションで調整可能 ○ 通常のユースケースではデフォルトのままでも問題ないが、一部のクラウドプロバイダーの DBサービ スでは調整が必要となる場合がある ● flush ● snapshot ● lock ● none ● auto ○ 各データベースにおけるデフォルト設定となる。 ○ MySQLの場合はflushと同義 ○ TiDBの場合はsnapshotと同義 https://docs.pingcap.com/tidb/stable/dumpling-overview

TiDB Lightningの特長 ● TiDBにデータをインポートするためのCLIツール ● 以下のデータ形式をサポートしている ○ Dumplingで出力されたSQLファイル ○ CSVファイル ○ Amazon AuroraまたはApache Hiveから出力されたParquetファイル ● インポートの状況を記録している”checkpoint”を利用して中断したところから再開す ることが可能 ● パターンマッチングや正規表現を利用してインポート対象のテーブルを絞り込むこと が可能 ● ローカルまたはAmazon S3、Google Cloud Storageからデータをインポートすること が可能 https://docs.pingcap.com/tidb/stable/tidb-lightning-overview

https://docs.pingcap.com/tidb/stable/tidb-lightning-overview#tidb-lightning-architecture TiDB Lightningのアーキテクチャとmode ● Physical import mode ● Logical import mode

https://docs.pingcap.com/tidb/stable/tidb-lightning-overview#tidb-lightning-architecture TiDB Lightningのアーキテクチャとmode ● Physical import mode ○ 初期データ移行など、完全データのインポート に適したモード ○ データをkey-valueのペアに変換し、TiKVノード にデータをアップロード、ローカルから TiKVの APIを呼び出して直接データを TiKVにインポー トする ○ パラメータ “backend” に “local” と指定するこ とで利用可能となる ● Logical import mode

https://docs.pingcap.com/tidb/stable/tidb-lightning-overview#tidb-lightning-architecture TiDB Lightningのアーキテクチャとmode ● Physical import mode ● Logical import mode ○ 差分データの追加や稼働中の本番環境での 利用に適したモード ○ データをSQL形式に変換し、SQLを実行して データをインポートする。 ○ パラメータ “backend” に “tidb” と指定すること で利用可能となる

Import mode比較 Import mode Physical Import Mode Logical Import Mode 速度 速い (100~500 GiB/hour) 遅い (10~50 GiB/hour) リソース消費 多い 少ない ネットワーク帯域消費 多い 少ない インポート中のACID 特性 無し 有り 対象テーブル 空でなければならない データがあっても良い TiDBクラスタのバージョン >= 4.0.0 全て インポート中のTiDBクラスタの利用 限定的 可

https://docs.pingcap.com/tidb/stable/get-started-with-tidb-lightning TiDB Lightningの利用 - コマンド実行例 nohup tiup tidb-lightning -config tidb-lightning.toml \ > nohup.out &
 ● tidb-lightningコマンドのインストールは tiup install tidb-lightning で 行う ● 通常インポート処理は時間を要するため、”&”をつけてバックグラウンドで処理を 継続するように、また、意図しない中断を防ぐために実行コマンドに”nohup”を追 加することが推奨されている ● ログファイルの中で “tidb lightning exit” というメッセージが出ていれば処理が正 常に完了したことになる ● server-modeを利用してWebUIから処理を実行することも可能 ● PrometheusとGrafanaを利用してインポート処理を監視することが可能

https://docs.pingcap.com/tidb/stable/monitor-tidb-lightning TiDB Lightningの監視 ● TiDB LightningではPrometheusでメトリクスを収集し、Grafanaで可視化するこ とが可能となっている ● デフォルト設定ではインポートの速度、進捗状況、リソース消費量などを見るこ とができる

TiCDCの紹介

TiCDCの特長 ● TiKVからchangelogを取り出してTiDBの差分データを連携する ● 連携先にMySQL、Kafka、TiDB、ストレージサービスが選択できる ○ Kafkaやストレージサービスの場合、差分データがイベントとして配信される ■ “ストレージサービス”とは、Amazon S3、Azure Blog Storage、NFSのこと ■ ストレージサービスへの配信は v6.5時点ではexperimentalとなっている ● 複数ノードでクラスタ化できるため、SPoFが無く高可用性を持つ ● 複数のプロトコル（出力形式）に対応している ● オンプレミスだけでなく、TiDB Cloud上でも利用可能 https://docs.pingcap.com/tidb/stable/ticdc-overview

TiCDCのアーキテクチャ ● 複数のTiCDCノードでクラスタ化する ことが可能 ○ PDが持つetcdを通じて構成される ● TiKVから取得したchangelogをTiCDC 内部で整理して連携先システムへ配 信する ● 連携先システムを複数持つができ、 連携タスクは”changefeed”として管 理される ● Web APIでTiCDCクラスタを管理でき る https://docs.pingcap.com/tidb/stable/ticdc-overview

TiCDCがサポートするプロトコル 連携先がKafkaまたはストレージサービスの場合、以下の出力プロトコルを利用でき る ● Avro ● Canal-JSON ● CSV

TiCDCがサポートするプロトコル 連携先がKafkaまたはストレージサービスの場合、以下の出力プロトコルを利用でき る ● Avro ○ Confluent platformで採用されているデータシリアライズのフォーマットであり、 Apach Avroとい うOSSプロジェクトで仕様が定義されている ○ データ定義をJSON形式で保存できるため、管理や運用をしやすい ○ データ自体はバイナリ形式で保存されるため、コンパクトで効率的となる ○ 連携先がKafkaの場合に利用可能 ● Canal-JSON ● CSV https://docs.pingcap.com/tidb/stable/ticdc-avro-protocol

TiCDCがサポートするプロトコル 連携先がKafkaまたはストレージサービスの場合、以下の出力プロトコルを利用でき る ● Avro ● Canal-JSON ○ MySQLのbinlogベースでMySQLのデータレプリケーションを行う Alibaba CanalというOSSで用 いられているJSON形式のデータプロトコル ○ Kafkaとストレージサービスのどちらでも利用可能 ● CSV https://docs.pingcap.com/tidb/stable/ticdc-canal-json

TiCDCがサポートするプロトコル 連携先がKafkaまたはストレージサービスの場合、以下の出力プロトコルを利用でき る ● Avro ● Canal-JSON ● CSV ○ 実行されたDMLの操作内容と、変更データを１行にまとめた CSV形式データ ○ 連携先がストレージサービスの場合のみ利用可能 https://docs.pingcap.com/tidb/stable/ticdc-csv

TiCDCによる双方向レプリケーション ● v6.5.0から利用可能となっている ● ２つのTiDBクラスタ間でのデータ同期を行うことができ、マルチアクティブなTiDB クラスタを実現可能 ● ある時点におけるクラスタ間のデータが 整合している必要がある ● DDLのレプリケーションは行われない ● 3つ以上のクラスタでの利用も可能 ○ ただし、循環レプリケーションはサポートされていない ■ 例えば、 TiDB A -> TiDB B -> TiDB C -> TiDB A というレプリケーションはできない ■ 3つ以上のクラスタ間でデータを相互にレプリケートしたい場合は TiDB A <-> TiDB B、 TiDB B <-> TiDB C、TiDB C <-> TiDB Aというように個別にレプリケーションを設定する 必要がある https://docs.pingcap.com/tidb/stable/ticdc-bidirectional-replication

TiCDCを利用した TiDBクラスタのDR環境構築例

用語の確認 ● High Availability (HA) ○ システムやサービスが停止する頻度が少ないこと ● Disaster Recovery (DR) ○ 災害発生後に速やかにシステム復旧を行えるようにするための予防措置 ● Recovery Time Objective (RTO) ○ 目標復旧時間。問題発生後にシステムやサービスが復元されるべき時間 ● Recovery Point Objective (RPO) ○ 目標復旧時点。復元に利用する最新のバックアップが取得された時点 ● Fault Tolerance Target (FTT) ○ 障害を許容できる範囲

DRにおける3段階のステージ 1. Backup and restore 2. Active-passive DR 3. Multi-active DR https://www.pingcap.com/blog/disaster-recovery-for-databases-how-it-evolves-over-years/

Backup and restore ● 定期的にスナップショットデータを取得し、別リージョンにて保管、問題発生時に保管 しているリージョンでシステムを復元する ● 実装しやすく、サービスによっては最初から機能が提供されていることもある ● データ規模とRTOが比例しやすく、RPOが大きくなりやすい ● RTO、RPOともに数時間程度が見込まれる ● 厳密な可用性が求められていない場合に適している https://www.pingcap.com/blog/disaster-recovery-for-databases-how-it-evolves-over-years/

Active-passive DR ● 読み書きを行うプライマリDBと、そこから送られてくるRedo logを利用して同期を行 う１つまたはそれ以上のセカンダリDBで構成される ● “クラスター”の概念を取り込んでいるものの、一般的にプライマリDBは1台であるた め、運用上はモノリシックDBと言える ● フェールオーバーの仕組みを適切に構築することで、RTOは数分、RPOは数秒程 度にまで抑えることが可能 https://www.pingcap.com/blog/disaster-recovery-for-databases-how-it-evolves-over-years/

Multi-active DR with a traditional DB ● データを分割して読み書きできる複数DBに持たせる構成 ● 一部のDBがダウンしてもサービスの継続は可能 ● 代替となるレプリケーションされたシャードを持つことでDRを実現することが可能 ● 一定のスケーラビリティを持つことはできるものの、データ規模が大きくなるにつれ てパフォーマンスが劣化しやすく、運用コストが大きくなりやすい https://www.pingcap.com/blog/disaster-recovery-for-databases-how-it-evolves-over-years/

Multi-active DR with a distributed DB ● RaftやPaxosのようなアルゴリズムを用いたデータの分散配置を複数リージョンに 渡って行う ● コンポーネントも複数リージョンに分散させることで、書込み性能をあげつつ、FTT はリージョンレベルとすることができる ● （TiDBの場合）データは同期的にレプリケーションされるため、RPOはほぼゼロ、 RTOは1分か、それ未満にすることが可能 https://www.pingcap.com/blog/disaster-recovery-for-databases-how-it-evolves-over-years/ この図における各リージョンの役割は以下の通り ● Region1がプライマリ ● Region2はフェイルオーバーのためのセカンダリ ● Region3はプライマリまたはセカンダリがダウンしても 奇数を維持するため

Multi-active DR with TiDB + TiCDC ● TiCDCでデータを別リージョンのクラスタへリアルタイムで同期させる ● 複数リージョンの同時ダウンに備えることができるため、厳しい可用性要件に応える ことが可能 ● TiCDCにHA特性があるため、データ同期の仕組みがSPoFになることはない ● FTTは複数リージョンレベル、RPOは秒単位、RTOは分単位にすることが可能 https://www.pingcap.com/blog/disaster-recovery-for-databases-how-it-evolves-over-years/

Multi-active DR with TiDB + TiCDC ● TiDB Cloudでは数クリックでセカンダリのクラスタを作成することが可能 ● Changefeed > Create secondary cluster > クラスタ名、ポート番号、リージョンを選択 https://www.pingcap.com/blog/disaster-recovery-for-databases-how-it-evolves-over-years/

まとめ

まとめ ● TiDBエコシステムのデータ管理ツールを紹介しました ○ データ移行やバックアップ、リストアをサポートするツールが提供されています ● DumplingとTiDB Lightning、TiCDCを解説しました ● DBにおけるDR構成を段階別に紹介しました ● TiCDCを利用したTiDBクラスタのDR環境構築事例を紹介しました ○ TiDB Cloudでは簡単にセカンダリのクラスタを作成することができます

Q&A

PingCAP定期ウェビナー https://pingcap.co.jp/event/ ※過去開催アーカイブ　：　 https://pingcap.co.jp/event-video/

次回以降のアジェンダ https://pingcap.co.jp/event/ 
 
 2023年2月3日(金) 14:00-15:00 PingCAP Education：TiDB 6.5 LTS新機能の紹介 2023年2月17日(金) 14:00-15:00 PingCAP Education：TiDB CloudのIntegration機能の紹介 - Datadog、 Prometheus、Vercelとの統合

Thank You!
 https://www.pingcap.com/
 info@pingcap.com


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/