TiDB 7.2.0 リリースノート

発売日：2023年6月29日

TiDB バージョン: 7.2.0

クイックアクセス: クイックスタート

7.2.0 では、次の主な機能と改善が導入されています。

機能の詳細

パフォーマンス

• 次の2つのウィンドウ関数 TiFlash ＃7427 @ xzhangxian1008に押し下げることをサポートします

  • FIRST_VALUE
  • LAST_VALUE

• TiFlashはパイプライン実行モデル（実験的） ＃6518 @ SeaRiseをサポートしています

  v7.2.0より前のバージョンでは、 TiFlashエンジンの各タスクは実行中に個別にスレッドリソースを要求する必要がありました。TiFlashはタスク数を制御することでスレッドリソースの使用量を制限し、過剰な使用を防いでいますが、この問題を完全に解消することはできませんでした。この問題に対処するため、v7.2.0以降、 TiFlashはパイプライン実行モデルを導入しました。このモデルは、すべてのスレッドリソースを一元管理し、タスク実行を均一にスケジュールすることで、リソースの過剰な使用を回避しながらスレッドリソースの利用率を最大化します。パイプライン実行モデルを有効または無効にするには、システム変数tidb_enable_tiflash_pipeline_modelを変更します。

  詳細についてはドキュメント参照してください。

• TiFlashはスキーマレプリケーションのレイテンシーを＃7630 @ hongyunyanに短縮します

  テーブルのスキーマが変更されると、 TiFlash はTiKV から最新のスキーマをタイムリーに複製する必要があります。v7.2.0 より前のバージョンでは、 TiFlash がテーブルデータにアクセスし、データベース内のテーブルスキーマの変更を検出すると、 TiFlash はTiFlashレプリカのないテーブルも含め、このデータベース内のすべてのテーブルのスキーマを再度複製する必要がありました。その結果、多数のテーブルを持つデータベースでは、 TiFlashを使用して 1 つのテーブルからデータを読み取るだけの場合でも、 TiFlash がすべてのテーブルのスキーマ複製を完了するまでにかなりのレイテンシーが発生する可能性があります。

  v7.2.0では、 TiFlashはスキーマレプリケーションのメカニズムを最適化し、 TiFlashレプリカを持つテーブルのスキーマレプリケーションのみをサポートします。TiFlashレプリカを持つテーブルでスキーマ変更が検出されると、 TiFlashはそのテーブルのスキーマのみをレプリケーションします。これにより、 TiFlashのスキーマレプリケーションのレイテンシーが短縮され、DDL操作がTiFlashデータレプリケーションに与える影響が最小限に抑えられます。この最適化は自動的に適用され、手動での設定は不要です。

• 統計収集のパフォーマンスを向上＃44725 @ xuyifangreeneyes

  TiDB v7.2.0では、統計収集戦略が最適化され、重複情報やオプティマイザにとって価値の低い情報をスキップするようになりました。統計収集の全体的な速度は30%向上しました。この改善により、TiDBはデータベースの統計をよりタイムリーに更新できるようになり、生成される実行プランの精度が向上し、データベース全体のパフォーマンスが向上します。

  デフォルトでは、統計収集はJSON 、 BLOB 、 MEDIUMBLOB 、 LONGBLOB型の列をスキップします。このデフォルトの動作は、システム変数tidb_analyze_skip_column_typesを設定することで変更できます。TiDB は、 JSON 、 BLOB 、 TEXT型とそのサブタイプのスキップをサポートしています。

  詳細についてはドキュメント参照してください。

• データとインデックスの一貫性チェックのパフォーマンスを向上＃43693 @ wjhuang2016

  ADMIN CHECK [TABLE|INDEX]文は、テーブル内のデータと対応するインデックス間の整合性をチェックするために使用されます。v7.2.0 では、TiDB はデータ整合性チェックの方法を最適化し、 ADMIN CHECK [TABLE|INDEX]の実行効率を大幅に向上させました。大量のデータを扱うシナリオでは、この最適化によりパフォーマンスが数百倍向上する可能性があります。

  最適化はデフォルトで有効（デフォルトはtidb_enable_fast_table_checkまたはON ）になっており、大規模なテーブルでのデータ整合性チェックにかかる時間を大幅に短縮し、運用効率を高めます。

  詳細についてはドキュメント参照してください。

