TiDB 8.0.0 リリースノート

発売日: 2024年3月29日

TiDB バージョン: 8.0.0

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

8.0.0 では、次の主要な機能と改善が導入されています。

機能の詳細

スケーラビリティ

• PD はマイクロサービス モード (実験的) ＃5766 @ ビンシビンをサポートします

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

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

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

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

  詳細についてはドキュメンテーション参照してください。

• Titanエンジン＃16245 @ コナー1996の使いやすさを向上

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

  詳細についてはドキュメンテーション参照してください。

パフォーマンス

• BR はスナップショットの復元速度を向上します (GA) ＃50701 @ 3ポインター @ リーヴルス

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

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

  詳細についてはドキュメンテーション参照してください。

• 以下の関数をTiFlash ＃50975 ＃50485 @ いびん87 @ 風の話し手にプッシュダウンすることをサポートします

  • CAST(DECIMAL AS DOUBLE)
  • POWER()

  詳細についてはドキュメンテーション参照してください。

• TiDBの並行HashAggアルゴリズムはディスクスピル（実験的） ＃35637 @ 翻訳者をサポートします

  以前のバージョンの TiDB では、HashAgg 演算子の同時実行アルゴリズムはディスクへの書き込みをサポートしていませんでした。SQL ステートメントの実行プランに同時実行 HashAgg 演算子が含まれている場合、その SQL ステートメントのすべてのデータはメモリ内でのみ処理できます。その結果、TiDB は大量のデータをメモリ内で処理する必要があります。データ サイズがメモリ制限を超えると、TiDB は非同時実行アルゴリズムのみを選択でき、同時実行を利用してパフォーマンスを向上させることはできません。

  v8.0.0 では、TiDB の同時 HashAgg アルゴリズムがディスク スピルをサポートしています。同時実行条件では、HashAgg 演算子はメモリ使用量に基づいてデータ スピルを自動的にトリガーできるため、パフォーマンスとデータ スループットのバランスをとることができます。現在、実験的機能として、TiDB はディスク スピルをサポートする同時 HashAgg アルゴリズムを有効にするかどうかを制御するtidb_enable_concurrent_hashagg_spill変数を導入しています。この変数がONの場合、有効であることを意味します。この変数は、将来のリリースで機能が一般提供された後には非推奨になります。

  詳細についてはドキュメンテーション参照してください。

• 自動統計収集のための優先キューを導入する＃50132 @ ハイラスティン

  オプティマイザ統計を最新の状態に維持することが、データベース パフォーマンスを安定させる鍵です。ほとんどのユーザーは、最新の統計を収集するために TiDB が提供する自動統計収集に依存しています。自動統計収集では、すべてのオブジェクトの統計の状態を確認し、異常なオブジェクトをキューに追加して順次収集します。以前のバージョンでは、順序はランダムであったため、より価値のある候補が更新されるまでの待機時間が長くなり、パフォーマンスが低下する可能性がありました。

  v8.0.0 以降、自動統計収集では、さまざまな条件と組み合わせてオブジェクトの優先順位を動的に設定し、新しく作成されたインデックスや定義が変更されたパーティション テーブルなど、より適切な候補が優先的に処理されるようにします。さらに、TiDB はヘルス スコアが低いテーブルを優先し、キューの先頭に配置します。この機能強化により、収集の順序がより合理的になり、古い統計によって発生するパフォーマンスの問題が軽減されるため、データベースの安定性が向上します。

  詳細についてはドキュメンテーション参照してください。

• 実行プランキャッシュの制限をいくつか削除＃49161 @ ミョンス @ qw4990

  TiDB はプランキャッシュをサポートしており、これは OLTP システムのレイテンシーを効果的に削減でき、パフォーマンスにとって重要です。v8.0.0 では、TiDB はプラン キャッシュに関するいくつかの制限を取り除きました。次の項目を含む実行プランをキャッシュできるようになりました。

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

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

  詳細についてはドキュメンテーション参照してください。

