TiDB 6.4.0 リリースノート

発売日：2022年11月17日

TiDB バージョン: 6.4.0-DMR

注記：

TiDB 6.4.0-DMR のドキュメントはアーカイブ済みです。PingCAP では、TiDB データベースの最新のLTSバージョン使用することを推奨しています。

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

v6.4.0-DMR の主な新機能と改善点は次のとおりです。

• FLASHBACK CLUSTER TO TIMESTAMP (実験的) を使用してクラスターを特定の時点に復元することをサポートします。
• TiDB インスタンスのグローバルメモリ使用量の追跡サポートします (実験的)。
• 線形ハッシュ分割構文と互換性があること。
• 高性能かつグローバルに単調なAUTO_INCREMENT (実験的) をサポートします。
• JSON型における配列データの範囲選択をサポートします。
• ディスク障害や I/O のスタックなどの極端な状況での障害回復を高速化します。
• テーブルの結合順序を決定するには動的計画アルゴリズム追加します。
• 相関サブクエリに対して非相関化を実行するかどうかを制御するには新しいオプティマイザヒントNO_DECORRELATE導入します。
• クラスター診断機能はGAになります。
• TiFlash は保存時の暗号化の SM4 アルゴリズムをサポートします。
• 指定されたパーティションのTiFlashレプリカをテーブルにすぐに圧縮しますへの SQL ステートメントの使用をサポートします。
• サポートEBSボリュームスナップショットを使用してTiDBクラスターをバックアップする 。
• DMは上流のデータソース情報を下流のマージされたテーブルの拡張列に書き込むサポートします。

新機能

SQL

• SQL 文を使用して、テーブル内の指定されたパーティションのTiFlashレプリカを即時に圧縮する機能をサポート＃5315 @ ヘヘチェン

  TiDBはv6.2.0以降、 TiFlashのフルテーブルレプリカにおける物理データを即座に圧縮するの機能をサポートしています。適切なタイミングでSQL文を手動で実行することで、 TiFlash内の物理データを即座に圧縮できるため、storage容量の削減とクエリパフォーマンスの向上につながります。v6.4.0では、圧縮対象となるTiFlashレプリカデータの粒度を改良し、テーブル内の特定のパーティションのTiFlashレプリカを即座に圧縮できるようになりました。

  SQL ステートメントALTER TABLE table_name COMPACT [PARTITION PartitionNameList] [engine_type REPLICA]実行すると、テーブル内の指定されたパーティションのTiFlashレプリカをすぐに圧縮できます。

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

• FLASHBACK CLUSTER TO TIMESTAMP (実験的) ＃37197 ＃13303 @ 定義2014 @ bb7133 @ Jmポテト @ コナー1996 @ HuSharp @ カルビンネオを使用して、クラスターを特定の時点に復元することをサポートします。

  FLASHBACK CLUSTER TO TIMESTAMP構文を使用すると、ガベージコレクション（GC）の有効期間内であれば、クラスターを特定の時点に迅速に復元できます。この機能は、DMLの誤った操作を簡単かつ迅速に元に戻すのに役立ちます。例えば、 WHERE句を指定せずに誤ってDELETE実行してしまった場合でも、この構文を使用すれば数分で元のクラスターを復元できます。この機能はデータベースのバックアップに依存せず、異なる時点のデータのロールバックをサポートし、データが変更された正確な時刻を特定します。7 FLASHBACK CLUSTER TO TIMESTAMPデータベースのバックアップを置き換えることはできませんのでご注意ください。

  FLASHBACK CLUSTER TO TIMESTAMP実行する前に、TiCDC などのツールで実行されている PITR およびレプリケーションタスクを一時停止し、 FLASHBACK完了後に再開する必要があります。そうしないと、レプリケーションタスクが失敗する可能性があります。

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

• FLASHBACK DATABASE ＃20463 @ エルワドバを使用して削除されたデータベースの復元をサポートします

  FLASHBACK DATABASE使用すると、 DROPによって削除されたデータベースとそのデータを、ガベージコレクション（GC）の有効期間内に復元できます。この機能は外部ツールに依存しません。SQL文を使用して、データとメタデータを迅速に復元できます。

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

Security

• TiFlashは保存時の暗号化にSM4アルゴリズムをサポートしています＃5953 @ リデジュ

  TiFlash の保存時暗号化に SM4 アルゴリズムを追加します。保存時暗号化を設定する場合、設定ファイルtiflash-learner.tomlのdata-encryption-method設定の値をsm4-ctrに設定することで、SM4 暗号化機能を有効にできます。

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