信頼性

• 予想よりも多くのリソースを消費するクエリを自動的に管理する（実験的） ＃43691 @ Connor1996 @ CabinfeverB @ glorv @ HuSharp @ nolouch

  データベースの安定性における最も一般的な課題は、突発的なSQLパフォーマンスの問題によって引き起こされる、データベース全体のパフォーマンス低下です。SQLパフォーマンスの問題には、十分にテストされていない新しいSQL文、データ量の急激な変化、実行プランの急激な変更など、多くの原因があります。これらの問題を根本的に完全に回避することは困難です。TiDB v7.2.0は、予想以上にリソースを消費するクエリを管理する機能を提供します。この機能により、パフォーマンス問題が発生した場合の影響範囲を迅速に縮小できます。

  これらのクエリを管理するために、リソースグループに対してクエリの最大実行時間を設定できます。クエリの実行時間がこの制限を超えると、クエリは自動的に優先順位が下げられるかキャンセルされます。また、テキストまたは実行プランに基づいて特定されたクエリを直ちに照合する期間を設定することもできます。これにより、特定フェーズにおいて問題のあるクエリが同時に実行され、予想以上に多くのリソースを消費するのを防ぐことができます。

  予想以上にリソースを消費するクエリを自動的に管理することで、予期せぬクエリパフォーマンスの問題に迅速に対応するための効果的な手段を提供します。この機能により、問題がデータベース全体のパフォーマンスに与える影響を軽減し、データベースの安定性を向上させることができます。

  詳細についてはドキュメント参照してください。

• 履歴実行プラン＃39199 @ qw4990に従ってバインディングを作成する機能を強化

  TiDB v7.2.0では、 履歴実行計画に従ってバインディングを作成するの機能が強化されました。この機能により、複雑なステートメントの解析とバインディングのプロセスが改善され、バインディングがより安定し、以下の新しいヒントがサポートされます。

  • AGG_TO_COP()
  • LIMIT_TO_COP()
  • ORDER_INDEX
  • NO_ORDER_INDEX()

  詳細についてはドキュメント参照してください。

• オプティマイザの動作をきめ細かく制御するためのオプティマイザ修正制御メカニズムを導入する＃43169 @ time-and-fate

  より合理的な実行計画を生成するために、TiDBオプティマイザの動作は製品のイテレーションを通じて進化していきます。しかし、特定のシナリオでは、これらの変更がパフォーマンスの低下につながる可能性があります。TiDB v7.2.0では、オプティマイザのきめ細かな動作を制御できるオプティマイザ修正制御が導入されました。これにより、新しい変更の一部をロールバックしたり、制御したりすることが可能になります。

  制御可能な各動作は、修正番号に対応するGitHub Issueで説明されています。制御可能なすべての動作はオプティマイザー修正コントロールにリストされています。動作を制御するには、 tidb_opt_fix_controlシステム変数を設定することで、1つまたは複数の動作の目標値を設定できます。

  オプティマイザ修正制御メカニズムは、TiDBオプティマイザをきめ細かなレベルで制御するのに役立ちます。アップグレードプロセスによって発生するパフォーマンスの問題を修正する新しい手段を提供し、TiDBの安定性を向上させます。

  詳細についてはドキュメント参照してください。

• 軽量統計初期化が一般提供 (GA) ＃42160 @ xuyifangreeneyesに開始

  v7.2.0以降、軽量統計初期化機能がGAとなります。軽量統計初期化により、起動時にロードする必要がある統計情報の数が大幅に削減され、統計情報のロード速度が向上します。この機能により、複雑なランタイム環境におけるTiDBの安定性が向上し、TiDBノードの再起動時にサービス全体への影響が軽減されます。

  v7.2.0以降のバージョンで新規作成されたクラスターでは、TiDBは起動時にデフォルトで軽量統計を読み込み、読み込みが完了するまで待機してからサービスを提供します。以前のバージョンからアップグレードしたクラスターでは、TiDB設定項目lite-init-statsおよびforce-init-stats ～ trueを設定することでこの機能を有効化できます。

  詳細についてはドキュメント参照してください。

