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クラスタ内で同時に実行される自動分析処理の数を制御するシステム変数tidb_auto_analyze_concurrencyを導入しました。TiDBは、ノードの規模とハードウェア仕様に基づいて、スキャンタスクの同時実行数を自動的に決定します。これにより、システムリソースを最大限に活用して統計情報の収集効率が向上し、手動チューニングの負担が軽減され、クラスタの安定したパフォーマンスが確保されます。 | |
| SQL | ベクトル検索（実験的） | ベクトル検索は、データのセマンティクスに基づいた検索手法であり、より関連性の高い検索結果を提供します。AIと大規模言語モデル（LLM）の中核関数の一つとして、ベクトル検索は検索拡張生成（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 @ ウィンドトーカー @ xzhangxian1008 @ 徐淮嶼 @ wshwsh12
TiDB v8.4.0では、ハッシュ結合演算子の最適化バージョンが導入され、実行効率が向上しました。現在、ハッシュ結合の最適化バージョンは内部結合と外部結合にのみ適用され、デフォルトでは無効になっています。この最適化バージョンを有効にするには、システム変数
tidb_hash_join_versionoptimizedに設定してください。詳細についてはドキュメント参照してください。
次の日付関数を TiKV ＃56297 ＃17529 @ ゲンリチにプッシュダウンすることをサポートします
DATE_ADD()DATE_SUB()ADDDATE()SUBDATE()
詳細についてはドキュメント参照してください。
インスタンスレベルの実行プランキャッシュをサポート（実験的） ＃54057 @ qw4990
インスタンスレベルの実行プランキャッシュにより、同じTiDBインスタンス内のすべてのセッションで実行プランキャッシュを共有できます。この機能により、TiDBクエリの応答時間が大幅に短縮され、クラスタのスループットが向上し、実行プランの変更の可能性が低減され、クラスタの安定したパフォーマンスが維持されます。セッションレベルの実行プランキャッシュと比較して、インスタンスレベルの実行プランキャッシュには以下の利点があります。
- 冗長性を排除し、同じメモリ消費量でより多くの実行プランをキャッシュします。
- インスタンスに固定サイズのメモリを割り当て、メモリ使用量をより効果的に制限します。
バージョン8.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導入されました。ただし、この機能は当時開発中であったため、有効化することは推奨されません。バージョン8.3.0以降、グローバルインデックス機能が実験的機能としてリリースされました。パーティションテーブルに
GLOBALキーワードを使用して明示的にグローバルインデックスを作成できます。これにより、パーティションテーブルの一意キーにはパーティション式で使用されるすべての列が含まれていなければならないという制限がなくなり、より柔軟なアプリケーション要件に対応できるようになります。さらに、グローバルインデックスは、パーティション化されていない列に基づくクエリのパフォーマンスも向上させます。この機能はv8.4.0で一般提供（GA）されます。グローバルインデックス機能を有効にするためにシステム変数
tidb_enable_global_index設定する代わりに、キーワードGLOBAL使用することでグローバルインデックスを作成できます。v8.4.0以降、このシステム変数は非推奨となり、常にONなります。詳細についてはドキュメント参照してください。
いくつかのシナリオでキャッシュされたテーブルのクエリパフォーマンスを向上＃43249 @ 天菜まお
v8.4.0では、TiDBは
SELECT ... LIMIT 1をIndexLookupで実行した場合、キャッシュされたテーブルのクエリパフォーマンスを最大5.4倍向上させます。さらに、TiDBはフルテーブルスキャンと主キークエリのシナリオにおいてIndexLookupReaderのパフォーマンスを向上させます。
信頼性
ランナウェイクエリは、処理されたキーとリクエストユニットの数をしきい値＃54434 @ HuSharpとしてサポートします。
TiDB v8.4.0以降、処理されたキー数（
PROCESSED_KEYS）とリクエストユニット数（RU）に基づいて、ランナウェイクエリを識別できるようになりました。実行時間（EXEC_ELAPSED）と比較して、これらの新しいしきい値はクエリのリソース消費をより正確に定義し、全体的なパフォーマンスが低下した場合の識別バイアスを回避します。複数の条件を同時に設定することができ、いずれかの条件が満たされた場合、クエリはランナウェイ クエリとして識別されます。
明細書概要表
MAX_PROCESSED_KEYS対応するフィールド (RESOURCE_GROUPMAX_REQUEST_UNIT_READMAX_REQUEST_UNIT_WRITE観察して、実行履歴に基づいて条件値を判断できます。詳細についてはドキュメント参照してください。
ランナウェイクエリ＃54434 @ Jmポテトのリソースグループの切り替えをサポート
TiDB v8.4.0以降では、ランナウェイクエリのリソースグループを特定のグループに切り替えることができます。1
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 @ djshow832をサポートします
TiProxy v1.3.0以降では、
tiproxyctl使用してTiProxyインスタンスに接続し、TiDB本番クラスタでアクセストラフィックをキャプチャし、指定したレートでテストクラスタで再生できるようになりました。この機能により、本番クラスタの実際のワークロードをテスト環境で再現し、SQL文の実行結果とパフォーマンスを検証できます。トラフィック リプレイは、次のシナリオで役立ちます。
- TiDB バージョンのアップグレードを確認する
- 変更の影響を評価する
- TiDBを拡張する前にパフォーマンスを検証する
- テストパフォーマンスの限界
詳細についてはドキュメント参照してください。
SQL
サポートベクターサーチ（実験的） ＃54245 ＃17290 ＃9032 @ そよ風のような @ ロイド・ポティガー @ エリック・ゼクアン @ ジムララ @ ジェイソン・ファン @ ウィノロス @ wk989898
ベクトル検索は、データのセマンティクスに基づいた検索手法であり、より関連性の高い検索結果を提供します。AIと大規模言語モデル（LLM）の中核関数の一つとして、ベクトル検索は検索拡張生成（RAG）、セマンティック検索、レコメンデーションシステムなど、様々なシナリオで活用できます。
TiDB v8.4.0以降、 ベクトルデータ型とベクトル検索インデックスサポートし、強力なベクトル検索機能を提供します。TiDBベクトルデータ型は最大16,383次元をサポートし、L2距離（ユークリッド距離）、コサイン距離、負の内積、L1距離（マンハッタン距離）など、さまざまな距離関数サポートします。
ベクター検索を開始するには、ベクターデータ型のテーブルを作成し、ベクターデータを挿入し、ベクターデータに対するクエリを実行するだけです。ベクターデータと従来のリレーショナルデータの混合クエリも実行できます。
ベクトル検索のパフォーマンスを向上させるには、 ベクトル検索インデックス作成して使用できます。TiDB ベクトル検索インデックスはTiFlashに依存していることに注意してください。ベクトル検索インデックスを使用する前に、TiDB クラスターにTiFlashノードがデプロイされていることを確認してください。
詳細についてはドキュメント参照してください。
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 @ ノルーシュ
バージョン8.4.0より前のバージョンでは、 Top SQL CPU時間をSQLごとに集計していました。CPU時間が消費されるSQL文が少ない場合、SQLごとの集計では問題を効果的に特定できません。バージョン8.4.0以降では、CPU時間をテーブル別またはデータベース別に集計できます。複数のシステムが存在するシナリオでは、新しい集計方法により、特定のシステムからの負荷変化をより効果的に特定できるため、診断効率が向上します。
詳細についてはドキュメント参照してください。
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システムに保存します。バージョン8.4.0以降、TiCDCはKafkaメッセージの
valueのフィールドのみを外部storageに送信できるようになりました。この機能は非Open Protocolプロトコルにのみ適用されます。この機能はclaim-check-raw-valueパラメータを設定することで制御できます。詳細についてはドキュメント参照してください。
TiCDC は、更新または削除イベント＃10969 @ 3エースショーハンドの古い値を検証するためのチェックサム V2 を導入しました。
v8.4.0以降、TiDBとTiCDCはChecksum V2アルゴリズムを導入し、
ADD COLUMNまたはDROP COLUMN操作後にUpdateイベントまたはDeleteイベントの古い値を検証する際のChecksum V1の問題を解決するようになりました。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 | 非推奨 | バージョン8.4.0では、この変数は非推奨となりました。値はデフォルト値のONに固定されます。つまり、 グローバルインデックスデフォルトで有効になります。グローバルインデックスを作成するには、 CREATE TABLEまたはALTER TABLE実行する際に、対応する列にキーワードGLOBALを追加するだけです。 |
tidb_enable_list_partition | 非推奨 | バージョン8.4.0では、この変数は非推奨となります。値はデフォルト値のONに固定され、デフォルトでリスト分割有効になります。 |
tidb_enable_table_partition | 非推奨 | バージョン8.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 | 新しく追加された | TiDBクラスター内の自動分析操作の同時実行数を設定します。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 | 新しく追加された | バージョン8.4.0より前のバージョンでは、新規作成テーブルの行分割スライス数のデフォルト設定には、 CREATE TABLE SQL文ごとにPRE_SPLIT_REGIONSつずつ宣言する必要がありました。これは、多数のテーブルを同様に設定する必要がある場合、煩雑な作業となります。この変数はこうした問題を解決するために導入されました。このシステム変数をGLOBALまたはSESSIONレベルに設定することで、ユーザビリティを向上させることができます。 |
tidb_shard_row_id_bits | 新しく追加された | バージョン8.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取得の待機時間を短縮できます。 |
コンフィグレーションパラメータ
| コンフィグレーションファイルまたはコンポーネント | コンフィグレーションパラメータ | タイプを変更 | 説明 |
|---|---|---|---|
| TiDB | grpc-keepalive-time | 修正済み | 最小値1を加算します。 |
| TiDB | grpc-keepalive-timeout | 修正済み | バージョン8.4.0より前では、このパラメータのデータ型はINTで、最小値は1でした。バージョン8.4.0以降では、データ型がFLOAT64に変更され、最小値は0.05なります。ネットワークジッターが頻繁に発生するシナリオでは、値を小さくして再試行間隔を短くすることで、ネットワークジッターによるパフォーマンスへの影響を軽減できます。 |
| TiDB | tidb_enable_stats_owner | 新しく追加された | 対応する TiDB インスタンスが自動統計更新タスクを実行できるかどうかを制御します。 |
| TiKV | region-split-keys | 修正済み | デフォルト値を"960000"から"2560000"に変更します。 |
| TiKV | region-split-size | 修正済み | デフォルト値を"96MiB"から"256MiB"に変更します。 |
| TiKV | sst-max-size | 修正済み | デフォルト値を"144MiB"から"384MiB"に変更します。 |
| TiKV | pessimistic-txn.in-memory-instance-size-limit | 新しく追加された | TiKVインスタンス内のメモリ内悲観的ロックのメモリ使用量制限を制御します。この制限を超えると、TiKVは悲観的ロックを永続的に書き込みます。 |
| TiKV | pessimistic-txn.in-memory-peer-size-limit | 新しく追加された | リージョン内のメモリ内悲観的ロックのメモリ使用量制限を制御します。この制限を超えると、TiKVは悲観的ロックを永続的に書き込みます。 |
| TiKV | raft-engine.spill-dir | 新しく追加された | Raftログ ファイルのマルチディスク ストレージをサポートするために、TiKV インスタンスがRaftログ ファイルを保存storageセカンダリ ディレクトリを制御します。 |
| TiKV | resource-control.priority-ctl-strategy | 新しく追加された | 低優先度タスクの管理ポリシーを制御します。TiKVは、低優先度タスクにフロー制御を追加することで、高優先度タスクが最初に実行されるようにします。 |
| PD | cert-allowed-cn | 修正済み | v8.4.0以降では、複数のCommon Names設定がサポートされます。v8.4.0より前では、 Common Nameつしか設定できません。 |
| 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以降では削除されています。 |
| TiCDC | 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 | 新しく追加された | ログバックアップデータのキーファイルを指定します。1 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はv8.4.0で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は完全に非推奨となりました。増分データレプリケーションの場合は、代わりにTiCDC使用してください。ポイントインタイムリカバリ（PITR）の場合は、 PITR使用してください。TiDBクラスターをv8.4.0以降のバージョンにアップグレードする前に、必ずTiCDCとPITRに切り替えてください。
以下の機能は将来のバージョンで削除される予定です。
- TiDB Lightning v8.0.0以降、物理インポートモードの競合検出の古いバージョン戦略は非推奨となり、
conflict.strategyパラメータを使用して論理インポートモードと物理インポートモードの両方の競合検出戦略を制御できるようになりました。旧バージョンの競合検出用のduplicate-resolutionパラメータは、将来のリリースで削除される予定です。
- TiDB Lightning v8.0.0以降、物理インポートモードの競合検出の古いバージョン戦略は非推奨となり、
非推奨の機能
以下の機能は将来のバージョンで廃止される予定です。
- TiDBでは、統計を自動的に収集するタスクの順序を最適化するために、優先度キューを有効にするかどうかを制御するためのシステム変数
tidb_enable_auto_analyze_priority_queueが導入されました。将来のリリースでは、統計を自動的に収集するタスクの順序付けは優先度キューのみになるため、このシステム変数は非推奨となります。 - TiDBはv7.5.0でシステム変数
tidb_enable_async_merge_global_stats導入しました。この変数を使用すると、TiDBがパーティション統計情報を非同期にマージするように設定し、OOM問題を回避することができます。将来のリリースでは、パーティション統計情報は非同期にマージされるため、このシステム変数は非推奨となります。 - 以降のリリースでは実行計画バインディングの自動進化再設計する予定であり、関連する変数と動作が変更されます。
- TiDB v8.0.0では、並列HashAggアルゴリズムのディスクスピルをサポートするかどうかを制御するシステム変数
tidb_enable_parallel_hashagg_spill導入されました。将来のバージョンでは、システム変数tidb_enable_parallel_hashagg_spill非推奨となる予定です。 - TiDB Lightningパラメータ
conflict.max-record-rows将来のリリースで廃止される予定であり、その後削除されます。このパラメータはconflict.thresholdに置き換えられます。これは、競合レコードの最大数が、単一のインポートタスクで許容される競合レコードの最大数と一致することを意味します。 - バージョン6.3.0以降、パーティションテーブルはデフォルトで動的剪定モード使用します。静的プルーニングモードと比較して、動的プルーニングモードはIndexJoinやプランキャッシュなどの機能をサポートし、パフォーマンスが向上します。そのため、静的プルーニングモードは非推奨となります。
改善点
TiDB
- 大量のデータをスキャンする際のBatchCopタスクの構築効率を最適化＃55915 ＃55413 @ wshwsh12
- トランザクションのバッファを最適化して、トランザクションの書き込みレイテンシーと TiDB CPU 使用率＃55287 @ あなた06を削減します
- システム変数
tidb_dml_type"bulk"＃50215 @ エキシウムに設定されている場合にDMLステートメントの実行パフォーマンスを最適化します。 - オプティマイザー修正制御 47400使用して、オプティマイザが
estRowsから1推定最小値を制限するかどうかを制御します。これは、Oracle や Db2 ＃47400 @ テリー・パーセルなどのデータベースと一致しています。 mysql.tidb_runaway_queriesログテーブルに書き込み制御を追加して、多数の同時書き込みによるオーバーヘッドを削減します＃54434 @ HuSharp- 内部テーブルに
Selection、Projection、またはAggregation演算子がある場合、デフォルトでインデックス結合をサポートします＃47233 @ ウィノロス - 特定のシナリオで
DELETE操作につき TiKV から取得される列詳細の数を減らし、これらの操作のリソース オーバーヘッドを＃38911 @ ウィノロスに削減します。 - システム変数
tidb_auto_analyze_concurrency＃53460 @ ホーキングレイを使用して、TiDB クラスター内の自動分析操作の同時実行性の設定をサポートします。 - 内部関数のロジックを最適化して、多数の列を持つテーブルをクエリする際のパフォーマンスを向上します＃52112 @ ラスティン170506
- フィルター条件
a = 1 AND b = 2a = 1 AND (a > 1 OR (a = 1 AND b = 2))＃56005ようガザルファミリーUSA簡素化する - 最適でない実行プランのリスクが高いシナリオでは、コストモデルでテーブルスキャンのコストを増やし、オプティマイザがインデックス＃56012 @ テリー・パーセルを優先するようにします。
- TiDBは2つの引数のバリアント
MID(str, pos)＃52420 @ ドヴェーデンをサポートしています - 非バイナリ主キー＃55660 @ lcwangchaoを持つテーブルの TTL タスクの分割をサポート
- システムメタデータ関連ステートメントのパフォーマンスを最適化する＃50305 @ ywqzzy @ 接線 @ ヨッヘンrh @ CbcWestwolf
- 自動分析操作用の新しい優先キューを実装して、分析パフォーマンスを向上させ、キュー＃55906 @ ラスティン170506の再構築コストを削減します。
- 統計モジュールがDDLイベント＃55722 @ fzzf678 @ ランス6716 @ ラスティン170506をサブスクライブできるようにDDL通知機能を導入する
- TiDB のアップグレード中に新しい TiDB ノードに DDL 所有権を強制的に引き継がせ、古い TiDB ノードが所有権＃51285 @ wjhuang2016を引き継ぐことによる互換性の問題を回避します。
- クラスターレベルの散布リージョン＃8424 @ リバー2000iをサポート
TiKV
- リージョン＃17309がLykxSassinatorつ以上あることによる余分なオーバーヘッドを回避するために、リージョンのデフォルト値を96 MiBから256 MiBに増やします。
- リージョンまたはTiKVインスタンスにおけるメモリ内悲観的ロックのメモリ使用量制限の設定をサポートします。ホットライトシナリオによって大量の悲観的ロックが発生する場合は、設定によりメモリ制限を増やすことができます。これにより、悲観的ロックのディスクへの書き込みによって発生するCPUおよびI/Oのオーバーヘッドを回避できます＃17542 @ cfzjywxk
- Raft Engineに新しい
spill-dir設定項目を導入し、 Raftログのマルチディスクstorageをサポートします。ホームディレクトリ（dir）があるディスクの容量が不足すると、 Raft Engineは自動的に新しいログをspill-dirに書き込み、システムの継続的な動作を保証します＃17356 @ LykxSassinator - RocksDB の圧縮トリガー メカニズムを最適化し、多数の DELETE バージョン＃17269 @ アンドレ・ムーシュを処理するときにディスク領域の再利用を高速化します。
- 書き込み操作のフロー制御構成の動的な変更をサポート＃17395 @ 栄光
- 空のテーブルと小さなリージョン＃17376 @ LykxSassinatorシナリオでのリージョン結合の速度を改善
- パイプラインDMLresolved-ts を長期間ブロックするのを防ぐ＃17459 @ エキシウム
PD
TiFlash
ツール
バグ修正
TiDB
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 @ wjhuang2016が含まれている場合にエラーが発生する問題を修正しました
- 除算演算で最小表示長を持つ整数型のデータで除算結果が＃55837 @ ウィンドトーカーにオーバーフローする可能性がある問題を修正しました。
- TopN演算子に続く演算子がメモリ制限を超えたときにフォールバックアクションをトリガーできない問題を修正＃56185 @ xzhangxian1008
- ソート演算子の
ORDER BY列目に定数＃55344 @ xzhangxian1008が含まれている場合に、その列が動かなくなる問題を修正しました。 - インデックスを追加するときに、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 @ HuSharpの誤った時間タイプを修正
TiKV
TiFlash
ツール
バックアップと復元 (BR)
TiDB データ移行 (DM)
TiDB Lightning
寄稿者
TiDB コミュニティからの以下の貢献者に感謝いたします。