TiDB 8.0.0 リリースノート

発売日：2024年3月29日

TiDB バージョン: 8.0.0

クイックアクセス: クイックスタート

バージョン8.0.0では、以下の主要な機能と改善点が導入されています。

機能の詳細

拡張性

• PDはマイクロサービスモードをサポートしています（実験的） #5766 @binshi-bing

  バージョン8.0.0以降、PDはマイクロサービスモードをサポートしています。このモードでは、PDのタイムスタンプ割り当て機能とクラスタスケジューリング関数を個別のマイクロサービスに分割し、それぞれを独立してデプロイできるため、PDのパフォーマンス拡張性が向上し、大規模クラスタにおけるPDのパフォーマンスボトルネックが解消されます。

  • tsoマイクロサービス: クラスター全体に単調増加するタイムスタンプ割り当てを提供します。
  • schedulingマイクロサービス: 負荷分散、ホットスポット処理、レプリカ修復、レプリカ配置などを含むがこれらに限定されない、クラスタ全体のスケジューリング関数を提供します。

  各マイクロサービスは独立したプロセスとしてデプロイされます。マイクロサービスに複数のレプリカを設定すると、マイクロサービスは自動的にプライマリ/セカンダリのフォールトトレラントモードを実装し、サービスの高い可用性と信頼性を確保します。

  現在、PDマイクロサービスはTiDB Operatorを使用してのみデプロイできます。PDがスケールアップでは解決できないほどの深刻なパフォーマンスボトルネックとなった場合は、このモードを検討することをお勧めします。

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

• Titan エンジンの使いやすさを向上 #16245 @Connor1996

  • Titan blob ファイルと RocksDB ブロックファイルの共有キャッシュをデフォルトで有効にします ( shared-blob-cacheデフォルト値はtrueです)。これにより、blob-cache-size個別に設定する必要がなくなります。
  • Titanエンジンを使用する際のパフォーマンスと柔軟性を向上させるため、 min-blob-size 、 blob-file-compression 、 discardable-ratioを動的に変更することをサポートします。

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

パフォーマンス

• BRによりスナップショットの復元速度が向上 (GA) #50701 @3pointer@Leavrth

  TiDB v8.0.0以降、スナップショット復元速度の高速化が一般提供（GA）となり、デフォルトで有効になっています。BRは、粗粒度リージョン分散アルゴリズムの採用、データベースとテーブルのバッチ作成、SSTファイルダウンロードと取り込み操作間の相互影響の低減、テーブル統計情報の復元の高速化など、さまざまな最適化を実装することで、スナップショット復元速度を大幅に向上させています。実際のケースでのテスト結果によると、単一のTiKVノードのデータ復元速度は1.2 GiB/sで安定し、100 TiBのデータを1時間以内に復元できます。

  これは、高負荷環境でもBRが各 TiKVノードのリソースを最大限に活用し、データベースの復元時間を大幅に短縮し、データベースの可用性と信頼性を向上させ、データ損失やシステム障害によるダウンタイムやビジネス損失を削減できることを意味します。復元速度の向上は、多数のゴルーチンの並列実行によるものであり、特にテーブルやリージョンが多い場合は、メモリ消費量が大幅に増加する可能性があることに注意してください。BRを実行するには、メモリ容量の大きいマシンを使用することをお勧めします。マシンのメモリ容量が限られている場合は、よりきめ細かいリージョン分散アルゴリズムを使用することをお勧めします。また、粗い粒度のリージョン分散アルゴリズムは外部storageの帯域幅を大量に消費する可能性があるため、外部帯域幅不足による他のアプリケーションへの影響を避ける必要があります。

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

• TiFlashへの以下の関数のプッシュダウンをサポート#50975 #50485 @yibin87 @windtalker

  • CAST(DECIMAL AS DOUBLE)
  • POWER()

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

• TiDB の並列 HashAgg アルゴリズムはディスク スピルをサポートします (実験的) #35637 @xzhangxian1008

  TiDBの以前のバージョンでは、HashAgg演算子の並行処理アルゴリズムはディスクスピルをサポートしていませんでした。SQL文の実行プランに並列HashAgg演算子が含まれている場合、そのSQL文のすべてのデータはメモリ内でしか処理できません。そのため、TiDBは大量のデータをメモリ内で処理する必要があります。データサイズがメモリ制限を超えると、TiDBは並列処理を行わないアルゴリズムしか選択できず、パフォーマンス向上のための並行処理を活用できません。

  バージョン 8.0.0 では、TiDB の並列 HashAgg アルゴリズムがディスク スピルをサポートしています。並列処理のあらゆる状況において、HashAgg オペレータはメモリ使用量に基づいてデータ スピルを自動的にトリガーし、パフォーマンスとデータ スループットのバランスを取ることができます。現在、実験的機能として、TiDB はディスク スピルをサポートする並列 HashAgg アルゴリズムを有効にするかどうかを制御するtidb_enable_parallel_hashagg_spill変数を導入しています。この変数がONの場合、有効になっていることを意味します。この機能が将来のリリースで一般提供されるようになった後、この変数は非推奨となります。

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

• 自動統計収集の優先キューを導入 #50132 @Rustin170506

  オプティマイザ統計を最新の状態に保つことは、データベースのパフォーマンスを安定させる鍵となります。ほとんどのユーザーは、最新の統計情報を収集するために、TiDB が提供する自動統計収集機能を利用しています。自動統計収集機能は、すべてのオブジェクトの統計ステータスをチェックし、異常なオブジェクトをキューに追加して順次収集します。以前のバージョンでは、この順序がランダムであったため、より適切な候補が更新されるまで過剰な待ち時間が発生し、パフォーマンスの低下につながる可能性がありました。

  バージョン8.0.0以降、自動統計収集機能は、さまざまな条件に基づいてオブジェクトの優先順位を動的に設定し、新規作成されたインデックスや定義変更のあるパーティションテーブルなど、より優先度の高い候補が優先的に処理されるようにします。さらに、TiDBは健全性スコアの低いテーブルを優先し、キューの最上位に配置します。この機能強化により、収集順序がより合理的になり、古い統計情報によって引き起こされるパフォーマンスの問題が軽減されるため、データベースの安定性が向上します。

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

