TiDB 7.2.0 リリースノート
発売日: 2023年6月29日
TiDB バージョン: 7.2.0
クイックアクセス: クイックスタート
7.2.0 では、次の主要な機能と改善が導入されています。
機能の詳細
パフォーマンス
次の2つのウィンドウ関数をTiFlash #7427 @ 翻訳者に押し下げることをサポートします
FIRST_VALUELAST_VALUE
TiFlash はパイプライン実行モデル (実験的) #6518 @ シーライズをサポートしています
v7.2.0 より前では、 TiFlashエンジンの各タスクは実行中に個別にスレッド リソースを要求する必要があります。TiFlashはタスクの数を制御してスレッド リソースの使用を制限し、過剰使用を防止しますが、この問題を完全に排除することはできませんでした。この問題に対処するために、v7.2.0 以降、 TiFlash はパイプライン実行モデルを導入しています。このモデルは、すべてのスレッド リソースを集中管理し、タスク実行を均一にスケジュールして、スレッド リソースの使用率を最大化しながらリソースの過剰使用を回避します。パイプライン実行モデルを有効または無効にするには、
tidb_enable_tiflash_pipeline_modelシステム変数を変更します。詳細についてはドキュメント参照してください。
TiFlashはスキーマレプリケーションのレイテンシーを短縮します#7630 @ ホンユンヤン
テーブルのスキーマが変更されると、 TiFlash は最新のスキーマを TiKV からタイムリーに複製する必要があります。v7.2.0 より前では、 TiFlash がテーブル データにアクセスし、データベース内のテーブル スキーマの変更を検出すると、 TiFlash は、 TiFlashレプリカのないテーブルも含め、このデータベース内のすべてのテーブルのスキーマを再度複製する必要があります。その結果、多数のテーブルがあるデータベースでは、 TiFlashを使用して 1 つのテーブルからデータを読み取るだけでよい場合でも、 TiFlash がすべてのテーブルのスキーマ複製を完了するまで待機するレイテンシーが長くなる可能性があります。
v7.2.0 では、 TiFlash はスキーマ レプリケーション メカニズムを最適化し、 TiFlashレプリカを持つテーブルのスキーマのレプリケーションのみをサポートします。TiFlash レプリカを持つテーブルのスキーマ変更が検出されると、 TiFlash はそのテーブルのスキーマのみをレプリケーションします。これTiFlash、 TiFlashのスキーマ レプリケーションのレイテンシーが短縮され、 TiFlashデータ レプリケーションに対する DDL 操作の影響が最小限に抑えられます。この最適化は自動的に適用され、手動での構成は必要ありません。
統計収集のパフォーマンスを向上させる#44725 @ 翻訳者
TiDB v7.2.0 では、統計収集戦略が最適化され、重複した情報やオプティマイザーにとって価値の低い情報がスキップされます。統計収集の全体的な速度が 30% 向上しました。この改善により、TiDB はデータベースの統計をよりタイムリーに更新できるようになり、生成された実行プランがより正確になり、データベース全体のパフォーマンスが向上します。
デフォルトでは、統計収集では
JSON、BLOB、MEDIUMBLOB、およびLONGBLOBタイプの列がスキップされます。tidb_analyze_skip_column_typesシステム変数を設定することで、デフォルトの動作を変更できます。 TiDB は、JSON、BLOB、およびTEXTタイプとそのサブタイプのスキップをサポートしています。詳細についてはドキュメント参照してください。
データとインデックスの一貫性チェックのパフォーマンスを向上#43693 @ 翻訳:
ADMIN CHECK [TABLE|INDEX]ステートメントは、テーブル内のデータとそれに対応するインデックス間の一貫性をチェックするために使用されます。v7.2.0 では、TiDB はデータの一貫性をチェックする方法を最適化し、ADMIN CHECK [TABLE|INDEX]の実行効率を大幅に向上させました。大量のデータを扱うシナリオでは、この最適化によりパフォーマンスが数百倍向上します。最適化はデフォルトで有効(デフォルトでは
tidb_enable_fast_table_checkまたはON)になっており、大規模なテーブルでのデータ整合性チェックに必要な時間を大幅に短縮し、運用効率を高めます。詳細についてはドキュメント参照してください。
信頼性
予想よりも多くのリソースを消費するクエリを自動的に管理する (実験的) #43691 @ コナー1996 @ キャビンフィーバーB @ 栄光 @ ヒューシャープ @ ノルーシュ
データベースの安定性に対する最も一般的な課題は、突然の SQL パフォーマンスの問題によってデータベース全体のパフォーマンスが低下することです。SQL パフォーマンスの問題には、十分にテストされていない新しい SQL ステートメント、データ量の大幅な変更、実行プランの突然の変更など、多くの原因があります。これらの問題を根本的に完全に回避することは困難です。TiDB v7.2.0 では、予想よりも多くのリソースを消費するクエリを管理する機能が提供されています。この機能により、パフォーマンスの問題が発生した場合の影響範囲を迅速に縮小できます。
これらのクエリを管理するには、リソース グループのクエリの最大実行時間を設定できます。クエリの実行時間がこの制限を超えると、クエリは自動的に優先順位が下げられるか、キャンセルされます。また、テキストまたは実行プランによって識別されたクエリをすぐに照合する期間を設定することもできます。これにより、識別フェーズ中に問題のあるクエリが同時に実行され、予想よりも多くのリソースが消費されるのを防ぐことができます。
予想よりも多くのリソースを消費するクエリを自動的に管理することで、予期しないクエリ パフォーマンスの問題に迅速に対応するための効果的な手段が提供されます。この機能により、問題がデータベース全体のパフォーマンスに与える影響を軽減し、データベースの安定性を向上させることができます。
詳細についてはドキュメント参照してください。
履歴実行計画に従ってバインディングを作成する機能を強化する#39199 @ qw4990
TiDB v7.2.0 では、 過去の実行計画に従ってバインディングを作成するの機能が強化されています。この機能により、複雑なステートメントの解析とバインディングのプロセスが改善され、バインディングがより安定し、次の新しいヒントがサポートされます。
詳細についてはドキュメント参照してください。
オプティマイザの動作を細かく制御するためのオプティマイザ修正制御メカニズムを導入する#43169 @ 時間と運命
より合理的な実行プランを生成するために、TiDB オプティマイザーの動作は製品の反復を通じて進化します。ただし、特定のシナリオでは、変更によってパフォーマンスが低下する可能性があります。TiDB v7.2.0 では、オプティマイザーのきめ細かい動作の一部を制御できるオプティマイザー修正コントロールが導入されています。これにより、いくつかの新しい変更をロールバックまたは制御できます。
制御可能な各動作は、修正番号に対応する GitHub の問題によって説明されています。制御可能なすべての動作はオプティマイザー修正コントロールにリストされています。動作制御を実現するには、
tidb_opt_fix_controlシステム変数を設定することで、1 つ以上の動作のターゲット値を設定できます。オプティマイザー修正制御メカニズムは、TiDB オプティマイザーを細かいレベルで制御するのに役立ちます。アップグレード プロセスによって発生するパフォーマンスの問題を修正する新しい手段を提供し、TiDB の安定性を向上させます。
詳細についてはドキュメント参照してください。
軽量統計初期化が一般提供 (GA) #42160 @ 翻訳者に開始
v7.2.0 以降、軽量統計初期化機能が GA になります。軽量統計初期化により、起動時にロードする必要がある統計の数が大幅に削減され、統計のロード速度が向上します。この機能により、複雑なランタイム環境での TiDB の安定性が向上し、TiDB ノードの再起動時にサービス全体に与える影響が軽減されます。
v7.2.0 以降のバージョンの新しく作成されたクラスターの場合、TiDB はデフォルトで TiDB の起動時に軽量統計をロードし、ロードが完了するまで待ってからサービスを提供します。以前のバージョンからアップグレードされたクラスターの場合、この機能を有効にするには、TiDB 構成項目
lite-init-statsおよびforce-init-stats~trueを設定できます。詳細についてはドキュメント参照してください。
構文
v7.2.0 以降では、
CHECK制約を使用して、指定した条件を満たすようにテーブル内の 1 つ以上の列の値を制限できます。3 制約がテーブルに追加されると、TiDB はテーブルにデータを挿入または更新する前に、制約が満たされているCHECKどうかを確認します。制約を満たすデータのみを書き込むことができます。この機能はデフォルトで無効になっています。有効にするには、
tidb_enable_check_constraintシステム変数をONに設定します。詳細についてはドキュメント参照してください。
DB操作
DDL ジョブは一時停止と再開操作をサポートします (実験的) #18015 @ ゴドゥム
TiDB v7.2.0 より前では、DDL ジョブの実行中にビジネス ピークが発生した場合、ビジネスへの影響を軽減するために、DDL ジョブを手動でキャンセルすることしかできませんでした。v7.2.0 では、TiDB に DDL ジョブの一時停止および再開操作が導入されています。これらの操作により、ピーク時に DDL ジョブを一時停止し、ピーク終了後に再開できるため、アプリケーション ワークロードへの影響を回避できます。
たとえば、
ADMIN PAUSE DDL JOBSまたはADMIN RESUME DDL JOBSを使用して複数の DDL ジョブを一時停止および再開できます。ADMIN PAUSE DDL JOBS 1,2; ADMIN RESUME DDL JOBS 1,2;詳細についてはドキュメント参照してください。
データ移行
データのインポート効率を大幅に向上させる新しいSQL文
IMPORT INTOを導入(実験的) #42930 @ D3ハンターIMPORT INTOステートメントは、 TiDB Lightningの物理インポートモード機能を統合します。このステートメントを使用すると、CSV、SQL、PARQUET などの形式のデータを TiDB の空のテーブルにすばやくインポートできます。このインポート方法により、 TiDB Lightningを個別に展開および管理する必要がなくなり、データ インポートの複雑さが軽減され、インポート効率が大幅に向上します。Amazon S3 または GCS に保存されているデータ ファイルの場合、 TiDB 分散実行フレームワーク (DXF)が有効になっていると、
IMPORT INTOデータ インポート ジョブを複数のサブジョブに分割し、それらを複数の TiDB ノードにスケジュールして並列インポートすることもサポートしており、これによりインポートのパフォーマンスがさらに向上します。詳細についてはドキュメント参照してください。
TiDB Lightningは、Latin-1文字セットのソースファイルをTiDB #44434 @ ランス6716にインポートすることをサポートします。
この機能により、 TiDB Lightningを使用して Latin-1 文字セットを含むソース ファイルを TiDB に直接インポートできます。v7.2.0 より前では、このようなファイルをインポートするには追加の前処理または変換が必要でした。v7.2.0 以降では、 TiDB Lightningインポート タスクを構成するときに
character-set = "latin1"指定するだけで済みます。その後、 TiDB Lightning はインポート プロセス中に文字セットの変換を自動的に処理し、データの整合性と正確性を確保します。詳細についてはドキュメント参照してください。
互換性の変更
注記:
このセクションでは、v7.1.0 から現在のバージョン (v7.2.0) にアップグレードするときに知っておく必要のある互換性の変更について説明します。v7.0.0 以前のバージョンから現在のバージョンにアップグレードする場合は、中間バージョンで導入された互換性の変更も確認する必要がある可能性があります。
行動の変化
- 更新イベントを処理する際、イベント内で主キーまたは null 以外の一意のインデックス値が変更されると、TiCDC はイベントを削除イベントと挿入イベントに分割します。詳細については、 ドキュメント参照してください。
システム変数
コンフィグレーションファイルのパラメータ
改善点
ティビ
- インデックススキャン範囲を構築するロジックを最適化し、複雑な条件をインデックススキャン範囲#41572 #44389 @ 翻訳者に変換できるようにします。
- 新しい監視メトリック
Stale Read OPSとStale Read Traffic#43325 @ あなた06を追加 - 古い読み取りの再試行リーダーがロックに遭遇すると、TiDBはロックを解決した後、リーダーで強制的に再試行し、不要なオーバーヘッドを回避します#43659 @ あなた06
- 推定時間を使用して古い読み取りtsを計算し、古い読み取り#44215 @ あなた06のオーバーヘッドを削減します。
- 長時間実行されるトランザクションのログとシステム変数を追加する#41471 @ クレイジーcs520
- 圧縮された MySQL プロトコルを介して TiDB に接続することをサポートします。これにより、低帯域幅ネットワークでのデータ集約型クエリのパフォーマンスが向上し、帯域幅コストが節約されます。これは、
zlibとzstdベースの両方の圧縮をサポートします#22605 @ ドヴェーデン utf8とutf8bm3両方を従来の 3 バイト UTF-8 文字セット エンコーディングとして認識します。これにより、従来の UTF-8 エンコーディングを持つテーブルを MySQL 8.0 から TiDB #26226 @ ドヴェーデンに移行しやすくなります。UPDATEのステートメント#44751 @ Cbcウェストウルフでの割り当てに:=使用することをサポートします
ティクヴ
PD
ツール
バックアップと復元 (BR)
ティCDC
- オブジェクトstorageサービスへのレプリケーションのシナリオでDDL操作が発生したときにデータファイルが格納されるディレクトリの構造を最適化します#8891 @ チャールズ・チュン96
- Kafka #8865 @ ハイラスティンへのレプリケーションのシナリオで OAUTHBEARER 認証をサポートする
- Kafka #9143 @ 3エースショーハンドへのレプリケーションのシナリオで
DELETE操作のハンドルキーのみを出力するオプションを追加します
TiDB データ移行 (DM)
TiDB Lightning
バグ修正
ティビ
- CTE を含むクエリによって TiDB がハングする問題を修正#43749 #36896 @ グオシャオゲ
min, maxクエリ結果が正しくない問題を修正#43805 @ うわーSHOW PROCESSLISTステートメントがサブクエリ時間が長いステートメントのトランザクションの TxnStart を表示できない問題を修正#40851 @ クレイジーcs520- コプロセッサータスク#43365 @ あなた06に
TxnScopeがないため、古い読み取りグローバル最適化が有効にならない問題を修正しました。 - フォロワー読み取りが再試行前にフラッシュバック エラーを処理せず、クエリ エラー#43673 @ あなた06が発生する問題を修正しました。
ON UPDATE文が主キー#44565 @ ジグアンを正しく更新しない場合にデータとインデックスが不整合になる問題を修正- MySQL 8.0.28以降のバージョン#43987 @ ヤンケオと一致するように、
UNIX_TIMESTAMP()関数の上限を3001-01-19 03:14:07.999999 UTCに変更します。 - 取り込みモード#44137 @ タンジェンタでインデックスの追加が失敗する問題を修正
- ロールバック状態で DDL タスクをキャンセルすると、関連するメタデータ#44143 @ 翻訳:にエラーが発生する問題を修正しました
- カーソルフェッチで
memTracker使用するとメモリリークが発生する問題を修正#44254 @ ヤンケオ - データベースを削除すると GC の進行が遅くなる問題を修正#33069 @ 天菜まお
- インデックス結合#43686 @ アイリンキッド @ ミョンスのプローブフェーズでパーティションテーブル内の対応する行が見つからない場合に TiDB がエラーを返す問題を修正しました。
SUBPARTITION使用してパーティション テーブル#41198 #41200 @ ミョンスを作成するときに警告が表示されない問題を修正しました- クエリが
MAX_EXECUTION_TIME超えたために強制終了された場合に返されるエラーメッセージが MySQL #43031 @ ドヴェーデンのものと一致しない問題を修正しました。 LEADINGヒントがブロック エイリアス#44645 @ qw4990のクエリをサポートしない問題を修正しましたLAST_INSERT_ID()関数の戻り値の型を VARCHAR から LONGLONG に変更して、MySQL #44574 @ 定義2014の戻り値と一致するようにします。- 非相関サブクエリを含むステートメントで共通テーブル式 (CTE) を使用すると、誤った結果が返される可能性がある問題を修正しました#44051 @ ウィノロス
- 結合したテーブルの再配置により外部結合結果が不正確になる可能性がある問題を修正#44314 @ アイリンキッド
PREPARE stmt FROM "ANALYZE TABLE xxx"tidb_mem_quota_query#44320 @ クリサンによって殺される可能性がある問題を修正
ティクヴ
PD
TiFlash
ツール
バックアップと復元 (BR)
ティCDC
- 解決済みのTSが一部のケースで正しく進まない問題を修正#8963 @ チャールズ・チュン96
- Avro または CSV プロトコルが使用されている場合に
UPDATE操作で古い値を出力できない問題を修正#9086 @ 3エースショーハンド - Kafka #8959 @ ハイラスティンにデータを複製するときに、ダウンストリーム メタデータを頻繁に読み取ることによって発生するダウンストリームの過度の負荷の問題を修正しました。
- TiDB または MySQL #9180 @ アズドンメンにデータを複製するときに、下流の双方向レプリケーション関連の変数を頻繁に設定することによって発生する下流ログが多すぎる問題を修正しました。
- PDノードがクラッシュするとTiCDCノードが#8868 @ アズドンメンで再起動する問題を修正
- TiCDC が下流の Kafka-on-Pulsar #8892 @ ハイラスティンで変更フィードを作成できない問題を修正しました
TiDB Lightning
寄稿者
TiDB コミュニティの以下の貢献者に感謝いたします。