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

これまでのウェビナースケジュール https://pingcap.co.jp/event/ 
 
 2023年6月15日(木) 14:00 - 15:00 【TiDB Serverless GA直前】TiDB新章。Serverless + Data API + AIによる新 たな活用 2023年7月27日(木) 14:00-15:00 TiDB Cloud最新状況の紹介 2023年9月14日(木) 14:00-15:00 TiDBとMySQLの互換性改善アップデート 2023年11月1日(木) 14:00-15:00 TiDB Operatorの紹介 2023年12月21日(木) 14:00-15:00 TiDB 7.4：MySQL 8.0互換性対応の紹介 2024年1月25日(木) 14:00-15:00 TiDB 7.5 LTS新機能の紹介 2024年2月29日(木) 14:00 - 15:00 TiDB Cloud APIとTerraform TiDB Cloud Providerの紹介 2024年3月28日(木) 14:00 - 15:00 TiProxyの紹介 2024年5月30日(木) 14:00 - 15:00 TiDB 8.0 DMR新機能の紹介 ※過去開催アーカイブ：https://pingcap.co.jp/event-video/

次回以降のウェビナースケジュール https://pingcap.co.jp/event/ 
 
 2024年7月予定 現在未定

おことわり ● 本ウェビナー募集開始後、 TiDB 8.1 LTSが2024年5月24日にリリースされました ○ ウェビナーの内容を TiDB 8.1 LTSの紹介に変更いたします ○ すべての TiDB 8.0 DMRの機能はTiDB 8.1 LTSに含まれます

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

TiDB LTS、DMRとは何か

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

TiDB 8.1 LTS新機能の紹介

● 2024年5月24日にリリース ● TiDB 7.5.0(2023年12月1日にリリース)以来、約6ヶ月ぶりのLTSバージョン ● https://docs.pingcap.com/tidb/stable/release-8.1.0 TiDB 8.1.0 LTS

● これらのExperimentalな機能がGA(General Availability)になりました ● 分散実行フレームワーク (Distributed eXecution Framework) ○ “TiDB 7.5 LTS新機能の紹介” ○ https://speakerdeck.com/pingcap0315/tidb-7-dot-5-ltsxin-ji-neng-noshao-jie ● グローバルソート ○ “TiDB 7.5 LTS新機能の紹介” ○ https://speakerdeck.com/pingcap0315/tidb-7-dot-5-ltsxin-ji-neng-noshao-jie GAとなった機能 (1)

● これらのExperimentalな機能がGA(General Availability)になりました ● TiProxy ○ “TiProxyの紹介” ○ https://speakerdeck.com/pingcap0315/tiproxynoshao-jie ● リソースコントロールの Runaway(暴走)クエリー対応 ○ “TiDB 7.5 LTS新機能の紹介” ○ https://speakerdeck.com/pingcap0315/tidb-7-dot-5-ltsxin-ji-neng-noshao-jie ● BRのスナップショットからのリストアの高速化 ○ リストアタスクを複数のタスクに分解して、各タスクを TiKVサーバーに割り当てる ○ --granularity="coarse-grained" ○ BR 7.5 以前で100MiB / sから、約1.2 GiB/秒と約10倍 GAとなった機能 (2)

● TiKVでのRaftstoreのスレッドプールのデフォルト値が 0から1に変更されました ● raftstore.store-io-pool-size ○ TiDB(TiKV) 8.0より前のバージョンのデフォルト値 : 0 ■ すべての書き込みは Raftstoreスレッド自身にて行われる ○ TiDB(TiKV) 8.0以降のデフォルト値 : 1 ■ メッセージのやりとりは Rafstoreスレッド自身、logの書き込みがStoreWriterス レッドにて行われる ● スレッドプールデフォルト値変更による効果 ○ 書き込み中心のシナリオで 20%の書き込み性能向上 ○ 非同期IOによりCPU負荷は3-5%増加 ● TiDB(TiKV)アップグレード時 ○ デフォルト値は0から1に変更されます Raftstoreスレッドプールのデフォルト値が変更

● Titanとは ○ RocksDBのプラグイン ○ KeyとValueを分割して保存(長いValueをBlobに保存) ● トレードオフ ○ 列の長いテーブル(JSONなど)での読み書きでRocksDB単体より優れる ○ ディスク容量、範囲クエリに関しては RocksDBに比べて劣る ● min-blob-size ○ この値より長い列が Titanに保存されるしきい値 ○ TiDB 7.6.0 DMRより前 : 1KiB ○ TiDB 7.6.0 DMR以降 : 32KiB ● アップグレードの際にこの値は変更されません Titanがデフォルトで有効

