TiDB 6.6.0 リリースノート

発売日：2023年2月20日

TiDB バージョン: 6.6.0- DMR

注記：

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

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

v6.6.0-DMR の主な新機能と改善点は次のとおりです。

機能の詳細

スケーラビリティ

• パーティション化されたRaft KVstorageエンジンをサポート (実験的) ＃11515 ＃12842 @ 忙しいカケス @ トニー・シュッキ @ タボキ @ バッファフライ @ 5kbps @ スペードA-タン @ ノルーシュ

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

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

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

• DDL操作の分散並列実行フレームワークをサポート（実験的） ＃37125 @ ジムララ

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

パフォーマンス

• 悲観的ロックキュー＃13298 @ ミョンケミンタの安定したウェイクアップ モデルをサポート

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

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

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

• バッチ集計データ要求＃39361 @ cfzjywxk @ あなた06

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

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

• LIMIT節＃40219 @ fzzf678の制限を削除します

  v6.6.0以降、TiDBプランキャッシュは、 LIMITパラメータとしてLIMIT ?やLIMIT 10, ?の変数を持つ実行プランのキャッシュをサポートします。この機能により、より多くのSQL文がプランキャッシュの恩恵を受けられるようになり、実行効率が向上します。現在、セキュリティ上の配慮から、TiDBは?が10000以下の実行プランのみをキャッシュできます。

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

• TiFlashは圧縮＃6620 @ ソロツグによるデータ交換をサポート

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

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

• TiFlashはステイル読み取り機能＃4483 @ ヘヘチェンをサポートしています

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

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

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

• regexp_replaceストリング機能をTiFlash ＃6115 @ xzhangxian1008にプッシュダウンする機能をサポート

信頼性

• リソース グループに基づくリソース制御のサポート (実験的) ＃38825 @ ノルーシュ @ 生まれ変わった人 @ 栄光 @ 天菜まお @ コナー1996 @ Jmポテト @ ネス HuSharp キャビンフィーバーB

  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です

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

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

• いくつかのオプティマイザヒント＃39964 @ 思い出させるを追加します

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

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

  オプティマイザーヒントを継続的に導入することで、ユーザーにさらに多くの介入方法が提供され、SQL パフォーマンスの問題が解決され、全体的なパフォーマンスの安定性が向上します。

• DDL 操作のリソース使用量の動的管理をサポート (実験的) ＃38025 @ ホーキングレイ

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

可用性

• SURVIVAL_PREFERENCE対SQLの配置ルール対ノルーシュ ＃38605構成をサポート

  SURVIVAL_PREFERENCES指定すると、データの災害時における生存性を高めるためのデータ生存設定が提供されます。2 SURVIVAL_PREFERENCE指定すると、以下の項目を制御できます。

  • クラウド リージョン全体に展開された TiDB クラスターの場合、1 つのクラウド リージョンに障害が発生しても、指定されたデータベースまたはテーブルは別のクラウド リージョンで存続できます。
  • 単一のクラウド リージョンにデプロイされた TiDB クラスターの場合、アベイラビリティ ゾーンで障害が発生しても、指定されたデータベースまたはテーブルは別のアベイラビリティ ゾーンで存続できます。

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

• FLASHBACK CLUSTER TO TIMESTAMP文＃14045 @ 定義2014 @ Jmポテトによる DDL 操作のロールバックをサポート

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

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

SQL

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

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

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

• MySQL互換の多値インデックスをサポート（実験的） ＃39592 @ ションジウェイ @ qw4990

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

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

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

DB操作

• リソースを消費するタスク用の読み取り専用storageノードの構成をサポート @ v01dstar

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

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

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

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

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

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

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

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

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

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

  v6.6.0より前のバージョンでは、大容量データを扱うシナリオでは、高速な完全データ移行のためにTiDB Lightningで物理インポートタスクを別途設定し、その後DMを使用して増分データ移行を行う必要があり、設定が複雑でした。v6.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 TiDB Lightning はエラーを無視し、ターゲットテーブルの列の順序に従ってデータのインポートを続行します。

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

• TiDB Lightningは、 TiKV ＃41163 @ 眠そうなモグラにキーと値のペアを送信するときに圧縮転送を有効にすることをサポートします。

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

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

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

• TiKV-CDCツールがGAとなり、RawKV ＃48 @ 沢民州 @ ハオジンミン @ ピンギュのデータ変更の購読をサポートするようになりました。

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

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

