TiDB 7.1.0 リリースノート

発売日: 2023年5月31日

TiDB バージョン: 7.1.0

クイックアクセス: クイックスタート | 実稼働環境への導入

TiDB 7.1.0 は長期サポートリリース (LTS) です。

以前の LTS 6.5.0 と比較して、7.1.0 には、 6.6.0-DMR 、 7.0.0-DMRでリリースされた新機能、改善、バグ修正が含まれているだけでなく、次の主要な機能と改善も導入されています。

機能の詳細

パフォーマンス

• パーティション化されたRaft KVstorageエンジンを強化する (実験的) ＃11515 ＃12842 @ 忙しいカケス @ トニー @ タボキ @ バッファフライ @ 5kbpsの @ スペードA-タン @ ノルーシュ

  TiDB v6.6.0 では、実験的機能として Partitioned Raft KVstorageエンジンが導入されました。このstorageエンジンは、複数の RocksDB インスタンスを使用して TiKVリージョンデータを保存し、各リージョンのデータは独立した RocksDB インスタンスに保存されます。新しいストレージ エンジンは、RocksDB インスタンス内のファイルの数とレベルをより適切に制御し、リージョン間のデータ操作の物理的な分離を実現し、より多くのデータを安定して管理することをサポートします。元の TiKVstorageエンジンと比較して、Partitioned Raft KVstorageエンジンを使用すると、同じハードウェア条件と読み取りと書き込みの混在シナリオで、書き込みスループットが約 2 倍になり、エラスティック スケーリング時間が約 4/5 短縮されます。

  TiDB v7.1.0 では、Partitioned Raft KVstorageエンジンがTiDB Lightning、 BR、TiCDC などのツールをサポートしています。

  現在、この機能は実験的であり、本番環境での使用は推奨されません。このエンジンは新しく作成されたクラスターでのみ使用でき、元の TiKVstorageエンジンから直接アップグレードすることはできません。

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

• TiFlash は遅延マテリアライゼーション (GA) ＃5829 @ ロイド・ポティガーをサポートします

  v7.0.0 では、クエリ パフォーマンスを最適化するための実験的機能として、 TiFlashに遅延マテリアライゼーションが導入されました。この機能は、デフォルトでは無効になっています ( tidb_opt_enable_late_materializationシステム変数はデフォルトでOFFに設定されます)。フィルター条件 ( WHERE句) を含むSELECTステートメントを処理する場合、 TiFlash はクエリに必要な列からすべてのデータを読み取り、クエリ条件に基づいてデータをフィルター処理して集計します。遅延マテリアライゼーションを有効にすると、TiDB はフィルター条件の一部を TableScan 演算子にプッシュダウンすることをサポートします。つまり、 TiFlash は最初に TableScan 演算子にプッシュダウンされたフィルター条件に関連する列データをスキャンし、条件を満たす行をフィルター処理してから、これらの行の他の列データをスキャンしてさらに計算するため、IO スキャンとデータ処理の計算が削減されます。

  v7.1.0 以降、 TiFlash の遅延マテリアライゼーション機能が一般に利用可能になり、デフォルトで有効になっています ( tidb_opt_enable_late_materializationシステム変数はデフォルトでONに設定されます)。TiDB オプティマイザーは、クエリの統計とフィルター条件に基づいて、どのフィルターを TableScan オペレーターにプッシュダウンするかを決定します。

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

• TiFlashは、ネットワーク伝送のオーバーヘッドに応じてMPP Joinアルゴリズムを自動的に選択することをサポートしています＃7084 @ ソロッツ

  TiFlash MPP モードは複数の結合アルゴリズムをサポートします。v7.1.0 より前では、TiDB はtidb_broadcast_join_threshold_countとtidb_broadcast_join_threshold_size変数と実際のデータ量に基づいて、MPP モードでブロードキャスト ハッシュ結合アルゴリズムを使用するかどうかを決定します。

  v7.1.0 では、TiDB はtidb_prefer_broadcast_join_by_exchange_data_size変数を導入しました。これは、ネットワーク伝送の最小オーバーヘッドに基づいて MPP Join アルゴリズムを選択するかどうかを制御します。この変数はデフォルトで無効になっており、デフォルトのアルゴリズム選択方法は v7.1.0 以前と同じままであることを示しています。変数をONに設定すると有効になります。有効にすると、 tidb_broadcast_join_threshold_countとtidb_broadcast_join_threshold_size変数を手動で調整する必要がなくなり (この時点では両方の変数は有効になりません)、TiDB は異なる Join アルゴリズムによるネットワーク伝送のしきい値を自動的に推定し、全体的なオーバーヘッドが最小のアルゴリズムを選択するため、ネットワーク トラフィックが削減され、MPP クエリのパフォーマンスが向上します。

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

• 読み取りホットスポットを軽減するために負荷ベースのレプリカ読み取りをサポートする＃14151 @ スティクナーフ @ あなた06

  読み取りホットスポットのシナリオでは、ホットスポット TiKV ノードは読み取り要求を時間内に処理できず、読み取り要求がキューイングされます。ただし、この時点ですべての TiKV リソースが使い果たされるわけではありません。レイテンシーを削減するために、TiDB v7.1.0 では負荷ベースのレプリカ読み取り機能が導入され、これにより、TiDB はホットスポット TiKV ノードでキューイングすることなく、他の TiKV ノードからデータを読み取ることができます。読み取り要求のキューの長さは、 tidb_load_based_replica_read_thresholdシステム変数を使用して制御できます。リーダー ノードの推定キュー時間がこのしきい値を超えると、TiDB はフォロワー ノードからのデータの読み取りを優先します。この機能により、読み取りホットスポットを分散させない場合と比較して、読み取りホットスポットのシナリオで読み取りスループットが 70% ～ 200% 向上します。

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