● PD (Placement Driver)とは ○ PDは3台構成で、1つのリーダー(leader)と2つのフォロワー(follower) ○ TiKV、TiDBとことなり、PDはスケールアウトできない ○ TiDBサーバー、TiKVのリージョン数が多い環境 ■ 多くのTiDBサーバーからの問い合わせにより PDのCPU負荷が高まる ● Active PD Follower ○ TiDBサーバーから、リージョン情報のリクエストを「すべて」の PDに対して取得を行う ○ PDはつねにリージョン情報をリーダーとフォロワー間で同期している ○ PDリーダーのCPU負荷の削減を目的 ● PDのフォロワーへのネットワーク経由のアクセスが遅い場合 ○ フォロワーをunavailableとマークして、フォロワーに問い合わせを行いません ○ 遅延があった場合、 TiDBは最新の情報をPDリーダーに再度リクエストします Active PD Follower (experimental)

● Active PD Followerの設定 ○ pd_enable_follower_handle_region ■ デフォルトは`OFF`(無効) mysql> select @@global.pd_enable_follower_handle_region; +-------------------------------------------+ | @@global.pd_enable_follower_handle_region | +-------------------------------------------+ | 0 | +-------------------------------------------+ 1 row in set (0.00 sec) mysql> set global pd_enable_follower_handle_region = on; Query OK, 0 rows affected (0.03 sec) mysql> select @@global.pd_enable_follower_handle_region; +-------------------------------------------+ | @@global.pd_enable_follower_handle_region | +-------------------------------------------+ | 1 | +-------------------------------------------+ Active PD Follower (experimental)

● TiDBのトランザクション ○ コミット/ロールバックされるまで TiDBサーバーのメモリ内に保持される ○ 多数のトランザクションの一つ一つは少数のデータを更新する場合に有効 ○ トランザクションサイズが大きい場合には、対応できない場合があった ● 以前のTiDBでの対応方法 ○ Non-transaction DML ( BATCH ON id LIMIT 2 DELETE FROM …) ○ 構文が標準的なSQLではなかった ○ 分割されたトランザクション全体の整合性が担保されない可能性があった ● 少数のトランザクションが大きなデータを更新する場合に適した設定 ○ Bulk DMLの導入 ○ トランザクションの途中の状態を TiKVに書き込む Bulk DML (experimental)

● Bulk DMLの設定 ○ tidb_dml_type ■ デフォルトは`STANDARD` ■ 多数のトランザクションは小さなデータを更新する ■ トランザクションのコンフリクトが発生しうる場合に適した設定 mysql> select @@session.tidb_dml_type; +-------------------------+ | @@session.tidb_dml_type | +-------------------------+ | STANDARD | +-------------------------+ 1 row in set (0.00 sec) mysql> set session tidb_dml_type = 'bulk'; Query OK, 0 rows affected (0.00 sec) mysql> select @@session.tidb_dml_type; +-------------------------+ | @@session.tidb_dml_type | +-------------------------+ | bulk | +-------------------------+ ○ BULK ■ 少数のトランザクションが大きなデータを更新する場合 ■ トランザクション間のコンフリクトが発生しない場合に ■ INSERT, UPDATE, REPLACE, DELETE文のみこの変更の影響を受ける Bulk DML (experimental)

● 現時点での制限事項 ○ Auto commitが有効なトランザクションのみに有効です ○ メタデータロック(MDL)が有効である必要があります ○ standardモードにフォールバックする場合があります ■ foreign keyが作成されたテーブル、 foreign keyの参照先になるテーブル ○ TTL ■ max-txn-ttl または 24時間の大きい方に変更されます ○ GC ■ tidb_gc_max_wait_time (デフォルト値: 86400秒/1日)より長いトランザクションは強制的に ロールバックされます Bulk DML (experimental)

● create tableが多数実行されるシナリオ ○ マルチテナント環境などで、多数 (万から数十万)のテーブルを作成する ● TiDBにおけるDDLの実行 ○ DDLはjobとして実行される ○ 多くのDDLは複数のステータス変更を伴う ● CREATE TABLE ○ noneとpublicの2つのみ ○ DDL jobの実行プロセスを簡略化しました ○ DDL をDDL ownerのTiDBサーバーで実行するのではなく、 DDLを受け取ったTiDBサーバーが直 接DDLを実行します テーブル作成の高速化 (experimental)

