TiDB 6.5.0 リリースノート

リリース日：2022年12月29日

TiDB バージョン: 6.5.0

クイックアクセス: クイックスタート | 本番環境へのデプロイ

TiDB 6.5.0 は長期サポートリリース (LTS) です。

TiDB 6.4.0-DMRと比較して、TiDB 6.5.0 では次の主要な機能と改善が導入されています。

• インデックス加速機能が一般提供 (GA) され、v6.1.0 と比較してインデックス追加のパフォーマンスが約 10 倍向上しました。
• TiDB グローバルメモリ制御が GA になり、 tidb_server_memory_limitを介してメモリ消費しきい値を制御できるようになりました。
• 高性能かつグローバルに単調なAUTO_INCREMENT列属性が、MySQLと互換性のあるGAになります。
• FLASHBACK CLUSTER TO TIMESTAMPは TiCDC および PITR と互換性があり、GA になります。
• より正確なコストモデル バージョン 2を一般提供し、 ANDでインデックスマージに接続された式をサポートすることで、 TiDB オプティマイザを強化します。
• JSON_EXTRACT()関数をTiFlashにプッシュダウンすることをサポートします。
• パスワード コンプライアンス監査要件を満たすパスワード管理ポリシーをサポートします。
• TiDB LightningとDumplingは、圧縮されたSQLおよびCSVファイルのインポートおよびエクスポートをサポートします。
• TiDB Data Migration (DM) 継続的なデータ検証が GA になります。
• TiDB バックアップ & リストアは、スナップショット チェックポイント バックアップをサポートし、 PITRのリカバリ パフォーマンスを 50% 向上させ、一般的なシナリオでの RPO を最短 5分に短縮します。
• Kafkaへのデータの複製の TiCDC スループットを 4000 行/秒から 35000 行/秒に向上し、レプリケーションのレイテンシーを2秒に短縮します。
• データのライフサイクルを管理するために行レベルTTL (Time to Live)を提供します (実験的)。
• TiCDC は、Amazon S3、Azure Blob Storage、NFS (実験的) など変更ログをオブジェクトストレージに複製することをサポートしています。

新機能

SQL

• TiDBのインデックス追加のパフォーマンスは約10倍向上します（GA） #35983 @benjamin2037 @tangenta

  TiDB v6.3.0では、インデックス作成時のバックフィル速度を向上させる実験的機能としてインデックス追加の高速化が導入されました。v6.5.0ではこの機能がGAとなり、デフォルトで有効化されます。大規模テーブルにおけるパフォーマンスはv6.1.0と比較して約10倍向上すると予想されます。この高速化機能は、単一のSQL文がインデックスを逐次追加するシナリオに適しています。複数のSQL文が並列でインデックスを追加する場合は、そのうちの1つのSQL文のみが高速化されます。

• DDL 変更時の DML 成功率を向上させる軽量メタデータロックを提供する (GA) #37275 @wjhuang2016

  TiDB v6.3.0 では、メタデータロックが実験的機能として導入されています。DML 文によって発生するInformation schema is changedエラーを回避するため、TiDB はテーブルメタデータの変更時に DML と DDL の優先順位を調整し、実行中の DDL を古いメタデータを持つ DML のコミットまで待機させます。v6.5.0 ではこの機能が GA となり、デフォルトで有効化されます。これは、さまざまな種類の DDL 変更シナリオに適しています。既存のクラスターを v6.5.0 より前のバージョンから v6.5.0 以降にアップグレードすると、TiDB は自動的にメタデータロックを有効にします。この機能を無効にするには、システム変数tidb_enable_metadata_lockをOFFに設定します。

  詳細についてはドキュメントを参照してください。

• FLASHBACK CLUSTER TO TIMESTAMP (GA) を使用して、クラスターを特定の時点に復元する機能をサポートします。 #37197 #13303 @Defined2014 @bb7133 @JmPotato @Connor1996 @HuSharp @CalvinNeo

  TiDB v6.4.0以降、 FLASHBACK CLUSTER TO TIMESTAMPステートメントが実験的機能として導入されました。このステートメントを使用すると、ガベージコレクション（GC）の有効期間内の特定の時点にクラスターを復元できます。v6.5.0では、この機能はTiCDCおよびPITRと互換性があり、GAとなります。この機能により、DMLの誤操作を簡単に元に戻したり、数分で元のクラスターを復元したり、異なる時点のデータをロールバックしてデータが変更された正確な時刻を特定したりすることが可能になります。

  詳細についてはドキュメントを参照してください。