可観測性

• クラスタ診断は GA ＃1438 @ ホークソンジーになります

  TiDBダッシュボードのクラスター診断機能は、指定された時間範囲内でクラスタに存在する可能性のある問題を診断し、診断結果とクラスタ関連の負荷監視情報を診断レポートにまとめます。この診断レポートはウェブページ形式で提供されます。ブラウザからページを保存した後、オフラインでページを閲覧したり、このページのリンクを配布したりできます。

  診断レポートを使用すると、負荷、コンポーネントの状態、時間消費、構成など、クラスターの基本的な健全性情報を迅速に把握できます。クラスターに一般的な問題がある場合は、セクション診断情報に組み込まれた自動診断の結果から原因を特定できます。

パフォーマンス

• コプロセッサタスク＃37724 @ あなた06同時実行適応メカニズムを導入する

  コプロセッサ タスクの数が増えると、TiKV の処理速度に基づいて、TiDB は自動的に同時実行性を高め ( tidb_distsql_scan_concurrencyの値を調整)、コプロセッサ タスク キューを減らしてレイテンシーを減らします。

• テーブル結合順序＃37825 @ ウィノロスを決定する動的計画アルゴリズムを追加します。

  以前のバージョンでは、TiDBはテーブルの結合順序を決定するために貪欲アルゴリズムを使用していました。v6.4.0では、TiDBオプティマイザーに動的計画アルゴリズム導入されました。動的計画アルゴリズムは貪欲アルゴリズムよりも多くの結合順序を列挙できるため、より適切な実行プランを見つける可能性が高まり、一部のシナリオではSQL実行効率が向上します。

  動的計画法アルゴリズムはより多くの時間を消費するため、TiDBの結合したテーブルの再配置アルゴリズムの選択は変数tidb_opt_join_reorder_thresholdによって制御されます。結合したテーブルの再配置に参加するノードの数がこのしきい値を超える場合、TiDBは貪欲アルゴリズムを使用します。それ以外の場合は、動的計画法アルゴリズムを使用します。

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

• プレフィックスインデックスは、null値のフィルタリングをサポートします＃21145 @ xuyifangreeneyes

  この機能はプレフィックスインデックスの最適化です。テーブル内の列にプレフィックスインデックスが設定されている場合、SQL文内の列の条件IS NULLまたはIS NOT NULLプレフィックスで直接フィルタリングできます。これにより、テーブル参照が回避され、SQL実行のパフォーマンスが向上します。

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

• TiDB チャンク再利用メカニズム＃38606 @ キープラーニング20221の強化

  以前のバージョンでは、TiDBはチャンクをwritechunk関数内でのみ再利用していました。TiDB v6.4.0では、チャンク再利用メカニズムがExecutorの演算子にも拡張されています。チャンクを再利用することで、TiDBは頻繁にメモリ解放を要求する必要がなくなり、一部のシナリオではSQLクエリの実行効率が向上します。システム変数tidb_enable_reuse_chunk使用して、チャンクオブジェクトの再利用の有無を制御できます。これはデフォルトで有効になっています。

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

• 相関サブクエリ＃37789 @ 時間と運命の相関解除を実行するかどうかを制御する新しいオプティマイザヒントNO_DECORRELATEを導入します。

  デフォルトでは、TiDB は常に相関サブクエリを書き換えてデコリレーションを実行しようとします。これにより、通常は実行効率が向上します。しかし、シナリオによっては、デコリレーションによって実行効率が低下する場合があります。v6.4.0 では、TiDB にオプティマイザーヒントNO_DECORRELATEが導入され、特定のクエリブロックに対してデコリレーションを実行しないようにオプティマイザーに指示することで、一部のシナリオにおけるクエリパフォーマンスが向上します。

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

• パーティションテーブル＃37977 @ イーサールでの統計収集のパフォーマンスを向上

  v6.4.0では、TiDBはパーティションテーブルの統計収集戦略を最適化します。システム変数tidb_auto_analyze_partition_batch_size使用して、パーティションテーブルの統計収集の同時実行性を設定することで、収集速度を向上させ、分析時間を短縮できます。

安定性