● テーブル作成の高速化の設定 ○ tidb_enable_fast_create_table ■ デフォルトは`OFF`(無効) mysql> select @@global.tidb_enable_fast_create_table; +----------------------------------------+ | @@global.tidb_enable_fast_create_table | +----------------------------------------+ | 0 | +----------------------------------------+ 1 row in set (0.00 sec) mysql> set global tidb_enable_fast_create_table = on; Query OK, 0 rows affected (0.07 sec) mysql> select @@global.tidb_enable_fast_create_table; +----------------------------------------+ | @@global.tidb_enable_fast_create_table | +----------------------------------------+ | 1 | +----------------------------------------+ ● Note ○ TiDB 7.6 DMR以前は、tidb_ddl_versionというシステム変数で制御されていました ○ TiDB 8.0以降は、tidb_ddl_versionは無効となります mysql> select @@global.tidb_ddl_version; ERROR 1193 (HY000): Unknown system variable 'tidb_ddl_version' テーブル作成の高速化 (experimental)

● 制限事項 ○ TiCDCは、tidb_enable_fast_create_tableを有効にしたテーブルをレプリケートできませ ん ○ テーブル作成の高速化は、 foreign key(外部キー)のないcreate tableのみ有効です テーブル作成の高速化 (experimental)

● カラムのデフォルト値に、定数だけでなくいくつかの関数が利用可能になりました ● 例: mysql> CREATE TABLE t1 ( -> d DATE DEFAULT (DATE_FORMAT(NOW(), '%Y-%m-%d') ) -> ); Query OK, 0 rows affected (0.11 sec) mysql> insert into t1 values(); Query OK, 1 row affected (0.00 sec) mysql> select * from t1; +------------+ | d | +------------+ | 2024-05-29 | +------------+ 1 row in set (0.00 sec) mysql> 関数をカラムのデフォルト値 (experimental)

● テーブルの数が多い (例: 100万以上)場合 ○ スキーマ情報(テーブル定義)の取得がボトルネックとなる場合がありました ● LRU (Least Recently Used)を用いたスキーマ情報を TiDBサーバーにキャッシュ可能になりました ○ 頻繁にアクセスされるテーブルのメタデータを優先的にキャッシュに保存します ○ テーブル数が多いシナリオではメモリ使用量を削減可能です スキーマ情報キャッシュの最適化 (experimental)

● テーブル作成の高速化の設定 ○ tidb_schema_cache_size ■ デフォルトは`0`(無効) ■ 1GB(1073741824 byte)に設定する例 mysql> select @@global.tidb_schema_cache_size; +---------------------------------+ | @@global.tidb_schema_cache_size | +---------------------------------+ | 0 | +---------------------------------+ 1 row in set (0.01 sec) mysql> set global tidb_schema_cache_size = 1073741824; Query OK, 0 rows affected (0.03 sec) mysql> select @@global.tidb_schema_cache_size; +---------------------------------+ | @@global.tidb_schema_cache_size | +---------------------------------+ | 1073741824 | +---------------------------------+ 1 row in set (0.00 sec) ● 設定可能な範囲 ○ 単位は Byte ○ [0, 9223372036854775807] (最大は8 エクサバイトですが、TiDBサーバーのメモリサイズを超えて設定しないように してください) スキーマ情報キャッシュの最適化 (experimental)

● 自動アナライズ(auto analyze) ○ バックグラウンドタスクとして実行 ● テーブルが作成され、その直後に大量のデータが追加される ○ 自動アナライズが間に合わず、古い統計情報のまま SQLの実行計画が作成される ○ 回避策は明示的に手動でのアナライズを行う ● 自動アナライズの優先キュー設定 ○ tidb_auto_analyze_priority_queue ■ デフォルトは`ON`(有効) mysql> select @@global.tidb_enable_auto_analyze_priority_queue; +--------------------------------------------------+ | @@global.tidb_enable_auto_analyze_priority_queue | +--------------------------------------------------+ | 1 | +--------------------------------------------------+ ● スコアの低い(最後に統計情報が取得されてから多くの変更がされている )テーブルを優先的に analyzeし ます 自動アナライズの優先キューでの実行