• INSERT 、 REPLACE 、 UPDATE 、 DELETE を含む非トランザクションDML文を完全にサポート #33485 @ekexium

  大規模データ処理のシナリオでは、大規模なトランザクションを含む単一のSQL文が、クラスタの安定性とパフォーマンスに悪影響を及ぼす可能性があります。非トランザクションDML文とは、内部実行のために複数のSQL文に分割されたDML文です。分割された文はトランザクションの原子性と独立性を損なう一方で、クラスタの安定性を大幅に向上させます。TiDBはバージョン6.1.0以降、非トランザクションDELETE文をサポートしており、バージョン6.5.0以降、非トランザクションINSERT文、REPLACE文、およびUPDATE文をサポートしています。

  詳細については、 非トランザクションDML文およびBATCH構文を参照してください。

• TTLをサポート (実験的) #39262 @lcwangchao

  TTLは行レベルのデータ有効期間管理を提供します。TiDBでは、TTL属性を持つテーブルはデータ有効期間を自動的にチェックし、期限切れのデータを行レベルで削除します。TTLは、オンラインの読み取りおよび書き込みワークロードに影響を与えることなく、不要なデータを定期的かつタイムリーにクリーンアップできるように設計されています。

  詳細についてはドキュメントを参照してください。

• INSERT INTO SELECT文を使用したTiFlashクエリ結果の保存をサポート (実験的) #37515 @gengliqi

  TiDB v6.5.0以降、 INSERT INTO SELECT文のSELECTの句（分析クエリ）をTiFlashにプッシュダウンできるようになりました。これにより、 TiFlashクエリの結果をINSERT INTOで指定したTiDBテーブルに簡単に保存して、さらに分析することができます。これは、結果のキャッシュ（つまり、結果のマテリアライゼーション）として機能します。例えば、次のようになります。

  INSERT INTO t2 SELECT Mod(x,y) FROM t1;
  

  実験的段階中は、この機能はデフォルトで無効になっています。有効にするには、システム変数tidb_enable_tiflash_read_for_write_stmtをONに設定します。この機能では、 INSERT INTOで指定される結果テーブルに特別な制限はなく、 TiFlashレプリカを結果テーブルに追加するかどうかは自由に設定できます。この機能の典型的な使用シナリオは以下のとおりです。

  • TiFlashを使用して複雑な分析クエリを実行する

  • TiFlashクエリ結果を再利用するか、同時実行性の高いオンライン リクエストを処理する

  • 入力データのサイズと比較して比較的小さい結果セットが必要です。100 MiB 未満が望ましいです。

    詳細についてはドキュメントを参照してください。

• バインディング履歴実行計画のサポート（実験的） #39199 @fzzf678

  SQL文の場合、実行中の様々な要因により、オプティマイザが以前の最適な実行計画ではなく新しい実行計画を選択することがあり、SQLパフォーマンスに影響が出ることがあります。この場合、最適な実行計画がまだクリアされていない場合、SQL実行履歴に残ります。

  TiDB v6.5.0では、 CREATE [GLOBAL | SESSION] BINDINGステートメントのバインディングオブジェクトを拡張することで、履歴実行計画のバインディングをサポートします。SQL文の実行計画が変更された場合、元の実行計画がSQL実行履歴メモリテーブル（例えばstatements_summary）に残っている限り、 CREATE [GLOBAL | SESSION] BINDINGステートメントでplan_digestを指定することで元の実行計画をバインドし、SQLパフォーマンスを迅速に回復できます。この機能により、実行計画変更の問題への対応プロセスが簡素化され、メンテナンス効率が向上します。

  詳細についてはドキュメントを参照してください。

セキュリティ

• パスワードの複雑さのポリシーをサポートする #38928 @CbcWestwolf

  このポリシーを有効にすると、パスワードを設定する際に、TiDBはパスワードの長さ、大文字と小文字、数字、特殊文字の数が適切かどうか、パスワードが辞書と一致しているかどうか、そしてユーザー名と一致しているかどうかをチェックします。これにより、安全なパスワードを設定できます。

  TiDB は、パスワードの強度を検証するための SQL 関数VALIDATE_PASSWORD_STRENGTH()を提供します。

  詳細についてはドキュメントを参照してください。

• パスワード有効期限ポリシーをサポート #38936 @CbcWestwolf

  TiDBは、パスワードの有効期限ポリシー（手動による有効期限、グローバルレベルの自動有効期限、アカウントレベルの自動有効期限など）の設定をサポートしています。このポリシーを有効にすると、パスワードを定期的に変更する必要があります。これにより、長期使用によるパスワード漏洩のリスクが軽減され、パスワードのセキュリティが向上します。

  詳細についてはドキュメントを参照してください。

• パスワード再利用ポリシーをサポートする #38937 @keeplearning20221

  TiDBは、グローバルレベルのパスワード再利用ポリシーとアカウントレベルのパスワード再利用ポリシーを含む、パスワード再利用ポリシーの設定をサポートしています。このポリシーを有効にすると、指定期間内に使用したパスワード、または直近の数個のパスワードは使用できなくなります。これにより、パスワードの繰り返し使用によるパスワード漏洩のリスクが軽減され、パスワードのセキュリティが向上します。

  詳細についてはドキュメントを参照してください。