• ディスク障害やスタックI/O ＃13648 @ LykxSassinatorなどの極端な状況での障害回復を高速化します

  エンタープライズユーザーにとって、データベースの可用性は最も重要な指標の一つです。複雑なハードウェア環境において、いかに迅速に障害を検知し、復旧するかは、常にデータベースの可用性における課題の一つでした。v6.4.0では、TiDBはTiKVノードの状態検出メカニズムを完全に最適化しました。ディスク障害やI/Oスタックなどの極端な状況下でも、TiDBはノードの状態を迅速に報告し、アクティブウェイクアップメカニズムを用いて事前にLeader選出を開始することで、クラスターの自己修復を加速します。この最適化により、TiDBはディスク障害発生時のクラスター復旧時間を約50%短縮できます。

• TiDBメモリ使用量のグローバル制御＃37816 @ wshwsh12

  バージョン6.4.0では、TiDBインスタンスのグローバルメモリ使用量を追跡する実験的機能として、メモリメモリ量のグローバル制御が導入されました。システム変数tidb_server_memory_limit使用して、グローバルメモリ使用量の上限を設定できます。メモリ使用量がしきい値に達すると、TiDBは空きメモリの回収と解放を試みます。メモリ使用量がしきい値を超えると、TiDBはメモリメモリ量によるシステムの問題を回避します。

  TiDBインスタンスのメモリ消費に潜在的なリスクがある場合、TiDBは事前に診断情報を収集し、指定されたディレクトリに書き込むことで、問題の診断を容易にします。同時に、メモリ使用量と操作履歴を表示するシステムテーブルビューINFORMATION_SCHEMA.MEMORY_USAGEとINFORMATION_SCHEMA.MEMORY_USAGE_OPS_HISTORY提供し、メモリ使用量の理解を深めるのに役立ちます。

  グローバルメモリ制御は、TiDBのメモリ管理における画期的な技術です。インスタンスのグローバルビューを導入し、メモリを体系的に管理することで、より多くの重要なシナリオにおいてデータベースの安定性とサービスの可用性を大幅に向上させることができます。

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

• 範囲構築オプティマイザ＃37176 @ xuyifangreeneyesのメモリ使用量を制御する

  バージョン6.4.0では、範囲を構築するオプティマイザの最大メモリ使用量を制限するシステム変数tidb_opt_range_max_sizeが導入されました。メモリ使用量が制限を超えると、オプティマイザはより正確な範囲ではなく、より粗い範囲を構築することでメモリ消費量を削減します。SQL文にINの条件が多数含まれる場合、この最適化によりコンパイル時のメモリ使用量を大幅に削減し、システムの安定性を確保できます。

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

• 統計情報の同期読み込みをサポート (GA) ＃37434 @ クリサン

  TiDB v6.4.0では、統計情報の同期ロード機能がデフォルトで有効になっています。この機能により、SQL文の実行時に、TiDBは大規模な統計情報（ヒストグラム、TopN、Count-Min Sketch統計情報など）をメモリに同期的にロードできるようになり、SQL最適化における統計情報の完全性が向上します。

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

• 軽量トランザクション書き込みの応答時間に対するバッチ書き込み要求の影響を軽減＃13313 @ 栄光

  一部のシステムのビジネスロジックでは、定期的なバッチDMLタスクが必要ですが、これらのバッチ書き込みタスクの処理はオンライントランザクションのレイテンシーを増加させます。v6.3.0では、TiKVがハイブリッドワークロードシナリオにおける読み取り要求のスケジューリングを最適化するため、 readpool.unified.auto-adjust-pool-size構成項目を有効にすると、TiKVがすべての読み取り要求に対してUnifyReadPoolスレッドプールのサイズを自動的に調整できるようになります。v6.4.0では、TiKVは書き込み要求を動的に識別して優先順位付けするだけでなく、1回のポーリングで1つのFSM（有限状態マシン）に適用スレッドが書き込める最大バイト数を制御することができるため、バッチ書き込み要求がトランザクション書き込みの応答時間に与える影響を軽減できます。

使いやすさ

• TiKV API V2 が一般公開 (GA) される＃11745 @ ピンギュ

  v6.1.0より前のTiKVは、クライアントから渡された生データのみを保存するため、基本的なキー値の読み取りと書き込み機能しか提供していませんでした。さらに、コーディング方法の違いとスコープ外のデータ範囲のため、TiDB、Transactional KV、RawKVを同じTiKVクラスター内で同時に使用することはできません。同時に使用するには複数のクラスターが必要となり、マシンコストと導入コストが増加します。

  TiKV API V2 は、新しい RawKVstorage形式とアクセス インターフェイスを提供し、次のような利点をもたらします。

  • MVCCに記録されたデータの変更タイムスタンプとともにデータを保存し、これに基づいて変更データキャプチャ（CDC）を実装します。この機能は実験的であり、詳細はTiKV-CDCに記載されています。
  • データはさまざまな使用方法に応じてスコープが設定され、API V2 は単一クラスター内での TiDB、トランザクション KV、および RawKV アプリケーションの共存をサポートします。
  • マルチテナントなどの機能をサポートするために、キー スペース フィールドを予約します。

  TiKV API V2 を有効にするには、TiKV 構成ファイルの[storage]セクションでapi-version = 2設定します。

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