• オプティマイザは複数値インデックスのサポートを強化します＃47759 ＃46539 @ アレナトルクス @ 時間と運命

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

  • オプティマイザは、多値インデックスの統計情報を収集し、その統計を使用して実行プランを決定します。SQL ステートメントで複数の多値インデックスを選択できる場合、オプティマイザはコストの低いインデックスを識別できます。
  • ORを使用して複数のmember of条件を接続する場合、オプティマイザーは各 DNF 項目 ( member of条件) の有効なインデックス部分パスを一致させ、Union を使用してこれらのパスを結合してIndex Mergeを形成できます。これにより、より効率的な条件フィルタリングとデータ フェッチが実現します。

  詳細についてはドキュメンテーション参照してください。

• 低精度TSO ＃51081 @ テーマの更新間隔の設定をサポート

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

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

  詳細についてはドキュメンテーション参照してください。

信頼性

• TiDBサーバーのメモリ消費量を削減するために、LRU アルゴリズムに従って必要なスキーマ情報をキャッシュする機能をサポートします (実験的) ＃50959 @ 翻訳者

  v8.0.0 より前では、各 TiDB ノードはすべてのテーブルのスキーマ情報をキャッシュします。数十万のテーブルがあるシナリオでは、これらのテーブル スキーマをキャッシュするだけで大​​量のメモリが消費される可能性があります。

  v8.0.0 以降、TiDB ではシステム変数tidb_schema_cache_sizeが導入され、スキーマ情報のキャッシュの上限を設定して、過剰なメモリ使用を防ぐことができます。この機能を有効にすると、TiDB は Least Recently Used (LRU) アルゴリズムを使用して必要なテーブルをキャッシュし、スキーマ情報によって消費されるメモリを効果的に削減します。

  詳細についてはドキュメンテーション参照してください。

可用性

• プロキシコンポーネントTiProxyが一般提供（GA）される＃413 @ 翻訳者 @ xhebox

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

  v8.0.0 では、TiProxy が一般提供され、署名証明書の自動生成と監視関数が強化されています。

  TiProxy の使用シナリオは次のとおりです。

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

  TiProxy はTiUP、 TiDB Operator、および TiDB Dashboard に統合されており、構成、展開、保守が容易になります。

  詳細についてはドキュメンテーション参照してください。

構文

• 大量のデータを処理するための新しい DML タイプをサポート (実験的) ＃50215 @ エキシウム

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

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

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

  詳細についてはドキュメンテーション参照してください。

• テーブル作成時にデフォルトの列値を設定する式の使用をサポート (実験的) ＃50936 @ ジムララ

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

  詳細についてはドキュメンテーション参照してください。

• div_precision_incrementシステム変数＃51501 @ いいえをサポート

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

  詳細についてはドキュメンテーション参照してください。

DB操作

• PITR は Amazon S3 オブジェクト ロック＃51184 @ リドリスをサポートします

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

  詳細についてはドキュメンテーション参照してください。

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

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

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

  詳細についてはドキュメンテーション参照してください。

• 一般的なログを別のファイルに書き込むことをサポート＃51248 @ 定義2014

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

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

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

  詳細についてはドキュメンテーション参照してください。

可観測性

• インデックス使用統計の監視をサポート＃49830 @ ヤンケオ

  適切なインデックス設計は、データベースのパフォーマンスを維持するための重要な前提条件です。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 キー管理サービス (Cloud KMS) (実験的) ＃8906 @ 栄光をサポートします

  TiKV は、保存時の暗号化技術を使用して保存データを暗号化することで、データのセキュリティを確保します。セキュリティのための保存時の暗号化の中核は、キー管理です。v8.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 はシンプルプロトコル＃9898 @ 3エースショーハンドのサポートを追加します

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

  詳細についてはドキュメンテーション参照してください。