• ログイン失敗の追跡と一時的なアカウントロックポリシーをサポート #38938 @lastincisor

  このポリシーを有効にすると、TiDBに連続して間違ったパスワードでログインした場合、アカウントは一時的にロックされます。ロック時間が終了すると、アカウントは自動的にロック解除されます。

  詳細についてはドキュメントを参照してください。

可観測性

• TiDB DashboardはKubernetes上に独立したPod としてデプロイできます #1447 @SabaPing

  TiDB v6.5.0以降およびTiDB Operator v1.4.0以降では、Kubernetes上にTiDB Dashboardを独立したPodとしてデプロイできます。TiDB Operatorを使用すると、このPodのIPアドレスにアクセスしてTiDB Dashboardを起動できます。

  TiDB Dashboardを個別にデプロイすると、次の利点が得られます。

  • TiDB Dashboardの計算処理はPDノードに負担をかけません。これにより、より安定したクラスター運用が実現します。

  • PD ノードが利用できない場合でも、ユーザーは診断のために TiDB Dashboardにアクセスできます。

  • インターネット経由でTiDB Dashboardにアクセスする場合、PDの特権インターフェースは使用されません。そのため、クラスターのセキュリティリスクは軽減されます。

    詳細についてはドキュメントを参照してください。

• パフォーマンス概要ダッシュボードにTiFlashと CDC (変更データキャプチャ) パネルが追加されました #39230 @dbsid

  TiDB v6.1.0以降、Grafanaにパフォーマンス概要ダッシュボードが導入されました。このダッシュボードは、TiDB、TiKV、PDの全体的なパフォーマンス診断のためのシステムレベルのエントリを提供します。v6.5.0では、パフォーマンス概要ダッシュボードにTiFlashとCDCパネルが追加されました。これらのパネルを使用することで、v6.5.0以降では、パフォーマンス概要ダッシュボードを使用してTiDBクラスター内のすべてのコンポーネントのパフォーマンスを分析できます。

  TiFlashおよび CDC パネルは、 TiFlashおよび TiCDC の監視情報を再編成します。これにより、 TiFlashおよび TiCDC のパフォーマンスの問題の分析とトラブルシューティングの効率が大幅に向上します。

  • TiFlashパネルでは、 TiFlashクラスターのリクエストタイプ、レイテンシー分析、リソース使用状況の概要を簡単に表示できます。

  • CDCパネルでは、TiCDC クラスターの健全性、レプリケーションのレイテンシー、データフロー、ダウンストリームの書き込みレイテンシーを簡単に確認できます。

    詳細についてはドキュメントを参照してください。

パフォーマンス

• インデックスマージは、 AND で接続された式をサポートします #39333 @guo-shaoge @time-and-fate @hailanwhu

  v6.5.0より前のTiDBでは、 ORで連結されたフィルタ条件に対してのみインデックスマージがサポートされていました。v6.5.0以降、TiDBはWHERE句のANDで連結されたフィルタ条件に対してもインデックスマージがサポートされるようになりました。これにより、TiDBのインデックスマージは、より一般的なクエリフィルタ条件の組み合わせをカバーできるようになり、union( OR )関係に限定されなくなりました。現在のv6.5.0バージョンでは、オプティマイザによって自動的に選択されたORの条件でのインデックスマージのみがサポートされています。AND条件でインデックスマージを有効にするには、 USE_INDEX_MERGEヒントを使用する必要があります。

  インデックスマージの詳細については、 v5.4.0 リリースノートとインデックスマージを使用したステートメントの説明を参照してください。

• 以下のJSON関数をTiFlash にプッシュダウンすることをサポートします #39458 @yibin87

  • ->

  • ->>

  • JSON_EXTRACT()

    JSON形式は、アプリケーションのデータモデリングに柔軟な方法を提供します。そのため、ますます多くのアプリケーションがデータ交換とデータストレージにJSON形式を使用しています。JSON関数をTiFlashにプッシュダウンすることで、JSON型のデータ分析の効率を向上させ、TiDBをよりリアルタイムな分析シナリオに活用できるようになります。

• 以下の文字列関数をTiFlash にプッシュダウンすることをサポートします #6115 @xzhangxian1008

  • regexp_like
  • regexp_instr
  • regexp_substr

• ビュー で実行計画生成に干渉するグローバルオプティマイザヒントをサポートします #37887 @Reminiscent

  ビューアクセスのシナリオによっては、最適なパフォーマンスを実現するために、ビュー内のクエリの実行計画にオプティマイザヒントを使用して介入する必要があります。TiDB v6.5.0以降、ビュー内のクエリブロックへのグローバルヒントの追加がサポートされ、クエリで定義されたヒントがビュー内で有効になります。この機能により、ネストされたビューを含む複雑なSQL文にヒントを挿入できるようになり、実行計画の制御が強化され、複雑な文のパフォーマンスが安定します。グローバルヒントを使用するには、 クエリブロックに名前を付け、 ヒント参照を指定する必要があります。

  詳細についてはドキュメントを参照してください。