• 実行プランのキャッシュに関するいくつかの制限を削除 #49161 @mjonss@qw4990

  TiDBはプランキャッシュキャッシュをサポートしており、OLTPシステムのレイテンシーを効果的に削減し、パフォーマンス向上に重要な役割を果たします。バージョン8.0.0では、TiDBはプランキャッシュに関するいくつかの制限を撤廃しました。以下の項目を含む実行プランをキャッシュできるようになりました。

  • パーティションテーブル
  • 生成された列(生成された列に依存するオブジェクト ( 多値インデックスなど) を含む)

  この機能強化により、プランキャッシュのユースケースが拡張され、複雑なシナリオにおけるデータベース全体のパフォーマンスが向上します。

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

• オプティマイザーが多値インデックスのサポートを強化#47759 #46539 @Arenatlx@time-and-fate

  TiDB v6.6.0 では複数値インデックスが導入され、JSON データ型のクエリ パフォーマンスが向上しました。v8.0.0 では、オプティマイザがマルチ値インデックスのサポートを強化し、複雑なシナリオでクエリを最適化するために、それらを正しく識別して利用できるようになりました。

  • オプティマイザは、複数値インデックスに関する統計情報を収集し、その統計情報に基づいて実行プランを決定します。SQL文で複数の複数値インデックスを選択できる場合、オプティマイザはコストが最も低いインデックスを特定できます。
  • ORを使用して複数のmember of条件を接続する場合、オプティマイザは各 DNF 項目 ( member of条件) に対して有効なインデックス部分パスを照合し、これらのパスを Union を使用して結合してIndex Mergeを形成できます。これにより、条件フィルタリングとデータ取得の効率が向上します。

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

• 低精度 TSO #51081 @Temaの更新間隔の構成をサポート

  TiDBの低精度TSO機能定期的に更新されるTSOをトランザクションのタイムスタンプとして使用します。古いデータの読み取りが許容されるシナリオでは、この機能はリアルタイム性能を犠牲にすることで、小規模な読み取り専用トランザクションのTSO取得のオーバーヘッドを削減し、高並行読み取りの能力を向上させます。

  バージョン8.0.0より前は、低精度TSO機能のTSO更新間隔は固定されており、実際のアプリケーション要件に応じて調整できませんでした。バージョン8.0.0では、TiDBはTSO更新間隔を制御するためのシステム変数tidb_low_resolution_tso_update_intervalを導入しました。この機能は、低精度TSO機能が有効になっている場合にのみ有効です。

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

可用性

• プロキシコンポーネントTiProxyが一般提供開始（GA）になりました #413 @djshow832 @xhebox

  TiDB v7.6.0では、実験的機能としてプロキシコンポーネントTiProxyが導入されました。TiProxyはTiDBの公式プロキシコンポーネントであり、クライアントとTiDBサーバーの間に配置されます。TiProxyはTiDBの負荷分散と接続維持関数を提供し、TiDBクラスタのワークロードをよりバランス良く分散させ、メンテナンス作業中のデータベースへのユーザーアクセスに影響を与えないようにします。

  バージョン8.0.0では、TiProxyが一般提供開始となり、署名証明書の自動生成機能と監視関数が強化されました。

  TiProxyの利用シナリオは以下のとおりです。

  • TiDBクラスタにおけるローリング再起動、ローリングアップグレード、スケールインなどのメンテナンス作業中、TiDBサーバーに変更が発生すると、クライアントとTiDBサーバー間の接続が中断されます。TiProxyを使用することで、これらのメンテナンス作業中に接続を他のTiDBサーバーにスムーズに移行できるため、クライアントへの影響を最小限に抑えることができます。
  • TiDBサーバーへのクライアント接続を、他のTiDBサーバーに動的に移行することはできません。複数のTiDBサーバーのワークロードが不均衡になると、クラスタ全体のリソースは十分であっても、特定のTiDBサーバーでリソース枯渇が発生し、レイテンシーが大幅に増加する可能性があります。この問題を解決するために、TiProxyは接続の動的移行機能を提供します。これにより、クライアントに影響を与えることなく、接続をあるTiDBサーバーから別のTiDBサーバーに移行できるため、TiDBクラスタの負荷分散が実現されます。

  TiProxyはTiUP、 TiDB Operator、およびTiDB Dashboardに統合されているため、設定、デプロイ、およびメンテナンスが容易です。

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

SQL

• 大量のデータを処理するための新しいDMLタイプをサポート（実験的） #50215 @ekexium

  バージョン8.0.0より前のTiDBでは、トランザクションデータをコミットする前にすべてメモリに格納していました。大量のデータを処理する場合、トランザクションに必要なメモリがボトルネックとなり、TiDBが処理できるトランザクションサイズが制限されていました。TiDBは、SQL文を分割することでトランザクションサイズの制限を解消しようと、非トランザクションDMLを導入しましたが、この機能には様々な制限があり、実際のシナリオでは理想的なエクスペリエンスを提供できませんでした。

  バージョン 8.0.0 以降、TiDB は大量のデータを処理するための DML タイプをサポートしています。この DML タイプは、実行中にデータを TiKV にタイムリーに書き込み、すべてのトランザクション データをメモリに継続的にstorageことを回避し、メモリ制限を超える大量のデータの処理をサポートします。この DML タイプはトランザクションの整合性を保証し、標準 DML と同じ構文を使用します。 INSERT 、 UPDATE 、 REPLACE 、およびDELETEステートメントは、この新しい DML タイプを使用して大規模な DML 操作を実行できます。

  この DML タイプはパイプラインDML機能によって実装され、自動コミットが有効になっているステートメントでのみ有効になります。この DML タイプを有効にするかどうかは、システム変数tidb_dml_type設定することで制御できます。

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

• テーブル作成時に一部の式を使用してデフォルトの列値を設定できるようにサポート（実験的） #50936 @zimulala

  バージョン8.0.0より前は、テーブルを作成する際に、列のデフォルト値は文字列、数値、日付に限定されていました。バージョン8.0.0以降では、いくつかの式を列のデフォルト値として使用できます。たとえば、列のデフォルト値をUUID()に設定できます。この機能により、より多様な要件に対応できます。

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

• div_precision_incrementシステム変数 #51501をサポートします @yibin87

  MySQL 8.0 では、 div_precision_increment演算子を使用して実行される除算演算の結果の桁数を増やすことを指定する変数/がサポートされています。v8.0.0 より前の TiDB ではこの変数はサポートされておらず、除算は 4 桁の小数点以下で実行されます。v8.0.0 以降では、TiDB はこの変数をサポートしています。除算演算の結果の桁数を増やすことを必要に応じて指定できます。

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

データベース操作

