TiDB 6.6.0 リリースノート

発売日：2023年2月20日

TiDB バージョン: 6.6.0- DMR

注記：

TiDB 6.6.0-DMR ドキュメントはアーカイブ済みです。 PingCAP は、TiDB データベースの最新のLTSバージョンを使用することを推奨します。

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

バージョン6.6.0-DMRの主な新機能と改善点は以下のとおりです。

機能の詳細

拡張性

• サポートパーティションRaft KVstorageエンジン (実験的) #11515 #12842 @busyjay@tonyxuqqiタボキーバッファロー5kb @SpadeA-Tang@nolouch

  TiDB v6.6.0 より前は、TiKV の Raft ベースのstorageエンジンは、単一の RocksDB インスタンスを使用して、TiKV インスタンスのすべての「リージョン」のデータを保存していました。より大規模なクラスタをより安定してサポートするために、TiDB v6.6.0 以降では、複数の RocksDB インスタンスを使用して TiKVリージョンデータを保存する新しい TiKVstorageエンジンが導入され、各リージョンのデータは個別の RocksDB インスタンスに独立して保存されます。この新しいエンジンは、RocksDB インスタンス内のファイルの数とレベルをより適切に制御し、リージョン間のデータ操作の物理的な分離を実現し、より多くのデータを安定して管理できます。これは、TiKV がパーティショニングによって複数の RocksDB インスタンスを管理していると考えることができます。そのため、この機能は Partitioned-Raft-KV と呼ばれています。この機能の主な利点は、書き込みパフォーマンスの向上、スケーリングの高速化、および同じハードウェアでサポートできるデータ量の拡大です。また、より大規模なクラスタにも対応できます。

  現在、この機能は実験的であり、本番環境での使用は推奨されません。

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

• DDL操作のための分散並列実行フレームワークのサポート（実験的） #37125 @zimulala

  以前のバージョンでは、TiDB クラスタ全体で 1 つの TiDB インスタンスのみが DDL オーナーとしてスキーマ変更タスクを処理できました。大規模テーブルの DDL 操作の DDL 並行性をさらに向上させるため、TiDB v6.6.0 では、DDL 用の分散並列実行フレームワークが導入されました。これにより、クラスタ内のすべての TiDB インスタンスが同じタスクのStateWriteReorganizationフェーズを同時に実行して、DDL の実行を高速化できます。この機能はシステム変数tidb_ddl_distribute_reorgによって制御され、現在はAdd Index操作のみでサポートされています。

パフォーマンス

• 悲観的ロック キューの安定したウェイクアップ モデルをサポート #13298 @MyonKeminta

  アプリケーションで頻繁に単一ポイントの悲観的ロック競合が発生する場合、既存のウェイクアップメカニズムではトランザクションがロックを取得する時間を保証できず、ロングテールレイテンシーが大きくなり、ロック取得タイムアウトが発生することもあります。v6.6.0 以降では、システム変数tidb_pessimistic_txn_aggressive_lockingの値をONに設定することで、悲観的ロック用の安定したウェイクアップ モデルを有効にできます。このウェイクアップ モデルでは、無効なウェイクアップによるリソースの浪費を回避するために、キューのウェイクアップ シーケンスを厳密に制御できます。深刻なロック競合が発生するシナリオでは、この安定したウェイクアップ モデルにより、ロングテールレイテンシーと P99 応答時間を短縮できます。

  テスト結果によると、これによりテールレイテンシーが40～60%削減されることが示されています。

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

• バッチ集計データ要求 #39361 @cfzjywxk @you06

  TiDB が TiKV にデータ要求を送信すると、TiDB はデータが存在するリージョンに応じて要求を複数のサブタスクにコンパイルし、各サブタスクは単一のリージョンの要求のみを処理します。アクセスするデータが高度に分散している場合、データのサイズが大きくなくても、多くのサブタスクが生成され、結果として多くの RPC 要求が発生し、余分な時間を消費します。v6.6.0 以降、TiDB は同じ TiKV インスタンスに送信されるデータ要求を部分的にマージする機能をサポートしており、サブタスクの数と RPC 要求のオーバーヘッドを削減します。データの分散度が高く、gRPC スレッド プールのリソースが不足している場合、要求をバッチ処理することでパフォーマンスを 50% 以上向上させることができます。

  この機能はデフォルトで有効になっています。システム変数tidb_store_batch_sizeを使用して、リクエストのバッチサイズを設定できます。

• LIMIT条項の制限を解除 #40219 @fzzf678

  バージョン 6.6.0 以降、TiDB プラン キャッシュはLIMITやLIMIT ?などの変数をLIMIT 10, ?パラメータとして指定した実行プランのキャッシュをサポートします。この機能により、より多くの SQL ステートメントがプラン キャッシュの恩恵を受けられるようになり、実行効率が向上します。現在、セキュリティ上の理由から、TiDB は?が 10000 を超えない実行プランのみをキャッシュできます。

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

• TiFlashは圧縮によるデータ交換をサポートします #6620 @solotzg

  TiFlashエンジンは、複数のノードと連携して計算を行うために、異なるノード間でデータを交換する必要があります。交換するデータのサイズが非常に大きい場合、データ交換のパフォーマンスが全体の計算効率に影響を与える可能性があります。v6.6.0では、 TiFlashエンジンに圧縮メカニズムが導入され、必要に応じて交換するデータを圧縮してから交換を実行することで、データ交換の効率が向上しました。

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