• パーティションテーブルから TiKV へのソート操作のプッシュダウンをサポート #26166 @winoros

  パーティションテーブル機能は v6.1.0 から GA となっていますが、TiDB は継続的にパフォーマンスを改善しています。v6.5.0 では、TiDB は計算とフィルタリングのためにORDER BYやLIMITなどのソート操作を TiKV にプッシュダウンすることをサポートします。これにより、ネットワーク I/O オーバーヘッドが削減され、パーティションテーブル使用時の SQL パフォーマンスが向上します。

• オプティマイザはより正確なコストモデルバージョン2（GA） を導入しました #35240 @qw4990

  TiDB v6.2.0 では、 コストモデル バージョン 2が実験的機能として導入されました。このモデルは、より正確なコスト推定手法を用いて、オプティマイザが最適な実行計画を選択できるように支援します。特にTiFlashを導入している場合、コストモデル バージョン 2 は適切なストレージエンジンを自動的に選択し、手動による介入を大幅に削減します。一定期間の実環境テストを経て、このモデルは v6.5.0 で一般提供となります。v6.5.0 以降、新規に作成されたクラスターはデフォルトでコストモデル バージョン 2 を使用します。v6.5.0 にアップグレードするクラスターでは、コストモデル バージョン 2 によってクエリプランが変更される可能性があるため、十分なパフォーマンステストを行った後、 tidb_cost_model_version = 2変数を設定して新しいコストモデルを使用するように設定できます。

  コストモデル バージョン 2 は、TiDB オプティマイザの全体的な機能を大幅に向上させ、TiDB をより強力な HTAP データベースへと進化させる、一般利用可能な機能になります。

  詳細についてはドキュメントを参照してください。

• TiFlashはテーブル行数を取得する操作を最適化します #37165 @elsa0520

  データ分析のシナリオでは、フィルター条件なしでCOUNT(*)を通してテーブルの実際の行数を取得する操作が一般的です。v6.5.0では、 TiFlashはCOUNT(*)の書き換えを最適化し、列定義が最短の非NULL列を自動的に選択して行数をカウントします。これにより、 TiFlashのI/O操作数を効果的に削減し、行数取得の実行効率を向上させます。

安定性

• グローバルメモリ制御機能はGA になりました #37816 @wshwsh12

  TiDBはv6.4.0以降、実験的機能としてグローバルメモリ制御を導入しました。v6.5.0ではGAとなり、メインメモリの消費量を追跡できるようになりました。グローバルメモリの消費量がtidb_server_memory_limitで定義されたしきい値に達すると、TiDBはGCまたはSQL操作のキャンセルによってメモリ使用量を制限し、安定性を確保しようとします。

  セッション中のトランザクションによって消費されるメモリ（最大値は以前は設定項目txn-total-size-limitによって設定されていました）が、メモリ管理モジュールによって追跡されるようになりました。単一セッションのメモリ消費量がシステム変数tidb_mem_quota_queryで定義されたしきい値に達すると、システム変数tidb_mem_oom_actionで定義された動作がトリガーされます（デフォルトはCANCEL 、つまり操作のキャンセルです）。前方互換性を確保するため、デフォルト以外の値としてtxn-total-size-limitが設定されている場合でも、TiDB はトランザクションがtxn-total-size-limitで設定されたメモリを使用できるようにします。

  TiDB v6.5.0以降をご利用の場合は、 txn-total-size-limitを削除し、トランザクションのメモリ使用量に別途制限を設けないことを推奨します。代わりに、システム変数tidb_mem_quota_queryとtidb_server_memory_limitを使用してグローバルメモリを管理することで、メモリ使用効率を向上させることができます。

  詳細についてはドキュメントを参照してください。

使いやすさ

• EXPLAIN ANALYZE出力のTiFlash TableFullScanオペレーターの実行情報を精緻化する #5926 @hongyunyan

  EXPLAIN ANALYZE文は、実行計画と実行時統計を出力するために使用されます。v6.5.0 では、 TiFlash はTableFullScanオペレーターの実行情報を改良し、DMFile 関連の実行情報を追加しました。これにより、 TiFlash のデータスキャンステータス情報がより直感的に表示されるようになり、 TiFlash のパフォーマンス分析が容易になります。

  詳細についてはドキュメントを参照してください。

• JSON形式での実行計画の出力をサポート#39261 @fzzf678

  TiDB v6.5.0では、実行計画の出力形式が拡張されました。EXPLAINにFORMAT = "tidb_json"を指定することで、SQL実行計画をJSON形式で出力できます。この機能により、SQLデバッグツールや診断ツールは実行計画をより便利かつ正確に読み取ることができるため、SQL診断やチューニングの利便性が向上します。

  詳細についてはドキュメントを参照してください。