• PITR は Amazon S3 オブジェクト ロック #51184 @RidRisRをサポートします

  Amazon S3 オブジェクトロックを使用すると、指定された保持期間中にバックアップデータが誤ってまたは意図的に削除されるのを防ぎ、データのセキュリティと整合性を強化できます。バージョン 6.3.0 以降、 BR はスナップショットバックアップで Amazon S3 オブジェクトロックをサポートし、フルバックアップにセキュリティレイヤーを追加します。バージョン 8.0.0 以降、PITR も Amazon S3 オブジェクトロックをサポートします。フルバックアップでもログデータバックアップでも、オブジェクトロック機能はより信頼性の高いデータ保護を保証し、データバックアップとリカバリのセキュリティをさらに強化し、規制要件を満たします。

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

• セッションレベルで非表示のインデックスを可視化する機能のサポート #50653 @hawkingrei

  デフォルトでは、オプティマイザは目に見えないインデックス表示 を選択しません。このメカニズムは通常、インデックスを削除するかどうかを評価するために使用されます。インデックスを削除した場合のパフォーマンスへの影響が不明な場合は、インデックスを一時的に非表示に設定し、必要に応じてすぐに表示に戻すことができます。

  バージョン8.0.0以降では、セッションレベルのシステム変数tidb_opt_use_invisible_indexes ONに設定することで、現在のセッションで非表示インデックスを認識させることができます。この機能を使用すると、新しいインデックスを作成し、最初にインデックスを可視化してから、現在のセッションのシステム変数を変更してテストすることで、他のセッションに影響を与えることなくパフォーマンスをテストできます。この改善により、SQLチューニングの安全性が向上し、本番データベースの安定性も向上します。

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

• 一般ログの別ファイルへの書き込みをサポート #51248 @Defined2014

  一般ログは、MySQL互換の機能で、実行されたすべてのSQLステートメントをログに記録し、問題の診断に役立ちます。TiDBもこの機能をサポートしています。変数tidb_general_log設定することで有効にできます。ただし、以前のバージョンでは、一般ログの内容は他の情報とともにTiDBインスタンスログにしか書き込まれず、ログを長期間保持する必要があるユーザーにとっては不便でした。

  バージョン8.0.0以降では、設定項目log.general-log-fileに有効なファイル名を設定することで、一般ログを指定したファイルに書き込むことができます。一般ログは、インスタンスログと同じローテーションおよび保持ポリシーに従います。

  さらに、履歴ログファイルが占めるディスク容量を削減するため、TiDB v8.0.0 ではネイティブのログ圧縮オプションが導入されました。設定項目log.file.compression gzipに設定すると、ローテーションされたログがgzip形式で自動的に圧縮されます。

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

可観測性

• 監視インデックスの使用統計をサポートする #49830 @YangKeao

  適切なインデックス設計は、データベースのパフォーマンスを維持するための重要な前提条件です。TiDB v8.0.0 では、現在の TiDB ノード上のすべてのインデックスの統計情報を記録するINFORMATION_SCHEMA.TIDB_INDEX_USAGEテーブルが導入されました。このテーブルには、以下の情報が含まれます。

  • インデックスをスキャンするステートメントの累積実行回数
  • インデックスにアクセスした際にスキャンされた行の総数
  • インデックスをスキャンしたときの選択性分布
  • インデックスへの最終アクセス時刻

  この情報を用いることで、オプティマイザで使用されていないインデックスや選択性の低いインデックスを特定し、インデックス設計を最適化することでデータベースのパフォーマンスを向上させることができます。

  さらに、TiDB v8.0.0 では MySQL と互換性のあるビューsys.schema_unused_indexesが導入されました。このビューには、TiDB インスタンスの最後の起動以降に使用されていないインデックスが表示されます。v8.0.0 より前のバージョンからアップグレードされたクラスタの場合、 sysスキーマとビューは自動的に作成されませんsys.schema_unused_indexesを参照して手動で作成できます。

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

Security

• TiKV 保存時の暗号化は Google キー管理サービス（クラウドKMS）をサポートします (実験的) #8906 @glorv

  TiKVは、保存データの暗号化技術を用いてデータのセキュリティを確保します。セキュリティのための保存データ暗号化の中核となるのは鍵管理です。バージョン8.0.0以降では、Google Cloud KMSを使用してTiKVのマスターキーを管理し、Cloud KMSに基づいた保存データ暗号化機能を確立することで、ユーザーデータのセキュリティを強化できます。

  Google Cloud KMS に基づく保存時の暗号化を有効にするには、Google Cloud でキーを作成し、TiKV 構成ファイルの[security.encryption.master-key]セクションを構成する必要があります。

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

• TiDBログの非機密化機能を強化する #51306 @xhebox

  TiDBログの機密性低減機能の強化は、ログファイル内のSQLテキスト情報をマークすることで、ユーザーがログを表示する際に機密データを安全に表示できるようにするものです。ログ情報の機密性低減を制御できるため、さまざまなシナリオでTiDBログを安全に使用でき、ログの機密性低減のセキュリティと柔軟性が向上します。この機能を使用するには、システム変数tidb_redact_logをMARKERに設定します。これにより、TiDBログ内のSQLテキストがマークされます。ログを表示すると、機密データはマーカーに基づいて安全に表示され、ログ情報が保護されます。

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

データ移行

• TiCDC は、Simple プロトコル #9898 @3AceShowHandのサポートを追加します

  TiCDCは、新しいプロトコルであるSimpleプロトコルを導入しました。このプロトコルは、DDLおよびBOOTSTRAPイベントにテーブルスキーマ情報を埋め込むことで、インバンドスキーマ追跡機能を提供します。

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

• TiCDC が Debezium 形式プロトコルのサポートを追加 #1799 @breezewish

  TiCDCは、Debeziumスタイルの形式でイベントメッセージを生成するプロトコルを使用して、データ変更イベントをKafkaシンクに発行できるようになりました。これにより、現在Debeziumを使用してMySQLからデータを取得し、下流処理に利用しているユーザーにとって、MySQLからTiDBへの移行が簡素化されます。

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

• DMは、ソースデータベースとターゲットデータベースのパスワードを暗号化および復号化するために、ユーザーが提供する秘密鍵の使用をサポートします #9492 @D3Hunter

  以前のバージョンでは、DMはセキュリティレベルが比較的低い固定の秘密鍵を内蔵していました。バージョン8.0.0以降では、アップストリームおよびダウンストリームデータベースのパスワードの暗号化と復号化に使用する秘密鍵ファイルをアップロードして指定できるようになりました。さらに、必要に応じて秘密鍵ファイルを置き換えることで、データセキュリティを強化できます。

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