• TiFlashデータ複製の進行状況＃4902 @ ヘヘチェン精度を向上

  TiDBでは、 INFORMATION_SCHEMA.TIFLASH_REPLICAテーブルのPROGRESSフィールドは、TiKV内の対応するテーブルからTiFlashレプリカへのデータレプリケーションの進行状況を示すために使用されます。以前のTiDBバージョンでは、 PROCESSフィールドはTiFlashレプリカの作成中のデータレプリケーションの進行状況のみを示します。TiFlashTiFlashの作成後、TiKV内の対応するテーブルに新しいデータがインポートされても、このフィールドは更新されず、新しいデータのTiKVからTiFlashへのレプリケーションの進行状況は表示されません。

  v6.4.0では、TiDBはTiFlashレプリカのデータレプリケーションの進行状況の更新メカニズムを改善しました。TiFlashTiFlashの作成後、TiKVの対応するテーブルに新しいデータがインポートされると、テーブルINFORMATION_SCHEMA.TIFLASH_REPLICAのPROGRESSの値が更新され、新しいデータのTiKVからTiFlashへの実際のレプリケーション進行状況が表示されます。この改善により、 TiFlashデータレプリケーションの実際の進行状況を簡単に確認できます。

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

MySQLの互換性

• 線形ハッシュパーティション構文＃38450 @ ミョンスと互換性がある

  以前のバージョンでは、TiDBはハッシュ、レンジ、List パーティショニングをサポートしていました。v6.4.0以降、TiDBはMySQL 線形ハッシュパーティショニングの構文にも対応しています。

  TiDBでは、MySQLリニアハッシュパーティションの既存のDDL文を直接実行できます。TiDBは対応するハッシュパーティションテーブルを作成します（TiDB内にはリニアハッシュパーティションは存在しないことに注意してください）。また、MySQLリニアハッシュパーティションの既存のDML文を直接実行することもできます。TiDBは対応するTiDBハッシュパーティションのクエリ結果を通常通り返します。この機能により、TiDBの構文とMySQLリニアハッシュパーティションの互換性が確保され、MySQLベースのアプリケーションからTiDBへのシームレスな移行が容易になります。

  パーティション数が2の累乗の場合、TiDBハッシュパーティションテーブルの行はMySQLリニアハッシュパーティションテーブルと同じように分散されます。それ以外の場合、TiDBにおける行の分散はMySQLとは異なります。

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

• 高性能かつ全体的に単調なAUTO_INCREMENT (実験的) ＃38442 @ 天菜まおをサポート

  TiDB v6.4.0 では、MySQL 互換モードAUTO_INCREMENTが導入されました。このモードでは、すべての TiDB インスタンスで ID が単調に増加するようにする、集中型の自動インクリメント ID 割り当てサービスが導入されます。この機能により、自動インクリメント ID によるクエリ結果の並べ替えが容易になります。MySQL 互換モードを使用するには、テーブル作成時にAUTO_ID_CACHEから1設定する必要があります。以下は例です。

  CREATE TABLE t (a INT AUTO_INCREMENT PRIMARY KEY) AUTO_ID_CACHE = 1;
  

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

• JSON型＃13644 @ ヤンケオの配列データの範囲選択をサポート

  v6.4.0 以降では、TiDB で MySQL 互換範囲選択構文使用できるようになります。

  • キーワードto使用すると、配列要素の開始位置と終了位置を指定し、配列内の連続した範囲の要素を選択できます。 0使用すると、配列の最初の要素の位置を指定できます。例えば、 $[0 to 2]使用すると、配列の最初の3つの要素を選択できます。

  • キーワードlastを使用すると、配列の最後の要素の位置を指定できます。これにより、右から左への位置を指定できます。例えば、 $[last-2 to last]使用すると、配列の最後の3つの要素を選択できます。

  この機能により、SQL ステートメントの記述プロセスが簡素化され、JSON 型の互換性がさらに向上し、MySQL アプリケーションを TiDB に移行する際の難易度が軽減されます。