• 非準備済みステートメントの実行プランをキャッシュする機能の強化 (実験的) ＃36598 @ qw4990

  TiDB v7.0.0 では、同時実行 OLTP の負荷容量を向上させるための実験的機能として、準備されていないプラン キャッシュが導入されています。v7.1.0 では、TiDB はこの機能を強化し、より多くの SQL ステートメントのキャッシュをサポートします。

  メモリ使用率を向上させるために、TiDB v7.1.0 では、準備されていないプラン キャッシュと準備されたプラン キャッシュのキャッシュ プールが統合されます。システム変数tidb_session_plan_cache_sizeを使用してキャッシュ サイズを制御できます。システム変数tidb_prepared_plan_cache_sizeとtidb_non_prepared_plan_cache_size非推奨です。

  前方互換性を維持するために、以前のバージョンから v7.1.0 以降のバージョンにアップグレードする場合、キャッシュ サイズtidb_session_plan_cache_size tidb_prepared_plan_cache_sizeと同じ値のままになり、 tidb_enable_non_prepared_plan_cacheアップグレード前の設定のままになります。十分なパフォーマンス テストを行った後、 tidb_enable_non_prepared_plan_cacheを使用して、準備されていないプラン キャッシュを有効にすることができます。新しく作成されたクラスターでは、準備されていないプラン キャッシュはデフォルトで有効になっています。

  準備されていないプラン キャッシュは、デフォルトでは DML ステートメントをサポートしません。この制限を削除するには、 tidb_enable_non_prepared_plan_cache_for_dmlシステム変数をONに設定します。

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

• TiDB 分散実行フレームワーク (DXF) のサポート (実験的) ＃41495 @ ベンジャミン2037

  TiDB v7.1.0 より前では、1 つの TiDB ノードのみが DDL 所有者として機能し、同時に DDL タスクを実行できました。TiDB v7.1.0 以降の新しい DXF では、複数の TiDB ノードが同じ DDL タスクを並行して実行できるため、TiDB クラスターのリソースをより有効に活用し、DDL のパフォーマンスを大幅に向上できます。さらに、TiDB ノードを追加することで、DDL のパフォーマンスを直線的に向上させることができます。この機能は現在実験的であり、 ADD INDEX操作のみをサポートしていることに注意してください。

  DXFを使用するには、 tidb_enable_dist_taskの値をONに設定します。

  SET GLOBAL tidb_enable_dist_task = ON;
  

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

信頼性

• リソース コントロールが一般提供 (GA) される＃38825 @ ノルーシュ @ ボーンチェンジャー @ 栄光 @ 天菜まお @ コナー1996 @ じゃがいも @ ネス @ キャビンフィーバーB @ ヒューシャープ

  TiDB は、リソース グループに基づくリソース制御機能を強化し、v7.1.0 で GA になりました。この機能により、TiDB クラスターのリソース利用効率とパフォーマンスが大幅に向上します。リソース制御機能の導入は、TiDB にとって画期的な出来事です。分散データベース クラスターを複数の論理ユニットに分割し、異なるデータベース ユーザーを対応するリソース グループにマップし、必要に応じて各リソース グループのクォータを設定できます。クラスター リソースが制限されている場合、同じリソース グループ内のセッションで使用されるすべてのリソースはクォータに制限されます。このように、リソース グループが過剰に消費されても、他のリソース グループのセッションには影響しません。

  この機能により、異なるシステムの複数の中小規模のアプリケーションを 1 つの TiDB クラスターに統合できます。アプリケーションのワークロードが大きくなっても、他のアプリケーションの正常な動作には影響しません。システムのワークロードが低い場合は、設定されたクォータを超えても、ビジー状態のアプリケーションに必要なシステム リソースを割り当てることができるため、リソースを最大限に活用できます。さらに、リソース制御機能を合理的に使用すると、クラスターの数を減らし、運用と保守の難しさを軽減し、管理コストを節約できます。

  TiDB v7.1.0 では、この機能により、実際のワークロードまたはハードウェアの展開に基づいてシステム容量を見積もる機能が導入されています。この見積機能により、容量計画のより正確な参照が提供され、エンタープライズ レベルのシナリオの安定性のニーズを満たすために TiDB リソース割り当てをより適切に管理できるようになります。

  ユーザー エクスペリエンスを向上させるために、TiDB ダッシュボードはリソース マネージャー ページを提供します。このページでリソース グループの構成を表示し、クラスターの容量を視覚的に見積もって、適切なリソース割り当てを容易にすることができます。

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

• 高速オンラインDDLのチェックポイントメカニズムをサポートし、フォールトトレランスと自動リカバリ機能を向上させます＃42164 @ タンジェンタ

  TiDB v7.1.0 では、 高速オンラインDDLのチェックポイント メカニズムが導入され、Fast Online DDL のフォールト トレランスと自動リカバリ機能が大幅に向上しました。障害により TiDB 所有者ノードが再起動または変更された場合でも、TiDB は定期的に自動更新されるチェックポイントから進行状況を回復できるため、DDL 実行の安定性と効率が向上します。

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