• IMPORT INTO ... FROM SELECTの機能を拡張するためにIMPORT INTO構文をサポートします (実験的) #49883 @D3Hunter

  以前の TiDB バージョンでは、クエリ結果をターゲット テーブルにインポートするにはINSERT INTO ... SELECTステートメントを使用するしかなく、大規模なデータセットのシナリオでは効率が悪かった。v8.0.0 以降では、TiDB でIMPORT INTO ... FROM SELECTを使用してSELECTクエリの結果を空の TiDB ターゲット テーブルにインポートできるようになり、 INSERT INTO ... SELECTの最大 8 倍のパフォーマンスを実現し、インポート時間を大幅に短縮できる。

  さらに、 IMPORT INTO ... FROM SELECTを使用して、 AS OF TIMESTAMPでクエリされた履歴データをインポートできます。

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

• TiDB Lightning は競合解決戦略を簡素化し、 replace戦略を使用した競合データの処理をサポートします (実験的) #51036 @lyzx2001

  以前のバージョンでは、 TiDB Lightning には論理インポート モード用のデータ競合解決戦略と物理インポート モード用の2つのデータ競合解決戦略ありましたが、これらは理解して設定するのが簡単ではありませんでした。

  バージョン 8.0.0 以降、 TiDB Lightning は旧バージョンの競合検出物理インポートモードの戦略を非推奨とし、 conflict.strategyパラメータを使用して論理インポートモードと物理インポートモードの両方の競合検出戦略を制御できるようにし、このパラメータの設定を簡素化しました。さらに、物理インポートモードでは、 replace戦略が、インポート時に主キーまたは一意キーの競合があるデータが検出された場合、最新のデータを保持して古いデータを上書きすることをサポートするようになりました。

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

• グローバルソートが一般提供開始（GA）となり、 IMPORT INTOのパフォーマンスと安定性が大幅に向上しました #45719 @lance6716

  バージョン7.4.0より前では、分散実行フレームワーク（DXF）を使用してIMPORT INTOタスクを実行すると、ローカルstorage容量が限られているため、TiDBはデータの一部をローカルでソートしてからTiKVにインポートしていました。このため、TiKVにインポートされたデータにかなりの重複が生じ、インポート中にTiKVが追加の圧縮操作を実行する必要が生じ、TiKVのパフォーマンスと安定性に影響が出ていました。

  v7.4.0 で導入された実験的機能であるグローバル ソートを使用すると、TiDB はインポートするデータを TiKV にインポートする前に、グローバル ソートのために一時的に外部storage(Amazon S3 など) に保存できます。これにより、インポート中の TiKV 圧縮操作が不要になります。v8.0.0 では、グローバル ソートが GA になります。この機能により、TiKV のリソース消費が削減され、 IMPORT INTOのパフォーマンスと安定性が大幅に向上します。グローバル ソートを有効にすると、各IMPORT INTOタスクは 40 TiB 以内のデータのインポートをサポートします。

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

互換性の変更

注記：

このセクションでは、バージョン7.6.0から最新バージョン（8.0.0）にアップグレードする際に知っておくべき互換性の変更点について説明します。バージョン7.5.0以前のバージョンから最新バージョンにアップグレードする場合は、中間バージョンで導入された互換性の変更点も確認する必要があるかもしれません。

• TiUPによってデフォルトでデプロイされているPrometheusのバージョンを2.27.1から2.49.1にアップグレードします。
• TiUPによってデプロイされたデフォルトのGrafanaバージョンを7.5.11から7.5.17にアップグレードします。
• GAではないがデフォルトで有効になっている証人関連のスケジューラを削除する #7765 @rleungx

行動の変化

• Security強化モード（SEM）でrequire_secure_transport ONに設定することを禁止し、ユーザーの接続に関する潜在的な問題を防止します。 #47665 @tiancaiamao
• DM では、暗号化および復号化用の固定秘密キーが削除され、暗号化および復号化用の秘密キーをカスタマイズできるようになります。アップグレード前にデータソース構成と移行タスクの設定で暗号化されたパスワードが使用されている場合、追加の操作についてはDMの暗号化と復号化のための秘密鍵をカスタマイズするのアップグレード手順を参照する必要があります。 #9492 @D3Hunter
• v8.0.0 より前では、 ADD INDEXおよびCREATE INDEX ( tidb_ddl_enable_fast_reorg = ON ) の高速化を有効にした後、エンコードされたインデックス キーは、下流の TiKV 容量に応じて動的に調整できない固定の同時実行数16で TiKV にデータを取り込みます。v8.0.0 以降では、 tidb_ddl_reorg_worker_cntシステム変数を使用して同時実行数を調整できます。デフォルト値は4です。以前のデフォルト値16と比較すると、新しいデフォルト値では、インデックス付きキーと値のペアを取り込むときのパフォーマンスが低下します。このシステム変数は、クラスターのワークロードに基づいて調整できます。

MySQLとの互換性

• KEYパーティションタイプは、パーティションフィールドのリストが空であるステートメントをサポートしており、これは MySQL の動作と一致しています。

システム変数

コンフィグレーションファイルパラメータ

システムテーブル

• TiDBノード上のインデックス使用統計を記録するために、新しいシステムテーブルINFORMATION_SCHEMA.TIDB_INDEX_USAGEとINFORMATION_SCHEMA.CLUSTER_TIDB_INDEX_USAGEを追加します。
• 新しいシステムスキーマsysと、TiDB の前回の起動以降に使用されていないインデックスを記録する新しいビューsys.schema_unused_indexesを追加します。

非推奨機能

• バージョン8.0.0以降、 tidb_disable_txn_auto_retryシステム変数は非推奨となり、TiDBは楽観的トランザクションの自動再試行をサポートしなくなりました。代替策として、楽観的トランザクションの競合が発生した場合は、エラーを捕捉してアプリケーションでトランザクションを再試行するか、悲観的トランザクションモードを使用してください。
• バージョン8.0.0以降、TiDBはTLSv1.0およびTLSv1.1プロトコルをサポートしなくなりました。TLSをTLSv1.2またはTLSv1.3にアップグレードする必要があります。
• バージョン8.0.0以降、 TiDB Lightningは旧バージョンの競合検出戦略を非推奨とし、 conflict.strategyパラメータを使用して論理インポートモードと物理インポートモードの両方の競合検出戦略を制御できるようにします。旧バージョンの競合検出のduplicate-resolutionパラメータは、今後のリリースで削除されます。
• 今後のリリースでは 実行プランバインディングの自動進化が再設計される予定であり、関連する変数や動作が変更される予定です。

