TiDB 7.2.0 リリースノート

発売日:2023年6月29日

TiDB バージョン: 7.2.0

クイックアクセス: クイックスタート | インストールパッケージ

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

カテゴリー特徴説明
スケーラビリティとパフォーマンスリソース グループは暴走クエリの管理をサポートします (実験的)クエリのタイムアウトをより詳細に管理できるようになり、クエリの分類に基づいてさまざまな動作が可能になります。指定したしきい値を満たすクエリは、優先順位を下げたり、終了したりできます。
TiFlash はパイプライン実行モデルをサポートします (実験的) TiFlash は、スレッド リソース制御を最適化するパイプライン実行モデルをサポートしています。
SQLデータインポート用の新しい SQL ステートメントIMPORT INTOをサポート (実験的) TiDB Lightningのデプロイメントとメンテナンスを簡素化するために、TiDB では新しい SQL ステートメントIMPORT INTOを導入しています。これは、Amazon S3 または Google Cloud Storage (GCS) から TiDB に直接リモート インポートするなど、 TiDB Lightningの物理インポート モードを統合します。
DB の操作と可観測性DDL は一時停止および再開操作をサポートします (実験的)この新機能により、インデックス作成などのリソースを大量に消費する DDL 操作を一時的に停止して、リソースを節約し、オンライン トラフィックへの影響を最小限に抑えることができます。準備ができたら、キャンセルして再起動することなく、これらの操作をシームレスに再開できます。この機能により、リソースの使用率が向上し、ユーザー エクスペリエンスが向上し、スキーマの変更が合理化されます。

機能の詳細

パフォーマンス

  • 次の 2 つのウィンドウ関数 TiFlash #7427 @ xzhangxian1008にプッシュダウンすることをサポートします。

    • FIRST_VALUE
    • LAST_VALUE
  • TiFlash はパイプライン実行モデル (実験的) #6518 @ シーライズをサポートしています。

    v7.2.0 より前では、 TiFlashエンジンの各タスクは実行中に個別にスレッド リソースを要求する必要がありました。 TiFlash は、スレッド リソースの使用量を制限し、過剰使用を防ぐためにタスクの数を制御しますが、この問題を完全に排除することはできませんでした。この問題に対処するために、 TiFlash には v7.2.0 以降、パイプライン実行モデルが導入されています。このモデルは、すべてのスレッド リソースを集中管理し、タスクの実行を均一にスケジュールすることで、リソースの過剰使用を回避しながらスレッド リソースの使用率を最大化します。パイプライン実行モデルを有効または無効にするには、 tidb_enable_tiflash_pipeline_modelシステム変数を変更します。

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

  • TiFlash は、スキーマ レプリケーションのレイテンシー#7630 @ ホンユニャンを削減します。

    テーブルのスキーマが変更されると、 TiFlash はTiKV から最新のスキーマをタイムリーに複製する必要があります。 v7.2.0 より前では、 TiFlash がテーブル データにアクセスし、データベース内のテーブル スキーマの変更を検出した場合、 TiFlash は、 TiFlashレプリカのないテーブルも含め、このデータベース内のすべてのテーブルのスキーマを再度複製する必要があります。その結果、多数のテーブルを含むデータベースでは、 TiFlashを使用して 1 つのテーブルからデータを読み取るだけでよい場合でも、 TiFlash がすべてのテーブルのスキーマ レプリケーションを完了するまでにかなりのレイテンシーが発生する可能性があります。

    v7.2.0 では、 TiFlash はスキーマ レプリケーション メカニズムを最適化し、 TiFlashレプリカを使用したテーブルのスキーマのレプリケーションのみをサポートします。 TiFlashレプリカを含むテーブルのスキーマ変更が検出されると、 TiFlash はそのテーブルのスキーマのみをレプリケートします。これにより、 TiFlashのスキーマ レプリケーションのレイテンシーが短縮され、 TiFlashデータ レプリケーションに対する DDL 操作の影響が最小限に抑えられます。この最適化は自動的に適用されるため、手動による構成は必要ありません。

  • 統計収集#44725 @ シュイファングリーンアイズのパフォーマンスを向上させます。

    TiDB v7.2.0 は統計収集戦略を最適化し、重複情報やオプティマイザーにとってほとんど価値のない情報の一部をスキップします。統計収集の全体的な速度が 30% 向上しました。この改善により、TiDB はデータベースの統計をよりタイムリーに更新できるようになり、生成された実行計画がより正確になり、データベース全体のパフォーマンスが向上します。

    デフォルトでは、統計収集ではJSONBLOBMEDIUMBLOB 、およびLONGBLOBタイプの列がスキップされます。 tidb_analyze_skip_column_typesシステム変数を設定することで、デフォルトの動作を変更できます。 TiDB はJSONBLOB 、およびTEXTタイプとそのサブタイプのスキップをサポートします。

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

  • データとインデックスの整合性チェックのパフォーマンスを向上#43693 @ wjhuang2016

    ADMIN CHECK [TABLE|INDEX]ステートメントは、テーブル内のデータとそれに対応するインデックス間の一貫性をチェックするために使用されます。 v7.2.0 では、TiDB はデータの整合性をチェックする方法を最適化し、 ADMIN CHECK [TABLE|INDEX]の実行効率を大幅に向上させます。大量のデータを使用するシナリオでは、この最適化によりパフォーマンスが数百倍向上します。

    最適化はデフォルトで有効になっており (デフォルトではtidb_enable_fast_table_checkON )、大規模なテーブルのデータ整合性チェックに必要な時間が大幅に短縮され、運用効率が向上します。

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

