TiDB 6.4.0 リリースノート
発売日: 2022年11月17日
TiDB バージョン: 6.4.0-DMR
注記：
TiDB 6.4.0-DMR のドキュメントはアーカイブ済みになりました。PingCAP では、TiDB データベースの最新のLTSバージョンを使用することを推奨しています。
クイックアクセス: クイックスタート
v6.4.0-DMR の主な新機能と改善点は次のとおりです。
FLASHBACK CLUSTER TO TIMESTAMP(実験的) を使用して、クラスターを特定の時点に復元することをサポートします。- TiDB インスタンスグローバルメモリ使用量の追跡をサポートします (実験的)。
- 線形ハッシュ分割構文と互換性があること。
- 高性能かつ全体的に単調な
AUTO_INCREMENT(実験的) をサポートします。 - JSON型配列データの範囲選択をサポートします。
- ディスク障害やスタックした I/O などの極端な状況での障害回復を高速化します。
- テーブルの結合順序を決定するには動的計画アルゴリズム追加します。
- 相関サブクエリに対して非相関化を実行するかどうかを制御するには新しいオプティマイザヒント
NO_DECORRELATE導入します。 - クラスター診断機能はGAになります。
- TiFlash は保存時の暗号化の SM4 アルゴリズムをサポートします。
- テーブル内の指定されたパーティションのTiFlashレプリカをすぐに圧縮しますへの SQL ステートメントの使用をサポートします。
- サポートEBS ボリューム スナップショットを使用して TiDB クラスターをバックアップする 。
- DM は上流のデータソース情報を下流のマージされたテーブルの拡張列に書き込むサポートします。
新機能
構文
SQL ステートメントを使用して、テーブル内の指定されたパーティションのTiFlashレプリカをすぐに圧縮する機能をサポート＃5315 @ ヘヘチェン
v6.2.0 以降、TiDB はTiFlashのフルテーブルレプリカで物理データを即座に圧縮するの機能をサポートしています。適切なタイミングで SQL 文を手動で実行してTiFlash内の物理データを即時に圧縮できるため、storageスペースの削減とクエリパフォーマンスの向上に役立ちます。v6.4.0 では、圧縮するTiFlashレプリカデータの粒度を改良し、テーブル内の指定されたパーティションのTiFlashレプリカを即時に圧縮することをサポートします。
SQL ステートメント
ALTER TABLE table_name COMPACT [PARTITION PartitionNameList] [engine_type REPLICA]を実行すると、テーブル内の指定されたパーティションのTiFlashレプリカをすぐに圧縮できます。詳細についてはユーザードキュメント参照してください。
FLASHBACK CLUSTER TO TIMESTAMP(実験的) ＃37197 ＃13303 @ 定義2014 @ bb7133 @ じゃがいも @ コナー1996 @ ヒューシャープ @ カルビンネオを使用して、クラスターを特定の時点に復元する機能をサポートします。FLASHBACK CLUSTER TO TIMESTAMP構文を使用すると、ガベージ コレクション (GC) の有効期間内にクラスターを特定の時点にすばやく復元できます。この機能を使用すると、DML の誤った操作を簡単かつ迅速に元に戻すことができます。たとえば、この構文を使用すると、誤ってWHERE句なしでDELETEを実行した後、数分で元のクラスターを復元できます。この機能はデータベース バックアップに依存せず、データが変更された正確な時間を特定するために、さまざまな時点でデータをロールバックすることをサポートしますFLASHBACK CLUSTER TO TIMESTAMPデータベース バックアップを置き換えることはできないことに注意してください。FLASHBACK CLUSTER TO TIMESTAMPを実行する前に、TiCDC などのツールで実行されている PITR およびレプリケーション タスクを一時停止し、FLASHBACKの完了後に再起動する必要があります。そうしないと、レプリケーション タスクが失敗する可能性があります。詳細についてはユーザードキュメント参照してください。
FLASHBACK DATABASE＃20463 @ エルワドバを使用して削除されたデータベースの復元をサポートしますFLASHBACK DATABASE使用すると、ガベージコレクション(GC) の有効期間内にDROPによって削除されたデータベースとそのデータを復元できます。この機能は外部ツールに依存しません。SQL ステートメントを使用してデータとメタデータをすばやく復元できます。詳細についてはユーザードキュメント参照してください。
Security
TiFlashは保存時の暗号化にSM4アルゴリズムをサポートしています＃5953 @ リデズ
保存時のTiFlash暗号化に SM4 アルゴリズムを追加します。保存時の暗号化を構成する場合、
tiflash-learner.toml構成ファイルでdata-encryption-method構成の値をsm4-ctrに設定することで、SM4 暗号化機能を有効にすることができます。詳細についてはユーザードキュメント参照してください。
可観測性
クラスタ診断は GA ＃1438 @ ホークソンジーになります
TiDB ダッシュボードのクラスター診断機能は、指定された時間範囲内でクラスターに存在する可能性のある問題を診断し、診断結果とクラスター関連の負荷監視情報を診断レポートにまとめます。この診断レポートは Web ページの形式です。ブラウザーからページを保存した後、オフラインでページを参照したり、このページのリンクを循環させたりすることができます。
診断レポートを使用すると、負荷、コンポーネントの状態、時間消費、構成など、クラスターの基本的な健全性情報をすばやく把握できます。クラスターに一般的な問題がある場合は、セクション診断情報に組み込まれている自動診断の結果で原因を見つけることができます。
パフォーマンス
コプロセッサタスク＃37724 @ あなた06の並行適応メカニズムを導入する
コプロセッサ タスクの数が増えると、TiKV の処理速度に基づいて、TiDB は自動的に同時実行性を高め (
tidb_distsql_scan_concurrencyの値を調整)、コプロセッサ タスク キューを減らしてレイテンシーを減らします。テーブル結合順序を決定するための動的計画アルゴリズムを追加する＃37825 @ ウィノロス
以前のバージョンでは、TiDB は貪欲アルゴリズムを使用してテーブルの結合順序を決定します。v6.4.0 では、TiDB オプティマイザーに動的計画アルゴリズム導入されています。動的計画アルゴリズムは貪欲アルゴリズムよりも多くの可能な結合順序を列挙できるため、より適切な実行プランが見つかる可能性が高まり、一部のシナリオでは SQL 実行効率が向上します。
動的プログラミング アルゴリズムはより多くの時間を消費するため、TiDB 結合したテーブルの再配置アルゴリズムの選択は
tidb_opt_join_reorder_threshold変数によって制御されます。Join 結合したテーブルの再配置に参加するノードの数がこのしきい値より大きい場合、TiDB は貪欲アルゴリズムを使用します。それ以外の場合、TiDB は動的プログラミング アルゴリズムを使用します。詳細についてはユーザードキュメント参照してください。
プレフィックスインデックスは null 値のフィルタリングをサポートします＃21145 @ 翻訳者
この機能はプレフィックス インデックスの最適化です。テーブル内の列にプレフィックス インデックスがある場合、SQL ステートメント内の列の
IS NULLまたはIS NOT NULL条件をプレフィックスで直接フィルター処理できます。これにより、この場合のテーブル検索が回避され、SQL 実行のパフォーマンスが向上します。詳細についてはユーザードキュメント参照してください。
TiDB チャンク再利用メカニズム＃38606 @ 学習を続ける20221を強化する
以前のバージョンでは、TiDB は
writechunk関数でのみチャンクを再利用していました。TiDB v6.4.0 では、チャンク再利用メカニズムが Executor の演算子に拡張されています。チャンクを再利用することで、TiDB は頻繁にメモリ解放を要求する必要がなくなり、一部のシナリオでは SQL クエリがより効率的に実行されます。システム変数tidb_enable_reuse_chunkを使用して、チャンク オブジェクトを再利用するかどうかを制御できます。これはデフォルトで有効になっています。詳細についてはユーザードキュメント参照してください。
相関サブクエリ＃37789 @ 時間と運命の相関解除を実行するかどうかを制御する新しいオプティマイザヒント
NO_DECORRELATEを導入します。デフォルトでは、TiDB は常に相関サブクエリを書き換えて非相関化を実行しようとします。これにより、通常は実行効率が向上します。ただし、シナリオによっては、非相関化によって実行効率が低下することがあります。v6.4.0 では、TiDB はオプティマイザー ヒント
NO_DECORRELATEを導入し、指定されたクエリ ブロックに対して非相関化を実行しないようにオプティマイザーに指示して、一部のシナリオでクエリ パフォーマンスを向上させます。詳細についてはユーザードキュメント参照してください。
パーティション化されたテーブル＃37977 @ イサールでの統計収集のパフォーマンスを向上
v6.4.0 では、TiDB はパーティション化されたテーブルでの統計収集戦略を最適化します。システム変数
tidb_auto_analyze_partition_batch_sizeを使用して、パーティション化されたテーブルでの統計収集の同時実行性を並列に設定し、収集を高速化し、分析時間を短縮できます。
安定性
ディスク障害やスタックI/O ＃13648 @ リクササシネーターなどの極端な状況での障害回復を高速化
エンタープライズ ユーザーにとって、データベースの可用性は最も重要な指標の 1 つです。複雑なハードウェア環境では、障害を迅速に検出して回復する方法が常にデータベースの可用性の課題の 1 つとなっています。v6.4.0 では、TiDB は TiKV ノードの状態検出メカニズムを完全に最適化しています。ディスク障害や I/O スタックなどの極端な状況でも、TiDB はノードの状態を迅速に報告し、アクティブ ウェイクアップ メカニズムを使用して事前にLeader選出を開始することで、クラスターの自己修復を加速します。この最適化により、TiDB はディスク障害が発生した場合のクラスターの回復時間を約 50% 短縮できます。
TiDBメモリ使用量のグローバル制御＃37816 @ うわー
v6.4.0 では、TiDB インスタンスのグローバルメモリ使用量を追跡する実験的機能として、メモリ使用量のグローバル制御が導入されています。システム変数
tidb_server_memory_limitを使用して、グローバルメモリ使用量の上限を設定できます。メモリ使用量がしきい値に達すると、TiDB は空きメモリを再利用して解放しようとします。メモリ使用量がしきい値を超えると、TiDB はメモリ使用量が最も高い SQL 操作を識別してキャンセルし、過剰なメモリ使用量によるシステムの問題を回避します。TiDB インスタンスのメモリ消費に潜在的なリスクがある場合、TiDB は事前に診断情報を収集し、指定されたディレクトリに書き込み、問題の診断を容易にします。同時に、TiDB はメモリ使用量と操作履歴を表示するシステム テーブル ビュー
INFORMATION_SCHEMA.MEMORY_USAGEとINFORMATION_SCHEMA.MEMORY_USAGE_OPS_HISTORYを提供し、メモリ使用量をよりよく理解するのに役立ちます。グローバルメモリ制御は、TiDBメモリ管理におけるマイルストーンです。インスタンスのグローバル ビューを導入し、メモリの体系的な管理を採用することで、より多くの重要なシナリオでデータベースの安定性とサービスの可用性を大幅に向上できます。
詳細についてはユーザードキュメント参照してください。
範囲構築オプティマイザのメモリ使用量を制御する＃37176 @ 翻訳者
v6.4.0 では、範囲を構築するオプティマイザの最大メモリ使用量を制限するために、システム変数
tidb_opt_range_max_sizeが導入されました。メモリ使用量が制限を超えると、オプティマイザは、より正確な範囲ではなく、より粗い範囲を構築して、メモリ消費を削減します。SQL ステートメントにIN条件が多数ある場合、この最適化により、コンパイルのメモリ使用量が大幅に削減され、システムの安定性が確保されます。詳細についてはユーザードキュメント参照してください。
統計情報の同期読み込みをサポート (GA) ＃37434 @ クリサン
TiDB v6.4.0 では、統計の同期ロード機能がデフォルトで有効になっています。この機能により、SQL ステートメントを実行するときに、TiDB は大規模な統計 (ヒストグラム、TopN、Count-Min Sketch 統計など) をメモリに同期的にロードできるため、SQL 最適化の統計の完全性が向上します。
詳細についてはユーザードキュメント参照してください。
軽量トランザクション書き込みの応答時間に対するバッチ書き込み要求の影響を軽減する＃13313 @ 栄光
一部のシステムのビジネス ロジックでは、定期的なバッチ DML タスクが必要ですが、これらのバッチ書き込みタスクを処理すると、オンライン トランザクションのレイテンシーが長くなります。v6.3.0 では、TiKV はハイブリッド ワークロード シナリオでの読み取り要求のスケジュールを最適化するため、
readpool.unified.auto-adjust-pool-size構成項目を有効にすると、TiKV がすべての読み取り要求の UnifyReadPool スレッド プールのサイズを自動的に調整できるようになります。v6.4.0 では、TiKV は書き込み要求を動的に識別して優先順位を付けることもでき、1 回のポーリングで 1 つの FSM (有限状態マシン) に適用スレッドが書き込むことができる最大バイト数を制御できるため、バッチ書き込み要求がトランザクション書き込みの応答時間に与える影響が軽減されます。
使いやすさ
TiKV API V2 が一般提供開始 (GA) ＃11745 @ ピンギュ
v6.1.0 より前の TiKV では、クライアントから渡された生データのみを保存するため、基本的なキー値の読み取りおよび書き込み機能のみが提供されます。さらに、コーディング方法の違いと範囲指定されていないデータ範囲のため、TiDB、トランザクション KV、および RawKV を同じ TiKV クラスターで同時に使用することはできません。代わりに、この場合は複数のクラスターが必要になり、マシンと展開のコストが増加します。
TiKV API V2 は、新しい RawKVstorage形式とアクセス インターフェイスを提供し、次のような利点をもたらします。
- 記録されたデータの変更タイムスタンプとともに MVCC にデータを保存し、それに基づいて変更データ キャプチャ (CDC) を実装します。この機能は実験的であり、 ティKV-CDCで詳しく説明されています。
- データはさまざまな用途に応じてスコープ設定され、API V2 は単一クラスター内での TiDB、トランザクション KV、および RawKV アプリケーションの共存をサポートします。
- マルチテナントなどの機能をサポートするために、キー スペース フィールドを予約します。
TiKV API V2 を有効にするには、TiKV 構成ファイルの
[storage]セクションでapi-version = 2設定します。詳細についてはユーザードキュメント参照してください。
TiFlashデータ複製の進行状況＃4902 @ ヘヘチェンの精度を向上
TiDB では、
INFORMATION_SCHEMA.TIFLASH_REPLICAテーブルのPROGRESSフィールドは、TiKV の対応するテーブルからTiFlashレプリカへのデータ複製の進行状況を示すために使用されます。以前のバージョンの TiDB では、PROCESSフィールドはTiFlashレプリカの作成中のTiFlash複製の進行状況のみを示します。TiFlash レプリカの作成後、新しいデータが TiKV の対応するテーブルにインポートされた場合、このフィールドは更新されず、新しいデータの TiKV からTiFlashへの複製の進行状況は表示されません。v6.4.0 では、TiDB はTiFlashレプリカのデータ レプリケーションの進行状況の更新メカニズムを改善しました。TiFlash レプリカの作成後、新しいデータが TiKV の対応するテーブルにインポートされると、
INFORMATION_SCHEMA.TIFLASH_REPLICAテーブルのPROGRESSTiFlashが更新され、新しいデータの TiKV からTiFlashへの実際のレプリケーションの進行状況が表示されます。この改善により、 TiFlashデータ レプリケーションの実際の進行状況を簡単に確認できます。詳細についてはユーザードキュメント参照してください。
MySQL 互換性
線形ハッシュパーティション構文＃38450 @ ミョンスと互換性がある
以前のバージョンでは、TiDB はハッシュ、範囲、およびList パーティショニングをサポートしていました。v6.4.0 以降では、TiDB はMySQL リニアハッシュパーティショニングの構文とも互換性があります。
TiDB では、MySQL リニア ハッシュ パーティションの既存の DDL ステートメントを直接実行でき、TiDB は対応するハッシュ パーティション テーブルを作成します (TiDB 内にはリニア ハッシュ パーティションがないことに注意してください)。また、MySQL リニア ハッシュ パーティションの既存の DML ステートメントを直接実行することもできます。TiDB は対応する TiDB ハッシュ パーティションのクエリ結果を通常どおり返します。この機能により、MySQL リニア ハッシュ パーティションとの TiDB 構文の互換性が確保され、MySQL ベースのアプリケーションから TiDB へのシームレスな移行が容易になります。
パーティション数が 2 の累乗の場合、TiDB ハッシュパーティションテーブルの行は、MySQL リニア ハッシュパーティションテーブルの行と同じように分散されます。それ以外の場合、TiDB でのこれらの行の分散は、MySQL とは異なります。
詳細についてはユーザードキュメント参照してください。
高性能かつ全体的に単調な
AUTO_INCREMENT(実験的) ＃38442 @ 天菜まおをサポートするTiDB v6.4.0 では、
AUTO_INCREMENTMySQL 互換モードが導入されています。このモードでは、すべての TiDB インスタンスで ID が単調に増加するようにする集中型の自動増分 ID 割り当てサービスが導入されています。この機能により、自動増分 ID によるクエリ結果の並べ替えが容易になります。MySQL 互換モードを使用するには、テーブルの作成時にAUTO_ID_CACHEから1に設定する必要があります。次に例を示します。CREATE TABLE t (a INT AUTO_INCREMENT PRIMARY KEY) AUTO_ID_CACHE = 1;詳細についてはユーザードキュメント参照してください。
JSON型＃13644 @ ヤンケオの配列データの範囲選択をサポート
v6.4.0 以降では、TiDB で MySQL 互換範囲選択構文使用できます。
キーワード
toを使用すると、配列要素の開始位置と終了位置を指定し、配列内の連続した範囲の要素を選択できます。0を使用すると、配列の最初の要素の位置を指定できます。 たとえば、$[0 to 2]を使用すると、配列の最初の 3 つの要素を選択できます。キーワード
lastを使用すると、配列の最後の要素の位置を指定できます。これにより、右から左への位置を設定できます。たとえば、$[last-2 to last]使用すると、配列の最後の 3 つの要素を選択できます。
この機能により、SQL ステートメントの記述プロセスが簡素化され、JSON 型の互換性がさらに向上し、MySQL アプリケーションを TiDB に移行する際の難易度が軽減されます。
データベースユーザー＃38172 @ Cbcウェストウルフの追加説明の追加をサポート
TiDB v6.4 では、
CREATE USERまたはALTER USER使用して、データベース ユーザー向けの追加の説明を追加できます。TiDB には 2 つの説明形式があります。COMMENTを使用してテキスト コメントを追加し、ATTRIBUTEを使用して JSON 形式の構造化属性のセットを追加できます。さらに、TiDB v6.4.0 では、ユーザーコメントとユーザー属性の情報を表示できる
USER_ATTRIBUTESテーブルが追加されました。CREATE USER 'newuser1'@'%' COMMENT 'This user is created only for test'; CREATE USER 'newuser2'@'%' ATTRIBUTE '{"email": "user@pingcap.com"}'; SELECT * FROM INFORMATION_SCHEMA.USER_ATTRIBUTES;+-----------+------+---------------------------------------------------+ | USER | HOST | ATTRIBUTE | +-----------+------+---------------------------------------------------+ | newuser1 | % | {"comment": "This user is created only for test"} | | newuser1 | % | {"email": "user@pingcap.com"} | +-----------+------+---------------------------------------------------+ 2 rows in set (0.00 sec)この機能により、TiDB と MySQL 構文の互換性が向上し、MySQL エコシステム内のツールやプラットフォームへの TiDB の統合が容易になります。
バックアップと復元
EBS ボリューム スナップショット＃33849 @ フェンゴウ1を使用して TiDB クラスターのバックアップをサポート
TiDB クラスターが EKS にデプロイされ、AWS EBS ボリュームを使用しており、TiDB クラスター データをバックアップする際に次の要件がある場合は、 TiDB Operator を使用してボリューム スナップショットとメタデータごとにデータを AWS S3 にバックアップできます。
- バックアップの影響を最小限に抑えます。たとえば、QPS とトランザクションのレイテンシーへの影響を 5% 未満に抑え、クラスターの CPU とメモリを占有しないようにします。
- 短時間でデータをバックアップおよび復元します。たとえば、1 時間以内にバックアップを完了し、2 時間以内にデータを復元します。
詳細についてはユーザードキュメント参照してください。
データ移行
DMは、下流のマージされたテーブル＃37797 @ リチュンジュの拡張列への上流データソース情報の書き込みをサポートします。
上流から TiDB にシャードされたスキーマとテーブルをマージする場合、ターゲット テーブルに複数のフィールド (拡張列) を手動で追加し、DM タスクを構成するときにその値を指定できます。たとえば、拡張列に上流のシャードされたスキーマとテーブルの名前を指定すると、DM によって下流に書き込まれるデータにはスキーマ名とテーブル名が含まれます。下流のデータが異常な場合、この機能を使用して、スキーマ名やテーブル名などのターゲット テーブルのデータ ソース情報をすばやく見つけることができます。
詳細についてはテーブル、スキーマ、ソース情報を抽出し、マージされたテーブルに書き込みます。参照してください。
DMは、いくつかの必須チェック項目をオプションのチェック項目に変更することで、事前チェックのメカニズムを最適化します＃7333 @ リチュンジュ
データ移行タスクをスムーズに実行するために、DM はタスクの開始時に事前チェック自動的にトリガーし、チェック結果を返します。DM は、事前チェックに合格した後にのみ移行を開始します。
v6.4.0 では、DM は次の 3 つのチェック項目を必須からオプションに変更し、事前チェックの合格率を向上させます。
- アップストリーム テーブルが TiDB と互換性のない文字セットを使用しているかどうかを確認します。
- 上流テーブルに主キー制約または一意キー制約があるかどうかを確認します。
- プライマリ/セカンダリ構成でアップストリーム データベースのデータベース ID
server_idが指定されているかどうかを確認します。
DM は、増分移行タスク＃7393 @ GMHDBJDのオプション パラメータとして、 binlog の位置と GTID の設定をサポートしています。
v6.4.0 以降では、 binlog の位置や GTID を指定せずに直接増分移行を実行できます。DM は、タスク開始後に生成されたbinlogファイルを上流から自動的に取得し、これらの増分データを下流に移行します。これにより、ユーザーは面倒な理解や複雑な設定から解放されます。
詳細についてはDM 高度なタスクコンフィグレーションファイル参照してください。
DM は移行タスク＃7343 @ ok江のステータス インジケーターを追加します
v6.4.0 では、DM は移行タスクのパフォーマンスと進行状況のインジケーターをさらに追加しました。これにより、移行のパフォーマンスと進行状況をより直感的に理解できるようになり、トラブルシューティングの参照としても役立ちます。
- データのインポートとエクスポートのパフォーマンスを示すステータス インジケーター (バイト/秒単位) を追加します。
- ダウンストリーム データベースにデータを書き込むためのパフォーマンス インジケーターの名前を TPS から RPS (行数/秒) に変更します。
- DM 完全移行タスクのデータ エクスポートの進行状況を示す進行状況インジケーターを追加します。
これらの指標の詳細については、 TiDB データ移行におけるクエリタスクステータス参照してください。
TiDBデータ共有サブスクリプション
TiCDCは、
3.2.0バージョン＃7191 @ 3エースショーハンドのKafkaへのデータのレプリケーションをサポートしています。v6.4.0 以降、TiCDC は
3.2.0バージョンのうちKafka へのデータの複製それ以前のバージョンをサポートします。
互換性の変更
システム変数
| 変数名 | タイプを変更 | 説明 |
|---|---|---|
max_execution_time | 修正済み | v6.4.0 より前では、この変数はすべてのタイプのステートメントに適用されます。v6.4.0 以降では、この変数は読み取り専用ステートメントの最大実行時間のみを制御します。 |
tidb_constraint_check_in_place_pessimistic | 修正済み | GLOBAL スコープを削除し、 pessimistic-txn.constraint-check-in-place-pessimistic構成項目を使用してデフォルト値を変更できるようにします。この変数は、TiDB が悲観的トランザクションで一意の制約をチェックするタイミングを制御します。 |
tidb_ddl_flashback_concurrency | 修正済み | v6.4.0 から有効になり、 FLASHBACK CLUSTER TO TIMESTAMPの同時実行を制御します。デフォルト値は64です。 |
tidb_enable_clustered_index | 修正済み | デフォルト値をINT_ONLYからONに変更します。これは、主キーがデフォルトでクラスター化インデックスとして作成されることを意味します。 |
tidb_enable_paging | 修正済み | デフォルト値をOFFからONに変更します。これは、コプロセッサ要求を送信するためのページング方式がデフォルトで使用されることを意味します。 |
tidb_enable_prepared_plan_cache | 修正済み | SESSION スコープを追加します。この変数はプリペアドプランキャッシュを有効にするかどうかを制御します。 |
tidb_memory_usage_alarm_ratio | 修正済み | デフォルト値を0.8から0.7に変更します。この変数は、tidb-serverメモリアラームをトリガーするメモリ使用率を制御します。 |
tidb_opt_agg_push_down | 修正済み | GLOBAL スコープを追加します。この変数は、オプティマイザーが集計関数を Join、Projection、および UnionAll の前の位置にプッシュダウンする最適化操作を実行するかどうかを制御します。 |
tidb_prepared_plan_cache_size | 修正済み | SESSION スコープを追加します。この変数は、セッションでキャッシュできるプランの最大数を制御します。 |
tidb_stats_load_sync_wait | 修正済み | デフォルト値を0から100に変更します。つまり、SQL 実行は、完全な列統計を同期的にロードするために、デフォルトで最大 100 ミリ秒待機できます。 |
tidb_stats_load_pseudo_timeout | 修正済み | デフォルト値をOFFからONに変更します。これは、完全な列統計を同期的にロードするタイムアウトに達した後、SQL 最適化が疑似統計の使用に戻ることを意味します。 |
last_sql_use_alloc | 新しく追加された | 前のステートメントがキャッシュされたチャンク オブジェクト (チャンク割り当て) を使用するかどうかを示します。この変数は読み取り専用で、デフォルト値はOFFです。 |
tidb_auto_analyze_partition_batch_size | 新しく追加された | パーティションテーブルを分析するときに TiDB が自動的に分析する実行できるパーティションの数を指定します (つまり、パーティションテーブルの統計情報を自動的に収集します)。デフォルト値は1です。 |
tidb_enable_external_ts_read | 新しく追加された | TiDB がtidb_external_tsで指定されたタイムスタンプでデータを読み取るかどうかを制御します。デフォルト値はOFFです。 |
tidb_enable_gogc_tuner | 新しく追加された | GOGC チューナーを有効にするかどうかを制御します。デフォルト値はONです。 |
tidb_enable_reuse_chunk | 新しく追加された | TiDB がチャンク オブジェクト キャッシュを有効にするかどうかを制御します。デフォルト値はONです。これは、TiDB がキャッシュされたチャンク オブジェクトを優先して使用し、要求されたオブジェクトがキャッシュにない場合にのみシステムから要求することを意味します。値がOFFの場合、TiDB はシステムからチャンク オブジェクトを直接要求します。 |
tidb_enable_prepared_plan_cache_memory_monitor | 新しく追加された | プリペアドプランキャッシュにキャッシュされた実行プランによって消費されるメモリをカウントするかどうかを制御します。デフォルト値はONです。 |
tidb_external_ts | 新しく追加された | デフォルト値は0です。3 tidb_enable_external_ts_read ON設定すると、TiDB はこの変数で指定されたタイムスタンプでデータを読み取ります。 |
tidb_gogc_tuner_threshold | 新しく追加された | GOGC をチューニングするための最大メモリしきい値を指定します。メモリがこのしきい値を超えると、GOGC チューナーは動作を停止します。デフォルト値は0.6です。 |
tidb_memory_usage_alarm_keep_record_num | 新しく追加された | tidb-server のメモリ使用量がメモリアラームしきい値を超えてアラームをトリガーすると、TiDB はデフォルトで最近の 5 つのアラーム中に生成されたステータス ファイルのみを保持します。この変数を使用してこの数を調整できます。 |
tidb_opt_prefix_index_single_scan | 新しく追加された | 不要なテーブル検索を回避し、クエリのパフォーマンスを向上させるために、TiDB オプティマイザーが一部のフィルター条件をプレフィックス インデックスにプッシュダウンするかどうかを制御します。デフォルト値はONです。 |
tidb_opt_range_max_size | 新しく追加された | オプティマイザがスキャン範囲を構築するためのメモリ使用量の上限を指定します。デフォルト値は67108864 (64 MiB) です。 |
tidb_server_memory_limit | 新しく追加された | スキャン範囲を構築するためのオプティマイザのメモリ使用量の上限を制御します (実験的)。デフォルト値は0で、メモリ制限がないことを意味します。 |
tidb_server_memory_limit_gc_trigger | 新しく追加された | TiDB が GC をトリガーしようとするしきい値を制御します (実験的)。デフォルト値は70%です。 |
tidb_server_memory_limit_sess_min_size | 新しく追加された | メモリ制限を有効にすると、TiDB は現在のインスタンスでメモリ使用量が最も高い SQL ステートメントを終了します。この変数は、終了する SQL ステートメントの最小メモリ使用量を指定します。デフォルト値は134217728 (128 MiB) です。 |
コンフィグレーションファイルのパラメータ
| コンフィグレーションファイル | コンフィグレーションパラメータ | タイプを変更 | 説明 |
|---|---|---|---|
| ティビ | tidb_memory_usage_alarm_ratio | 削除されました | この構成項目は無効になりました。 |
| ティビ | memory-usage-alarm-ratio | 削除されました | システム変数tidb_memory_usage_alarm_ratioに置き換えられます。この構成項目が v6.4.0 より前のバージョンの TiDB で構成されている場合、アップグレード後に有効になりません。 |
| ティビ | pessimistic-txn.constraint-check-in-place-pessimistic | 新しく追加された | システム変数tidb_constraint_check_in_place_pessimisticのデフォルト値を制御します。デフォルト値はtrueです。 |
| ティビ | tidb-max-reuse-chunk | 新しく追加された | チャンク割り当てのキャッシュされたチャンク オブジェクトの最大数を制御します。デフォルト値は64です。 |
| ティビ | tidb-max-reuse-column | 新しく追加された | チャンク割り当てのキャッシュされた列オブジェクトの最大数を制御します。デフォルト値は256です。 |
| ティクヴ | cdc.raw-min-ts-outlier-threshold | 非推奨 | この構成項目は無効になりました。 |
| ティクヴ | causal-ts.alloc-ahead-buffer | 新しく追加された | 事前に割り当てられた TSO キャッシュ サイズ (期間)。デフォルト値は3sです。 |
| ティクヴ | causal-ts.renew-batch-max-size | 新しく追加された | タイムスタンプ要求内の TSO の最大数を制御します。デフォルト値は8192です。 |
| ティクヴ | raftstore.apply-yield-write-size | 新しく追加された | 1 回のポーリングで 1 つの FSM (有限状態マシン) に適用スレッドが書き込むことができる最大バイト数を制御します。デフォルト値は32KiBです。これはソフト制限です。 |
| PD | tso-update-physical-interval | 新しく追加された | v6.4.0 から有効になり、PD が TSO の物理時間を更新する間隔を制御します。デフォルト値は50msです。 |
| TiFlash | data-encryption-method | 修正済み | 新しい値オプションsm4-ctrが導入されました。この構成項目がsm4-ctrに設定されている場合、データは保存される前に SM4 を使用して暗号化されます。 |
| DM | routes.route-rule-1.extract-table | 新しく追加された | オプション。シャーディング シナリオで、シャーディングされたテーブルのソース情報を抽出するために使用します。抽出された情報は、データ ソースを識別するために、ダウンストリームのマージされたテーブルに書き込まれます。このパラメータが設定されている場合は、事前にダウンストリームにマージされたテーブルを手動で作成する必要があります。 |
| DM | routes.route-rule-1.extract-schema | 新しく追加された | オプション。シャーディング シナリオで、シャーディングされたスキーマのソース情報を抽出するために使用します。抽出された情報は、データ ソースを識別するために、ダウンストリームのマージされたテーブルに書き込まれます。このパラメータが設定されている場合は、事前にダウンストリームにマージされたテーブルを手動で作成する必要があります。 |
| DM | routes.route-rule-1.extract-source | 新しく追加された | オプション。シャーディング シナリオでソース インスタンス情報を抽出するために使用します。抽出された情報は、データ ソースを識別するために、ダウンストリームのマージされたテーブルに書き込まれます。このパラメータが設定されている場合は、事前にダウンストリームにマージされたテーブルを手動で作成する必要があります。 |
| ティCDC | transaction-atomicity | 修正済み | デフォルト値をtableからnoneに変更します。この変更により、レプリケーションのレイテンシーと OOM のリスクが軽減されます。さらに、TiCDC は、すべてのトランザクションではなく、いくつかのトランザクション (1 つのトランザクションのサイズが 1024 行を超える) のみを分割するようになりました。 |
その他
- v6.4.0 以降、
mysql.userテーブルにUser_attributesとToken_issuer2 つの新しい列が追加されます。以前の TiDB バージョンのバックアップ データを TiDB v6.4.0 にmysqlスキーマのシステムテーブルを復元するすると、 BR はmysql.userテーブルに対してcolumn count mismatchエラーを報告します。13 スキーマでシステム テーブルを復元しないと、このエラーは報告されませmysql。 - 名前がDumplingエクスポートファイルの形式に一致するが、非圧縮形式で終わるファイル (
test-schema-create.sql.originやtest.table-schema.sql.originなど) については、 TiDB Lightningによる処理方法が変更されました。v6.4.0 より前では、インポートするファイルにこのようなファイルが含まれている場合、 TiDB Lightning はそのようなファイルのインポートをスキップします。v6.4.0 以降では、 TiDB Lightningはそのようなファイルがサポートされていない圧縮形式を使用していると想定するため、インポート タスクは失敗します。 - v6.4.0 以降では、権限
SYSTEM_VARIABLES_ADMINまたはSUPERを持つ changefeed のみが TiCDC Syncpoint 機能を使用できます。
改善点
ティビ
ティクヴ
- 新しい構成項目
apply-yield-write-sizeを追加して、Apply スレッドが 1 回のポーリングで 1 つの有限状態マシンに書き込むことができる最大バイト数を制御し、Apply スレッドが大量のデータを書き込むときにRaftstore の輻輳を緩和します＃13313 @ 栄光 - リーダー転送プロセス中の QPS ジッターを回避するために、リージョンのリーダーを移行する前にエントリ キャッシュをウォームアップします＃13060 @ コスベン
json_constrains演算子をコプロセッサー＃13592 @ 李鎮歓にプッシュダウンするサポート- いくつかのシナリオでフラッシュパフォーマンスを向上させるために、
CausalTsProvider非同期関数を追加します＃13428 @ 沢民州
- 新しい構成項目
PD
TiFlash
ツール
TiDBダッシュボード
バックアップと復元 (BR)
ティCDC
- 交換パーティション DDL ステートメント＃639 @ アズドンメンの複製をサポート
- MQシンクモジュール＃7353 @ ハイラスティンの非バッチ送信パフォーマンスを向上
- テーブルに多数のリージョン＃7078 ＃7281 @ スドジがある場合の TiCDC プラーのパフォーマンスを向上
- 同期ポイントが有効な場合、
tidb_enable_external_ts_read変数を使用して下流 TiDB の履歴データの読み取りをサポートします＃7419 @ アズドンメン - レプリケーションの安定性を向上させるために、トランザクション分割を有効にし、セーフモードをデフォルトで無効にします＃7505 @ アズドンメン
TiDB データ移行 (DM)
TiDB Lightning
バグ修正
ティビ
- 新しいインデックス＃38165 @ タンジェンタを作成した後に発生する可能性のあるインデックスの不整合の問題を修正します
INFORMATION_SCHEMA.TIKV_REGION_STATUSテーブル＃38407 @ Cbcウェストウルフの権限問題を修正mysql.tables_privテーブル＃38293 @ Cbcウェストウルフでgrantorフィールドが欠落している問題を修正- 共通テーブル式の結合結果が間違っている可能性がある問題を修正＃38170 @ 翻訳:
- 共通テーブル式の結合結果が間違っている可能性がある問題を修正＃37928 @ ヤンケオ
- トランザクションリージョン番号監視パネルの情報が正しくない問題を修正＃38139 @ ジャッキー
- システム変数
tidb_constraint_check_in_place_pessimisticが内部トランザクションに影響を与える可能性がある問題を修正しました。変数のスコープは SESSION に変更されました＃38766 @ エキシウム - クエリ内の条件が誤って投影＃35623 @ 思い出させるにプッシュダウンされる問題を修正しました
ANDとORの間違ったisNullRejectedチェック結果が間違ったクエリ結果＃38304 @ イサールを引き起こす問題を修正しました- 外部結合が削除されるときに
ORDER BYinGROUP_CONCATが考慮されず、間違ったクエリ結果＃18216 @ ウィノロスが発生する問題を修正しました。 - 誤ってプッシュダウンされた条件が結合したテーブルの再配置 ＃38736 @ ウィノロスによって破棄されたときに発生する間違ったクエリ結果の問題を修正しました。
ティクヴ
cgroupとmountinfoレコードが複数ある場合に Gitpod で TiDB が起動に失敗する問題を修正＃13660 @ タボキ- TiKV メトリックの誤った表現を修正
tikv_gc_compaction_filtered＃13537 @ 定義2014 - 異常な
delete_files_in_range＃13534 @ タボキによるパフォーマンスの問題を修正 - スナップショット取得中に期限切れのリースが原因で発生する異常なリージョン競合を修正＃13553 @ スペードA-タン
- 最初のバッチで
FLASHBACK失敗したときに発生したエラーを修正＃13672 ＃13704 ＃13723 @ ヒューシャープ
PD
- 不正確なストリームタイムアウトを修正し、リーダーの切り替えを高速化＃5207 @ キャビンフィーバーB
TiFlash
ツール
TiDBダッシュボード
バックアップと復元 (BR)
ティCDC
changefeed queryの結果のうちsasl-passwordがマスクされていない問題を修正＃7182 @ ドヴェーデン- etcd トランザクションでコミットされる操作が多すぎると TiCDC が利用できなくなる問題を修正＃7131 @ アズドンメン
- REDOログが誤って削除される可能性がある問題を修正＃6413 @ アズドンメン
- Kafka Sink V2 ＃7344 @ ハイラスティンでワイド テーブルを複製する際のパフォーマンス低下を修正
- チェックポイント ts が誤って＃7274 @ ハイラスティンに進められる可能性がある問題を修正しました
- マウンタモジュール＃7235 @ ハイラスティンのログレベルが不適切であるためにログが多すぎるという問題を修正しました
- TiCDC クラスターに＃4051 @ アズドンメンという 2 人の所有者が存在する可能性がある問題を修正しました。
TiDB データ移行 (DM)
- DM WebUIが間違った
allow-listパラメータ＃7096 @ ゾウビングウを生成する問題を修正 - DM ワーカーが開始または停止するときに、一定の確率でデータ競合が発生する問題を修正＃6401 @ りゅうめんぎゃ
- DM が
UPDATEまたはDELETEステートメントを複製しても対応する行データが存在しない場合、DM がイベント＃6383 @ GMHDBJDを黙って無視する問題を修正しました。 query-statusコマンド＃7189 @ GMHDBJDを実行した後にsecondsBehindMasterフィールドが表示されない問題を修正しました- チェックポイントを更新すると大規模なトランザクション＃5010 @ ランス6716がトリガーされる可能性がある問題を修正
- フルタスクモードで、タスクが同期ステージに入ってすぐに失敗すると、DM が上流のテーブルスキーマ情報＃7159 @ ランス6716を失う可能性がある問題を修正しました。
- 整合性チェックが有効になっている場合にデッドロックが発生する可能性がある問題を修正＃7241 @ ブチュイトウデゴウ
- タスクの事前チェックに
INFORMATION_SCHEMAテーブル＃7317 @ ランス6716のSELECT権限が必要である問題を修正 - TLS 構成が空の場合にエラーが発生する問題を修正＃7384 @ りゅうめんぎゃ
- DM WebUIが間違った
TiDB Lightning
TiDBDumpling
寄稿者
TiDB コミュニティの以下の貢献者に感謝いたします。