改善点

• TiDB

  • CREATE TABLE DDL ステートメントの実行パフォーマンスを 10 倍向上させ、線形スケーラビリティをサポート #50052 @GMHDBJD
  • 16個のIMPORT INTO ... FROM FILEタスクを同時に送信することをサポートし、ターゲットテーブルへの大量データインポートを容易にし、データファイルのインポートの効率とパフォーマンスを大幅に向上させます #49008 @D3Hunter
  • Sortオペレーターのディスクへのデータスピル処理のパフォーマンスを改善 #47733 @xzhangxian1008
  • ディスクへのデータ流出中にクエリをキャンセルする機能をサポートし、データ流出機能の終了メカニズムを最適化します #50511 @wshwsh12
  • 複数の等しい条件を持つテーブル結合クエリを処理する際に、部分条件に一致するインデックスを使用してインデックス結合を構築することをサポートする #47233 @winoros
  • クエリ内のソート要件を識別し、ソート要件を満たすインデックスを選択するインデックスマージ機能を強化します #48359 @AilinKid
  • Apply演算子が同時に実行されない場合、TiDB ではSHOW WARNINGS実行することで、同時実行をブロックしている演算子の名前を表示できます。 #50256 @hawkingrei
  • point getクエリがすべてのインデックスでサポートされている場合に、クエリに最適なインデックスを選択することでpoint getクエリのインデックス選択を最適化します。 #50184 @elsa0520
  • TiKVの負荷が高い時に広範囲にわたるタイムアウトが発生するのを避けるため、統計情報を同期的にロードするタスクの優先度を一時的に「高」に調整します。タイムアウトが発生すると、統計情報がロードされない可能性があります。 #50332 @winoros
  • PREPAREステートメントが実行プランキャッシュにヒットしなかった場合、TiDB ではSHOW WARNINGSを実行することで理由を確認できます。 #50407 @hawkingrei
  • 同じデータ行が複数回更新された場合のクエリ推定情報の精度を向上させる #47523 @terry1purcell
  • インデックスマージは、 OR述語への複数値インデックスとAND演算子の埋め込みをサポートします #51778 @time-and-fate
  • force-init-stats trueに設定すると、TiDB は TiDB 起動中にサービスを提供する前に統計情報の初期化が完了するまで待機します。この設定により HTTP サーバーの起動がブロックされなくなり、ユーザーは引き続き監視できるようになります #50854 @hawkingrei
  • MemoryTrackerはIndexLookup演算子 #45901 @solotzgのメモリ使用量を追跡できます
  • MemoryTracker はMemTableReaderExecオペレーター #51456 @wshwsh12のメモリ使用量を追跡できます
  • 大規模テーブルをクエリする際に、PD からリージョンをバッチでロードして KV 範囲からリージョンへの変換プロセスを高速化するサポート #51326 @SeaRise
  • システムテーブルINFORMATION_SCHEMA.TABLES 、 INFORMATION_SCHEMA.STATISTICS 、 INFORMATION_SCHEMA.KEY_COLUMN_USAGE 、およびINFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTSパフォーマンスを最適化しました。以前のバージョンと比較して、パフォーマンスが最大 100 倍向上しています。 #50305 @ywqzzy

• TiKV

  • 構成や操作が不適切な場合のクラスタTSOの堅牢性を向上させるため、TSOの検証と検出機能を強化する #16545 @cfzjywxk
  • 未コミットトランザクションの処理パフォーマンスを向上させるため、悲観的ロックのクリーンアップロジックを最適化する #16158 @cfzjywxk
  • TiKV の統一ヘルス制御を導入し、異常な単一の TiKV ノードがクラスタ アクセス パフォーマンスに与える影響を軽減します。この最適化は、 tikv-client.enable-replica-selector-v2をfalseに設定することで無効にできます。 #16297 #1104 #1167 @MyonKeminta@zyguan@crazycs520
  • PDクライアントはメタデータstorageインターフェースを使用して、以前のグローバル構成インターフェースを置き換えます #14484 @HuSharp
  • cf stats の書き込みによるデータ読み込み動作の判定により、スキャン性能を向上させる #16245 @Connor1996
  • Raft設定変更プロセス中にノードが削除され、投票者が降格された最新のハートビートをチェックして、この動作によってリージョンにアクセスできなくなることがないようにしてください #15799 @tonyxuqqi
  • パイプラインDML用のFlushおよびBufferBatchGetインターフェースを追加 #16291 @ekexium
  • cgroupのCPUとメモリ制限の監視とアラート機能を追加 #16392 @pingandb
  • リージョンワーカーとスナップショット生成ワーカーのCPU監視機能を追加 #16562 @Connor1996
  • ピアおよびストアメッセージの低速ログを追加 #16600 @Connor1996

• PD

  • PD クライアントのサービス検出機能を強化して、高可用性と負荷分散を向上させます #7576 @CabinfeverB
  • PDクライアントの再試行メカニズムを強化する #7673 @JmPotato
  • cgroupのCPUとメモリ制限の監視とアラート機能を追加#7716 #7918 @pingandb @rleungx
  • etcd ウォッチ使用時のパフォーマンスと高可用性を向上させる#7738 #7724 #7689 @lhy1024
  • パフォーマンスのボトルネックをより適切に分析するために、ハートビートの監視メトリクスを追加します #7868 @nolouch
  • etcdリーダーがPDリーダーに与える影響を軽減する #7499 @JmPotato @HuSharp
  • 異常な etcd ノードの検出メカニズムを強化する #7730 @JmPotato @HuSharp
  • pd-ctlのGCセーフポイントの出力を最適化する #7767 @nolouch
  • ホットスポットスケジューラにおける履歴ウィンドウ構成の動的な変更をサポートする #7877 @lhy1024
  • オペレーター作成時のロック競合問題を軽減する #7837 @Leavrth
  • 可用性を向上させるためにGRPC構成を調整 #7821 @rleungx

• TiFlash

  • json_path関数のJSON_EXTRACT()引数に非定数値を使用することをサポートする #8510 @SeaRise
  • JSON_LENGTH(json, path)機能 #8711シーライズをサポートします