• TiFlash は、 ステイル読み取り機能 #4483 @hehechenをサポートしています

  ステイル読み取り機能はv5.1.1以降、一般提供（GA）されており、特定のタイムスタンプまたは指定された時間範囲内の履歴データを読み取ることができます。Stale Readは、ローカルのTiKVレプリカからデータを直接読み取ることで、読み取りレイテンシーを削減し、クエリのパフォーマンスを向上させることができます。v6.6.0より前のTiFlashでは、 ステイル読み取りはサポートされていません。テーブルにTiFlashレプリカが存在する場合でも、 ステイル読み取りはTiKVレプリカのみを読み取ることができます。

  バージョン6.6.0以降、 TiFlashはステイル読み取り機能をサポートしています。AS AS OF TIMESTAMP構文またはtidb_read_stalenessシステム変数を使用してテーブルの履歴データをクエリする場合、テーブルにTiFlashレプリカが存在すると、オプティマイザは対応するデータをTiFlashレプリカから読み込むことを選択できるようになり、クエリのパフォーマンスがさらに向上します。

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

• TiFlashにregexp_replace文字列関数をプッシュダウンする機能のサポート #6115 @xzhangxian1008

信頼性

• リソース グループに基づくリソース制御のサポート (実験的) #38825 @nolouch@BornChangerグロルヴ@tiancaiamao@Connor1996 @JmPotato @hnes @CabinfeverB @HuSharp

  TiDBクラスタのリソースグループを作成し、異なるデータベースユーザーを対応するリソースグループにバインドし、実際のニーズに応じて各リソースグループのクォータを設定できるようになりました。クラスタのリソースが制限されている場合、同じリソースグループ内のセッションで使用されるすべてのリソースはクォータに制限されます。このようにして、リソースグループが過剰に消費された場合でも、他のリソースグループのセッションには影響しません。TiDBは、Grafanaダッシュボード上でリソースの実際の使用状況を表示する組み込みビューを提供し、リソースをより合理的に割り当てるのに役立ちます。

  リソース制御機能の導入は、TiDBにとって画期的な出来事です。この機能により、分散データベースクラスタを複数の論理ユニットに分割できます。たとえ個々のユニットがリソースを過剰に使用したとしても、他のユニットが必要とするリソースを圧迫することはありません。

  この機能を使うと、次のことができます。

  • 異なるシステムに存在する複数の中小規模アプリケーションを単一のTiDBクラスタに統合します。アプリケーションのワークロードが増加しても、他のアプリケーションの正常な動作には影響しません。システムワークロードが低い場合、ビジー状態のアプリケーションは、設定された読み取り/書き込みクォータを超えても必要なシステムリソースを割り当てられるため、リソースを最大限に活用できます。
  • すべてのテスト環境を単一のTiDBクラスタに統合するか、より多くのリソースを消費するバッチタスクを単一のリソースグループにまとめるかを選択できます。これにより、ハードウェア利用率を向上させ、運用コストを削減しながら、重要なアプリケーションが常に必要なリソースを確保できるようになります。

  さらに、リソース制御機能を合理的に活用することで、クラスタ数を削減し、運用・保守の難易度を下げ、管理コストを削減することができます。

  v6.6 では、リソース制御を有効にするには、TiDB のグローバル変数tidb_enable_resource_controlと TiKV 設定項目resource-control.enabled両方を有効にする必要があります。現在サポートされているクォータ方式は「 リクエストユニット（RU） 」に基づいています。RU は、CPU や IO などのシステム リソースに対する TiDB の統一抽象化ユニットです。

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

• 過去の実行計画を拘束することは、GA #39199 @fzzf678です。

  バージョン6.5.0では、TiDBはCREATE [GLOBAL | SESSION] BINDING文のバインディングターゲットを拡張し、過去の実行プランに基づいてバインディングを作成する機能をサポートしています。バージョン6.6.0では、この機能は一般提供（GA）となります。実行プランの選択は、現在のTiDBノードに限定されません。任意のTiDBノードによって生成された過去の実行プランをSQLバインディングのターゲットとして選択できるため、機能の使いやすさがさらに向上します。

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

• いくつかのオプティマイザー ヒントを追加 #39964 @Reminiscent

  TiDB は v6.6.0 でLIMIT操作の実行プランの選択を制御するためのオプティマイザヒントをいくつか追加しました。

  • ORDER_INDEX() : オプティマイザに指定されたインデックスを使用するように指示し、データの読み取り時にインデックスの順序を維持し、 Limit + IndexScan(keep order: true)に似たプランを生成します。
  • NO_ORDER_INDEX() : オプティマイザに指定されたインデックスを使用するように指示し、データの読み取り時にインデックスの順序を保持せず、 TopN + IndexScan(keep order: false)に似たプランを生成します。

  オプティマイザヒントを継続的に導入することで、ユーザーはより多くの介入方法を利用できるようになり、SQLのパフォーマンス問題の解決に役立ち、全体的なパフォーマンスの安定性が向上します。

• DDL操作のリソース使用量を動的に管理するサポート（実験的） #38025 @hawkingrei

  TiDB v6.6.0 では、DDL 操作のリソース管理が導入されており、これらの操作の CPU 使用率を自動的に制御することで、オンライン アプリケーションに対する DDL 変更の影響を軽減します。この機能はDDL分散並列実行フレームワークが有効になった後にのみ有効です。

可用性

