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