信頼性

  • 予想よりも多くのリソースを消費するクエリを自動的に管理する (実験的) #43691 @ コナー1996 @ キャビンフィーバーB @ グロルフ @ ヒューシャープ @ ノールーシュ

    データベースの安定性に対する最も一般的な課題は、突然の SQL パフォーマンスの問題によって引き起こされるデータベース全体のパフォーマンスの低下です。 SQL パフォーマンスの問題には、十分にテストされていない新しい SQL ステートメント、データ量の大幅な変更、実行計画の突然の変更など、さまざまな原因が考えられます。これらの問題を根本から完全に回避することは困難です。 TiDB v7.2.0 は、予想よりも多くのリソースを消費するクエリを管理する機能を提供します。この機能により、パフォーマンスの問題が発生した場合に、影響範囲を迅速に縮小できます。

    これらのクエリを管理するために、リソース グループのクエリの最大実行時間を設定できます。クエリの実行時間がこの制限を超えると、クエリは自動的に優先順位が下げられるかキャンセルされます。特定されたクエリをテキストまたは実行プランで即座に照合する期間を設定することもできます。これは、予想よりも多くのリソースを消費する可能性がある、識別フェーズ中に問題のあるクエリの同時実行性が高くなることを防ぐのに役立ちます。

    予想よりも多くのリソースを消費するクエリの自動管理により、予期しないクエリのパフォーマンスの問題に迅速に対応するための効果的な手段が提供されます。この機能により、データベース全体のパフォーマンスに対する問題の影響が軽減され、データベースの安定性が向上します。

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

  • 過去の実行計画に従ってバインディングを作成する機能を強化#39199 @ qw4990

    TiDB v7.2.0 は過去の実行計画に従ってバインディングを作成するの機能を強化します。この機能により、複雑なステートメントの解析とバインドのプロセスが改善され、バインディングがより安定し、次の新しいヒントがサポートされます。

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

  • オプティマイザー修正制御メカニズムを導入して、オプティマイザーの動作をきめ細かく制御できるようにします#43169 @ 時間と運命

    より合理的な実行計画を生成するために、TiDB オプティマイザーの動作は製品の反復を通じて進化します。ただし、特定のシナリオでは、変更によりパフォーマンスの低下が生じる可能性があります。 TiDB v7.2.0 では、オプティマイザーの詳細な動作の一部を制御できるオプティマイザー修正コントロールが導入されています。これにより、いくつかの新しい変更をロールバックしたり制御したりできます。

    制御可能な各動作は、修正番号に対応する GitHub の問題によって説明されます。制御可能な動作はすべてオプティマイザー修正コントロールにリストされています。 tidb_opt_fix_controlシステム変数を設定して 1 つ以上の動作の目標値を設定し、動作制御を実現できます。

    オプティマイザー修正制御メカニズムは、TiDB オプティマイザーを詳細なレベルで制御するのに役立ちます。これは、アップグレード プロセスによって発生するパフォーマンスの問題を修正する新しい手段を提供し、TiDB の安定性を向上させます。

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

  • 軽量の統計初期化が一般公開 (GA) #42160 @ シュイファングリーンアイズ

    v7.2.0 以降、軽量統計初期化機能が GA になりました。軽量の統計初期化により、起動時にロードする必要がある統計の数が大幅に削減され、統計のロード速度が向上します。この機能により、複雑なランタイム環境における TiDB の安定性が向上し、TiDB ノードの再起動時のサービス全体への影響が軽減されます。

    v7.2.0 以降のバージョンで新しく作成されたクラスターの場合、TiDB は TiDB の起動時にデフォルトで軽量統計をロードし、ロードが完了するまで待ってからサービスを提供します。以前のバージョンからアップグレードされたクラスターの場合、TiDB 構成項目lite-init-statsおよびforce-init-statsからtrueを設定して、この機能を有効にすることができます。

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