• SQLにおける配置ルール #38605 @nolouchのSURVIVAL_PREFERENCEの構成のサポート

  SURVIVAL_PREFERENCES 、データの災害時における耐障害性を高めるためのデータ耐障害性設定を提供します。 SURVIVAL_PREFERENCEを指定することで、以下の項目を制御できます。

  • クラウドリージョンをまたいでデプロイされたTiDBクラスタの場合、あるクラウドリージョンで障害が発生しても、指定されたデータベースまたはテーブルは別のクラウドリージョンで存続できます。
  • 単一のクラウドリージョンにデプロイされたTiDBクラスタの場合、可用性ゾーンに障害が発生した場合でも、指定されたデータベースまたはテーブルは別の可用性ゾーンで存続できます。

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

• FLASHBACK CLUSTER TO TIMESTAMPステートメントによる DDL 操作のロールバックのサポート #14045 @Defined2014 @JmPotato

  FLASHBACK CLUSTER TO TIMESTAMPステートメントは、ガベージ コレクション (GC) の有効期間内の指定された時点にクラスタ全体を復元することをサポートします。TiDB v6.6.0 では、この機能に DDL 操作のロールバック機能が追加されました。これにより、クラスタ上で発生した DML または DDL 操作の誤りを迅速に取り消したり、クラスタを数分以内にロールバックしたり、タイムライン上でクラスタを複数回ロールバックして特定のデータ変更が発生したタイミングを特定したりすることができます。

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

SQL

• MySQL互換の外部キー制約をサポート（実験的） #18209 @crazycs520

  TiDB v6.6.0では、MySQLと互換性のある外部キー制約機能が導入されました。この機能は、テーブル内またはテーブル間の参照、制約の検証、およびカスケード操作をサポートします。この機能は、アプリケーションのTiDBへの移行、データの一貫性の維持、データ品質の向上、およびデータモデリングの容易化に役立ちます。

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

• MySQL互換の複数値インデックスのサポート（実験的） #39592 @xiongjiwei@qw4990

  TiDB は v6.6.0 で MySQL 互換のマルチ値インデックスを導入しました。JSON 列の配列の値をフィルタリングすることは一般的な操作ですが、通常のインデックスではこの操作を高速化することはできません。配列にマルチ値インデックスを作成することで、フィルタリングのパフォーマンスを大幅に向上させることができます。JSON 列の配列にマルチ値インデックスがある場合、そのマルチ値インデックスを使用してMEMBER OF() 、 JSON_CONTAINS() 、 JSON_OVERLAPS()関数で取得条件をフィルタリングすることで、I/O 消費を大幅に削減し、操作速度を向上させることができます。

  複数値インデックスの導入により、TiDBのJSONデータ型に対するサポートがさらに強化され、MySQL 8.0との互換性も向上します。

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

データベース操作

• リソースを大量に消費するタスク向けに読み取り専用storageノードを構成する機能をサポート @v01dstar

  本番環境では、バックアップや大規模なデータ読み取りと分析など、読み取り専用操作が定期的に大量のリソースを消費し、クラスタ全体のパフォーマンスに影響を与える場合があります。TiDB v6.6.0 では、リソースを消費する読み取り専用タスク用に読み取り専用storageノードを構成して、オンライン アプリケーションへの影響を軽減できます。現在、TiDB、TiSpark、およびBR は、読み取り専用storageノードからのデータ読み取りをサポートしています。 手順のパフォーマンスの安定性を確保するため、システム変数tidb_replica_read 、TiSpark 構成項目spark.tispark.replica_read 、または br コマンドstorage引数--replica-read-label 、読み取り先を指定して、読み取り専用ストレージ ノードを次のように構成できます。

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

• store-io-pool-sizeの動的な変更をサポート #13964 @LykxSassinator

  TiKV の設定項目raftstore.store-io-pool-size 、 Raft I/O タスクを処理するスレッドの許容数を指定します。この値は、TiKV のパフォーマンスをチューニングする際に調整できます。バージョン 6.6.0 より前のバージョンでは、この設定項目を動的に変更することはできませんでした。バージョン 6.6.0 以降では、サーバーを再起動せずにこの設定を変更できるため、より柔軟なパフォーマンス調整が可能になります。

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

• TiDBクラスタ初期化時に実行されるSQLスクリプトの指定をサポートする #35624 @morgo

  TiDB クラスタを初めて起動する際に、コマンドライン パラメータ--initialize-sql-fileを設定することで、実行する SQL スクリプトを指定できます。この機能は、システム変数の値の変更、ユーザーの作成、権限の付与などの操作を実行する必要がある場合に使用できます。

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

• TiDBデータ移行（DM）は、TiDB Lightningの物理インポートモードと統合され、完全移行のパフォーマンスを最大10倍向上させます（実験的）@lance6716

  バージョン6.6.0では、DMの完全移行機能がTiDB Lightningの物理インポートモードと統合され、DMによる完全データ移行のパフォーマンスが最大10倍向上し、大容量データシナリオにおける移行時間を大幅に短縮できるようになりました。

  バージョン6.6.0より前は、大容量データの場合、高速なフルデータ移行のためにTiDB Lightningで物理インポートタスクを個別に設定し、その後DMを使用して増分データ移行を行う必要があり、複雑な設定が必要でした。バージョン6.6.0以降では、 TiDB Lightningタスクを設定することなく大容量データを移行できます。1つのDMタスクで移行を完了できます。

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