• データベースユーザー＃38172 @ CbcWestwolfの追加説明の追加をサポート

  TiDB v6.4では、 CREATE USERまたはALTER USER使用してデータベースユーザー向けの説明を追加できます。TiDBは2つの説明形式を提供しています。5 COMMENT使用してテキストコメントを追加し、 ATTRIBUTEを使用してJSON形式の構造化属性セットを追加できます。

  さらに、TiDB v6.4.0 では、ユーザーコメントとユーザー属性の情報を表示できるUSER_ATTRIBUTESテーブルが追加されました。

  CREATE USER 'newuser1'@'%' COMMENT 'This user is created only for test';
  CREATE USER 'newuser2'@'%' ATTRIBUTE '{"email": "user@pingcap.com"}';
  SELECT * FROM INFORMATION_SCHEMA.USER_ATTRIBUTES;
  

  +-----------+------+---------------------------------------------------+
  | USER      | HOST | ATTRIBUTE                                         |
  +-----------+------+---------------------------------------------------+
  | newuser1  | %    | {"comment": "This user is created only for test"} |
  | newuser1  | %    | {"email": "user@pingcap.com"}                     |
  +-----------+------+---------------------------------------------------+
  2 rows in set (0.00 sec)
  

  この機能により、TiDB と MySQL 構文の互換性が向上し、TiDB を MySQL エコシステムのツールやプラットフォームに統合しやすくなります。

バックアップと復元

• EBSボリュームスナップショット＃33849 @ フェンゴウ1を使用したTiDBクラスターのバックアップをサポート

  TiDB クラスターが EKS にデプロイされ、AWS EBS ボリュームを使用しており、TiDB クラスター データをバックアップする際に次の要件がある場合は、 TiDB Operatorを使用してボリューム スナップショットとメタデータごとにデータを AWS S3 にバックアップできます。

  • バックアップの影響を最小限に抑えます。たとえば、QPS とトランザクションのレイテンシーへの影響を 5% 未満に保ち、クラスターの CPU とメモリを占有しないようにします。
  • 短時間でデータのバックアップとリストアを行います。例えば、1時間以内にバックアップを完了し、2時間以内にデータをリストアします。

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

データ移行

• DMは、上流のデータソース情報を下流のマージされたテーブル＃37797 @ リチュンジュの拡張列に書き込むことをサポートします。

  上流からTiDBにシャード化されたスキーマとテーブルをマージする際、ターゲットテーブルに複数のフィールド（拡張列）を手動で追加し、DMタスクの設定時にそれらの値を指定できます。例えば、拡張列に上流のシャード化されたスキーマとテーブルの名前を指定すると、DMによって下流に書き込まれるデータにはスキーマ名とテーブル名が含まれます。下流のデータが通常とは異なる場合、この機能を使用することで、ターゲットテーブル内のスキーマ名やテーブル名などのデータソース情報を素早く見つけることができます。

  詳細についてはテーブル、スキーマ、ソース情報を抽出し、結合されたテーブルに書き込みます参照してください。

• DMは、いくつかの必須チェック項目をオプションの項目に変更することで、事前チェックのメカニズムを最適化します＃7333 @ リチュンジュ

  データ移行タスクをスムーズに実行するために、DM はタスクの開始時に事前チェック自動的にトリガーし、チェック結果を返します。DM は事前チェックに合格した後にのみ移行を開始します。

  v6.4.0 では、DM は次の 3 つのチェック項目を必須からオプションに変更し、事前チェックの合格率を向上させました。

  • アップストリーム テーブルが TiDB と互換性のない文字セットを使用しているかどうかを確認します。
  • 上流のテーブルに主キー制約または一意キー制約があるかどうかを確認します
  • プライマリ/セカンダリ構成で、アップストリーム データベースのデータベース ID server_idが指定されているかどうかを確認します。

• DM は、増分移行タスク＃7393 @ GMHDBJDオプション パラメータとして、binlogの位置と GTID を構成することをサポートしています。

  v6.4.0以降、binlogの位置やGTIDを指定せずに、直接増分マイグレーションを実行できるようになりました。DMは、タスク開始後に生成されたbinlogファイルを上流から自動的に取得し、これらの増分データを下流に移行します。これにより、ユーザーは煩雑な設定や理解の手間から解放されます。

  詳細についてはDM 高度なタスクコンフィグレーションファイル参照してください。