• バックアップと復元はチェックポイント復元＃42339 @ リーヴルスをサポートします

  スナップショットの復元またはログの復元は、ディスクの枯渇やノードのクラッシュなどの回復可能なエラーにより中断される可能性があります。TiDB v7.1.0 より前では、エラーに対処した後でも中断前の回復の進行状況は無効になり、復元を最初からやり直す必要がありました。大規模なクラスターの場合、これにはかなりの追加コストがかかります。

  TiDB v7.1.0 以降、バックアップと復元 (BR) にチェックポイント復元機能が導入され、中断された復元を続行できるようになりました。この機能により、中断された復元の回復の進行状況のほとんどを保持できます。

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

• 統計＃42160 @ 翻訳者のロード戦略を最適化する

  TiDB v7.1.0 では、軽量統計初期化が実験的機能として導入されています。軽量統計初期化により、起動時にロードする必要がある統計の数が大幅に削減され、統計のロード速度が向上します。この機能により、複雑なランタイム環境での TiDB の安定性が向上し、TiDB ノードの再起動時にサービス全体に与える影響が軽減されます。この機能を有効にするには、パラメータlite-init-statsからtrueに設定できます。

  TiDB の起動時に、初期統計が完全にロードされる前に実行される SQL ステートメントの実行プランが最適ではない場合があり、パフォーマンスの問題が発生します。このような問題を回避するために、TiDB v7.1.0 では構成パラメータforce-init-statsが導入されています。このオプションを使用すると、起動時に統計の初期化が完了した後にのみ TiDB がサービスを提供するかどうかを制御できます。このパラメータはデフォルトでは無効になっています。

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

• TiCDCは単一行データのデータ整合性検証機能をサポートしています＃8718 ＃42747 @ 3エースショーハンド @ ジグアン

  v7.1.0 以降、TiCDC では、チェックサム アルゴリズムを使用して単一行データの整合性を検証するデータ整合性検証機能が導入されています。この機能は、TiDB からデータを書き込み、それを TiCDC 経由で複製し、それを Kafka クラスターに書き込むプロセスでエラーが発生していないかどうかを確認するのに役立ちます。データ整合性検証機能は、Kafka をダウンストリームとして使用する変更フィードのみをサポートし、現在は Avro プロトコルをサポートしています。

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

• TiCDCはDDLレプリケーション操作＃8686 @ ハイラスティンを最適化します

  v7.1.0 より前では、大きなテーブルのすべての行に影響する DDL 操作 (列の追加や削除など) を実行すると、TiCDC のレプリケーションレイテンシーが大幅に増加していました。v7.1.0 以降、TiCDC はこのレプリケーション操作を最適化し、DDL 操作によるダウンストリームレイテンシーへの影響を軽減します。

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

• TiB レベルのデータをインポートする際のTiDB Lightningの安定性を向上＃43510 ＃43657 @ D3ハンター @ ランス6716

  v7.1.0 以降、 TiDB Lightningには、TiB レベルのデータをインポートする際の安定性を向上させるための 4 つの構成項目が追加されました。

  • tikv-importer.region-split-batch-size 、バッチでリージョンを分割するときのリージョンの数を制御します。デフォルト値は4096です。
  • tikv-importer.region-split-concurrency 、リージョンを分割する際の同時実行性を制御します。デフォルト値は CPU コアの数です。
  • tikv-importer.region-check-backoff-limit 、分割および分散操作後にリージョンがオンラインになるまで待機する再試行回数を制御します。デフォルト値は1800で、最大再試行間隔は 2 秒です。再試行の間にいずれかのリージョンがオンラインになった場合、再試行回数は増加しません。
  • tikv-importer.pause-pd-scheduler-scope 、 TiDB Lightning がPD スケジューリングを一時停止する範囲を制御します。値のオプションは"table"と"global"です。デフォルト値は"table"です。v6.1.0 より前のバージョンの TiDB では、データのインポート中にグローバル スケジューリングを一時停止する"global"オプションのみを設定できます。v6.1.0 以降では、 "table"オプションがサポートされています。これは、ターゲット テーブル データを格納するリージョンに対してのみスケジューリングが一時停止されることを意味します。データ量が多いシナリオでは、安定性を向上させるために、この設定項目を"global"に設定することをお勧めします。

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

構文

• INSERT INTO SELECTステートメントを使用したTiFlashクエリ結果の保存をサポート (GA) ＃37515 @ ゲンリキ

  v6.5.0 以降、TiDB はINSERT INTO SELECTステートメントのSELECT句 (分析クエリ) をTiFlashにプッシュダウンすることをサポートしています。これにより、 TiFlashクエリ結果をINSERT INTOで指定された TiDB テーブルに簡単に保存してさらに分析することができ、結果のキャッシュ (つまり、結果のマテリアライゼーション) として機能します。

  v7.1.0 では、この機能が一般に提供されています。 INSERT INTO SELECTステートメントのSELECT句の実行中に、オプティマイザーは、 SQL モードとTiFlashレプリカのコスト見積もりに基づいて、クエリをTiFlashにプッシュダウンするかどうかをインテリジェントに決定できます。したがって、実験的フェーズで導入されたtidb_enable_tiflash_read_for_write_stmtシステム変数は非推奨になりました。TiFlash のINSERT INTO SELECTステートメントの計算ルールはSTRICT SQL Mode要件を満たしていないため、TiDB では、現在のセッションのSQL モードが厳密でない場合にのみ、 INSERT INTO SELECTステートメントのSELECT句をTiFlashにプッシュダウンできます。つまり、 sql_mode値にSTRICT_TRANS_TABLESとSTRICT_ALL_TABLES含まれません。

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