SQL

• CHECK制約＃41711 @ fzzf678をサポートする

  v7.2.0以降では、 CHECK制約を使用して、テーブル内の1つ以上の列の値をCHECK指定した条件を満たすように制限できます。3制約がテーブルに追加されると、TiDBはテーブルにデータを挿入または更新する前に、制約が満たされているかどうかを確認します。制約を満たすデータのみが書き込まれます。

  この機能はデフォルトで無効になっています。システム変数tidb_enable_check_constraint ONに設定すると有効になります。

  詳細についてはドキュメント参照してください。

DB操作

• DDL ジョブは一時停止と再開操作をサポートします (実験的) ＃18015 @ godouxm

  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 @ D3Hunter

  IMPORT INTOステートメントは、 TiDB Lightningの物理インポートモード機能を統合します。このステートメントを使用すると、CSV、SQL、PARQUET などの形式のデータを TiDB の空のテーブルに迅速にインポートできます。このインポート方法により、 TiDB Lightningを個別に導入・管理する必要がなくなり、データインポートの複雑さが軽減され、インポート効率が大幅に向上します。

  Amazon S3 または GCS に保存されているデータファイルの場合、 TiDB 分散実行フレームワーク (DXF)が有効になっていると、 IMPORT INTOデータインポートジョブを複数のサブジョブに分割し、それらを複数の TiDB ノードにスケジュールして並列インポートすることもサポートしており、これによりインポートのパフォーマンスがさらに向上します。

  詳細についてはドキュメント参照してください。

• TiDB Lightningは、 Latin-1文字セットのソースファイルをTiDB ＃44434 @ lance6716にインポートすることをサポートします。

  この機能により、 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はイベントを削除イベントと挿入イベントに分割します。詳細については、 ドキュメント参照してください。
• デフォルト値tidb_remove_orderby_in_subqueryをOFFからONに変更します。これは、オプティマイザーがサブクエリからORDER BY個の句を削除し、不要なソート操作を回避することを意味します。この変更により、クエリ結果の行順序が異なる場合があります。ISO/IEC SQL 標準では、クエリ結果がサブクエリで指定されたORDER BYソート順序に従う必要はありません。最終結果で特定の順序を確保する必要がある場合は、外部クエリにORDER BY句を追加します。アプリケーションがサブクエリのソートに依存している場合は、この変数をOFFに設定できます。以前のバージョンからアップグレードされたクラスターは、デフォルトで以前の動作を保持します。

システム変数

コンフィグレーションファイルのパラメータ

改善点

• ティドブ

  • インデックススキャン範囲を構築するロジックを最適化し、複雑な条件をインデックススキャン範囲＃41572 ＃44389 @ xuyifangreeneyesに変換できるようにします。
  • 新しい監視メトリックStale Read OPSとStale Read Traffic ＃43325 @ you06を追加
  • 古い読み取りの再試行リーダーがロックに遭遇すると、TiDBはロックを解決した後、リーダーで強制的に再試行し、不要なオーバーヘッドを回避します＃43659 @ you06
  • 推定時間を使用して古い読み取りtsを計算し、古い読み取り＃44215 @ you06のオーバーヘッドを削減します。
  • 長時間実行されるトランザクションのログとシステム変数を追加する＃41471 @ crazycs520
  • 圧縮MySQLプロトコルを介したTiDBへの接続をサポート。これにより、低帯域幅ネットワークにおけるデータ集約型クエリのパフォーマンスが向上し、帯域幅コストを削減できます。1 zlibとzstdベースの両方の圧縮をサポートしています＃22605 @ dveeden
  • utf8とutf8bm3両方を従来の 3 バイト UTF-8 文字セットエンコーディングとして認識します。これにより、MySQL 8.0 から TiDB ＃26226 @ dveedenへの従来の UTF-8 エンコーディングを持つテーブルの移行が容易になります。
  • UPDATEステートメント＃44751 @ CbcWestwolfでの割り当てに:=使用することをサポート

