TiDB 6.5 LTS新機能の紹介
 本多康夫 Technical support engineer at PingCAP Japan

アジェンダ ● TiDBのLTS、DMRとは何か ● TiDB 6.5 LTS新機能の紹介 ● TiDB 6.5をTiDB Cloudで利用する方法 ● Q&A, アンケートのお願い ● お知らせ

TiDB LTS、DMRとは何か

● 新機能を頻繁にリリースするサイクルと、比較的安定したリリースするサイクルの両立を図る ● LTS - Long Term Supportの略 ○ 約6ヶ月間隔でリリースされます ○ 新機能が追加されます ○ 不具合の修正を含むパッチリリース (例: TiDB v6.1.3)も提供されます ● DMR - Development Milestone Releaseの略 ○ 約2ヶ月間隔でリリースされます ○ 新機能が追加されます ○ 不具合の修正を含むパッチリリース (例 v6.4.1)は提供されません ■ DMRで発生した不具合の修正は次の DMRまたはLTSに含まれます ■ DMRのパッチリリースバージョンは常に 0となります(v6.2.0, v6.3.0, v6.4.0) ● LTS、DMRはTiDB 6.0.0から導入されました ○ TiDB 5以前のバージョンは全て LTSと同等の扱いとなります TiDB LTS、DMRとは何か

● 2022年12月29日にリリース ● TiDB 6.1.0(2022年6月13日にリリース)以来、約6ヶ月ぶりのLTSバージョン ● https://docs.pingcap.com/tidb/dev/release-6.5.0 TiDB 6.5 LTS

TiDB 6.5 LTS新機能の紹介

● TiDB 6.1と比べて10倍のインデックス作成の高速化 ● グローバルに単調増加する AUTO_INCREMENT ● Flashback database/cluster ● TiDBサーバーレベルメモリコントロール ● その他の新機能の紹介 TiDB 6.5 LTS新機能の紹介

● 従来の対策: バッチサイズやワーカー数の変更 ○ tidb_ddl_reorg_batch_size デフォルト値 256行 ○ Tidb_ddl_reorg_worker_cnt デフォルト値 4ワーカー ● インデックス作成のうち主な処理 バックフィル処理 ○ テーブルから全てのレコードをスキャンして、インデックス用のキーと値のペアを作成し、 TiKVに書 き戻す処理 ● 従来の課題 ○ バックフィル処理を1行1行、2PCを経由して書き込みを行う必要があった ○ インデックス作成の書き込みトランザクションが、ユーザーが実行するトランザクションと衝突する可 能性があり、インデックス書き込みを再試行する必要があった ● 6.5での変更 ○ まず、バックフィル処理の開始時刻をスナップショットとして使用し、インデックスデータをまとめたフ ルコピーを一つ作成 ○ その後、フルコピー作成中にデータを変更したインデックスのデルタ部分をフルコピーする ○ TiDBサーバーにソート済みの結果を一時的に保存し、まとめて TiKVに書き込むようにした TiDB 6.1と比べて10倍のインデックス作成の高速化

● 測定結果例 ○ https://ossinsight.io/ での30億レコードのテーブルにインデックスを追加する処理 ○ 16.5時間から1.5時間へ短縮 ● 必要な設定変更 ○ `tidb_ddl_enable_fast_reorg` (システム変数) ■ インデックス作成の高速化を有効にするかどうかを指定する ■ デフォルト値: true ○ `tidb_ddl_disk_quota` (システム変数) ■ インデックス作成時の TiDBサーバーで利用可能なディスクサイズの上限 ■ デフォルト値: 107374182400 byte (100GiB) ○ `temp-dir` (configファイルで設定) ■ TiDBサーバーで、インデックス作成の高速化のために使われる一時領域 ■ デフォルト値: “/tmp/tidb” TiDB 6.1と比べて10倍のインデックス作成の高速化

● 制限事項 ○ PiTRのLog backup実行中は、インデックス作成の高速化が有効になりません ● 例 ○ Log Backupを先に開始し、その完了前にインデックス作成を開始した場合 ■ インデックス作成は高速化されません ■ 従来の方法でインデックスが作成されます ○ インデックス作成を先に開始し、その完了前に Log Backupを開始した場合 ■ Log Backup処理がエラーとなります ■ インデックス作成は高速化されます ○ インデックス作成とLog Backupを同時に開始した場合 ■ PiTRが新しく作成されたインデックスのバックアップに失敗する可能性があります ● https://docs.pingcap.com/tidb/stable/backup-and-restore-faq#why-is-the-acceleration-of-adding-inde xes-feature-incompatible-with-pitr も参照ください TiDB 6.1と比べて10倍のインデックス作成の高速化