• DM は移行タスク＃7343 @ okJiangステータス インジケーターを追加します

  バージョン 6.4.0 では、DM により移行タスクのパフォーマンスと進行状況のインジケーターがさらに追加され、移行のパフォーマンスと進行状況をより直感的に理解できるようになり、トラブルシューティングの参照としても役立ちます。

  • データのインポートおよびエクスポートのパフォーマンスを示すステータス インジケーター (バイト/秒単位) を追加します。
  • ダウンストリーム データベースにデータを書き込むためのパフォーマンス インジケーターの名前を TPS から RPS (行数/秒) に変更します。
  • DM 完全移行タスクのデータ エクスポートの進行状況を示す進行状況インジケーターを追加します。

  これらの指標の詳細については、 TiDB データ移行におけるクエリタスクステータス参照してください。

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

• TiCDCは＃7191 3.2.0のデータレプリケーションを3エースショーハンドサポートしています。

  v6.4.0 以降、TiCDC は3.2.0バージョンのうちKafkaへのデータの複製それ以前のバージョンをサポートします。

互換性の変更

システム変数

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

その他

• v6.4.0以降、 mysql.userテーブルにUser_attributesとToken_issuer 2つの新しい列が追加されます。以前のTiDBバージョンmysqlバックアップデータからTiDB v6.4.0にmysqlスキーマ内のシステムテーブルを復元する復元すると、 BRはmysql.userテーブルに対してcolumn count mismatchエラーを報告します。13スキーマでシステムテーブルを復元しない場合、このエラーは報告されません。
• 名前がDumplingエクスポートファイルの形式一致するものの、末尾が非圧縮形式（ test-schema-create.sql.originやtest.table-schema.sql.originなど）であるファイルについては、 TiDB Lightningによる処理方法が変更されました。v6.4.0 より前では、インポートするファイルにこれらのファイルが含まれている場合、 TiDB Lightning はそれらのファイルのインポートをスキップしていました。v6.4.0 以降では、 TiDB Lightning はこれらのファイルがサポートされていない圧縮形式を使用していると想定し、インポートタスクは失敗します。
• v6.4.0 以降では、権限SYSTEM_VARIABLES_ADMINまたはSUPER持つ changefeed のみが TiCDC Syncpoint 機能を使用できます。

改善点

• TiDB

  • noop変数lc_messages ＃38231 @ djshow832変更を許可する
  • AUTO_RANDOM列目をクラスター化複合インデックス＃38572 @ 接線の最初の列としてサポートします
  • 内部トランザクションの再試行で悲観的トランザクションを使用して再試行の失敗を回避し、時間の消費を削減します＃38136 @ ジャッキーsp

• TiKV

  • 新しい構成項目apply-yield-write-size追加して、Apply スレッドが 1 回のポーリングで 1 つの有限状態マシンに書き込むことができる最大バイト数を制御し、Apply スレッドが大量のデータ＃13313 @ 栄光を書き込むときにRaftstore の輻輳を緩和します。
  • リーダー移行プロセス中のQPSジッターを回避するために、リージョンのリーダーを移行する前にエントリキャッシュをウォームアップします＃13060 @ コスベン
  • json_constrains演算子をコプロセッサー＃13592 @ 立振環にプッシュダウンする機能をサポート
  • いくつかのシナリオでフラッシュパフォーマンスを向上させるために、 CausalTsProviderに非同期関数を追加します＃13428 @ 沢民州

• PD

  • ホットリージョンスケジューラのv2アルゴリズムがGAになりました。一部のシナリオでは、v2アルゴリズムは両方の構成ディメンションでより適切なバランスを実現し、無効なスケジューリング＃5021 @ フンドゥンDMを削減できます。
  • オペレータステップのタイムアウトメカニズムを最適化して、早期のタイムアウト＃5596 @ バッファフライを回避する
  • 大規模クラスタのスケジューラのパフォーマンスを向上＃5473 @ バッファフライ
  • PD ＃5637 @ lhy1024では提供されない外部タイムスタンプの使用をサポートします

• TiFlash

  • TiFlash MPPエラー処理ロジックをリファクタリングして、MPP ＃5095 @ ウィンドトーカーの安定性をさらに向上します。
  • TiFlash計算プロセスのソートを最適化し、結合と集計＃5294 @ ソロツグキー処理を最適化します。
  • デコード時のメモリ使用量を最適化し、冗長な転送列を削除して結合パフォーマンスを向上させる＃6157 @ イービン87

