TiDB 8.4.0 リリースノート
発売日：2024年11月11日
TiDB バージョン: 8.4.0
クイックアクセス: クイックスタート
バージョン8.4.0では、以下の主要な機能と改善点が導入されています。
機能の詳細
パフォーマンス
TSOリクエストに並列バッチモードを導入し、TSO取得のレイテンシーを削減する#54960 #8432 @MyonKeminta
バージョン8.4.0より前では、TiDBはPDからTSO要求する際に、特定の期間に複数のTSO要求を収集し、それらをバッチ処理で順次処理することで、リモートプロシージャコール（RPC）要求の数を減らし、PDのワークロードを軽減していました。しかし、レイテンシに敏感なシナリオでは、この逐次バッチ処理モードのパフォーマンスは理想的ではありませんでした。
TiDB v8.4.0では、異なる同時実行能力を持つTSOリクエスト用の並列バッチモードが導入されました。並列モードはTSO取得のレイテンシーを短縮しますが、PDのワークロードが増加する可能性があります。TSO取得に並列RPCモードを設定するには、
tidb_tso_client_rpc_modeシステム変数を構成してください。詳細については、 ドキュメントを参照してください。
TiDB のハッシュ結合演算子の実行効率を最適化する (実験的) #55153 #53127 @windtalker@xzhangxian1008 @XuHuaiyu@wshwsh12
TiDB v8.4.0では、ハッシュ結合演算子の最適化バージョンが導入され、実行効率が向上しました。現在、最適化バージョンのハッシュ結合は内部結合と外部結合操作にのみ適用され、デフォルトでは無効になっています。この最適化バージョンを有効にするには、
tidb_hash_join_versionシステム変数をoptimizedに設定してください。詳細については、 ドキュメントを参照してください。
TiKVへの以下の日付関数のプッシュダウンをサポート#56297 #17529 @gengliqi
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 @mjonss@Defined2014 @jiyfhust@L-maple
TiDBの初期バージョンでは、パーティションテーブルはグローバルインデックスをサポートしていないため、いくつかの制限がありました。たとえば、一意キーはテーブルのパーティション式内のすべての列を使用する必要があります。クエリ条件でパーティションキーを使用しない場合、クエリはすべてのパーティションをスキャンするため、パフォーマンスが低下します。v7.6.0以降では、グローバルインデックス機能を有効にするためにシステム変数
tidb_enable_global_indexが導入されました。しかし、この機能は当時開発中であったため、有効にすることは推奨されません。バージョン8.3.0以降、グローバルインデックス機能は実験的機能としてリリースされました。
GLOBALキーワードを使用すると、パーティションテーブルのグローバルインデックスを明示的に作成できます。これにより、パーティションテーブルの一意キーにパーティション式で使用されるすべての列を含める必要があるという制約がなくなり、より柔軟なアプリケーション要件に対応できるようになります。さらに、グローバルインデックスは、パーティション化されていない列に基づくクエリのパフォーマンスも向上させます。バージョン 8.4.0 では、この機能が一般提供 (GA) になります。グローバル インデックス機能を有効にするためにシステム変数
tidb_enable_global_indexを設定する代わりに、キーワードGLOBALを使用してグローバル インデックスを作成できます。バージョン 8.4.0 以降、このシステム変数は非推奨となり、常にONになります。詳細については、ドキュメントを参照してください。
一部のシナリオでキャッシュされたテーブルのクエリパフォーマンスを改善 #43249 @tiancaiamao
バージョン8.4.0では、TiDBは
SELECT ... LIMIT 1IndexLookupと共に実行する際に、キャッシュされたテーブルのクエリパフォーマンスを最大5.4倍向上させます。さらに、TiDBはフルテーブルスキャンと主キークエリのシナリオにおいて、IndexLookupReaderのパフォーマンスを向上させます。
信頼性
暴走クエリは、処理されたキーとリクエストユニットの数をしきい値としてサポートします #54434 @HuSharp
バージョン8.4.0以降、TiDBは処理されたキーの数（
PROCESSED_KEYS）とリクエストユニットの数（RU）に基づいて、暴走クエリを識別できるようになりました。実行時間（EXEC_ELAPSED）と比較すると、これらの新しいしきい値はクエリのリソース消費をより正確に定義し、全体的なパフォーマンスが低下した際の識別バイアスを回避します。複数の条件を同時に設定することができ、いずれかの条件が満たされた場合、そのクエリは暴走クエリとして識別されます。
履歴実行に基づいて条件値を決定するには、 概要表で対応するフィールド（
RESOURCE_GROUPMAX_REQUEST_UNIT_WRITEMAX_REQUEST_UNIT_READ、MAX_PROCESSED_KEYS）ステートメントサマリーテーブルを確認できます。詳細については、 ドキュメントを参照してください。
暴走クエリに対するリソースグループの切り替えのサポート #54434 @JmPotato
TiDB v8.4.0以降では、暴走クエリのリソースグループを特定のリソースグループに切り替えることができます。
COOLDOWNメカニズムでリソース消費量を削減できない場合は、 リソースグループを作成し、そのリソースサイズを制限し、SWITCH_GROUPパラメータを設定して、識別された暴走クエリをこのグループに移動できます。一方、同じセッション内の後続のクエリは、元のリソースグループで引き続き実行されます。リソースグループを切り替えることで、リソース使用状況をより正確に管理し、リソース消費量をより厳密に制御できます。詳細については、 ドキュメントを参照してください。
tidb_scatter_regionシステム変数を使用してクラスターレベルのリージョン散乱戦略を設定することをサポートします #55184 @D3Hunterバージョン8.4.0より前では、
tidb_scatter_regionシステム変数は有効化または無効化のみが可能でした。有効化すると、TiDBはバッチテーブル作成時にテーブルレベルの分散戦略を適用します。しかし、バッチで数十万ものテーブルを作成する場合、この戦略によってリージョンが少数のTiKVノードに集中し、それらのノードでOOM（メモリ不足）の問題が発生します。バージョン8.4.0以降、
tidb_scatter_regionは文字列型に変更されました。これにより、クラスタレベルの分散戦略がサポートされ、前述のシナリオにおけるTiKVのメモリ不足問題を回避するのに役立ちます。詳細については、ドキュメントを参照してください。
リソース制御のバックグラウンドタスクにおけるリソース使用量の上限設定をサポートする #56019 @glorv
TiDBのリソース制御機能を使用すると、バックグラウンドタスクを識別して優先度を下げることができます。特定のシナリオでは、リソースが利用可能な場合でも、バックグラウンドタスクのリソース消費を制限したい場合があります。v8.4.0以降では、
UTILIZATION_LIMITパラメータを使用して、バックグラウンドタスクが消費できるリソースの最大割合を設定できます。各ノードは、すべてのバックグラウンドタスクのリソース使用量をこの割合以下に抑えます。この機能により、バックグラウンドタスクのリソース消費を正確に制御できるため、クラスタの安定性がさらに向上します。詳細については、 ドキュメントを参照してください。
リソースグループのリソース割り当て戦略を最適化する #50831 @nolouch
TiDBはバージョン8.4.0でリソース割り当て戦略を改善し、リソース管理に関するユーザーの期待にさらに応えられるようにしました。
- 実行時に大規模クエリのリソース割り当てを制御してリソースグループの制限を超えないようにし、暴走クエリ
COOLDOWNと組み合わせることで、大規模クエリの同時実行を特定して削減し、瞬間的なリソース消費を削減できます。 - デフォルトの優先度スケジューリング戦略を調整します。優先度の異なるタスクが同時に実行される場合、優先度の高いタスクにより多くのリソースが割り当てられます。
- 実行時に大規模クエリのリソース割り当てを制御してリソースグループの制限を超えないようにし、暴走クエリ
可用性
TiProxyがトラフィック再生をサポート（実験的） #642 @djshow832
TiProxy v1.3.0以降では、
tiproxyctlを使用してTiProxyインスタンスに接続し、TiDB本番クラスタのアクセストラフィックをキャプチャして、指定したレートでテストクラスタに再生できます。この機能により、本番クラスタの実際のワークロードをテスト環境で再現し、SQLステートメントの実行結果とパフォーマンスを検証できます。交通状況のリプレイは、次のような状況で役立ちます。
- TiDBのバージョンアップグレードを確認する
- 変更の影響を評価する
- TiDBを拡張する前にパフォーマンスを検証する
- 試験性能限界
詳細については、ドキュメントを参照してください。
SQL
ベクトル検索のサポート (実験的) #54245 #17290 #9032 @breezewish@Lloyd-Pottiger@zimulalaエリックゼクアン@ジムララ@JaySon-Huang@winoros@wk989898
ベクトル検索は、データの意味論に基づいた検索手法であり、より関連性の高い検索結果を提供します。AIや大規模言語モデル（LLM）の中核関数の一つとして、ベクトル検索は、検索拡張生成（RAG）、意味検索、推薦システムなど、さまざまなシナリオで活用できます。
v8.4.0 以降、TiDB は ベクトルデータ型とベクトル検索インデックスをサポートし、強力なベクトル検索機能を提供します。 TiDB ベクトル データ タイプは、最大 16,383 次元をサポートし、L2 距離 (ユークリッド距離)、コサイン距離、負の内積、L1 距離 (マンハッタン距離) を含むさまざまな距離関数をサポートします。
ベクトル検索を開始するには、ベクトルデータ型のテーブルを作成し、ベクトルデータを挿入し、ベクトルデータに対するクエリを実行するだけで済みます。ベクトルデータと従来の関係データを組み合わせたクエリを実行することも可能です。
ベクトル検索のパフォーマンスを向上させるために、ベクトル検索インデックスを作成して使用できます。 TiDB ベクトル検索インデックスはTiFlashに依存していることに注意してください。ベクトル検索インデックスを使用する前に、 TiFlashノードが TiDB クラスターにデプロイされていることを確認してください。
詳細については、ドキュメントを参照してください。
データベース操作
BRはログ バックアップ データのクライアント側暗号化をサポートします (実験的) #55834 @Tristan1900
以前のTiDBバージョンでは、スナップショットバックアップデータのみがクライアント側で暗号化されていました。v8.4.0以降では、ログバックアップデータもクライアント側で暗号化できるようになりました。ログバックアップデータをバックアップストレージにアップロードする前に、以下のいずれかの方法でバックアップデータを暗号化してセキュリティを確保できます。
- カスタム固定キーを使用して暗号化する
- ローカルディスクに保存されているマスターキーを使用して暗号化します。
- キー管理サービス（KMS）によって管理されるマスターキーを使用して暗号化します。
詳細については、 ドキュメントを参照してください。
BRはクラウドストレージシステムでバックアップデータを復元する際に、より少ない権限しか必要としない #55870 @Leavrth
バージョン8.4.0より前は、 BRはリストア中にリストアの進行状況に関するチェックポイント情報をバックアップストレージシステムに書き込みます。これらのチェックポイントにより、中断されたリストアを迅速に再開できます。バージョン8.4.0以降では、 BRはリストアチェックポイント情報をターゲットのTiDBクラスタに書き込みます。つまり、 BRはリストア中にバックアップディレクトリへの読み取りアクセスのみを必要とします。
詳細については、 ドキュメントを参照してください。
可観測性
TiDBとTiKVが消費したCPU時間をシステムテーブルに表示する #55542 @yibin87
TiDB DashboardのTop SQLページCPU 使用率の高い SQL ステートメントを表示します。バージョン 8.4.0 以降、TiDB はシステム テーブルに CPU 使用時間情報を追加し、セッションや SQL の他のメトリックと並べて表示することで、CPU 使用率の高い操作をさまざまな視点から簡単に把握できるようにしました。この情報は、インスタンスの CPU スパイクやクラスタ内の読み書きホットスポットなどのシナリオで、問題の原因を迅速に特定するのに役立ちます。
- ステートメントサマリーテーブルには
AVG_TIDB_CPU_TIMEとAVG_TIKV_CPU_TIMEが追加され、過去の個々の SQL ステートメントによって消費された平均 CPU 時間が表示されます。 - 情報スキーマ.プロセスリストテーブルには、
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 @nolouch
バージョン8.4.0より前は、 Top SQL SQLごとにCPU時間を集計していました。CPU時間が少数のSQL文によって消費されていない場合、SQLによる集計では問題を効果的に特定できませんでした。バージョン8.4.0以降では、CPU時間をテーブル別またはデータベース別に集計できるようになりました。複数のシステムが存在するシナリオでは、この新しい集計方法により、特定のシステムからの負荷変動をより効果的に特定でき、診断効率が向上します。
詳細については、ドキュメントを参照してください。
セキュリティ
BRはAWS IMDSv2をサポートしています #16443 @pingyu
TiDBをAmazon EC2にデプロイする場合、 BRはAWSインスタンスメタデータサービスバージョン2（IMDSv2）をサポートします。EC2インスタンスを設定することで、 BRがインスタンスに関連付けられたIAMロールを使用してAmazon S3にアクセスするための適切な権限を取得できます。
詳細については、 ドキュメントを参照してください。
データ移行
TiCDC Claim-Check は、Kafka メッセージの
valueフィールドの外部ストレージへの送信のみをサポートします #11396 @3AceShowHandバージョン 8.4.0 より前では、クレームチェック機能が有効になっている場合 (
large-message-handle-optionをclaim-checkに設定した場合)、TiCDC は大きなメッセージを処理する際に、keyとvalueフィールドの両方をエンコードして外部ストレージシステムに保存します。バージョン8.4.0以降、TiCDCはKafkaメッセージの
valueフィールドのみを外部ストレージに送信する機能をサポートしています。この機能は、Open Protocol以外のプロトコルにのみ適用されます。claim-check-raw-valueパラメータを設定することで、この機能を制御できます。詳細については、 ドキュメントを参照してください。
TiCDC は、更新または削除イベントで古い値を検証するための Checksum V2 を導入 #10969 @3AceShowHand
バージョン 8.4.0 以降、TiDB と TiCDC は
ADD COLUMNまたはDROP COLUMN操作後の Update イベントまたは Delete イベントで古い値を検証する際の Checksum V1 の問題に対処するため、Checksum V2 アルゴリズムを導入しました。バージョン 8.4.0 以降で作成されたクラスタ、またはバージョン 8.4.0 にアップグレードされたクラスタでは、単一行データのチェックサム検証が有効になっている場合、TiDB はデフォルトで Checksum V2 を使用します。TiCDC は Checksum V1 と V2 の両方の処理をサポートしています。この変更は TiDB と TiCDC の内部実装にのみ影響し、下流の Kafka コンシューマーのチェックサム計算方法には影響しません。詳細については、ドキュメントを参照してください。
互換性の変更
注記：
このセクションでは、v8.3.0 から最新バージョン (v8.4.0) にアップグレードする際に知っておくべき互換性の変更点について説明します。v8.2.0 以前のバージョンから最新バージョンにアップグレードする場合は、中間バージョンで導入された互換性の変更点も確認する必要があるかもしれません。
システム変数
コンフィグレーションパラメータ
オフラインパッケージの変更
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 以降にアップグレードすると、クラスタが使用できなくなります。
削除された機能
バージョン8.4.0以降、以下の機能が削除されます。
- バージョン 8.4.0 では、 TiDB Binlogは削除されました。バージョン 8.3.0 以降、TiDB Binlog は完全に非推奨となっています。増分データレプリケーションには、代わりにTiCDCを使用してください。ポイントインタイムリカバリ(PITR) には、 PITRを使用してください。TiDB クラスタをバージョン 8.4.0 以降にアップグレードする前に、必ず TiCDC と PITR に切り替えてください。
今後のバージョンでは、以下の機能が削除される予定です。
- バージョン8.0.0以降、 TiDB Lightningは旧バージョンの競合検出戦略を非推奨とし、
conflict.strategyパラメータを使用して論理インポートモードと物理インポートモードの両方の競合検出戦略を制御できるようにします。旧バージョンの競合検出のduplicate-resolutionパラメータは、今後のリリースで削除されます。
- バージョン8.0.0以降、 TiDB Lightningは旧バージョンの競合検出戦略を非推奨とし、
非推奨機能
以下の機能は、将来のバージョンで廃止される予定です。
- TiDBでは、統計情報を自動的に収集するタスクの順序を最適化するために優先度キューを有効にするかどうかを制御するためのシステム変数
tidb_enable_auto_analyze_priority_queueが導入されました。今後のリリースでは、統計情報を自動的に収集するタスクの順序付けには優先度キューが唯一の方法となるため、このシステム変数は非推奨となります。 - TiDBはv7.5.0でシステム変数
tidb_enable_async_merge_global_statsを導入しました。この変数を使用すると、TiDBがパーティション統計の非同期マージを使用するように設定し、メモリ不足の問題を回避できます。今後のリリースでは、パーティション統計は非同期でマージされるため、このシステム変数は非推奨となります。 - 今後のリリースでは 実行プランバインディングの自動進化が再設計される予定であり、関連する変数と動作が変更されます。
- バージョン8.0.0では、TiDBが並列ハッシュアグリゲーションアルゴリズムのディスクスピルをサポートするかどうかを制御するシステム変数
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 @you06
- システム変数
tidb_dml_typeが"bulk"に設定されている場合の DML ステートメントの実行パフォーマンスを最適化する #50215 @ekexium - オプティマイザー修正制御 47400の使用をサポートし、オプティマイザーが
estRowsの推定最小値を1。これは、Oracle や Db2 などのデータベースと一貫性があります #47400 @terry1purcell mysql.tidb_runaway_queriesログ テーブルに書き込み制御を追加し、多数の同時書き込みによって発生するオーバーヘッドを削減します #54434 @HuSharp- 内部テーブルに
Selection、Projection、またはAggregation演算子がある場合、デフォルトでインデックス結合をサポートします #47233 @winoros - 特定のシナリオにおける
DELETE操作のために TiKV から取得する列の詳細の数を減らし、これらの操作のリソースオーバーヘッドを削減します #38911 @winoros - TiDBクラスタ内での自動分析操作の同時実行設定をシステム変数
tidb_auto_analyze_concurrencyを使用してサポートする #53460 @hawkingrei - 多数の列を持つテーブルをクエリする際のパフォーマンスを向上させるため、内部関数のロジックを最適化します #52112 @Rustin170506
a = 1 AND (a > 1 OR (a = 1 AND b = 2))からa = 1 AND b = 2のようなフィルター条件を簡素化 #56005 @ghazalfamilyusa- 最適ではない実行プランのリスクが高いシナリオでは、コストモデルでテーブルスキャンのコストを増やし、オプティマイザがインデックスを優先するようにします #56012 @terry1purcell
- TiDB は 2 つの引数を持つバリアント
MID(str, pos)をサポートしています #52420 @dveeden - バイナリ型以外の主キーを持つテーブルのTTLタスクの分割をサポート #55660 @lcwangchao
- システムのメタデータ関連ステートメントのパフォーマンスを最適化する #50305 @ywqzzy @tangenta@joechenrh @CbcWestwolf
- 自動分析操作に新しい優先度キューを実装して、分析パフォーマンスを向上させ、キューの再構築コストを削減します #55906 @Rustin170506
- 統計モジュールがDDLイベントを購読できるように、DDL通知機能を導入する #55722 @fzzf678 @lance6716 @Rustin170506
- TiDB のアップグレード中に、新しい TiDB ノードが DDL の所有権を引き継ぐように強制することで、古い TiDB ノードが所有権を引き継ぐことによる互換性の問題を回避する #51285 @wjhuang2016
- クラスターレベルの散乱リージョンをサポート #8424 @River2000i
TiKV
- リージョンのデフォルト値を 96 MiB から 256 MiB に増やして、Region が多すぎることによる余分なオーバーヘッドを回避します #17309 @LykxSassinator
- リージョンまたはTiKVインスタンスにおけるインメモリ悲観的ロックのメモリ使用量制限の設定をサポートします。ホットライトシナリオで多数の悲観的ロックが発生する場合、構成によってメモリ制限を増やすことができます。これにより、悲観的ロックがディスクに書き込まれることによって発生するCPUおよびI/Oオーバーヘッドを回避できます。 #17542 @cfzjywxk
- Raft Engineに新しい設定項目
spill-dirを導入し、 Raftログのマルチディスクストレージをサポートします。ホームディレクトリ (dirが配置されているディスクの空き容量がなくなると、 Raft Engine は新しいログを自動的にspill-dirに書き込み、システムの継続的な動作を保証します #17356 @LykxSassinator - RocksDB の圧縮トリガー メカニズムを最適化し、多数の DELETE バージョンを処理する際のディスク領域の再利用を加速します #17269 @AndreMouche
- 書き込み操作のフロー制御構成を動的に変更するサポート #17395 @glorv
- 空のテーブルと小さなリージョンを含むシナリオでのリージョンマージの速度を改善 #17376 @LykxSassinator
- パイプラインDMLresolved-ts を長期間ブロックしないようにします #17459 @ekexium
PD
TiFlash
LENGTH()およびASCII()関数の実行効率を最適化する #9344 @xzhangxian1008- TiFlashが分散ストレージとコンピューティング要求を処理する際に作成する必要のあるスレッド数を減らし、そのような要求を多数処理する際のTiFlashコンピューティングノードのクラッシュを回避するのに役立ちます #9334 @JinheLin
- パイプライン実行モデルにおけるタスク待機メカニズムの強化 #8869 @SeaRise
- JOIN オペレーターがキャンセル要求にタイムリーに応答できるように、JOIN オペレーターのキャンセル メカニズムを改善 #9430 @windtalker
ツール
Backup & Restore (BR)
split-tableおよびsplit-region-on-table構成項目がfalse(デフォルト値) であるクラスターにデータを復元する際、テーブルによるリージョンの分割を無効にすることで復元速度を向上させます。 #53532 @Leavrth- デフォルトでは、
RESTORESQL ステートメントを使用して、空ではないクラスターへの完全なデータの復元を無効にします #55087 @BornChanger
バグ修正
TiDB
tidb_restricted_read_only変数がtrueに設定されている場合にデッドロックが発生する可能性がある問題を修正します。 #53822 #55373 @Defined2014- TiDBが正常シャットダウン中に自動コミットトランザクションの完了を待たない問題を修正 #55464 @YangKeao
- TTLジョブ実行中に
tidb_ttl_delete_worker_countの値を減らすとジョブが完了しない問題を修正 #55561 @lcwangchao - テーブルのインデックスに生成列が含まれている場合、
Unknown column 'column_name' in 'expression'ステートメントを使用してテーブルの統計情報を収集する際にANALYZEエラーが発生する可能性がある問題を修正しました。 #55438 @hawkingrei - 統計関連の不要な設定を非推奨にして、冗長なコードを削減する #55043 @Rustin170506
- 相関サブクエリとCTEを含むクエリを実行するとTiDBがハングアップしたり、誤った結果を返す可能性がある問題を修正しました #55551 @guo-shaoge
lite-init-statsを無効にすると統計情報が同期的に読み込まれない可能性がある問題を修正しました #54532 @hawkingreiUPDATEまたはDELETEステートメントに再帰 CTE が含まれている場合、ステートメントがエラーを報告するか、効果を発揮しない可能性がある問題を修正します #55666 @time-and-fate- ウィンドウ関数を含む SQL バインディングが場合によっては有効にならない問題を修正しました #55981 @winoros
- 非バイナリ照合順序を持つ文字列列の統計情報が、統計情報の初期化時にロードに失敗する可能性がある問題を修正 #55684 @winoros
- クエリ条件
column IS NULLを使用して一意インデックスにアクセスする際に、オプティマイザが行数を誤って 1 と推定する問題を修正しました。 #56116 @hawkingrei - クエリに
(... AND ...) OR (... AND ...) ...のようなフィルタ条件が含まれている場合、オプティマイザが行数推定に最適な複数列統計情報を使用しない問題を修正します #54323 @time-and-fate - クエリに利用可能なインデックス マージ実行プランがある場合、
read_from_storageヒントが有効にならない可能性がある問題を修正 #56217 @AilinKid IndexNestedLoopHashJoinのデータ競合問題を修正 #49692 @solotzgSUB_PARTテーブル内のINFORMATION_SCHEMA.STATISTICSの値がNULLになっている問題を修正します #55812 @Defined2014- DMLステートメントにネストされた生成列が含まれている場合にエラーが発生する問題を修正しました #53967 @wjhuang2016
- 除算演算において最小表示長の整数型データを使用すると除算結果がオーバーフローする場合がある問題を修正 #55837 @windtalker
- TopN オペレーターに続くオペレーターがメモリ制限を超えた場合にフォールバックアクションをトリガーできない問題を修正しました #56185 @xzhangxian1008
- ソート演算子の
ORDER BY列に定数が含まれている場合に、列が固定されてしまう問題を修正しました。 #55344 @xzhangxian1008 - インデックスを追加する際に、PDリーダーを終了させた後に
8223 (HY000)エラーが発生し、テーブル内のデータが不整合になる問題を修正しました #55488 @tangenta - DDL履歴ジョブが多すぎると、履歴DDLジョブに関する情報を要求するとOOMが発生する問題を修正 #55711 @joccau
- グローバルソートが有効で、リージョンサイズが96 MiBを超える場合に
IMPORT INTOの実行が停止する問題を修正しました。 #55374 @lance6716 - 一時テーブルで
IMPORT INTOを実行すると TiDB がクラッシュする問題を修正しました #55970 @D3Hunter - 一意インデックスを追加すると
duplicate entryエラーが発生する問題を修正 #56161 @tangenta - TiKVが810秒以上ダウンしている場合、 TiDB LightningがすべてのKVペアを取り込まないため、テーブル内のデータが不整合になる問題を修正しました #55808 @lance6716
CREATE TABLE LIKEステートメントがキャッシュされたテーブルに使用できない問題を修正 #56134 @tiancaiamao- CTE 内の
FORMAT()式の紛らわしい警告メッセージを修正 #56198 @dveeden - パーティションテーブルを作成する際に、
CREATE TABLEとALTER TABLEの間で列タイプの制限が矛盾する問題を修正 #56094 @mjonss INFORMATION_SCHEMA.RUNAWAY_WATCHESテーブル内の誤った時間タイプを修正 #54770 @HuSharp
TiKV
TiFlash
- テーブルに無効な文字を含むデフォルト値を持つビット型列が含まれている場合、 TiFlashがテーブルスキーマを解析できない問題を修正しました #9461 @Lloyd-Pottiger
- 複数のリージョンが同時にスナップショットを適用している際に発生する、リージョン重複チェックの誤った失敗によりTiFlashがpanic可能性がある問題を修正しました #9329 @CalvinNeo
- TiFlashでサポートされていない一部の JSON関数がTiFlashにプッシュダウンされる問題を修正 #9444 @windtalker
ツール
Backup & Restore (BR)
TiDB Data Migration (DM)
TiDB Lightning
- TiDB Lightning が、2 つのインスタンスが同時に並列インポートタスクを開始し、同じタスク ID が割り当てられた場合、
verify allocator base failedエラーを報告する問題を修正しました #55384 @ei-sugimoto
- TiDB Lightning が、2 つのインスタンスが同時に並列インポートタスクを開始し、同じタスク ID が割り当てられた場合、
貢献者
TiDBコミュニティの以下の貢献者の皆様に感謝申し上げます。
- ei-sugimoto
- eltociear
- guoshouyan (初回貢献者)
- JackL9u
- kafka1991 (初回貢献者)
- qingfeng777
- samba-rgb (初回貢献者)
- SeaRise
- tuziemon (初回貢献者)
- xyproto (初回貢献者)