TiDB 6.6.0 リリースノート

発売日: 2023年2月20日

TiDB バージョン: 6.6.0- DMMR の

注記：

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 以降では、新しい TiKVstorageエンジンが導入されました。このエンジンは、複数の RocksDB インスタンスを使用して TiKVリージョンデータを格納し、各リージョンのデータは個別の RocksDB インスタンスに独立して格納されます。新しいエンジンは、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 @ ミョンケミンタの安定したウェイクアップ モデルをサポート

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

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

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

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

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

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

• LIMIT節#40219 @ ふーふーの制限を解除します

  v6.6.0 以降、TiDB プラン キャッシュは、 LIMIT ?やLIMIT 10, ?などの変数をLIMITパラメータとして持つ実行プランのキャッシュをサポートします。この機能により、より多くの 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 @ 翻訳者にプッシュダウンする機能をサポート

信頼性

• リソース グループに基づくリソース制御をサポート (実験的) ＃38825 @ ノルーシュ @ ボーンチェンジャー @ 栄光 @ 天菜まお @ コナー1996 @ じゃがいも @ ネス @ キャビンフィーバーB @ ヒューシャープ

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

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

  この機能を使用すると、次のことが可能になります。

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

  さらに、リソース制御機能を合理的に使用すると、クラスターの数を減らし、運用と保守の難易度を軽減し、管理コストを節約できます。

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

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

• 過去の実行計画のバインドは GA ＃39199 @ ふーふーです

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

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

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

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

  • 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 for SQL の配置ルール ＃38605 @ ノルーシュの構成をサポート

  SURVIVAL_PREFERENCESデータの災害時の生存性を高めるためのデータ生存設定を提供します。 SURVIVAL_PREFERENCEを指定すると、以下を制御できます。

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

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

• FLASHBACK CLUSTER TO TIMESTAMPステートメント＃14045 @ 定義2014 @ じゃがいもによる DDL 操作のロールバックをサポート

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

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

構文

• MySQL 互換の外部キー制約をサポート (実験的) ＃18209 @ クレイジーcs520

  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ノードの構成をサポート @ v01dスター

  本番環境では、バックアップや大規模なデータの読み取りと分析など、一部の読み取り専用操作が定期的に大量のリソースを消費し、クラスター全体のパフォーマンスに影響を与える可能性があります。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 @ リクササシネーターの動的変更をサポート

  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"を追加します@ ダシュン

  v6.6.0 では、 TiDB Lightningに新しいプロファイル パラメータ"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 (Change Data Capture) ツールです。TiKV と PD は、TiDB なしで使用すると KV データベースを構成でき、RawKV と呼ばれます。TiKV-CDC は、RawKV のデータ変更をサブスクライブし、それを下流の TiKV クラスターにリアルタイムで複製することをサポートしているため、RawKV のクラスター間レプリケーションが可能になります。

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

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

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

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

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

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

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

可観測性

• TiDBダッシュボード＃781 @ 宜尼Xu9506で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 はプランをキャッシュしません。

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

• スロークエリログ＃39893 @ 時間と運命にWarningsフィールドを追加します

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

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

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

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

  このような問題に対処するため、TiDB v6.6.0 では、 PLAN REPLAYER PLAN REPLAYER CAPTUREキャプチャの機能が拡張されました。3 コマンドを使用すると、対象の 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 @ うわーの自動ローテーションをサポートします

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

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

• TiDB Lightning は、 AWS IAMロールキーとセッショントークン＃40750 @ ok江を介して 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 @ クレイジーcs520

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

• MySQL互換のマルチ値インデックスをサポート（実験的） ＃39592 @ 雄吉偉 @ qw4990

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

システム変数

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

その他

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

改善点

• ティビ

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

• ティクヴ

  • パーティション化された 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 @ トニー
  • Raftstore非同期書き込み＃13730 @ コナー1996での優先スケジューリングをサポート
  • 1コア未満のCPUでのTiKVの起動をサポート＃13586 ＃13752 ＃14017 @ アンドレイドDB
  • Raftstoreスロースコアの新しい検出メカニズムを最適化し、 evict-slow-trend-scheduler ＃14131 @ 内側を追加します
  • RocksDB のブロックキャッシュを強制的に共有し、CF ＃12936 @ 忙しいカケスに従ってブロックキャッシュを個別に設定することはサポートされなくなりました。