MySQLとの互換性

• 高性能かつグローバルに単調なAUTO_INCREMENT列属性 (GA) をサポート #38442 @tiancaiamao

  TiDBはv6.4.0以降、実験的機能としてMySQL互換モードAUTO_INCREMENTを導入しました。このモードでは、すべてのTiDBインスタンスでIDが単調に増加するようにする、集中型のAUTO_INCREMENT ID割り当てサービスが導入されます。この機能により、AUTO_INCREMENT IDによるクエリ結果のソートが容易になります。v6.5.0では、この機能がGAになります。この機能を使用したテーブルの挿入TPSは20,000を超えると予想されており、この機能は単一のテーブルとクラスタ全体の書き込みスループットを向上させるためのエラスティックスケーリングをサポートしています。MySQL互換モードを使用するには、テーブル作成時にAUTO_ID_CACHEを1に設定する必要があります。以下は例です。

  CREATE TABLE t(a int AUTO_INCREMENT key) AUTO_ID_CACHE 1;
  

  詳細についてはドキュメントを参照してください。

データ移行

• gzip、snappy、zstd 圧縮形式での SQL および CSV ファイルのエクスポートとインポートをサポート#38514 @lichunzhu

  Dumpling は、gzip、snappy、zstd などの圧縮形式で圧縮された SQL ファイルおよび CSV ファイルへのデータのエクスポートをサポートしています。TiDB Lightning は、これらの形式で圧縮されたファイルのインポートもサポートしています。

  これまで、CSVファイルやSQLファイルの保存には、データのエクスポートやインポートに大量のストレージ容量が必要であり、ストレージコストが高くなっていました。この機能のリリースにより、データファイルを圧縮することで、ストレージコストを大幅に削減できます。

  詳細についてはドキュメントを参照してください。

• binlog解析機能を最適化 #924 @GMHDBJD

  TiDBは、移行タスクに含まれないスキーマとテーブルのbinlogイベントをフィルタリングすることで、解析効率と安定性を向上させます。このポリシーはv6.5.0でデフォルトで有効になります。追加の設定は必要ありません。

  以前は、移行するテーブルが少数であっても、上流のbinlogファイル全体を解析する必要がありました。binlogファイル内の移行が不要なテーブルのbinlogイベントも解析する必要があり、効率が悪かったです。また、これらのbinlogイベントが解析をサポートしていない場合、タスクは失敗します。移行タスクで必要なテーブルのbinlogイベントのみを解析することで、binlog解析の効率が大幅に向上し、タスクの安定性が向上します。

• TiDB LightningのディスククォータはGA です #446 @buchuitoudegou

  TiDB Lightningのディスククォータを設定できます。ディスククォータが不足している場合、 TiDB Lightning はソースデータの読み取りと一時ファイルの書き込みを停止します。代わりに、ソートされたキーと値をまず TiKV に書き込み、TiDB Lightningの一時ファイルを削除した後、インポートプロセスを続行します。

  以前は、 TiDB Lightning が物理モードでデータをインポートすると、生データのエンコード、ソート、分割のためにローカルディスク上に多数の一時ファイルが作成されていました。ローカルディスクの空き容量が不足すると、 TiDB Lightning はファイルへの書き込みに失敗したためにエラーで終了していました。この機能により、 TiDB Lightningタスクはローカルディスクの上書きを回避できます。

  詳細についてはドキュメントを参照してください。

• DMにおける継続的なデータ検証はGA です #4426 @D3Hunter

  上流データベースから下流データベースへの増分データ移行プロセスにおいて、データフローによってエラーやデータ損失が発生する可能性がわずかにあります。クレジットや証券業務など、強力なデータ整合性が求められるシナリオでは、移行後にデータに対してフルボリュームチェックサムを実行し、データの整合性を確保できます。ただし、一部の増分レプリケーションシナリオでは、上流と下流のデータが常に変化するため、上流と下流への書き込みが継続的かつ中断されることなく行われるため、すべてのデータに対して整合性チェックを実行することが困難になります。

  以前は、データ全体を検証するために業務を中断する必要があり、業務に影響が出ていました。この機能により、業務を中断することなく増分データ検証を実行できるようになりました。

  詳細についてはドキュメントを参照してください。

TiDBデータ共有サブスクリプション