SQL

  • CHECK制約#41711 @ fzzf678をサポート

    v7.2.0 以降、 CHECK制約を使用して、指定した条件を満たすようにテーブル内の 1 つ以上の列の値を制限できます。 CHECK制約がテーブルに追加されると、TiDB はテーブルにデータを挿入または更新する前に制約が満たされているかどうかをチェックします。制約を満たすデータのみを書き込むことができます。

    この機能はデフォルトでは無効になっています。 tidb_enable_check_constraintシステム変数をONに設定して有効にできます。

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

DB操作

  • DDL ジョブは操作の一時停止と再開をサポートします (実験的) #18015 @ ゴドゥム

    TiDB v7.2.0 より前では、DDL ジョブの実行中にビジネス ピークが発生した場合、DDL ジョブを手動でキャンセルしてビジネスへの影響を軽減することしかできませんでした。 v7.2.0 では、TiDB に DDL ジョブの一時停止および再開操作が導入されました。これらの操作により、ピーク時に DDL ジョブを一時停止し、ピーク終了後に再開できるため、アプリケーションのワークロードへの影響を回避できます。

    たとえば、 ADMIN PAUSE DDL JOBSまたはADMIN RESUME DDL JOBSを使用して複数の DDL ジョブを一時停止および再開できます。

    ADMIN PAUSE DDL JOBS 1,2; ADMIN RESUME DDL JOBS 1,2;

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

データ移行

  • データのインポート効率を大幅に向上させる新しい SQL ステートメントIMPORT INTOを導入します (実験的) #42930 @ D3ハンター

    IMPORT INTOステートメントは、 TiDB Lightningの物理インポートモード機能を統合します。このステートメントを使用すると、CSV、SQL、PARQUET などの形式でデータを TiDB の空のテーブルにすばやくインポートできます。このインポート方法により、 TiDB Lightningを個別に展開して管理する必要がなくなり、データ インポートの複雑さが軽減され、インポート効率が大幅に向上します。

    Amazon S3 または GCS に保存されているデータ ファイルの場合、 TiDB 分散実行フレームワーク (DXF)が有効な場合、 IMPORT INTOデータ インポート ジョブを複数のサブジョブに分割し、それらを並行インポート用に複数の TiDB ノードにスケジュールすることもサポートします。これにより、インポートのパフォーマンスがさらに向上します。

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

  • TiDB Lightning は、 Latin-1 文字セットを含むソース ファイルの TiDB #44434 @ ランス6716へのインポートをサポートしています。

    この機能を使用すると、 TiDB Lightningを使用して、Latin-1 文字セットを含むソース ファイルを TiDB に直接インポートできます。 v7.2.0 より前では、このようなファイルをインポートするには追加の前処理または変換が必要です。 v7.2.0 以降、 TiDB Lightningインポート タスクを構成するときにcharacter-set = "latin1"を指定するだけで済みます。その後、 TiDB Lightning はインポート プロセス中に自動的に文字セット変換を処理し、データの整合性と正確性を確保します。

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

