TiDB 7.4.0 リリースノート
発売日:2023年10月12日
TiDB バージョン: 7.4.0
クイックアクセス: クイックスタート
7.4.0 では、次の主な機能と改善が導入されています。
機能の詳細
スケーラビリティ
分散実行フレームワーク (DXF) のバックエンド
ADD INDEXまたはIMPORT INTOタスクを並列実行するための TiDB ノードの選択をサポート (実験的) #46453 @ywqzzyリソースを大量に消費するクラスターで
ADD INDEXまたはIMPORT INTOタスクを並列実行すると、TiDBノードのリソースを大量に消費し、クラスターのパフォーマンス低下につながる可能性があります。v7.4.0以降では、システム変数tidb_service_scopeを使用して、 TiDB 分散実行フレームワーク (DXF)配下の各TiDBノードのサービススコープを制御できます。既存のTiDBノードを複数選択するか、新しいTiDBノードにTiDBサービススコープを設定すると、すべての並列タスクADD INDEXとIMPORT INTOはこれらのノードでのみ実行されます。このメカニズムにより、既存のサービスへのパフォーマンスへの影響を回避できます。詳細についてはドキュメントを参照してください。
パーティション化されたRaft KVストレージエンジンの強化 (実験的) #11515 #12842 @busyjay @tonyxuqqi @tabokie @bufferflies @5kbpers @SpadeA-Tang @nolouch
TiDB v6.6.0 では、実験的機能として Partitioned Raft KVストレージエンジンが導入されました。このエンジンは、複数の RocksDB インスタンスを使用して TiKVリージョンデータを格納し、各リージョンのデータは個別の RocksDB インスタンスに独立して格納されます。
TiDB v7.4.0では、Partitioned Raft KVストレージエンジンの互換性と安定性がさらに向上しました。大規模データテストを通じて、DM、 Dumpling、 TiDB Lightning、TiCDC、 BR、PITRといったTiDBエコシステムツールおよび機能との互換性が確保されています。さらに、Partitioned Raft KVストレージエンジンは、読み取りと書き込みが混在するワークロードにおいてもより安定したパフォーマンスを提供し、特に書き込み負荷の高いシナリオに適しています。さらに、各TiKVノードは8コアCPUをサポートし、8TBのデータストレージと64GBのメモリを搭載できるようになりました。
詳細についてはドキュメントを参照してください。
TiFlashは、分散ストレージおよびコンピューティングアーキテクチャ(GA)をサポートします#6882 @JaySon-Huang @JinheLin @breezewish @lidezhu @CalvinNeo @Lloyd-Pottiger
v7.0.0では、 TiFlashは実験的機能として、分散ストレージおよびコンピューティングアーキテクチャを導入しました。一連の改良を経て、v7.4.0以降、 TiFlashの分散ストレージおよびコンピューティングアーキテクチャがGAとなります。
このアーキテクチャでは、 TiFlashノードは2種類(コンピューティングノードと書き込みノード)に分かれており、S3 APIと互換性のあるオブジェクトストレージをサポートします。どちらのノードも、コンピューティング容量またはストレージ容量を個別に拡張できます。分散ストレージおよびコンピューティングアーキテクチャでは、 TiFlashレプリカの作成、データのクエリ、オプティマイザヒントの指定など、結合ストレージおよびコンピューティングアーキテクチャと同様にTiFlashを使用できます。
TiFlashの分散ストレージおよびコンピューティングアーキテクチャと結合ストレージおよびコンピューティングアーキテクチャは、同じクラスター内で使用したり、相互に変換したりすることはできません。TiFlashをデプロイする際に、使用するアーキテクチャを設定できます。
詳細についてはドキュメントを参照してください。
パフォーマンス
JSON 演算子
MEMBER OFを TiKV にプッシュダウンする機能をサポート #46307 @wshwsh12value MEMBER OF(json_array)詳細についてはドキュメントを参照してください。
任意のフレーム定義タイプのウィンドウ関数をTiFlash にプッシュダウンする機能をサポート #7376 @xzhangxian1008
v7.4.0より前のTiFlashでは、
PRECEDINGまたはFOLLOWING含むウィンドウ関数をサポートしておらず、そのようなフレーム定義を含むウィンドウ関数はTiFlashにプッシュダウンできませんでした。v7.4.0以降、 TiFlashはすべてのウィンドウ関数のフレーム定義をサポートします。この機能は自動的に有効化され、フレーム定義を含むウィンドウ関数は、関連要件が満たされた場合に自動的にTiFlashにプッシュダウンされ、実行されます。クラウドストレージベースのグローバルソート機能を導入して、並列実行における
ADD INDEXおよびIMPORT INTOタスクのパフォーマンスと安定性を向上します (実験的) #45719 @wjhuang2016v7.4.0より前のバージョンでは、Distributed eXecution Framework(DXF)で
ADD INDEXやIMPORT INTOようなタスクを実行する場合、各TiDBノードは、エンコードされたインデックスKVペアとテーブルデータKVペアのソートのために、かなりの量のローカルディスク領域を割り当てる必要がありました。しかし、グローバルソート機能がないため、処理中に異なるTiDBノード間および各ノード内でデータが重複する可能性があります。その結果、TiKVはこれらのKVペアをストレージエンジンにインポートする際に、常にコンパクション操作を実行する必要があり、ADD INDEXとIMPORT INTOのパフォーマンスと安定性に影響を与えます。v7.4.0では、TiDBにグローバルソートの機能が導入されました。エンコードされたデータをローカルに書き込んでソートする代わりに、クラウドストレージに書き込んでグローバルソートを行うようになりました。ソート後、インデックスデータとテーブルデータの両方がTiKVに並列でインポートされるため、パフォーマンスと安定性が向上します。
詳細についてはドキュメントを参照してください。
非プリペアドステートメントの実行計画のキャッシュをサポート (GA) #36598 @qw4990
TiDB v7.0.0では、同時実行OLTPの処理能力を向上させるための実験的機能として、非プリペアドプランキャッシュが導入されました。v7.4.0ではこの機能がGAとなります。実行プランキャッシュはより多くのシナリオに適用され、TiDBの同時実行処理能力が向上します。
非プリペアドプランキャッシュを有効にすると、メモリとCPUのオーバーヘッドが増加する可能性があり、すべての状況に適しているとは限りません。v7.4.0以降、この機能はデフォルトで無効になっています。
tidb_enable_non_prepared_plan_cacheを有効にし、tidb_session_plan_cache_sizeでキャッシュサイズを制御できます。また、この機能はデフォルトではDML文をサポートしておらず、SQL文には一定の制限があります。詳細については、 制限を参照してください。
詳細についてはドキュメントを参照してください。
信頼性
TiFlashはクエリレベルのデータスピルをサポート#7738 @windtalker
TiFlash v7.0.0以降、
GROUP BY、ORDER BY、JOINの3つのオペレーターのデータスピル制御がサポートされます。この機能により、データサイズが利用可能なメモリを超えた場合にクエリの終了やシステムクラッシュなどの問題を防ぐことができます。ただし、各オペレーターのスピルを個別に管理するのは煩雑で、全体的なリソース制御には効果的ではありません。v7.4.0では、 TiFlashにクエリレベルのデータスピルが導入されました。TiFlashへのクエリのメモリ制限を
tiflash_mem_quota_query_per_nodeに設定し、データスピルをトリガーするメモリ比率をtiflash_query_spill_ratioに設定することで、クエリのメモリ使用量を効率的に管理し、 TiFlashのメモリリソースをより適切に制御できます。詳細についてはドキュメントを参照してください。
ユーザー定義の TiKV 読み取りタイムアウトをサポート #45380 @crazycs520
通常、TiKVはリクエストを数ミリ秒という非常に高速に処理します。しかし、TiKVノードがディスクI/Oジッターやネットワークレイテンシーに遭遇すると、リクエスト処理時間が大幅に増加する可能性があります。v7.4.0より前のバージョンでは、TiKVリクエストのタイムアウト制限は固定されており、調整できません。そのため、TiKVノードで問題が発生すると、TiDBは一定時間のタイムアウト応答を待機する必要があり、ジッター発生時のアプリケーションクエリパフォーマンスに顕著な影響が生じます。
TiDB v7.4.0 では、新しいシステム変数
tikv_client_read_timeoutが導入され、クエリで TiDB が TiKV に送信する RPC 読み取りリクエストのタイムアウトをカスタマイズできるようになりました。つまり、ディスクまたはネットワークの問題により TiKV ノードに送信されたリクエストが遅延した場合、TiDB はより早くタイムアウトし、他の TiKV ノードにリクエストを再送信できるため、クエリのレイテンシーが短縮されます。すべての TiKV ノードでタイムアウトが発生した場合、TiDB はデフォルトのタイムアウトを使用して再試行します。さらに、クエリでオプティマイザヒント/*+ SET_VAR(TIKV_CLIENT_READ_TIMEOUT=N) */を使用して、TiDB が TiKV RPC 読み取りリクエストを送信するタイムアウトを設定することもできます。この機能強化により、不安定なネットワークやストレージ環境に TiDB が柔軟に適応できるようになり、クエリのパフォーマンスが向上し、ユーザーエクスペリエンスが強化されます。詳細についてはドキュメントを参照してください。
オプティマイザヒントを使用して、一部のシステム変数の値を一時的に変更することをサポートします。 #45892 @winoros
TiDB v7.4.0では、MySQL 8.0と同様のオプティマイザヒント
SET_VAR()が導入されました。ヒントSET_VAR()SQL文に含めることで、文の実行中にシステム変数の値を一時的に変更できます。これにより、様々な文の環境設定が容易になります。例えば、リソースを大量に消費するSQL文の並列処理を積極的に強化したり、変数を通じてオプティマイザの動作を変更したりすることが可能になります。変更可能なシステム変数は、ヒント
SET_VAR()のシステム変数で確認できます。明示的にサポートされていない変数を変更すると、予期しない動作が発生する可能性があるため、変更しないことを強くお勧めします。詳細についてはドキュメントを参照してください。
TiFlashはリソース制御をサポート #7660 @guo-shaoge
TiDB v7.1.0では、リソース制御機能が一般提供され、TiDBとTiKVのリソース管理機能を提供します。v7.4.0では、 TiFlashがリソース制御機能をサポートし、TiDB全体のリソース管理機能が向上しました。TiFlashのリソースTiFlashは既存のTiDBリソース制御機能と完全に互換性があり、既存のリソースグループはTiDB、TiKV、 TiFlashのリソースを同時に管理します。
TiFlashリソース制御機能を有効にするかどうかを制御するには、 TiFlashパラメータ
enable_resource_controlを設定します。この機能を有効にすると、 TiFlashはTiDBのリソースグループ設定に基づいてリソースのスケジュールと管理を実行し、全体的なリソースの適切な割り当てと使用を保証します。詳細についてはドキュメントを参照してください。
TiFlashはパイプライン実行モデル(GA) をサポートします。 #6518 @SeaRise
TiFlash v7.2.0 以降、パイプライン実行モデルが導入されました。このモデルは、すべてのスレッドリソースを一元管理し、タスク実行を均一にスケジュールすることで、スレッドリソースを最大限に活用し、リソースの過剰使用を回避します。v7.4.0 では、 TiFlash はスレッドリソースの使用状況の統計を改善し、パイプライン実行モデルは GA 機能となり、デフォルトで有効化されます。この機能はTiFlashリソース制御機能と相互に依存しているため、TiDB v7.4.0 では、以前のバージョンでパイプライン実行モデルの有効化/無効化に使用されていた変数
tidb_enable_tiflash_pipeline_modelが削除されました。代わりに、 TiFlashパラメータtidb_enable_resource_controlを設定することで、パイプライン実行モデルとTiFlashリソース制御機能を有効化または無効化できます。詳細についてはドキュメントを参照してください。
オプティマイザモードのオプションを追加 #46080 @time-and-fate
TiDB v7.4.0 では、オプティマイザが使用する推定方法を制御する新しいシステム変数
tidb_opt_objectiveが導入されました。デフォルト値moderate、オプティマイザの従来の動作が維持され、実行時統計を使用してデータ変更に基づいて推定値を調整します。この変数をdeterminateに設定すると、オプティマイザは実行時修正を考慮せず、統計のみに基づいて実行計画を生成します。長期にわたって安定したOLTPアプリケーションや、既存の実行計画に自信がある場合は、テスト後にモード
determinateに切り替えることをお勧めします。これにより、プラン変更の可能性が軽減されます。詳細についてはドキュメントを参照してください。
TiDB リソース制御はバックグラウンドタスクの管理をサポートします (実験的) #44517 @glorv
データバックアップや自動統計収集などのバックグラウンドタスクは、優先度が低いにもかかわらず、多くのリソースを消費します。これらのタスクは通常、定期的または不定期にトリガーされます。実行中に大量のリソースを消費するため、オンラインの高優先度タスクのパフォーマンスに影響を与えます。v7.4.0以降、TiDBリソース制御機能はバックグラウンドタスクの管理をサポートします。この機能により、低優先度タスクがオンラインアプリケーションに及ぼすパフォーマンスへの影響を軽減し、合理的なリソース割り当てを実現し、クラスターの安定性を大幅に向上させます。
TiDB は次の種類のバックグラウンドタスクをサポートしています。
lightning: TiDB LightningまたはIMPORT INTOを使用してインポートタスクを実行します。br: BRを使用してバックアップおよび復元タスクを実行します。PITR はサポートされていません。ddl: Reorg DDL のバッチデータ書き戻しフェーズ中のリソース使用量を制御します。stats: 手動で実行されるか、TiDB によって自動的にトリガーされる統計を収集するタスク。デフォルトでは、バックグラウンドタスクとしてマークされたタスクタイプは空で、バックグラウンドタスクの管理は無効になっています。このデフォルトの動作は、TiDB v7.4.0より前のバージョンと同じです。バックグラウンドタスクを管理するには、
defaultリソースグループのバックグラウンドタスクタイプを手動で変更する必要があります。詳細についてはドキュメントを参照してください。
ロック統計が一般公開(GA)される#46351 @Rustin170506
v7.4.0では、 ロック統計一般提供となります。運用上のセキュリティを確保するため、統計情報のロックとロック解除には、統計情報の収集と同じ権限が必要です。さらに、TiDBは特定のパーティションに対する統計情報のロックとロック解除をサポートし、柔軟性が向上しています。データベース内のクエリや実行計画に自信があり、変更を防止したい場合は、統計情報をロックすることで安定性を高めることができます。
詳細についてはドキュメントを参照してください。
テーブルにハッシュ結合を選択するかどうかを制御するシステム変数を導入します。 #46695 @coderplay
MySQL 8.0では、新機能としてテーブルのハッシュ結合が導入されました。この機能は主に、比較的大きな2つのテーブルと結果セットを結合するために使用されます。ただし、トランザクションワークロードやMySQL 5.7で実行される一部のアプリケーションでは、テーブルのハッシュ結合はパフォーマンスリスクをもたらす可能性があります。MySQLには、ハッシュ結合をグローバルレベルとセッションレベルのどちらで選択するかを制御するための
optimizer_switch用意されています。TiDB v7.4.0以降、テーブルのハッシュ結合を制御するためのシステム変数
tidb_opt_enable_hash_join導入されました。これはデフォルトで有効になっています(ON)。実行計画でテーブル間のハッシュ結合を選択する必要がない場合は、この変数をOFFに変更することで、実行計画のロールバックの可能性を低減し、システムの安定性を向上させることができます。詳細についてはドキュメントを参照してください。
統計キャッシュのメモリ制御は一般提供(GA) #45367 @hawkingrei
TiDBインスタンスは、テーブル統計をキャッシュすることで、実行計画の生成を高速化し、SQLパフォーマンスを向上させることができます。v6.1.0以降、TiDBはシステム変数
tidb_stats_cache_mem_quotaを導入しました。このシステム変数を設定することで、統計キャッシュのメモリ使用量の上限を設定できます。キャッシュが上限に達すると、TiDBは非アクティブなキャッシュエントリを自動的に削除し、インスタンスのメモリ使用量を制御して安定性を向上させます。v7.4.0 以降、この機能は一般提供 (GA) されます。
詳細についてはドキュメントを参照してください。
SQL
TiDBはパーティションタイプ管理をサポート #42728 @mjonss
v7.4.0より前のバージョンでは、TiDBのパーティションテーブルのパーティションタイプは変更できませんでした。v7.4.0以降では、パーティションテーブルを非パーティションテーブルに変更したり、非パーティションテーブルをパーティションテーブルに変更したり、パーティションタイプの変更がサポートされるようになりました。これにより、パーティションテーブルのパーティションタイプと数を柔軟に調整できるようになりました。例えば、
ALTER TABLE t PARTITION BY ...ステートメントを使用してパーティションタイプを変更できます。詳細についてはドキュメントを参照してください。
TiDBは
ROLLUP修飾子とGROUPING関数の使用をサポートしています #44487 @AilinKidWITH ROLLUP修飾子とGROUPING関数は、多次元データ要約のためのデータ分析でよく使用されます。v7.4.0 以降では、GROUP BY句でWITH ROLLUP修飾子とGROUPING関数を使用できます。例えば、SELECT ... FROM ... GROUP BY ... WITH ROLLUP構文でWITH ROLLUP修飾子を使用できます。詳細についてはドキュメントを参照してください。
DB操作
照合順序
utf8mb4_0900_ai_ciとutf8mb4_0900_binをサポート #37566 @YangKeao @zimulala @bb7133TiDB v7.4.0 では、MySQL 8.0 からのデータ移行のサポートが強化され、
utf8mb4_0900_ai_ciとutf8mb4_0900_bin2つの照合順序が追加されました。utf8mb4_0900_ai_ciはMySQL 8.0 のデフォルトの照合順序です。TiDB v7.4.0では、MySQL 8.0と互換性のあるシステム変数
default_collation_for_utf8mb4も導入されました。これにより、utf8mb4文字セットのデフォルトの照合順序を指定できるようになり、 MySQL 5.7以前のバージョンからの移行やデータレプリケーションとの互換性が確保されます。詳細についてはドキュメントを参照してください。
可観測性
ログにセッション接続 ID とセッション エイリアスを追加することをサポート #46071 @lcwangchao
SQL実行の問題をトラブルシューティングする際には、根本原因を特定するために、TiDBコンポーネントログの内容を相関させる必要があることがよくあります。v7.4.0以降、TiDBはセッション接続ID(
CONNECTION_ID)をセッション関連ログ(TiDBログ、スロークエリログ、TiKVコプロセッサからのスローログなど)に書き込むことができます。セッション接続IDに基づいて複数の種類のログの内容を相関させることで、トラブルシューティングと診断の効率を向上させることができます。さらに、セッションレベルのシステム変数
tidb_session_aliasを設定することで、上記のログにカスタム識別子を追加できます。ログにアプリケーション識別情報を挿入できるこの機能により、ログの内容とアプリケーションを関連付け、アプリケーションからログへのリンクを構築し、診断の難易度を軽減できます。TiDB Dashboardは、実行計画をテーブルビューで表示することをサポートしています#1589 @baurine
v7.4.0 では、TiDB Dashboardは、診断エクスペリエンスを向上させるために、Slow QueryページとSQL Statementページで実行計画をテーブルビューで表示することをサポートしています。
詳細についてはドキュメントを参照してください。
データ移行
IMPORT INTO機能をつでD3ハンター強化する #46704バージョン7.4.0以降では、
IMPORT INTO文にCLOUD_STORAGE_URIのオプションを追加することで、インポートのパフォーマンスと安定性を向上させるグローバルソート機能(実験的)を有効にすることができますCLOUD_STORAGE_URIのオプションでは、エンコードされたデータの保存先となるクラウドストレージのアドレスを指定できます。さらに、v7.4.0 では、
IMPORT INTO機能に次の機能が導入されています。Split_Fileオプションの構成をサポートします。これにより、大きな CSV ファイルを複数の 256 MiB の小さな CSV ファイルに分割して並列処理し、インポートパフォーマンスを向上させることができます。圧縮されたCSVファイルとSQLファイル
.snappyインポート.zstサポートします。サポートされている.zstd形式は、.gzip.gz。詳細についてはドキュメントを参照してください。
Dumplingは、データをCSVファイルにエクスポートする際に、ユーザー定義のターミネータをサポートします#46982 @GMHDBJD
バージョン7.4.0より前のDumplingでは、データをCSVファイルにエクスポートする際に、行末文字として
"\r\n"を使用します。そのため、行末文字として"\n"しか認識しない下流システムでは、エクスポートされたCSVファイルを解析できないか、解析前にサードパーティ製の変換ツールを使用する必要があります。バージョン7.4.0以降、 Dumplingに新しいパラメータ
--csv-line-terminatorが導入されました。このパラメータを使用すると、データをCSVファイルにエクスポートする際に、任意の終端文字を指定できます。このパラメータは"\r\n"と"\n"サポートしています。以前のバージョンとの一貫性を保つため、デフォルトの終端文字は"\r\n"です。詳細についてはドキュメントを参照してください。
TiCDCはPulsarへのデータ複製をサポート #9413 @yumchina @asddongmen
Pulsarは、クラウドネイティブかつ分散型のメッセージストリーミングプラットフォームであり、リアルタイムデータストリーミングエクスペリエンスを大幅に向上させます。v7.4.0以降、TiCDCは変更データをPulsarに
canal-json形式で複製し、Pulsarとのシームレスな統合を実現します。この機能により、TiCDCはTiDBの変更を容易にキャプチャしてPulsarに複製できるため、データ処理と分析機能に新たな可能性をもたらします。Pulsarから新たに生成された変更データを読み取り、処理する独自のコンシューマーアプリケーションを開発することで、特定のビジネスニーズに対応できます。詳細についてはドキュメントを参照してください。
TiCDC はクレームチェックパターンで大きなメッセージの処理を改善します #9153 @3AceShowHand
バージョン7.4.0より前のTiCDCでは、Kafkaの最大メッセージサイズ(
max.message.bytes)を超える大きなメッセージを下流に送信できませんでした。バージョン7.4.0以降では、Kafkaを下流として変更フィードを設定する際に、大きなメッセージを保存する外部ストレージの場所を指定し、外部ストレージ内の大きなメッセージのアドレスを含む参照メッセージをKafkaに送信できるようになりました。コンシューマーはこの参照メッセージを受信すると、外部ストレージのアドレスからメッセージの内容を取得できます。詳細についてはドキュメントを参照してください。
互換性の変更
動作の変更
v7.4.0 以降、TiDB は MySQL 8.0 の必須機能と互換性があり、
version()8.0.11で始まるバージョンを返します。TiFlash を以前のバージョンから v7.4.0 にアップグレードした後、元のバージョンへのインプレースダウングレードはサポートされません。これは、v7.4 以降、 TiFlash がPageStorage V3 のデータ圧縮ロジックを最適化し、データ圧縮中に発生する読み取りおよび書き込みの増幅を削減しているためです。これにより、基盤となるストレージファイル名の一部が変更されます。
TSO タイムスタンプの論理部分を抽出できるように
TIDB_PARSE_TSO_LOGICAL()関数が追加されました。MySQL 8.0 との互換性を向上させるために
information_schema.CHECK_CONSTRAINTSテーブルが追加されました。複数の変更を含むトランザクションにおいて、更新イベントで主キーまたは非NULLの一意インデックス値が変更された場合、TiCDCはイベントを削除イベントと挿入イベントに分割し、すべてのイベントが挿入イベントに先行する削除イベントの順序に従うようにします。詳細については、 ドキュメントを参照してください。
システム変数
コンフィグレーションファイルのパラメータ
廃止および削除された機能
- mydumperバージョン7.5.0で廃止され、その機能の大部分はDumplingに置き換えられました。mydumperではなくDumplingを使用することを強くお勧めします。
- TiKVインポーターはバージョン7.5.0で廃止されます。代替としてTiDB Lightningの物理インポートモードを使用することを強くお勧めします。
- TiCDCの
enable-old-valueのパラメータは削除されます#9667 @3AceShowHand
改善点
TiDB
- パーティションテーブルでの
ANALYZE操作のメモリ使用量とパフォーマンスを最適化します #47071 #47104 #46804 @hawkingrei - 統計ガベージコレクションメモリ使用量とパフォーマンスを最適化します #31778 @winoros
- インデックスマージ交差のプッシュダウン
limitを最適化してクエリパフォーマンスを向上させる #46863 @AilinKid IndexLookupに多くのテーブル取得タスクが含まれる場合に、誤ってフルテーブルスキャンを選択する可能性を最小限に抑えるようにコストモデルを改善します#45132 @qw4990- 結合除去ルールを最適化して、
join on unique keysのクエリパフォーマンスを向上させます。 #46248 @fixdb - 実行エラーを回避するために、多値インデックス列の照合順序を
binaryに変更します#46717 @YangKeao
- パーティションテーブルでの
TiKV
- OOM を防ぐためにリゾルバのメモリ使用量を最適化します #15458 @overvenus
- ルータオブジェクトのLRUCacheを排除してメモリ使用量を削減し、OOM を防止します。 #15430 @Connor1996
- TiCDC リゾルバのメモリ使用量を削減 #15412 @overvenus
- RocksDB 圧縮によるメモリ変動を削減 #15324 @overvenus
- Partitioned Raft KV のフロー制御モジュールのメモリ消費を削減 #15269 @overvenus
- 接続再試行のプロセスでPDクライアントのバックオフメカニズムを追加し、エラー再試行中に再試行間隔を徐々に増やしてPD圧力を軽減します。 #15428 @nolouch
- RocksDB の
background_compactionを動的に調整するサポート #15424 @glorv
PD
TiFlash
ツール
Backup & Restore (BR)
- リージョンリーダーシップの移行が発生すると、PITR ログバックアップの進行のレイテンシーが長くなるという問題を軽減します#13638 @YuJuncen
- HTTPクライアントで
MaxIdleConnsとMaxIdleConnsPerHostパラメータを設定することにより、ログバックアップとPITRリストアタスクの接続再利用のサポートを強化します。 #46011 @Leavrth - PD または外部 S3ストレージへの接続に失敗した場合のBRのフォールトトレランスを向上#42909 @Leavrth
- 新しい復元パラメータ
WaitTiflashReadyを追加します。このパラメータを有効にすると、 TiFlashレプリカが正常に複製された後に復元操作が完了します#43828 #46302 @3pointer - ログバックアップのCPUオーバーヘッドを削減
resolve lock#40759 @3pointer
TiCDC
TiDB Lightning
- リージョンスキャッタフェーズ中のTiDB Lightningの再試行ロジックを最適化します。 #46203 @mittalrishabh
- データインポートフェーズ中の
no leaderエラーに対するTiDB Lightningの再試行ロジックを最適化します。 #46253 @lance6716
バグ修正
TiDB
- ハッシュパーティション化されていないテーブルに対して
BatchPointGetオペレーターが誤った結果を返す問題を修正しました#45889 @Defined2014 - ハッシュパーティションテーブルに対して
BatchPointGetオペレーターが誤った結果を返す問題を修正しました #46779 @jiyfhust - TiDBパーサーが状態のままになり、解析エラーが発生する問題を修正#45898 @qw4990
EXCHANGE PARTITION制約をチェックしない問題を修正 #45922 @mjonsstidb_enforce_mppシステム変数が正しく復元できない問題を修正#46214 @djshow832LIKE述語の_が誤って処理される問題を修正#46287 #46618 @Defined2014- TiDBがスキーマを取得できなかった場合に
schemaTsが0に設定される問題を修正しました #46325 @hihihuhu AUTO_ID_CACHE=1に設定されている場合にDuplicate entryが発生する可能性がある問題を修正しました #46444 @tiancaiamaoAUTO_ID_CACHE=1に設定されている場合に、panic後に TiDB がゆっくりと回復する問題を修正しました。 #46454 @tiancaiamaoAUTO_ID_CACHE=1に設定されている場合にnext_row_idinSHOW CREATE TABLEが間違っている問題を修正しました #46545 @tiancaiamao- サブクエリで CTE を使用すると解析中に発生するpanic問題を修正しました #45838 @djshow832
EXCHANGE PARTITION失敗またはキャンセルされた場合に、パーティションテーブルの制限が元のテーブルに残る問題を修正#45920 #45791 @mjonss- リストパーティションの定義で、
NULLと空の文字列の両方の使用がサポートされていない問題を修正しました。 #45694 @mjonss - パーティション交換中にパーティション定義に準拠していないデータを検出できない問題を修正 #46492 @mjonss
tmp-storage-quota設定が で有効にならない問題を修正 #26806 @wshwsh12 #45161WEIGHT_STRING()関数が照合順序と一致しない問題を修正 #45725 @dveeden- インデックス結合のエラーによりクエリが停止する可能性がある問題を修正#45716 @wshwsh12
DATETIMEまたはTIMESTAMP列を数値定数と比較するときに、MySQL と動作が一致しない問題を修正しました。 #38361 @yibin87- 符号なし型と
Duration型定数を比較したときに発生する誤った結果を修正しました #45410 @wshwsh12 - アクセスパスプルーニングロジックが
READ_FROM_STORAGE(TIFLASH[...])ヒントを無視し、Can't find a proper physical planエラーが発生する問題を修正しました。 #40146 @AilinKid GROUP_CONCATORDER BY列を解析できない問題を修正 #41986 @AilinKid- 深くネストされた式に対してハッシュコードが繰り返し計算され、メモリ使用量が増加し、OOM が発生する問題を修正しました。 #42788 @AilinKid
- CAST に精度損失がないのに条件
cast(col)=rangeで FullScan が発生する問題を修正#45199 @AilinKid - MPP実行計画で集計がユニオンを介してプッシュダウンされると、結果が正しくなくなる問題を修正#45850 @AilinKid
in (?)とのバインディングがin (?, ... ?)と一致しない問題を修正しました #44298 @qw4990non-prep plan cache実行計画を再利用するときに接続照合順序を考慮しないことによって発生するエラーを修正しました #47008 @qw4990- 実行されたプランがプランキャッシュにヒットしない場合に警告が報告されない問題を修正しました #46159 @qw4990
plan replayer dump explainエラーを報告する問題を修正 #46197 @time-and-fate- CTE を含む DML 文を実行するとpanicが発生する問題を修正しました #46083 @winoros
- 2つのサブクエリを結合するときに
TIDB_INLJヒントが有効にならない問題を修正しました #46160 @qw4990 MERGE_JOINの結果が間違っている問題を修正#46580 @qw4990
- ハッシュパーティション化されていないテーブルに対して
TiKV
- Titanが有効になっているときにTiKVが起動に失敗し、
Blob file deleted twiceエラーが発生する問題を修正しました #15454 @Connor1996 - スレッド自発的およびスレッド非自発的監視パネルにデータがない問題を修正しました #15413 @SpadeA-Tang
- raftstore-applys が継続的に増加するデータエラーを修正しました #15371 @Connor1996
- リージョンのメタデータが正しくないことによって引き起こされるTiKV panic問題を修正しました #13311 @zyguan
sync_recoveryからsyncに切り替えた後に QPS が 0 に低下する問題を修正しました #15366 @nolouch- オンラインアンセーフリカバリがタイムアウトで中止されない問題を修正 #15346 @Connor1996
- CpuRecord によって発生する潜在的なメモリリークの問題を修正しました #15304 @overvenus
- バックアップクラスタがダウンし、プライマリクラスタがクエリされたときに
"Error 9002: TiKV server timeout"が発生する問題を修正しました #12914 @Connor1996 - プライマリクラスタが回復した後に TiKV が再起動するとバックアップ TiKV が停止する問題を修正しました #12320 @disksing
- Titanが有効になっているときにTiKVが起動に失敗し、
PD
- フラッシュバック中にリージョン情報が更新されず保存されない問題を修正 #6912 @overvenus
- ストア構成の同期が遅いために PD リーダーの切り替えが遅くなる問題を修正しました #6918 @bufferflies
- Scatter Peers でグループが考慮されない問題を修正しました #6962 @bufferflies
- RU消費量が0未満の場合にPDがクラッシュする問題を修正 #6973 @CabinfeverB
- 変更された分離レベルがデフォルトの配置ルールに同期されない問題を修正しました #7121 @rleungx
- クラスタが大きい場合、クライアントが定期的に更新される
min-resolved-tsPD OOMを引き起こす可能性がある問題を修正しました#46664 @HuSharp
TiFlash
ツール
Backup & Restore (BR)
TiCDC
- PD のスケールアップおよびスケールダウン中に TiCDC が無効な古いアドレスにアクセスする問題を修正#9584 @fubinzh @asddongmen
- 一部のシナリオでチェンジフィードが失敗する問題を修正#9309 #9450 #9542 #9685 @hicqu @CharlesCheung96
- アップストリームで 1 つのトランザクションで複数の行の一意のキーが変更されると、レプリケーション書き込み競合が発生する可能性がある問題を修正しました。 #9430 @sdojjy
- アップストリームで同じDDL文で複数のテーブルの名前を変更するとレプリケーションエラーが発生する問題を修正 #9488 @CharlesCheung96 #9476 @asddongmen
- CSVファイルで中国語の文字が検証されない問題を修正#9609 @CharlesCheung96
- すべての変更フィードが削除された後に上流の TiDB GC がブロックされる問題を修正#9633 @sdojjy
scale-outが有効になっている場合のノード間の書き込みキーの不均等な配布の問題を修正#9665 @sdojjy- ログに機密ユーザー情報が記録される問題を修正 #9690 @sdojjy
TiDB Data Migration (DM)
- DM が大文字と小文字を区別しない照合順序で競合を正しく処理できない問題を修正しました #9489 @hihihuhu
- DM バリデーターのデッドロック問題を修正し、再試行を強化しました。 #9257 @D3Hunter
- 失敗した DDL がスキップされ、後続の DDL が実行されない場合に、DM によって返されるレプリケーション ラグが増大し続ける問題を修正しました#9605 @D3Hunter
- オンライン DDL をスキップするときに DM が上流のテーブルスキーマを適切に追跡できない問題を修正しました #9587 @GMHDBJD
- 楽観的モードでタスクを再開するときに DM がすべての DML をスキップする問題を修正しました #9588 @GMHDBJD
- DMが楽観的モードでパーティションDDLをスキップする問題を修正 #9788 @GMHDBJD
TiDB Lightning
貢献者
TiDB コミュニティからの以下の貢献者に感謝いたします。