● 従来の設定 ○ AUTO_INCREMENT は単一TiDBサーバー内で単調増加 ○ 各TiDBサーバーがAUTO_INCREMENTのキャッシュ(デフォルト30000) ○ 複数のTiDBサーバーをまたがる場合は、一意性は保たれるが、順序は保証されない ○ グローバルに単調増加させる回避策として、 AUTO_ID_CACHE 1各TiDBサーバーのキャッ シュを無効にする ■ 毎回TiKVからAUTO_INCREMENTの値を取得し直す ■ 性能劣化が著しい ● TiDB 6.5以降(厳密にはTiDB 6.4 DMR以降) ○ デフォルトの動作は従来通り ○ AUTO_ID_CACHE 1の内部的な動作が変更され、単一の TiDBサーバーがauto_incrementの中央 集権的な割り当てサービスとして値を発番し、各 TiDBサーバーは中央集権的な TiDBサーバーから 値を取得します グローバルに単調増加するAUTO_INCREMENT

● 課題 ○ AUTO_INCREMENTの値がグローバルに単調増加することを前提とするユーザーが多かった ○ 例: order by ○ レコードの作成時刻をテーブルに持たせ、 order by とするなどは技術的 には回避可能だが、アプリケーション変更を行う必要があった ○ AUTO_ID_CACHE 1では性能を満たすことができない場合が多かった (500 Insert QPS程 度) グローバルに単調増加するAUTO_INCREMENT

● TiDB 6.5以降(厳密にはTiDB 6.4 DMR以降) ○ デフォルトの動作は従来通り ○ AUTO_ID_CACHE 1の内部的な動作が変更され、単一の TiDBサーバーがauto_incrementの中央 集権的な割り当てサービスとして値を発番し、各 TiDBサーバーは中央集権的な TiDBサーバーから 値を取得します ○ 約40000 Insert QPS程度 ● Note ○ TiDB 6.3以前に`AUTO_ID_CACHE 1`で作成されたテーブルを TiDB 6.5にアップグレー ドした場合、従来通り TiKVから毎回値を取得する動作となります ○ `AUTO_ID_CACHE 1`からキャッシュの値の変更はできません (逆もできません) ○ TiDBのアーキテクチャを生かし、スループットを限界まで高めたい場合は引き続き、キャッシュされ たauto_incrementあるいはAUTO_RANDOMの利用を推奨します グローバルに単調増加するAUTO_INCREMENT

従来のauto_incrementの動き [ 1, 30000 ] TiDB cached [ 30001, 60000 ] TiDB cached TiKV 60000 Insert into t values (null, …) Insert into t values (null, …) Insert into t values (null, …) ID 1 2 30001 3 4 30002 … 各TiDBサーバーにキャッシュを持つ A Clustered Table

新しいauto_incrementの動き [ 1, 1000 ] TiDB owner ,cached TiDB TiKV 1001 Insert into t values (null, …) Insert into t values (null, …) Insert into t values (null, …) ID 1 2 3 4 5 6 … 単一TiDBサーバーがauto_incrementを発番する TiDB TiDB async req

● 従来の設定 ○ 「クエリ単位」でのメモリ上限が設定可能だった ○ システム変数`tidb_mem_quota_query` ○ デフォルト値: 1GiB ○ `tidb_mem_quota_query` には達しない複数クエリの合計メモリサイズの制限ができなかった ● TiDB 6.5以降 ○ 「TiDBサーバー単位」でのメモリ上限が設定可能となった ○ システム変数 tidb_server_memory_limit ■ デフォルト値: TiDBサーバーの物理メモリの 80% ■ 1から99%の範囲で指定可能 ■ 単位なしの数値の場合は Byte単位として認識されます ■ KB,MB,TBの単位を用いた絶対値指定が可能 ■ 0 と指定した場合、この機能は無効となります TiDBサーバーレベルメモリコントロール

● tidb_server_memory_limit の上限に達した場合 ○ そのTiDBサーバーで実行中のクエリから、もっとも大きなメモリを利用しているクエリをキャンセル ○ GoレベルでのGC(TiKVでのGCとは異なります)を実行し、メモリの回収を行います ○ キャンセルされるクエリーは、 tidb_server_memory_limit_sess_min_size (デフォルト値 は128MB) より大きいものが選ばれます ○ 同時にキャンセルされるクエリは 1つです ○ クエリーをキャンセルしても `tidb_server_memory_limit`を超える場合、次に大きなメモリを利用して いるクエリーがキャンセルされま ○ 以降 `tidb_server_memory_limit` を下回るまで繰り返し TiDBサーバーレベルメモリコントロール

● Flashbackとは ○ クラスター、データベース、テーブル状態を過去の時点に戻すこと ● Flashbackが有用なケース : 論理的なエラー ○ データを誤って更新して commitしてしまった ○ テーブルやデータベースを誤って DROPまたはTRUNCATEしてしまった ● 従来のFLASHBACK ○ @@tidb_snapshot 変数 : クエリー単位で時刻を指定した Flashback可能 ○ FLASHBACK TABLE テーブル単位のみ可能 ● TiDB 6.5でのFLASHBACK ○ FLASHBACK DATABASE データベース単位での Flashbackが可能 ○ FLASHBACK CLUSTER TO TIMESTAMP TiDBクラスタ単位での時刻を指定した Flashbackが可 能 Flashback database/cluster