互換性の変更

注記:

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

システム変数

変数名種類の変更説明
last_insert_id修正済みMySQL の最大値と一致するように、最大​​値を9223372036854775807から18446744073709551615に変更します。
tidb_enable_non_prepared_plan_cache修正済みさらにテストを行った後、デフォルト値をOFFからONに変更します。これは、準備されていない実行プラン キャッシュが有効になることを意味します。
tidb_remove_orderby_in_subquery修正済みさらにテストを行った後、デフォルト値をOFFからONに変更します。これは、オプティマイザがサブクエリ内のORDER BY句を削除することを意味します。
tidb_analyze_skip_column_types新しく追加された統計を収集するコマンドANALYZEを実行するときに、統計収集のためにどのタイプの列をスキップするかを制御します。この変数はtidb_analyze_version = 2にのみ適用されます。 ANALYZE TABLE t COLUMNS c1, ..., cnの構文を使用する場合、指定した列の型がtidb_analyze_skip_column_typesに含まれる場合、この列の統計は収集されません。
tidb_enable_check_constraint新しく追加されたCHECK制約を有効にするかどうかを制御します。デフォルト値はOFFで、この機能が無効であることを意味します。
tidb_enable_fast_table_check新しく追加されたテーブル内のデータとインデックスの整合性を迅速にチェックするためにチェックサムベースのアプローチを使用するかどうかを制御します。デフォルト値はONで、この機能が有効であることを意味します。
tidb_enable_tiflash_pipeline_model新しく追加されたTiFlashの新しい実行モデルパイプラインモデルを有効にするかどうかを制御します。デフォルト値はOFFで、パイプライン モデルが無効であることを意味します。
tidb_expensive_txn_time_threshold新しく追加された高価なトランザクションをログに記録するためのしきい値を制御します。デフォルトでは 600 秒です。トランザクションの継続時間がしきい値を超え、トランザクションがコミットもロールバックもされない場合、そのトランザクションは高価なトランザクションとみなされ、ログに記録されます。

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