• MySQL 互換のマルチ値インデックスが一般提供 (GA) される＃39592 @ 雄吉偉 @ qw4990 @ ヤンケオ

  JSON 列の配列の値をフィルタリングすることは一般的な操作ですが、通常のインデックスではこのような操作を高速化することはできません。配列に複数値インデックスを作成すると、フィルタリングのパフォーマンスが大幅に向上します。JSON 列の配列に複数値インデックスがある場合は、複数値インデックスを使用してMEMBER OF() 、 JSON_CONTAINS() 、およびJSON_OVERLAPS()関数で検索条件をフィルタリングできるため、I/O 消費が削減され、操作速度が向上します。

  v7.1.0 では、多値インデックス機能が一般提供 (GA) されます。より完全なデータ型をサポートし、TiDB ツールと互換性があります。多値インデックスを使用すると、本番環境での JSON 配列の検索操作を高速化できます。

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

• ハッシュおよびキーパーティションテーブルのパーティション管理を改善する＃42728 @ ミョンス

  v7.1.0 より前では、TiDB のハッシュおよびキー パーティション テーブルは、 TRUNCATE PARTITIONパーティション管理ステートメントのみをサポートしています。v7.1.0 以降では、ハッシュおよびキー パーティション テーブルは、 ADD PARTITIONおよびCOALESCE PARTITIONパーティション管理ステートメントもサポートします。したがって、必要に応じて、ハッシュおよびキー パーティション テーブルのパーティション数を柔軟に調整できます。たとえば、 ADD PARTITIONステートメントでパーティション数を増やしたり、 COALESCE PARTITIONステートメントでパーティション数を減らしたりすることができます。

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

• 範囲INTERVALパーティションの構文が一般公開（GA） ＃35683 @ ミョンスになります

  範囲 INTERVAL パーティション分割 (v6.3.0 で導入) の構文が GA になりました。この構文を使用すると、すべてのパーティションを列挙せずに、必要な間隔で範囲パーティション分割を定義できるため、範囲パーティション分割の DDL ステートメントの長さが大幅に短縮されます。構文は、元の範囲パーティション分割の構文と同じです。

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

• 生成された列はbb7133で一般公開 (GA) されます

  生成された列は、データベースにとって貴重な機能です。テーブルを作成するときに、列の値が、ユーザーによって明示的に挿入または更新されるのではなく、テーブル内の他の列の値に基づいて計算されるように定義できます。この生成された列は、仮想列または保存された列のいずれかになります。TiDB は以前のバージョンから MySQL 互換の生成列をサポートしており、この機能は v7.1.0 で GA になります。

  生成された列を使用すると、TiDB の MySQL 互換性が向上し、MySQL からの移行プロセスが簡素化されます。また、データ保守の複雑さが軽減され、データの一貫性とクエリの効率が向上します。

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

DB操作

• DDL 操作を手動でキャンセルせずに、スムーズなクラスタ アップグレードをサポート (実験的) ＃39751 @ ジムララ

  TiDB v7.1.0 より前のバージョンでは、クラスターをアップグレードするには、アップグレード前に実行中またはキューに入れられた DDL タスクを手動でキャンセルし、アップグレード後に再度追加する必要があります。

  よりスムーズなアップグレード エクスペリエンスを提供するために、TiDB v7.1.0 では DDL タスクの自動一時停止と再開がサポートされています。v7.1.0 以降では、事前に DDL タスクを手動でキャンセルしなくてもクラスターをアップグレードできます。TiDB はアップグレード前に実行中またはキューに入れられたユーザー DDL タスクを自動的に一時停止し、ローリング アップグレード後にこれらのタスクを再開するため、TiDB クラスターのアップグレードが容易になります。

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

可観測性

• オプティマイザ診断情報の強化＃43122 @ 時間と運命

  十分な情報を取得することが、SQL パフォーマンス診断の鍵となります。v7.1.0 では、TiDB はさまざまな診断ツールにオプティマイザー ランタイム情報を引き続き追加し、実行プランの選択方法に関するより詳細な情報を提供し、SQL パフォーマンスの問題のトラブルシューティングを支援します。新しい情報には次のものが含まれます。

  • PLAN REPLAYERの出力はdebug_trace.json 。
  • EXPLAINの出力におけるoperator info部分的な統計詳細。
  • 遅いクエリのStatsフィールドの部分的な統計詳細。

  詳細については、 PLAN REPLAYERを使用してクラスターの現場情報を保存および復元します 、 EXPLAINウォークスルー 、 遅いクエリを特定するを参照してください。

Security