• TiDB Lightning は、ソース ファイルとターゲット テーブル間の列名の不一致の問題に対処するため、新しい構成パラメータ"header-schema-match"を追加しました。@dsdashun

  TiDB Lightning v6.6.0では、新しいプロファイルパラメータ"header-schema-match"が追加されました。デフォルト値はtrueで、これはソースCSVファイルの最初の行が列名として扱われ、ターゲットテーブルの列名と一致することを意味します。CSVテーブルヘッダーのフィールド名がターゲットテーブルの列名と一致しない場合は、この設定をfalseに設定できます。TiDB Lightningはエラーを無視し、ターゲットテーブルの列の順序でデータのインポートを続行します。

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

• TiDB Lightning は、キーと値のペアを TiKV に送信する際の圧縮転送の有効化をサポートします #41163 @sleepymole

  バージョン6.6.0以降、 TiDB Lightningは、ローカルでエンコードおよびソートされたキーと値のペアをTiKVに送信する際に圧縮してネットワーク転送する機能をサポートしており、ネットワーク経由で転送されるデータ量を削減し、ネットワーク帯域幅のオーバーヘッドを低減します。この機能がサポートされる以前のTiDBバージョンでは、 TiDB Lightningは比較的高いネットワーク帯域幅を必要とし、データ量が多い場合には高額なトラフィック料金が発生していました。

  この機能はデフォルトでは無効になっています。有効にするには、 TiDB Lightningの構成項目compress-kv-pairsを"gzip"または"gz"に設定してください。

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

• TiKV-CDC ツールは現在 GA であり、RawKV #48 @zeminzhou@haojinmingピンギュデータ変更のサブスクライブをサポートしています。

  TiKV-CDCは、TiKVクラスタ用のCDC（変更データキャプチャ）ツールです。TiKVとPDは、TiDBを使用しない場合、RawKVと呼ばれるKVデータベースを構成できます。TiKV-CDCは、RawKVのデータ変更を購読し、それを下流のTiKVクラスタにリアルタイムで複製することをサポートしており、RawKVのクラスタ間レプリケーションを可能にします。

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

• TiCDC は、Kafka チェンジフィード上の単一テーブルのスケールアウトと複数の TiCDC ノードへのチェンジフィードの分散をサポートします (実験的) #7720 @overvenus

  v6.6.0より前は、アップストリームのテーブルが大量の書き込みを受け入れると、そのテーブルのレプリケーション機能をスケールアウトできず、レプリケーションのレイテンシーが増加していました。TiCDC v6.6.0以降では、アップストリームテーブルの変更フィードをKafkaシンク内の複数のTiCDCノードに分散できるため、単一テーブルのレプリケーション機能をスケールアウトできます。

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

• ゴームTiDB 統合テストを追加します。現在、TiDB は GORM によってサポートされるデフォルトのデータベースです。 #6014 @Icemap

  • v1.4.6 では、 GORM MySQL ドライバーTiDB #104のAUTO_RANDOM属性に適応します
  • v1.4.6 では、 GORM MySQL ドライバーTiDB に接続する際に、 UniqueフィールドのUnique属性がAutoMigrate中に変更できない問題を修正しました。 #105
  • GORMドキュメントTiDB をデフォルトのデータベースとして言及しています #638

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

可観測性

• TiDBダッシュボードでSQLバインディングを素早く作成するサポート #781 @YiniXu9506

  TiDB v6.6.0では、ステートメント履歴からSQLバインディングを作成する機能がサポートされており、TiDBダッシュボード上でSQLステートメントを特定の実行プランにすばやくバインドできます。

  この機能は、ユーザーフレンドリーなインターフェースを提供することで、TiDBにおけるプランのバインディングプロセスを簡素化し、操作の複雑さを軽減し、プランバインディングプロセスの効率とユーザーエクスペリエンスを向上させます。

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

• 実行プランのキャッシュに関する警告を追加 @qw4990

  実行プランをキャッシュできない場合、TiDB は診断を容易にするために警告でその理由を示します。例:

  mysql> PREPARE st FROM 'SELECT * FROM t WHERE a<?';
  Query OK, 0 rows affected (0.00 sec)
  
  mysql> SET @a='1';
  Query OK, 0 rows affected (0.00 sec)
  
  mysql> EXECUTE st USING @a;
  Empty set, 1 warning (0.01 sec)
  
  mysql> SHOW WARNINGS;
  +---------+------+----------------------------------------------+
  | Level   | Code | Message                                      |
  +---------+------+----------------------------------------------+
  | Warning | 1105 | skip plan-cache: '1' may be converted to INT |
  +---------+------+----------------------------------------------+
  

  前述の例では、オプティマイザが非INT型をINT型に変換し、パラメータの変更に伴って実行プランが変わる可能性があるため、TiDBはプランをキャッシュしません。

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

• Warningsフィールドをスロークエリログに追加します #39893 @time-and-fate

  TiDB v6.6.0 では、パフォーマンスの問題を診断しやすくするために、スロークエリログにWarningsフィールドが追加されました。このフィールドには、スロークエリの実行中に生成された警告が記録されます。これらの警告は、TiDB ダッシュボードのスロークエリページでも確認できます。

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