• TiKV

  • pd.retry-interval ＃14964 @ rleungxを使用した接続要求の失敗などのシナリオで PD 接続の再試行間隔の構成をサポートします。
  • グローバルリソース使用率＃14604 @ Connor1996を組み込むことで、リソース制御スケジューリングアルゴリズムを最適化します。
  • check_leaderリクエストに gzip 圧縮を使用してトラフィックを削減＃14553 @ you06
  • check_leaderリクエスト＃14658 @ you06に関連するメトリックを追加します
  • TiKV が書き込みコマンド＃12362 @ cfzjywxkを処理する際の詳細な時間情報を提供します

• PD

  • 他のリクエストの影響を防ぐために、PDリーダー選出には別のgRPC接続を使用する＃6403 @ rleungx
  • マルチリージョンシナリオでのホットスポットの問題を軽減するために、バケット分割をデフォルトで有効にします＃6433 @ bufferflies

• ツール

  • バックアップと復元 (BR)

    • 共有アクセス署名 (SAS) ＃44199 @ Leavrthによる Azure Blob Storage へのアクセスをサポート

  • TiCDC

    • オブジェクトstorageサービスへのレプリケーションのシナリオでDDL操作が発生したときにデータファイルが格納されるディレクトリの構造を最適化します＃8891 @ CharlesCheung96
    • Kafka ＃8865 @ Rustin170506へのレプリケーションのシナリオでOAUTHBEARER認証をサポートする
    • Kafka ＃9143 @ 3AceShowHandへのレプリケーションのシナリオで、 DELETE操作のハンドルキーのみを出力するオプションを追加します。

  • TiDB データ移行 (DM)

    • MySQL 8.0 で圧縮されたバイナリログを増分レプリケーションのデータソースとして読み取る機能をサポート＃6381 @ dveeden

  • TiDB Lightning

    • インポート中の再試行メカニズムを最適化して、リーダーの切り替え＃44263 @ lance6716によるエラーを回避します。
    • インポート後にSQLでチェックサムを検証し、検証＃41941 @ GMHDBJDの安定性を向上
    • ワイドテーブル＃43853 @ D3Hunterをインポートする際のTiDB Lightning OOM の問題を最適化します

バグ修正

• ティドブ

  • CTE を含むクエリによって TiDB がハングする問題を修正＃43749 ＃36896 @ guo-shaoge
  • min, maxクエリ結果が正しくない問題を修正＃43805 @ wshwsh12
  • SHOW PROCESSLIST文でサブクエリ時間が長い文のトランザクションの TxnStart を表示できない問題を修正＃40851 @ crazycs520
  • コプロセッサータスク＃43365 @ you06にTxnScopeが不足しているため、古い読み取りグローバル最適化が有効にならない問題を修正しました。
  • フォロワー読み取りが再試行前にフラッシュバックエラーを処理せず、クエリエラー＃43673 @ you06が発生する問題を修正しました
  • ON UPDATE文が主キー＃44565 @ zyguanを正しく更新しない場合にデータとインデックスが不整合になる問題を修正しました
  • 権限テーブル＃41048 @ bb7133の一部の列における大文字と小文字の区別の問題を修正しました
  • MySQL 8.0.28以降のバージョン＃43987 @ YangKeaoと一致するように、 UNIX_TIMESTAMP()関数の上限を3001-01-19 03:14:07.999999 UTCに変更します。
  • 取り込みモード＃44137 @ tangentaでインデックスの追加が失敗する問題を修正
  • ロールバック状態でDDLタスクをキャンセルすると、関連するメタデータ＃44143 @ wjhuang2016にエラーが発生する問題を修正しました
  • カーソルフェッチでmemTracker使用するとメモリリークが発生する問題を修正＃44254 @ YangKeao
  • データベースを削除するとGCの進行が遅くなる問題を修正＃33069 @ tiancaiamao
  • インデックス結合＃43686 @ AilinKid @ mjonssのプローブフェーズでパーティションテーブル内の対応する行が見つからない場合に TiDB がエラーを返す問題を修正しました。
  • SUBPARTITIONを使用してパーティションテーブル＃41198 ＃41200 @ mjonssを作成するときに警告が表示されない問題を修正しました
  • クエリがMAX_EXECUTION_TIME超えたために強制終了された場合に返されるエラーメッセージが MySQL ＃43031 @ dveedenのものと一致しない問題を修正しました。
  • LEADINGヒントがブロックエイリアス＃44645 @ qw4990のクエリをサポートしない問題を修正しました
  • LAST_INSERT_ID()関数の戻り値の型を VARCHAR から LONGLONG に変更して、MySQL ＃44574 @ Defined2014の戻り値と一致するようにします。
  • 非相関サブクエリ＃44051 @ winorosを含むステートメントで共通テーブル式 (CTE) を使用すると誤った結果が返される可能性がある問題を修正しました
  • 結合したテーブルの再配置により外部結合結果が不正確になる可能性がある問題を修正＃44314 @ AilinKid
  • PREPARE stmt FROM "ANALYZE TABLE xxx" tidb_mem_quota_query ＃44320 @ chrysanで殺される可能性がある問題を修正