• PD

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

• TiFlash

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

• ツール

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

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

  • ティCDC

    • 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 @ ダシュンで設定するサポート
    • BOM ヘッダー＃40744 @ ダシュンを含む CSV データ ファイルのインポートをサポート
    • TiKV フロー制限エラーが発生した場合は処理ロジックを最適化し、代わりに他の利用可能な領域を試します#40205 @ ランス6716
    • インポート中にテーブルの外部キーのチェックを無効にする#40027 @ 眠いモグラ

  • Dumpling

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

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

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

バグ修正

• ティビ

  • datetime値＃39336 @ 翻訳者が正しくないために統計収集タスクが失敗する問題を修正しました
  • テーブル作成＃38189 @ 翻訳者の後にstats_meta作成されない問題を修正
  • DDL データ バックフィル＃24427 @ ミョンスを実行するときにトランザクションで頻繁に発生する書き込み競合を修正
  • 取り込みモード＃39641 @ タンジェンタを使用して空のテーブルにインデックスを作成できないことがある問題を修正しました。
  • 同じトランザクション内の異なるSQL文に対して、スロークエリログのwait_ts同じになる問題を修正＃39713 @ トンスネークリン
  • 行レコード＃39570 @ 翻訳:を削除するプロセス中に列を追加すると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 @ 翻訳:のデフォルト値も変更すると、テーブルに不正な値が書き込まれる問題を修正しました。
  • テーブル＃38436 @ タンジェンタに多くのリージョンがある場合、無効なリージョンキャッシュが原因でインデックス追加操作が非効率になる問題を修正しました。
  • 自動増分 ID ＃40584 @ ドゥージール9の割り当てで発生するデータ競合を修正
  • JSON の not 演算子の実装が MySQL ＃40683 @ ヤンケオの実装と互換性がない問題を修正しました
  • 同時ビューによって DDL 操作がブロックされる可能性がある問題を修正＃40352 @ 沢民州
  • パーティション化されたテーブルの列を変更する DDL ステートメントを同時に実行することによって発生するデータの不整合を修正します＃40620 @ ミョンス @ ミョンス
  • パスワードを指定せずに認証に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 @ 翻訳:
  • SHOW PRIVILEGES文が不完全な権限リスト＃40591 @ Cbcウェストウルフを返す問題を修正
  • ユニークインデックス＃40592 @ タンジェンタを追加するときに TiDB がパニックになる問題を修正
  • ADMIN RECOVERステートメントを実行するとインデックスデータが破損する可能性がある問題を修正#40430 @ 雄吉偉
  • クエリ対象のテーブルに式インデックス#40130 @ 雄吉偉にCAST式が含まれている場合にクエリが失敗する可能性がある問題を修正しました。
  • ユニークインデックスが重複データを生成する場合がある問題を修正＃40217 @ タンジェンタ
  • 多数のリージョンがあるが、 PrepareまたはExecute ＃39605 @ 翻訳者を使用して一部の仮想テーブルをクエリするときにテーブル ID をプッシュダウンできない PD OOM 問題を修正しました。
  • インデックスを＃40879 @ タンジェンタで追加するとデータ競合が発生する可能性がある問題を修正しました
  • 仮想列＃41014 @ アイリンキッドによって発生するcan't find proper physical plan問題を修正
  • 動的トリミングモード＃40368 @ イサールでパーティションテーブルにグローバルバインディングが作成された後に TiDB が再起動できない問題を修正しました。
  • auto analyzeにより正常なシャットダウンに長い時間がかかる問題を修正＃40038 @ 翻訳者
  • IndexMerge 演算子がメモリ制限動作をトリガーしたときに TiDBサーバーのpanicが発生する問題を修正＃41036 @ グオシャオゲ
  • パーティションテーブルに対するSELECT * FROM table_name LIMIT 1クエリが遅い問題を修正＃40741 @ ソロッツ

• ティクヴ

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

• PD

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

• 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 @ ジョッカウでデータの不整合が発生する問題を修正しました。

  • ティCDC

    • 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 @ りゅうめんぎゃの実行に失敗する問題を修正
    • 最後の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 @ ダシュン

寄稿者

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

• モルゴ
• ジフハウス
• b41sh
• ソースリウ
• 歌zhibin97
• マミル
• ドゥージール9
• ヒヒフフ
• マイコキシン
• 翻訳者
• アンドレイドDB