• SQL実行プランの生成を自動的にキャプチャする #38779 @Yisaer

  実行計画の問題をトラブルシューティングする過程で、 PLAN REPLAYER現場を保存し、診断の効率を向上させるのに役立ちます。しかし、シナリオによっては、一部の実行計画の生成を自由に再現できないため、診断作業がより困難になります。

  このような問題に対処するため、TiDB v6.6.0 ではPLAN REPLAYERにより自動キャプチャ機能が拡張されました。 PLAN REPLAYER CAPTUREコマンドを使用すると、対象の SQL ステートメントを事前に登録し、同時に対象の実行プランを指定できます。TiDB は、登録された対象に一致する SQL ステートメントまたは実行プランを検出すると、 PLAN REPLAYER情報を自動的に生成してパッケージ化します。実行プランが不安定な場合、この機能により診断効率が向上します。

  この機能を使用するには、 tidb_enable_plan_replayer_captureの値をONに設定してください。

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

• 永続化ステートメントのサポート概要（実験的） #40812 @mornyx

  バージョン6.6.0より前は、ステートメントサマリーデータはメモリに保持されていたため、TiDBサーバーの再起動時に失われていました。バージョン6.6.0以降、TiDBはステートメントサマリーの永続化をサポートするようになり、履歴データを定期的にディスクに書き込むことが可能になりました。これにより、システムテーブルに対するクエリの結果は、メモリではなくディスクから取得されます。TiDBの再起動後も、すべての履歴データは保持されます。

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

Security

• TiFlashはTLS証明書の自動ローテーションをサポートします #5503 @ywqzzy

  バージョン6.6.0では、TiDBはTiFlash TLS証明書の自動ローテーションをサポートしています。コンポーネント間で暗号化されたデータ転送が有効になっているTiDBクラスタでは、 TiFlashのTLS証明書の有効期限が切れて新しい証明書に再発行する必要が生じた場合、TiDBクラスタを再起動することなく、新しいTiFlash TLS証明書を自動的にロードできます。さらに、TiDBクラスタ内のコンポーネント間でTLS証明書をローテーションしても、TiDBクラスタの使用には影響しないため、クラスタの高い可用性が確保されます。

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

• TiDB LightningはAWS IAMロールキーとセッショントークンを介してAmazon S3データへのアクセスをサポートします #40750 okJiang

  バージョン6.6.0より前は、 TiDB LightningはAWS IAMユーザーのアクセスキー（各アクセスキーはアクセスキーIDとシークレットアクセスキーで構成されます）によるS3データへのアクセスのみをサポートしていたため、一時的なセッショントークンを使用してS3データにアクセスすることはできませんでした。バージョン6.6.0以降では、データセキュリティを向上させるため、 TiDB LightningはAWS IAMロールのアクセスキーとセッショントークンによるS3データへのアクセスもサポートするようになりました。

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

テレメトリー

• 2023 年 2 月 20 日以降、TiDB および TiDB ダッシュボード (v6.6.0 を含む) の新しいバージョンではテレメトリ機能デフォルトで無効になります。デフォルトのテレメトリ構成を使用する以前のバージョンからアップグレードする場合、アップグレード後にテレメトリ機能は無効になります。特定のバージョンについては、 TiDBのリリーススケジュールを参照してください。
• バージョン1.11.3以降、新規にデプロイされたTiUPでは、テレメトリ機能はデフォルトで無効になっています。以前のバージョンのTiUPからバージョン1.11.3以降にアップグレードした場合、テレメトリ機能はアップグレード前と同じ状態を維持します。

互換性の変更

注記：

このセクションでは、バージョン6.5.0から最新バージョン（6.6.0）にアップグレードする際に知っておくべき互換性の変更点について説明します。バージョン6.4.0以前のバージョンから最新バージョンにアップグレードする場合は、中間バージョンで導入された互換性の変更点も確認する必要があるかもしれません。

MySQLとの互換性

• MySQL互換の外部キー制約をサポート（実験的） #18209 @crazycs520

  詳細については、このドキュメントおよびドキュメントのSQLセクションを参照してください。

• MySQL互換の複数値インデックスのサポート（実験的） #39592 @xiongjiwei@qw4990

  詳細については、このドキュメントおよびドキュメントのSQLセクションを参照してください。

システム変数

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

その他

• store-io-pool-size動的に変更できるようにサポートします。これにより、TiKVのパフォーマンスチューニングがより柔軟になります。
• LIMIT句の制限を解除することで、実行パフォーマンスを向上させます。
• バージョン6.6.0以降、 BRはバージョン6.1.0より前のクラスターへのデータ復元をサポートしていません。
• バージョン6.6.0以降、TiDBは潜在的な正確性の問題のため、パーティション化されたテーブルの列型の変更をサポートしなくなりました。

改善点

• TiDB

  • TTLバックグラウンドクリーニングタスクのスケジューリングメカニズムを改善し、単一テーブルのクリーニングタスクを複数のサブタスクに分割して、複数のTiDBノードで同時に実行するようにスケジュールできるようにする #40361 @YangKeao
  • デフォルト以外の区切り文字を設定した後に複数ステートメントを実行することで返される結果の列名表示を最適化する #39662 @mjonss
  • 警告メッセージ生成後のステートメントの実行効率を最適化する #39702 @tiancaiamao
  • ADD INDEXの分散データバックフィルをサポート（実験的） #37119 @zimulala
  • CURDATE()を列のデフォルト値として使用することをサポートします #38356 @CbcWestwolf
  • partial order prop push downが LIST 型のパーティション テーブルをサポートするようになりました #40273 @winoros
  • オプティマイザーのヒントと実行プランのバインディング間の競合に関するエラー メッセージを追加 #40910 @Reminiscent
  • プランキャッシュ戦略を最適化し、一部のシナリオでプランキャッシュを使用する際に最適でないプランを回避する#40312 #40218 #40280 #41136 #40686 @qw4990
  • メモリリークとパフォーマンスの低下を避けるために、期限切れの領域キャッシュを定期的にクリアします #40461 @sticnarf
  • MODIFY COLUMNはパーティションテーブルではサポートされていません #39915 @wjhuang2016
  • パーティションテーブルが依存する列の名前変更を無効にする #40150 @mjonss
  • パーティションテーブルが依存する列が削除されたときに報告されるエラーメッセージを改善する #38739 @jiyfhust
  • FLASHBACK CLUSTERがmin-resolved-tsのチェックに失敗した場合に再試行するメカニズムを追加します #39836 @Defined2014