● FLASHBACK TABLE コマンド例 (dropの場合) ○ DROP TABLE t ○ FLASHBACK TABLE t ● FLASHBACK TABLE コマンド例 (truncateの場合) ○ TRUNCATE TABLE t ○ FLASHBACK TABLE t to t1 (tのテーブル定義は存在するため別名に ) ● FLASHBACK DATABASE コマンド例 (同一名称または別名のどちらにも Flashback可能) ○ DROP DATABASE test ○ FLASHBACK DATABASE test ○ FLASHBACK DATABASE test to test1 ● Note: DROPまたはTRUNCATEされたデータベース、テーブルはその後変更されないため、 FLASHBACK TABLE/DATABASEに時刻を指定することはできません。常に DROPまたはTRUNCATE の直前に戻ります Flashback table/databaseコマンド例

● Flashback clusterでは、TiDBクラスター全体をどの時刻に戻るのかを指定する必要があります ○ SQL文でTiDBクラスターをDROPすることはできないため、誤操作により DROPされることはない ● FLASHBACK CLUSTER TO TIMESTAMP '2022-09-21 16:02:50'; Flashback cluster to timestamp コマンド例

● 必要な設定 ○ TiDBのFlashbackはTiKVが追記型のアーキテクチャであることを利用しています ○ GCで削除されていないレコードのみが回復可能です ○ tidb_gc_life_time GCを行った後に保持されるデータの期間 ■ デフォルト値: 10分 ○ tikv_gc_safe_point 以降の時刻にFlashback可能です ○ FLASHBACK CLUSTER TO TIMESTAMPでは、Flashback前と後の両方のデータが TiKVに格納さ れますので、十分なディスクサイズが必要です Flashback database/cluster

● PITR ○ フルバックアップとログバックアップの組み合わせ ○ 従来はTiDB Binlogでのみ可能だったが TiDB 5.0以降の新機能との組み合わせに制限があった ● 悲観ロックによるパフォーマンスの低下を抑制 ● JSON関数のTiFlashへのプッシュダウン ● Non transactional DMLによる大規模なトランザクションの分割 ● TTL(Time to Live)機能により、自動的に期限切れのレコードを削除可能に (experimental) ● TiCDCのスループット向上 ● コストモデルバージョン 2 ● メタデータロックの導入 https://pingcap.co.jp/announcing-tidb-6-5-lts-release-major-leap-into-2023-with-a-mature-enterprise-datab ase/ その他の新機能の紹介

TiDB 6.5をTiDB Cloudで利用する方法

● Serverless Tierの場合 ○ 各LTSまたはDMRバージョンリリース後、デフォルトの TiDBバージョンが更新されます ○ 現在はTiDB 6.4.0 DMRの後は、6.5.0をスキップし、6.6.0 DMRとなる予定です ● 例 ○ TiDB v6.4.0 DMR : 2022年11月17日 ○ TiDB Cloud Serverless Tierデフォルトバージョン変更日 : 2022年12月27日 ○ https://docs.pingcap.com/tidbcloud/release-notes-2022#december-27-2022 ○ アップグレードに関する問題があったため、 2023年1月4日に修正 ○ https://docs.pingcap.com/tidbcloud/tidb-cloud-release-notes#january-4-2023 ○ Upgrade the default TiDB version of all Serverless Tier clusters from v6.3.0 to v6.4.0. TiDB 6.5をTiDB Cloudで利用する方法

● Dedicated Tierの場合 ○ 各LTSバージョンまたはメンテナンスバージョンリリース後、デフォルトの TiDBバージョンが更新され ます ○ Dedicated TierではDMRリリースはデフォルトの TiDBバージョンに選択されません ● 例 : TiDB v6.5.0 LTS の場合 ○ TiDB v6.5.0リリース日 : 2022年12月29日 ○ Dedicated Tierデフォルトバージョン変更日 : 2023年1月17日 ■ TiDB Cloud Release Notes in 2023 | PingCAP Docs ■ Upgrade the default TiDB version of new Dedicated Tier clusters from v6.1.3 to v6.5.0. ● メンテナンスバージョン例 : TiDB v6.1.3 LTSの場合 ○ TiDB v6.1.3リリース日 : 2022年12月5日 ○ Dedicated Tierデフォルトバージョン変更日 : 2022年12月6日 ■ https://docs.pingcap.com/tidbcloud/release-notes-2022#december-6-2022 ■ Upgrade the default TiDB version of new Dedicated Tier clusters from v6.1.2 to v6.1.3. TiDB 6.5をTiDB Cloudで利用する方法

Q&A

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

これまでのウェビナースケジュール https://pingcap.co.jp/event/ 
 
 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との統合 2023年3月2日(木) 14:00-15:00 ハンズオン TiDB Cloud Serverless TierとChatGPTのSQL生成を試してみ よう! ※過去開催アーカイブ　：　https://pingcap.co.jp/event-video/

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