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 では次の主要な機能と改善が導入されています。

ヒント：

以前の LTS 6.1.0 と比較して、 TiDB 6.5.0 には、 6.2.0-DMR 、 6.3.0-DMR 、 6.4.0-DMRでリリースされた新機能、改善、バグ修正も含まれています。

• 6.1.0 LTS バージョンと 6.5.0 LTS バージョン間の変更点の完全なリストを取得するには、このリリース ノートに加えて、 6.2.0-DMR リリースノート 、 6.3.0-DMR リリースノート 、および6.4.0-DMR リリースノートも参照してください。
• 6.1.0 LTS バージョンと 6.5.0 LTS バージョンの主な機能を簡単に比較するには、 TiDBの機能のv6.1とv6.5列を確認してください。

• インデックス加速機能が一般提供 (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 データ移行 (DM) 継続的なデータ検証 GA になります。
• TiDB バックアップ & リストアは、スナップショット チェックポイント バックアップをサポートし、 PITRのリカバリ パフォーマンスを 50% 向上させ、一般的なシナリオでの RPO を最短 5 分に短縮します。
• Kafkaへのデータの複製の TiCDC スループットを 4000 行/秒から 35000 行/秒に向上し、レプリケーションのレイテンシーを2 秒に短縮します。
• データのライフサイクルを管理するために行レベル存続時間（TTL）を提供します (実験的)。
• TiCDC は、Amazon S3、Azure Blob Storage、NFS (実験的) など変更ログをオブジェクトstorageに複製するサポートしています。

新機能

SQL

• TiDBのインデックス追加のパフォーマンスは約10倍向上します（GA） ＃35983 @ ベンジャミン2037 @ 接線

  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 @ 定義2014 @ bb7133 @ Jmポテト @ コナー1996 @ HuSharp @ カルビンネオを使用して、クラスターを特定の時点に復元する機能をサポートします。

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

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

• INSERT UPDATE含む非トランザクションDMLステートメントDELETE ＃33485にサポートしエキシウム REPLACE

  大規模データ処理のシナリオでは、大規模なトランザクションを含む単一の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 @ ゲンリキ

  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パフォーマンスを迅速に回復できます。この機能により、実行プラン変更の問題への対応プロセスが簡素化され、メンテナンス効率が向上します。

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

Security

• パスワードの複雑さのポリシー＃38928 @ Cbcウェストウルフをサポートする

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

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

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

• パスワード有効期限ポリシー＃38936 @ Cbcウェストウルフをサポート

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

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

• パスワード再利用ポリシー＃38937 @ キープラーニング20221をサポートする

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

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

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

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

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

可観測性

• TiDBダッシュボードはKubernetes上に独立したPod ＃1447 @ サバピンとしてデプロイできます

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

  TiDB ダッシュボードを個別に展開すると、次の利点が得られます。

  • TiDBダッシュボードの計算処理はPDノードに負担をかけません。これにより、より安定したクラスター運用が実現します。
  • PD ノードが利用できない場合でも、ユーザーは診断のために TiDB ダッシュボードにアクセスできます。
  • インターネット経由でTiDBダッシュボードにアクセスする場合、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 @ グオシャオゲ @ 時間と運命 @ ハイランフーで接続された式をサポートします

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

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

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

  • ->
  • ->>
  • JSON_EXTRACT()

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

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

  • regexp_like
  • regexp_instr
  • regexp_substr

• ビュー ＃37887 @ 思い出させるで実行プラン生成に干渉するグローバルオプティマイザヒントをサポートします

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

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

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

  パーティションテーブル機能は 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 は適切なstorageエンジンを自動的に選択し、手動による介入を大幅に削減します。一定期間の実環境テストを経て、このモデルは v6.5.0 で一般提供となります。v6.5.0 以降、新規に作成されたクラスターはデフォルトでコストモデル バージョン 2 を使用します。v6.5.0 にアップグレードするクラスターでは、コストモデル バージョン 2 によってクエリプランが変更される可能性があるため、十分なパフォーマンステストを行った後、 tidb_cost_model_version = 2変数を設定して新しいコストモデルを使用するように設定できます。

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

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

• TiFlashはテーブル行数＃37165 @ エルサ0520を取得する操作を最適化します

  データ分析のシナリオでは、フィルター条件なしで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出力＃5926 @ ホンユニャンのTiFlash TableFullScan演算子の実行情報を精緻化する

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

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

• JSON形式での実行プランの出力をサポート＃39261 @ fzzf678

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

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

MySQLの互換性

• 高性能かつグローバルに単調なAUTO_INCREMENT列属性 (GA) ＃38442 @ 天菜麻緒をサポート

  TiDBはv6.4.0以降、実験的機能としてMySQL互換モードAUTO_INCREMENT導入しました。このモードでは、すべてのTiDBインスタンスでIDが単調に増加するようにする、集中型の自動インクリメントID割り当てサービスが導入されます。この機能により、自動インクリメント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 @ リチュンジュ

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

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

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

• binlog解析機能を＃924 @ gmhdbjdで最適化

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

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

• TiDB LightningのディスククォータはGA ＃446 @ ブチュイトデゴウです

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

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

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

• DMにおける継続的なデータ検証はGA ＃4426 @ D3ハンターです

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

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

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

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

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

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

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

• TiCDCは2つのクラスタ間の双方向レプリケーションをサポートします＃38587 @ ションジウェイ @ アズドンメン

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

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

• TiCDCはTLSオンライン＃7908 @ チャールズ・チャン96の更新をサポート

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

• TiCDCのパフォーマンスが大幅に向上＃7540 ＃7478 ＃7532 @ スドジ @ 3エースショーハンド

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

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

バックアップと復元

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

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

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

• PITRのパフォーマンスはジョッカウで著しく向上しました

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

• TiKV- BR GA: RawKV ＃67 @ ピンギュ @ ハオジンミンのバックアップと復元をサポート

  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メカニズムは非推奨となり、 メタデータロックに置き換えられます。

改善点

• ティドブ

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

• TiKV

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

• PD

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

• TiFlash

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

• ツール

  • TiDBダッシュボード

    • 低速クエリページに 3 つの新しいフィールドを追加します:「準備済みですか?」、「プランはキャッシュからですか?」、「プランはバインディングからですか?」 ＃1451 @ シュギット

  • バックアップと復元 (BR)

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

  • TiCDC

    • Kafka プロトコルエンコーダー＃7540 ＃7532 ＃7543 @ 3エースショーハンド @ スドジのパフォーマンスを向上

  • TiDB データ移行 (DM)

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

バグ修正

• ティドブ

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

• TiKV

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

• PD

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

• TiFlash

  • TiFlash ＃6159 @ リデジュを再起動した後、デルタレイヤーの列ファイルを圧縮できない問題を修正しました。
  • TiFlashファイルオープンOPSが＃6345 @ ジェイソン・ファンで高すぎる問題を修正

• ツール

  • バックアップと復元 (BR)

    • BRがログバックアップデータを削除するときに、削除されるべきでないデータを誤って削除してしまう問題を修正＃38939 @ リーヴルス
    • データベースまたはテーブル＃39150 @ モクイシュル28の照合に古いフレームワークを使用すると復元タスクが失敗する問題を修正しました
    • Alibaba CloudとHuawei CloudがAmazon S3storage＃39545 @ 3ポイントシュートと完全に互換性がないため、バックアップが失敗する問題を修正

  • TiCDC

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

  • TiDB データ移行 (DM)

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

  • TiDB Lightning

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

寄稿者

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

• e1ijah1
• 国翔CN (初回投稿者)
• 嘉陽鄭
• ジフハスト
• マイクチェンウェイ
• ピンアンドビー
• サシャシュラ
• ソースリウ
• wxbty