コンフィグレーションファイルコンフィグレーションパラメータ種類の変更説明
TiDBlite-init-stats修正済みさらにテストを行った後、デフォルト値をfalseからtrueに変更します。これは、TiDB が初期化効率を向上させるために、TiDB の起動時にデフォルトで軽量統計初期化を使用することを意味します。
TiDBforce-init-stats修正済みデフォルト値をfalseからtrueに変更してlite-init-statsに合わせます。これは、TiDB が TiDB の起動中にサービスを提供する前に統計の初期化が完了するのを待つことを意味します。
TiKV[`rocksdb.[defaultcfwritecflockcf].compaction-guard-min-output-file-size`](/tikv-configuration-file.md#compaction-guard-min-output-file-size)
TiKV[`rocksdb.[defaultcfwritecflockcf].optimize-filters-for-memory`](/tikv-configuration-file.md#optimize-filters-for-memory-new-in-v720)
TiKV[`rocksdb.[defaultcfwritecflockcf].periodic-compaction-seconds`](/tikv-configuration-file.md#periodic-compaction-seconds-new-in-v720)
TiKV[`rocksdb.[defaultcfwritecflockcf].ribbon-filter-above-level`](/tikv-configuration-file.md#ribbon-filter-above-level-new-in-v720)
TiKV[`rocksdb.[defaultcfwritecflockcf].ttl`](/tikv-configuration-file.md#ttl-new-in-v720)
TiDB Lightningsend-kv-pairs廃止されましたv7.2.0 以降、パラメータsend-kv-pairsは非推奨になりました。物理インポート モードで TiKV にデータを送信する場合、 send-kv-sizeを使用して 1 つのリクエストの最大サイズを制御できます。
TiDB Lightningcharacter-set修正済みデータ インポートでサポートされる文字セットに新しい値オプションlatin1が導入されました。このオプションを使用すると、Latin-1 文字セットを含むソース ファイルをインポートできます。
TiDB Lightningsend-kv-size新しく追加された物理インポートモードでTiKVにデータを送信する際の1リクエストの最大サイズを指定します。キーと値のペアのサイズが指定されたしきい値に達すると、 TiDB Lightningはそれらのペアを直ちに TiKV に送信します。これにより、大きな幅のテーブルをインポートするときにTiDB Lightningノードがメモリ内にあまりにも多くのキーと値のペアを蓄積することによって引き起こされる OOM 問題が回避されます。このパラメータを調整すると、メモリ使用量とインポート速度のバランスが取れ、インポート プロセスの安定性と効率が向上します。
データ移行strict-optimistic-shard-mode新しく追加されたこの構成アイテムは、TiDB Data Migration v2.0 の DDL シャード マージ動作と互換性を保つために使用されます。この設定項目は楽観的モードで有効にできます。これを有効にすると、レプリケーション タスクはタイプ 2 DDL ステートメントに遭遇すると中断されます。複数のテーブルの DDL 変更間に依存関係があるシナリオでは、適時に中断される可能性があります。アップストリームとダウンストリームの間でデータの一貫性を確保するには、レプリケーション タスクを再開する前に各テーブルの DDL ステートメントを手動で処理する必要があります。
TiCDCsink.protocol修正済みダウンストリームが Kafka の場合、新しい値のオプション"open-protocol"が導入されます。メッセージのエンコードに使用されるプロトコル形式を指定します。
TiCDCsink.delete-only-output-handle-key-columns新しく追加されたDELETE イベントの出力を指定します。このパラメータは、 "canal-json"および"open-protocol"プロトコルに対してのみ有効です。デフォルト値はfalseで、すべての列を出力することを意味します。 trueに設定すると、主キー列または一意のインデックス列のみが出力されます。

改善点

  • TiDB

    • 複雑な条件をインデックス スキャン範囲#41572 #44389 @ シュイファングリーンアイズに変換できるように、インデックス スキャン範囲を構築するロジックを最適化します。
    • 新しい監視メトリクスStale Read OPSおよびStale Read Traffic #43325 @ あなた06を追加
    • 古い読み取りの再試行リーダーがロックに遭遇すると、TiDB はロックを解決した後にリーダーで強制的に再試行します。これにより、不要なオーバーヘッドが回避されます#43659 @ あなた06
    • 推定時間を使用して古い読み取り ts を計算し、古い読み取り#44215 @ あなた06のオーバーヘッドを削減します。
    • 長時間実行トランザクションのログとシステム変数を追加#41471 @ クレイジークス520
    • 圧縮 MySQL プロトコルを介した TiDB への接続をサポートします。これにより、低帯域幅ネットワーク下でのデータ集約型クエリのパフォーマンスが向上し、帯域幅コストが節約されます。これは、 zlibベースの圧縮とzstdの圧縮の両方をサポートします。 #22605 @ ドヴィーデン
    • utf8utf8bm3の両方を従来の 3 バイト UTF-8 文字セット エンコーディングとして認識するため、従来の UTF-8 エンコーディングを使用したテーブルの MySQL 8.0 から TiDB #26226 @ ドヴィーデンへの移行が容易になります。
    • UPDATEステートメント#44751 @ Cbcウェストウルフでの代入に:=を使用するサポート
  • TiKV

    • pd.retry-interval #14964 @ ルルンクスを使用した接続要求の失敗などのシナリオでの PD 接続の再試行間隔の構成のサポート
    • グローバル リソース使用量#14604 @ コナー1996を組み込むことにより、リソース制御スケジューリング アルゴリズムを最適化します。
    • check_leaderリクエストに gzip 圧縮を使用してトラフィック#14553 @ あなた06を削減します
    • check_leaderリクエスト#14658 @ あなた06に関連するメトリクスを追加
    • TiKV の書き込みコマンド処理中に詳細な時間情報を提供します#12362 @ cfzjywxk
  • PD

    • 他のリクエストの影響を防ぐために、PD リーダーの選出には別の gRPC 接続を使用します#6403 @ ルルンクス
    • マルチリージョン シナリオ#6433 @ バッファフライでのホットスポットの問題を軽減するために、デフォルトでバケット分割を有効にします。
  • ツール

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

      • Shared Access Signature (SAS) #44199 @ レヴルスによる Azure Blob Storage へのアクセスのサポート
    • TiCDC

      • オブジェクトstorageサービスへのレプリケーションのシナリオで DDL 操作が発生するときに、データ ファイルが保存されるディレクトリの構造を最適化します#8891 @ CharlesCheung96
      • Kafka #8865 @ こんにちはラスティンへのレプリケーションのシナリオで OAUTHBEARER 認証をサポートします。
      • Kafka #9143 @ 3エースショーハンドにレプリケーションのシナリオにおけるDELETEオペレーションのハンドルキーのみを出力するオプションを追加
    • TiDB データ移行 (DM)

      • インクリメンタル レプリケーション#6381 @ ドヴィーデンのデータ ソースとして、MySQL 8.0 で圧縮されたバイナリログの読み取りをサポートします。
    • TiDB Lightning

      • リーダーの切り替え#44263 @ ランス6716によって引き起こされるエラーを回避するために、インポート中の再試行メカニズムを最適化します。
      • インポート後に SQL でチェックサムを検証し、検証の安定性を向上させる#41941 @ GMHDBJD
      • 幅の広いテーブル#43853 @ D3ハンターをインポートする際のTiDB Lightning OOM 問題の最適化

バグの修正

  • TiDB

    • CTE を使用したクエリにより TiDB がハングする問題を修正#43749 #36896 @ グオシャオゲ
    • min, maxクエリ結果が正しくない問題を修正#43805 @ wshwsh12
    • SHOW PROCESSLISTステートメントがサブクエリ時間の長いステートメント#40851 @ クレイジークス520のトランザクションの TxnStart を表示できない問題を修正
    • コプロセッサータスク#43365 @ あなた06TxnScopeがないため、古い読み取りグローバル最適化が有効にならない問題を修正
    • フォロワー読み取りが再試行する前にフラッシュバック エラーを処理せず、クエリ エラー#43673 @ あなた06が発生する問題を修正します。
    • ON UPDATEステートメントが主キー#44565 @ ジグアンを正しく更新しない場合、データとインデックスが矛盾する問題を修正します。
    • MySQL 8.0.28 以降のバージョン#43987 @ ヤンケオの上限と一致するように、 UNIX_TIMESTAMP()関数の上限を3001-01-19 03:14:07.999999 UTCに変更します。
    • インジェストモード#44137 @ タンジェンタでインデックスの追加が失敗する問題を修正
    • ロールバック状態で DDL タスクをキャンセルすると、関連するメタデータ#44143 @ wjhuang2016でエラーが発生する問題を修正します。
    • カーソルフェッチでmemTrackerを使用するとメモリリーク#44254 @ ヤンケオが発生する問題を修正
    • データベースを削除すると GC の進行が遅くなる問題を修正#33069 @ ティエンチャイアマオ
    • インデックス結合#43686 @ アイリンキッド @ むじょんのプローブフェーズでパーティションテーブル内の対応する行が見つからない場合、TiDB がエラーを返す問題を修正します。
    • SUBPARTITION使用してパーティション テーブル#41198 #41200 @ むじょんを作成するときに警告が表示されない問題を修正します。
    • MAX_EXECUTION_TIMEを超えたためにクエリが強制終了された場合、返されるエラー メッセージが MySQL #43031 @ ドヴィーデンのエラー メッセージと一致しない問題を修正
    • LEADINGヒントがブロック エイリアス#44645 @ qw4990のクエリをサポートしていない問題を修正します。
    • MySQL #44574 @ 定義2014の戻り値と一致するように、 LAST_INSERT_ID()関数の戻り値の型を VARCHAR から LONGLONG に変更します。
    • 非相関サブクエリ#44051 @ ウィノロスを含むステートメントで共通テーブル式 (CTE) を使用すると、誤った結果が返される可能性がある問題を修正します。
    • 結合したテーブルの再配置により不正な外部結合結果#44314 @ アイリンキッドが発生する可能性がある問題を修正
    • PREPARE stmt FROM "ANALYZE TABLE xxx"tidb_mem_quota_query #44320 @ クリサンに殺される可能性がある問題を修正
  • TiKV

    • TiKV が古い悲観的ロックの競合#13298 @ cfzjywxkを処理するときに、トランザクションが不正な値を返す問題を修正します。
    • メモリ内の悲観的ロックがフラッシュバックの失敗とデータの不整合を引き起こす可能性がある問題を修正します#13303 @ Jmポテト
    • TiKV が古いリクエスト#13298 @ cfzjywxkを処理するときにフェア ロックが正しくない可能性がある問題を修正
    • autocommitpoint get replica read線形化可能性#14715 @ cfzjywxkを壊す可能性がある問題を修正
  • PD

    • 一部の特殊なケースで冗長レプリカが自動的に修復できない問題を修正#6573 @ ノールーシュ
  • TiFlash

    • 結合ビルド側のデータが非常に大きく、小さな文字列型の列#7416 @ イービン87が多数含まれている場合、クエリが必要以上のメモリを消費する可能性がある問題を修正します。
  • ツール

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

    • TiCDC

      • Resolved TSが正常に進まない場合がある問題を修正#8963 @ CharlesCheung96
      • Avro または CSV プロトコルが使用されている場合、 UPDATE操作で古い値を出力できない問題を修正#9086 @ 3エースショーハンド
      • データを Kafka #8959 @ こんにちはラスティンにレプリケートするときに、ダウンストリーム メタデータを頻繁に読み取ることによって引き起こされる過度のダウンストリーム プレッシャーの問題を修正します。
      • TiDB または MySQL #9180 @ 東門にデータをレプリケートするときに、ダウンストリーム双方向レプリケーション関連の変数を頻繁に設定することによって発生するダウンストリーム ログが多すぎる問題を修正します。
      • PD ノードのクラッシュにより TiCDC ノードが再起動される問題を修正します#8868 @ 東門
      • TiCDC がダウンストリーム Kafka-on-Pulsar #8892 @ こんにちはラスティンでチェンジフィードを作成できない問題を修正
    • TiDB Lightning

      • experimental.allow-expression-indexが有効で、デフォルト値が UUID #44497 @ リチュンジュである場合のTiDB Lightningpanicの問題を修正
      • データ ファイル#43195 @ ランス6716の分割中にタスクが終了したときのTiDB Lightningpanicの問題を修正しました。

貢献者

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

このページは役に立ちましたか?

Playground
新規
登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。
製品
TiDB Cloud
TiDB
価格
PoC お問い合わせ
エコシステム
TiKV
TiFlash
OSS Insight
© 2024 PingCAP. All Rights Reserved.
Privacy Policy.