• TiFlashシステムテーブル情報のクエリに使用するインターフェイスを置き換えます＃6941 @ フロービーハッピー

  v7.1.0 以降、TiDB のINFORMATION_SCHEMA.TIFLASH_TABLESおよびINFORMATION_SCHEMA.TIFLASH_SEGMENTSシステム テーブルのクエリ サービスを提供するときに、 TiFlash はHTTP ポートではなく gRPC ポートを使用するため、HTTP サービスのセキュリティ リスクを回避できます。

• LDAP認証＃43580 @ ヤンケオをサポート

  v7.1.0 以降、TiDB は LDAP 認証をサポートし、 authentication_ldap_saslとauthentication_ldap_simple 2 つの認証プラグインを提供します。

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

• データベース監査機能の強化 (Enterprise Edition)

  v7.1.0 では、TiDB Enterprise Edition のデータベース監査機能が強化され、その機能が大幅に拡張され、ユーザー エクスペリエンスが向上して、企業のデータベース セキュリティ コンプライアンスのニーズに対応できるようになりました。

  • より詳細な監査イベント定義とよりきめ細かい監査設定のために、「フィルター」と「ルール」の概念を導入します。
  • JSON 形式でのルールの定義をサポートし、よりユーザーフレンドリーな構成方法を提供します。
  • 自動ログローテーションとスペース管理関数を追加し、保持時間とログサイズの 2 つの次元でのログローテーションの構成をサポートします。
  • 監査ログをTEXTと JSON 形式の両方で出力できるようにサポートし、サードパーティ ツールとの統合を容易にします。
  • 監査ログの編集をサポートします。セキュリティを強化するために、すべてのリテラルを置き換えることができます。

  データベース監査は、TiDB Enterprise Edition の重要な機能です。この機能は、企業がデータのセキュリティとコンプライアンスを確保するための強力な監視および監査ツールを提供します。この機能は、企業の管理者がデータベース操作のソースと影響を追跡して、違法なデータの盗難や改ざんを防止するのに役立ちます。さらに、データベース監査は、企業がさまざまな規制およびコンプライアンス要件を満たすのにも役立ち、法的および倫理的コンプライアンスを確保します。この機能は、企業の情報セキュリティにとって重要なアプリケーション価値を持っています。

  詳細については、 ユーザーガイド参照してください。この機能は、TiDB Enterprise Edition に含まれています。この機能を使用するには、 TiDBエンタープライズページに移動して TiDB Enterprise Edition を入手してください。

互換性の変更

注記：

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

行動の変化

• セキュリティを向上させるため、 TiFlashはHTTPサービスポート（デフォルト8123 ）を廃止し、代わりにgRPCポートを使用します。

  TiFlashを v7.1.0 にアップグレードした場合、TiDB を v7.1.0 にアップグレードする際に、TiDB はTiFlashシステム テーブル ( INFORMATION_SCHEMA.TIFLASH_TABLESおよびINFORMATION_SCHEMA.TIFLASH_SEGMENTS ) を読み取ることができません。

• TiDB バージョン v6.2.0 から v7.0.0 のTiDB Lightning は、TiDB クラスターのバージョンに基づいてグローバル スケジューリングを一時停止するかどうかを決定します。TiDB クラスター バージョン >= v6.1.0 の場合、スケジューリングはターゲット テーブル データを格納するリージョンに対してのみ一時停止され、ターゲット テーブルのインポートが完了すると再開されます。その他のバージョンの場合、 TiDB Lightning はグローバル スケジューリングを一時停止します。TiDB v7.1.0 以降では、 pause-pd-scheduler-scope構成することで、グローバル スケジューリングを一時停止するかどうかを制御できます。デフォルトでは、 TiDB Lightning はターゲット テーブル データを格納するリージョンに対してスケジューリングを一時停止します。ターゲット クラスターのバージョンが v6.1.0 より前の場合、エラーが発生します。この場合、パラメータの値を"global"に変更して再試行できます。

• TiDB v7.1.0 でFLASHBACK CLUSTER TO TIMESTAMP使用すると、FLASHBACK 操作が完了した後も、一部のリージョンが FLASHBACK プロセスに残ることがあります。v7.1.0 ではこの機能を使用しないことをお勧めします。詳細については、問題＃44292を参照してください。この問題が発生した場合は、 TiDB スナップショットのバックアップと復元機能を使用してデータを復元できます。

システム変数

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

改善点

• ティビ

  • SHOW INDEX結果＃42227 @ ウィノロスの Cardinality 列に対応する列の個別値の数を表示します。
  • TTLスキャンクエリがTiKVブロックキャッシュ＃43206 @ lcwangchaoに影響を与えないようにするにはSQL_NO_CACHE使用します。
  • MAX_EXECUTION_TIMEに関連するエラー メッセージを改善して、MySQL ＃43031 @ ドヴェーデンと互換性を持たせます。
  • IndexLookUp ＃26166 @ 定義2014のパーティション テーブルでの MergeSort 演算子の使用をサポート
  • MySQL ＃43576 @ アスジェと互換性を持たせるためにcaching_sha2_password拡張します

• ティクヴ

  • パーティション化されたRaft KV ＃14447 @ スペードA-タンを使用する場合、分割操作による書き込み QPS への影響を軽減します。
  • パーティション化されたRaft KV ＃14581 @ バッファフライを使用するときにスナップショットが占めるスペースを最適化します
  • TiKV ＃12362 @ 翻訳でリクエストの処理の各段階についてより詳細な時間情報を提供します
  • ログバックアップ＃13867 @ ユジュンセンで PD をメタストアとして使用します

