TiDB 6.4.0 リリースノート
発売日：2022年11月17日
TiDBバージョン: 6.4.0-DMR
注記：
TiDB 6.4.0-DMR ドキュメントはアーカイブ済みです。 PingCAP は、TiDB データベースの最新のLTSバージョンを使用することを推奨します。
クイックアクセス: クイックスタート
バージョン6.4.0-DMRの主な新機能と改善点は以下のとおりです。
FLASHBACK CLUSTER TO TIMESTAMP(実験的) を使用して、クラスターを特定の時点に復元することをサポートします。- TiDB インスタンスのグローバルメモリ使用量の追跡をサポートします (実験的)。
- 線形ハッシュのパーティショニング構文と互換性があります。
- 高性能かつグローバルに単調な
AUTO_INCREMENTサポートします (実験的)。 - JSON型の配列データの範囲選択をサポートします。
- ディスク障害やI/Oスタックなどの極端な状況下での障害リカバリを加速します。
- 動的計画アルゴリズムを追加して、テーブルの結合順序を決定します。
- 新しいオプティマイザヒント
NO_DECORRELATEを導入して、相関サブクエリの非相関化を実行するかどうかを制御します。 - クラスター診断機能が GA になります。
- TiFlash は保存時の暗号化のための SM4 アルゴリズムをサポートしています。
- SQL ステートメントを使用してテーブル内の指定されたパーティションのコンパクトなTiFlashレプリカを即座にサポートします。
- EBSボリュームスナップショットを使用したTiDBクラスタのバックアップサポートします。
- DM は上流のデータソース情報を下流のマージ済みテーブルの拡張列に書き込むサポートしています。
新機能
SQL
SQL ステートメントを使用して、テーブル内の指定されたパーティションのTiFlashレプリカをすぐに圧縮するサポート #5315 @hehechen
バージョン6.2.0以降、TiDBはTiFlashのフルテーブルレプリカに対して物理データを即座に圧縮する機能をサポートしています。適切なタイミングでSQLステートメントを手動で実行してTiFlash内の物理データを即座に圧縮することで、storage容量を削減し、クエリパフォーマンスを向上させることができます。バージョン6.4.0では、圧縮するTiFlashレプリカデータの粒度をさらに細かくし、テーブル内の指定されたパーティションのTiFlashレプリカを即座に圧縮できるようにしました。
SQL ステートメント
ALTER TABLE table_name COMPACT [PARTITION PartitionNameList] [engine_type REPLICA]を実行すると、テーブル内の指定されたパーティションのTiFlashレプリカを即座に圧縮できます。詳細については、 ユーザー向けドキュメントを参照してください。
FLASHBACK CLUSTER TO TIMESTAMPを使用した特定の時点へのクラスターの復元のサポート (実験的) #37197 #13303 @Defined2014 @bb7133 @JmPotato @Connor1996 @HuSharp @CalvinNeoFLASHBACK CLUSTER TO TIMESTAMP構文を使用すると、ガベージコレクション（GC）の有効期間内に、クラスタを特定の時点に迅速に復元できます。この機能は、DML操作の誤りを簡単かつ迅速に取り消すのに役立ちます。たとえば、{{B-PLACEHOLDER-2-PLACEHOLDER-E}WHERE句なしで誤ってDELETEを実行した後、この構文を使用して数分で元のクラスタを復元できます。この機能はデータベースのバックアップに依存せず、異なる時点のデータをロールバックして、データが変更された正確な時刻を特定できます。FLASHBACK CLUSTER TO TIMESTAMPはデータベースのバックアップの代わりにはならないことに注意してください。FLASHBACK CLUSTER TO TIMESTAMPを実行する前に、TiCDC などのツールで実行されている PITR およびレプリケーション タスクを一時停止し、FLASHBACKが完了した後に再開する必要があります。そうしないと、レプリケーション タスクが失敗する可能性があります。詳細については、 ユーザー向けドキュメントを参照してください。
FLASHBACK DATABASE#20463 @erwadbaを使用して削除されたデータベースの復元をサポートしますFLASHBACK DATABASEを使用すると、DROPによってガベージコレクション(GC) の有効期間内に削除されたデータベースとそのデータを復元できます。この機能は外部ツールに依存しません。SQL ステートメントを使用して、データとメタデータを迅速に復元できます。詳細については、 ユーザー向けドキュメントを参照してください。
Security
TiFlashは保存時の暗号化にSM4アルゴリズムをサポートしています #5953 @lidezhu
TiFlashの保存時暗号化にSM4アルゴリズムを追加します。保存時暗号化を設定する際に、
data-encryption-method構成ファイル内のsm4-ctr}}構成の値をtiflash-learner.toml暗号化機能を有効にできます。詳細については、ユーザー向けドキュメントを参照してください。
可観測性
クラスタ診断が GA になります #1438 @Hawkson-jee
TiDB Dashboardの クラスター診断は、指定された時間範囲内でクラスタに存在する可能性のある問題を診断し、診断結果とクラスタ関連の負荷監視情報を レポートにまとめます。この診断レポートはWeb 診断レポート形式です。ブラウザからページを保存した後、オフラインでページを閲覧したり、このページのリンクを共有したりできます。
診断レポートを使用すると、負荷、コンポーネントの状態、処理時間、構成など、クラスタの基本的な状態情報をすばやく把握できます。クラスタに一般的な問題がある場合は、 診断情報セクションにある組み込みの自動診断結果から原因を特定できます。
パフォーマンス
コプロセッサタスクの同時実行適応メカニズムを導入します #37724 @you06
TiKV の処理速度に基づいて、コプロセッサ タスクの数が増えると、TiDB は自動的に並列度を上げて (
tidb_distsql_scan_concurrencyの値を調整して)、コプロセッサ タスク キューを減らし、レイテンシーを削減します。テーブル結合順序を決定するための動的計画アルゴリズムを追加 #37825 @winoros
以前のバージョンでは、TiDB はテーブルの結合順序を決定するために貪欲アルゴリズムを使用していました。v6.4.0 では、TiDB オプティマイザに 計画 が導入されました。 動的計画アルゴリズム計画アルゴリズムは、貪欲アルゴリズムよりも多くの可能な結合順序を列挙できるため、より良い実行計画を見つける可能性が高まり、一部のシナリオでは SQL 実行効率が向上します。
動的計画法アルゴリズムは処理に時間がかかるため、TiDBの結合したテーブルの再配置アルゴリズムの選択は、
tidb_opt_join_reorder_threshold変数によって制御されます。Join 結合したテーブルの再配置に参加するノード数がこの閾値を超えると、TiDBは貪欲法アルゴリズムを使用します。そうでない場合は、動的計画法アルゴリズムを使用します。詳細については、ユーザー向けドキュメントを参照してください。
プレフィックスインデックスは、null値のフィルタリングをサポートしています。 #21145 @xuyifangreeneyes
この機能は、プレフィックスインデックスの最適化です。テーブル内の列にプレフィックスインデックスが設定されている場合、SQL文内の列の
IS NULLまたはIS NOT NULL条件をプレフィックスで直接フィルタリングできるため、この場合テーブル検索が不要になり、SQL実行のパフォーマンスが向上します。詳細については、 ユーザー向けドキュメントを参照してください。
TiDBチャンク再利用メカニズムの強化 #38606 @keeplearning20221
以前のバージョンでは、TiDB は
writechunk関数内でのみチャンクを再利用していました。TiDB v6.4.0 では、チャンク再利用メカニズムが Executor の演算子に拡張されました。チャンクを再利用することで、TiDB はメモリ解放を頻繁に要求する必要がなくなり、一部のシナリオでは SQL クエリの実行効率が向上します。システム変数tidb_enable_reuse_chunk使用して、チャンク オブジェクトを再利用するかどうかを制御できます。この機能はデフォルトで有効になっています。詳細については、 ユーザー向けドキュメントを参照してください。
相関サブクエリの非相関化を実行するかどうかを制御する新しいオプティマイザー ヒント
NO_DECORRELATEを導入します #37789 @time-and-fateTiDB はデフォルトでは、相関のあるサブクエリを書き換えて相関解除を実行しようとします。これにより、通常は実行効率が向上します。しかし、シナリオによっては相関解除によって実行効率が低下する場合があります。v6.4.0 では、オプティマイザヒント
NO_DECORRELATEが導入され、特定のクエリブロックに対して相関解除を実行しないようにオプティマイザに指示することで、シナリオによってはクエリのパフォーマンスが向上します。詳細については、ユーザー向けドキュメントを参照してください。
パーティション化されたテーブルの統計情報収集のパフォーマンスを改善する #37977 @Yisaer
バージョン6.4.0では、TiDBはパーティションテーブルの統計情報を収集する戦略を最適化しました。システム変数
tidb_auto_analyze_partition_batch_sizeを使用して、パーティションテーブルの統計情報を並列収集する際の同時実行数を設定することで、収集速度を向上させ、分析時間を短縮できます。
安定性
ディスク障害やI/Oスタックなどの極端な状況における障害リカバリを加速する #13648 @LykxSassinator
エンタープライズユーザーにとって、データベースの可用性は最も重要な指標の一つです。複雑なハードウェア環境では、障害を迅速に検知して復旧する方法が、データベース可用性における課題の一つとなっています。v6.4.0では、TiDBはTiKVノードの状態検出メカニズムを完全に最適化しました。ディスク障害やI/Oスタックといった極端な状況下でも、TiDBはノードの状態を迅速に報告し、アクティブウェイクアップメカニズムを使用してLeader選出を事前に開始することで、クラスタの自己修復を加速します。この最適化により、TiDBはディスク障害発生時のクラスタリカバリ時間を約50%短縮できます。
TiDBのメモリ使用量に関するグローバル制御 #37816 @wshwsh12
バージョン6.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 @xuyifangreeneyes
バージョン6.4.0では、範囲を構築するオプティマイザの最大メモリ使用量を制限するために、システム変数
tidb_opt_range_max_sizeが導入されました。メモリ使用量がこの制限を超えると、オプティマイザはメモリ消費量を削減するために、より正確な範囲ではなく、より粗い粒度の範囲を構築します。SQL文にIN条件が多数ある場合、この最適化によりコンパイル時のメモリ使用量を大幅に削減し、システムの安定性を確保できます。詳細については、 ユーザー向けドキュメントを参照してください。
統計情報の同期読み込みをサポート (GA) #37434 @chrysan
TiDB v6.4.0では、統計情報の同期読み込み機能がデフォルトで有効になっています。この機能により、SQL文の実行時に、ヒストグラム、TopN、Count-Min Sketch統計情報などの大規模な統計情報をメモリに同期的に読み込むことが可能になり、SQL最適化のための統計情報の網羅性が向上します。
詳細については、 ユーザー向けドキュメントを参照してください。
バッチ書き込みリクエストが軽量トランザクション書き込みの応答時間に与える影響を軽減する #13313 @glorv
一部のシステムのビジネスロジックでは、定期的なバッチ DML タスクが必要ですが、これらのバッチ書き込みタスクを処理すると、オンライン トランザクションのレイテンシーが増加します。v6.3.0 では、TiKV はハイブリッド ワークロード シナリオでの読み取り要求のスケジューリングを最適化するため、
readpool.unified.auto-adjust-pool-size構成項目を有効にすると、TiKV がすべての読み取り要求に対して UnifyReadPool スレッド プールのサイズを自動的に調整します。v6.4.0 では、TiKV は書き込み要求も動的に識別して優先順位を付け、1 回のポーリングで Apply スレッドが 1 つの FSM (有限状態機械) に対して書き込むことができる最大バイト数を制御できるため、バッチ書き込み要求がトランザクション書き込みの応答時間に与える影響を軽減できます。
使いやすさ
TiKV API V2 が一般公開 (GA) #11745 @pingyu
バージョン6.1.0より前のTiKVは、クライアントから渡された生データのみを保存するため、基本的なキーバリューの読み書き機能しか提供していませんでした。さらに、異なるコーディング方式とスコープのないデータ範囲のため、TiDB、トランザクションKV、およびRawKVを同じTiKVクラスタで同時に使用することはできません。そのため、複数のクラスタが必要となり、マシンコストと導入コストが増加します。
TiKV API V2は、新しいRawKVstorageフォーマットとアクセスインターフェースを提供し、以下の利点をもたらします。
- MVCCにデータを保存する際に、記録されたデータの変更タイムスタンプを付加します。このタイムスタンプに基づいて変更データキャプチャ（CDC）が実装されます。この機能は実験的であり、詳細はTiKV-CDCに記載されています。
- データはさまざまな用途に応じて範囲が定められており、API V2では、単一のクラスタ内でTiDB、トランザクションKV、およびRawKVアプリケーションが共存することをサポートしています。
- マルチテナントなどの機能をサポートするために、キースペースフィールドを予約してください。
TiKV API V2を有効にするには、TiKV設定ファイルの
api-version = 2セクションに[storage]}を設定します。詳細については、 ユーザー向けドキュメントを参照してください。
TiFlashデータ複製進捗状況の精度向上 #4902 @hehechen
TiDBでは、
PROGRESSテーブルのINFORMATION_SCHEMA.TIFLASH_REPLICAフィールドは、TiKVの対応するテーブルからTiFlashレプリカへのデータレプリケーションの進行状況をTiFlashために使用されます。以前のTiDBバージョンでは、PROCESSフィールドは、 TiFlashレプリカの作成中のデータレプリケーションの進行状況のみを提供していました。TiFlashレプリカが作成された後、TiKVの対応するテーブルに新しいデータがインポートされた場合、このフィールドは更新されず、新しいデータのTiKVからTiFlashへのレプリケーションの進行状況は表示されません。バージョン6.4.0では、TiDBはTiFlashレプリカのデータレプリケーション進捗状況の更新メカニズムを改善しました。TiFlashレプリカが作成された後、TiKVの対応するテーブルに新しいデータがインポートされると、
INFORMATION_SCHEMA.TIFLASH_REPLICAテーブルのPROGRESS値が更新され、新しいデータに対するTiKVからTiFlashへの実際のレプリケーション進捗状況が表示されます。この改善により、 TiFlashデータレプリケーションの実際の進捗状況を簡単に確認できます。詳細については、 ユーザー向けドキュメントを参照してください。
MySQLとの互換性
線形ハッシュパーティショニング構文との互換性を確保する #38450 @mjonss
以前のバージョンでは、TiDB はハッシュ、レンジ、List パーティショニングをサポートしていました。 v6.4.0 以降、TiDB はMySQL 線形ハッシュパーティショニングの構文とも互換性があります。
TiDBでは、MySQLのリニアハッシュパーティションの既存のDDLステートメントを直接実行でき、TiDBは対応するハッシュパーティションテーブルを作成します（TiDB内部にはリニアハッシュパーティションは存在しません）。また、MySQLのリニアハッシュパーティションの既存のDMLステートメントを直接実行することもでき、TiDBは対応するTiDBハッシュパーティションのクエリ結果を正常に返します。この機能により、TiDBの構文とMySQLのリニアハッシュパーティションとの互換性が確保され、MySQLベースのアプリケーションからTiDBへのスムーズな移行が可能になります。
パーティション数が2のべき乗である場合、TiDBハッシュパーティションテーブルの行は、MySQLリニアハッシュパーティションテーブルの行と同じように分散されます。そうでない場合、TiDBにおけるこれらの行の分散はMySQLとは異なります。
詳細については、 ユーザー向けドキュメントを参照してください。
高性能かつグローバルに単調な
AUTO_INCREMENT(実験的) をサポート #38442 @tiancaiamaoTiDB 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 @YangKeao
v6.4.0 以降、TiDB で MySQL 互換の範囲選択構文を使用できるようになりました。
キーワード
toを使用すると、配列要素の開始位置と終了位置を指定したり、配列内の連続した範囲の要素を選択したりできます。0を使用すると、配列の最初の要素の位置を指定できます。たとえば、$[0 to 2]を使用すると、配列の最初の 3 つの要素を選択できます。キーワード
lastを使用すると、配列の最後の要素の位置を指定できます。これにより、右から左への位置設定が可能になります。たとえば、$[last-2 to last]を使用すると、配列の最後の 3 つの要素を選択できます。
この機能により、SQL文の記述プロセスが簡素化され、JSON型の互換性がさらに向上し、MySQLアプリケーションをTiDBに移行する際の難易度が軽減されます。
データベースユーザー向けの追加説明の追加をサポート #38172 @CbcWestwolf
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構文の互換性が向上し、TiDBをMySQLエコシステムのツールやプラットフォームに容易に統合できるようになります。
バックアップと復元
EBS ボリューム スナップショットを使用した TiDB クラスターのバックアップをサポート #33849 @fengou1
TiDB クラスターが EKS 上にデプロイされ、AWS EBS ボリュームを使用している場合、TiDB クラスター データのバックアップ時に以下の要件を満たす必要がある場合は、 TiDB Operatorを使用してボリューム スナップショットとメタデータによるデータを AWS S3 にバックアップできます。
- バックアップの影響を最小限に抑える。例えば、QPSとトランザクションレイテンシーへの影響を5%未満に抑え、クラスタのCPUとメモリを消費しないようにする。
- 短時間でデータのバックアップと復元が可能です。例えば、1時間以内にバックアップを完了し、2時間以内にデータを復元できます。
詳細については、 ユーザー向けドキュメントを参照してください。
データ移行
DMは、下流のマージ済みテーブルの拡張列に上流のデータソース情報を書き込むことをサポートしています #37797 @lichunzhu
上流から TiDB へシャーディングされたスキーマとテーブルをマージする際、ターゲット テーブルに複数のフィールド (拡張列) を手動で追加し、DM タスクの設定時にその値を指定できます。たとえば、拡張列に上流のシャーディングされたスキーマとテーブルの名前を指定すると、DM によって下流に書き込まれるデータにはスキーマ名とテーブル名が含まれます。下流のデータが通常と異なる場合、この機能を使用して、スキーマ名やテーブル名など、ターゲット テーブル内のデータ ソース情報をすばやく特定できます。
DMは、必須チェック項目の一部をオプションに変更することで、事前チェックメカニズムを最適化します #7333 @lichunzhu
データ移行タスクをスムーズに実行するために、DMはタスク開始時に自動的に事前チェックトリガーし、チェック結果を返します。DMは事前チェックに合格した後にのみ移行を開始します。
バージョン6.4.0では、DMは以下の3つのチェック項目を必須から任意に変更し、事前チェックの合格率を向上させました。
- 上流のテーブルがTiDBと互換性のない文字セットを使用していないか確認してください。
- 上流テーブルに主キー制約または一意キー制約があるかどうかを確認してください。
- プライマリ/セカンダリ構成で、アップストリームデータベースのデータベースID
server_idが指定されているかどうかを確認してください。
DMは、増分移行タスクのオプションパラメータとしてbinlogの位置とGTIDを設定することをサポートします #7393 @GMHDBJD
バージョン6.4.0以降では、binlogの位置やGTIDを指定せずに、増分移行を直接実行できます。DMは、タスク開始後にアップストリームから生成されたbinlogファイルを自動的に取得し、これらの増分データをダウンストリームに移行します。これにより、ユーザーは面倒な理解や複雑な設定から解放されます。
詳細については、 DM 高度タスクコンフィグレーションファイルを参照してください。
DMが移行タスクのステータスインジケーターを追加 #7343 okJiang
バージョン6.4.0では、DMに移行タスクのパフォーマンスと進捗状況を示す指標がさらに追加され、移行のパフォーマンスと進捗状況をより直感的に把握できるようになり、トラブルシューティングの際の参考情報としても役立ちます。
- データインポートおよびエクスポートのパフォーマンスを示すステータスインジケーター（バイト/秒）を追加します。
- 下流データベースへのデータ書き込みに関するパフォーマンス指標の名前を、TPSからRPS（行/秒）に変更します。
- DMの完全移行タスクにおけるデータエクスポートの進捗状況を示す進捗インジケーターを追加します。
これらの指標の詳細については、 TiDBデータ移行におけるクエリタスクステータス参照してください。
TiDBデータ共有サブスクリプション
TiCDC は
3.2.0バージョン #7191 @3AceShowHandの Kafka へのデータのレプリケーションをサポートします。v6.4.0 以降、TiCDC は
3.2.0バージョン以前のデータをデータをKafkaに複製するをサポートします。
互換性の変更
システム変数
コンフィグレーションファイルパラメータ
その他
- v6.4.0 以降、
mysql.userテーブルには、User_attributesとToken_issuerという 2 つの新しい列が追加されています。以前の TiDB バージョンのバックアップ データから TiDB v6.4.0 にmysqlスキーマ内のシステムテーブルを復元します。と、 BR はcolumn count mismatchテーブルのmysql.userエラーを報告します。mysqlスキーマ内のシステム テーブルを復元しない場合、このエラーは報告されません。 - 名前が「 Dumplingのエクスポートファイルの形式一致するものの、末尾が非圧縮形式（例
test-schema-create.sql.originおよびtest.table-schema.sql.origin）で終わるファイルについては、 TiDB Lightning の処理方法が変更されました。v6.4.0 より前は、インポート対象ファイルにこのようなファイルが含まれている場合、TiDB Lightning はこれらのファイルのインポートをスキップしていました。v6.4.0 以降では、 TiDB Lightning TiDB Lightning はこれらのファイルがサポートされていない圧縮形式を使用しているとみなすため、インポート処理は失敗します。 - バージョン6.4.0以降、
SYSTEM_VARIABLES_ADMINまたはSUPERの権限を持つチェンジフィードのみがTiCDC Syncpoint機能を使用できます。
改善点
TiDB
ティクヴ
- Applyスレッドが1回のポーリングで1つの有限状態マシンに対して書き込める最大バイト数を制御し、Applyスレッドが大量のデータを書き込む際のRaftstoreの混雑を緩和するために、新しい設定項目
apply-yield-write-size-0-PLACEHOLDER-E}}を追加します。 #13313 @glorv - リージョンのリーダーを移行する前にエントリキャッシュをウォームアップして、リーダー転送プロセス中のQPSジッターを回避する #13060 @cosven
json_constrains演算子をコプロセッサー #13592にプッシュダウンするサポート @lizhenhuanCausalTsProviderに非同期関数を追加して、一部のシナリオでのフラッシュパフォーマンスを改善します #13428 @zeminzhou
- Applyスレッドが1回のポーリングで1つの有限状態マシンに対して書き込める最大バイト数を制御し、Applyスレッドが大量のデータを書き込む際のRaftstoreの混雑を緩和するために、新しい設定項目
PD
- ホットリージョンスケジューラのv2アルゴリズムがGAになります。一部のシナリオでは、v2アルゴリズムは、設定された両方の次元でより良いバランスを実現し、無効なスケジューリングを減らすことができます。 #5021 @hundundm
- 早期のタイムアウトを回避するためにオペレーター ステップのタイムアウト メカニズムを最適化します #5596 @bufferflies
- 大規模クラスターでのスケジューラーのパフォーマンスを向上 #5473 @bufferflies
- PD #5637で提供されていない外部タイムスタンプの使用をサポートする @lhy1024
TiFlash
ツール
TiDBダッシュボード
バックアップと復元 (BR)
TiCDC
- ExchangeパーティションDDLステートメントの複製をサポートする #639 @asddongmen
- MQ シンク モジュールの非バッチ送信パフォーマンスを向上 #7353 @Rustin170506
- テーブルに多数のリージョンがある場合の TiCDC プーラーのパフォーマンスを改善#7078 #7281 @sdojjy
- Syncpointが有効になっている場合に
tidb_enable_external_ts_read変数を使用して下流のTiDBの履歴データを読み取ることをサポートする #7419 @asddongmen - トランザクション分割を有効にし、デフォルトでセーフモードを無効にすることで、レプリケーションの安定性を向上させます #7505 @asddongmen
TiDBデータ移行（DM）
- 役に立たない
operate-source updateコマンドを dmctl から削除します #7246 @buchuitoudegou - 上流データベースが TiDB と互換性のない DDL ステートメントを使用している場合に DM の完全インポートが失敗する問題を修正しました。TiDB でサポートされている DDL ステートメントを使用して、事前に TiDB でターゲット テーブルのスキーマを手動で作成することで、インポートの成功を確実にすることができます #37984 @lance6716
- 役に立たない
TiDB Lightning
バグ修正
TiDB
- 新しいインデックスを作成した後に発生する可能性のあるインデックスの不整合の問題を修正します #38165 @tangenta
INFORMATION_SCHEMA.TIKV_REGION_STATUSテーブル #38407の権限の問題を修正しました @CbcWestwolfgrantorテーブルにmysql.tables_privフィールドが欠落している問題を修正します #38293 @CbcWestwolf- 共通テーブル式の結合結果が間違っている可能性がある問題を修正 #38170 @wjhuang2016
- 共通テーブル式の和集合の結果が間違っている可能性がある問題を修正 #37928 @YangKeao
- トランザクション領域番号監視パネルの情報が正しくない問題を修正 #38139 @jackysp
- システム変数
tidb_constraint_check_in_place_pessimistic内部トランザクションに影響を与える可能性がある問題を修正しました。変数のスコープを SESSION に変更しました。 #38766 @ekexium - クエリ内の条件が誤ってプロジェクションにプッシュダウンされる問題を修正 #35623 @Reminiscent
isNullRejectedおよびORANDのチェック結果が間違っていたためにクエリ結果が間違っていた問題を修正しました #38304 @Yisaer- 外部結合が削除された際に
ORDER BY内のGROUP_CONCATが考慮されず、クエリ結果が誤る問題を修正しました #18216 @winoros - 結合したテーブルの再配置 #38736により誤ってプッシュダウンされた条件が破棄された際に発生する、誤ったクエリ結果の問題を修正しました。@winoros
ティクヴ
- 複数の
cgroupおよびmountinfoが存在する場合に Gitpod で TiDB が起動に失敗する問題を修正 #13660 @tabokie - TiKV メトリクスの間違った式を修正
tikv_gc_compaction_filtered#13537 @Defined2014 - 異常な
delete_files_in_range#13534によって引き起こされたパフォーマンスの問題を修正します @tabokie - スナップショット取得中のリース期限切れによって引き起こされる異常なリージョン競合を修正 #13553 @SpadeA-Tang
FLASHBACK最初のバッチで失敗したときに発生したエラーを修正します#13672 #13704 #13723 @HuSharp
- 複数の
PD
- 不正確なストリーム タイムアウトを修正し、リーダーの切り替えを加速します #5207 @CabinfeverB
TiFlash
- PageStorage GC がページ削除マーカーを適切にクリアしない場合に発生する、WAL ファイルのサイズ超過による OOM の問題を修正 #6163 @JaySon-Huang
ツール
TiDBダッシュボード
バックアップと復元 (BR)
TiCDC
sasl-passwordの結果でchangefeed queryがマスクされない問題を修正 #7182 @dveeden- etcdトランザクションで操作が多すぎるとTiCDCが利用できなくなる可能性がある問題を修正 #7131 @asddongmen
- リドゥログが正しく削除されない可能性がある問題を修正 #6413 @asddongmen
- Kafka Sink V2 でワイドテーブルを複製するときのパフォーマンスの低下を修正 #7344 @Rustin170506
- チェックポイントtsが正しく進まない可能性がある問題を修正 #7274 @Rustin170506
- マウンターモジュールのログレベルが不適切なため、大量のログが出力される問題を修正 #7235 @Rustin170506
- TiCDCクラスターに2人のオーナーが存在する可能性がある問題を修正 #4051 @asddongmen
TiDBデータ移行（DM）
- DM WebUI が間違った
allow-listパラメータを生成する問題を修正 #7096 @zoubingwu - DMワーカーが起動または停止時にデータ競合を引き起こす確率がある問題を修正します #6401 @liumengya94
- DM が
UPDATEまたはDELETEステートメントを複製する際に、対応する行データが存在しない場合、DM がイベントをサイレントに無視する問題を修正します。 #6383 @GMHDBJD secondsBehindMasterコマンドを実行した後、query-statusフィールドが表示されない問題を修正しました #7189 @GMHDBJD- チェックポイントの更新時に大きなトランザクションが発生する可能性がある問題を修正しました #5010 @lance6716
- フルタスクモードで、タスクが同期段階に入ってすぐに失敗した場合、DMがアップストリームのテーブルスキーマ情報を失う可能性がある問題を修正します #7159 @lance6716
- 整合性チェックが有効になっている場合にデッドロックが発生する可能性がある問題を修正 #7241 @buchuitoudegou
- タスクの事前チェックで
SELECTテーブルに対するINFORMATION_SCHEMA権限が必要になる問題を修正します。 #7317 @lance6716 - TLS設定が空の場合にエラーが発生する問題を修正しました #7384 @liumengya94
- DM WebUI が間違った
TiDB Lightning
TiDBDumpling
寄稿者
TiDBコミュニティの以下の貢献者の皆様に感謝申し上げます。