• TiKV

  • partitioned-raft-kv モードにおける一部のパラメータのデフォルト値を最適化します。TiKV 設定項目storage.block-cache.capacityのデフォルト値を 45% から 30% に調整し、 region-split-sizeのデフォルト値を96MiBから10GiBに調整します。raft-kv モードを使用し、 enable-region-bucketがtrueの場合、 region-split-sizeはデフォルトで 1 GiB に調整されます。 #12842 @tonyxuqqi
  • Raftstoreの非同期書き込みにおける優先度スケジューリングのサポート #13730 @Connor1996
  • コア数が1未満のCPUでTiKVを起動するサポート#13586 #13752 #14017 @andreid-db
  • Raftstoreのスロースコアの新しい検出メカニズムを最適化し、 evict-slow-trend-scheduler #14131 @innerrを追加しました
  • RocksDBのブロックキャッシュを共有し、CF #12936に従ってブロックキャッシュを個別に設定することをサポートしなくなりました。@busyjay

• PD

  • OOM問題を軽減するためのグローバルメモリしきい値の管理をサポート（実験的） #5827 hnes
  • GC圧力を軽減するためにGCチューナーを追加（実験的） #5827 hnes
  • 異常なノードを検出してスケジュールするためのevict-slow-trend-schedulerスケジューラを追加します #5808 @innerr
  • キースペースを管理するためにキースペース マネージャーを追加 #5293 @AmoebaProtozoa

• TiFlash

  • TiFlashデータスキャンプロセスにおけるMVCCフィルタリング操作を分離する独立したMVCCビットマップフィルタをサポートし、データスキャンプロセスの将来的な最適化の基盤を提供する #6296 @JinheLin
  • クエリがない場合、 TiFlashのメモリ使用量を最大30%削減します #6589 @hongyunyan

• ツール

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

    • TiKV側でのログバックアップファイルのダウンロードの同時実行性を最適化し、通常のシナリオにおけるPITRリカバリのパフォーマンスを向上させる #14206 @YuJuncen

  • TiCDC

    • TiCDCレプリケーションのパフォーマンスを向上させるためのバッチUPDATE DMLステートメントのサポート #8084 @amyangfei
    • MQ シンクと MySQL シンクを非同期モードで実装して、シンクのスループットを向上させます #5928 @hicqu@Rustin170506

  • TiDBデータ移行（DM）

    • DM アラート ルールとコンテンツを最適化 #7376 @D3Hunter

      従来は、関連するエラーが発生するたびに「DM_XXX_process_exits_with_error」のようなアラートが発生していました。しかし、一部のアラートはアイドル状態のデータベース接続が原因で発生し、再接続後に回復できる場合があります。このようなアラートを減らすため、DMはエラーを自動的に回復可能なエラーと回復不可能なエラーの2種類に分類します。

      • 自動的に回復可能なエラーの場合、DMは2分以内にエラーが3回以上発生した場合にのみアラートを報告します。
      • 自動的に回復できないエラーの場合、DMは元の動作を維持し、アラートを即座に報告します。

    • 非同期/バッチリレーライターを追加してリレーパフォーマンスを最適化 #4287 @GMHDBJD

  • TiDB Lightning

    • 物理インポートモードはキースペース #40531 @iosmanthusをサポートします
    • lightning.max-errorによる競合の最大数設定のサポート #40743 @dsdashun
    • BOMヘッダー付きCSVデータファイルのインポートをサポート #40744 @dsdashun
    • TiKVフロー制限エラーが発生した場合の処理​​ロジックを最適化し、代わりに他の利用可能な領域を試す #40205 @lance6716
    • インポート中のテーブル外部キーのチェックを無効にする #40027 @sleepymole

  • Dumpling

    • 外部キーの設定のエクスポートをサポート #39913 @lichunzhu

  • 同期差分検査ツール

    • 下流のテーブルが上流に存在しない場合に、上流と下流のデータ整合性のチェックをスキップするかどうかを制御する新しいパラメータskip-non-existing-tableを追加します #692 @lichunzhu@liumengya94

バグ修正