• TiCDC は Debezium フォーマット プロトコル＃1799 @ そよ風のようなのサポートを追加します

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

  詳細についてはドキュメンテーション参照してください。

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

  以前のバージョンでは、DM は比較的セキュリティの低い組み込みの固定秘密鍵を使用していました。v8.0.0 以降では、上流および下流のデータベースのパスワードを暗号化および復号化するための秘密鍵ファイルをアップロードして指定できます。また、必要に応じて秘密鍵ファイルを置き換えて、データ セキュリティを強化することもできます。

  詳細についてはドキュメンテーション参照してください。

• IMPORT INTO機能を強化するためにIMPORT INTO ... FROM SELECT構文をサポートします (実験的) ＃49883 @ D3ハンター

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

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

  詳細についてはドキュメンテーション参照してください。

• TiDB Lightning は競合解決戦略を簡素化し、 replace戦略 (実験的) ＃51036 @ 翻訳者を使用して競合するデータの処理をサポートします。

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

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

  詳細についてはドキュメンテーション参照してください。

• グローバルソートが一般提供（GA）され、 IMPORT INTOのパフォーマンスと安定性が大幅に向上しました＃45719 @ ランス6716

  v7.4.0 より前では、 分散実行フレームワーク (DXF)使用してIMPORT INTOタスクを実行する場合、ローカルstorageスペースが限られているため、TiDB は TiKV にインポートする前にデータの一部のみをローカルでソートします。その結果、TiKV にインポートされたデータが大幅に重複し、インポート中に TiKV で追加の圧縮操作を実行する必要があり、TiKV のパフォーマンスと安定性に影響します。

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

  詳細についてはドキュメンテーション参照してください。

互換性の変更

注記：

このセクションでは、v7.6.0 から現在のバージョン (v8.0.0) にアップグレードするときに知っておく必要のある互換性の変更について説明します。v7.5.0 以前のバージョンから現在のバージョンにアップグレードする場合は、中間バージョンで導入された互換性の変更も確認する必要がある可能性があります。

• GA ではないがデフォルトで有効になっている監視関連のスケジューラを削除します＃7765 @ rleungx

行動の変化

• ユーザーの潜在的な接続問題を防ぐために、Security強化モード (SEM) でrequire_secure_transportからONの設定を禁止します＃47665 @ 天菜まお
• DM では、暗号化と復号化の固定秘密鍵が削除され、暗号化と復号化の秘密鍵をカスタマイズできるようになります。アップグレード前にデータソース構成と移行タスクの構成で暗号化パスワードが使用されている場合は、追加の操作についてはDM 暗号化と復号化のための秘密鍵をカスタマイズするのアップグレード手順を参照する必要があります＃9492 @ D3ハンター
• v8.0.0 より前では、 ADD INDEXとCREATE INDEX ( tidb_ddl_enable_fast_reorg = ON ) のアクセラレーションを有効にすると、エンコードされたインデックス キーは16の固定同時実行性で TiKV にデータを取り込みますが、これは下流の 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と新しいビューsys.schema_unused_indexesを追加します。これは、TiDB の最後の起動以降に使用されていないインデックスを記録します。

廃止された機能

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

改善点

• ティビ

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

• ティクヴ

  • TSOの検証と検出を強化して、構成や操作が不適切な場合のクラスターTSOの堅牢性を向上させる＃16545 @ 翻訳
  • コミットされていないトランザクションの処理パフォーマンスを向上させるために、悲観的ロックのクリーンアップロジックを最適化します＃16158 @ 翻訳
  • TiKV の統合ヘルスコントロールを導入して、異常な単一 TiKV ノードがクラスターアクセスパフォーマンスに与える影響を軽減します。1 からtikv-client.enable-replica-selector-v2 false設定することで、この最適化を無効にすることができます＃16297 ＃1104 ＃1167 @ ミョンケミンタ @ ジグアン @ クレイジーcs520
  • PDクライアントは、メタデータstorageインターフェースを使用して、以前のグローバル構成インターフェース＃14484 @ ヒューシャープを置き換えます。
  • write cf stats ＃16245 @ コナー1996を通じてデータの読み込み動作を決定することでスキャンのパフォーマンスを向上させます。
  • Raft conf 変更プロセス中にノードが削除され、投票者が降格されたかどうか最新のハートビートをチェックして、この動作によってリージョンがアクセス不能にならないことを確認します＃15799 @ トニー
  • パイプライン DML ＃16291 @ エキシウム用の Flush および BufferBatchGet インターフェイスを追加します。
  • cgroup CPU とメモリ制限の監視とアラートを追加＃16392 @ ピンとb
  • リージョンワーカーとスナップショット生成ワーカー＃16562 @ コナー1996の CPU モニタリングを追加します。
  • ピアのスローログを追加し、メッセージ＃16600 @ コナー1996を保存します。