• PD

  • スナップショットの実行の詳細に基づいてストア制限のサイズを自動的に調整するコントローラを追加します。このコントローラを有効にするには、 store-limit-versionをv2に設定します。有効にすると、スケールインまたはスケールアウトの速度を制御するためにstore limit構成を手動で調整する必要がなくなります＃6147 @ バッファフライ
  • storageエンジンが raft-kv2 ＃6297 @ バッファフライの場合、ホットスポット スケジューラによって不安定な負荷のあるリージョンが頻繁にスケジュールされるのを避けるために、履歴負荷情報を追加します。
  • リーダーのヘルスチェックメカニズムを追加します。etcdリーダーが配置されているPDサーバーがリーダーとして選出できない場合、PDはetcdリーダーをアクティブに切り替えて、PDリーダーが利用可能であることを確認します＃6403 @ ノルーシュ

• TiFlash

  • 分散storageおよびコンピューティングアーキテクチャにおけるTiFlash のパフォーマンスと安定性を向上＃6882 @ ジェイソン・ファン @ そよ風のような @ ジンヘリン
  • 小さい方のテーブルをビルド側として選択することで、セミ結合またはアンチセミ結合でのクエリパフォーマンスの最適化をサポートします＃7280 @ いいえ
  • デフォルト設定＃7272 @ そよ風のようなでBRおよびTiDB LightningからTiFlashへのデータ インポートのパフォーマンスを向上

• ツール

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

    • ログバックアップ＃14433 @ ジョッカウ中に TiKV 構成項目log-backup.max-flush-intervalを変更することをサポート

  • ティCDC

    • オブジェクトstorageにデータを複製するシナリオで DDL イベントが発生した場合にディレクトリ構造を最適化する＃8890 @ チャールズ・チュン96
    • TiCDC レプリケーションタスクが失敗した場合にアップストリームの GC TLS を設定する方法を最適化する＃8403 @ チャールズ・ジェン44
    • Kafka-on-Pulsar ダウンストリームへのデータ複製をサポート＃8892 @ ハイラスティン
    • オープンプロトコルプロトコルを使用して、Kafka ＃8706 @ スドジにデータを複製するときに更新が発生した後に変更された列のみを複製することをサポートします。
    • 下流の障害やその他のシナリオにおける TiCDC のエラー処理を最適化する＃8657 @ ヒック
    • TLS ＃8867 @ ハイラスティンを有効にするシナリオで認証アルゴリズムを設定するかどうかを制御する構成項目insecure-skip-verifyを追加します。

  • TiDB Lightning

    • 不均一なリージョン分布に関連する事前チェック項目の重大度レベルをCriticalからWarnに変更して、ユーザーがデータをインポートできないようにする＃42836 @ ok江
    • データのインポート中にunknown RPCが発生した場合に再試行メカニズムを追加する＃43291 @ D3ハンター
    • リージョンジョブ＃43682 @ ランス6716の再試行メカニズムを強化

バグ修正