• TiKV

  • TiKV が古い悲観的ロックの競合＃13298 @ cfzjywxkを処理するときにトランザクションが誤った値を返す問題を修正しました
  • メモリ内悲観的ロックがフラッシュバックの失敗とデータの不整合を引き起こす可能性がある問題を修正＃13303 @ JmPotato
  • TiKV が古いリクエスト＃13298 @ cfzjywxkを処理するときにフェアロックが正しくない可能性がある問題を修正しました
  • autocommitとpoint get replica read ＃14715 @ cfzjywxkの線形化可能性を壊す可能性がある問題を修正

• PD

  • 一部のコーナーケースで冗長レプリカが自動的に修復されない問題を修正＃6573 @ nolouch

• TiFlash

  • 結合ビルド側のデータが非常に大きく、小さな文字列型の列が多数含まれている場合、クエリが必要以上にメモリを消費する可能性がある問題を修正しました＃7416 @ yibin87

• ツール

  • バックアップと復元 (BR)

    • checksum mismatch場合によっては誤って報告される問題を修正＃44472 @ Leavrth
    • resolved lock timeout場合によっては誤って報告される問題を修正＃43236 @ YuJuncen
    • 統計情報＃44490 @ tangentaを復元するときに TiDB がpanic可能性がある問題を修正しました

  • TiCDC

    • 解決済みのTSが＃8963 @ CharlesCheung96で正しく進まない場合がある問題を修正
    • AvroまたはCSVプロトコルが使用されている場合、 UPDATE操作で古い値を出力できない問題を修正しました＃9086 @ 3AceShowHand
    • Kafka ＃8959 @ Rustin170506にデータを複製するときに下流のメタデータを頻繁に読み取ることによって発生する下流の過度の負荷の問題を修正しました
    • TiDB または MySQL ＃9180 @ asddongmenにデータを複製するときに、下流の双方向レプリケーション関連の変数を頻繁に設定することによって発生する下流ログが多すぎる問題を修正しました。
    • PDノードがクラッシュするとTiCDCノードが＃8868 @ asddongmenで再起動する問題を修正
    • TiCDC が下流の Kafka-on-Pulsar ＃8892 @ Rustin170506で changefeed を作成できない問題を修正しました

  • TiDB Lightning

    • experimental.allow-expression-indexが有効で、デフォルト値が UUID ＃44497 @ lichunzhuの場合の TiDB Lightningpanic問題を修正しました
    • データファイル＃43195 @ lance6716を分割中にタスクが終了したときに発生するTiDB Lightningpanicの問題を修正しました

寄稿者

TiDB コミュニティの以下の貢献者に感謝いたします。

• asjdf
• ブラックティア23
• キャヴァンスー
• ダラエス
• デモマニト
• ディサム
• ハッピー-v587
• ジフハスト
• L-メープル
• ニュリク
• シージC
• タンジンユ97