● バックグラウンドタスクとして実行 ● テーブルが作成され、その直後に大量のデータが追加される ○ 自動アナライズが間に合わず、古い統計情報のまま SQLの実行計画が作成される ○ 回避策は明示的に手動でのアナライズを行う ● 自動アナライズ ○ tidb_auto_analyze_priority_queue ■ デフォルトは`ON`(有効) mysql> select @@global.tidb_enable_auto_analyze_priority_queue; +--------------------------------------------------+ | @@global.tidb_enable_auto_analyze_priority_queue | +--------------------------------------------------+ | 1 | +--------------------------------------------------+ ● スコアの低い(最後に統計情報が取得されてから多くの変更がされている )テーブルを優先的に analyzeし ます 自動アナライズの優先キューでの実行

● インデックス使用状況のモニタリングが可能になりました ● 利用できるテーブル、ビュー ○ information_schema.tidb_index_usage ■ INDEX_NAME : インデックス名 ■ QUERY_TOTAL : このインデックスを利用した SQLの数 ■ KV_REQ_TOTAL : このインデックスにアクセスするときの TiKVへのリクエスト数 ■ LAST_ACCESS_TIME : このインデックスが最後に利用された時刻 ○ information_schema.cluster_tidb_index_usage ■ INSTANCE : TiDBサーバー ○ sys.schema_unused_index ■ TiDBサーバーで利用されていないインデックスを表示するビュー ■ TiDBにsysスキーマが導入されました インデックス使用状況のモニタリング

● sys.schema_unused_index ○ TiDBサーバーが再起動されてから、利用されていないインデックスを表示します ○ INFORMATION_SCHEMA.CLUSTER_TIDB_INDEX_USAGEテーブルを元にしたビュー ■ sys, mysql,INFORMATION_SCHEMAを除く ■ プライマリーキーを除く ○ 列 ■ object_schema : インデックスが存在するスキーマ ■ object_name : インデックスが張られたテーブル名 ■ index_name : インデックス名 ● 制限事項 ○ インデックスの使用状況は 5分程度遅れて反映されます ○ TiDBサーバーを再起動するとこれらの情報はクリアされます インデックス使用状況のモニタリング

● TiDB 6.4でAUTO_ID_CACHE = 1 ○ ”TiDB 6.5 LTS新機能紹介” ○ https://speakerdeck.com/pingcap0315/tidb-6-dot-5-ltsxin-ji-neng-noshao-jie ● TiDBサーバー再起動時 ○ forceRebaseと呼ばれる処理を実施し、できるだけ TiDBサーバー再起動前後での auto_increment のギャップを少なくする処理を実施していました ○ AUTO_ID_CACHE = 1のテーブルが多数の場合、 forceRebase処理の数が増え、TiDBサーバー の再起動が長期化するようになりました ● TiDB 8.1からはこのforceRebase処理を行わないようになりました ○ TiDBサーバー再起動時に auto_incrementのギャップの値が大きくなります ● https://docs.pingcap.com/tidb/stable/release-8.1.0/#behavior-changes AUTO_ID_CACHE=1の動作変更

● 定期的なfull compaction (experimental) ○ full compactionを行う時間帯を設定可能になりました ■ デフォルト : 制限なし ○ full compactionをTiKVサーバーのCPU使用率に基づいて実施可能になりました ■ デフォルト : 10%より低い場合のみ実施する ● Cross database binding ○ 複数データベース(schema)共通のbinding(SQLの実行計画を固定)が作成可能になりました ○ tidb_opt_enable_fuzzy_binding デフォルトは無効 ● Plan cacheの改善 ○ パーティション表、Generated column(仮想列)に対応 ● LOAD DATA が明示的なトランザクションに対応しました ● TLS 1.0とTLS 1.1の対応が終了しました ○ TLS 1.2またはTLS 1.3をご利用ください その他の新機能

● Data Migration (DM)が MySQL 8.0からのデータ移行に正式に対応しました ● Debezium プロトコルに対応しました ○ https://docs.pingcap.com/tidb/stable/ticdc-debezium/ ● Simple protocol に対応しました ○ https://docs.pingcap.com/tidb/stable/ticdc-simple-protocol/ Data Migration(DM) / TiCDC関連の変更

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

● Dedicated Tierの場合 ○ 各LTSバージョンまたはメンテナンスバージョンリリース後、デフォルトの TiDBバージョンが更新され ます ○ 2024年5月28日現在、TiDB Dedicatedでのデフォルトバージョンは TiDB 7.5.1です ○ TiDB 8.1.0は個別のクラスタで利用可能です ○ デフォルトバージョンが更新され次第お知らせします ● Serverless Tierの場合 ○ 現在ご利用いただけるバージョンは TiDB 7.1となり、TiDB 8.1は現在Serverless Tierではご利用い ただけません TiDB 8.1をTiDB Cloudで利用する方法

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