TiDB 5.4 リリースノート
発売日：2022年2月15日
TiDB バージョン: 5.4.0
v5.4 の主な新機能または改善点は次のとおりです。
- GBK 文字セットをサポート
- 複数の列のインデックスのフィルタリング結果をマージする Index Merge を使用したデータ アクセスのサポート
- セッション変数を使用した古いデータの読み取りをサポート
- 統計を収集するための構成の永続化をサポート
- Raft Engineを TiKV のログ保存エンジンとしてサポート (実験的)
- クラスターに対するバックアップの影響を最適化する
- バックアップ ストレージとしての Azure Blob Storage の使用をサポート
- TiFlashと MPP エンジンの安定性とパフォーマンスを継続的に改善します
- TiDB Lightningにスイッチを追加して、データを含む既存のテーブルへのインポートを許可するかどうかを決定します
- 継続的なプロファイリング機能を最適化 (実験的)
- TiSpark はユーザーの識別と認証をサポートします
互換性の変更
ノート：
以前の TiDB バージョンから v5.4.0 にアップグレードする場合、すべての中間バージョンの互換性の変更点を知りたい場合は、該当するバージョンのリリースノートを確認できます。
システム変数
Configuration / コンフィグレーションファイルのパラメーター
その他
- TiDB と PD の間にインターフェースが追加されます。
information_schema.TIDB_HOT_REGIONS_HISTORYシステム テーブルを使用する場合、TiDB は対応するバージョンの PD を使用する必要があります。 - TiDB サーバー、PD サーバー、および TiKV サーバーは、ログ関連のパラメーターに統一された命名方法を使用して開始し、ログ名、出力形式、およびローテーションと有効期限のルールを管理します。詳細については、 TiKV 構成ファイル - ログを参照してください。
- v5.4.0 以降、プラン キャッシュを介してキャッシュされた実行プランの SQL バインディングを作成すると、バインディングは、対応するクエリに対して既にキャッシュされているプランを無効にします。新しいバインディングは、v5.4.0 より前にキャッシュされた実行プランには影響しません。
- v5.3 以前のバージョンでは、 TiDB データ移行 (DM)のドキュメントが TiDB ドキュメントから独立しています。 v5.4 以降、DM ドキュメントは同じバージョンの TiDB ドキュメントに統合されています。 DMドキュメンテーションサイトにアクセスしなくても、 DM ドキュメントを直接読むことができます。
- ポイントインタイム リカバリ (PITR) の実験的機能を cdclog と共に削除します。 v5.4.0 以降、cdclog ベースの PITR と cdclog はサポートされなくなりました。
- システム変数を「DEFAULT」に設定する動作をより MySQL 互換にする#29680
- システム変数
lc_time_namesを読み取り専用#30084に設定します tidb_store_limitのスコープを INSTANCE または GLOBAL から GLOBAL #30756に設定します- 列にゼロが含まれる場合、整数型の列を時間型の列に変換することを禁止します#25728
- 浮動小数点値#30148を挿入するときに、
InfまたはNANの値に対してエラーが報告されない問題を修正します。 - 自動 ID が範囲外の場合に
REPLACEステートメントが他の行を誤って変更する問題を修正します#30301
新機能
SQL
TiDB は v5.4.0 以降、GBK 文字セットをサポートしています
v5.4.0 より前の TiDB は、
ascii、binary、latin1、utf8、およびutf8mb4文字セットをサポートしています。中国語ユーザーのサポートを強化するために、TiDB は v5.4.0 以降、GBK 文字セットをサポートしています。初めて TiDB クラスターを初期化するときに TiDB 構成ファイルで
new_collations_enabled_on_first_bootstrapオプションを有効にすると、TiDB GBK 文字セットはgbk_binとgbk_chinese_ciの両方の照合をサポートします。GBK 文字セットを使用する場合は、互換性の制限に注意する必要があります。詳細については、 文字セットと照合 - GBKを参照してください。
安全
TiSpark はユーザー認証と承認をサポートします
TiSpark 2.5.0 以降、TiSpark はデータベース ユーザー認証と、データベースまたはテーブル レベルでの読み取り/書き込み承認の両方をサポートしています。この機能を有効にすると、企業がドローなどの不正なバッチ タスクを実行してデータを取得することを防止できるため、オンライン クラスターの安定性とデータ セキュリティが向上します。
この機能はデフォルトで無効になっています。有効にすると、TiSpark を介して操作しているユーザーが必要なアクセス許可を持っていない場合、ユーザーは TiSpark から例外を取得します。
TiUPは root ユーザーの初期パスワードの生成をサポートします
クラスターを開始するためのコマンドに
--initパラメーターが導入されました。このパラメーターを使用すると、 TiUPを使用してデプロイされた TiDB クラスターで、 TiUPはデータベース ルート ユーザーの強力な初期パスワードを生成します。これにより、空のパスワードで root ユーザーを使用する際のセキュリティ リスクが回避され、データベースのセキュリティが確保されます。
パフォーマンス
列型ストレージ エンジンTiFlashとコンピューティング エンジン MPP の安定性とパフォーマンスを継続的に改善します。
より多くの関数を MPP エンジンにプッシュすることをサポートします。
- 文字列関数:
LPAD()、RPAD()、STRCMP() - 日付関数:
ADDDATE(string, real)、DATE_ADD(string, real)、DATE_SUB(string, real)、SUBDATE(string, real)、QUARTER()
- 文字列関数:
リソース使用率を改善するためのエラスティック スレッド プール機能の導入 (実験的)
TiKV からデータをレプリケートする際に、行ベースのストレージ形式から列ベースのストレージ形式にデータを変換する効率が向上し、データ レプリケーションの全体的なパフォーマンスが 50% 向上します。
一部の構成項目のデフォルト値を調整して、 TiFlashのパフォーマンスと安定性を向上させます。 HTAP ハイブリッド ロードでは、1 つのテーブルに対する単純なクエリのパフォーマンスが最大 20% 向上します。
ユーザー文書: サポートされているプッシュダウン計算 、 tiflash.toml ファイルを構成する
セッション変数を使用して、指定された時間範囲内の履歴データを読み取ります
TiDB は、 Raftコンセンサス アルゴリズムに基づくマルチレプリカ分散データベースです。同時実行性とスループットの高いアプリケーション シナリオに直面した場合、TiDB はフォロワー レプリカを介して読み取りパフォーマンスをスケールアウトし、読み取り要求と書き込み要求を分離できます。
さまざまなアプリケーション シナリオに対して、TiDB はフォロワー読み取りの 2 つのモードを提供します。強整合性読み取りと弱整合性履歴読み取りです。強力な一貫性のある読み取りモードは、リアルタイム データを必要とするアプリケーション シナリオに適しています。ただし、このモードでは、リーダーとフォロワー間のデータ レプリケーションのレイテンシーとスループットの低下により、特に地理的に分散された展開の場合、読み取り要求のレイテンシーが長くなる可能性があります。
リアルタイム データの要件がそれほど厳しくないアプリケーション シナリオでは、履歴読み取りモードをお勧めします。このモードでは、レイテンシーが短縮され、スループットが向上します。 TiDB は現在、次の方法による履歴データの読み取りをサポートしています。SQL ステートメントを使用して過去の時点からデータを読み取るか、過去の時点に基づいて読み取り専用トランザクションを開始します。どちらの方法も、特定の時点または指定された時間範囲内の履歴データの読み取りをサポートしています。詳細については、
AS OF TIMESTAMP句を使用した履歴データの読み取りを参照してください。v5.4.0 以降、TiDB は、セッション変数を介して指定された時間範囲内の履歴データの読み取りをサポートすることにより、履歴読み取りモードの使いやすさを向上させます。このモードは、準リアルタイムのシナリオで低レイテンシ、高スループットの読み取り要求を処理します。変数は次のように設定できます。
set @@tidb_replica_read=leader_and_follower set @@tidb_read_staleness="-5"この設定により、TiDB は最も近いリーダーまたはフォロワー ノードを選択し、5 秒以内に最新の履歴データを読み取ることができます。
インデックス マージの GA
Index Merge は、SQL 最適化の実験的機能として TiDB v4.0 に導入されました。この方法は、クエリで複数のデータ列のスキャンが必要な場合に条件フィルタリングを大幅に高速化します。例として、次のクエリを取り上げます。
WHEREステートメントで、ORで接続されたフィルター条件が列key1およびkey2にそれぞれのインデックスを持っている場合、インデックス マージ機能はそれぞれのインデックスを同時にフィルター処理し、クエリ結果をマージして、マージされた結果を返します。SELECT * FROM table WHERE key1 <= 100 OR key2 = 200;TiDB v4.0 より前では、テーブルに対するクエリは、一度にフィルタリングするために 1 つのインデックスのみを使用することをサポートしていました。データの複数の列に対してクエリを実行する場合は、インデックス マージを有効にして、個々の列のインデックスを使用して正確なクエリ結果を短時間で取得できます。インデックス マージは、不要な全テーブル スキャンを回避し、多数の複合インデックスを確立する必要がありません。
v5.4.0 では、Index Merge が GA になります。ただし、次の制限に注意する必要があります。
Index Merge は、論理和正規形 (X 1 ⋁ X 2 ⋁ …X n ) のみをサポートします。つまり、この機能は、
WHERE句のフィルタリング条件がORで接続されている場合にのみ機能します。v5.4.0 以降の新しくデプロイされた TiDB クラスターの場合、この機能はデフォルトで有効になっています。以前のバージョンからアップグレードされた v5.4.0 以降の TiDB クラスターの場合、この機能はアップグレード前の設定を継承し、必要に応じて設定を変更できます (v4.0 より前の TiDB クラスターの場合、この機能は存在せず、デフォルトで無効になっています)。 .
Raft Engineのサポート (実験的)
TiKV のログ ストレージ エンジンとしてRaft Engineを使用することをサポートします。 RocksDB と比較して、 Raft Engineは TiKV I/O 書き込みトラフィックを最大 40% 削減し、CPU 使用率を 10% 削減し、フォアグラウンド スループットを約 5% 向上させ、特定の負荷の下でテールレイテンシーを 20% 削減できます。さらに、 Raft Engineはログのリサイクルの効率を改善し、極端な状況でのログの蓄積の問題を修正します。
Raft Engineはまだ実験的機能であり、デフォルトでは無効になっています。 v5.4.0 のRaft Engineのデータ形式は、以前のバージョンと互換性がないことに注意してください。クラスターをアップグレードする前に、すべての TiKV ノードでRaft Engineが無効になっていることを確認する必要があります。 v5.4.0 以降のバージョンでのみRaft Engineを使用することをお勧めします。
PREDICATE COLUMNSでの統計収集のサポート (実験的)ほとんどの場合、SQL ステートメントを実行するとき、オプティマイザーは一部の列 (
WHERE、JOIN、ORDER BY、およびGROUP BYステートメントの列など) の統計のみを使用します。これらの使用済み列はPREDICATE COLUMNSと呼ばれます。v5.4.0 以降、システム変数
tidb_enable_column_trackingの値をONに設定して、TiDB がPREDICATE COLUMNSを収集できるようにすることができます。設定後、TiDB は 100 *
stats-leaseごとにPREDICATE COLUMNSの情報をmysql.column_stats_usageのシステム テーブルに書き込みます。ビジネスのクエリ パターンが安定している場合は、ANALYZE TABLE TableName PREDICATE COLUMNS構文を使用してPREDICATE COLUMNS列のみの統計を収集できます。これにより、統計収集のオーバーヘッドを大幅に削減できます。統計の同期読み込みをサポート (実験的)
v5.4.0 以降、TiDB は同期読み込み統計機能を導入しています。この機能はデフォルトで無効になっています。この機能を有効にすると、TiDB は、SQL ステートメントを実行するときに大規模な統計 (ヒストグラム、TopN、Count-Min Sketch 統計など) をメモリに同期的にロードできるため、SQL 最適化の統計の完全性が向上します。
安定性
ANALYZE 構成の永続化をサポート
統計は、オプティマイザが実行計画を生成するときに参照する基本情報の一種です。統計の精度は、生成された実行計画が適切かどうかに直接影響します。統計の精度を確保するために、さまざまなテーブル、パーティション、およびインデックスに対してさまざまなコレクション構成を設定する必要がある場合があります。
v5.4.0 以降、
ANALYZEは一部の構成の永続化をサポートしています。この機能を使用すると、既存の構成を将来の統計収集に簡単に再利用できます。ANALYZE構成永続化機能は、デフォルトで有効になっています (システム変数tidb_analyze_versionはデフォルトで2で、tidb_persist_analyze_optionsはONです)。この機能を使用して、ステートメントを手動で実行するときに、ANALYZEステートメントで指定された持続性構成を記録できます。記録されると、次に TiDB が自動的に統計を更新するか、これらの構成を指定せずに手動で統計を収集するときに、TiDB は記録された構成に従って統計を収集します。
高可用性と災害復旧
クラスターに対するバックアップ タスクの影響を軽減する
バックアップと復元 (BR) では、自動調整機能が導入されています (既定で有効になっています)。この機能は、クラスター リソースの使用状況を監視し、バックアップ タスクで使用されるスレッドの数を調整することで、クラスターに対するバックアップ タスクの影響を軽減できます。場合によっては、バックアップ用のクラスター ハードウェア リソースを増やして自動調整機能を有効にすると、クラスターに対するバックアップ タスクの影響を 10% 以下に制限できます。
バックアップのターゲット ストレージとして Azure Blob Storage をサポートする
バックアップと復元 (BR) は、Azure Blob Storage をリモート バックアップ ストレージとしてサポートします。 TiDB を Azure クラウドにデプロイすると、クラスター データを Azure Blob Storage サービスにバックアップできるようになりました。
データ移行
TiDB Lightningは、データを含むテーブルへのデータのインポートを許可するかどうかを決定する新しい機能を導入します
TiDB Lightningは構成項目
incremental-importを導入します。データを含むテーブルへのデータのインポートを許可するかどうかを決定します。デフォルト値はfalseです。並行インポート モードを使用する場合は、構成をtrueに設定する必要があります。TiDB Lightningに並行インポート用のメタ情報を格納するスキーマ名を導入
TiDB Lightningでは、
meta-schema-nameの構成アイテムが導入されています。並行インポート モードでは、このパラメーターは、ターゲット クラスター内の各TiDB Lightningインスタンスのメタ情報を格納するスキーマ名を指定します。デフォルトの値は「lightning_metadata」です。このパラメータに設定する値は、同じ並列インポートに参加するTiDB Lightningインスタンスごとに同じにする必要があります。そうしないと、インポートされたデータの正確性が保証されません。TiDB Lightningが重複解決を導入
ローカル バックエンド モードでは、 TiDB Lightningは、データのインポートが完了する前に重複データを出力し、その重複データをデータベースから削除します。インポートの完了後に重複データを解決し、アプリケーション ルールに従って挿入する適切なデータを選択できます。後続の増分データ移行フェーズで発生する重複データによって引き起こされるデータの不整合を回避するために、重複データに基づいてアップストリーム データ ソースをクリーンアップすることをお勧めします。
TiDB Data Migration (DM) でのリレー ログの使用を最適化する
source構成のenable-relayスイッチを回復します。start-relayおよびstop-relayコマンドを使用して、リレー ログの動的な有効化と無効化をサポートします。リレーログのステータスを
sourceにバインドします。sourceは、任意の DM-worker に移行された後、有効または無効の元のステータスを保持します。中継ログの保存パスを DM-worker 設定ファイルに移動します。
DMでの照合順序処理を最適化
collation_compatible構成アイテムを追加します。値のオプションはloose(デフォルト) とstrictです。- アプリケーションに照合順序がアップストリームとダウンストリームで異なる可能性がある場合は、デフォルトの
looseモードを使用してエラーの報告を回避できます。 - アプリケーションが照合順序が一貫している必要がある場合は、
strictモードを使用できます。ただし、ダウンストリームがアップストリームのデフォルトの照合順序をサポートしていない場合、データ レプリケーションでエラーが報告されることがあります。
- アプリケーションに照合順序がアップストリームとダウンストリームで異なる可能性がある場合は、デフォルトの
DM の
transfer sourceを最適化して、レプリケーション タスクのスムーズな実行をサポートDM-worker ノードの負荷が不均衡な場合、
transfer sourceコマンドを使用して、sourceの構成を別の負荷に手動で転送できます。最適化後、transfer sourceコマンドは手動操作を簡素化します。 DMが内部で他の操作を完了するため、関連するすべてのタスクを一時停止する代わりに、ソースをスムーズに転送できます。DM OpenAPI の一般提供開始 (GA)
DM は、データ ソースの追加やタスクの管理など、API を介して日常的な管理をサポートします。 v5.4.0 では、DM OpenAPI が GA になります。
診断効率
Top SQL (実験的機能)
ソースを消費するクエリを簡単に見つけられるように、新しい実験的機能であるTop SQL (既定では無効) が導入されました。
TiDB データ共有サブスクリプション
クラスターに対する TiCDC の影響を最適化する
TiCDC を使用すると、TiDB クラスターのパフォーマンスへの影響が大幅に軽減されます。テスト環境では、TiDB に対する TiCDC のパフォーマンスへの影響を 5% 未満に減らすことができます。
展開とメンテナンス
継続的なプロファイリングの強化 (実験的)
サポートされるコンポーネントの増加: TiDB、PD、および TiKV に加えて、TiDB v5.4.0 はTiFlashの CPU プロファイリングもサポートします。
より多くの形式のプロファイリング表示: フレーム チャートでの CPU プロファイリングとゴルーチンの結果の表示をサポートします。
サポートされる展開環境の増加: 継続的なプロファイリングは、 TiDB Operatorを使用して展開されたクラスターにも使用できます。
継続的なプロファイリングはデフォルトで無効になっており、TiDB ダッシュボードで有効にすることができます。
継続的プロファイリングは、v1.9.0 以降の TiUP または v1.3.0 以降のTiUP TiDB Operatorを使用してデプロイまたはアップグレードされたクラスターに適用されます。
改良点
TiDB
ADMIN {SESSION | INSTANCE | GLOBAL} PLAN_CACHE構文をサポートして、キャッシュされたクエリ プランをクリアします#30370
TiKV
- コプロセッサーは、ストリームのような方法で要求を処理するページング API をサポートします#11448
read-through-lockをサポートして、読み取り操作が 2 次ロックの解決を待つ必要がないようにする#11402- ディスク領域の枯渇によるpanicを回避するために、ディスク保護メカニズムを追加します#10537
- ログのアーカイブとローテーションをサポート#11651
- Raftクライアントによるシステム コールを減らし、CPU 効率を高める#11309
- コプロセッサーは部分文字列の TiKV #11495へのプッシュダウンをサポート
- Read Committed 分離レベル#11485で読み取りロックをスキップすることにより、スキャンのパフォーマンスを向上させます。
- バックアップ操作で使用されるデフォルトのスレッド プール サイズを減らし、負荷が高い場合にスレッド プールの使用を制限する#11000
- Apply スレッド プールと Store スレッド プールのサイズを動的に調整するサポート#11159
snap-generatorスレッド プール#11247のサイズの構成をサポート- 読み取りと書き込みが頻繁に行われるファイルが多数ある場合に発生するグローバル ロック競合の問題を最適化します#250
PD
TiFlash
- 現地オペレーターのコミュニケーションを最適化
- gRPC の非一時的なスレッド数を増やして、スレッドの頻繁な作成または破棄を回避します
ツール
バグの修正
TiDB
- クラスターを#25422から v5.x にアップグレードするときに発生する
tidb_analyze_versionの値の変更の問題を修正します。 - サブクエリで異なる照合順序を使用した場合に発生する間違った結果の問題を修正します#30748
- TiDB の
concat(ifnull(time(3))の結果が MySQL #29498の結果と異なる問題を修正 - 楽観的トランザクション モード#30410での潜在的なデータ インデックスの不整合の問題を修正します。
- TiKV #30200に式をプッシュダウンできない場合、IndexMerge のクエリ実行プランが間違っている問題を修正
- 列の型を同時に変更すると、スキーマとデータの間で不整合が発生する問題を修正します#31048
- サブクエリがあるとIndexMergeのクエリ結果がおかしくなる問題を修正#30913
- クライアント#30896で FetchSize の設定が大きすぎる場合に発生するpanicの問題を修正します。
- LEFT JOIN が誤って INNER JOIN #20510に変換される可能性がある問題を修正
CASE-WHEN式と照合順序を併用するとpanicが発生することがある問題を修正#30245INの値にバイナリ定数#31261が含まれている場合に発生する間違ったクエリ結果の問題を修正します。- CTE にサブクエリがある場合に発生する間違ったクエリ結果の問題を修正します#31255
INSERT ... SELECT ... ON DUPLICATE KEY UPDATEステートメントを実行するとpanic#28078が発生する問題を修正します。- INDEX HASH JOIN が
send on closed channelエラー#31129を返す問題を修正
- クラスターを#25422から v5.x にアップグレードするときに発生する
TiKV
PD
TiFlash
- MPP クエリが停止したときにTiFlashがpanicになる問題を修正
where <string>句を含むクエリが間違った結果を返す問題を修正- 整数主キーの列タイプをより大きな範囲に設定するときに発生する可能性のあるデータの不整合の問題を修正します
- 入力時刻が 1970-01-01 00:00:01 UTC より前の場合、
unix_timestampの動作が TiDB や MySQL の動作と一致しない問題を修正 - 再起動後にTiFlashが
EstablishMPPConnectionエラーを返すことがある問題を修正 CastStringAsDecimal動作がTiFlashと TiDB/TiKV で一致しない問題を修正- クエリ結果に
DB::Exception: Encode type of coprocessor response is not CHBlock個のエラーが返される問題を修正 castStringAsReal動作がTiFlashと TiDB/TiKV で一致しない問題を修正- TiFlashの
date_add_string_xxx関数の返される結果が MySQL の結果と一致しない問題を修正します。
ツール
バックアップと復元 (BR)
TiCDC
min.insync.replicasがreplication-factor#3994より小さい場合にレプリケーションが実行できない問題を修正cached regionモニタリング指標がマイナス#4300になる問題を修正mq sink write row監視データがない問題を修正#3431sql mode#3810の互換性の問題を修正- レプリケーション タスクが削除されたときに発生する潜在的なpanicの問題を修正します#3128
- デフォルトの列値#3929を出力するときに発生するpanicとデータの不整合の問題を修正します。
- デフォルト値をレプリケートできない問題を修正#3793
- デッドロックが原因でレプリケーション タスクがスタックする潜在的な問題を修正します#4055
- ディスクが完全に書き込まれたときにログが出力されない問題を修正#3362
- DDL ステートメントの特殊なコメントによってレプリケーション タスクが停止する問題を修正します#3755
- RHEL リリース#3584でタイムゾーンの問題が原因でサービスを開始できない問題を修正
- 不正確なチェックポイント#3545によって引き起こされる潜在的なデータ損失の問題を修正します。
- コンテナー環境での OOM の問題を修正する#1798
config.Metadata.Timeout#3352の構成が正しくないために発生するレプリケーション停止の問題を修正します。
TiDB データ移行 (DM)
TiDB Lightning
Binlog
- Drainerが
CREATE PLACEMENT POLICY文#1118と互換性がないために失敗する問題を修正
- Drainerが