• TiCDC は、変更されたログをストレージシンクに複製することをサポートしています (実験的) #6797 @zhaoxinyu

  TiCDCは、Amazon S3、Azure Blob Storage、NFS、その他のS3互換ストレージサービスへの変更ログのレプリケーションをサポートしています。クラウドストレージは手頃な価格で使いやすいです。Kafkaを使用していない場合は、ストレージシンクを使用できます。TiCDCは変更ログをファイルに保存し、ストレージシステムに送信します。コンシューマープログラムは、ストレージシステムから新しく生成された変更ログファイルを定期的に読み取ります。

  ストレージシンクは、canal-json形式とCSV形式の変更ログをサポートしています。詳細については、ドキュメントを参照してください。

• TiCDCは2つのクラスタ間の双方向レプリケーションをサポートします#38587 @xiongjiwei @asddongmen

  TiCDCは、2つのTiDBクラスタ間の双方向レプリケーションをサポートしています。アプリケーションのために地理的に分散された複数のアクティブデータセンターを構築する必要がある場合、この機能をソリューションとして利用できます。あるTiDBクラスタから別のTiDBクラスタへのTiCDCの変更フィードにbdr-mode = trueパラメータを設定することで、2つのTiDBクラスタ間の双方向データレプリケーションを実現できます。

  詳細についてはドキュメントを参照してください。

• TiCDCはTLSオンラインの更新をサポート #7908 @CharlesCheung96

  データベースシステムのセキュリティを維持するには、システムで使用する証明書に有効期限ポリシーを設定する必要があります。有効期限が切れると、システムは新しい証明書を必要とします。TiCDC v6.5.0は、TLS証明書のオンライン更新をサポートしています。レプリケーションタスクを中断することなく、TiCDCは証明書を自動的に検出して更新するため、手動による介入は不要です。

• TiCDCのパフォーマンスが大幅に向上#7540 #7478 #7532 @sdojjy @3AceShowHand

  TiDBクラスタのテストシナリオでは、TiCDCのパフォーマンスが大幅に向上しました。具体的には、シナリオKafkaへのデータの複製では、単一のTiCDCが処理できる行変更の最大量は3万行/秒に達し、レプリケーションのレイテンシーは10秒に短縮されました。TiKVとTiCDCのローリングアップグレード中でも、レプリケーションのレイテンシーは30秒未満です。

  災害復旧 (DR) シナリオでは、TiCDC の再実行ログと同期ポイントを有効にすると、TiCDC のスループットを 4000 行/秒から 35000 行/秒に向上でき、レプリケーションのレイテンシーを2秒に制限できます。

バックアップと復元

• TiDB バックアップ & リストアはスナップショット チェックポイント バックアップをサポートします #38647 @Leavrth

  TiDBスナップショットバックアップは、チェックポイントからのバックアップ再開をサポートしています。バックアップ＆リストア（BR）は、回復可能なエラーが発生するとバックアップを再試行します。ただし、再試行が複数回失敗するとBRは終了します。チェックポイントバックアップ機能により、数十分のネットワーク障害など、回復可能なより長い障害の再試行が可能になります。

  BR終了後1時間以内にシステムを障害から復旧しない場合、バックアップ対象のスナップショットデータがGCメカニズムによって再利用され、バックアップが失敗する可能性があることに注意してください。詳細については、 ドキュメントを参照してください。

• PITRのパフォーマンスは著しく向上しました @joccau

  ログリストア段階では、1つのTiKVのリストア速度が9MiB/sに達し、従来比50%の高速化を実現しました。リストア速度はスケーラブルで、DRシナリオにおけるRTO（目標復旧時間）は大幅に短縮されます。DRシナリオにおけるRPO（目標復旧時点）は最短5分です。通常のクラスター運用保守（OM）では、例えばローリングアップグレードの実行時や、1つのTiKVのみがダウンしている場合でも、RPOは5分です。

• TiKV-BR GA: RawKVのバックアップと復元をサポート #67 @pingyu @haojinming

  TiKV-BRは、TiKVクラスターで使用されるバックアップおよびリストアツールです。TiKVとPDは、TiDBを使用せずにRawKVと呼ばれるKVデータベースを構成できます。TiKV-BRは、RawKVを使用する製品のデータバックアップとリストアをサポートします。また、 TiKVクラスターのapi-versionをAPI V1からAPI V2にアップグレードすることもできます。

  詳細についてはドキュメントを参照してください。

互換性の変更

システム変数

設定ファイルのパラメータ

その他

• v6.5.0 以降、 mysql.userテーブルにPassword_reuse_historyとPassword_reuse_timeの2つの新しい列が追加されます。
• バージョン6.5.0以降、 インデックス加速機能がデフォルトで有効になっています。この機能は1つのALTER TABLE文で複数の列またはインデックスを変更すると完全には互換性がありません。インデックスアクセラレーションを使用して一意インデックスを追加する場合、同じステートメント内で他の列やインデックスを変更しないようにする必要があります。この機能はPITR（ポイントインタイムリカバリ）とも互換性がありません。インデックスアクセラレーション機能を使用する場合は、バックグラウンドでPITRバックアップタスクが実行されていないことを確認する必要があります。そうしないと、予期しない結果が発生する可能性があります。詳細については、 ドキュメントを参照してください。

