Upgrade to Pro — share decks privately, control downloads, hide ads and more …

TiDB 6.5 LTS新機能の紹介

PingCAP-Japan
February 03, 2023

TiDB 6.5 LTS新機能の紹介

ウェビナー開催日:2023年2月3日

このスライドでは、2022年12月末にリリースされた分散型データベースTiDB 6.5の新機能を紹介します。

TiDB 6.5では、TiDB 6.1と比べて10倍のインデックス作成の高速化、MySQLとの互換性を高めたグローバルに単調増加するAUTO_INCREMENT、データベースクラスタ全体を過去の状態に戻すFLASHBACK CLUSTERなどの多くの新機能が追加されています。

TiDB 6.5は、TiDB 6.1に続くLTS (Long Term Support) リリースであり、TiDB 6.5で新たに追加された機能だけでなく、TiDB 6.2から6.4 DMRまでの新機能を全て含む、本番環境での利用を推奨するバージョンです。また、TiDBの新しいバージョンをTiDB Cloudで利用する方法についても説明します。

トピック:
・TiDB LTS、DMRとは何か (おさらい)
・TiDB 6.5新機能の紹介
・TiDB 6.5をTiDB Cloudで利用する方法

アーカイブ動画:
https://www.youtube.com/watch?v=k5LqW05uWaw

PingCAP-Japan

February 03, 2023
Tweet

More Decks by PingCAP-Japan

Other Decks in Technology

Transcript

  1. TiDB 6.5 LTS新機能の紹介

    本多康夫
    Technical support engineer at PingCAP Japan

    View Slide

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

    View Slide

  3. TiDB LTS、DMRとは何か

    View Slide

  4. ● 新機能を頻繁にリリースするサイクルと、比較的安定したリリースするサイクルの両立を図る
    ● 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とは何か

    View Slide

  5. ● 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

    View Slide

  6. TiDB 6.5 LTS新機能の紹介

    View Slide

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

    View Slide

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

    View Slide

  9. ● 測定結果例
    ○ 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倍のインデックス作成の高速化

    View Slide

  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倍のインデックス作成の高速化

    View Slide

  11. ● 従来の設定
    ○ 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

    View Slide

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

    View Slide

  13. ● 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

    View Slide

  14. 従来の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

    View Slide

  15. 新しい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

    View Slide

  16. ● 従来の設定
    ○ 「クエリ単位」でのメモリ上限が設定可能だった
    ○ システム変数`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サーバーレベルメモリコントロール

    View Slide

  17. ● 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サーバーレベルメモリコントロール

    View Slide

  18. ● 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

    View Slide

  19. ● 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コマンド例

    View Slide

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

    View Slide

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

    View Slide

  22. ● 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/
    その他の新機能の紹介

    View Slide

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

    View Slide

  24. ● 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で利用する方法

    View Slide

  25. ● 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で利用する方法

    View Slide

  26. Q&A

    View Slide

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

    View Slide

  28. これまでのウェビナースケジュール
    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/

    View Slide

  29. Thank You!

    https://www.pingcap.com/

    [email protected]

    View Slide