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でリリースされた新機能、改善、バグ修正が含まれているだけでなく、次の主要な機能と改善も導入されています。

機能の詳細

パフォーマンス

• Partitioned Raft KVstorageエンジンの強化 (実験的) #11515 #12842 @ ビジージェイ @ トニーシュクキ @ タボキー @ バッファフライ @ 5kbps @ SpadeA-Tang @ ノールーシュ

  TiDB v6.6.0 では、実験的機能として Partitioned Raft KVstorageエンジンが導入されています。これは、複数の RocksDB インスタンスを使用して TiKVリージョンデータを保存し、各リージョンのデータは個別の RocksDB インスタンスに独立して保存されます。新しいstorageエンジンは、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 参加アルゴリズムを自動的に選択することをサポートしています#7084 @ ソロッツグ

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

  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 はさまざまな結合アルゴリズムによってネットワーク送信のしきい値を自動的に推定し、最も小さいアルゴリズムを選択します。全体的なオーバーヘッドが増加するため、ネットワーク トラフィックが削減され、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 @ Jmポテト @ フネス @ キャビンフィーバーB @ ヒューシャープ

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

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

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

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

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

• Fast Online 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"に設定することをお勧めします。

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

SQL

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

  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 value には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ステートメントを使用してパーティションの数を減らすことができます。

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

• Range INTERVAL パーティショニングの構文が一般公開 (GA) #35683 @ むじょん

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

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

• 生成された列がbb7133で一般公開 (GA) される

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

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

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

DB操作

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

  TiDB v7.1.0 より前では、クラスターをアップグレードするには、アップグレード前に実行中の DDL タスクまたはキューに入れられた 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 認証をサポートし、2 つの認証プラグインauthentication_ldap_saslとauthentication_ldap_simpleを提供します。

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

• データベース監査機能の強化（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 スナップショットのバックアップと復元機能を使用してデータを復元できます。

システム変数

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

改善点

• TiDB

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

• TiKV

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

• PD

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

• TiFlash

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

• ツール

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

    • ログ バックアップ#14433 @ ジョッカウ中の TiKV 構成アイテムlog-backup.max-flush-intervalの変更のサポート

  • TiCDC

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

  • TiDB Lightning

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

バグの修正

