TiDB 7.3.0 リリースノート
発売日：2023年8月14日
TiDB バージョン: 7.3.0
クイックアクセス: クイックスタート
7.3.0では、以下の主要機能が導入されています。さらに、7.3.0には、TiDBサーバーおよびTiFlashにおけるクエリの安定性を向上させるための一連の機能強化（機能の詳細セクションで説明）も含まれています。これらの機能強化は、より細かなものであり、ユーザーに直接影響を与えるものではないため、以下の表には含まれていません。
機能の詳細
パフォーマンス
TiFlashはレプリカ選択戦略をサポートしています #44106 @XuHuaiyu
バージョン 7.3.0 より前のTiFlashでは、パフォーマンスを最大化するために、すべてのノードのレプリカを使用してデータ スキャンと MPP 計算を行っていました。バージョン 7.3.0 以降では、 TiFlash はレプリカ選択戦略を導入し、システム変数
tiflash_replica_readを使用して設定できるようになりました。この戦略では、ノードのゾーン属性に基づいて特定のレプリカを選択し、データ スキャンと MPP 計算のために特定のノードをスケジュールすることができます。複数のデータセンターに展開され、各データセンターに完全なTiFlashデータレプリカが存在するクラスターの場合、この戦略を設定して、現在のデータセンターのTiFlashレプリカのみを選択することができます。これにより、データスキャンとMPP計算は現在のデータセンター内のTiFlashノードでのみ実行されるため、データセンター間での過剰なネットワークデータ転送を回避できます。
詳細については、 ドキュメントを参照してください。
TiFlash はノード内のランタイム フィルターをサポート #40220 @elsa0520
ランタイムフィルタは、クエリプランニングフェーズ中に生成される動的な述語です。テーブル結合処理において、これらの動的な述語は結合条件を満たさない行を効果的にフィルタリングし、スキャン時間とネットワークオーバーヘッドを削減し、テーブル結合の効率を向上させます。TiFlashはv7.3.0以降、ノード内でランタイムフィルタをサポートし、分析クエリの全体的なパフォーマンスを向上させています。一部のTPC-DSワークロードでは、パフォーマンスが10%から50%向上する可能性があります。
この機能はv7.3.0ではデフォルトで無効になっています。この機能を有効にするには、システム変数
tidb_runtime_filter_modeLOCALに設定してください。詳細については、ドキュメントを参照してください。
TiFlashは共通テーブル式（CTE）の実行をサポートします（実験的） #43333 @winoros
バージョン7.3.0より前のTiFlashのMPPエンジンは、デフォルトではCTEを含むクエリを実行できません。MPPフレームワーク内で最高の実行パフォーマンスを実現するには、システム変数
tidb_opt_force_inline_cteを使用してCTEのインライン化を強制する必要があります。バージョン7.3.0以降、TiFlashのMPPエンジンは、CTEをインライン化せずにクエリを実行できるようになり、MPPフレームワーク内での最適なクエリ実行が可能になりました。TPC-DSベンチマークテストでは、CTEをインライン化する場合と比較して、この機能によりCTEを含むクエリの全体的な実行速度が20%向上することが確認されています。
この機能は実験的であり、デフォルトでは無効になっています。システム変数
tidb_opt_enable_mpp_shared_cte_executionによって制御されます。
信頼性
新しいオプティマイザヒントを追加 #45520 @qw4990
TiDB v7.3.0では、テーブル間の結合方法を制御するための新しいオプティマイザヒントがいくつか導入されています。これには以下が含まれます。
NO_MERGE_JOIN()は、マージ結合以外の結合方法を選択します。NO_INDEX_JOIN()は、インデックスネストループ結合以外の結合方法を選択します。NO_INDEX_MERGE_JOIN()は、インデックスネストループマージ結合以外の結合方法を選択します。NO_HASH_JOIN()は、ハッシュ結合以外の結合方法を選択します。NO_INDEX_HASH_JOIN()はインデックスネストループハッシュ結合以外の結合方法を選択します。
詳細については、ドキュメントを参照してください。
予想以上にリソースを使用するクエリを手動でマークする (実験的) #43691 @Connor1996 @CabinfeverB
TiDB v7.2.0では、想定以上のリソースを使用するクエリ（暴走クエリ）を自動的にダウングレードまたはキャンセルすることで、TiDBが自動的に管理します。しかし、実際の運用では、ルールだけではすべてのケースに対応できません。そこで、TiDB v7.3.0では、暴走クエリを手動でマークする機能が導入されました。新しいコマンド
QUERY WATCHを使用すると、SQLテキスト、SQLダイジェスト、または実行プランに基づいて暴走クエリをマークでき、マークされた暴走クエリをダウングレードまたはキャンセルできます。この機能は、データベースにおける突発的なパフォーマンス問題に対する効果的な介入手段を提供します。クエリによって引き起こされるパフォーマンス問題の場合、根本原因を特定する前に、この機能によって全体的なパフォーマンスへの影響を迅速に軽減し、システムサービスの品質を向上させることができます。
詳細については、 ドキュメントを参照してください。
SQL
リストとリスト列のパーティションテーブルはデフォルトのパーティションをサポートします #20679 @mjonss@bb7133
バージョン 7.3.0 より前では、
INSERTステートメントを使用してリストまたはリスト COLUMNSパーティションテーブルにデータを挿入する場合、データはテーブルの指定されたパーティション条件を満たす必要があります。挿入するデータがこれらの条件のいずれにも満たない場合、ステートメントの実行が失敗するか、条件を満たさないデータは無視されます。バージョン7.3.0以降、ListおよびList COLUMNSパーティションテーブルはデフォルトパーティションをサポートします。デフォルトパーティションが作成された後、挿入するデータがパーティション条件を満たさない場合、そのデータはデフォルトパーティションに書き込まれます。この機能により、ListおよびList COLUMNS パーティショニングの使いやすさが向上し、
INSERTステートメントの実行失敗や、パーティション条件を満たさないデータによるデータの無視を防ぐことができます。この機能は、MySQL構文に対するTiDBの拡張機能であることに注意してください。デフォルトのパーティションを持つパーティションテーブルの場合、テーブル内のデータをMySQLに直接レプリケートすることはできません。
詳細については、ドキュメントを参照してください。
可観測性
統計収集の進行状況を表示 #44033 @hawkingrei
大規模テーブルの統計情報を収集するには、多くの場合、長い時間がかかります。以前のバージョンでは、統計情報の収集の進行状況を確認できなかったため、完了時間を予測できませんでした。TiDB v7.3.0 では、統計情報の収集の進行状況を表示する機能が導入されました。システムテーブル
mysql.analyze_jobsまたはSHOW ANALYZE STATUSを使用して、各サブタスクの全体的なワークロード、現在の進行状況、および推定完了時間を確認できます。大規模なデータインポートや SQL パフォーマンス最適化などのシナリオでは、この機能によりタスク全体の進行状況を把握しやすくなり、ユーザーエクスペリエンスが向上します。詳細については、 ドキュメントを参照してください。
Plan Replayer は履歴統計のエクスポートをサポート #45038 @time-and-fate
バージョン7.3.0以降、
dump with stats as of timestampが新たに追加されたため、Plan Replayerを使用して、指定した時点におけるSQL関連オブジェクトの統計情報をエクスポートできます。実行プランの問題を診断する際に、履歴統計情報を正確に取得することで、問題発生時に実行プランがどのように生成されたかをより詳細に分析できます。これにより、問題の根本原因を特定しやすくなり、実行プランの問題診断の効率が大幅に向上します。詳細については、ドキュメントを参照してください。
データ移行
TiDB Lightning で競合データ検出および処理戦略の新バージョンが導入されました #41629 @lance6716
以前のバージョンでは、 TiDB Lightning は論理インポート モードと物理インポート モードに対して異なる競合検出および処理方法を使用しており、設定が複雑でユーザーが理解しにくいものでした。さらに、物理インポート モードでは
replaceまたはignore戦略を使用して競合を処理することができませんでした。v7.3.0 以降、 TiDB Lightning は論理インポート モードと物理インポート モードの両方に対して統一された競合検出および処理戦略を導入しました。競合が発生した場合、競合するデータをエラーとして報告 (error)、置換 (replace)、または無視 (ignore) するかを選択できます。競合レコードの数を制限することもでき、たとえば、指定した数の競合レコードを処理した後、タスクが中断されて終了します。さらに、このシステムはトラブルシューティングのために矛盾するデータを記録することもできます。競合が多数含まれるインポートデータの場合、パフォーマンス向上のため、競合検出および処理戦略の新しいバージョンを使用することをお勧めします。ラボ環境では、新しいバージョンの戦略は、競合検出および処理のパフォーマンスを旧バージョンよりも最大3倍高速化できます。このパフォーマンス値は参考値です。実際のパフォーマンスは、構成、テーブル構造、および競合データの割合によって異なる場合があります。なお、競合戦略の新バージョンと旧バージョンは同時に使用できません。旧バージョンの競合検出および処理戦略は、将来的に廃止される予定です。
詳細については、 ドキュメントを参照してください。
TiDB Lightning がパーティション化されたRaft KV をサポート (実験的) #14916 @GMHDBJD
TiDB Lightningがパーティション化されたRaft KVをサポートするようになりました。この機能により、TiDB Lightningのデータインポートパフォーマンスが向上します。
TiDB Lightning は、より多くの診断ログを出力することでトラブルシューティングを強化する新しいパラメータ
enable-diagnose-logを導入しました #45497 @D3Hunterデフォルトでは、この機能は無効になっており、 TiDB Lightning は
lightning/mainを含むログのみを出力。有効にすると、 TiDB Lightning はclient-goおよびtidbに関連する問題の診断に役立つように、すべてのパッケージclient-goおよびtidbを含む) のログを出力します。詳細については、 ドキュメントを参照してください。
互換性の変更
注記：
このセクションでは、バージョン7.2.0から最新バージョン（7.3.0）にアップグレードする際に知っておくべき互換性の変更点について説明します。バージョン7.1.0以前のバージョンから最新バージョンにアップグレードする場合は、中間バージョンで導入された互換性の変更点も確認する必要があるかもしれません。
行動の変化
TiDB
- MPP はTiFlashエンジンが提供する分散コンピューティング フレームワークであり、ノード間でのデータ交換を可能にし、高性能かつ高スループットの SQL アルゴリズムを提供します。他のプロトコルと比較して、MPP プロトコルはより成熟しており、より優れたタスクおよびリソース管理を提供できます。v7.3.0 以降、TiDB が計算タスクをTiFlashにプッシュする場合、オプティマイザはデフォルトで MPP プロトコルを使用した実行プランのみを生成します。tidb_allow_mpp が
OFFに設定されている場合、TiDB をアップグレードした後にクエリでエラーが発生する可能性があります。tidb_allow_mpp前にtidb_allow_mppの値を確認し、ONに設定することをお勧めします。コスト見積もりに基づいて実行プランを生成するために、オプティマイザがCop、BatchCop、およびMPPプロトコルのいずれかを選択する必要がある場合は、tidb_allow_tiflash_cop変数をONに設定できます。
- MPP はTiFlashエンジンが提供する分散コンピューティング フレームワークであり、ノード間でのデータ交換を可能にし、高性能かつ高スループットの SQL アルゴリズムを提供します。他のプロトコルと比較して、MPP プロトコルはより成熟しており、より優れたタスクおよびリソース管理を提供できます。v7.3.0 以降、TiDB が計算タスクをTiFlashにプッシュする場合、オプティマイザはデフォルトで MPP プロトコルを使用した実行プランのみを生成します。tidb_allow_mpp が
バックアップと復元 (BR)
- BR は、完全なデータ復元を実行する前に、空のクラスタのチェックを追加します。デフォルトでは、空でないクラスタへのデータ復元は許可されていません。復元を強制する場合は、
--filterオプションを使用して、データを復元する対応するテーブル名を指定できます。
- BR は、完全なデータ復元を実行する前に、空のクラスタのチェックを追加します。デフォルトでは、空でないクラスタへのデータ復元は許可されていません。復元を強制する場合は、
TiDB Lightning
tikv-importer.on-duplicateは非推奨となり、conflict.strategyに置き換えられました。- TiDB Lightning が移行タスクを停止する前に許容できる非致命的なエラーの最大数を制御する
max-errorパラメータは、インポートデータの競合を制限しなくなりました。代わりに、conflict.thresholdパラメータが、許容できる競合レコードの最大数を制御するようになりました。
TiCDC
- KafkaシンクがAvroプロトコルを使用している場合、
force-replicateパラメータがtrueに設定されている場合、TiCDCはchangefeedを作成する際にエラーを報告します。 delete-only-output-handle-key-columnsとforce-replicateパラメータ間に互換性がないため、両方のパラメータが有効になっている場合、TiCDC は変更フィードを作成する際にエラーを報告します。- 出力プロトコルがオープンプロトコルの場合、
UPDATEイベントは変更された列のみを出力します。
- KafkaシンクがAvroプロトコルを使用している場合、
システム変数
コンフィグレーションファイルパラメータ
システムテーブル
- 内部タイマーのメタデータを格納するための新しいシステムテーブル
mysql.tidb_timersを追加します。
非推奨機能
TiDB
- 統計情報用の
Fast Analyze機能（実験的）は、バージョン7.5.0で廃止されます。 - 統計の増分収集機能は v7.5.0 で非推奨になります。
- 統計情報用の
改善点
TiDB
EXPLAINステートメントが最適化フェーズ中にサブクエリを事前に実行するかどうかを制御するための新しいシステム変数tidb_opt_enable_non_eval_scalar_subqueryを導入します #22076 @winoros- グローバルキルが有効な場合、 Ctrl+Cを押すと現在のセッションを終了できます #8854 @pingyu
IS_FREE_LOCK()およびIS_USED_LOCK()のロック関数をサポートする #44493 @dveeden- ディスクからダンプされたチャンクを読み取るパフォーマンスを最適化 #45125 @YangKeao
- Optimizer Fix Controls を使用してインデックス結合の内部テーブルの過大評価問題を最適化する #44855 @time-and-fate
TiKV
PD
TiFlash
- 新しい DTFile フォーマット バージョン
storage.format_version = 5をサポートして物理ファイルの数を削減します (実験的) #7595 @hongyunyan
- 新しい DTFile フォーマット バージョン
ツール
バックアップと復元 (BR)
TiCDC
UPDATEイベント送信時に更新された列値のみが含まれるように、Open Protocol 出力のメッセージ サイズを最適化します #9336 @3AceShowHandハンド- Storage Sink が HEX 形式のデータの 16 進数エンコーディングをサポートするようになり、AWS DMS フォーマット仕様との互換性が確保されました #9373 @CharlesCheung96
- Kafka Sink は、メッセージが大きすぎる場合にハンドルキーデータのみを送信するをサポートし、メッセージのサイズを削減します #9382 @3AceShowHand
バグ修正
TiDB
- MySQL Cursor Fetch プロトコルを使用した場合に、結果セットのメモリ消費量が
tidb_mem_quota_query制限を超え、TiDB のメモリ不足が発生する問題を修正しました。修正後、TiDB は自動的に結果セットをディスクに書き込み、メモリを解放します。 #43233 @YangKeao - データ競合によって引き起こされる TiDBpanic問題を修正 #45561 @gengliqi
indexMergeを含むクエリが強制終了されたときに発生するハングアップ問題を修正 #45279 @xzhangxian1008tidb_enable_parallel_applyが有効な場合、MPP モードでのクエリ結果が正しくない問題を修正 #45299 @windtalkerresolve lockPD時間の急激な変化時にハングアップする可能性がある問題を修正 #44822 @zyguan- GC Resolve Locks ステップで一部の悲観的ロックが見落とされる可能性がある問題を修正 #45134 @MyonKeminta
ORDER BYを含むクエリが動的プルーニングモードで誤った結果を返す問題を修正 #45007 @Defined2014AUTO_INCREMENTがDEFAULT列の値と同じ列に指定できてしまう問題を修正しました #45136 @Defined2014- システムテーブル
INFORMATION_SCHEMA.TIKV_REGION_STATUSをクエリした際に、場合によっては誤った結果が返される問題を修正しました #45531 @Defined2014 - 一部のケースでパーティションテーブルのプルーニングが正しく行われない問題を修正 #42273 @jiyfhust
- パーティションテーブルのパーティションを切り捨てる際にグローバルインデックスがクリアされない問題を修正 #42435 @L-maple
- TiDBノードの障害発生後、他のTiDBノードがTTLタスクを引き継がない問題を修正 #45022 lcwangchao
- TTL実行時のメモリリーク問題を修正 #45510 @lcwangchao
- パーティションテーブルにデータを挿入する際の不正確なエラーメッセージの問題を修正 #44966 @lilinghai
INFORMATION_SCHEMA.TIFLASH_REPLICAテーブルの読み取り権限の問題を修正 #7795 @Lloyd-Pottiger- パーティションテーブル名が間違っている場合にエラーが発生する問題を修正 #44967 @River2000i
tidb_enable_dist_taskが有効になっている場合にインデックス作成が停止する問題を修正 #44440 @tangenta- BR #44716を使用して
duplicate entryを含むテーブルを復元する際に発生するAUTO_ID_CACHE=1エラーを修正します。@tiancaiamao TRUNCATE TABLEの実行に要した時間がADMIN SHOW DDL JOBSに表示されるタスク実行時間と一致しない問題を修正しました。 #44785 @tangenta- TiDBのアップグレード時にメタデータの読み取りに1つのDDLリースよりも時間がかかると、アップグレードが停止する問題を修正しました #45176 @zimulala
SELECT CAST(n AS CHAR)ステートメント内のnが負の数の場合、クエリ結果が正しくない問題を修正しました #44786 @xheboxtidb_opt_agg_push_downが有効になっている場合にクエリが間違った結果を返す可能性がある問題を修正 #44795 @AilinKidcurrent_date()を含むクエリがプランキャッシュを使用した場合に発生する誤った結果の問題を修正します #45086 @qw4990
- MySQL Cursor Fetch プロトコルを使用した場合に、結果セットのメモリ消費量が
TiKV
- GC中にデータを読み取ると、まれにTiKVpanicが発生する可能性がある問題を修正しました #15109 @MyonKeminta
PD
- PD の再起動によって
defaultリソース グループが再初期化される可能性がある問題を修正 #6787 @glorv - etcdが既に起動しているがクライアントがまだ接続していない場合に、クライアントを呼び出すとPDがpanicを起こす可能性がある問題を修正しました #6860 @HuSharp
- リージョンの出力
health-checkが、リージョンID #6560を照会して返されるリージョン情報と一致しない問題を修正します。@JmPotato unsafe recoveryで失敗した学習者ピアがauto-detectモードでは無視される問題を修正 #6690 @v01dstar- 配置ルールがルールを満たしていないTiFlash学習者を選択してしまう問題を修正します #6662 @rleungx
- ルールチェッカーがピアを選択する際に、不健全なピアを削除できない問題を修正 #6559 @nolouch
- PD の再起動によって
TiFlash
- TiFlashがデッドロックのためにパーティション化されたテーブルを正常に複製できない問題を修正 #7758 @hongyunyan
INFORMATION_SCHEMA.TIFLASH_REPLICAシステム テーブルにユーザーがアクセスする権限を持たないテーブルが含まれる問題を修正 #7795 @Lloyd-Pottiger- 同じ MPP タスク内に複数の HashAgg 演算子が存在する場合、MPP タスクのコンパイルに非常に長い時間がかかり、クエリのパフォーマンスに深刻な影響を与える問題を修正しました #7810 @SeaRise
ツール
TiCDC
- PD #9294が一時的に利用できないために changefeeds が失敗する問題を修正しました @asddongmen
- TiCDCノードの一部がネットワークから隔離された場合に発生する可能性のあるデータ不整合の問題を修正します #9344 @CharlesCheung96
- Kafka Sinkでエラーが発生した場合、changefeedの進行が永久にブロックされる可能性がある問題を修正しました #9309 @hicqu
- TiCDCノードの状態変化時に発生する可能性のあるpanic問題を修正 #9354 @sdojjy
- デフォルトの
ENUM値のエンコード エラーを修正 #9259 @3AceShowHand
TiDB Lightning
寄稿者
TiDBコミュニティの以下の貢献者の皆様に感謝申し上げます。