非推奨の機能

v6.5.0 以降では、v4.0.7 で導入されたAMEND TRANSACTIONメカニズムは非推奨となり、 メタデータロックに置き換えられます。

改善点

• TiDB

  • BITとCHAR列については、 INFORMATION_SCHEMA.COLUMNSの結果をMySQL と一致させる #25472 @hawkingrei
  • TiFlash MPPモードのTiFlashノードのTiDBプローブメカニズムを最適化し、ノードが異常な場合のパフォーマンスへの影響を軽減します#39686 @hackersean

• TiKV

  • ディスク容量の枯渇を避けるため、十分なスペースがない場合はRaft Engineへの書き込みを停止します#13642 @jiayang-zheng
  • json_valid関数のTiKVへのプッシュダウンをサポート #13571 @lizhenhuan
  • 1回のバックアップリクエストで複数の範囲のデータのバックアップをサポート#13701 @Leavrth
  • rusotoライブラリを更新してAWSのアジア太平洋地域（ap-southeast-3）へのデータバックアップをサポート #13751 @3pointer
  • 悲観的トランザクション競合を減らす#13298 @MyonKeminta
  • 外部ストレージオブジェクトをキャッシュすることでリカバリパフォーマンスを向上 #13798 @YuJuncen
  • 専用スレッドで CheckLeader を実行して、TiCDC レプリケーションのレイテンシーを削減します。 #13774 @overvenus
  • チェックポイントのプル モデルをサポート #13824 @YuJuncen
  • crossbeam-channel を更新することで、送信側でのスピンの問題を回避します。 #13815 @sticnarf
  • TiKV でのバッチコプロセッサータスク処理をサポート #13849 @cfzjywxk
  • TiKVにリージョンを起動するように通知することで、障害回復の待ち時間を短縮します。 #13648 @LykxSassinator
  • コード最適化によりメモリ使用量のリクエストサイズを削減 #13827 @BusyJay
  • コードの拡張性を向上させるためにRaft拡張機能を導入する#13827 @BusyJay
  • tikv-ctl を使用して、特定のキー範囲に含まれるリージョンを照会することをサポートします。 #13760 @HuSharp
  • 更新されないが継続的にロックされている行の読み取りと書き込みのパフォーマンスを向上#13694 @sticnarf

• PD

  • ロックの粒度を最適化してロックの競合を減らし、高同時実行時のハートビートの処理能力を向上させる#5586 @rleungx
  • 大規模クラスタのスケジューラパフォーマンスを最適化し、スケジューリングポリシーの生成を高速化します。 #5473 @bufferflies
  • リージョンの読み込み速度を向上 #5606 @rleungx
  • リージョンハートビートの最適化された処理により不要なオーバーヘッドを削減 #5648 @rleungx
  • tombstoneストアの自動ガベージコレクション機能を追加 #5348 @nolouch

• TiFlash

  • SQL側でバッチ処理が行われないシナリオでの書き込みパフォーマンスの向上#6404 @lidezhu
  • explain analyze出力に TableFullScan の詳細を追加します #5926 @hongyunyan

• ツール

  • TiDB Dashboard

    • スロークエリページに 3 つの新しいフィールドを追加します:"Is Prepared?"、"Is Plan from Cache?"、"Is Plan from Binding?" #1451 @shhdgit

  • Backup & Restore (BR)

    • バックアップログデータの消去プロセス中にBRメモリ使用量を最適化します #38869 @Leavrth
    • 復元プロセス中にPDリーダースイッチによって発生する復元失敗の問題を修正#36910 @MoCuishle28
    • ログバックアップで OpenSSL プロトコルを使用することにより、TLS 互換性が向上します。 #13867 @YuJuncen

  • TiCDC

    • Kafka プロトコルエンコーダーのパフォーマンスを向上 #7540 #7532 #7543 @3AceShowHand @sdojjy

  • TiDB Data Migration (DM)

    • ブロックリスト内のテーブルのデータを解析しないことで、DMのデータ複製パフォーマンスを向上します。 #7622 @GMHDBJD
    • 非同期書き込みとバッチ書き込みを使用してDMリレーの書き込み効率を向上 #7580 @GMHDBJD
    • DM事前チェックのエラーメッセージを最適化 #7621 @buchuitoudegou
    • 古いMySQLバージョンに対するSHOW SLAVE HOSTSの互換性を改善 #5017 @lyzx2001

バグ修正