• TiDB

  • 統計収集タスクがdatetime値の誤りにより失敗する問題を修正 #39336 @xuyifangreeneyes
  • テーブル作成後にstats_metaが作成されない問題を修正 #38189 @xuyifangreeneyes
  • DDLデータバックフィル実行時のトランザクションにおける頻繁な書き込み競合を修正 #24427 @mjonss
  • インジェストモードを使用して空のテーブルにインデックスを作成できない場合がある問題を修正 #39641 @tangenta
  • スロークエリログのwait_tsが同じトランザクション内の異なる SQL ステートメントでも同じである問題を修正 #39713 @TonsnakeLin
  • 行レコードの削除処理中に列を追加した際にAssertion Failedエラーが報告される問題を修正しました #39570 @wjhuang2016
  • 列タイプを変更する際にnot a DDL ownerエラーが報告される問題を修正しました #39643 @zimulala
  • AUTO_INCREMENT列の自動インクリメント値が使い果たされた後に行を挿入してもエラーが報告されない問題を修正しました #38950 @Dousir9
  • 式インデックスの作成時にUnknown columnエラーが報告される問題を修正 #39784 @Defined2014
  • 生成された式にこのテーブルの名前が含まれている場合、名前が変更されたテーブルにデータを挿入できない問題を修正します #39826 @Defined2014
  • 列が書き込み専用の場合にINSERT ignoreステートメントがデフォルト値を入力できない問題を修正 #40192 @YangKeao
  • リソース管理モジュールを無効にしたときにリソースが解放されない問題を修正 #40546 @zimulala
  • TTLタスクが統計情報の更新を時間内にトリガーできない問題を修正 #40109 @YangKeao
  • TiDBがキー範囲を構築する際にNULL値を適切に処理しないために予期しないデータが読み込まれる問題を修正しました #40158 @tiancaiamao
  • MODIFY COLUMNステートメントが列のデフォルト値も変更する場合に、無効な値がテーブルに書き込まれる問題を修正します #40164 @wjhuang2016
  • テーブル内にリージョンが多数存在する場合に、リージョンキャッシュが無効になるためインデックス追加操作が非効率になる問題を修正しました #38436 @tangenta
  • 自動インクリメントIDの割り当て時に発生したデータ競合を修正 #40584 @Dousir9
  • JSON の not 演算子の実装が MySQL の実装と互換性がない問題を修正しました #40683 @YangKeao
  • 同時ビューがDDL操作をブロックする可能性がある問題を修正 #40352 @zeminzhou
  • パーティションテーブルの列を変更するDDLステートメントを同時に実行することによって発生するデータの不整合を修正 #40620 @mjonss@mjonss
  • caching_sha2_passwordを認証に使用し、パスワードを指定しない場合に「不正なパケット」が報告される問題を修正 #40831 @dveeden
  • テーブルの主キーにENUM列が含まれている場合に TTL タスクが失敗する問題を修正しました #40456 @lcwangchao
  • mysql.tidb_mdl_view #40838 @YangKeaoで、MDLによってブロックされた一部のDDL操作をクエリできない問題を修正します。
  • DDL取り込み中にデータ競合が発生する可能性がある問題を修正 #40970 @tangenta
  • タイムゾーン変更後にTTLタスクが一部のデータを誤って削除する可能性がある問題を修正 #41043 @lcwangchao
  • JSON_OBJECTが場合によってはエラーを報告する問題を修正 #39806 @YangKeao
  • TiDB が初期化中にデッドロックする可能性がある問題を修正 #40408 @Defined2014
  • メモリ再利用によりシステム変数の値が場合によっては誤って変更される可能性がある問題を修正 #40979 @lcwangchao
  • 取り込みモードで一意インデックスを作成すると、データがインデックスと矛盾する可能性がある問題を修正します #40464 @tangenta
  • 同じテーブルを同時に切り捨てる際に、一部の切り捨て操作がMDLによってブロックされない問題を修正しました #40484 @wjhuang2016
  • SHOW PRIVILEGESステートメントが不完全な特権リストを返す問題を修正 #40591 @CbcWestwolf
  • 一意のインデックスを追加するときに TiDB がパニックになる問題を修正 #40592 @tangenta
  • ADMIN RECOVERステートメントを実行するとインデックスデータが破損する可能性がある問題を修正しました #40430 @xiongjiwei
  • クエリ対象のテーブルに式インデックスにCAST式が含まれている場合にクエリが失敗する可能性がある問題を修正しました #40130 @xiongjiwei
  • ユニークインデックスが場合によっては重複データを生成する可能性がある問題を修正 #40217 @tangenta
  • PrepareまたはExecute #39605 @djshow832
  • インデックス追加時にデータ競合が発生する可能性がある問題を修正 #40879 @tangenta
  • 仮想列 #41014 @AilinKidキッドによって引き起こされるcan't find proper physical planの問題を修正します
  • 動的トリミングモードでパーティションテーブルのグローバルバインディングが作成された後、TiDBが再起動できない問題を修正 #40368 @Yisaer
  • auto analyzeが原因で正常シャットダウンに時間がかかる問題を修正 #40038 @xuyifangreeneyes
  • IndexMerge オペレーターがメモリ制限動作をトリガーしたときの TiDBサーバーのpanicを修正 #41036 @guo-shaoge
  • パーティションテーブルに対するSELECT * FROM table_name LIMIT 1クエリが遅い問題を修正 #40741 @solotzg

• TiKV

  • const Enum型を他の型にキャストする際に発生するエラーを修正します #14156 @wshwsh12
  • 解決された TS によりネットワーク トラフィックが増加する問題を修正 #14092 @overvenus
  • TiDBとTiKV間のネットワーク障害によって発生するデータ不整合の問題を修正。DML実行中に悲観的DMLが失敗した後に発生するデータ不整合の問題を修正 #14038 @MyonKeminta