• ツール

  • TiDBダッシュボード

    • 監視ページでのTiFlashメトリックの表示をサポートし、そのページ＃1440 @ イニシュ9506でのメトリックの表示を最適化します。
    • スロークエリリストとSQLステートメントリストに結果の行数を表示します＃1443 @ バウリン
    • Alertmanager が存在しない場合に Alertmanager エラーを報告しないようにダッシュボードを最適化します＃1444 @ バウリン

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

    • メタデータのロードメカニズムを改善しました。メタデータは必要な場合にのみメモリにロードされるため、PITR ＃38404 @ ユジュンセンのメモリ使用量が大幅に削減されます。

  • TiCDC

    • 交換パーティションDDLステートメント＃639 @ アズドンメンの複製をサポート
    • MQシンクモジュール＃7353 @ ハイラスティンの非バッチ送信パフォーマンスを向上
    • テーブルに多数のリージョン＃7078 ＃7281 @ スドジがある場合の TiCDC プラーのパフォーマンスを向上
    • 同期ポイントが有効な場合、 tidb_enable_external_ts_read変数を使用して下流 TiDB の履歴データの読み取りをサポートします＃7419 @ アズドンメン
    • レプリケーションの安定性を向上させるために、トランザクション分割を有効にし、セーフモードをデフォルトで無効にします＃7505 @ アズドンメン

  • TiDB データ移行 (DM)

    • dmctl ＃7246 @ ブチュイトデゴウから不要なコマンドoperate-source updateを削除します
    • 上流データベースがTiDBと互換性のないDDL文を使用している場合、DMの完全インポートが失敗する問題を修正しました。TiDBでサポートされているDDL文を使用して、事前にTiDBでターゲットテーブルのスキーマを手動で作成しておくことで、インポートを確実に成功させることができます＃37984 @ ランス6716

  • TiDB Lightning

    • ファイルスキャンロジックを最適化して、スキーマファイル＃38598 @ dsdashunのスキャンを高速化します。

バグ修正

• TiDB

  • 新しいインデックス＃38165 @ 接線を作成した後に発生する可能性のあるインデックスの不整合の問題を修正しました
  • INFORMATION_SCHEMA.TIKV_REGION_STATUSテーブル＃38407 @ CbcWestwolfの権限の問題を修正
  • mysql.tables_privテーブル＃38293 @ CbcWestwolfでgrantorフィールドが欠落している問題を修正しました
  • 共通テーブル式の結合結果が間違っている可能性がある問題を修正＃38170 @ wjhuang2016
  • 共通テーブル式の結合結果が間違っている可能性がある問題を修正＃37928 @ ヤンケオ
  • トランザクションリージョン番号監視パネルの情報が正しくない問題を修正＃38139 @ ジャッキーsp
  • システム変数tidb_constraint_check_in_place_pessimistic内部トランザクションに影響を与える可能性がある問題を修正しました。変数のスコープはSESSIONに変更されました＃38766 @ エキシウム
  • クエリ内の条件が誤って投影＃35623 @ 思い出させるにプッシュダウンされる問題を修正しました
  • ANDとOR間違ったisNullRejectedチェック結果が間違ったクエリ結果＃38304 @ イーサールを引き起こす問題を修正しました
  • 外部結合が除去されるときにORDER BY in GROUP_CONCATが考慮されず、間違ったクエリ結果＃18216 @ ウィノロスが発生する問題を修正しました。
  • 結合したテーブルの再配置 ＃38736 @ ウィノロスによって誤ってプッシュダウンされた条件が破棄されたときに発生する間違ったクエリ結果の問題を修正しました。

• TiKV

  • cgroupとmountinfoレコードが複数ある場合、TiDB が Gitpod で起動に失敗する問題を修正しました＃13660 @ タボキ
  • TiKVメトリックの誤った表現を修正tikv_gc_compaction_filtered ＃13537 @ 定義2014
  • 異常なdelete_files_in_range ＃13534 @ タボキによって引き起こされるパフォーマンスの問題を修正
  • スナップショット取得中に期限切れのリースが原因で発生する異常なリージョン競合を修正＃13553 @ スペードA-タン
  • 最初のバッチ＃13672 ＃13704 ＃13723 @ HuSharpでFLASHBACK失敗したときに発生したエラーを修正

• PD

  • 不正確なストリームタイムアウトを修正し、リーダーのスイッチオーバーを高速化＃5207 @ キャビンフィーバーB