• TiDB

  • 一部のケースで発生するチャンク再利用機能のメモリチャンクの誤用問題を修正#38917 @keeplearning20221
  • tidb_constraint_check_in_place_pessimisticの内部セッションがグローバル設定の影響を受ける可能性がある問題を修正しました #38766 @ekexium
  • AUTO_INCREMENT列がCHECK制約で動作しない問題を修正 #38894 @YangKeao
  • INSERT IGNORE INTOを使用してSTRING型のデータをSMALLINT型のAUTO_INCREMENT列に挿入すると、エラーが発生する問題を修正しました。 #38483 @hawkingrei
  • パーティションテーブルのパーティション列の名前を変更する操作で NULL ポインタ エラーが発生する問題を修正しました。 #38932 @mjonss
  • パーティションテーブルのパーティション列を変更すると、DDLがハングする問題を修正しました。 #38530 @mjonss
  • v4.0.16からv6.4.0 にアップグレードした後にADMIN SHOW JOB操作がパニックになる問題を修正 #38980 @tangenta
  • tidb_decode_key関数がパーティションテーブルのエンコーディングを正しく解析できない問題を修正しました #39304 @Defined2014
  • ログローテーション中に gRPC エラーログが正しいログファイルにリダイレクトされない問題を修正しました #38941 @xhebox
  • TiKV が読み取りエンジンとして設定されていない場合に、TiDB がBEGIN; SELECT... FOR UPDATE;ポイントクエリに対して予期しない実行計画を生成する問題を修正しました#39344 @Yisaer
  • 誤ってStreamAggをTiFlashにプッシュダウンすると、間違った結果が発生する問題を修正しました。 #39266 @fixdb

• TiKV

  • Raft Engine ctl のエラーを修正しました #11119 @tabokie
  • tikv-ctl でcompact raftコマンドを実行するときに発生するGet raft db is not allowedエラーを修正します #13515 @guoxiangCN
  • TLS が有効な場合にログバックアップが機能しない問題を修正#13867 @YuJuncen
  • ジオメトリフィールドタイプのサポート問題を修正しました #13651 @dveeden
  • 新しい照合順序が有効になっていない場合、 LIKE演算子の_が非 ASCII 文字と一致しない問題を修正#13769 @YangKeao
  • reset-to-versionコマンドを実行すると tikv-ctl が予期せず終了する問題を修正しました #13829 @tabokie

• PD

  • balance-hot-region-scheduler構成が変更されていない場合は保持されない問題を修正しました #5701 @HunDunDM
  • rank-formula-versionがアップグレードプロセス中にアップグレード前の構成を保持しない問題を修正#5698 @HunDunDM

• TiFlash

  • TiFlash を再起動した後、デルタレイヤーの列ファイルをコンパクションできない問題を修正しました。 #6159 @lidezhu
  • TiFlashファイルオープンOPSが高すぎる問題を修正 #6345 @JaySon-Huang

• ツール

  • Backup & Restore (BR)

    • BRがログバックアップデータを削除するときに、削除されるべきでないデータを誤って削除してしまう問題を修正#38939 @Leavrth
    • データベースまたはテーブルの照合順序に古いフレームワークを使用すると復元タスクが失敗する問題を修正しました #39150 @MoCuishle28
    • Alibaba CloudとHuawei CloudがAmazon S3ストレージと完全に互換性がないため、バックアップが失敗する問題を修正 #39545 @3pointer

  • TiCDC

    • PDリーダーがクラッシュするとTiCDCが停止する問題を修正 #7470 @zeminzhou
    • 最初にDDL文を実行し、次に変更フィードを一時停止して再開するシナリオで発生したデータ損失を修正しました #7682 @asddongmen
    • より新しいバージョンの TiFlash がある場合に TiCDC が誤ってエラーを報告する問題を修正しました #7744 @overvenus
    • 下流ネットワークが利用できない場合にシンクコンポーネントがスタックする問題を修正#7706 @hicqu
    • ユーザーがレプリケーションタスクを素早く削除し、同じタスク名で別のタスクを作成するとデータが失われる問題を修正#7657 @overvenus

  • TiDB Data Migration (DM)

    • 上流データベースがGTIDモードを有効にしているが、データがない場合にtask-mode:allタスクを開始できない問題を修正しました。 #7037 @liumengya94
    • 既存のワーカーが終了する前に新しい DM-workerがスケジュールされると、データが複数回複製される問題を修正しました#7658 @GMHDBJD
    • アップストリームデータベースが正規表現を使用して権限を付与するときに DM 事前チェックに合格しない問題を修正しました #7645 @lance6716

  • TiDB Lightning

    • TiDB Lightning が巨大なソースデータファイルをインポートする際のメモリリークの問題を修正しました #39331 @dsdashun
    • TiDB Lightningが並列でデータをインポートするときに競合を正しく検出できない問題を修正しました #39476 @dsdashun

貢献者

TiDB コミュニティの以下の貢献者に感謝いたします。

• e1ijah1
• guoxiangCN (初回貢献者)
• jiayang-zheng
• jiyfhust
• mikechengwei
• pingandb
• sashashura
• sourcelliu
• wxbty