• PD

  • リージョン Scatterタスクが予期せず冗長なレプリカを生成する問題を修正 #5909 @HunDunDM
  • オンラインの安全でない回復機能がauto-detectモードで停止してタイムアウトする問題を修正しました #5753 @Connor1996
  • 特定の条件下でreplace-down-peer実行が遅くなる問題を修正 #5788 @HunDunDM
  • ReportMinResolvedTSの呼び出しが頻繁すぎる場合に発生する PD OOM 問題を修正します #5965 @HunDunDM

• TiFlash

  • TiFlash関連のシステムテーブルへのクエリが停止する可能性がある問題を修正 #6745 @lidezhu
  • セミジョインがデカルト積を計算する際に過剰なメモリを使用する問題を修正 #6730 @gengliqi
  • DECIMAL データ型の除算演算の結果が丸められない問題を修正 #6393 @LittleFall
  • TiFlashクエリでstart_tsがMPPクエリを一意に識別できない問題を修正します。これにより、MPPクエリが誤ってキャンセルされる可能性があります #43426 @hehechen

• ツール

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

    • ログバックアップの復元時に、ホットリージョンが原因で復元が失敗する問題を修正 #37207 @Leavrth
    • ログバックアップが実行されているクラスターにデータを復元すると、ログバックアップファイルが復元不能になる問題を修正しました #40797 @Leavrth
    • PITR 機能が CA バンドルをサポートしていない問題を修正 #38775 @YuJuncen
    • リカバリ中に重複する一時テーブルが原因で発生するpanic問題を修正 #40797 @joccau
    • PITR が PD クラスターの構成変更をサポートしていない問題を修正 #14165 @YuJuncen
    • PDとtidb-server間の接続障害によりPITRバックアップの進行状況が進まなくなる問題を修正 #41082 @YuJuncen
    • PDとTiKV間の接続障害によりTiKVがPITRタスクをリッスンできない問題を修正 #14159 @YuJuncen
    • TiDBクラスタにPITRバックアップタスクがない場合、 resolve lockの頻度が高すぎる問題を修正 #40759 @joccau
    • PITRバックアップタスクが削除された際に、残存バックアップデータが原因で新しいタスクのデータ不整合が発生する問題を修正しました #40403 @joccau

  • TiCDC

    • transaction_atomicityとprotocolが設定ファイル経由で更新できない問題を修正しました #7935 @CharlesCheung96
    • リドゥログのstorageパスで事前チェ​​ックが実行されない問題を修正 #6335 @CharlesCheung96
    • S3storage障害時にリドゥログが許容できる期間が不十分であるという問題を修正 #8089 @CharlesCheung96
    • TiKVまたはTiCDCノードのスケールインまたはスケールアウト時などの特殊なシナリオでchangefeedが停止する可能性がある問題を修正しました #8174 @hicqu
    • TiKV ノード間のトラフィックが多すぎる問題を修正 #14092 @overvenus
    • プルベースのシンクが有効になっている場合の CPU 使用率、メモリ制御、スループットに関する TiCDC のパフォーマンスの問題を修正#8142 #8157 #8001 #5928 @hicqu@Rustin170506

  • TiDBデータ移行（DM）

    • binlog-schema deleteコマンドの実行に失敗する問題を修正しました #7373 @liumengya94
    • 最後のbinlogがスキップされたDDLである場合にチェックポイントが進まない問題を修正 #8175 @D3Hunter
    • 1 つのテーブルで「更新」タイプと「非更新」タイプの両方の式フィルターが指定されている場合、すべてのUPDATEステートメントがスキップされるバグを修正しました #7831 @lance6716
    • テーブルにupdate-old-value-exprまたはupdate-new-value-exprのいずれか一方のみが設定されている場合、フィルタルールが有効にならないか、DM がパニックを起こすバグを修正しました。 #7774 @lance6716

  • TiDB Lightning

    • 一部のシナリオで TiDB の再起動によりTiDB Lightningタイムアウトがハングする問題を修正 #33714 @lichunzhu
    • TiDB Lightning が並列インポート中に最後のTiDB Lightningインスタンスを除くすべてのインスタンスでローカルの重複レコードに遭遇した場合に、競合解決を誤ってスキップする可能性がある問題を修正しました #40923 @lichunzhu
    • 事前チェックでターゲットクラスター内で実行中の TiCDC の存在を正確に検出できない問題を修正します #41040 @lance6716
    • TiDB Lightningが分割リージョンフェーズでパニックを起こす問題を修正 #40934 @lance6716
    • 競合解決ロジック ( duplicate-resolution ) がチェックサムの不一致を引き起こす可能性がある問題を修正 #40657 @sleepymole
    • データ ファイルに閉じられていない区切り文字がある場合に発生する可能性のある OOM 問題を修正 #40400 @buchuitoudegou
    • エラーレポート内のファイルオフセットがファイルサイズを超える問題を修正 #40034 @buchuitoudegou
    • PDClient の新しいバージョンで並行インポートが失敗する可能性がある問題を修正 #40493 @AmoebaProtozoa
    • TiDB Lightningの事前チェックで、以前のインポート失敗によって残されたダーティデータを見つけられない問題を修正 #39477 @dsdashun

寄稿者

TiDBコミュニティの以下の貢献者の皆様に感謝申し上げます。

• モルゴ
• ジフハスト
• b41sh
• ソースリウ
• ソンジビン97
• マミル
• Dousir9
• ひひひひひ
• ミコキシン
• シュニン97
• andreid-db