TiDB 6.2.0 リリースノート
発売日：2022年8月23日
TiDBバージョン: 6.2.0-DMR
バージョン6.2.0-DMRの主な新機能と改善点は以下のとおりです。
- TiDB Dashboardは視覚的な実行計画をサポートしており、実行計画をより直感的に表示できます。
- パフォーマンス分析とチューニングをより効率的に行うために、TiDB Dashboardに監視ページを追加します。
- TiDB のロックビュー機能は、楽観的トランザクションの待機情報の表示をサポートし、ロック競合の迅速な特定を容易にします。
- TiFlash はストレージフォーマットの新しいバージョンをサポートし、安定性とパフォーマンスを強化します。
- きめ細かいシャッフル機能ウィンドウ関数を複数のスレッドで並列実行できます。
- 新しい並行DDLフレームワーク：DDLステートメントのブロックが減り、実行効率が向上します。
- TiKV はCPU使用率を自動的に調整するをサポートしており、安定した効率的なデータベース運用を保証します。
- 特定時点リカバリ（PITR）は、過去の任意の時点から TiDB クラスターのスナップショットを新しいクラスターに復元するために導入されました。
- TiDB Lightning は、クラスター レベルではなく、物理インポート モードでテーブルテーブルレベルでのスケジューリングを一時停止するをサポートしています。
- BR はユーザーおよび権限データの復元サポートしており、バックアップと復元がよりスムーズになります。
- TiCDC特定の種類のDDLイベントをフィルタリングするフィルタリングすることをサポートすることで、より多くのデータ レプリケーション シナリオを可能にします。
SAVEPOINT機構がサポートされており、トランザクション内のロールバックポイントを柔軟に制御できます。- TiDB は1つの
ALTER TABLEステートメントだけで、複数の列またはインデックスの追加、削除、変更を行うサポートしています。 - クラスター間RawKV複製サポートされるようになりました。
新機能
SQL
物理データ圧縮機能はGAです
TiFlashのバックエンドは、特定の条件に基づいて物理データを自動的に圧縮し、不要なデータの蓄積を減らし、データストレージ構造を最適化します。
TiFlashテーブルには、データ圧縮が自動的にトリガーされる前に、一定量の不要なデータが含まれていることがよくあります。この機能を使用すると、適切なタイミングを選択してSQLステートメントを手動で実行し、 TiFlash内の物理データを即座に圧縮できるため、ストレージ容量の使用量を削減し、クエリのパフォーマンスを向上させることができます。この機能はTiDB v6.1では実験的でしたが、TiDB v6.2.0で一般提供（GA）となりました。
可観測性
TiDB DashboardをPDから分離
TiDB DashboardはPDから監視ノードに移動されました。これにより、TiDB DashboardがPDに与える影響が軽減され、PDの安定性が向上します。
TiDB Dashboardにモニタリングページが追加されました
新しいモニタリング ページには、パフォーマンス チューニングに必要な主要な指標が表示され、これに基づいてデータベース時間によるパフォーマンスチューニングを参照してパフォーマンスを分析および調整できます。
具体的には、ユーザー応答時間とデータベース時間を全体的かつトップダウンの視点から分析することで、ユーザー応答時間のボトルネックがデータベースの問題によるものかどうかを確認できます。ボトルネックがデータベースにある場合は、データベース時間の概要とSQLレイテンシーの内訳を使用してボトルネックを特定し、パフォーマンスを調整できます。
TiDB Dashboardはビジュアル実行計画をサポートしています
TiDB Dashboardは、SQLステートメントページとモニタリングページを通じて、視覚的な実行計画と基本的な診断サービスを提供します。この機能により、クエリプランの各ステップを特定するための新しい視点が得られます。そのため、クエリ実行計画のすべての痕跡をより直感的に把握できます。
この機能は、複雑で大規模なクエリの実行方法を学習する際に特に役立ちます。また、TiDB Dashboardは各クエリ実行計画について、実行の詳細を自動的に分析し、潜在的な問題点を特定し、特定のクエリプランの実行時間を短縮するための最適化提案を提供します。
Lock ビューは、楽観的トランザクションの待機情報の表示をサポートしています。
ロックの競合が多すぎると、深刻なパフォーマンスの問題を引き起こす可能性があり、そのような問題のトラブルシューティングにはロックの競合を検出することが不可欠です。v6.2.0 より前の TiDB では、
INFORMATION_SCHEMA.DATA_LOCK_WAITSシステム ビューを使用してロックの競合関係を表示することはできましたが、楽観的トランザクションの待機情報は表示されませんでした。TiDB v6.2.0 ではDATA_LOCK_WAITSビューが拡張され、悲観的ロックによってブロックされている楽観的トランザクションがビューに一覧表示されます。この機能により、ユーザーはロックの競合を迅速に検出でき、アプリケーションの改善の基礎となるため、ロックの競合の頻度を減らし、全体的なパフォーマンスを向上させることができます。
パフォーマンス
LEADINGオプティマイザヒントを改善し、外部結合の順序付けをサポートするようにしました。バージョン 6.1.0 では、テーブルの結合順序を変更するためにオプティマイザヒント
LEADINGが導入されました。しかし、このヒントは外部結合を含むクエリには適用できませんでした。詳細については、LEADING文書を参照してください。バージョン 6.2.0 では、TiDB はこの制限を解除しました。外部結合を含むクエリでも、このヒントを使用してテーブルの結合順序を指定できるようになり、SQL の実行パフォーマンスが向上し、実行計画の急激な変更を回避できます。SEMI_JOIN_REWRITEクエリのパフォーマンスを向上させるために、新しいオプティマイザEXISTSを追加します。場合によっては、
EXISTSを含むクエリは最適な実行計画を取得できず、実行時間が長くなる可能性があります。v6.2.0 では、このようなシナリオに対応するためにオプティマイザに書き換えルールが追加され、クエリ内でSEMI_JOIN_REWRITEを使用することで、オプティマイザにクエリを強制的に書き換えさせ、クエリのパフォーマンスを向上させることができます。分析クエリのパフォーマンスを向上させるために、新しいオプティマイザヒント
MERGEを追加します。共通テーブル式 (CTE) は、クエリロジックを簡素化する効果的な方法です。複雑なクエリを作成する際に広く使用されています。v6.2.0 より前のバージョンでは、 TiFlash環境で CTE を自動的に展開することができなかったため、MPP の実行効率が多少制限されていました。v6.2.0 では、MySQL 互換のオプティマイザヒント
MERGEが導入されました。このヒントにより、オプティマイザは CTE インラインを展開できるようになり、CTE クエリ結果のコンシューマーがTiFlashでクエリを並行して実行できるようになったため、一部の分析クエリのパフォーマンスが向上しました。一部の分析シナリオにおける集計操作のパフォーマンスを最適化する
TiFlash を使用して OLAP シナリオで列に対して集計操作を実行する場合、集計列の分布が不均一であるために深刻なデータスキューが発生し、集計列にさまざまな値が含まれている場合、その列に対する
COUNT(DISTINCT)クエリの実行効率が低下します。v6.2.0 では、単一の列に対するCOUNT(DISTINCT)クエリのパフォーマンスを向上させるための新しい書き換えルールが導入されました。TiDBは同時DDL操作をサポートしています
TiDB v6.2.0では、新しい同時実行DDLフレームワークが導入されました。これにより、異なるテーブルオブジェクトに対してDDLステートメントを同時実行できるようになり、他のテーブルに対するDDL操作によってDDL操作がブロックされる問題が修正されました。さらに、TiDBは、複数のテーブルにインデックスを追加したり、列の型を変更したりする際に、同時DDL実行をサポートします。これにより、DDL実行の効率が向上します。
オプティマイザは文字列マッチングの推定精度を向上させます
文字列マッチングのシナリオでは、オプティマイザが行数を正確に推定できない場合、最適な実行計画の生成に影響します。たとえば、条件が
like '%xyz'または正規表現regex ()の場合です。このようなシナリオでの推定精度を向上させるため、TiDB v6.2.0 では推定方法を強化しました。新しい方法では、統計情報とシステム変数の TopN 情報を組み合わせて精度を向上させ、マッチングの選択性を手動で変更できるようにすることで、SQL のパフォーマンスを向上させています。TiFlashにプッシュダウンされたウィンドウ関数は、複数のスレッドで実行できます。
きめ細かいシャッフル機能を有効にすると、ウィンドウ関数を単一のスレッドではなく、複数のスレッドで実行できるようになります。この機能により、ユーザーの操作を変更することなく、クエリの応答時間を大幅に短縮できます。変数の値を調整することで、シャッフルの粒度を制御できます。
TiFlashは、より新しいバージョンのストレージフォーマットをサポートしています。
新しいストレージフォーマットは、高並列処理や高負荷なワークロード環境において、ガベージコレクション（GC）によって引き起こされるCPU使用率の上昇を緩和します。これにより、バックグラウンドタスクのI/Oトラフィックが大幅に削減され、高並列処理や高負荷なワークロード環境下での安定性が向上します。同時に、ディスク容量の増大やディスクの無駄遣いも大幅に削減できます。
TiDB v6.2.0では、データはデフォルトで新しいストレージ形式で保存されます。TiFlashを以前のバージョンからv6.2.0にアップグレードする場合、以前のTiFlashバージョンでは新しいストレージ形式を認識できないため、 TiFlash上でインプレースダウングレードを実行することはできませんのでご注意ください。
TiFlash のアップグレードの詳細については、 TiFlashアップグレードガイドを参照してください。
TiFlashは、複数の同時実行シナリオにおけるデータスキャン性能を最適化します（実験的）。
TiFlashは、同一データの読み取り操作を統合することで、同一データの重複読み取りを削減し、複数の同時タスクにおけるリソースオーバーヘッドを最適化することで、データスキャン性能を向上させます。これにより、同一データが複数の同時タスクに関与する場合に、各タスクで同一データを個別に読み取る必要が生じたり、同一データが同時に複数回読み取られたりする状況を回避します。
TiFlashは、データの一貫性を犠牲にして読み書き速度を向上させるため、データスキャン用のFastScan機能を追加しました（実験的）。
TiDBはv6.2.0でFastScanを導入しました。FastScanは整合性チェックをスキップすることで処理速度を大幅に向上させます。FastScanは、オフライン分析タスクなど、データの高精度や整合性が求められないシナリオに適しています。従来、 TiFlashはデータの整合性を確保するために、データスキャン処理中にデータの整合性チェックを実行し、複数の異なるバージョンから必要なデータを見つける必要がありました。
TiDB v6.2.0 に以前のバージョンからアップグレードすると、データの一貫性を確保するために、すべてのテーブルで FastScan がデフォルトで有効になりません。FastScan は各テーブルごとに個別に有効にできます。TiDB v6.2.0 で FastScan が有効になっているテーブルは、それより低いバージョンにダウングレードすると無効になりますが、通常のデータ読み取りには影響しません。この場合、強力な一貫性読み取りと同等になります。
安定性
TiKVはCPU使用率の自動調整をサポートしています（実験的）。
データベースは通常、内部処理を実行するためのバックグラウンドプロセスを備えています。統計情報を収集することで、パフォーマンスの問題を特定し、より適切な実行計画を作成し、データベースの安定性とパフォーマンスを向上させることができます。しかし、より効率的に情報を収集する方法、そして日常的な利用に影響を与えずにバックグラウンド処理とフォアグラウンド処理のリソースオーバーヘッドのバランスを取る方法は、データベース業界における長年の課題の一つでした。
バージョン6.2.0以降、TiDBはTiKV設定ファイルを使用してバックグラウンドリクエストのCPU使用率を設定できるようになりました。これにより、TiKVでの統計情報の自動収集などのバックグラウンド操作のCPU使用率を制限し、極端な場合にバックグラウンド操作によるユーザー操作のリソース占有を回避できます。これにより、データベースの操作の安定性と効率性が確保されます。
同時に、TiDBはCPU使用率の自動調整もサポートしています。TiKVは、インスタンスのCPU使用率に応じて、バックグラウンドリクエストが占めるCPUリソースを適応的に調整します。この機能はデフォルトでは無効になっています。
使いやすさ
TiKVは、コマンドラインフラグを使用して詳細な設定情報を一覧表示することをサポートしています。
TiKV 設定ファイルは、TiKV インスタンスの管理に使用できます。しかし、長時間実行され、複数のユーザーによって管理されているインスタンスの場合、どの設定項目が変更されたか、デフォルト値は何かを把握するのは困難です。これは、クラスタのアップグレードやデータの移行時に混乱を招く可能性があります。TiDB v6.2.0 以降、tikv-server は、すべての TiKV 設定項目のデフォルト値と現在の値を一覧表示する新しいコマンドラインフラグ
—-config-infoをサポートしており、TiKV プロセスの起動パラメータをユーザーがすばやく確認できるようになり、使いやすさが向上します。
MySQLとの互換性
TiDBは、単一の
ALTER TABLEステートメントで複数の列またはインデックスを変更することをサポートしています。バージョン6.2.0より前は、TiDBは単一のDDL変更のみをサポートしていたため、異種データベースを移行する際にDDL操作の互換性が損なわれ、複雑なDDLステートメントをTiDBがサポートする複数の単純なDDLステートメントに変換するには余分な労力が必要でした。さらに、一部のユーザーはORMフレームワークを使用してSQLでアセンブリを作成していたため、SQLの互換性の問題も発生していました。バージョン6.2.0以降、TiDBは単一のSQLステートメントで複数のスキーマオブジェクトを変更できるようになり、ユーザーにとってSQLの実装が容易になり、使いやすさが向上しました。
トランザクションにおけるセーブポイントの設定をサポートする
トランザクションとは、データベースがACID特性を保証する一連の連続した操作の論理的な集合です。複雑なアプリケーションシナリオでは、トランザクション内で多数の操作を管理する必要があり、場合によってはトランザクション内の操作をロールバックする必要が生じることもあります。「セーブポイント」は、トランザクションの内部実装のための名前付きメカニズムです。このメカニズムを使用することで、トランザクション内のロールバックポイントを柔軟に制御でき、より複雑なトランザクションを管理し、多様なアプリケーション設計においてより自由度を高めることができます。
データ移行
BRはユーザーデータと権限データの復元をサポートしています
BR は、通常の復元を実行する際に、ユーザーデータと権限データの復元をサポートします。ユーザーデータと権限データを復元するために、追加の復元プランは必要ありません。この機能を有効にするには、 BRを使用してデータを復元する際に
--with-sys-tableパラメーターを指定してください。ログとスナップショットのバックアップと復元に基づくポイントインタイムリカバリ（PITR）をサポートします。
PITRは、ログとスナップショットのバックアップおよび復元に基づいて実装されています。これにより、クラスタの履歴上の任意の時点のスナップショットを新しいクラスタに復元できます。この機能は、以下のニーズを満たします。
- ディザスタリカバリにおけるRPO（目標復旧時点）を20分未満に短縮する。
- アプリケーションからの書き込みエラーが発生した場合は、例えば、エラー発生前の状態にデータをロールバックするなどの方法で対処します。
- 法令の要件を満たすため、履歴データの監査を実施する。
この機能には使用上の制限があります。詳細はユーザーマニュアルを参照してください。
DMは継続的なデータ検証をサポートします（実験的）
継続的なデータ検証は、データ移行中に上流のbinlogと下流に書き込まれたデータを継続的に比較するために使用されます。検証ツールは、データの不整合やレコードの欠落など、データの例外を特定します。
この機能は、一般的な完全データ検証方式における検証の遅延や過剰なリソース消費といった問題を解決します。
Amazon S3バケットのリージョンを自動的に識別する
データ移行タスクでは、Amazon S3バケットのリージョンを自動的に識別できます。リージョンパラメータを明示的に渡す必要はありません。
TiDB Lightningのディスククォータ設定をサポート（実験的）
TiDB Lightning が物理インポートモード (backend='local') でデータをインポートする場合、
sorted-kv-dirにはソースデータを格納するのに十分な空き容量が必要です。ディスク容量が不足すると、インポートタスクが失敗する可能性があります。TiDB Lightning が使用するディスク容量の合計を制限するために、新しいdisk_quota設定を使用すれば、sorted-kv-dirに十分なストレージ容量がない場合でも、インポートタスクを正常に完了できます。TiDB Lightningは、物理インポートモードでの本番クラスタへのデータインポートをサポートしています。
従来、 TiDB Lightningの物理インポートモード（backend='local'）は、対象クラスタに大きな影響を与えていました。例えば、移行中にPDのグローバルスケジューリングが一時停止されるといった問題がありました。そのため、従来の物理インポートモードは、初期データインポートにのみ適していました。
TiDB Lightningは、既存の物理インポートモードを改良しました。テーブルのスケジュールを一時停止できるようにすることで、インポートの影響をクラスタレベルからテーブルレベルにまで軽減します。つまり、インポートされていないテーブルの読み書きが可能になります。
この機能には手動設定は不要です。TiDBクラスタがv6.1.0以降、かつTiDB Lightningがv6.2.0以降の場合、新しい物理インポートモードは自動的に有効になります。
TiDB Lightningのユーザー向けドキュメントドキュメントをリファクタリングして、その構造をより合理的かつ明確にします。 「バックエンド」の用語も、新規ユーザーの理解の障壁を下げるために変更されています。
- 「ローカルバックエンド」を「物理インポートモード」に置き換えてください。
- 「tidb backend」を「logical import mode」に置き換えてください。
TiDBデータ共有サブスクリプション
クラスター間RawKVレプリケーションのサポート（実験的）
新しいコンポーネントTiKV-CDCを使用して、RawKVのデータ変更を購読し、そのデータ変更を下流のTiKVクラスタにリアルタイムで複製することをサポートします。これにより、クラスタ間の複製が可能になります。
DDLおよびDMLイベントのフィルタリングをサポートします。
特別な状況では、増分データ変更ログに対してフィルタルールを設定したい場合があります。たとえば、DROP TABLEなどの高リスクなDDLイベントをフィルタリングする場合などです。TiCDCはバージョン6.2.0以降、指定されたタイプのDDLイベントのフィルタリングと、SQL式に基づくDMLイベントのフィルタリングをサポートしています。これにより、TiCDCはより多くのデータレプリケーションシナリオに適用可能になります。
互換性の変更
システム変数
コンフィグレーションファイルパラメータ
その他
- TiFlash
format_version4から3にダウングレードすることはできません。詳細については、 TiFlashアップグレードガイドを参照してください。 - バージョン6.2.0以降では、デフォルト値の
falseをdt_enable_logical_splitのままにして、trueに変更しないことを強くお勧めします。詳細は、既知の問題#5576を参照してください。 - バックアップ クラスタにTiFlashレプリカがある場合、PITR を実行すると、リストア クラスタにはTiFlashレプリカ内のデータが含まれません。TiFlash レプリカからデータをリストアするには、 TiFlashレプリカを手動で構成する必要があります。
exchange partitionDDL ステートメントを実行すると、PITR が失敗する可能性があります。アップストリームデータベースが TiDB Lightning の物理インポート モードを使用してデータをインポートする場合、ログ バックアップでデータをバックアップできません。データ インポート後にフル バックアップを実行することをお勧めします。PITR のその他の互換性の問題については、 PITRの制限を参照してください。 - TiDB v6.2.0以降では、データ復元時に
mysqlパラメータを指定することで--with-sys-table=trueスキーマのテーブルを復元できます。 ALTER TABLEステートメントを実行して複数の列またはインデックスを追加、削除、または変更する場合、TiDB は同じ DDL ステートメントの変更内容に関わらず、ステートメント実行前後のテーブルを比較してテーブルの一貫性をチェックします。DDL の実行順序は、シナリオによっては MySQL と完全には互換性がない場合があります。- TiDBコンポーネントがv6.2.0以降の場合、TiKVコンポーネントはv6.2.0より前のバージョンであってはなりません。
- TiKV は動的構成をサポートする構成アイテム
split.region-cpu-overload-threshold-ratioを追加します。 - スロークエリログ、
information_schema.statements_summary、およびinformation_schema.slow_queryはbinary_plan、またはバイナリ形式でエンコードされた実行計画をエクスポートできます。 SHOW TABLE ... REGIONSステートメントに、SCHEDULING_CONSTRAINTSとSCHEDULING_STATE2 つの列が追加されます。これらはそれぞれ、SQL の配置におけるリージョンスケジューリング制約と現在のスケジューリング状態を示します。- TiDB v6.2.0以降では、 TiKV-CDCを介してRawKVのデータ変更をキャプチャできます。
ROLLBACK TO SAVEPOINTを使用してトランザクションを特定のセーブポイントまでロールバックする場合、MySQL は指定されたセーブポイント以降に保持されているロックのみを解放しますが、TiDB の悲観的トランザクションでは、TiDB は指定されたセーブポイント以降に保持されているロックをすぐには解放しません。代わりに、TiDB はトランザクションがコミットまたはロールバックされたときにすべてのロックを解放します。- TiDB v6.2.0以降、
SELECT tidb_version()ステートメントはストアタイプ（tikvまたはunistore）も返します。 - TiDBには隠しシステム変数はなくなりました。
- TiDB v6.2.0では、2つの新しいシステムテーブルが導入されました。
INFORMATION_SCHEMA.VARIABLES_INFO: TiDB システム変数に関する情報を表示するために使用されます。PERFORMANCE_SCHEMA.SESSION_VARIABLES: TiDB セッションレベルのシステム変数に関する情報を表示するために使用されます。
削除された機能
TiDB v6.2.0以降、 BRを使用したRawKVのバックアップと復元は非推奨となりました。
改善点
TiDB
SHOW COUNT(*) WARNINGSおよびSHOW COUNT(*) ERRORSステートメントのサポート #25068 @likznSHOW TABLES/DATABASES LIKE …の出力を MySQL とより互換性のあるものにしてください。出力の列名にはLIKEの値が含まれています #35116 @likznJSON関連関数のパフォーマンスを改善する #35859 @wjhuang2016
SHA-2を使用したパスワードログインの検証速度を向上 #35998 @virusdefender
コプロセッサー通信プロトコルを最適化します。これにより、TiDB プロセスがデータを読み取る際のメモリ消費量を大幅に削減し、Dumplingによるテーブルのスキャンとデータのエクスポートのシナリオにおける OOM 問題をさらに軽減できます。システム変数
tidb_enable_pagingを導入し、この通信プロトコルを有効にするかどうか (SESSION または GLOBAL のスコープで) を制御します。このプロトコルはデフォルトでは無効になっています。有効にするには、変数の値をtrueに設定します。 #35633 @tiancaiamao@wshwsh12一部の演算子 (HashJoin、HashAgg、Update、Delete) のメモリ追跡の精度を最適化しました ( #35634 、 #35631 、 #35635 @wshwsh12 ) ( #34096 @ekexium)
システム テーブル
INFORMATION_SCHEMA.DATA_LOCK_WAIT楽観的トランザクションのロック情報の記録をサポートしています #34609 @longfangsongトランザクションの監視メトリクスを追加 #34456 @longfangsong
TiKV
- HTTPボディサイズを削減するために、gzipを使用してメトリクスレスポンスを圧縮するサポート #12355 @glorv
- Grafana ダッシュボードの TiKV パネルの読みやすさを改善 #12007 @kevin-xianliu
- Applyオペレーターのコミットパイプラインのパフォーマンスを最適化する #12898 @ethercflow
- RocksDB で同時に実行されるサブコンパクション操作の数を動的に変更する機能のサポート (
rocksdb.max-sub-compactions) #13145 @ethercflow
PD
TiFlash
TiFlash MPP エンジンのエラー処理を改良し、安定性を向上 #5095 @windtalker @yibin87
ツール
Backup & Restore (BR)
- 大規模クラスタバックアップにおけるS3レート制限によるバックアップ失敗を修正するため、バックアップデータディレクトリ構造を調整しました #30087 @MoCuishle28
TiCDC
TiDB Lightning
TiUP
バグ修正
TiDB
- クエリ条件でパーティションキーが使用され、照合順序がクエリパーティションテーブルのものと異なる場合に、パーティションが正しく削除されない問題を修正します #32749 @mjonss
SET ROLEホストに大文字が含まれている場合に付与されたロールと一致しない問題を修正 #33061 @morgoauto_incrementを持つ列を削除できない問題を修正 #34891 @Defined2014SHOW CONFIGに削除された設定項目が表示される問題を修正 #34867 @morgoSHOW DATABASES LIKE …が大文字と小文字を区別する問題を修正 #34766 @e1ijah1SHOW TABLE STATUS LIKE ...が大文字小文字を区別する問題を修正 #7518 @likznmax-index-length非厳格モードでエラーを報告する問題を修正 #34931 @e1ijah1ALTER COLUMN ... DROP DEFAULTが機能しない問題を修正 #35018 @Defined2014- テーブル作成時に、デフォルト値と列の型が一致せず、自動的に修正されない問題を修正しました #34881 @Lloyd-Pottiger
mysql.columns_privを実行した後、DROP USERテーブルのデータが同期的に削除されない問題を修正しました #35059 @lcwangchao- 一部のシステムのスキーマ内でテーブルを作成することを禁止することで、DDL ジャムの問題を修正します #35205 @tangenta
- パーティション化されたテーブルをクエリした際に、場合によっては「index-out-of-range」および「non used index」エラーが報告される問題を修正しました #35181 @mjonss
INTERVAL expr unit + exprがエラーを報告する可能性がある問題を修正 #30253 @mjonss- トランザクション内で作成された一時テーブルが見つからないバグを修正 #35644 @djshow832
ENUM列に照合順序を設定する際に発生するpanic問題を修正しました #31637 @wjhuang2016- PDノードが1つダウンした際に、他のPDノードを再試行しないために
information_schema.TIKV_REGION_STATUSのクエリが失敗する問題を修正しました #35708 @tangenta SHOW CREATE TABLE …がENUMの後にセットまたはSET character_set_results = GBK列を正しく表示できない問題 #31338 @tangenta- システム変数
tidb_log_file_max_daysとtidb_configのスコープの誤りを修正 #35190 @morgo SHOW CREATE TABLEの出力が、ENUMまたはSET列の MySQL と互換性がない問題を修正します #36317 @Defined2014- テーブル作成時に
LONG BYTE列の動作が MySQL と互換性がない問題を修正しました #36239 @Defined2014 auto_increment = xが一時テーブルに適用されない問題を修正 #36224 @djshow832- 列を同時に変更する際の誤ったデフォルト値を修正 #35846 @wjhuang2016
- 可用性を向上させるために、異常な TiKV ノードにリクエストを送信しないようにします #34906 @sticnarf
- LOAD DATA ステートメントで列リストが機能しない問題を修正 #35198 @SpadeA-Tang
- 一部のシナリオで悲観的ロックが非一意のセカンダリインデックスに誤って追加される問題を修正 #36235 @ekexium
TiKV
- 悲観的トランザクションで
WriteConflictエラーを報告しないようにします #11612 @sticnarf - 非同期コミットが有効になっている場合に、悲観的トランザクションで発生する可能性のある重複コミット レコードを修正 #12615 @sticnarf
storage.api-versionを1から2に変更した際に TiKV がパニック #12600 @pingyu- TiKVとPD間のリージョンサイズ構成の不整合の問題を修正 #12518 @5kbpers
- TiKV が PD クライアントに再接続し続ける問題を修正#12506 、 #12827 @Connor1996
- TiKVが空文字列の型変換時にパニックを起こす問題を修正 #12673 @wshwsh12
DATETIMEの値に小数が含まれている場合とZの値が含まれている場合に発生する時間解析エラーの問題を修正しました #12739 @gengliqi- Apply オペレーターが TiKV RocksDB に書き込む perf コンテキストが粗粒度である問題を修正 #11044 @LykxSassinator
- バックアップ/インポート/ CDCの設定が無効な場合にTiKVが起動できない問題を修正 #12771 @3pointer
- ピアが分割され、同時に破棄される際に発生する可能性のあるpanic問題を修正 #12825 @BusyJay
- リージョンマージプロセスでソースピアがスナップショットによってログを追いついたときに発生する可能性のpanic問題を修正 #12663 @BusyJay
max_sample_sizeが0に設定されている場合に統計分析で発生するpanic問題を修正 #11192 @LykxSassinator- Raft Engineが有効になっているときに暗号化キーがクリーンアップされない問題を修正 #12890 @tabokie
get_valid_int_prefix関数が TiDB と互換性がない問題を修正します。例えば、FLOAT型がINTに誤って変換されていました #13045 @guo-shaoge- 新しいリージョンのコミットログ期間が長すぎるためにQPSが低下する問題を修正しました #13077 @Connor1996
- リージョンのハートビートが中断された後、PD が TiKV に再接続しない問題を修正 #12934 @bufferflies
- 悲観的トランザクションで
ツール
Backup & Restore (BR)
- レート制限付きバックアップタスク完了後にBRがレート制限をリセットしない問題を修正 #31722 @MoCuishle28
貢献者
TiDBコミュニティの以下の貢献者の皆様に感謝申し上げます。