• TiFlash

  • PageStorage GC がページ削除マーカーを適切にクリアしない場合に発生する、WAL ファイルのサイズが大きすぎることによる OOM 問題を修正しました＃6163 @ ジェイソン・ファン

• ツール

  • TiDBダッシュボード

    • 特定の複雑な SQL 文の実行プランをクエリする際の TiDB OOM 問題を修正＃1386 @ バウリン
    • NgMonitoring が PD ノード＃164 @ 中zcへの接続を失ったときに、 Top SQLスイッチが有効にならない可能性がある問題を修正しました。

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

    • 復元プロセス中にPDリーダースイッチによって発生する復元失敗の問題を修正＃36910 @ モクイシュル28
    • ログバックアップタスクを一時停止できない問題を修正＃38250 @ ジョッカウ
    • BRがログバックアップデータを削除するときに、削除されるべきでないデータを誤って削除してしまう問題を修正＃38939 @ リーヴルス
    • Azure Blob Storage または Google Cloud Storage に保存されたログバックアップデータを初めて削除するときにBR がデータを削除できない問題を修正＃38229 @ リーヴルス

  • TiCDC

    • changefeed query結果のうちsasl-passwordが＃7182 @ ドヴェーデンでマスクされない問題を修正しました
    • etcdトランザクションでコミットされる操作が多すぎるとTiCDCが利用できなくなる問題を修正＃7131 @ アズドンメン
    • REDOログが誤って削除される可能性がある問題を修正＃6413 @ アズドンメン
    • Kafka Sink V2 ＃7344 @ ハイラスティンでワイドテーブルを複製する際のパフォーマンス低下を修正
    • チェックポイント ts が誤って＃7274 @ ハイラスティンに進められる可能性がある問題を修正しました
    • マウンタモジュール＃7235 @ ハイラスティンのログレベルが不適切であるためにログが多すぎる問題を修正しました
    • TiCDC クラスタに＃4051 @ アズドンメンという 2 人の所有者が存在する可能性がある問題を修正しました

  • TiDB データ移行 (DM)

    • DM WebUIが間違ったallow-listパラメータ＃7096 @ ズービンウーを生成する問題を修正しました
    • DM ワーカーが開始または停止するときに、一定の確率でデータ競合が発生する問題を修正しました＃6401 @ liumengya94
    • DM がUPDATEまたはDELETEステートメントを複製したが、対応する行データが存在しない場合、DM がイベント＃6383 @ GMHDBJDを黙って無視する問題を修正しました。
    • query-statusコマンド＃7189 @ GMHDBJDを実行した後にsecondsBehindMasterフィールドが表示されない問題を修正しました
    • チェックポイントの更新により大規模なトランザクション＃5010 @ ランス6716がトリガーされる可能性がある問題を修正しました
    • フルタスクモードで、タスクが同期ステージに入ってすぐに失敗すると、DM が上流のテーブルスキーマ情報＃7159 @ ランス6716を失う可能性がある問題を修正しました。
    • 整合性チェックが有効になっているときにデッドロックが発生する可能性がある問題を修正＃7241 @ ブチュイトデゴウ
    • タスクの事前チェックにテーブルINFORMATION_SCHEMA ＃7317 @ ランス6716のSELECT権限が必要である問題を修正しました
    • 空のTLS構成によってエラー＃7384 @ liumengya94が発生する問題を修正

  • TiDB Lightning

    • binaryエンコード形式＃38351 @ dsdashunの文字列型列を含むターゲット テーブルに Apache Parquet ファイルをインポートする際のインポート パフォーマンスの低下を修正しました。

  • TiDBDumpling

    • Dumpling が多数のテーブル＃36549 @ ランス6716をエクスポートするときにタイムアウトする可能性がある問題を修正しました
    • 一貫性ロックが有効になっているが、アップストリームにターゲットテーブル＃38683 @ ランス6716がない場合に報告されるロックエラーを修正しました

寄稿者

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

• 645775992
• アンDJ
• アンドリュー・ディ
• エルワドバ
• ふざ1989
• ゴールドウィンド・ティング (初回投稿者)
• h3n4l
• イグスリン (初回投稿者)
• ihcsim
• ジガオルオ
• モルゴ
• ランキシー
• シェンキデバオジ (初回投稿者)
• 桃峰流 (初回投稿者)
• TszKitLo40
• wxbty (初回投稿者)
• zgcbj