• ティビ

  • パーティション＃42183 @ Cbcウェストウルフを再編成した後、手動でANALYZE TABLEを実行するプロンプトが表示されない問題を修正しました。
  • DROP TABLE操作が実行されているときにADMIN SHOW DDL JOBS結果にテーブル名が表示されない問題を修正＃42268 @ 天菜まお
  • Grafana モニタリング パネル＃42562 @ ピンとbでIgnore Event Per MinuteとStats Cache LRU Costチャートが正常に表示されない問題を修正しました。
  • INFORMATION_SCHEMA.COLUMNSテーブル＃43379 @ bb7133をクエリしたときにORDINAL_POSITION列が誤った結果を返す問題を修正しました
  • 権限テーブル＃41048 @ bb7133の一部の列における大文字と小文字の区別の問題を修正
  • キャッシュ テーブルに新しい列が追加された後、列＃42928 @ ルクスのデフォルト値ではなく値がNULLなる問題を修正しました。
  • 述語＃43645 @ ウィノロスをプッシュダウンするときに CTE 結果が正しくない問題を修正しました
  • 多数のパーティションとTiFlashレプリカ＃42940 @ ミョンスを持つパーティション テーブルに対してTRUNCATE TABLE実行するときに書き込み競合によって発生する DDL 再試行の問題を修正しました。
  • パーティションテーブル＃41198 ＃41200 @ ミョンスの作成時にSUBPARTITION使用すると警告が表示されない問題を修正
  • 生成された列＃40066 @ ジフハウスの値オーバーフローの問題を処理する際の MySQL との非互換性の問題を修正
  • REORGANIZE PARTITION他の DDL 操作＃42442 @ bb7133と同時に実行できない問題を修正
  • DDL でパーティション再編成タスクをキャンセルすると、後続の DDL 操作が失敗する可能性がある問題を修正＃42448 @ lcwangchao
  • 特定の条件下で削除操作のアサーションが正しくない問題を修正＃42426 @ 天菜まお
  • cgroup 情報の読み取りエラーにより、TiDBサーバーが起動できない問題を修正しました。エラー メッセージは「cgroup v1 からファイルメモリ.stat を読み取れません: /sys/ メモリ.stat を開いても、そのようなファイルまたはディレクトリはありません」です＃42659 @ ホーキングレイ
  • グローバルインデックス＃42312 @ L-メープルを持つパーティションテーブルの行のパーティションキーを更新するときに発生するDuplicate Key問題を修正します
  • TTLモニタリングパネルのScan Worker Time By Phaseチャートにデータ＃42515 @ lcwangchaoが表示されない問題を修正
  • グローバルインデックスを持つパーティションテーブルに対する一部のクエリが誤った結果を返す問題を修正＃41991 ＃42065 @ L-メープル
  • パーティションテーブル＃42180 @ ミョンスの再編成プロセス中に一部のエラー ログが表示される問題を修正しました
  • INFORMATION_SCHEMA.DDL_JOBSテーブルのQUERY列目のデータ長が列定義＃42440 @ 天菜まおを超える可能性がある問題を修正しました。
  • INFORMATION_SCHEMA.CLUSTER_HARDWAREテーブルでコンテナー＃42851 @ ホーキングレイに誤った値が表示される可能性がある問題を修正しました
  • ORDER BY + LIMIT ＃43158 @ 定義2014を使用してパーティションテーブルをクエリすると誤った結果が返される問題を修正しました。
  • 取り込み方法＃42903 @ タンジェンタを使用して複数の DDL タスクが同時に実行される問題を修正しました
  • Limit ＃24636を使用してパーティションテーブルをクエリしたときに返される誤った値を修正
  • IPv6環境で誤ったTiDBアドレスが表示される問題を修正＃43260 @ ネクスター
  • システム変数tidb_enable_tiflash_read_for_write_stmtとtidb_enable_exchange_partition ＃43281 @ ゲンリキの値が誤って表示される問題を修正しました
  • tidb_scatter_regionが有効になっている場合、パーティションが切り捨てられた後にリージョンが自動的に分割されない問題を修正＃43174 ＃43028 @ ジフハウス
  • 生成された列を持つテーブルにチェックを追加し、これらの列でサポートされていない DDL 操作のエラーを報告します＃38988 ＃24321 @ 天菜まお
  • 特定の型変換エラーでエラーメッセージが正しく表示されない問題を修正＃41730 @ ホーキングレイ
  • TiDBノードが正常にシャットダウンされた後、このノードでトリガーされたDDLタスクがキャンセルされる問題を修正＃43854 @ ジムララ
  • PDメンバーアドレスが変更されると、 AUTO_INCREMENT列目のIDの割り当てが長時間ブロックされる問題を修正＃42643 @ 天菜まお
  • DDL実行中にGC lifetime is shorter than transaction durationエラーを報告する問題を修正＃40074 @ タンジェンタ
  • メタデータ ロックが予期せず DDL 実行をブロックする問題を修正＃43755 @ 翻訳:
  • IPv6 環境＃43286 @ 定義2014でクラスターが一部のシステム ビューを照会できない問題を修正
  • 動的プルーニングモード＃43686 @ ミョンスで内部結合中にパーティションが見つからない問題を修正
  • TiDBがテーブル＃43392 @ グオシャオゲを分析するときに構文エラーを報告する問題を修正
  • テーブル名の変更中に TiCDC が行の変更の一部を失う可能性がある問題を修正＃43338 @ タンジェンタ
  • クライアントがカーソル読み取り＃38116 @ ヤンケオを使用すると TiDBサーバーがクラッシュする問題を修正しました
  • ADMIN SHOW DDL JOBS LIMIT誤った結果を返す問題を修正＃42298 @ Cbcウェストウルフ
  • UNION ＃42563 @ lcwangchaoでユニオンビューと一時テーブルをクエリするときに発生する TiDBpanic問題を修正しました。
  • トランザクション＃39664 @ 天菜まおで複数のステートメントをコミットするときにテーブル名の変更が有効にならない問題を修正しました
  • 時間変換＃42439 @ qw4990中に準備済みプラン キャッシュと準備されていないプラン キャッシュの動作間の非互換性の問題を修正しました
  • Decimal 型＃43311 @ qw4990のプラン キャッシュによって発生する誤った結果を修正しました。
  • 間違ったフィールドタイプチェック＃42459 @ アイリンキッドによる、null 認識アンチ結合 (NAAJ) での TiDBpanic問題を修正
  • RC 分離レベルでの悲観的トランザクションにおける DML 実行の失敗により、データとインデックス＃43294 @ エキシウムの間に不整合が生じる可能性がある問題を修正しました。
  • 極端なケースで、悲観的トランザクションの最初のステートメントが再試行されるときに、このトランザクションのロックを解決するとトランザクションの正確性に影響する可能性がある問題を修正しました＃42937 @ ミョンケミンタ
  • GC がロック＃43243 @ ミョンケミンタを解決するときに、まれに悲観的トランザクションの残留悲観的ロックがデータの正確性に影響を与える可能性がある問題を修正しました。
  • LOCKからPUT最適化により、特定のクエリ＃28011 @ ジグアンで重複データが返される問題を修正しました。
  • データが変更された場合、ユニークインデックスのロック動作がデータが変更されていない場合のロック動作と一致しない問題を修正＃36438 @ ジグアン