• PD

  • PDクライアントのサービス検出機能を強化して、高可用性と負荷分散を改善します＃7576 @ キャビンフィーバーB
  • PDクライアント＃7673 @ じゃがいもの再試行メカニズムを強化
  • cgroup CPU とメモリ制限の監視とアラートを追加＃7716 ＃7918 @ ピンとb @ rleungx
  • etcd使用時のパフォーマンスと高可用性を向上させる＃7738 ＃7724 ＃7689 @ 翻訳者
  • パフォーマンスのボトルネックをより適切に分析するために、ハートビートの監視メトリックを追加します＃7868 @ ノルーシュ
  • etcdリーダーのPDリーダーへの影響を軽減する＃7499 @ じゃがいも @ ヒューシャープ
  • 不健全なetcdノードの検出メカニズムを強化する＃7730 @ じゃがいも @ ヒューシャープ
  • pd-ctl ＃7767 @ ノルーシュの GC セーフポイントの出力を最適化します。
  • ホットスポットスケジューラ＃7877 @ 翻訳者の履歴ウィンドウ構成の動的変更をサポート
  • 演算子＃7837 @ リーヴルスの作成時のロック競合の問題を軽減します。
  • GRPC 構成を調整して可用性を向上させる＃7821 @ rleungx

• TiFlash

  • JSON_EXTRACT()関数＃8510 @ シーライズのjson_path引数に非定数値の使用をサポート
  • JSON_LENGTH(json, path)機能＃8711 @ シーライズをサポート

• ツール

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

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

  • ティCDC

    • TiCDCがデータを複製する際のメモリ消費量を削減するために、 RowChangedEventのメモリ消費量を最適化します＃10386 @ リデズ
    • 変更フィードタスク＃10499 @ 3エースショーハンドの作成と再開時に start-ts パラメータが有効であることを確認します。

  • 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 @ ok江

  • TiDB Lightning

    • logical-import-batch-rows ＃46607 @ ケニーを使用して論理インポート モードでバッチ内の最大行数を構成することをサポートします。
    • TiDB LightningはTiFlashの容量が不足するとエラーを報告します＃50324 @ ok江

バグの修正

• ティビ

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

• ティクヴ

  • tidb_enable_row_level_checksum有効にすると TiKV がpanicになる可能性がある問題を修正＃16371 @ 翻訳
  • 例外的な状況で休止状態のリージョンがすぐに起動しない問題を修正＃16368 @ リクササシネーター
  • ノードをオフラインにする前に、リージョン内のすべてのレプリカの最後のハートビート時間をチェックすることで、1 つのレプリカがオフラインになるとリージョン全体が使用できなくなる問題を修正しました＃16465 @ トニー
  • 最大値INT64より大きく最大値UINT64より小さい JSON 整数が TiKV によってFLOAT64として解析され、TiDB ＃16512 @ ヤンケオとの不整合が発生する問題を修正しました。
  • 監視メトリックtikv_unified_read_pool_thread_countにデータがない場合がある問題を修正＃16629 @ ユジュンセン

• PD

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

• TiFlash

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

• ツール

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

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

  • ティCDC

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

  • TiDB データ移行 (DM)

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

  • TiDB Lightning

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

寄稿者

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

• アオアン
• バッファフライ
• デーモン365
• エルトシア
• リチュンジュ
• ジフハウス
• ピンとb
• 神奇徳宝子
• スミティズ
• 歌zhibin97
• タンジンギュ97
• テーマ
• ub-3
• ヨシキポム