TiDB 8.4.0 リリースノート
発売日: 2024年11月11日
TiDB バージョン: 8.4.0
クイックアクセス: クイックスタート
8.4.0 では、次の主要な機能と改善が導入されています。
| カテゴリ | 機能/拡張機能 | 説明 |
|---|---|---|
| スケーラビリティとパフォーマンス | インスタンスレベルの実行プラン キャッシュ(実験的) | インスタンス レベルのプラン キャッシュを使用すると、同じ TiDB インスタンス内のすべてのセッションでプラン キャッシュを共有できます。セッション レベルのプラン キャッシュと比較すると、この機能では、より多くの実行プランをメモリにキャッシュすることで SQL コンパイル時間が短縮され、全体的な SQL 実行時間が短縮されます。これにより、OLTP のパフォーマンスとスループットが向上し、メモリ使用量の制御が向上し、データベースの安定性が向上します。 |
| パーティションテーブルのグローバルインデックス(GA) | グローバル インデックスを使用すると、パーティション化されていない列の取得効率を効果的に向上でき、一意のキーにパーティション キーが含まれていなければならないという制限がなくなります。この機能により、TiDB パーティション テーブルの使用シナリオが拡張され、データ移行に必要なアプリケーション変更作業の一部が回避されます。 | |
| TSO リクエストの並列モード | 同時実行性の高いシナリオでは、この機能を使用して、TSO の取得の待機時間を短縮し、クラスターのスループットを向上させることができます。 | |
| キャッシュされたテーブルのクエリパフォーマンスを向上 | キャッシュされたテーブルでのインデックス スキャンのクエリ パフォーマンスが向上し、シナリオによっては最大 5.4 倍向上します。小さなテーブルでの高速クエリの場合、キャッシュされたテーブルを使用すると、全体的なパフォーマンスが大幅に向上します。 | |
| 信頼性と可用性 | ランナウェイクエリのトリガーをさらにサポートし、リソースグループの切り替えをサポートします。 | ランナウェイ クエリは、予期しない SQL パフォーマンスの問題がシステムに与える影響を軽減する効果的な方法を提供します。TiDB v8.4.0 では、コプロセッサーによって処理されたキーの数 ( PROCESSED_KEYS ) と要求単位 ( RU ) が識別条件として導入され、識別されたクエリが指定されたリソース グループに配置されるため、ランナウェイ クエリをより正確に識別して制御できます。 |
| リソース制御のバックグラウンドタスクのリソース使用量の上限設定をサポート | リソース制御のバックグラウンド タスクに最大パーセンテージ制限を設定することで、さまざまなアプリケーション システムのニーズに基づいてリソース消費を制御できます。これにより、バックグラウンド タスクの消費を低いレベルに抑え、オンライン サービスの品質を確保できます。 | |
| TiProxy はトラフィックのキャプチャと再生をサポートします(実験的) | TiProxy を使用して、クラスターのアップグレード、移行、またはデプロイメントの変更などの主要な操作の前に、TiDB 実本番クラスターから実際のワークロードをキャプチャします。これらのワークロードをターゲット テスト クラスターで再生して、パフォーマンスを検証し、変更が成功したことを確認します。 | |
| 同時自動統計収集 | システム変数tidb_auto_analyze_concurrencyを使用して、単一の自動統計収集タスク内での同時実行を設定できます。TiDB は、ノードの規模とハードウェア仕様に基づいて、スキャン タスクの同時実行を自動的に決定します。これにより、システム リソースを最大限に活用して統計収集の効率が向上し、手動によるチューニングが減り、安定したクラスター パフォーマンスが保証されます。 | |
| 構文 | ベクトル検索（実験的） | ベクトル検索は、データセマンティクスに基づく検索方法であり、より関連性の高い検索結果を提供します。AI と大規模言語モデル (LLM) のコア関数の 1 つとして、ベクトル検索は、検索拡張生成 (RAG)、セマンティック検索、推奨システムなど、さまざまなシナリオで使用できます。 |
| DB 操作と可観測性 | メモリテーブルに TiKV と TiDB の CPU 時間を表示する | CPU 時間がシステム テーブルに統合され、セッションや SQL の他のメトリックと一緒に表示されるようになったため、CPU 消費量の多い操作を複数の観点から観察し、診断の効率を向上させることができます。これは、インスタンス内の CPU スパイクやクラスター内の読み取り/書き込みホットスポットなどのシナリオを診断する場合に特に便利です。 |
| テーブルまたはデータベースごとに集計された TiKV CPU 時間の表示をサポート | ホットスポットの問題が個々の SQL ステートメントによって発生していない場合は、 Top SQLのテーブルまたはデータベース レベル別に集計された CPU 時間を使用すると、ホットスポットの原因となっているテーブルまたはアプリケーションを迅速に特定できるため、ホットスポットと CPU 消費の問題の診断効率が大幅に向上します。 | |
| IMDSv2 サービスを有効にした TiKV インスタンスのバックアップをサポート | AWS EC2 は、デフォルトのメタデータ サービスとして IMDSv2 を使用するようになりました。TiDB は、IMDSv2 が有効になっている TiKV インスタンスからのデータのバックアップをサポートしており、パブリック クラウド サービスで TiDB クラスターをより効率的に実行するのに役立ちます。 | |
| Security | ログバックアップデータのクライアント側暗号化（実験的） | ログ バックアップ データをバックアップstorageにアップロードする前に、バックアップ データを暗号化して、storage中および転送中のセキュリティを確保できます。 |
機能の詳細
パフォーマンス
TSOリクエストに並列バッチモードを導入し、TSO取得のレイテンシーを短縮する＃54960 ＃8432 @ ミョンケミンタ
v8.4.0 より前では、PD からTSO要求すると、TiDB は特定の期間に複数の TSO 要求を収集し、それらをバッチでシリアルに処理して、リモート プロシージャ コール (RPC) 要求の数を減らし、PD のワークロードを軽減していました。ただし、レイテンシの影響を受けやすいシナリオでは、このシリアル バッチ モードのパフォーマンスは理想的ではありません。
v8.4.0 では、TiDB は、さまざまな同時実行機能を備えた TSO 要求の並列バッチ モードを導入しています。並列モードでは、TSO 取得のレイテンシーが短縮されますが、PD ワークロードが増加する可能性があります。TSO を取得するための並列 RPC モードを設定するには、
tidb_tso_client_rpc_modeシステム変数を構成します。詳細についてはドキュメント参照してください。
TiDBのハッシュ結合演算子の実行効率を最適化（実験的） ＃55153 ＃53127 @ 風の話し手 @ 翻訳者 @ 徐懐玉 @ うわー
v8.4.0 では、TiDB はハッシュ結合演算子の最適化バージョンを導入し、実行効率を向上させています。現在、ハッシュ結合の最適化バージョンは内部結合と外部結合操作にのみ適用され、デフォルトでは無効になっています。この最適化バージョンを有効にするには、
tidb_hash_join_versionシステム変数をoptimizedに設定します。詳細についてはドキュメント参照してください。
次の日付関数を TiKV ＃56297 ＃17529 @ ゲンリキにプッシュダウンすることをサポートします
DATE_ADD()DATE_SUB()ADDDATE()SUBDATE()
詳細についてはドキュメント参照してください。
インスタンスレベルの実行プランキャッシュをサポート (実験的) ＃54057 @ qw4990
インスタンス レベルの実行プラン キャッシュを使用すると、同じ TiDB インスタンス内のすべてのセッションで実行プラン キャッシュを共有できます。この機能により、TiDB クエリの応答時間が大幅に短縮され、クラスターのスループットが向上し、実行プランの変更の可能性が減り、安定したクラスター パフォーマンスが維持されます。セッション レベルの実行プラン キャッシュと比較して、インスタンス レベルの実行プラン キャッシュには次の利点があります。
- 冗長性を排除し、同じメモリ消費量でより多くの実行プランをキャッシュします。
- インスタンスに固定サイズのメモリを割り当て、メモリ使用量をより効果的に制限します。
v8.4.0 では、インスタンス レベルの実行プラン キャッシュはクエリ実行プランのキャッシュのみをサポートしており、デフォルトでは無効になっています。
tidb_enable_instance_plan_cache使用してこの機能を有効にし、tidb_instance_plan_cache_max_size使用して最大メモリ使用量を設定できます。 この機能を有効にする前に、 準備された実行計画キャッシュと準備されていない実行プランのキャッシュ無効にしてください。詳細についてはドキュメント参照してください。
TiDB Lightningの論理インポートモードは、準備されたステートメントとクライアントステートメントキャッシュ＃54850 @ dbsidをサポートします。
logical-import-prep-stmt構成項目を有効にすると、TiDB Lightning の論理インポート モードで実行される SQL ステートメントは、準備されたステートメントとクライアント ステートメント キャッシュを使用します。これにより、 TiDB SQL の解析とコンパイルのコストが削減され、SQL 実行効率が向上し、実行プラン キャッシュにヒットする可能性が高くなり、論理インポートが高速化されます。詳細についてはドキュメント参照してください。
パーティションテーブルはグローバルインデックスをサポートします (GA) ＃45133 @ ミョンス @ 定義2014 @ ジフハウス @ L-メープル
初期の TiDB バージョンでは、グローバル インデックスをサポートしていないため、パーティションテーブルにはいくつかの制限がありました。たとえば、一意のキーは、テーブルのパーティション式のすべての列を使用する必要があります。クエリ条件でパーティション キーが使用されていない場合、クエリはすべてのパーティションをスキャンするため、パフォーマンスが低下します。v7.6.0 以降では、グローバル インデックス機能を有効にするためにシステム変数
tidb_enable_global_indexが導入されました。ただし、この機能は当時開発中であり、有効にすることは推奨されません。v8.3.0 以降、グローバル インデックス機能は実験的機能としてリリースされています。1 キーワードを使用して、パーティションテーブルのグローバル インデックスを明示的に作成できます。これにより、パーティションテーブルの一意のキーにはパーティション式で
GLOBALされるすべての列を含める必要があるという制限がなくなり、より柔軟なアプリケーション要件が可能になります。さらに、グローバル インデックスにより、パーティション化されていない列に基づくクエリのパフォーマンスも向上します。v8.4.0 では、この機能が一般提供 (GA) されます。グローバル インデックス機能を有効にするためにシステム変数
tidb_enable_global_indexを設定する代わりに、キーワードGLOBAL使用してグローバル インデックスを作成できます。v8.4.0 以降、このシステム変数は非推奨となり、常にONなります。詳細についてはドキュメント参照してください。
いくつかのシナリオでキャッシュされたテーブルのクエリパフォーマンスを向上＃43249 @ 天菜まお
v8.4.0 では、TiDB は
SELECT ... LIMIT 1IndexLookupで実行する場合、キャッシュされたテーブルのクエリ パフォーマンスを最大 5.4 倍向上させます。さらに、TiDB はフル テーブル スキャンと主キー クエリ シナリオでIndexLookupReaderのパフォーマンスを向上させます。
信頼性
ランナウェイクエリは、処理されたキーとリクエストユニットの数をしきい値＃54434 @ ヒューシャープとしてサポートします。
v8.4.0以降、TiDBは処理されたキーの数（
PROCESSED_KEYS）とリクエストユニット数（RU）に基づいて、暴走クエリを識別できるようになりました。実行時間（EXEC_ELAPSED）と比較して、これらの新しいしきい値はクエリのリソース消費をより正確に定義し、全体的なパフォーマンスが低下した場合の識別バイアスを回避します。複数の条件を同時に設定することができ、いずれかの条件が満たされるとクエリはランナウェイ クエリとして識別されます。
ステートメント要約表の対応するフィールド (
RESOURCE_GROUP、MAX_REQUEST_UNIT_WRITE、MAX_REQUEST_UNIT_READ、MAX_PROCESSED_KEYS) を観察して、実行履歴に基づいて条件値を判断できます。詳細についてはドキュメント参照してください。
ランナウェイクエリ＃54434 @ じゃがいものリソースグループの切り替えをサポート
TiDB v8.4.0 以降では、ランナウェイ クエリのリソース グループを特定のグループに切り替えることができます。
COOLDOWNメカニズムでリソース消費を抑えることができない場合は、 リソース グループを作成し、そのリソース サイズを制限し、SWITCH_GROUPパラメータを設定して、識別されたランナウェイ クエリをこのグループに移動することができます。その間、同じセッション内の後続のクエリは、元のリソース グループで引き続き実行されます。リソース グループを切り替えることで、リソースの使用をより正確に管理し、リソース消費をより厳密に制御できます。詳細についてはドキュメント参照してください。
tidb_scatter_regionシステム変数＃55184 @ D3ハンターを使用してクラスターレベルのリージョン分散戦略の設定をサポートします。v8.4.0 より前では、
tidb_scatter_regionシステム変数は有効または無効にすることしかできませんでした。有効にすると、TiDB はバッチ テーブルの作成時にテーブル レベルの分散戦略を適用します。ただし、バッチで数十万のテーブルを作成すると、この戦略により、いくつかの TiKV ノードに領域が集中し、それらのノードで OOM (メモリ不足) の問題が発生します。v8.4.0 以降、
tidb_scatter_region文字列型に変更されました。クラスター レベルの分散戦略がサポートされるようになり、前述のシナリオでの TiKV OOM の問題を回避するのに役立ちます。詳細についてはドキュメント参照してください。
リソース制御＃56019 @ 栄光のバックグラウンドタスクのリソース使用量の上限設定をサポート
TiDB リソース制御は、バックグラウンド タスクを識別してその優先度を下げることができます。特定のシナリオでは、リソースが利用可能な場合でも、バックグラウンド タスクのリソース消費を制限する必要がある場合があります。v8.4.0 以降では、
UTILIZATION_LIMITパラメータを使用して、バックグラウンド タスクが消費できるリソースの最大割合を設定できます。各ノードは、すべてのバックグラウンド タスクのリソース使用量をこの割合未満に保ちます。この機能により、バックグラウンド タスクのリソース消費を正確に制御できるようになり、クラスターの安定性がさらに向上します。詳細についてはドキュメント参照してください。
リソースグループ＃50831 @ ノルーシュのリソース割り当て戦略を最適化する
TiDB は、リソース管理に対するユーザーの期待にさらに応えるために、v8.4.0 でリソース割り当て戦略を改善しました。
- 実行時に大規模なクエリのリソース割り当てを制御して、リソース グループの制限を超えないようにし、ランナウェイ クエリ
COOLDOWNと組み合わせます。これにより、大規模なクエリの同時実行を識別して削減し、瞬間的なリソース消費を削減できます。 - デフォルトの優先度スケジュール戦略を調整します。異なる優先度のタスクが同時に実行される場合、優先度の高いタスクにはより多くのリソースが割り当てられます。
- 実行時に大規模なクエリのリソース割り当てを制御して、リソース グループの制限を超えないようにし、ランナウェイ クエリ
可用性
TiProxy はトラフィック再生をサポートします (実験的) ＃642 @ 翻訳者
TiProxy v1.3.0 以降では、
tiproxyctl使用して TiProxy インスタンスに接続し、TiDB本番クラスターでアクセス トラフィックをキャプチャし、指定されたレートでテスト クラスターで再生することができます。この機能により、実本番クラスターの実際のワークロードをテスト環境で再現し、SQL ステートメントの実行結果とパフォーマンスを検証することができます。トラフィック リプレイは、次のシナリオで役立ちます。
- TiDB バージョンのアップグレードを確認する
- 変更の影響を評価する
- TiDBを拡張する前にパフォーマンスを検証する
- テストパフォーマンスの限界
詳細についてはドキュメント参照してください。
構文
サポートベクター検索（実験的） ＃54245 ＃17290 ＃9032 @ そよ風のような @ ロイド・ポティガー @ エリック・ゼクアン @ ジムララ @ ジェイソン・ファン @ ウィノロス @ 989898 円
ベクトル検索は、データセマンティクスに基づく検索方法であり、より関連性の高い検索結果を提供します。AI と大規模言語モデル (LLM) のコア関数の 1 つとして、ベクトル検索は、検索拡張生成 (RAG)、セマンティック検索、推奨システムなど、さまざまなシナリオで使用できます。
v8.4.0 以降、TiDB はベクトルデータ型とベクトル検索インデックスサポートし、強力なベクトル検索機能を提供します。TiDB ベクトル データ型は最大 16,383 次元をサポートし、L2 距離 (ユークリッド距離)、コサイン距離、負の内積、L1 距離 (マンハッタン距離) など、さまざまな距離関数サポートします。
ベクトル検索を開始するには、ベクトル データ型のテーブルを作成し、ベクトル データを挿入して、ベクトル データのクエリを実行するだけです。ベクトル データと従来のリレーショナル データの混合クエリを実行することもできます。
ベクトル検索のパフォーマンスを向上させるには、 ベクトル検索インデックス作成して使用できます。TiDB ベクトル検索インデックスはTiFlashに依存していることに注意してください。ベクトル検索インデックスを使用する前に、 TiFlashノードが TiDB クラスターにデプロイされていることを確認してください。
詳細についてはドキュメント参照してください。
DB操作
BR はログバックアップデータのクライアント側暗号化をサポートします (実験的) ＃55834 @ トリスタン1900
以前のバージョンの TiDB では、クライアント側で暗号化できるのはスナップショット バックアップ データのみでした。v8.4.0 以降では、ログ バックアップ データもクライアント側で暗号化できます。ログ バックアップ データをバックアップstorageにアップロードする前に、次のいずれかの方法でバックアップ データを暗号化してセキュリティを確保できます。
- カスタム固定キーを使用して暗号化する
- ローカルディスクに保存されたマスターキーを使用して暗号化する
- キー管理サービス (KMS) によって管理されるマスターキーを使用して暗号化する
詳細についてはドキュメント参照してください。
BR、クラウドstorageシステムでバックアップ データを復元するときに必要な権限が少なくなります＃55870 @ リーヴルス
v8.4.0 より前では、 BR は復元中に復元の進行状況に関するチェックポイント情報をバックアップstorageシステムに書き込みます。これらのチェックポイントにより、中断された復元を迅速に再開できます。v8.4.0 以降では、 BR は復元チェックポイント情報をターゲット TiDB クラスターに書き込みます。つまり、 BR は復元中にバックアップ ディレクトリへの読み取りアクセスのみを必要とします。
詳細についてはドキュメント参照してください。
可観測性
システムテーブル＃55542 @ いびん87のTiDBとTiKVによって消費されたCPU時間を表示します。
Top SQLページにはTiDBダッシュボード CPU 消費量が多い SQL ステートメントが表示されます。v8.4.0 以降、TiDB はシステム テーブルに CPU 時間消費情報を追加し、セッションまたは SQL の他のメトリックとともに表示します。これにより、複数の観点から CPU 消費量が多い操作を簡単に観察できます。この情報は、インスタンス CPU スパイクやクラスター内の読み取り/書き込みホットスポットなどのシナリオで問題の原因を迅速に特定するのに役立ちます。
- ステートメント要約表
AVG_TIDB_CPU_TIMEとAVG_TIKV_CPU_TIMEを加えて、履歴的に個々の SQL ステートメントで消費された平均 CPU 時間を示します。 - INFORMATION_SCHEMA.PROCESSLISTテーブルには
TIDB_CPUとTIKV_CPU追加され、セッションで現在実行されている SQL ステートメントの累積 CPU 消費量が表示されます。 - スロークエリログ
Tidb_cpu_timeフィールドとTikv_cpu_timeフィールドを追加し、キャプチャされた SQL ステートメントによって消費された CPU 時間を示します。
デフォルトでは、TiKV によって消費された CPU 時間が表示されます。TiDB によって消費された CPU 時間を収集すると、追加のオーバーヘッド (約 8%) が発生するため、TiDB によって消費された CPU 時間は、 Top SQLが有効な場合にのみ実際の値が表示され、それ以外の場合は常に
0として表示されます。詳細については
INFORMATION_SCHEMA.PROCESSLISTおよびINFORMATION_SCHEMA.SLOW_QUERY参照してください。- ステートメント要約表
Top SQL は、テーブルまたはデータベースごとに集計された CPU 時間の結果の表示をサポートしています＃55540 @ ノルーシュ
v8.4.0 より前では、 Top SQL CPU 時間を SQL ごとに集計していました。CPU 時間がいくつかの SQL ステートメントによって消費されていない場合、SQL による集計では問題を効果的に特定できません。v8.4.0 以降では、CPU 時間をテーブル別またはDB 別に集計することを選択できます。複数のシステムがあるシナリオでは、新しい集計方法により、特定のシステムからの負荷の変化をより効果的に特定できるため、診断の効率が向上します。
詳細についてはドキュメント参照してください。
Security
BRはAWS IMDSv2 ＃16443 @ ピンギュをサポートします
TiDB を Amazon EC2 にデプロイする場合、 BR はAWS インスタンス メタデータ サービス バージョン 2 (IMDSv2) をサポートします。EC2 インスタンスを設定して、 BR がインスタンスに関連付けられたIAMロールを使用して Amazon S3 に適切なアクセス権限を付与できるようにすることができます。
詳細についてはドキュメント参照してください。
データ移行
TiCDC Claim-Check は、Kafka メッセージの
valueフィールドのみを外部storage＃11396 @ 3エースショーハンドに送信することをサポートします。v8.4.0 より前では、Claim-Check 機能が有効になっている場合 (
large-message-handle-optionをclaim-checkに設定)、TiCDC は大きなメッセージを処理するときにkeyフィールドとvalueフィールドの両方をエンコードして外部storageシステムに保存します。v8.4.0 以降、TiCDC は Kafka メッセージの
valueフィールドのみを外部storageに送信することをサポートします。この機能は、非オープン プロトコル プロトコルにのみ適用されます。この機能は、claim-check-raw-valueパラメータを設定することで制御できます。詳細についてはドキュメント参照してください。
TiCDC は、更新または削除イベント＃10969 @ 3エースショーハンドの古い値を検証するためのチェックサム V2 を導入しました。
v8.4.0 以降、TiDB と TiCDC は、
ADD COLUMNまたはDROP COLUMN操作後に更新または削除イベントの古い値を検証する際の Checksum V1 の問題に対処するために、Checksum V2 アルゴリズムを導入しています。v8.4.0 以降で作成されたクラスター、または v8.4.0 にアップグレードされたクラスターの場合、単一行データのチェックサム検証が有効になっていると、TiDB はデフォルトで Checksum V2 を使用します。TiCDC は、Checksum V1 と V2 の両方の処理をサポートしています。この変更は、TiDB と TiCDC の内部実装にのみ影響し、下流の Kafka コンシューマーのチェックサム計算方法には影響しません。詳細についてはドキュメント参照してください。
互換性の変更
注記：
このセクションでは、v8.3.0 から現在のバージョン (v8.4.0) にアップグレードするときに知っておく必要のある互換性の変更について説明します。v8.2.0 以前のバージョンから現在のバージョンにアップグレードする場合は、中間バージョンで導入された互換性の変更も確認する必要がある可能性があります。
システム変数
| 変数名 | タイプを変更 | 説明 |
|---|---|---|
log_bin | 削除されました | v8.4.0 では、 TiDBBinlog削除されました。この変数は、TiDB Binlogが使用されているかどうかを示し、v8.4.0 以降では削除されます。 |
sql_log_bin | 削除されました | v8.4.0 では、 TiDBBinlog削除されました。この変数は、変更を TiDB Binlogに書き込むかどうかを示し、v8.4.0 以降では削除されます。 |
tidb_enable_global_index | 非推奨 | v8.4.0 では、この変数は非推奨です。その値はデフォルト値ONに固定されます。つまり、 グローバルインデックスデフォルトで有効になります。グローバル インデックスを作成するには、 CREATE TABLEまたはALTER TABLEを実行するときに、対応する列にキーワードGLOBALを追加するだけです。 |
tidb_enable_list_partition | 非推奨 | v8.4.0 では、この変数は非推奨です。その値はデフォルト値ONに固定されます。つまり、デフォルトではリストの分割が有効になります。 |
tidb_enable_table_partition | 非推奨 | v8.4.0 では、この変数は非推奨です。その値はデフォルト値ONに固定されます。つまり、デフォルトではテーブルパーティションが有効になります。 |
tidb_analyze_partition_concurrency | 修正済み | 値の範囲を[1, 18446744073709551615]から[1, 128]に変更します。 |
tidb_enable_inl_join_inner_multi_pattern | 修正済み | デフォルト値をOFFからONに変更します。v8.4.0 以降では、内部テーブルにSelection 、 Aggregation 、またはProjectionの演算子がある場合、インデックス結合がデフォルトでサポートされます。 |
tidb_opt_prefer_range_scan | 修正済み | デフォルト値をOFFからONに変更します。統計のないテーブル (疑似統計) または空のテーブル (統計がゼロ) の場合、オプティマイザは完全なテーブル スキャンよりも間隔スキャンを優先します。 |
tidb_scatter_region | 修正済み | v8.4.0 より前では、そのタイプはブール型で、 ONとOFFのみをサポートしており、新しく作成されたテーブルのリージョンは、有効にした後はテーブル レベルの分散のみをサポートします。v8.4.0 以降では、 SESSIONスコープが追加され、タイプがブール型から列挙型に変更され、デフォルト値がOFFから null に変更され、オプションの値TABLEとGLOBALが追加されました。さらに、バッチでの高速テーブル作成中にリージョンが不均一に分散されることで発生する TiKV OOM の問題を回避するために、クラスター レベルの分散ポリシーがサポートされるようになりました。 |
tidb_schema_cache_size | 修正済み | デフォルト値を0から536870912 (512 MiB) に変更し、この機能がデフォルトで有効になっていることを示します。許可される最小値は67108864 (64 MiB) に設定されています。 |
tidb_auto_analyze_concurrency | 新しく追加された | 単一の自動統計収集タスク内の同時実行性を設定します。v8.4.0 より前では、この同時実行性は1に固定されています。統計収集タスクを高速化するには、クラスターの使用可能なリソースに基づいてこの同時実行性を増やすことができます。 |
tidb_enable_instance_plan_cache | 新しく追加された | インスタンス プラン キャッシュ機能を有効にするかどうかを制御します。 |
tidb_enable_stats_owner | 新しく追加された | 対応する TiDB インスタンスが自動統計更新タスクを実行できるかどうかを制御します。 |
tidb_hash_join_version | 新しく追加された | TiDB がハッシュ結合演算子の最適化バージョンを使用するかどうかを制御します。デフォルト値legacyは、最適化バージョンが使用されないことを意味します。 optimizedに設定すると、TiDB はハッシュ結合演算子の実行時に最適化バージョンを使用して、ハッシュ結合のパフォーマンスを向上させます。 |
tidb_instance_plan_cache_max_size | 新しく追加された | インスタンス プラン キャッシュの最大メモリ使用量を設定します。 |
tidb_instance_plan_cache_reserved_percentage | 新しく追加された | メモリの削除後にインスタンス プラン キャッシュ用に予約されるアイドルメモリの割合を制御します。 |
tidb_pre_split_regions | 新しく追加された | v8.4.0 より前では、新しく作成されたテーブルの行分割スライスのデフォルト数を設定するには、 CREATE TABLE SQL ステートメントごとにPRE_SPLIT_REGIONS宣言する必要がありましたが、多数のテーブルを同様に構成する必要がある場合は複雑になります。この変数は、このような問題を解決するために導入されました。このシステム変数をGLOBALまたはSESSIONレベルに設定して、使いやすさを向上させることができます。 |
tidb_shard_row_id_bits | 新しく追加された | v8.4.0 より前では、新しく作成されたテーブルの行 ID のスライスのデフォルト数を設定するには、 CREATE TABLEまたはALTER TABLE SQL ステートメントごとにSHARD_ROW_ID_BITS宣言する必要がありましたが、多数のテーブルを同様に構成する必要がある場合は複雑になります。この変数は、このような問題を解決するために導入されました。このシステム変数をGLOBALまたはSESSIONレベルに設定して、使いやすさを向上させることができます。 |
tidb_tso_client_rpc_mode | 新しく追加された | TiDB が PD に TSO RPC 要求を送信するモードを切り替えます。このモードは、TSO RPC 要求を並列処理できるかどうかを決定し、各 TS 取得操作のバッチ待機に費やされる時間に影響します。これにより、特定のシナリオでのクエリ実行中に TS を取得するための待機時間を短縮できます。 |
コンフィグレーションパラメータ
| コンフィグレーションファイルまたはコンポーネント | コンフィグレーションパラメータ | タイプを変更 | 説明 |
|---|---|---|---|
| ティビ | grpc-keepalive-time | 修正済み | 最小値1を追加します。 |
| ティビ | grpc-keepalive-timeout | 修正済み | v8.4.0 より前では、このパラメータのデータ型は INT で、最小値は1です。v8.4.0 以降では、データ型は FLOAT64 に変更され、最小値は0.05なります。ネットワーク ジッターが頻繁に発生するシナリオでは、値を小さくして再試行間隔を短くすることで、ネットワーク ジッターによるパフォーマンスへの影響を軽減できます。 |
| ティビ | tidb_enable_stats_owner | 新しく追加された | 対応する TiDB インスタンスが自動統計更新タスクを実行できるかどうかを制御します。 |
| ティクヴ | region-split-keys | 修正済み | デフォルト値を"960000"から"2560000"に変更します。 |
| ティクヴ | region-split-size | 修正済み | デフォルト値を"96MiB"から"256MiB"に変更します。 |
| ティクヴ | sst-max-size | 修正済み | デフォルト値を"144MiB"から"384MiB"に変更します。 |
| ティクヴ | pessimistic-txn.in-memory-instance-size-limit | 新しく追加された | TiKV インスタンス内のメモリ内悲観的ロックのメモリ使用量制限を制御します。この制限を超えると、TiKV は悲観的ロックを永続的に書き込みます。 |
| ティクヴ | pessimistic-txn.in-memory-peer-size-limit | 新しく追加された | リージョン内のメモリ内悲観的ロックのメモリ使用量制限を制御します。この制限を超えると、TiKV は悲観的ロックを永続的に書き込みます。 |
| ティクヴ | raft-engine.spill-dir | 新しく追加された | Raftログ ファイルのマルチディスクstorageをサポートするために、TiKV インスタンスがRaftログ ファイルを保存するセカンダリ ディレクトリを制御します。 |
| ティクヴ | resource-control.priority-ctl-strategy | 新しく追加された | 優先度の低いタスクの管理ポリシーを制御します。TiKV は、優先度の低いタスクにフロー制御を追加することで、優先度の高いタスクが最初に実行されるようにします。 |
| PD | cert-allowed-cn | 修正済み | v8.4.0 以降では、複数のCommon Names設定がサポートされます。v8.4.0 より前では、 Common Name 1 つしか設定できません。 |
| PD | max-merge-region-keys | 修正済み | デフォルト値を200000から540000に変更します。 |
| PD | max-merge-region-size | 修正済み | デフォルト値を20から54に変更します。 |
| TiFlash | storage.format_version | 修正済み | ベクター インデックスの作成とstorageをサポートするために、デフォルトのTiFlashstorageフォーマットのバージョンを5から7に変更します。このフォーマットの変更により、v8.4.0 以降のバージョンにアップグレードされたTiFlashクラスターは、以前のバージョンへのインプレース ダウングレードをサポートしません。 |
| TiDBBinlog | --enable-binlog | 削除されました | v8.4.0 では、 TiDBBinlog削除されました。このパラメータは、TiDBbinlog生成を有効にするかどうかを制御し、v8.4.0 以降では削除されます。 |
| ティCDC | claim-check-raw-value | 新しく追加された | TiCDC が Kafka メッセージのvalueのフィールドのみを外部storageに送信するかどうかを制御します。この機能は、非オープン プロトコル シナリオにのみ適用されます。 |
| TiDB Lightning | logical-import-prep-stmt | 新しく追加された | 論理インポート モードでは、このパラメータは、パフォーマンスを向上させるために準備されたステートメントとステートメント キャッシュを使用するかどうかを制御します。デフォルト値はfalseです。 |
| BR | --log.crypter.key | 新しく追加された | ログ バックアップ データの暗号化キーを 16 進文字列形式で指定します。アルゴリズムaes128-ctrの場合は 128 ビット (16 バイト) のキー、アルゴリズムaes192-ctrの場合は 24 バイトのキー、アルゴリズムaes256-ctrの場合は 32 バイトのキーです。 |
| BR | --log.crypter.key-file | 新しく追加された | ログバックアップデータのキーファイルを指定します。 crypter.keyを渡さずに、キーが格納されているファイルパスをパラメータとして直接渡すこともできます。 |
| BR | --log.crypter.method | 新しく追加された | ログ バックアップ データの暗号化アルゴリズムを指定します。指定できる値はaes128-ctr 、 aes192-ctr 、またはaes256-ctrです。既定値はplaintextで、データは暗号化されないことを示します。 |
| BR | --master-key | 新しく追加された | ログ バックアップ データのマスター キーを指定します。ローカル ディスクに保存されているマスター キー、またはクラウド キー管理サービス (KMS) によって管理されるマスター キーを使用できます。 |
| BR | --master-key-crypter-method | 新しく追加された | ログ バックアップ データのマスター キーに基づく暗号化アルゴリズムを指定します。指定できる値はaes128-ctr 、 aes192-ctr 、またはaes256-ctrです。既定値はplaintextで、データは暗号化されないことを示します。 |
オフラインパッケージの変更
v8.4.0 以降では、 TiDB-community-toolkit バイナリパッケージから次のコンテンツが削除されます。
pump-{version}-linux-{arch}.tar.gzdrainer-{version}-linux-{arch}.tar.gzbinlogctlarbiter
オペレーティング システムとプラットフォームの要件の変更
TiDB をアップグレードする前に、オペレーティング システムのバージョンがOSおよびプラットフォームの要件を満たしていることを確認してください。
- CentOS Linux のサポート終了によると、CentOS Linux 7 のアップストリームサポートは 2024 年 6 月 30 日に終了します。TiDB は、8.4 DMR バージョンから CentOS 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。CentOS 7 上の TiDB クラスターを v8.4.0 以降にアップグレードすると、クラスターが使用できなくなります。
- Red Hat Enterprise Linux ライフサイクルによると、Red Hat Enterprise Linux 7 のメンテナンスサポートは 2024 年 6 月 30 日に終了します。TiDB は 8.4 DMR バージョンから Red Hat Enterprise Linux 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。Red Hat Enterprise Linux 7 上の TiDB クラスターを v8.4.0 以降にアップグレードすると、クラスターが使用できなくなります。
削除された機能
v8.4.0 以降では次の機能が削除されます。
- v8.4.0 では、 TiDBBinlog削除されました。v8.3.0 以降では、 TiDB Binlog は完全に非推奨です。増分データ レプリケーションの場合は、代わりにティCDC使用します。ポイントインタイム リカバリ (PITR) の場合は、 ピトル使用します。TiDB クラスターを v8.4.0 以降のバージョンにアップグレードする前に、必ず TiCDC と PITR に切り替えてください。
以下の機能は将来のバージョンで削除される予定です:
- v8.0.0 以降、 TiDB Lightning物理インポート モードの競合検出の旧バージョン戦略が廃止され、
conflict.strategyパラメータを使用して論理インポート モードと物理インポート モードの両方の競合検出戦略を制御できるようになりました。競合検出の旧バージョンのduplicate-resolutionパラメータは、将来のリリースで削除される予定です。
- v8.0.0 以降、 TiDB Lightning物理インポート モードの競合検出の旧バージョン戦略が廃止され、
廃止された機能
以下の機能は将来のバージョンで廃止される予定です。
- TiDB では、統計を自動的に収集するタスクの順序を最適化するために優先キューを有効にするかどうかを制御するためのシステム変数
tidb_enable_auto_analyze_priority_queueが導入されています。将来のリリースでは、統計を自動的に収集するタスクを順序付ける唯一の方法は優先キューになるため、このシステム変数は非推奨になります。 - TiDB は、v7.5.0 でシステム変数
tidb_enable_async_merge_global_statsを導入しました。これを使用して、TiDB がパーティション統計の非同期マージを使用して OOM の問題を回避するように設定できます。将来のリリースでは、パーティション統計は非同期にマージされるため、このシステム変数は非推奨になります。 - 以降のリリースでは実行計画バインディングの自動進化再設計する予定であり、関連する変数と動作が変更されます。
- v8.0.0 では、TiDB は、同時 HashAgg アルゴリズムのディスク スピルをサポートするかどうかを制御する
tidb_enable_parallel_hashagg_spillシステム変数を導入します。将来のバージョンでは、tidb_enable_parallel_hashagg_spillシステム変数は非推奨になります。 - TiDB Lightningパラメータ
conflict.max-record-rowsは、将来のリリースで廃止される予定であり、その後削除されます。このパラメータはconflict.thresholdに置き換えられます。これは、競合するレコードの最大数が、単一のインポート タスクで許容できる競合するレコードの最大数と一致することを意味します。 - v6.3.0 以降、パーティション テーブルはデフォルトで動的剪定モード使用します。静的プルーニング モードと比較して、動的プルーニング モードは IndexJoin やプラン キャッシュなどの機能をサポートし、パフォーマンスが向上します。したがって、静的プルーニング モードは非推奨になります。
改善点
ティビ
- 大量のデータをスキャンする際のBatchCopタスク構築の効率を最適化＃55915 ＃55413 @ うわー
- トランザクションのバッファを最適化して、トランザクションの書き込みレイテンシーと TiDB CPU 使用率を削減します＃55287 @ あなた06
- システム変数
tidb_dml_typeが"bulk"＃50215 @ エキシウムに設定されている場合にDMLステートメントの実行パフォーマンスを最適化します。 - オプティマイザー修正制御 47400使用して、オプティマイザが
estRowsから1の推定最小値を制限するかどうかを制御します。これは、Oracle や DB2 ＃47400 @ テリー・パーセルなどのデータベースと一致しています。 - 多数の同時書き込みによるオーバーヘッドを削減するために、
mysql.tidb_runaway_queriesログ テーブルに書き込み制御を追加します＃54434 @ ヒューシャープ - 内部テーブルに
Selection、Projection、またはAggregation演算子がある場合、デフォルトでインデックス結合をサポートします＃47233 @ ウィノロス - 特定のシナリオで
DELETE操作に対して TiKV から取得される列の詳細の数を減らし、これらの操作のリソース オーバーヘッドを削減します＃38911 @ ウィノロス - システム変数
tidb_auto_analyze_concurrency＃53460 @ ホーキングレイを使用して、単一の自動統計収集タスク内での同時実行の設定をサポートします。 - 多数の列を持つテーブルをクエリする際のパフォーマンスを向上させるために、内部関数のロジックを最適化します＃52112 @ ラスティン170506
- フィルター条件を
a = 1 AND (a > 1 OR (a = 1 AND b = 2))～a = 1 AND b = 2＃56005 @ ガザルファミリーのように簡略化する - 最適でない実行プランのリスクが高いシナリオでは、コストモデルでテーブルスキャンのコストを増やし、オプティマイザがインデックス＃56012 @ テリー・パーセルを優先するようにします。
- TiDBは2つの引数のバリアント
MID(str, pos)＃52420 @ ドヴェーデンをサポートしています - 非バイナリ主キー＃55660 @ lcwangchaoを持つテーブルの TTL タスクの分割をサポート
- システムメタデータ関連ステートメントのパフォーマンスを最適化する＃50305 @ うわー @ タンジェンタ @ ジョーチェン @ Cbcウェストウルフ
- 自動分析操作用の新しい優先キューを実装して、分析パフォーマンスを向上させ、キュー＃55906 @ ラスティン170506の再構築コストを削減します。
- 統計モジュールが DDL イベントをサブスクライブできるように DDL 通知機能を導入する＃55722 @ ふーふー @ ランス6716 @ ラスティン170506
- TiDB のアップグレード中に新しい TiDB ノードに DDL 所有権を強制的に引き継がせ、古い TiDB ノードが所有権＃51285 @ 翻訳:を引き継ぐことによる互換性の問題を回避します。
- クラスターレベルの散布リージョン＃8424 @ リバー2000iをサポート
ティクヴ
- リージョン＃17309 @ リクササシネーターが多すぎることによる余分なオーバーヘッドを回避するために、リージョンのデフォルト値を 96 MiB から 256 MiB に増やします。
- リージョンまたは TiKV インスタンス内のメモリ内悲観的ロックのメモリ使用量制限の設定をサポートします。ホット書き込みシナリオで多数の悲観的ロックが発生する場合は、設定によってメモリ制限を増やすことができます。これにより、悲観的ロックがディスクに書き込まれることで＃17542する CPU および I/O オーバーヘッドを回避できます。1 @ 翻訳
- Raft Engineに新しい
spill-dir設定項目を導入し、 Raftログのマルチディスクstorageをサポートします。ホームディレクトリ（dir）があるディスクの容量が不足すると、 Raft Engineは自動的に新しいログをspill-dirに書き込み、システムの継続的な動作を保証します＃17356 @ リクササシネーター - RocksDB の圧縮トリガー メカニズムを最適化し、多数の DELETE バージョン＃17269 @ アンドレ・ムーシュを処理するときにディスク領域の再利用を高速化します。
- 書き込み操作のフロー制御構成を動的に変更するサポート＃17395 @ 栄光
- 空のテーブルと小さなリージョン＃17376 @ リクササシネーターシナリオでのリージョンマージの速度を向上
- パイプライン化された DMLresolved-ts を長期間ブロックするのを防ぐ＃17459 @ エキシウム
PD
TiFlash
ツール
バグ修正
ティビ
tidb_restricted_read_only変数がtrue＃53822 ＃55373 @ 定義2014に設定されている場合にデッドロックが発生する可能性がある問題を修正しました- TiDB が正常なシャットダウン中に自動コミットトランザクションの完了を待たない問題を修正＃55464 @ ヤンケオ
- TTLジョブ実行中に
tidb_ttl_delete_worker_countの値を減らすとジョブが＃55561 @ lcwangchaoで完了しなくなる問題を修正 - テーブルのインデックスに生成された列が含まれている場合、
ANALYZEステートメント＃55438 @ ホーキングレイを介してテーブルの統計情報を収集するときにUnknown column 'column_name' in 'expression'エラーが発生する可能性がある問題を修正しました。 - 冗長なコードを削減するために、統計に関連する不要な設定を廃止する＃55043 @ ラスティン170506
- 相関サブクエリと CTE ＃55551 @ グオシャオゲ含むクエリを実行すると、TiDB がハングしたり、誤った結果が返されたりする問題を修正しました。
lite-init-stats無効にすると統計が同期的にロードされない可能性がある問題を修正＃54532 @ ホーキングレイUPDATEまたはDELETEステートメントに再帰 CTE が含まれている場合、ステートメントがエラーを報告したり、 ＃55666 @ 時間と運命有効にならない可能性がある問題を修正しました。- ウィンドウ関数を含むSQLバインディングが場合によっては有効にならない可能性がある問題を修正＃55981 @ ウィノロス
- 統計＃55684 @ ウィノロスを初期化するときに、非バイナリ照合順序の文字列列の統計が読み込まれない可能性がある問題を修正しました。
- クエリ条件
column IS NULL＃56116 @ ホーキングレイで一意のインデックスにアクセスするときに、オプティマイザが行数を誤って 1 と見積もる問題を修正しました。 - クエリに
(... AND ...) OR (... AND ...) ...＃54323 @ 時間と運命のようなフィルタ条件が含まれている場合、オプティマイザが行数の推定に最適な複数列の統計情報を使用しない問題を修正しました。 - クエリに利用可能なインデックスマージ実行プラン＃56217 @ アイリンキッドがある場合に
read_from_storageヒントが有効にならない可能性がある問題を修正しました。 IndexNestedLoopHashJoin＃49692 @ ソロッツのデータ競合問題を修正INFORMATION_SCHEMA.STATISTICSテーブルのSUB_PART値がNULL＃55812 @ 定義2014になる問題を修正しました- DML文にネストされた生成列＃53967 @ 翻訳:が含まれている場合にエラーが発生する問題を修正
- 除算演算で最小表示長を持つ整数型のデータにより、除算結果が＃55837 @ 風の話し手でオーバーフローする可能性がある問題を修正しました。
- TopN演算子に続く演算子がメモリ制限を超えたときにフォールバックアクションをトリガーできない問題を修正＃56185 @ 翻訳者
- ソート演算子の
ORDER BY列目に定数＃55344 @ 翻訳者が含まれている場合にスタックする問題を修正しました。 - インデックスを追加するときに、PDリーダーを強制終了した後に
8223 (HY000)エラーが発生し、テーブル内のデータが不整合になる問題を修正しました＃55488 @ タンジェンタ - 履歴 DDL ジョブ＃55711 @ ジョッカウに関する情報をリクエストすると、DDL 履歴ジョブが多すぎるために OOM が発生する問題を修正しました。
- グローバルソートが有効でリージョンサイズが96 MiB ＃55374 @ ランス6716を超えると
IMPORT INTO実行が停止する問題を修正 - 一時テーブルで
IMPORT INTO実行すると TiDB がクラッシュする問題を修正＃55970 @ D3ハンター - ユニークインデックスを追加すると
duplicate entryエラー＃56161 @ タンジェンタが発生する問題を修正 - TiKV が 810 秒以上ダウンしている場合にTiDB Lightning がすべての KV ペアを取り込まず、テーブル＃55808 @ ランス6716のデータが不整合になる問題を修正しました。
CREATE TABLE LIKEステートメントがキャッシュされたテーブル＃56134 @ 天菜まおに使用できない問題を修正- CTE ＃56198 @ ドヴェーデンの
FORMAT()式に関する紛らわしい警告メッセージを修正 - パーティションテーブル＃56094 @ ミョンスを作成するときに、列の型制限が
CREATE TABLEとALTER TABLE間で一致しない問題を修正しました。 INFORMATION_SCHEMA.RUNAWAY_WATCHES表＃54770 @ ヒューシャープの誤った時間タイプを修正
ティクヴ
TiFlash
ツール
バックアップと復元 (BR)
TiDB データ移行 (DM)
TiDB Lightning
寄稿者
TiDB コミュニティの以下の貢献者に感謝いたします。