• ティクヴ

  • tidb_pessimistic_txn_fair_locking有効にすると、極端なケースでは、失敗した RPC 再試行によって期限切れになった要求が、ロック解決操作＃14551 @ ミョンケミンタ中のデータの正確性に影響を与える可能性がある問題を修正しました。
  • tidb_pessimistic_txn_fair_locking有効にすると、極端なケースでは、失敗した RPC 再試行によって期限切れのリクエストが発生し、トランザクションの競合が無視され、トランザクションの一貫性＃14311 @ ミョンケミンタに影響する可能性がある問題を修正しました。
  • 暗号化キーIDの競合により古いキー＃14585 @ タボキが削除される可能性がある問題を修正
  • クラスターを以前のバージョンから v6.5 以降のバージョンにアップグレードしたときに、蓄積されたロック レコードによって発生するパフォーマンス低下の問題を修正しました＃14780 @ ミョンケミンタ
  • PITRリカバリプロセス＃14313 @ ユジュンセン中にraft entry is too largeエラーが発生する問題を修正
  • PITRリカバリプロセス中にlog_batch 2GBを超えるためTiKVがパニックになる問題を修正＃13848 @ ユジュンセン

• PD

  • TiKV パニック＃6252 @ ヒューシャープ後に PD 監視パネルのlow space storeの数値が異常になる問題を修正
  • PDリーダースイッチ＃6366 @ イオマンサス後にリージョンヘルス監視データが削除される問題を修正
  • ルールチェッカーがschedule=denyラベル＃6426 @ ノルーシュの不健全な領域を修復できない問題を修正しました
  • TiKV またはTiFlashの再起動後に既存のラベルの一部が失われる問題を修正＃6467 @ じゃがいも
  • レプリケーションモード＃14704 @ ノルーシュの学習ノードがある場合にレプリケーションステータスを切り替えることができない問題を修正

• TiFlash

  • 遅延マテリアライゼーション＃7455 @ ロイド・ポティガーを有効にした後、 TIMESTAMPまたはTIMEタイプのデータをクエリするとエラーが返される問題を修正しました。
  • 大規模な更新トランザクションにより、 TiFlashが繰り返しエラーを報告し、 ＃7316 @ ジェイソン・ファンを再起動する可能性がある問題を修正しました。

• ツール

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

    • クラスター＃42973 @ ユジュンセンで TiKV ノードがクラッシュしたときにバックアップが遅くなる問題を修正
    • 一部のケースでバックアップの失敗により不正確なエラーメッセージが表示される問題を修正＃43236 @ ユジュンセン

  • ティCDC

    • TiCDC タイムゾーン設定＃8798 @ ハイラスティンの問題を修正
    • PDアドレスまたはリーダーに障害が発生したときにTiCDCが自動的に回復できない問題を修正＃8812 ＃8877 @ アズドンメン
    • 上流の TiKV ノードの 1 つがクラッシュするとチェックポイントの遅延が増加する問題を修正＃8858 @ ヒック
    • オブジェクトstorageにデータを複製する際に、上流のEXCHANGE PARTITION操作が下流の＃8914 @ チャールズ・チュン96に正しく複製されない問題を修正しました。
    • いくつかの特殊なシナリオでソートコンポーネントのメモリ使用量が過剰になることによって発生する OOM 問題を修正＃8974 @ ヒック
    • 下流の Kafka シンクがローリング再起動されたときに発生する TiCDC ノードpanicを修正＃9023 @ アズドンメン

  • TiDB データ移行 (DM)

    • レプリケーション＃7028 @ ランス6716中に latin1 データが破損する可能性がある問題を修正しました

  • TiDBDumpling

    • UNSIGNED INTEGER型の主キーがチャンク＃42620 @ リチュンジュの分割に使用できない問題を修正
    • --output-file-templateが誤って＃42391 @ リチュンジュに設定されている場合に TiDB Dumpling がpanicになる可能性がある問題を修正しました

  • TiDBBinlog

    • 失敗したDDL文＃1228 @ ok江に遭遇したときにエラーが発生する可能性がある問題を修正

  • TiDB Lightning

    • データインポート＃42456 @ ランス6716中のパフォーマンス低下の問題を修正
    • 大量のデータをインポートする際のwrite to tikv with no leader returnedの問題を修正＃43055 @ ランス6716
    • データインポート＃43197 @ D3ハンター中にログがkeys within region is empty, skip doIngest過剰になる問題を修正
    • 部分書き込み＃43363 @ ランス6716中にpanicが発生する可能性がある問題を修正
    • 幅の広いテーブル＃43728 @ D3ハンターをインポートするときに OOM が発生する可能性がある問題を修正しました
    • TiDB Lightning Grafanaダッシュボード＃43357 @ リチュンジュでデータが欠落する問題を修正
    • keyspace-name ＃43684 @ 沢民州の設定が間違っているためにインポートに失敗する問題を修正
    • 範囲の部分書き込み中にデータのインポートがスキップされる可能性がある問題を修正＃43768 @ ランス6716

パフォーマンステスト

TiDB v7.1.0 のパフォーマンスについては、 TiDB Cloud Dedicated クラスターのTPC-C パフォーマンステストレポートとSysbench パフォーマンステストレポートを参照してください。

寄稿者

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

• えり
• イーサフロー
• ヒヒフフ
• ジフハウス
• L-メープル
• ルクス
• ピンとb
• ヨークヘレン
• ユジアリスタ (初めての投稿者)