TiDB 8.1.0 リリースノート
発売日: 2024年5月24日
TiDB バージョン: 8.1.0
クイックアクセス: クイックスタート | 実稼働環境への導入
TiDB 8.1.0 は長期サポートリリース (LTS) です。
以前の LTS 7.5.0 と比較して、8.1.0 には7.6.0-DMRおよび8.0.0-DMRでリリースされた新機能、改善、バグ修正が含まれています。7.5.x から 8.1.0 にアップグレードする場合、 TiDB リリースノート PDFをダウンロードして、2 つの LTS バージョン間のすべてのリリース ノートを表示できます。次の表に、7.6.0 から 8.1.0 への主な変更点を示します。
カテゴリー | 機能/拡張機能 | 説明 |
---|---|---|
スケーラビリティとパフォーマンス | クラスター スナップショットの復元速度の高速化(v8.0.0 で GA) | この機能により、 BR はクラスターのスケールの利点を最大限に活用し、クラスター内のすべての TiKV ノードがデータ復元の準備ステップに参加できるようになります。この機能により、大規模クラスター内の大規模データセットの復元速度が大幅に向上します。実際のテストでは、この機能によりダウンロード帯域幅が飽和し、ダウンロード速度が 8 ~ 10 倍、エンドツーエンドの復元速度が約 1.5 ~ 3 倍向上することが示されています。 |
バッチでテーブルを作成する場合、最大 10 倍の速度を実現します(実験的、v7.6.0 で導入) | v7.6.0 で新しい DDLアーキテクチャが実装されたことで、バッチ テーブル作成のパフォーマンスが著しく向上し、最大 10 倍高速化しました。この大幅な機能強化により、多数のテーブルの作成に必要な時間が大幅に短縮されます。この高速化は、数万から数十万に及ぶ大量のテーブルが一般的に存在する SaaS シナリオで特に顕著です。 | |
アクティブ PD フォロワーを使用して PD のリージョン情報クエリ サービスを強化します(実験的、v7.6.0 で導入) | TiDB v7.6.0 では、PD フォロワーがリージョン情報クエリ サービスを提供できるようにする実験的機能「Active PD Follower 」が導入されています。この機能により、多数の TiDB ノードとリージョンを持つクラスターでGetRegion およびScanRegions 要求を処理する PD クラスターの機能が向上し、PD リーダーの CPU 負荷が軽減されます。 | |
より大規模なトランザクションのためのバルク DML (実験的、v8.0.0 で導入) | 大規模なクリーンアップ ジョブ、結合、集計などの大規模なバッチ DML ジョブは、大量のメモリを消費する可能性があり、これまでは非常に大規模な規模で制限されていました。バルク DML ( tidb_dml_type = "bulk" ) は、トランザクション保証を提供し、OOM の問題を軽減しながら、大規模なバッチ DML タスクをより効率的に処理するための新しい DML タイプです。この機能は、データのロードに使用する場合、インポート、ロード、および復元操作とは異なります。 | |
膨大な数のテーブルがある場合のスキーマ情報のキャッシュの安定性を向上 (実験的、v8.0.0 で導入) | マルチテナント アプリケーションの記録システムとして TiDB を使用している SaaS 企業は、多くの場合、相当数のテーブルを保存する必要があります。以前のバージョンでは、100 万以上のテーブル数を処理することは可能でしたが、全体的なユーザー エクスペリエンスが低下する可能性がありました。TiDB v8.0.0 では、次の機能強化により状況が改善されています。
| |
信頼性と可用性 | グローバル ソート(v8.0.0 で GA) | グローバル ソート機能はIMPORT INTO およびCREATE INDEX の安定性と効率性を向上させることを目的としています。処理するデータをグローバルにソートすることで、この機能は TiKV へのデータ書き込みの安定性、制御性、およびスケーラビリティを向上させ、結果としてデータのインポートとインデックス作成のユーザー エクスペリエンスとサービス品質を高めます。グローバル ソートを有効にすると、各IMPORT INTO またはCREATE INDEX ステートメントは、最大 40 TiB のデータのインポートまたはインデックスの追加をサポートするようになりました。 |
クロスデータベース SQL バインディング(v7.6.0 で導入) | 同じスキーマを持つ数百のデータベースを管理する場合、これらのデータベース全体に SQL バインディングを適用する必要があることがよくあります。たとえば、SaaS または PaaS データ プラットフォームでは、各ユーザーは通常、同じスキーマを持つ個別のデータベースを操作し、それらに対して同様の SQL クエリを実行します。この場合、各データベースに SQL を 1 つずつバインドするのは現実的ではありません。TiDB v7.6.0 では、すべてのスキーマが同等のデータベース間でバインディングを一致させることができるデータベース間 SQL バインディングが導入されています。 | |
TiProxy をサポート(v8.0.0 で GA) | デプロイメント ツールを使用して簡単にデプロイできる TiProxy サービスを完全にサポートし、ローリング再起動、アップグレード、またはスケーリング イベントを通じて TiDB への接続を管理および維持します。 | |
データ移行 (DM) は MySQL 8.0 (v7.6.0 で GA) を正式にサポートします | これまで、DM を使用して MySQL 8.0 からデータを移行することは実験的機能であり、本番環境では使用できませんでした。TiDB v7.6.0 では、この機能の安定性と互換性が強化され、本番環境で MySQL 8.0 から TiDB にデータをスムーズかつ迅速に移行できるようになります。v7.6.0 では、この機能が一般提供 (GA) されます。 | |
TiDB リソース制御は、予想よりも多くのリソースを消費するクエリの管理をサポートします (v8.1.0 で GA) | TiDB は、リソース グループのルールを通じて、予想よりも多くのリソースを消費するクエリを自動的に識別し、これらのクエリを制限またはキャンセルできます。ルールによってクエリが識別されない場合でも、クエリ特性を手動で追加し、対応する対策を講じて、突然のクエリ パフォーマンスの問題がデータベース全体に与える影響を軽減できます。 | |
DB 操作と可観測性 | インデックス使用統計の監視をサポート (v8.0.0 で導入) | 適切なインデックス設計は、データベースのパフォーマンスを維持するための重要な前提条件です。TiDB v8.0.0 では、インデックスの使用統計を提供するINFORMATION_SCHEMA.TIDB_INDEX_USAGE テーブルとsys.schema_unused_indexes ビューが導入されています。この機能は、データベース内のインデックスの効率を評価し、インデックス設計を最適化するのに役立ちます。 |
データ移行 | TiCDC はシンプル プロトコル(v8.0.0 で導入) をサポートしています。 | TiCDC では、新しいプロトコルである Simple プロトコルが導入されています。このプロトコルは、DDL および BOOTSTRAP イベントにテーブル スキーマ情報を埋め込むことで、インバンド スキーマ追跡機能を提供します。 |
TiCDC はDebezium 形式プロトコル(v8.0.0 で導入) をサポートしています。 | TiCDC は、新しいプロトコルである Debezium プロトコルを導入しました。TiCDC は、Debezium スタイルのメッセージを生成するプロトコルを使用して、データ変更イベントを Kafka シンクに公開できるようになりました。 | |
TiCDC はクライアント認証をサポートしています (v8.1.0 で導入) | TiCDC は、相互トランスポート層Security(mTLS) または TiDB ユーザー名とパスワードを使用したクライアント認証をサポートしています。この機能により、CLI または OpenAPI クライアントは TiCDC への接続を認証できます。 |
機能の詳細
信頼性
予想よりも多くのリソースを消費するクエリの管理をサポート (GA) #43691 @ ノルーシュ
突然の SQL クエリ パフォーマンスの問題は、データベース全体のパフォーマンスの低下を引き起こす可能性があり、これはデータベースの安定性に対する最も一般的な課題です。これらの問題の原因は、テストされていない新しい SQL ステートメント、データ量の大幅な変更、実行プランの突然の変更など、多岐にわたります。これらの問題をソースで完全に回避することは困難です。TiDB v7.2.0 では、予想よりも多くのリソースを消費するクエリを管理して、突然のクエリ パフォーマンスの問題の影響を迅速に軽減する機能が導入されました。この機能は、v8.1.0 で一般提供されます。
リソース グループ内のクエリの最大実行時間を設定できます。クエリの実行時間が設定値を超えると、クエリの優先度が自動的に下げられるか、クエリがキャンセルされます。また、問題のあるクエリの同時実行が高すぎる場合に識別フェーズで過剰なリソース消費を回避するために、一定期間内にテキストまたは実行プランを通じて特定されたクエリにすぐに一致するように設定することもできます。
TiDB は、クエリの手動マークもサポートして
QUERY WATCH
ます。1 コマンドを使用すると、SQL テキスト、SQL ダイジェスト、または実行プランに基づいてクエリをマークできます。マークに一致するクエリはダウングレードまたはキャンセルでき、SQL ブロックリストを追加する目的を達成できます。予想よりも多くのリソースを消費するクエリの自動管理機能により、根本原因が特定される前にクエリの問題が全体的なパフォーマンスに与える影響を迅速に軽減する効果的な手段がユーザーに提供され、データベースの安定性が向上します。
詳細についてはドキュメンテーション参照してください。
構文
テーブルの作成時にデフォルトの列値を設定する式をさらにサポート (GA) #50936 @ ジムララ
v8.0.0 より前では、テーブルを作成するときに、列のデフォルト値は文字列、数値、日付、および特定の式に制限されていました。v8.0.0 以降では、デフォルトの列値としてさらに多くの式を使用できます。たとえば、列のデフォルト値を
DATE_FORMAT
に設定できます。この機能により、より多様な要件を満たすことができます。v8.1.0 では、この機能が GA になります。v8.1.0 以降では、列を
ADD COLUMN
ずつ追加するときに、式をデフォルト値として使用できます。詳細についてはドキュメンテーション参照してください。
DB操作
デフォルトで TiDB 分散実行フレームワーク (DXF) を有効にして、並列実行#52441 @ D3ハンターで
ADD INDEX
またはIMPORT INTO
のタスクのパフォーマンスと安定性を向上させます。DXF は v7.5.0 で一般提供 (GA) されますが、デフォルトでは無効になっています。つまり、
ADD INDEX
またはIMPORT INTO
タスクは、デフォルトでは 1 つの TiDB ノードによってのみ実行されます。v8.1.0 以降、TiDB はデフォルトでこの機能を有効にします (
tidb_enable_dist_task
デフォルトはON
です)。有効にすると、DXF は複数の TiDB ノードをスケジュールして、同じADD INDEX
またはIMPORT INTO
タスクを並行して実行し、TiDB クラスターのリソースを最大限に活用して、これらのタスクのパフォーマンスを大幅に向上させることができます。さらに、TiDB ノードを追加し、新しく追加されたノードにtidb_service_scope
を構成することで、ADD INDEX
およびIMPORT INTO
タスクのパフォーマンスを直線的に向上させることができます。詳細についてはドキュメンテーション参照してください。
Security
TiDB ログ感度低下 (GA) #52364 @ xheboxを強化
強化された TiDB ログの非感度化は、ユーザーがログを表示するときに機密データを削除することをサポートします。これは、ログ ファイル内の SQL テキスト情報をマークすることによって実装されます。ログ情報をマークするかどうかを制御して、さまざまなシナリオで TiDB ログを安全に使用できるようにすることで、ログの非感度化を使用する際のセキュリティと柔軟性が向上します。この機能を使用するには、システム変数
tidb_redact_log
をMARKER
に設定すると、TiDB のランタイム ログ内の SQL テキストがマークされます。さらに、TiDBサーバーでcollect-log
サブコマンドを使用して、マークされた機密データをログから削除し、ログを安全な方法で表示できます。すべてのマーカーを削除して通常のログを取得することもできます。この機能は、v8.1.0 で一般提供されました。詳細についてはドキュメンテーション参照してください。
データ移行
IMPORT INTO ... FROM SELECT
構文(GA) #49883 @ D3ハンターをサポートv8.0.0 より前では、クエリ結果をターゲット テーブルにインポートするには
INSERT INTO ... SELECT
ステートメントを使用するしかなく、これは一部の大規模データセット シナリオでは比較的非効率的でした。v8.0.0 では、TiDB はIMPORT INTO ... FROM SELECT
実験的機能として導入し、SELECT
クエリの結果を空の TiDB ターゲット テーブルにインポートできるようになりました。これにより、INSERT INTO ... SELECT
の最大 8 倍のパフォーマンスが実現され、インポート時間が大幅に短縮されます。さらに、IMPORT INTO ... FROM SELECT
使用して、AS OF TIMESTAMP
でクエリされた履歴データをインポートできます。v8.1.0 では、
IMPORT INTO ... FROM SELECT
構文が一般提供 (GA) され、IMPORT INTO
ステートメントの機能シナリオが強化されます。詳細についてはドキュメンテーション参照してください。
TiDB Lightningは競合解決戦略を簡素化し、
replace
戦略(GA) #51036 @ 翻訳者を使用して競合するデータの処理をサポートします。v8.0.0 より前のTiDB Lightningには、論理インポート モードが1つのデータ競合解決戦略 、物理インポート モード2つのデータ競合解決戦略あり、理解して構成するのは簡単ではありません。
v8.0.0 では、 TiDB Lightning は物理インポート モードの競合検出の旧バージョン戦略を非推奨にし、
conflict.strategy
パラメータ (実験的) を介して論理インポート モードと物理インポート モードの両方の競合検出戦略を制御できるようにし、このパラメータの構成を簡素化しました。さらに、物理インポート モードでは、インポート時に主キーまたは一意キーの競合のあるデータが検出された場合に、replace
戦略で最新のデータを保持し、古いデータを上書きすることがサポートされます。v8.1.0 では、replace
戦略で競合するデータを処理する機能が一般提供 (GA) されます。詳細についてはドキュメンテーション参照してください。
TiCDCはクライアント認証#10636 @ チャールズ・チュン96をサポートします
v8.1.0 では、TiCDC は、TiCDC CLI または OpenAPI を使用しているときにクライアント認証をサポートします。この機能により、クライアント証明書を使用したクライアント認証を要求するように TiCDC を構成し、相互トランスポート層Security(mTLS) を確立できます。さらに、TiDB のユーザー名とパスワードに基づいて認証を構成することもできます。
詳細についてはドキュメンテーション参照してください。
互換性の変更
注記:
このセクションでは、v8.0.0 から現在のバージョン (v8.1.0) にアップグレードするときに知っておく必要のある互換性の変更について説明します。v7.6.0 以前のバージョンから現在のバージョンにアップグレードする場合は、中間バージョンで導入された互換性の変更も確認する必要がある可能性があります。
行動の変化
- 以前のバージョンでは、 TiDB Lightningの
tidb.tls
構成項目は、値"false"
と""
同様に扱い、値"preferred"
と"skip-verify"
同様に扱いました。 v8.1.0 以降、 TiDB Lightning はtidb.tls
に対して"false"
、""
、"skip-verify"
、および"preferred"
の動作を区別します。 詳細については、 TiDB Lightning構成を参照してください。 AUTO_ID_CACHE=1
のテーブルの場合、TiDB は集中型自動増分ID割り当てサービスサポートします。以前のバージョンでは、このサービスのプライマリ TiDB ノードは、TiDB プロセスが終了すると (たとえば、TiDB ノードの再起動中)、自動的にforceRebase
操作を実行して、自動割り当て ID が可能な限り連続した状態を維持していました。ただし、AUTO_ID_CACHE=1
のテーブルが多すぎると、forceRebase
実行に非常に時間がかかり、TiDB がすぐに再起動できなくなり、データの書き込みがブロックされて、システムの可用性に影響します。この問題を解決するために、v8.1.0 以降、TiDB はforceRebase
動作を削除しますが、この変更により、フェイルオーバー中に自動割り当て ID が連続しなくなります。
システム変数
変数名 | タイプを変更 | 説明 |
---|---|---|
tidb_auto_analyze_ratio | 修正済み | 値の範囲を[0, 18446744073709551615] から(0, 1] に変更します。 |
tidb_enable_dist_task | 修正済み | デフォルト値をOFF からON に変更します。これは、Distributed eXecution Framework (DXF) がデフォルトで有効になっていることを意味します。これにより、TiDB クラスターのリソースが十分に活用され、 ADD INDEX およびIMPORT INTO タスクのパフォーマンスが大幅に向上します。DXF が有効になっているクラスターを v8.1.0 以降にアップグレードする場合は、アップグレード前に DXF を無効にします ( tidb_enable_dist_task をOFF に設定)。これにより、アップグレード中にADD INDEX 操作が行われてデータ インデックスの不整合が発生するのを回避できます。アップグレード後に、DXF を手動で有効にできます。 |
tidb_service_scope | 修正済み | オプションの値を"" またはbackground から最大 64 文字の文字列に変更します。これにより、各 TiDB ノードのサービス スコープをより柔軟に制御できます。有効な文字は、数字0-9 、文字a-zA-Z 、アンダースコア_ 、ハイフン- です。Distributed eXecution Framework (DXF) は、この変数の値に基づいて、分散タスクを実行するようにスケジュールできる TiDB ノードを決定します。具体的なルールについては、 タスクのスケジュールを参照してください。 |
コンフィグレーションファイルのパラメータ
コンフィグレーションファイル | コンフィグレーションパラメータ | タイプを変更 | 説明 |
---|---|---|---|
ティビ | concurrently-init-stats | 新しく追加された | TiDB の起動時に統計を同時に初期化するかどうかを制御します。デフォルト値はfalse です。 |
TiDB Lightning | conflict.max-record-rows | 修正済み | v8.1.0 以降では、ユーザー入力に関係なく、 TiDB Lightning がconflict.max-record-rows の値にconflict.threshold の値を自動的に割り当てるため、 conflict.max-record-rows 手動で構成する必要はありません。 conflict.max-record-rows 将来のリリースで廃止される予定です。 |
TiDB Lightning | conflict.threshold | 修正済み | デフォルト値を9223372036854775807 から10000 に変更して、異常なタスクをすぐに中断し、対応する調整をできるだけ早く行えるようにします。これにより、異常なデータ ソースや不正なテーブル スキーマ定義が原因で、インポート後に大量の競合データが発見されるシナリオを回避し、時間と計算リソースを節約できます。 |
ティCDC | security.client-allowed-user | 新しく追加された | クライアント認証に許可されるユーザー名を一覧表示します。このリストにないユーザー名による認証要求は拒否されます。デフォルト値は null です。 |
ティCDC | security.client-user-required | 新しく追加された | クライアント認証にユーザー名とパスワードを使用するかどうかを制御します。デフォルト値はfalse です。 |
ティCDC | security.mtls | 新しく追加された | TLS クライアント認証を有効にするかどうかを制御します。デフォルト値はfalse です。 |
ティCDC | sink.debezium.output-old-value | 新しく追加された | 行データが変更される前に値を出力するかどうかを制御します。デフォルト値はtrue です。無効にすると、 UPDATE イベントは「前」フィールドを出力しません。 |
ティCDC | sink.open.output-old-value | 新しく追加された | 行データが変更される前に値を出力するかどうかを制御します。デフォルト値はtrue です。無効にすると、 UPDATE イベントは "p" フィールドを出力しません。 |
廃止された機能
- 以降のリリースでは実行計画バインディングの自動進化再設計する予定であり、関連する変数と動作が変更されます。
- TiDB Lightningパラメータ
conflict.max-record-rows
、将来のリリースで廃止される予定であり、その後削除されます。このパラメータはconflict.threshold
に置き換えられます。これは、競合するレコードの最大数が、単一のインポート タスクで許容できる競合するレコードの最大数と一致することを意味します。 - v8.0.0 以降、 TiDB Lightning物理インポート モードの競合検出の旧バージョン戦略が廃止され、
conflict.strategy
パラメータを使用して論理インポート モードと物理インポート モードの両方の競合検出戦略を制御できるようになりました。競合検出の旧バージョンのduplicate-resolution
パラメータは、将来のリリースで削除される予定です。
改善点
ティビ
SHOW CREATE TABLE
#51837 @ ネガチョフの出力に表示される外部キーの MySQL 互換性を改善しましたSHOW CREATE TABLE
#52939 @ Cbcウェストウルフの出力に表示される式のデフォルト値の MySQL 互換性を改善しました- 取り込みモード#52596 @ ランス6716で複数のインデックスを同時に追加する機能をサポート
- システム変数
tidb_service_scope
をさまざまな値で構成し、分散実行フレームワーク (DXF) #52441 @ うわーの利用率を向上させることをサポート - 常に
false
である DNF 項目の処理を強化し、そのようなフィルター条件を直接無視することで、不要なテーブル全体のスキャンを回避します#40997 @ ハイラスティン - オプティマイザがクエリに対して単一インデックススキャン方式(フルテーブルスキャン以外)を選択できる場合、オプティマイザがクエリに対してインデックスマージを自動的に選択しないという制限を削除するために、オプティマイザ修正コントロールの使用をサポートします#52869 @ 時間と運命
- コプロセッサー演算子#28937 @ 翻訳の列
execution info
にtotal_kv_read_wall_time
メトリックを追加します。 - リソースコントロールダッシュボードに
RU (max)
メトリックを追加する#49318 @ ノルーシュ - リソースロック (RLock) が時間内に解放されない問題を回避するために、LDAP 認証にタイムアウトメカニズムを追加します#51883 @ ヤンケオ
ティクヴ
PD
TiFlash
ツール
バックアップと復元 (BR)
ティCDC
- REDOログを使用してデータリカバリ中のメモリの安定性を向上させ、OOM #10900 @ チャールズ・チュン96の可能性を低減します。
- トランザクション競合シナリオでのデータレプリケーションの安定性が大幅に向上し、パフォーマンスが最大10倍向上します#10896 @ チャールズ・チュン96
バグの修正
ティビ
- 複数値インデックスを持つテーブルを含むSQL文を実行すると、
Can't find a proper physical plan for this query
エラー#49438 @ qw4990が返される可能性がある問題を修正しました。 - OOM エラーが発生した後に自動統計収集が停止する問題を修正#51993 @ ハイラスティン
- BRを使用して統計情報のないテーブルを復元した後、そのテーブルの統計情報の健全性が 100% のままになる問題を修正しました#29769 @ ウィノロス
- アップグレード#52040 @ ハイラスティン中に TiDB がシステム テーブルの統計を作成する問題を修正
- 統計の初期化が完了する前に自動統計収集がトリガーされる問題を修正#52346 @ ハイラスティン
tidb_mem_quota_analyze
が有効になっていて、統計の更新に使用されるメモリが制限#52601 @ ホーキングレイを超えると TiDB がクラッシュする可能性がある問題を修正しました。- TiDB の同期的な統計読み込みメカニズムが空の統計の読み込みを無期限に再試行し、
fail to get stats version for this histogram
log #52657 @ ホーキングレイを出力問題を修正しました。 - 照合の新しいフレームワークが無効になっている場合、異なる照合を含む式によってクエリがpanicになる可能性がある問題を修正#52772 @ 翻訳:
CPS by type
メトリックに誤った値#52605 @ ノルーシュが表示される問題を修正INFORMATION_SCHEMA.TIKV_REGION_STATUS
#52013 @ じゃがいもをクエリすると nil ポインタエラーが発生する問題を修正しました- 列#51592 @ ダンキシュに無効なデフォルト値が指定されたときに表示される誤ったエラー メッセージを修正しました。
- 取り込みモードでインデックスを追加すると、一部のコーナーケースでデータインデックスの不整合が発生する可能性がある問題を修正#51954 @ ランス6716
- 外部キー#51838 @ ヤンケオを持つテーブルを復元するときに DDL 操作が停止する問題を修正しました
- TiDBネットワークが分離されているときにインデックスの追加が失敗する問題を修正#51846 @ うわー
- インデックスの名前を変更した後に同じ名前のインデックスを追加するとエラーが発生する問題を修正#51431 @ ランス6716
- インデックス#52411 @ タンジェンタの追加中にクラスターのアップグレードによって発生するデータ インデックスの不整合の問題を修正しました。
- 分散実行フレームワーク (DXF) #52640 @ タンジェンタを有効にした後に、大きなテーブルにインデックスを追加できない問題を修正しました。
- インデックスを同時に追加するとエラー
no such file or directory
#52475 @ タンジェンタが報告される問題を修正しました - インデックスの追加が失敗した後に一時データをクリーンアップできない問題を修正#52639 @ ランス6716
- プラン キャッシュ シナリオ#51407 @ 翻訳:でメタデータ ロックが DDL 操作の実行を阻止できない問題を修正しました。
- 大量のデータをインポートするときに
IMPORT INTO
操作が停止する問題を修正#52884 @ ランス6716 - gRPC エラー#51301 @ グオシャオゲをログに記録するときに TiDB が予期せず再起動する問題を修正しました
- IndexHashJoin が Anti Left Outer Semi Join #52923 @ いいえを計算するときに冗長データを出力する問題を修正しました。
- 相関サブクエリ#52777 @ いいえの TopN 演算子の誤った結果を修正
- HashJoin プローブ#52222 @ 風の話し手の不正確な実行時間統計を修正
- 静的パーティションプルーニングモードで
TABLESAMPLE
使用すると誤った結果が返される問題を修正(tidb_partition_prune_mode='static'
) #52282 @ タンジェンタ - 夏時間#51675 @ lcwangchaoで TTL が 1 時間ずれる問題を修正
- TiDBダッシュボード監視ページ#51889 @ ヤンケオでの接続数(接続数)の計算と表示が誤っていた問題を修正
- パーティション DDL タスク#51090 @ ジフハウスをロールバックするときにステータスが停止する問題を修正しました
EXPLAIN ANALYZE
#52646 @ ジェイソン・ファンを実行するとmax_remote_stream
の値が正しくなくなる問題を修正しましたTIDB_HOT_REGIONS
テーブルをクエリすると、誤ってINFORMATION_SCHEMA
テーブル#50810 @ 定義2014が返される可能性がある問題を修正しました。- 特定の列の統計が完全にロードされていない場合に、
EXPLAIN
ステートメントの結果に誤った列 ID が表示される可能性がある問題を修正しました#52207 @ 時間と運命 IFNULL
関数によって返される型が MySQL #51765 @ ヤンケオと一致しない問題を修正- ユニークインデックスを追加すると TiDB がpanicを起こす可能性がある問題を修正#52312 @ 翻訳:
- 複数値インデックスを持つテーブルを含むSQL文を実行すると、
ティクヴ
- 古いリージョンピアがGCメッセージ#16504 @ クレイジーcs520を無視するとresolve-tsがブロックされる問題を修正
- RocksDB の非アクティブな Write Ahead Logs (WAL) によってデータが破損する可能性がある問題を修正#16705 @ コナー1996
PD
- PD マイクロサービス モードのオン/オフを切り替えるときに TSO が停止する可能性がある問題を修正#7849 @ じゃがいも
- DR自動同期の
State
監視メトリックにデータが表示されない問題を修正#7974 @ 翻訳者 - バイナリバージョンのチェックでPDpanic#7978 @ じゃがいもが発生する可能性がある問題を修正
- TTLパラメータを解析するときに発生する型変換エラーを修正#7980 @ ヒューシャープ
- 展開された 2 つのデータセンター間でLeaderを切り替えると転送に失敗する問題を修正#7992 @ トンスネークリン
- pd-ctl の
PrintErrln
stderr
#8022 @ ヒューシャープにエラーメッセージを出力できない問題を修正しました Merge
スケジュール#8049 @ ノルーシュを生成するときに PD がpanicになる可能性がある問題を修正しましたGetAdditionalInfo
#8079 @ ヒューシャープによって引き起こされるpanic問題を修正- PDの
Filter target
監視メトリックが散布範囲情報を提供しない問題を修正#8125 @ ヒューシャープ - クエリ結果
SHOW CONFIG
に非推奨の構成項目trace-region-flow
#7917 @ rleungxが含まれる問題を修正しました - スケーリングの進行状況が正しく表示されない問題を修正#7726 @ キャビンフィーバーB
TiFlash
- 非厳密な
sql_mode
#8803 @ ロイド・ポティガーで無効なデフォルト値を持つ列にデータを挿入するとTiFlash がpanicになる可能性がある問題を修正しました - 同時実行性の高い読み取りシナリオでTiFlash が一時的に誤った結果を返す可能性がある問題を修正#8845 @ ジンヘリン
- 分散storageおよびコンピューティングアーキテクチャで、 TiFlashコンピューティング ノード#8920 @ ジンヘリンの
storage.remote.cache.capacity
構成項目の値を変更した後、Grafana に表示されるディスクused_size
メトリックが正しくない問題を修正しました。 - クラスターを v6.5.0 より前のバージョンから v6.5.0 以降にアップグレードするときに、 TiFlashメタデータが破損してプロセスがpanicになる可能性がある問題を修正しました#9039 @ ジェイソン・ファン
- 分散storageとコンピューティングアーキテクチャで、コンピューティングノードのプロセスが停止するとTiFlash がpanicになる可能性がある問題を修正しました#8860 @ グオシャオゲ
- 仮想生成列#8787 @ グオシャオゲを含むクエリを実行するとTiFlash がエラーを返す可能性がある問題を修正しました。
- 非厳密な
ツール
バックアップと復元 (BR)
- BR が
AUTO_RANDOM
列#52255 @ リーヴルスを含むユニオン クラスター化インデックスのAUTO_RANDOM
ID 割り当ての進行状況をバックアップできない問題を修正しました。 - ログバックアップタスクを一時停止後に削除しても、GCセーフポイント#52082 @ 3ポインターがすぐに復元されない問題を修正しました。
- 特別なイベントのタイミングにより、ログ バックアップ#16739 @ ユジュンセンでデータが失われる可能性があるというまれな問題を修正しました。
- TiKV の再起動により、ログ バックアップのグローバル チェックポイントが実際のバックアップ ファイルの書き込みポイントよりも先に進められ、少量のバックアップ データが失われる可能性がある問題を修正しました#16809 @ ユジュンセン
- フルバックアップ#50837 @ ボーンチェンジャー中に
--concurrency
に関連する紛らわしい情報がログに表示される問題を修正 - BRを使用してデータを復元する場合、または物理インポート モードでTiDB Lightningを使用してデータをインポートする場合に、PD から取得されたリージョンにLeaderがない問題を修正しました#51124 #50501 @ リーヴルス
- ログバックアップタスクを一時停止、停止、再構築した後、タスクの状態は正常であるが、チェックポイントが#53047 @ リドリスに進まない問題を修正しました。
- 不安定なテストケースを修正
TestClearCache
#51671 @ 翻訳者 - 不安定なテストケースを修正
TestGetMergeRegionSizeAndCount
#52095 @ 3ポインター - 不安定な統合テストを修正
br_tikv_outage
#52673 @ リーヴルス - テストケース
TestGetTSWithRetry
実行に時間がかかりすぎる問題を修正#52547 @ リーヴルス - PD #17020 @ ユジュンセンへのネットワーク接続が不安定な状態で一時停止中のログ バックアップ タスクを再開すると TiKV がpanicになる可能性がある問題を修正しました。
- BR が
ティCDC
- TiCDC所有者ノードを退去させるAPI(
/api/v2/owner/resign
)を呼び出すと、TiCDCタスクが予期せず再起動する問題を修正しました#10781 @ スドジ - 下流の Pulsar が停止しているときに、changefeed を削除すると通常の TiCDC プロセスが停止し、他の changefeed プロセスも停止するという問題を修正しました#10629 @ アズドンメン
- Grafana の所有権履歴パネルが不安定になる問題を修正#10796 @ ホンユンヤン
- PD を再起動すると、TiCDC ノードがエラー#10799 @ 3エースショーハンドで再起動する可能性がある問題を修正しました。
- PD ディスク I/O の高レイテンシーによりデータレプリケーション#9054 @ アズドンメンで深刻なレイテンシーが発生する問題を修正
TIMEZONE
種類のデフォルト値が正しいタイムゾーン#10931 @ 3エースショーハンドに従って設定されない問題を修正DROP PRIMARY KEY
とDROP UNIQUE KEY
ステートメントが正しく複製されない問題を修正#10890 @ アズドンメン- TiCDC が上流に書き込まれた後に下流の
Exchange Partition ... With Validation
DDL の実行に失敗し、変更フィードが#10859 @ ホンユンヤンで停止する問題を修正しました。
- TiCDC所有者ノードを退去させるAPI(
TiDB Lightning
- ソースファイル#51800 @ ランス6716内の互換性のない SQL ステートメントが原因で、 TiDB Lightning がデータインポート中に
no database selected
を報告する問題を修正しました。 - TiDB Lightning がサーバーモード#36374 @ ケニーでログに機密情報を出力する可能性がある問題を修正しました。
- PDLeaderを強制終了すると、 TiDB Lightning がデータ インポート#50501 @ リーヴルス中に
invalid store ID 0
エラーを報告する問題を修正しました。 replace
戦略#52886 @ 翻訳者を使用して競合するデータを処理するときにTiDB Lightning がUnknown column in where clause
エラーを報告する問題を修正しました。- Parquet 形式#52518 @ ケニーの空のテーブルをインポートするときにTiDB Lightning がパニックになる問題を修正しました。
- ソースファイル#51800 @ ランス6716内の互換性のない SQL ステートメントが原因で、 TiDB Lightning がデータインポート中に
性能テスト
TiDB v8.1.0 のパフォーマンスについては、TiDB 専用クラスターのTPC-C パフォーマンステストレポートとSysbench パフォーマンステストレポートを参照してください。
寄稿者
TiDB コミュニティの以下の貢献者に感謝いたします。
- アルトゥルメランチク (初めての投稿者)
- キャビンフィーバーB
- ダンキシュ (初めての投稿者)
- イマラソン (初めての投稿者)
- ジフハウス
- ネガチョフ (初めての投稿者)
- テストウィル
- yzhan1 (初めての投稿者)
- 翻訳者 (初めての投稿者)