TiDB 6.6.0 リリースノート
発売日：2023年2月20日
TiDB バージョン: DMR
注記：
TiDB 6.6.0-DMR のドキュメントはアーカイブされたになりました。 PingCAP では、 最新のLTSバージョンの TiDB データベースを使用することをお勧めします。
クイックアクセス: クイックスタート | インストールパッケージ
v6.6.0-DMR の主な新機能と改善点は次のとおりです。
| カテゴリー | 特徴 | 説明 |
|---|---|---|
| スケーラビリティとパフォーマンス | TiKV はPartitioned Raft KVstorageエンジンをサポートします (実験的) | TiKV は Partitioned Raft KVstorageエンジンを導入し、各リージョンは独立した RocksDB インスタンスを使用します。これにより、クラスターのstorage容量を TB から PB に簡単に拡張でき、より安定した書き込みレイテンシーと強力なスケーラビリティを実現できます。 |
| TiKV はデータリクエストのバッチ集約をサポートします | この機能強化により、TiKV バッチ取得操作の合計 RPC が大幅に削減されます。データが高度に分散しており、gRPC スレッド プールのリソースが不十分な状況では、コプロセッサ要求をバッチ処理すると、パフォーマンスが 50% 以上向上する可能性があります。 | |
| TiFlash はステイル読み取りと圧縮交換をサポートします | TiFlash は、リアルタイム要件が制限されていないシナリオでクエリのパフォーマンスを向上させることができる古い読み取り機能をサポートしています。 TiFlash は、並列データ交換の効率を向上させるデータ圧縮をサポートしており、TPC-H の全体的なパフォーマンスが 10% 向上し、ネットワーク使用量を 50% 以上節約できます。 | |
| 信頼性と可用性 | リソース制御(実験的) | リソース グループに基づいたリソース管理をサポートします。これにより、データベース ユーザーが対応するリソース グループにマップされ、実際のニーズに基づいて各リソース グループのクォータが設定されます。 |
| 履歴 SQL バインディング | TiDB ダッシュボードで履歴実行計画のバインドと実行計画の迅速なバインドをサポートします。 | |
| SQL 機能 | 外部キー(実験的) | データの一貫性を維持し、データ品質を向上させるために、MySQL 互換の外部キー制約をサポートします。 |
| 多値インデックス(実験的) | MySQL と互換性のある多値インデックスを導入し、JSON タイプを強化して、TiDB と MySQL 8.0 の互換性を向上させます。 | |
| DBの操作と可観測性 | DM は物理的なインポートをサポートします(実験的) | TiDB Data Migration (DM) は、TiDB Lightning の物理インポート モードを統合して、完全なデータ移行のパフォーマンスを向上させ、パフォーマンスが最大 10 倍速くなります。 |
機能の詳細
スケーラビリティ
サポートパーティションRaft KVstorageエンジン (実験的) #11515 #12842 @ ビジージェイ @ トニーシュクキ @ タボキー @ バッファフライ @ 5kbps @ SpadeA-Tang @ ノールーシュ
TiDB v6.6.0 より前は、TiKV の Raft ベースのstorageエンジンは単一の RocksDB インスタンスを使用して、TiKV インスタンスのすべての「リージョン」のデータを保存していました。大規模なクラスターをより安定してサポートするために、TiDB v6.6.0 以降では、複数の RocksDB インスタンスを使用して TiKVリージョンデータを保存する新しい TiKVstorageエンジンが導入され、各リージョンのデータは個別の RocksDB インスタンスに個別に保存されます。新しいエンジンは、RocksDB インスタンス内のファイルの数とレベルをより適切に制御し、リージョン間のデータ操作の物理的な分離を実現し、より多くのデータの安定した管理をサポートします。これは、パーティショニングを通じて複数の RocksDB インスタンスを管理する TiKV として見ることができます。そのため、この機能は 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 @ cfzjywxk @ あなた06
TiDB がデータ リクエストを TiKV に送信すると、TiDB はデータが存在するリージョンに応じてリクエストを異なるサブタスクにコンパイルし、各サブタスクは 1 つのリージョンのリクエストのみを処理します。アクセスするデータが分散性が高い場合、データサイズが大きくなくてもサブタスクが多数生成され、RPCリクエストが多く発生して余分な時間がかかります。 v6.6.0 以降、TiDB は、同じ TiKV インスタンスに送信されるデータ リクエストの部分的なマージをサポートします。これにより、サブタスクの数と RPC リクエストのオーバーヘッドが削減されます。データの分散が高く、gRPC スレッド プール リソースが不十分な場合、リクエストをバッチ処理するとパフォーマンスが 50% 以上向上する可能性があります。
この機能はデフォルトで有効になっています。システム変数
tidb_store_batch_sizeを使用してリクエストのバッチ サイズを設定できます。LIMIT条項#40219 @ fzzf678の制限を削除しますv6.6.0 以降、TiDB プラン キャッシュは、
LIMIT ?やLIMIT 10, ?などの変数をLIMITパラメータとして使用した実行プランのキャッシュをサポートします。この機能により、より多くの SQL ステートメントがプラン キャッシュの恩恵を受けることができるため、実行効率が向上します。現在、セキュリティを考慮して、TiDB は 10000 以下の?の実行プランのみをキャッシュできます。詳細については、 ドキュメンテーションを参照してください。
TiFlash は圧縮#6620 @ ソロッツグでのデータ交換をサポートします
コンピューティングのために複数のノードと連携するには、 TiFlashエンジンは異なるノード間でデータを交換する必要があります。交換されるデータのサイズが非常に大きい場合、データ交換のパフォーマンスが全体的なコンピューティング効率に影響を与える可能性があります。 v6.6.0 では、 TiFlashエンジンに圧縮メカニズムが導入され、必要に応じて交換するデータを圧縮してから交換が行われるため、データ交換の効率が向上します。
詳細については、 ドキュメンテーションを参照してください。
TiFlash は、 ステイル読み取り機能#4483 @ へへへんをサポートしています。
ステイル読み取り機能は v5.1.1 から一般提供 (GA) されており、特定のタイムスタンプまたは指定された時間範囲内の履歴データを読み取ることができます。古い読み取りでは、ローカル TiKV レプリカからデータを直接読み取ることで、読み取りレイテンシーを短縮し、クエリのパフォーマンスを向上させることができます。 v6.6.0 より前では、 TiFlash はステイル読み取りをサポートしていません。テーブルにTiFlashレプリカがある場合でも、 ステイル読み取り はその TiKV レプリカのみを読み取ることができます。
v6.6.0 以降、 TiFlash はステイル読み取り機能をサポートします。
AS OF TIMESTAMP構文またはtidb_read_stalenessシステム変数を使用してテーブルの履歴データをクエリするとき、テーブルにTiFlashレプリカがある場合、オプティマイザはTiFlashレプリカから対応するデータを読み取ることを選択できるため、クエリのパフォーマンスがさらに向上します。詳細については、 ドキュメンテーションを参照してください。
regexp_replace文字列機能のTiFlash #6115 @ xzhangxian1008へのプッシュダウンをサポート
信頼性
リソース グループに基づくリソース制御のサポート (実験的) #38825 @ ノールーシュ @ ボーンチェンジャー @ グロルフ @ ティエンチャイアマオ @ コナー1996 @ Jmポテト @ フネス @ キャビンフィーバー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_PREFERENCEfor SQL の配置ルール #38605 @ ノールーシュの構成をサポートSURVIVAL_PREFERENCESデータの災害時の生存性を高めるためのデータ生存性設定を提供します。SURVIVAL_PREFERENCEを指定すると、次のことを制御できます。- クラウド リージョン全体にデプロイされた TiDB クラスターの場合、クラウド リージョンに障害が発生した場合、指定されたデータベースまたはテーブルは別のクラウド リージョンで存続できます。
- 単一のクラウド リージョンにデプロイされた TiDB クラスターの場合、可用性ゾーンに障害が発生した場合、指定されたデータベースまたはテーブルは別の可用性ゾーンで存続できます。
詳細については、 ドキュメンテーションを参照してください。
FLASHBACK CLUSTER TO TIMESTAMPステートメント#14045 @ 定義2014 @ Jmポテトによる DDL 操作のロールバックのサポートFLASHBACK CLUSTER TO TIMESTAMPステートメントは、ガベージ コレクション (GC) の有効期間内の指定された時点へのクラスター全体の復元をサポートします。 TiDB v6.6.0 では、この機能により DDL 操作のロールバックのサポートが追加されています。これを使用すると、クラスター上での DML または DDL の誤操作をすばやく元に戻したり、数分以内にクラスターをロールバックしたり、タイムライン上でクラスターを複数回ロールバックして、特定のデータ変更がいつ発生したかを判断したりすることができます。詳細については、 ドキュメンテーションを参照してください。
SQL
MySQL 互換の外部キー制約をサポート (実験的) #18209 @ クレイジークス520
TiDB v6.6.0 では、MySQL と互換性のある外部キー制約機能が導入されています。この機能は、テーブル内またはテーブル間の参照、制約の検証、およびカスケード操作をサポートします。この機能は、アプリケーションを TiDB に移行し、データの一貫性を維持し、データ品質を向上させ、データ モデリングを容易にするのに役立ちます。
詳細については、 ドキュメンテーションを参照してください。
MySQL 互換の複数値インデックスのサポート (実験的) #39592 @ ションジウェイ @ qw4990
TiDB は、v6.6.0 で MySQL 互換の複数値インデックスを導入します。 JSON 列内の配列の値をフィルター処理するのは一般的な操作ですが、通常のインデックスではそのような操作を高速化することはできません。配列に複数値のインデックスを作成すると、フィルタリングのパフォーマンスが大幅に向上します。 JSON列の配列に多値インデックス
JSON_OVERLAPS()ある場合、多値インデックスを使用してMEMBER OF()関数で検索条件を絞り込むことができるため、I/O消費量JSON_CONTAINS()大幅に削減され、動作速度が向上します。多値インデックスの導入により、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 @ リククスサシネーターの動的変更をサポート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 Data Migration (DM) は、TiDB Lightning の物理インポート モードと統合され、完全な移行 (実験的) @ ランス6716のパフォーマンスが最大 10 倍向上します。
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"を追加 @ dsダシュンv6.6.0 では、 TiDB Lightning に新しいプロファイル パラメータ
"header-schema-match"が追加されています。デフォルト値はtrueです。これは、ソース CSV ファイルの最初の行が列名として扱われ、ターゲット テーブルの最初の行と一貫性があることを意味します。 CSV テーブル ヘッダーのフィールド名がターゲット テーブルの列名と一致しない場合は、この構成をfalseに設定できます。 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 @ オーバーヴィーナスをサポートしています。
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 では、TiDB に接続するときに、
AutoMigrate#105の間にUniqueフィールドのUnique属性を変更できない問題GORM MySQL ドライバー修正されます。 - GORM ドキュメントデフォルトのデータベースとして TiDB を示しています#638
詳細については、 GORM ドキュメントを参照してください。
- v1.4.6 では、 GORM MySQL ドライバー TiDB #104の
可観測性
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 はプランをキャッシュしません。
詳細については、 ドキュメンテーションを参照してください。
スロークエリログ#39893 @ 時間と運命に
Warningsフィールドを追加します。TiDB v6.6.0 では、パフォーマンスの問題の診断に役立つように、スロー クエリ ログに
Warningsフィールドが追加されます。このフィールドには、遅いクエリの実行中に生成された警告が記録されます。 TiDB ダッシュボードの低速クエリ ページでも警告を表示できます。詳細については、 ドキュメンテーションを参照してください。
SQL 実行プラン#38779 @ イーサールの生成を自動的にキャプチャします。
実行計画の問題のトラブルシューティングのプロセスにおいて、
PLAN REPLAYERシーンを保存し、診断の効率を向上させるのに役立ちます。ただし、シナリオによっては、一部の実行計画の生成を自由に再現できないため、診断作業がより困難になります。このような問題に対処するために、TiDB v6.6.0 では自動キャプチャの機能が
PLAN REPLAYERされています。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 @ オクジャンを介した 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 ダッシュボード (v6.6.0 を含む) の新しいバージョンでは、 テレメトリー機能がデフォルトで無効になります。デフォルトのテレメトリ構成を使用する以前のバージョンからアップグレードする場合、アップグレード後にテレメトリ機能は無効になります。特定のバージョンについては、 TiDB リリース タイムラインを参照してください。
- v1.11.3 以降、新しくデプロイされたTiUPではテレメトリ機能がデフォルトで無効になっています。 TiUPの以前のバージョンから v1.11.3 以降のバージョンにアップグレードした場合、テレメトリ機能はアップグレード前と同じステータスを維持します。
互換性の変更
注記：
このセクションでは、v6.5.0 から現在のバージョン (v6.6.0) にアップグレードするときに知っておく必要がある互換性の変更について説明します。 v6.4.0 以前のバージョンから現在のバージョンにアップグレードする場合は、中間バージョンで導入された互換性の変更も確認する必要がある場合があります。
MySQLの互換性
MySQL 互換の外部キー制約をサポート (実験的) #18209 @ クレイジークス520
詳細については、このドキュメントのSQLセクションとドキュメンテーションを参照してください。
MySQL と互換性のある複数値インデックスのサポート (実験的) #39592 @ ションジウェイ @ qw4990
詳細については、このドキュメントのSQLセクションとドキュメンテーションを参照してください。
システム変数
| 変数名 | 種類の変更 | 説明 |
|---|---|---|
tidb_enable_amend_pessimistic_txn | 削除されました | v6.5.0 以降、この変数は非推奨になりました。 v6.6.0 以降、この変数とAMEND TRANSACTION機能は削除されています。 TiDB はInformation schema is changedエラーを回避するためにメタロック使用します。 |
tidb_enable_concurrent_ddl | 削除されました | この変数は、TiDB が同時 DDL ステートメントを使用できるようにするかどうかを制御します。この変数が無効になっている場合、TiDB は古い DDL 実行フレームワークを使用し、同時 DDL 実行のサポートが制限されています。 v6.6.0 以降、この変数は削除され、TiDB は古い DDL 実行フレームワークをサポートしなくなります。 |
tidb_ttl_job_run_interval | 削除されました | この変数は、バックグラウンドでの TTL ジョブのスケジュール間隔を制御するために使用されます。 v6.6.0 以降、この変数は削除されています。これは、TiDB が TTL ランタイムを制御するためにすべてのテーブルにTTL_JOB_INTERVAL属性を提供しており、これはtidb_ttl_job_run_intervalよりも柔軟であるためです。 |
foreign_key_checks | 修正済み | この変数は、外部キー制約チェックを有効にするかどうかを制御します。デフォルト値はOFFからONに変更されます。これは、デフォルトで外部キーのチェックが有効になることを意味します。 |
tidb_enable_foreign_key | 修正済み | この変数は、外部キー機能を有効にするかどうかを制御します。デフォルト値はOFFからONに変更されます。これは、デフォルトで外部キーが有効になることを意味します。 |
tidb_enable_general_plan_cache | 修正済み | この変数は、一般プラン キャッシュを有効にするかどうかを制御します。 v6.6.0 以降、この変数の名前はtidb_enable_non_prepared_plan_cacheに変更されます。 |
tidb_enable_historical_stats | 修正済み | この変数は、履歴統計を有効にするかどうかを制御します。デフォルト値はOFFからONに変更されます。これは、履歴統計がデフォルトで有効になることを意味します。 |
tidb_enable_telemetry | 修正済み | デフォルト値はONからOFFに変更されます。これは、TiDB ではテレメトリがデフォルトで無効になっていることを意味します。 |
tidb_general_plan_cache_size | 修正済み | この変数は、一般プラン キャッシュによってキャッシュできる実行プランの最大数を制御します。 v6.6.0 以降、この変数の名前はtidb_non_prepared_plan_cache_sizeに変更されます。 |
tidb_replica_read | 修正済み | TiDB が読み取り専用ノードからデータを読み取る際に使用する学習器レプリカを指定するために、この変数に新しい値オプションlearnerが追加されました。 |
tidb_replica_read | 修正済み | TiDB クラスターの全体的な読み取り可用性を向上させるために、この変数に新しい値オプションprefer-leaderが追加されました。このオプションが設定されている場合、TiDB はリーダー レプリカからの読み取りを優先します。リーダー レプリカのパフォーマンスが大幅に低下すると、TiDB は自動的にフォロワー レプリカから読み取ります。 |
tidb_store_batch_size | 修正済み | この変数は、 IndexLookUpオペレーターのコプロセッサータスクのバッチ サイズを制御します。 0バッチを無効にすることを意味します。 v6.6.0 以降、デフォルト値は0から4に変更されます。これは、リクエストのバッチごとに 4 つのコプロセッサータスクが 1 つのタスクにバッチ化されることを意味します。 |
mpp_exchange_compression_mode | 新しく追加された | この変数は、MPP Exchange オペレーターのデータ圧縮モードを指定します。これは、TiDB がバージョン番号1の MPP 実行プランを選択すると有効になります。デフォルト値UNSPECIFIED 、TiDB が自動的にFAST圧縮モードを選択することを意味します。 |
mpp_version | 新しく追加された | この変数は、MPP 実行プランのバージョンを指定します。バージョンが指定されると、TiDB は MPP 実行プランの指定されたバージョンを選択します。デフォルト値UNSPECIFIED TiDB が自動的に最新バージョン1を選択することを意味します。 |
tidb_ddl_distribute_reorg | 新しく追加された | この変数は、DDL 再編成フェーズの分散実行を有効にして、このフェーズを高速化するかどうかを制御します。デフォルト値OFFは、デフォルトでは DDL 再編成フェーズの分散実行を有効にしないことを意味します。現在、この変数はADD INDEXに対してのみ有効です。 |
tidb_enable_historical_stats_for_capture | 新しく追加された | この変数は、 PLAN REPLAYER CAPTUREによって取得される情報にデフォルトで履歴統計が含まれるかどうかを制御します。デフォルト値OFF 、履歴統計がデフォルトで含まれないことを意味します。 |
tidb_enable_plan_cache_for_param_limit | 新しく追加された | この変数は、 プリペアドプランキャッシュ がLimitの後にCOUNT含む実行プランをキャッシュするかどうかを制御します。デフォルト値はONです。これは、 プリペアドプランキャッシュ がそのような実行計画のキャッシュをサポートすることを意味します。 プリペアドプランキャッシュ は、10000 を超える数をカウントするCOUNT条件を持つ実行プランのキャッシュをサポートしていないことに注意してください。 |
tidb_enable_plan_replayer_capture | 新しく追加された | この変数は、 PLAN REPLAYER CAPTURE機能を計画するを有効にするかどうかを制御します。デフォルト値OFF PLAN REPLAYER CAPTURE機能を無効にすることを意味します。 |
tidb_enable_resource_control | 新しく追加された | この変数は、リソース制御機能を有効にするかどうかを制御します。デフォルト値はOFFです。この変数がONに設定されている場合、TiDB クラスターはリソース グループに基づいたアプリケーションのリソース分離をサポートします。 |
tidb_historical_stats_duration | 新しく追加された | この変数は、履歴統計をstorageに保持する期間を制御します。デフォルト値は 7 日です。 |
tidb_index_join_double_read_penalty_cost_rate | 新しく追加された | この変数は、インデックス結合の選択にペナルティ コストを追加するかどうかを制御します。デフォルト値0 、この機能がデフォルトで無効になっていることを意味します。 |
tidb_pessimistic_txn_aggressive_locking | 新しく追加された | この変数は、悲観的トランザクションに対して拡張された悲観的ロック ウェイクアップ モデルを使用するかどうかを制御します。デフォルト値OFFは、デフォルトではこのようなウェイクアップ モデルを悲観的トランザクションに使用しないことを意味します。 |
tidb_stmt_summary_enable_persistent | 新しく追加された | この変数は読み取り専用です。 ステートメントの概要の永続性を有効にするかどうかを制御します。この変数の値は設定項目tidb_stmt_summary_enable_persistentと同じです。 |
tidb_stmt_summary_filename | 新しく追加された | この変数は読み取り専用です。 ステートメントの概要の永続性が有効な場合に永続データが書き込まれるファイルを指定します。この変数の値は設定項目tidb_stmt_summary_filenameと同じです。 |
tidb_stmt_summary_file_max_backups | 新しく追加された | この変数は読み取り専用です。 ステートメントの概要の永続性が有効な場合に保持できるデータ ファイルの最大数を指定します。この変数の値は設定項目tidb_stmt_summary_file_max_backupsと同じです。 |
tidb_stmt_summary_file_max_days | 新しく追加された | この変数は読み取り専用です。 ステートメントの概要の永続性が有効な場合、永続データ ファイルを保持する最大日数を指定します。この変数の値は設定項目tidb_stmt_summary_file_max_daysと同じです。 |
tidb_stmt_summary_file_max_size | 新しく追加された | この変数は読み取り専用です。 ステートメントの概要の永続化が有効な場合、永続データ ファイルの最大サイズを指定します。この変数の値は設定項目tidb_stmt_summary_file_max_sizeと同じです。 |
コンフィグレーションファイルのパラメータ
| コンフィグレーションファイル | コンフィグレーションパラメータ | 種類の変更 | 説明 |
|---|---|---|---|
| TiKV | rocksdb.enable-statistics | 削除されました | この設定項目は、RocksDB 統計を有効にするかどうかを指定します。 v6.6.0以降、この項目は削除されています。 RocksDB 統計は、診断に役立つようにデフォルトですべてのクラスターに対して有効になっています。詳細は#13942を参照してください。 |
| TiKV | raftdb.enable-statistics | 削除されました | この設定項目は、 Raft RocksDB 統計を有効にするかどうかを指定します。 v6.6.0以降、この項目は削除されています。 Raft RocksDB 統計は、診断に役立つようにデフォルトですべてのクラスターに対して有効になっています。詳細は#13942を参照してください。 |
| TiKV | storage.block-cache.shared | 削除されました | v6.6.0 以降、この構成項目は削除され、ブロックキャッシュはデフォルトで有効になり、無効にすることはできません。詳細は#12936を参照してください。 |
| DM | on-duplicate | 削除されました | この構成アイテムは、完全なインポート フェーズ中に競合を解決する方法を制御します。 v6.6.0 では、新しい構成項目on-duplicate-logicalおよびon-duplicate-physicalが導入され、 on-duplicateが置き換えられます。 |
| TiDB | enable-telemetry | 修正済み | v6.6.0 以降、デフォルト値はtrueからfalseに変更されます。これは、TiDB ではテレメトリがデフォルトで無効になっていることを意味します。 |
| TiKV | rocksdb.defaultcf.block-sizeとrocksdb.writecf.block-size | 修正済み | デフォルト値は64Kから32Kに変更されます。 |
| TiKV | rocksdb.defaultcf.block-cache-size rocksdb.writecf.block-cache-size rocksdb.lockcf.block-cache-size | 廃止されました | v6.6.0 以降、これらの構成項目は非推奨になります。詳細は#12936を参照してください。 |
| PD | enable-telemetry | 修正済み | v6.6.0 以降、デフォルト値はtrueからfalseに変更されます。これは、TiDB ダッシュボードでテレメトリがデフォルトで無効になることを意味します。 |
| DM | import-mode | 修正済み | この構成項目の可能な値は、 "sql"および"loader"から"logical"および"physical"に変更されます。デフォルト値は"logical"です。これは、TiDB Lightning の論理インポート モードを使用してデータをインポートすることを意味します。 |
| TiFlash | profile.default.max_memory_usage_for_all_queries | 修正済み | すべてのクエリで生成される中間データのメモリ使用量の制限を指定します。 v6.6.0 以降、デフォルト値は0から0.8に変更されます。これは、制限が合計メモリの 80% であることを意味します。 |
| TiCDC | consistent.storage | 修正済み | この構成項目は、REDO ログのバックアップが保存されるパスを指定します。 scheme 、GCS、および Azure にさらに 2 つの値オプションが追加されます。 |
| TiDB | initialize-sql-file | 新しく追加された | この構成項目は、TiDB クラスターの初回起動時に実行される SQL スクリプトを指定します。デフォルト値は空です。 |
| TiDB | tidb_stmt_summary_enable_persistent | 新しく追加された | この構成項目は、ステートメントの要約の永続性を有効にするかどうかを制御します。デフォルト値はfalseで、この機能はデフォルトでは有効になっていないことを意味します。 |
| TiDB | tidb_stmt_summary_file_max_backups | 新しく追加された | ステートメント概要の永続化が有効になっている場合、この構成では、永続化できるデータ ファイルの最大数を指定します。 0ファイル数に制限がないことを意味します。 |
| TiDB | tidb_stmt_summary_file_max_days | 新しく追加された | ステートメント概要の永続性が有効になっている場合、この構成は永続データ ファイルを保持する最大日数を指定します。 |
| TiDB | tidb_stmt_summary_file_max_size | 新しく追加された | ステートメント概要の永続性が有効になっている場合、この構成は永続データ ファイルの最大サイズ (MiB 単位) を指定します。 |
| TiDB | tidb_stmt_summary_filename | 新しく追加された | ステートメントの概要の永続性が有効になっている場合、この構成は永続データが書き込まれるファイルを指定します。 |
| TiKV | resource-control.enabled | 新しく追加された | 対応するリソース グループのリクエスト ユニット (RU) に従って、ユーザーのフォアグラウンド読み取り/書き込みリクエストのスケジューリングを有効にするかどうか。デフォルト値はfalseで、対応するリソース グループの RU に従ってスケジューリングを無効にすることを意味します。 |
| TiKV | storage.engine | 新しく追加された | この構成項目は、storageエンジンのタイプを指定します。値のオプションは"raft-kv"と"partitioned-raft-kv"です。この設定項目はクラスターの作成時にのみ指定でき、一度指定すると変更することはできません。 |
| TiKV | rocksdb.write-buffer-flush-oldest-first | 新しく追加された | この構成項目は、現在の RocksDB のmemtableのメモリ使用量がしきい値に達したときに使用されるフラッシュ戦略を指定します。 |
| TiKV | rocksdb.write-buffer-limit | 新たに追加されました | この構成項目は、単一の TiKV 内のすべての RocksDB インスタンスのmemtableによって使用される合計メモリの制限を指定します。デフォルト値は、マシンの合計メモリの 25% です。 |
| PD | pd-server.enable-gogc-tuner | 新しく追加された | この設定項目は、デフォルトでは無効になっている GOGC チューナーを有効にするかどうかを制御します。 |
| PD | pd-server.gc-tuner-threshold | 新しく追加された | この構成項目は、GOGC をチューニングするための最大メモリしきい値比率を指定します。デフォルト値は0.6です。 |
| PD | pd-server.server-memory-limit-gc-trigger | 新しく追加された | この設定項目は、PD が GC をトリガーしようとするしきい値比率を指定します。デフォルト値は0.7です。 |
| PD | pd-server.server-memory-limit | 新しく追加された | この設定項目は、PD インスタンスのメモリ制限率を指定します。値0はメモリ制限がないことを意味します。 |
| TiCDC | scheduler.region-per-span | 新しく追加された | この構成項目は、リージョンの数に基づいてテーブルを複数のレプリケーション範囲に分割するかどうかを制御します。これらの範囲は複数の TiCDC ノードによってレプリケートできます。デフォルト値は50000です。 |
| TiDB Lightning | compress-kv-pairs | 新しく追加された | この構成項目は、物理インポート モードで KV ペアを TiKV に送信するときに圧縮を有効にするかどうかを制御します。デフォルト値は空で、圧縮が有効になっていないことを意味します。 |
| DM | checksum-physical | 新しく追加された | この構成項目は、DM がインポート後にデータの整合性を検証するためにテーブルごとにADMIN CHECKSUM TABLE <table>を実行するかどうかを制御します。デフォルト値は"required"で、インポート後に管理チェックサムを実行します。チェックサムが失敗した場合、DM はタスクを一時停止するため、失敗を手動で処理する必要があります。 |
| DM | disk-quota-physical | 新しく追加された | この設定項目はディスク クォータを設定します。 TiDB Lightningのdisk-quota構成に相当します。 |
| DM | on-duplicate-logical | 新しく追加された | この構成項目は、DM が論理インポート モードで競合するデータを解決する方法を制御します。デフォルト値は"replace"で、新しいデータを使用して既存のデータを置き換えることを意味します。 |
| DM | on-duplicate-physical | 新しく追加された | この構成項目は、DM が物理インポート モードで競合するデータを解決する方法を制御します。デフォルト値は"none"で、競合するデータを解決しないことを意味します。 "none"のパフォーマンスは最高ですが、ダウンストリーム データベースでデータの不整合が発生する可能性があります。 |
| DM | sorting-dir-physical | 新しく追加された | この設定項目は、物理インポート モードでのローカル KV ソートに使用されるディレクトリを指定します。デフォルト値はdirの構成と同じです。 |
| 同期差分インスペクター | skip-non-existing-table | 新たに追加されました | この構成項目は、ダウンストリームのテーブルがアップストリームに存在しない場合に、アップストリームとダウンストリームのデータ整合性のチェックをスキップするかどうかを制御します。 |
| ティスパーク | spark.tispark.replica_read | 新しく追加された | この構成項目は、読み取るレプリカのタイプを制御します。値のオプションはleader 、 follower 、およびlearnerです。 |
| ティスパーク | spark.tispark.replica_read.label | 新しく追加された | この構成アイテムは、ターゲット TiKV ノードのラベルを設定するために使用されます。 |
その他
- 動的変更のサポート
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 @ Cbcウェストウルフのデフォルト値として
CURDATE()の使用をサポート partial order prop push downは LIST タイプのパーティションテーブル#40273 @ ウィノロスをサポートするようになりました。- オプティマイザーのヒントと実行プランのバインディング間の競合に関するエラー メッセージを追加#40910 @ 懐かしい
- 一部のシナリオでプラン キャッシュを使用する場合、最適でないプランを回避するためにプラン キャッシュ戦略を最適化します#40312 #40218 #40280 #41136 #40686 @ qw4990
- 期限切れの領域キャッシュを定期的にクリアして、メモリリークとパフォーマンスの低下を回避します#40461 @ スティックナーフ
MODIFY COLUMNはパーティションテーブル#39915 @ wjhuang2016ではサポートされません- パーティションテーブルが依存する列の名前変更を無効にする#40150 @ むじょん
- パーティションテーブルテーブルが依存する列が削除されたときに報告されるエラー メッセージを調整します#38739 @ ジフフスト
FLASHBACK CLUSTERチェックに失敗した場合にリトライする仕組みを追加min-resolved-ts#39836 @ 定義2014
TiKV
- Partitioned-raft-kv モードの一部のパラメーターのデフォルト値を最適化します。TiKV 構成項目
storage.block-cache.capacityのデフォルト値は 45% から 30% に調整され、デフォルト値region-split-sizeは96MiBから10GiBに調整されます。 raft-kv モードを使用し、enable-region-buckettrueである場合、デフォルトではregion-split-size1 GiB に調整されます。 #12842 @ トニーシュクキ - Raftstoreの非同期書き込み#13730 @ コナー1996での優先スケジューリングのサポート
- 1 コア未満の CPU での TiKV の起動をサポート#13586 #13752 #14017 @ アンドロイドデータベース
- Raftstore の遅いスコアの新しい検出メカニズムを最適化し、
evict-slow-trend-scheduler#14131 @ インナーを追加します - RocksDB のブロックキャッシュを強制的に共有し、CF #12936 @ ビジージェイに従ってブロックキャッシュを個別に設定することはサポートされなくなりました。
- Partitioned-raft-kv モードの一部のパラメーターのデフォルト値を最適化します。TiKV 構成項目
PD
TiFlash
ツール
バックアップと復元 (BR)
TiCDC
- バッチ
UPDATEDML ステートメントをサポートして、TiCDC レプリケーションのパフォーマンス#8084 @ 咸陽飛を向上させます。 - MQ シンクと MySQL シンクを非同期モードで実装して、シンクのスループットを向上させます#5928 @ ひっくり返る @ こんにちはラスティン
- バッチ
TiDB データ移行 (DM)
DM アラート ルールとコンテンツの最適化#7376 @ D3ハンター
以前は、関連エラーが発生するたびに、「DM_XXX_process_exits_with_error」のようなアラートが生成されていました。ただし、一部のアラートはアイドル状態のデータベース接続によって発生し、再接続後に回復できます。このような種類のアラートを減らすために、DM はエラーを 2 つのタイプ (自動的に回復可能なエラーと回復不可能なエラー) に分類します。
- 自動的に回復可能なエラーの場合、DM はエラーが 2 分以内に 3 回以上発生した場合にのみアラートを報告します。
- 自動的に回復できないエラーの場合、DM は元の動作を維持し、すぐにアラートを報告します。
TiDB Lightning
Dumpling
同期差分インスペクター
バグの修正
TiDB
- 不正な
datetime値#39336 @ シュイファングリーンアイズが原因で統計収集タスクが失敗する問題を修正します。 - テーブル作成#38189 @ シュイファングリーンアイズの後に
stats_metaが作成されない問題を修正 - DDL データ バックフィル#24427 @ むじょんを実行するときにトランザクションで頻繁に発生する書き込み競合を修正しました。
- インジェスト モード#39641 @ タンジェンタを使用して空のテーブルにインデックスを作成できない場合がある問題を修正
- スロークエリログの
wait_ts同じトランザクション#39713 @ トンスネークリン内の異なる SQL ステートメントで同じであるという問題を修正します。 - 行レコード#39570 @ wjhuang2016の削除プロセス中に列を追加すると、
Assertion Failedエラーが報告される問題を修正します。 - 列タイプ#39643 @ ジムララを変更すると
not a DDL ownerエラーが報告される問題を修正 AUTO_INCREMENT列#38950 @ ドゥーシール9の自動インクリメント値を使い果たした後に行を挿入するときにエラーが報告されない問題を修正します。- 式インデックス#39784 @ 定義2014を作成するときに
Unknown columnエラーが報告される問題を修正 - 生成された式にこのテーブル#39826 @ 定義2014の名前が含まれている場合、名前を変更したテーブルにデータを挿入できない問題を修正します。
- 列が書き込み専用#40192 @ ヤンケオの場合、
INSERT ignoreステートメントでデフォルト値を入力できない問題を修正します。 - リソース管理モジュール#40546 @ ジムララを無効にするとリソースが解放されない問題を修正
- TTL タスクが時間#40109 @ ヤンケオで統計更新をトリガーできない問題を修正
- キー範囲#40158 @ ティエンチャイアマオを構築するときに TiDB が
NULL値を適切に処理しないため、予期しないデータが読み取られる問題を修正 MODIFT COLUMNステートメントが列#40164 @ wjhuang2016のデフォルト値も変更する場合、不正な値がテーブルに書き込まれる問題を修正します。- テーブル#38436 @ タンジェンタに多数のリージョンがある場合、無効なリージョンキャッシュによりインデックスの追加操作が非効率になる問題を修正
- 自動インクリメント ID #40584 @ ドゥーシール9の割り当て時に発生したデータ競合を修正しました。
- JSON での not 演算子の実装が MySQL #40683 @ ヤンケオでの実装と互換性がないという問題を修正
- 同時ビューにより DDL 操作がブロックされる可能性がある問題を修正#40352 @ 沢民州
- パーティション テーブル#40620 @ むじょん @ むじょんの列を変更する DDL ステートメントを同時に実行することによって発生するデータの不整合を修正しました。
- パスワードを指定せずに認証に
caching_sha2_password使用すると、「不正なパケット」が報告される問題を修正#40831 @ ドヴィーデン - テーブルの主キーに
ENUMカラム#40456 @ ルクワンチャオが含まれる場合、TTL タスクが失敗する問題を修正します。 - MDL によってブロックされた一部の DDL 操作が
mysql.tidb_mdl_view#40838 @ ヤンケオでクエリできない問題を修正します。 - DDL 取り込み#40970 @ タンジェンタ中にデータ競合が発生する可能性がある問題を修正
- タイムゾーンが変更された後、TTL タスクが一部のデータを誤って削除する可能性がある問題を修正#41043 @ ルクワンチャオ
JSON_OBJECTが場合によってはエラーを報告する場合がある問題を修正#39806 @ ヤンケオ- TiDB が初期化#40408 @ 定義2014中にデッドロックする可能性がある問題を修正
- メモリの再利用によりシステム変数の値が誤って変更される場合がある問題を修正#40979 @ ルクワンチャオ
- インジェストモード#40464 @ タンジェンタで一意のインデックスを作成すると、データがインデックスと不整合になる可能性がある問題を修正
- 同じテーブルを同時に切り捨てる場合、一部の切り捨て操作が MDL によってブロックされない問題を修正します#40484 @ wjhuang2016
SHOW PRIVILEGESステートメントが不完全な権限リスト#40591 @ Cbcウェストウルフを返す問題を修正します。- 一意のインデックス#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 @ シュイファングリーンアイズ- IndexMerge オペレーターがメモリ制限動作をトリガーしたときの TiDBサーバーのpanicを修正しました#41036 @ グオシャオゲ
- パーティションテーブルに対する
SELECT * FROM table_name LIMIT 1クエリが遅い#40741 @ ソロッツグという問題を修正
- 不正な
TiKV
PD
TiFlash
ツール
バックアップと復元 (BR)
- ログ バックアップを復元するときに、ホット リージョンにより復元が失敗する問題を修正します#37207 @ レヴルス
- ログ バックアップが実行されているクラスターにデータを復元すると、ログ バックアップ ファイルが回復不能になる問題を修正します#40797 @ レヴルス
- PITR 機能が CA バンドル#38775 @ ユジュンセンをサポートしない問題を修正
- リカバリ#40797 @ ジョッカウ中に一時テーブルの重複によって引き起こされるpanicの問題を修正
- PITR が PD クラスター#14165 @ ユジュンセンの構成変更をサポートしていない問題を修正
- PD と tidb-server の間の接続障害により、PITR バックアップの進行状況が#41082 @ ユジュンセン進まない問題を修正
- PD と TiKV #14159 @ ユジュンセン間の接続障害により、TiKV が PITR タスクをリッスンできない問題を修正
- TiDB クラスター#40759 @ ジョッカウに PITR バックアップ タスクがない場合、
resolve lockの頻度が高すぎる問題を修正 - PITR バックアップ タスクが削除されると、残ったバックアップ データにより新しいタスク#40403 @ ジョッカウでデータの不整合が発生する問題を修正します。
TiCDC
- 設定ファイル#7935 @ CharlesCheung96から
transaction_atomicityとprotocolを更新できない問題を修正 - REDOログ#6335 @ CharlesCheung96のstorageパスで事前チェックが行われない問題を修正
- S3storage障害#8089 @ CharlesCheung96に対して REDO ログが許容できる期間が不十分である問題を修正
- TiKV または TiCDC ノード#8174 @ ひっくり返るをスケールインまたはスケールアウトするときなど、特殊なシナリオで変更フィードが停止する可能性がある問題を修正します。
- TiKV ノード#14092 @ オーバーヴィーナス間のトラフィックが高すぎる問題を修正
- プルベースのシンクが有効になっている場合の、CPU 使用率、メモリ制御、およびスループットに関する TiCDC のパフォーマンスの問題を修正します#8157 #8142 #8001 #5928 ひっくり返る @ こんにちはラスティン
- 設定ファイル#7935 @ CharlesCheung96から
TiDB データ移行 (DM)
binlog-schema deleteコマンドの実行に失敗する問題を修正#7373 @ リウメンギャ94- 最後のbinlogがスキップされた DDL #8175 @ D3ハンターである場合、チェックポイントが進められない問題を修正します。
- 1つのテーブルに「更新」タイプと「非更新」タイプの両方の式フィルタを指定した場合、
UPDATEステートメントがすべてスキップされるバグを修正#7831 @ ランス6716 - テーブルに
update-old-value-exprまたはupdate-new-value-exprのいずれか 1 つだけが設定されている場合、フィルター ルールが有効にならない、または DM パニック#7774 @ ランス6716が発生するバグを修正
TiDB Lightning
- 一部のシナリオ#33714 @ リチュンジュで TiDB の再起動が原因でTiDB Lightningタイムアウトがハングする問題を修正
- 並列インポート#40923 @ リチュンジュ中に、最後の TiDB Lightning インスタンスを除くすべてのTiDB Lightningインスタンスでローカルの重複レコードが検出された場合、 TiDB Lightning が誤って競合解決をスキップする可能性がある問題を修正します。
- 事前チェックがターゲット クラスター#41040 @ ランス6716で実行中の TiCDC の存在を正確に検出できない問題を修正します。
- TiDB Lightning が分割リージョン フェーズ#40934 @ ランス6716でパニックになる問題を修正
- 競合解決ロジック (
duplicate-resolution) によってチェックサムの不一致が生じる可能性がある問題を修正します#40657 @ 眠いもぐら - データ ファイル#40400 @ ブチュイトデゴウに閉じられていない区切り文字がある場合に発生する可能性がある OOM の問題を修正します。
- エラーレポートのファイルオフセットがファイルサイズ#40034 @ ブチュイトデゴウを超える問題を修正
- PDClient の新しいバージョンで、並列インポートが失敗する可能性がある問題を修正します#40493 @ アメーバ原生動物
- TiDB Lightning事前チェックが、以前に失敗したインポート#39477 @ dsダシュンによって残されたダーティ データを見つけられない問題を修正
貢献者
TiDB コミュニティの以下の貢献者に感謝いたします。