• TiCDC は、Kafka の変更フィード上の単一のテーブルのスケールアウトと、変更フィードを複数の TiCDC ノードに分散することをサポートします (実験的) ＃7720 @ 金星の上

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

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

• ゴームではTiDBの統合テストが追加されました。これにより、TiDBがGORMでサポートされるデフォルトのデータベースになりました＃6014 @ アイスマップ

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

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

可観測性

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

  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 @ 時間と運命

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

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

• SQL実行プラン＃38779 @ イーサールの生成を自動的にキャプチャ

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

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

  この機能を使用するには、 tidb_enable_plan_replayer_captureの値をONに設定します。

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

• 永続的なステートメントのサポートの概要（実験的） ＃40812 @ モーニクス

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

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

Security

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

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

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

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

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

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

テレメトリー

• 2023年2月20日以降、TiDBおよびTiDB Dashboardの新しいバージョン（v6.6.0を含む）では、 テレメトリ機能デフォルトで無効化されます。デフォルトのテレメトリ設定を使用している以前のバージョンからアップグレードした場合、アップグレード後にテレメトリ機能は無効化されます。具体的なバージョンについては、 TiDB リリース タイムラインご覧ください。
• v1.11.3 以降、新規に導入されたTiUPではテレメトリ機能がデフォルトで無効化されます。以前のバージョンのTiUPから v1.11.3 以降にアップグレードした場合、テレメトリ機能はアップグレード前と同じ状態を維持します。

互換性の変更

注記：

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

MySQLの互換性

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

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

• MySQL互換のマルチ値インデックスをサポート（実験的） ＃39592 @ ションジウェイ @ qw4990

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

システム変数

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

その他

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

改善点

• TiDB

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

• TiKV

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

• PD

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

• TiFlash

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

• ツール

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

    • TiKV 側でログ バックアップ ファイルのダウンロードの同時実行を最適化して、通常のシナリオ＃14206 @ ユジュンセンでの PITR リカバリのパフォーマンスを向上させます。

  • TiCDC

    • TiCDC レプリケーションのパフォーマンスを向上させるためにバッチUPDATE DML ステートメントをサポートする＃8084 @ 咸陽飛
    • シンクのスループットを向上させるために、非同期モードでMQシンクとMySQLシンクを実装します＃5928 @ ヒック @ ハイラスティン

  • TiDB データ移行 (DM)

    • DMアラートルールとコンテンツ＃7376 @ D3ハンターを最適化

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

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

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

  • TiDB Lightning

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

  • Dumpling

    • 外部キー＃39913 @ リチュンジュ設定のエクスポートをサポート

  • 同期差分インスペクター

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

バグ修正

• TiDB

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

• TiKV

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

• PD

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

• TiFlash

  • TiFlash関連のシステムテーブルをクエリすると＃6745 @ リデズで停止する可能性がある問題を修正しました
  • 直交積＃6730 @ ゲンリキを計算するときにセミ結合が過剰なメモリを使用する問題を修正しました
  • DECIMALデータ型の除算演算の結果が＃6393 @ リトルフォール丸められない問題を修正しました
  • start_ts TiFlashクエリでMPPクエリを一意に識別できないため、MPPクエリが誤ってキャンセルされる可能性がある問題を修正＃43426 @ ヘヘチェン

• ツール

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

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

  • TiCDC

    • transaction_atomicityとprotocol構成ファイル＃7935 @ チャールズ・チュン96経由で更新できない問題を修正
    • REDOログ＃6335 @ チャールズ・チュン96のstorageパスで事前チェックが実行されない問題を修正
    • S3storage障害＃8089 @ チャールズ・チュン96に対して、REDO ログが許容できる期間が不十分である問題を修正しました
    • TiKV または TiCDC ノード＃8174 @ ヒックスケールインまたはスケールアウトなどの特別なシナリオで、changefeed がスタックする可能性がある問題を修正しました。
    • TiKVノード＃14092と金星の上間のトラフィックが多すぎる問題を修正
    • プルベースのシンクが有効な場合の、CPU 使用率、メモリ制御、スループットに関する TiCDC のパフォーマンスの問題を修正しました＃8142 ＃8157 ＃8001 ＃5928 @ ヒック @ ハイラスティン

  • TiDB データ移行 (DM)

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

  • TiDB Lightning

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

寄稿者

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

• モルゴ
• ジフハウス
• b41sh
• ソースリウ
• ソンジビン97
• マミル
• ドゥーシル9
• ヒヒフフ
• マイコキシン
• シュニン97
• andreid-db