• TiDB

  • パーティション#42183 @ Cbcウェストウルフを再編成した後、 ANALYZE TABLE手動で実行することについてのプロンプトが表示されない問題を修正
  • DROP TABLE操作の実行時にADMIN SHOW DDL JOBSの結果でテーブル名が欠落する問題を修正#42268 @ ティエンチャイアマオ
  • Grafana監視パネル#42562 @ ピンアンドブにおいて、チャートIgnore Event Per MinuteとStats Cache LRU Costが正常に表示されない場合がある問題を修正
  • INFORMATION_SCHEMA.COLUMNSテーブル#43379 @ bb7133をクエリすると、 ORDINAL_POSITION列が間違った結果を返す問題を修正します。
  • 権限テーブル#41048 @ bb7133の一部の列における大文字と小文字の区別の問題を修正しました。
  • キャッシュ テーブルに新しい列が追加された後、値が列のデフォルト値#42928 @ lqsではなくNULLになる問題を修正します。
  • 述語#43645 @ ウィノロスをプッシュダウンすると CTE の結果が正しくなくなる問題を修正
  • 多くのパーティションとTiFlashレプリカを含むパーティション テーブルに対してTRUNCATE TABLEを実行するときに、書き込み競合によって引き起こされる DDL 再試行の問題を修正します#42940 @ むじょん
  • パーティションテーブル#41198 #41200 @ むじょんの作成でSUBPARTITION使用すると警告が表示されない問題を修正
  • 生成されたカラム#40066 @ ジフフストでの値のオーバーフローの問題に対処するときの MySQL との非互換性の問題を修正しました。
  • REORGANIZE PARTITIONが他の DDL 操作#42442 @ bb7133と同時に実行できない問題を修正
  • DDL でパーティション再編成タスクをキャンセルすると、後続の DDL 操作が失敗する可能性がある問題を修正します#42448 @ ルクワンチャオ
  • 特定の条件下で削除操作のアサーションが正しくない問題を修正#42426 @ ティエンチャイアマオ
  • cgroup 情報の読み取りエラーにより TiDBサーバーが起動できず、エラー メッセージ「cgroup v1 からファイルメモリ.stat を読み取れません: /sys/メモリ.stat を開きます。そのようなファイルまたはディレクトリはありません」 #42659 @ ホーキングレイが表示される問題を修正します。
  • グローバル インデックス#42312 @ L-カエデを持つパーティションテーブルの行のパーティション キーを更新するときに発生するDuplicate Key問題を修正します。
  • TTL監視パネルのScan Worker Time By Phaseグラフにデータ#42515 @ ルクワンチャオが表示されない問題を修正
  • グローバル インデックスを使用したパーティション テーブルに対する一部のクエリが誤った結果を返す問題を修正します#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 環境#43260 @ ネクスターで誤った TiDB アドレスが表示される問題を修正
  • システム変数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 @ wjhuang2016
  • IPv6 環境#43286 @ 定義2014でクラスターが一部のシステム ビューをクエリできない問題を修正
  • 動的プルーニング モード#43686 @ むじょんでの内部結合中にパーティションが見つからない問題を修正
  • テーブル#43392 @ グオシャオゲを分析するときに TiDB が構文エラーを報告する問題を修正
  • テーブルの名前変更#43338 @ タンジェンタ中に TiCDC が行の変更の一部を失う可能性がある問題を修正
  • クライアントがカーソル読み取り#38116 @ ヤンケオを使用すると TiDBサーバーがクラッシュする問題を修正
  • ADMIN SHOW DDL JOBS LIMITが間違った結果#42298 @ Cbcウェストウルフを返す問題を修正
  • UNION #42563 @ ルクワンチャオを使用してユニオン ビューと一時テーブルをクエリするときに発生する TiDBpanicの問題を修正しました。
  • トランザクション#39664 @ ティエンチャイアマオで複数のステートメントをコミットすると、テーブルの名前変更が有効にならない問題を修正します。
  • 時間変換#42439 @ qw4990中の準備済みプラン キャッシュと準備されていないプラン キャッシュの動作間の非互換性の問題を修正しました。
  • Decimal type #43311 @ qw4990のプラン キャッシュによって引き起こされる間違った結果を修正しました。
  • 間違ったフィールド タイプ チェック#42459 @ アイリンキッドによる、null-aware anti join (NAAJ) での TiDBpanic問題を修正しました。
  • RC 分離レベルでの悲観的トランザクションでの DML 実行の失敗により、データとインデックス#43294 @ エキシウムの間で不整合が発生する可能性がある問題を修正します。
  • 極端な場合、悲観的トランザクションの最初のステートメントが再試行されるときに、このトランザクションのロックを解決するとトランザクションの正確性に影響を与える可能性があるという問題を修正します#42937 @ ミョンケミンタ
  • まれに、GC がロック#43243 @ ミョンケミンタを解決するときに、悲観的トランザクションの残存する悲観的ロックがデータの正確性に影響を与える可能性がある問題を修正します。
  • LOCKからPUT最適化により、特定のクエリ#28011 @ ジグアンで重複データが返される問題を修正します。
  • データが変更された場合、一意のインデックスのロック動作がデータが変更されていない場合のロック動作と一致しない問題を修正します#36438 @ ジグアン

• TiKV

  • 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エラーが発生する問題を修正
  • log_batch 2 GB #13848 @ ユジュンセンを超えたため、PITR 回復プロセス中に TiKV がパニックになる問題を修正

• PD

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

• TiFlash

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

• ツール

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

    • クラスター#42973 @ ユジュンセンで TiKV ノードがクラッシュした場合のバックアップの速度低下の問題を修正
    • 場合によってはバックアップの失敗により不正確なエラー メッセージが表示される問題を修正#43236 @ ユジュンセン

  • TiCDC

    • TiCDC タイムゾーン設定#8798 @ こんにちはラスティンの問題を修正
    • PD アドレスまたはリーダーに障害が発生した場合、TiCDC が自動的に回復できない問題を修正#8812 #8877 @ 東門
    • 上流の TiKV ノードの 1 つがクラッシュしたときにチェックポイント ラグが増加する問題を修正します#8858 @ ひっくり返る
    • オブジェクトstorageにデータをレプリケートするときに、アップストリームのEXCHANGE PARTITIONオペレーションがダウンストリーム#8914 @ CharlesCheung96に適切にレプリケートできない問題を修正します。
    • 一部の特殊なシナリオ#8974 @ ひっくり返るにおけるソーターコンポーネントの過剰なメモリ使用によって引き起こされる OOM 問題を修正します。
    • ダウンストリーム Kafka シンクがローリング再起動されるときに発生する TiCDC ノードpanicを修正します#9023 @ 東門

  • TiDB データ移行 (DM)

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

  • TiDBDumpling

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

  • TiDBBinlog

    • 失敗した DDL ステートメント#1228 @ オクジャンが発生したときにエラーが発生する可能性がある問題を修正します。

  • 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 専用クラスターのTPC-C パフォーマンス テスト レポートとSysbench パフォーマンス テスト レポートを参照してください。

貢献者

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

• ブラックティア23
• エーテルフロー
• ヒヒヒヒヒ
• ジフフスト
• L-カエデ
• lqs
• ピンアンドブ
• ヨークヘレン
• ユジアリスタ (初投稿者)