• ツール

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

    • --load-stats br } を導入します。 #50568 @Leavrth
    • --tikv-max-restore-concurrencyコマンドラインツールに、新しい復元パラメータ { br } を導入します。このパラメータは、各 TiKV ノードのダウンロードおよび取り込みファイルの最大数を制御します。また、ジョブキューの最大長を制御することで、 BRノードのメモリ消費量も制御します。 #51621 @3pointerシュート
    • 粒度の粗いリージョン分散アルゴリズムを有効にして同時パラメータを適応的に取得できるようにすることで、復元パフォーマンスを向上させます #50701 @3pointer
    • logのコマンドラインヘルプ情報にbrコマンドを表示する #50927 @RidRisR
    • テーブルIDの再利用を最大化し、リストアパフォーマンスを向上させるため、リストアプロセス中にテーブルIDを事前割り当てする機能をサポートする #51736 @Leavrth
    • BR使用時にTiDB内のGCメモリ制限チューナー機能を無効にしてOOM問題を回避する #51078 @Leavrth
    • データ復元時のSSTファイルのマージ速度を、より効率的なアルゴリズムを使用して改善する #50613 @Leavrth
    • データ復元時にデータベースをバッチ処理で作成する機能をサポート #50767 @Leavrth
    • ログバックアップ中に、グローバルチェックポイントの進行に影響を与える最も遅いリージョンの情報をログとメトリクスに出力する #51046 @YuJuncen
    • 大規模データセットのシナリオにおけるRESTOREステートメントのテーブル作成パフォーマンスを改善 #48301 @Leavrth

  • TiCDC

    • TiCDCがデータを複製する際のメモリ消費量を削減するために、 RowChangedEventのメモリ消費量を最適化します #10386 @lidezhu
    • チェンジフィードタスクの作成と再開時に start-ts パラメータが有効であることを確認します #10499 @3AceShowHand

  • TiDBデータ移行（DM）

    • MariaDBプライマリ/セカンダリレプリケーションシナリオにおいて、移行パスがMariaDBプライマリインスタンス→MariaDBセカンダリインスタンス→DM→TiDBである場合、 gtid_strict_mode = offかつMariaDBセカンダリインスタンスのGTIDが厳密にインクリメントされていない場合（例えば、MariaDBセカンダリインスタンスへのデータ書き込みがある場合）、DMタスクはless than global checkpoint positionエラーを報告します。v8.0.0以降、TiDBはこのシナリオと互換性があり、データは正常に下流に移行できます。 #10741 @okJiang

  • TiDB Lightning

    • 論理インポートモードでのバッチ内の最大行数の設定をサポートするlogical-import-batch-rows #46607 @kennytm
    • TiDB Lightning はTiFlashの容量が不足している場合にエラーを報告する #50324 @okJiang

バグ修正

• TiDB

  • データ変更がないにもかかわらずauto analyzeが複数回トリガーされる問題を修正 #51775 @Rustin170506
  • auto analyzeの同時実行設定が正しくない問題を修正 #51749 @hawkingrei
  • 単一のSQL文を使用して複数のインデックスを追加した際に発生するインデックスの不整合の問題を修正 #51746 @tangenta
  • クエリでColumn ... in from clause is ambiguousを使用する場合に発生する可能性があるNATURAL JOINエラーを修正 #32044 @AilinKid
  • TiDB がgroup byの定数値を誤って削除したことによる誤ったクエリ結果の問題を修正 #38756 @Rustin170506ラスティン
  • LEADINGヒントがUNION ALLステートメントで有効にならない問題を修正 #50067 @hawkingrei
  • BIT型の列が一部の関数の計算に関与している場合、デコードエラーによりクエリエラーが発生する可能性がある問題を修正しました。 #49566 #50850 #50855 @jiyfhust
  • PDとの相互作用の問題により、 tiup cluster upgrade/startを使用してローリングアップグレードを実行するとTiDBがpanic可能性がある問題を修正しました #50152 @zimulala
  • UNIQUE句を使用してORDER BYインデックス ルックアップを実行するとエラーが発生する可能性がある問題を修正 #49920 @jackysp
  • TiDBがENUMまたはSET型を定数伝播で処理する際に誤ったクエリ結果を返す問題を修正 #49440 @winoros
  • クエリに Apply 演算子が含まれている場合に TiDB がpanicを起こし、 fatal error: concurrent map writesエラーが発生する問題を修正しました #50347 @SeaRise
  • 文字列型の変数に対するSET_VARの制御が無効になる可能性がある問題を修正しました #50507 @qw4990
  • SYSDATE()がtidb_sysdate_is_nowに設定されている場合、 1関数がプランキャッシュ内の時間を誤って使用する問題を修正しました。 #49299 @hawkingrei
  • CREATE GLOBAL BINDINGステートメントを実行する際に、スキーマ名が大文字の場合、バインディングが有効にならない問題を修正しました #50646 @qw4990
  • Index Pathが重複したインデックスを選択する問題を修正 #50496 @AilinKid
  • PLAN REPLAYERステートメントにCREATE GLOBAL BINDINGが含まれている場合IN()がバインディングのロードに失敗する問題を修正 #43192 @King-Dylan
  • 複数のanalyzeタスクが失敗した場合に、失敗理由が正しく記録されない問題を修正します #50481 @Rustin170506
  • tidb_stats_load_sync_waitが有効にならない問題を修正 #50872 @jiyfhust
  • max_execute_time設定が複数のレベルで互いに干渉する問題を修正 #50914 @jiyfhust
  • 統計情報の同時更新によって発生するスレッドセーフティの問題を修正 #50835 @Rustin170506
  • パーティション テーブルでauto analyzeを実行すると TiDB がpanicを引き起こす可能性がある問題を修正 #51187 @Rustin170506
  • SQL文中のIN()に異なる数の値が含まれている場合、SQLバインディングが機能しない可能性がある問題を修正しました #51222 @hawkingrei
  • TiDB が式内のシステム変数の型を正しく変換できない問題を修正 #43527 @Rustin170506
  • force-init-statsが設定されている場合に TiDB が対応するポートをリッスンしない問題を修正 #51473 @hawkingrei
  • determinateモード ( tidb_opt_objective='determinate' ) において、クエリに述語が含まれていない場合、統計情報がロードされない可能性がある問題を修正します #48257 @time-and-fate
  • init-statsプロセスが TiDB をpanic、 load statsプロセスを終了する可能性がある問題を修正しました #51581 @hawkingrei
  • IN()述語にNULLが含まれている場合にクエリ結果が正しくない問題を修正 #51560 @winoros
  • DDLタスクが複数のテーブルに関係する場合、ブロックされたDDLステートメントがMDLビューに表示されない問題を修正します #47743 @wjhuang2016
  • テーブル上のprocessed_rowsタスクのANALYZEが、そのテーブルの総行数を超える可能性がある問題を修正しました #50632 @ホーキングホーキングレイ
  • HashJoin演算子がディスクにスピルしない場合に発生する可能性のあるゴルーチンリークの問題を修正 #50841 @wshwsh12
  • CTEクエリのメモリ使用量が制限を超えた場合に発生するゴルーチンリークの問題を修正 #50337 @guo-shaoge
  • 集計関数をグループ計算に使用した際に発生する可能性のあるCan't find column ...エラーを修正 #50926 @qw4990
  • CREATE TABLEステートメントに特定のパーティションまたは制約が含まれている場合に、テーブル名の変更などの DDL 操作が停止する問題を修正しました #50972 @lcwangchao
  • Grafana の監視メトリックtidb_statistics_auto_analyze_totalが整数として表示されない問題を修正 #51051 @hawkingrei
  • tidb_gogc_tuner_threshold変数が変更された後、 tidb_server_memory_limitシステム変数が適切に調整されない問題を修正 #48180 @hawkingrei
  • クエリに JOIN 操作が含まれる場合にindex out of rangeエラーが発生する可能性がある問題を修正 #42588 @AilinKid
  • 列のデフォルト値が削除されている場合、列のデフォルト値を取得するとエラーが返される問題を修正します#50043 #51324 @crazycs520
  • TiFlash の遅延実体化処理で関連する列が処理されると、間違った結果が返される場合がある問題を修正#49241 #51204 @Lloyd-Pottiger
  • LIKE()関数がバイナリ照合順序入力を処理する際に誤った結果を返す可能性がある問題を修正しました #50393 @yibin87
  • JSON_LENGTH()関数が、2 番目のパラメータがNULLの場合に誤った結果を返す問題を修正しました #50931 @SeaRise
  • CAST(AS DATETIME)が特定の状況下で時間精度を失う可能性がある問題を修正 #49555 @SeaRise
  • テーブルにクラスター化インデックスがある場合、並列処理Applyが誤った結果を生成する可能性がある問題を修正 #51372 @guo-shaoge
  • プライマリキーのタイプがALTER TABLE ... COMPACT TIFLASH REPLICA VARCHARが正しく終了しない可能性がある問題を修正 #51810 @breezewish
  • NULLステートメントを使用してパーティション テーブルを交換する際にDEFAULT NULL属性のEXCHANGE PARTITION値のチェックが正しく行われない問題を修正しました。 #47167 @jiyfhust
  • パーティションテーブルの定義が、UTF8以外の文字セットを使用した場合に誤った動作を引き起こす可能性がある問題を修正しました #49251 @YangKeao
  • 一部のシステム変数について、 INFORMATION_SCHEMA.VARIABLES_INFOテーブルに誤ったデフォルト値が表示される問題を修正しました #49461 @jiyfhust
  • データベース名に空の文字列を使用した場合にエラーが報告されない場合がある問題を修正 #45873 @yoshikipom
  • SPLIT TABLE ... INDEXステートメントにより TiDB がpanicを引き起こす可能性がある問題を修正 #50177 @Defined2014
  • KeyPartitionタイプのパーティションテーブルをクエリするとエラーが発生する可能性がある問題を修正#50206 #51313 #51196 @time-and-fate@jiyfhust@mjonss
  • ハッシュパーティションテーブルをクエリすると誤った結果が生成される可能性がある問題を修正 #50427 @Defined2014
  • opentracing が正しく動作しない問題を修正 #50508 @Defined2014
  • ALTER INSTANCE RELOAD TLSがエラーを報告した際にエラーメッセージが不完全になる問題を修正しました #50699 @dveeden
  • AUTO_INCREMENT属性が自動インクリメントIDを割り当てる際に不要なトランザクション競合を引き起こし、IDが連続しなくなる問題を修正しました #50819 @tiancaiamao
  • TiDBログにおける一部のエラーのスタック情報が不完全な問題を修正 #50849 @tiancaiamao
  • LIMIT句の数値が大きすぎる場合に、一部のクエリでメモリ使用量が過剰になる問題を修正しました #51188 @Defined2014
  • TTL機能によって、場合によってはデータ範囲の分割が正しく行われずデータホットスポットが発生する問題を修正しました #51527 @lcwangchao
  • SETステートメントが明示的トランザクションの最初の行にある場合に有効にならない問題を修正 #51387 @YangKeao
  • BINARYタイプの JSON をクエリすると、場合によってはエラーが発生する問題を修正しました #51547 @YangKeao
  • TTLが有効期限を計算する際に、夏時間調整の移行を正しく処理しない問題を修正 #51675 @lcwangchao
  • SURVIVAL_PREFERENCESステートメントの出力にSHOW CREATE PLACEMENT POLICY属性が特定の条件下で表示されない問題を修正しました #51699 @lcwangchao
  • 設定ファイルに無効な設定項目が含まれている場合に、設定ファイルが有効にならない問題を修正します #51399 @Defined2014

• TiKV

  • tidb_enable_row_level_checksumを有効にするとTiKVがpanicを起こす可能性がある問題を修正しました #16371 @cfzjywxk
  • 例外的な状況で休止状態のリージョンがすぐに起動されない問題を修正 #16368 @LykxSassinator
  • レプリカが1つオフラインになったときにリージョン全体が利用できなくなる問題を修正するため、ノードをオフラインにする前にリージョンのすべてのレプリカの最終ハートビート時間をチェックします #16465 tonyxuqqi
  • TiKV が、最大値INT64より大きく、最大値UINT64より小さい JSON 整数をFLOAT64として解析し、TiDB との不整合を引き起こす問題を修正しました。 #16512 @YangKeao
  • 監視メトリックtikv_unified_read_pool_thread_countにデータがない場合がある問題を修正 #16629 @YuJuncen

• PD

  • MergeLabels関数が呼び出されたときにデータ競合が発生する問題を修正します #7535 @lhy1024
  • evict-leader-schedulerインターフェイスを呼び出したときに出力がない問題を修正 #7672 @CabinfeverB
  • PD監視項目learner-peer-countがリーダー切り替え後に古い値を同期しない問題を修正 #7728 @CabinfeverB
  • watch etcd正しくオフになっていない場合に発生するメモリリークの問題を修正しました #7807 @rleungx
  • 一部の TSO ログでエラー原因 #7496 @CabinfeverBが出力されない問題を修正
  • 再起動後に予期しない負のモニタリング指標が発生する問題を修正 #4489 @lhy1024
  • Leaderのリースがログ時刻よりも後に期限切れになる問題を修正 #7700 @CabinfeverB
  • TiDB (PD クライアント) と PD 間の TLS スイッチが矛盾している場合に TiDB がパニックになる問題を修正#7900 #7902 #7916 @CabinfeverB
  • Goroutine が正しく閉じられなかった場合にメモリリークが発生する問題を修正しました #7782 @HuSharp
  • 特殊文字を含むスケジューラをpd-ctlが削除できない問題を修正 #7798 @JmPotato
  • TSO #7864 @CabinfeverBを取得するときに PD クライアントがブロックされる可能性がある問題を修正

• TiFlash

  • レプリカ移行中にPDとのネットワーク接続が不安定になりTiFlashがpanicになる問題を修正 #8323 @JaySon-Huang
  • クエリの遅延によりメモリ使用量が大幅に増加する問題を修正 #8564 @JinheLin
  • TiFlashレプリカを削除して再追加するとTiFlashでデータ破損が発生する可能性がある問題を修正 #8695 @JaySon-Huang
  • ポイントインタイムリカバリ(PITR) の実行後、またはFLASHBACK CLUSTER TOの実行後にTiFlashレプリカ データが誤って削除され、データ異常が発生する可能性がある問題を修正 #8777 @JaySon-Huang
  • Null 許容カラムを null 許容カラム以外に変更するALTER TABLE ... MODIFY COLUMN ... NOT NULLの実行後にTiFlash がパニックになる問題を修正 #8419 @JaySon-Huang
  • 分散storageとコンピューティングアーキテクチャにおいて、ネットワーク分離後にクエリが永久にブロックされる可能性がある問題を修正 #8806 @JinheLin
  • 分散storageとコンピューティングアーキテクチャにおいて、 TiFlash がシャットダウン中にpanic可能性がある問題を修正 #8837 @JaySon-Huang
  • リモート読み取り時にデータ競合によりTiFlashがクラッシュする可能性がある問題を修正 #8685 @solotzg
  • CAST(AS JSON)関数が JSON オブジェクト キーの重複を削除しない問題を修正 #8712 @SeaRise
  • ENUM列がチャンクエンコード中にTiFlashを引き起こす可能性がある問題を修正しました #8674 @yibin87

• ツール

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

    • リージョンがリーダーになった直後に分割またはマージされると、ログバックアップのチェックポイントが停止する問題を修正 #16469 @YuJuncen
    • 一部の極端なケースでフルバックアップがピアを見つけられなかった際にTiKVがパニックを起こす問題を修正 #16394 @Leavrth
    • 同じノード上の TiKV IP アドレスを変更した後にログのバックアップが停止する問題を修正 #50445 @3pointer
    • S3からファイルコンテンツを読み取る際にエラーが発生した場合にBRが再試行できない問題を修正 #49942 @Leavrth
    • データ復元失敗後にチェックポイントから再開するとエラーthe target cluster is not fresh発生する問題を修正 #50232 @Leavrth
    • ログ バックアップ タスクを停止すると TiDB がクラッシュする問題を修正 #50839 @YuJuncen
    • TiKVノードにリーダーがいないためにデータ復元が遅くなる問題を修正 #50566 @Leavrth
    • --filterオプションを指定した後でも完全復元ではターゲット クラスターが空である必要がある問題を修正 #51009 @3pointer

  • TiCDC

    • storageシンク使用時にstorageサービスによって生成されるファイルシーケンス番号が正しくインクリメントされない可能性がある問題を修正しました #10352 @CharlesCheung96
    • TiCDCが複数のチェンジフィードを同時に作成する際にErrChangeFeedAlreadyExistsエラーを返す問題を修正 #10430 @CharlesCheung96
    • add table partitionでignore-eventイベントをフィルタリングした後、TiCDC が関連パーティションの他のタイプの DML 変更を下流にレプリケートしない問題を修正します。 #10524 @CharlesCheung96
    • アップストリームテーブルでTRUNCATE PARTITIONが実行された後、changefeed がエラーを報告する問題を修正します #10522 @sdojjy
    • 変更フィードを再開する際にsnapshot lost caused by GCが時間内に報告されず、変更フィードのcheckpoint-tsが TiDB の GC セーフポイントより小さい問題を修正します #10463 @sdojjy
    • 単一行データのデータ整合性検証が有効になった後、タイムゾーンの不一致により TiCDC TIMESTAMPタイプのチェックサムを検証できない問題を修正 #10573 @3AceShowHand
    • Syncpoint テーブルが正しく複製されない可能性がある問題を修正しました #10576 @asddongmen
    • Apache Pulsarをダウンストリームとして使用する際に、OAuth2.0、TLS、mTLSが正しく有効化できない問題を修正 #10602 @asddongmen
    • TiKVがアップグレード、再起動、またはリーダーを追放した際に、変更フィードが停止する可能性がある問題を修正しました #10584 @asddongmen
    • DDLステートメントが頻繁に実行されるシナリオで、BarrierTSが間違っているためにデータが間違ったCSVファイルに書き込まれる問題を修正 #10668 @lidezhu
    • KVクライアントでのデータ競合によりTiCDCがpanicを起こす問題を修正 #10718 @asddongmen
    • TiCDCがテーブルレプリケーションタスクのスケジュール時にパニックを起こす問題を修正 #10613 @CharlesCheung96

  • TiDBデータ移行（DM）

    • アップストリームのプライマリキーがバイナリタイプの場合にデータが失われる問題を修正 #10672 @GMHDBJD

  • TiDB Lightning

    • TiKVスペースのチェックによって発生するパフォーマンス低下の問題を修正 #43636 @lance6716
    • TiDB Lightningがファイルスキャン中に無効なシンボリックリンクファイルに遭遇した際にエラーを報告する問題を修正しました #49423 @lance6716
    • 0がNO_ZERO_IN_DATE } に含まれていない場合に、 TiDB Lightning がsql_modeを含む日付値を正しく解析できない問題 #50757 @GMHDBJD

寄稿者

TiDBコミュニティの以下の貢献者の皆様に感謝申し上げます。

• アオアン
• バッファロー
• デーモン365
• エルトシアー
• リチュンジュ
• ジフハスト
• pingandb
• シェンキデバオジ
• スミティーズ
• ソンジビン97
• タンジンユ97
• テーマ
• ub-3
• ヨシキポム