TiDB 5.0の新機能

発売日：2021年4月7日

TiDB バージョン: 5.0.0

バージョン5.0では、PingCAPは企業がTiDBをベースとしたアプリケーションを迅速に構築できるよう支援することに特化しており、データベースのパフォーマンス、パフォーマンスの変動、セキュリティ、高可用性、ディザスタリカバリ、SQLパフォーマンスのトラブルシューティングなどに関する懸念から解放します。

バージョン5.0における主な新機能または改善点は以下のとおりです。

• TiFlashノードを介して大規模並列処理（MPP）アーキテクチャを導入し、大規模な結合クエリの実行ワークロードをTiFlashノード間で共有します。MPPモードが有効になっている場合、TiDBはコストに基づいて、計算を実行するためにMPPフレームワークを使用するかどうかを決定します。MPPモードでは、結合キーは計算中にExchange操作によって再分配され、計算負荷が各TiFlashノードに分散され、計算が高速化されます。ベンチマークによると、同じクラスタリソースを使用した場合、TiDB 5.0 MPPはGreenplum 6.15.0およびApache Spark 3.1.1と比較して2～3倍高速化され、一部のクエリでは8倍のパフォーマンス向上を実現しています。
• データベースのパフォーマンスを向上させるために、クラスタ化インデックス機能を導入します。例えば、TPC-C tpmCテストでは、クラスタ化インデックスを有効にしたTiDBのパフォーマンスは39%向上しました。
• 非同期コミット機能を有効にすると、書き込みレイテンシーを削減できます。例えば、64スレッドのSysbenchテストでは、非同期コミットを有効にした場合、インデックス更新の平均レイテンシーは12.04msから7.01msへと41.7%削減されます。
• ジッターを低減します。これは、オプティマイザの安定性を向上させ、システムタスクによるI/O、ネットワーク、CPU、メモリリソースの使用を制限することによって実現されます。例えば、8時間のパフォーマンステストでは、TPC-C tpmCの標準偏差は2%を超えません。
• スケジューリングを改善し、実行計画を可能な限り安定させることで、システムの安定性を向上させる。
• リージョンメンバーシップの変更時にもシステムの可用性を保証するRaft共同合意アルゴリズムを導入します。
• EXPLAIN機能と非表示インデックスを最適化することで、データベース管理者 (DBA) が SQL ステートメントをより効率的にデバッグできるようになります。
• 企業データの信頼性を保証します。TiDBからAmazon S3storageやGoogle Cloud GCSにデータをバックアップしたり、これらのクラウドstorageプラットフォームからデータを復元したりできます。
• Amazon S3storageまたはTiDB/MySQLへのデータインポートおよびデータエクスポートのパフォーマンスが向上し、企業がクラウド上でアプリケーションを迅速に構築できるようになります。例えば、TPC-Cテストでは、1 TiBのデータをインポートする際のパフォーマンスが40%向上し、254 GiB/hから366 GiB/hになりました。

互換性の変更

システム変数

• 複数のオペレーターの同時実行を制御するには、 tidb_executor_concurrencyシステム変数を追加します。以前のtidb_*_concurrency設定 ( tidb_projection_concurrencyなど) は引き続き有効ですが、使用時に警告が表示されます。

• ASCII文字セットを書き込む際にASCII検証チェックをスキップするかどうかを指定するには、 tidb_skip_ascii_checkシステム変数を追加します。デフォルト値はOFFです。

• テーブルスキーマでdouble(N)のような構文を定義できるかどうかを判断するには、 tidb_enable_strict_double_type_checkシステム変数を追加します。デフォルト値はOFFです。

• tidb_dml_batch_sizeのデフォルト値を20000から0に変更します。これは、 LOAD / INSERT INTO SELECT ...ではバッチ DML ステートメントがデフォルトで使用されなくなることを意味します。代わりに、厳密なACIDセマンティクスに準拠するために、大規模なトランザクションが使用されます。

  注記：

  変数のスコープがセッションからグローバルに変更され、デフォルト値が20000から0に変更されました。アプリケーションが元のデフォルト値に依存している場合は、アップグレード後にset globalステートメントを使用して変数を元の値に変更する必要があります。

• 一時テーブルの構文互換性は、システム変数tidb_enable_noop_functionsを使用して制御します。この変数の値がOFFの場合、 CREATE TEMPORARY TABLE構文はエラーを返します。

• ガベージコレクション関連のパラメータを直接制御するには、以下のシステム変数を追加してください。

  • tidb_gc_concurrency
  • tidb_gc_enable
  • tidb_gc_life_time
  • tidb_gc_run_interval
  • tidb_gc_scan_lock_mode

• enable-joint-consensusのデフォルト値をfalseからtrueに変更すると、ジョイントコンセンサス機能がデフォルトで有効になります。

• tidb_enable_amend_pessimistic_txnの値を0または1からONまたはOFFに変更します。

• tidb_enable_clustered_indexのデフォルト値をOFFからINT_ONLYに変更し、以下の新しい意味を設定します。

  • ON : クラスター化インデックスが有効になっています。非クラスター化インデックスの追加または削除がサポートされています。

  • OFF : クラスター化インデックスは無効になっています。非クラスター化インデックスの追加または削除はサポートされています。

  • INT_ONLY : デフォルト値。動作はv5.0以前と同じです。 alter-primary-key = falseと併せて、INT型のクラスタ化インデックスを有効にするかどうかを制御できます。

    注記：

    5.0 GA のINT_ONLYのtidb_enable_clustered_index値は、5.0 RC のOFF値と同じ意味です。 OFF設定の 5.0 RC クラスターから 5.0 GA にアップグレードすると、 INT_ONLYと表示されます。

コンフィグレーションファイルパラメータ

• TiDB のindex-limit設定項目を追加します。デフォルト値は64で、範囲は[64,512]です。MySQL テーブルは最大 64 個のインデックスをサポートします。この値がデフォルト設定を超え、テーブルに 64 個を超えるインデックスが作成された場合、テーブル スキーマが MySQL に再インポートされるとエラーが報告されます。
• TiDB が MySQL の ENUM/SET の長さ (ENUM の長さ < 255) と互換性があり、一貫性を保つように、 enable-enum-length-limit設定項目を追加します。デフォルト値はtrueです。
• pessimistic-txn.enable設定項目をtidb_txn_mode環境変数に置き換えてください。
• performance.max-memory設定項目をperformance.server-memory-quotaに置き換えます。
• tikv-client.copr-cache.enable設定項目をtikv-client.copr-cache.capacity-mbに置き換えます。項目の値が0.0の場合、この機能は無効になります。項目の値が0.0より大きい場合、この機能は有効になります。デフォルト値は1000.0です。
• rocksdb.auto-tuned設定項目をrocksdb.rate-limiter-auto-tunedに置き換えます。
• raftstore.sync-log設定項目を削除します。デフォルトでは、書き込まれたデータは強制的にディスクに書き込まれます。v5.0 より前は、 raftstore.sync-log明示的に無効にできます。v5.0 以降では、設定値はtrueに強制的に設定されます。
• gc.enable-compaction-filter設定項目のデフォルト値をfalseからtrueに変更します。
• enable-cross-table-merge設定項目のデフォルト値をfalseからtrueに変更します。
• rate-limiter-auto-tuned設定項目のデフォルト値をfalseからtrueに変更します。

その他

• アップグレード前に、TiDB構成のfeedback-probabilityの値を確認してください。値が0でない場合、アップグレード後に「回復可能なゴルーチンでpanicが発生しました」というエラーが発生しますが、このエラーはアップグレード自体には影響しません。
• 列の型変更時に、 VARCHAR型とCHAR型の間の変換を禁止し、データの正確性に関する問題を回避する。

新機能

SQL

List パーティショニング（Experimental）

ユーザー向けドキュメント

リストパーティショニング機能を使用すると、大量のデータを含むテーブルを効率的にクエリおよび管理できます。

この機能を有効にすると、 PARTITION BY LIST(expr) PARTITION part_name VALUES IN (...)式に従ってパーティションとパーティション間のデータの分散方法が定義されます。パーティション化されたテーブルのデータセットは、最大 1024 個の異なる整数値をサポートします。これらの値はPARTITION ... VALUES IN (...)句を使用して定義できます。

リストパーティショニングを有効にするには、セッション変数tidb_enable_list_partition ONに設定します。

List COLUMNS パーティショニング（Experimental）

ユーザー向けドキュメント

List COLUMNS パーティショニングは、リストパーティショニングの一種です。複数の列をパーティションキーとして使用できます。整数データ型の他に、文字列、 DATE 、およびDATETIMEデータ型の列もパーティション列として使用できます。

List COLUMNS パーティショニングを有効にするには、セッション変数tidb_enable_list_partition ONに設定します。

見えないインデックス

ユーザー向けドキュメント、 #9246

パフォーマンスを調整したり、最適なインデックスを選択したりする場合、SQL ステートメントを使用してインデックスをVisibleまたはInvisibleに設定できます。この設定により、 DROP INDEXやADD INDEXなどのリソースを消費する操作の実行を回避できます。

インデックスの表示設定を変更するには、 ALTER INDEXステートメントを使用します。変更後、オプティマイザはインデックスの表示設定に基づいて、このインデックスをインデックスリストに追加するかどうかを決定します。

EXCEPT演算子とINTERSECT演算子

ユーザー向けドキュメント、 #18031

INTERSECT演算子は集合演算子であり、2つ以上のクエリの結果セットの共通部分を返します。これは、 Inner Join演算子の代替手段と言えます。

EXCEPT演算子は集合演算子であり、2つのクエリの結果セットを結合し、最初のクエリ結果には含まれるが2番目のクエリ結果には含まれない要素を返します。

トランザクション

#18005

悲観的トランザクション モードでは、トランザクションに関係するテーブルに同時 DDL 操作またはSCHEMA VERSION変更が含まれている場合、トランザクションのコミットが成功するように、またトランザクションが DDL 操作またはSCHEMA VERSION変更によって中断されたときにクライアントがInformation schema is changedエラーを受け取るのを避けるために、システムはトランザクションのSCHEMA VERSION最新の状態に自動的に更新します。

この機能はデフォルトでは無効になっています。機能を有効にするには、システム変数tidb_enable_amend_pessimistic_txnの値を変更してください。この機能はバージョン 4.0.7 で導入され、バージョン 5.0 で以下の問題が修正されています。

• TiDB Binlog がAdd Column操作を実行する際に発生する互換性の問題
• ユニークインデックスとこの機能を併用した場合に発生するデータ不整合の問題
• 追加されたインデックスとこの機能を併用した場合に発生するデータ不整合の問題

現在、この機能には以下の互換性の問題が残っています。

• 同時トランザクションが発生すると、トランザクションの意味が変わる可能性があります。
• TiDB Binlogと併用した場合に発生する既知の互換性の問題
• Change Columnとの非互換性

文字セットと照合順序

• utf8mb4_unicode_ciおよびutf8_unicode_ci照合順序をサポートします。 ユーザー向けドキュメント、 #17596
• 照合順序における大文字小文字を区別しない比較ソートをサポートする

Security

ユーザー向けドキュメント、 #18566

セキュリティコンプライアンス要件（一般データ保護規則、GDPRなど）を満たすため、システムは出力されるエラーメッセージやログから情報（IDやクレジットカード番号など）を匿名化する機能をサポートしており、機密情報の漏洩を防ぐことができます。

TiDBは出力ログ情報の非機密化をサポートしています。この機能を有効にするには、以下のスイッチを使用してください。

• グローバル変数tidb_redact_log 。デフォルト値は0で、これは非機密化が無効になっていることを意味します。tidb-server ログの非機密化を有効にするには、変数の値を1に設定します。
• 設定項目security.redact-info-log 。デフォルト値はfalseで、これは非感度化が無効になっていることを意味します。tikv-server ログの非感度化を有効にするには、変数の値をtrueに設定します。
• 設定項目security.redact-info-log 。デフォルト値はfalseで、これは非機密化が無効になっていることを意味します。pd-server ログの非機密化を有効にするには、変数の値をtrueに設定します。
• tiflash-server の構成項目security.redact_info_logと tiflash-learner の構成項目security.redact-info-logです。デフォルト値はどちらもfalseで、これは感度低減が無効になっていることを意味します。tiflash-server と tiflash-learner のログの感度低減を有効にするには、両方の変数の値をtrueに設定します。

この機能はバージョン5.0で導入されました。この機能を使用するには、上記のシステム変数とすべての設定項目を有効にしてください。

パフォーマンス最適化

MPPアーキテクチャ

ユーザー向けドキュメント

TiDBは、 TiFlashノードを通じてMPPアーキテクチャを導入しています。このアーキテクチャにより、複数のTiFlashノードが大規模な結合クエリの実行ワークロードを共有することが可能になります。

MPPモードが有効な場合、TiDBは計算コストに基づいて、クエリをMPPエンジンに送信して計算を行うかどうかを判断します。MPPモードでは、TiDBはデータ計算中に結合キーを再分配することで（ Exchange操作）、テーブル結合の計算を各実行中のTiFlashノードに分散し、計算を高速化します。さらに、 TiFlashが既にサポートしている集計計算機能により、TiDBはクエリの計算をTiFlash MPPクラスタにプッシュダウンできます。これにより、分散環境が実行プロセス全体を高速化し、分析クエリの速度を大幅に向上させることができます。

TPC-H 100ベンチマークテストにおいて、 TiFlash MPPは従来の分析データベースやHadoop上のSQLの分析エンジンに比べて大幅な処理速度向上を実現しています。このアーキテクチャにより、最新のトランザクションデータに対して大規模な分析クエリを直接実行でき、従来のオフライン分析ソリューションよりも高いパフォーマンスを発揮します。ベンチマークによると、同じクラスタリソースを使用した場合、TiDB 5.0 MPPはGreenplum 6.15.0およびApache Spark 3.1.1に比べて2～3倍の高速化を実現し、一部のクエリでは8倍のパフォーマンス向上を達成しています。

現在、MPP モードがサポートしていない主な機能は次のとおりです (詳細については、 TiFlashを使用するを参照してください)。

• テーブルパーティショニング
• ウィンドウ機能
• 照合
• 組み込み関数
• TiKVからデータを読み取る
• OOM流出
• 連合
• フルアウタージョイント

クラスター化インデックス

ユーザー向けドキュメント、 #4841

テーブル構造を設計したり、データベースの動作を分析したりする際に、主キーを持つ一部の列が頻繁にグループ化およびソートされ、これらの列に対するクエリが特定の範囲のデータまたは異なる値を持つ少量のデータを頻繁に返し、対応するデータが読み取りまたは書き込みのホットスポット問題を引き起こさないことがわかった場合は、クラスタ化インデックス機能を使用することをお勧めします。

クラスタ化インデックスは、テーブルのデータに関連付けられたstorage構造です。一部のデータベース管理システムでは、クラスタ化インデックステーブルをインデックス構成テーブルと呼びます。クラスタ化インデックスを作成する際には、テーブルの1つ以上の列をインデックスのキーとして指定できます。TiDBはこれらのキーを特定の構造に格納するため、キーに関連付けられた行を迅速かつ効率的に検索でき、クエリとデータ書き込みのパフォーマンスが向上します。

クラスタ化インデックス機能を有効にすると、TiDB のパフォーマンスは大幅に向上します (例えば、TPC-C tpmC テストでは、クラスタ化インデックスを有効にした TiDB のパフォーマンスは、以下のケースで 39% 向上します)。

• データが挿入される際、クラスタ化インデックスによって、ネットワークからのインデックスデータの書き込み回数が1回削減されます。
• 同等の条件を持つクエリが主キーのみに関係する場合、クラスタ化インデックスによってネットワークからのインデックスデータの読み取り回数が1回削減されます。
• 範囲条件を含むクエリが主キーのみに関係する場合、クラスタ化インデックスはネットワークからのインデックスデータの読み取り回数を削減します。
• 同等条件または範囲条件を含むクエリに主キーのプレフィックスが含まれる場合、クラスタ化インデックスによってネットワークからのインデックスデータの読み取り回数が削減されます。

各テーブルは、クラスタ化インデックスまたは非クラスタ化インデックスのいずれかを使用してデータをソートおよび格納できます。これら2つのstorage構造の違いは次のとおりです。

• クラスター化インデックスを作成する際、テーブル内の1つまたは複数の列をインデックスのキー値として指定できます。クラスター化インデックスは、キー値に基づいてテーブルのデータをソートして格納します。各テーブルには、クラスター化インデックスを1つだけ設定できます。テーブルにクラスター化インデックスがある場合、そのテーブルはクラスター化インデックステーブルと呼ばれます。そうでない場合は、非クラスター化インデックステーブルと呼ばれます。
• 非クラスタ化インデックスを作成すると、テーブル内のデータは順不同構造で格納されます。TiDBは各データ行に一意のROWIDを自動的に割り当てるため、非クラスタ化インデックスのキー値を明示的に指定する必要はありません。クエリ実行時には、ROWIDを使用して対応する行が特定されます。データのクエリまたは挿入時には少なくとも2回のネットワークI/O操作が発生するため、クラスタ化インデックスと比較してパフォーマンスが低下します。

テーブルデータが変更されると、データベースシステムはクラスタ化インデックスと非クラスタ化インデックスを自動的に維持します。

デフォルトでは、すべての主キーは非クラスター化インデックスとして作成されます。主キーをクラスター化インデックスまたは非クラスター化インデックスとして作成するには、次の 2 つの方法のいずれかを使用できます。

• テーブルを作成する際に、ステートメント内でキーワードCLUSTERED | NONCLUSTEREDを指定すると、システムは指定された方法でテーブルを作成します。構文は以下のとおりです。

CREATE TABLE `t` (`a` VARCHAR(255), `b` INT, PRIMARY KEY (`a`, `b`) CLUSTERED);

または

CREATE TABLE `t` (`a` VARCHAR(255) PRIMARY KEY CLUSTERED, `b` INT);

テーブルにクラスタ化インデックスがあるかどうかを照会するにはSHOW INDEX FROM tbl-nameというステートメントを実行します。

• クラスタ化インデックス機能を制御するには、システム変数tidb_enable_clustered_indexを設定します。サポートされている値は、 ON 、 OFF 、およびINT_ONLY 。
  • ON : すべてのタイプの主キーに対してクラスタ化インデックス機能が有効になっていることを示します。非クラスタ化インデックスの追加と削除がサポートされています。
  • OFF : すべてのタイプの主キーに対して、クラスタ化インデックス機能が無効になっていることを示します。非クラスタ化インデックスの追加と削除はサポートされています。
  • INT_ONLY : デフォルト値。変数がINT_ONLYに設定され、 alter-primary-keyがfalseに設定されている場合、単一の整数列で構成される主キーは、デフォルトでクラスタ化インデックスとして作成されます。この動作は、TiDB v5.0 およびそれ以前のバージョンと同様です。

CREATE TABLEステートメントにキーワードCLUSTERED | NONCLUSTEREDが含まれている場合、そのステートメントはシステム変数と構成項目の設定を上書きします。

ステートメントでキーワードCLUSTERED | NONCLUSTERED指定して、クラスタ化インデックス機能を使用することをお勧めします。この方法により、TiDB は必要に応じてシステム内のクラスタ化インデックスと非クラスタ化インデックスのすべてのデータ型を同時に使用できるようになり、より柔軟に対応できます。

tidb_enable_clustered_index = INT_ONLYの使用は推奨されません。 INT_ONLYは、この機能の互換性を確保するために一時的に使用されており、将来的に廃止される予定です。

クラスタ化インデックスの制限事項は以下のとおりです。

• クラスタ化インデックスと非クラスタ化インデックス間の相互変換はサポートされていません。
• クラスター化インデックスの削除はサポートされていません。
• ALTER TABLEステートメントを使用したクラスタ化インデックスの追加、削除、および変更はサポートされていません。
• クラスタ化インデックスの再編成および再作成はサポートされていません。
• インデックスの有効化または無効化はサポートされていないため、非表示インデックス機能はクラスタ化インデックスには適用されません。
• UNIQUE KEYをクラスタ化インデックスとして作成することはサポートされていません。
• TiDB Binlogとクラスタ化インデックス機能を併用することはサポートされていません。TiDB Binlog を有効にすると、TiDB は単一の整数プライマリキーのみをクラスタ化インデックスとして作成することをサポートします。TiDB Binlog は、クラスタ化インデックスを持つ既存のテーブルのデータ変更をダウンストリームにレプリケートしません。
• クラスタ化インデックス機能を属性SHARD_ROW_ID_BITSおよびPRE_SPLIT_REGIONSと併用することはサポートされていません。
• クラスターを新しいバージョンにアップグレードした後、ロールバックした場合、ロールバック前にテーブルデータをエクスポートし、ロールバック後にデータをインポートすることで、新しく追加されたテーブルをダウングレードする必要があります。その他のテーブルは影響を受けません。

非同期コミット

ユーザー向けドキュメント、 #8316

データベースのクライアントは、データベースシステムがトランザクションのコミットを2段階（2PC）で同期的に完了するまで待機します。トランザクションは、第1段階のコミットが成功した後に結果をクライアントに返し、システムは第2段階のコミット操作をバックグラウンドで非同期的に実行して、トランザクションのコミットレイテンシーを短縮します。トランザクションの書き込みが1つのリージョンのみに関係する場合は、第2段階は省略され、トランザクションは1段階のコミットとなります。

非同期コミット機能を有効にした後、同じハードウェアと構成で、Sysbenchを64スレッドで更新インデックスをテストするように設定すると、平均レイテンシーが12.04msから7.01msに41.7%減少します。

非同期コミット機能が有効になっている場合、ネットワークインタラクションのレイテンシーを1回減らし、データ書き込みのパフォーマンスを向上させるために、データベースアプリケーション開発者は、トランザクションの一貫性を線形一貫性から因果関係の一貫性の に下げることを検討することをお勧めします。因果一貫性を有効にするSQLステートメントはSTART TRANSACTION WITH CAUSAL CONSISTENCYです。

因果的一貫性を有効にした後、同じハードウェアと構成で、Sysbenchをoltp_write_onlyを64スレッドでテストするように設定すると、平均レイテンシーが11.86msから11.19msに5.6%減少しました。

トランザクションの一貫性が線形一貫性から因果一貫性に低下した後、アプリケーション内の複数のトランザクション間に相互依存性がない場合、トランザクションはグローバルに一貫した順序を持ちません。

非同期コミット機能は、新しく作成されたv5.0クラスターではデフォルトで有効になっています。

この機能は、以前のバージョンから v5.0 にアップグレードされたクラスターではデフォルトで無効になっています。 set global tidb_enable_async_commit = ON;およびset global tidb_enable_1pc = ON;ステートメントを実行することで、この機能を有効にできます。

非同期コミット機能の制限事項は以下のとおりです。

• 直接的なダウングレードはサポートされていません。

コプロセッサーキャッシュ機能をデフォルトで有効にする

ユーザー向けドキュメント、 #18028

5.0 GAでは、コプロセッサーキャッシュ機能がデフォルトで有効になっています。この機能が有効になると、データ読み取りのレイテンシーを削減するために、TiDBはtikv-serverにプッシュダウンされた演算子の計算結果をtidb-serverにキャッシュします。

コプロセッサーキャッシュ機能を無効にするには、 capacity-mbの構成項目tikv-client.copr-cacheを0.0に変更します。

delete from table where id <? Limit ?ステートメントの実行パフォーマンスを改善します。

#18028

delete from table where id <? limit ?ステートメントの p99 パフォーマンスは 4 倍向上しました。

ロードベース分割戦略を最適化し、一部の小規模テーブルホットスポット読み取りシナリオでデータが分割できないというパフォーマンス問題を解決します。

#18005

安定性を向上させる

不完全なスケジューリングによって引き起こされるパフォーマンスのジッター問題を最適化します。

#18005

TiDBのスケジューリングプロセスは、I/O、ネットワーク、CPU、メモリなどのリソースを消費します。TiDBがスケジュールされたタスクを制御しない場合、リソースの優先実行により、QPS（1秒あたりの処理数）や遅延が発生し、パフォーマンスの変動が生じる可能性があります。

以下の最適化後、8時間の性能試験において、TPC-C tpmCの標準偏差は2%を超えない。

不要なスケジューリングとパフォーマンスのジッターを軽減するために、新しいスケジューリング計算式を導入する。

ノード容量がシステムで設定された上限値に常に近い場合、またはstore-limitが大きすぎる場合、容量負荷のバランスを取るために、システムはリージョンを他のノードに頻繁に割り当てたり、リージョンを元のノードに戻したりします。スケジューリングはI/O、ネットワーク、CPU、メモリなどのリソースを消費し、パフォーマンスの変動を引き起こすため、このタイプのスケジューリングは不要です。

この問題を軽減するために、PD は新しいデフォルトのスケジュール計算式を導入しました。 region-score-formula-version = v1を設定することで、以前の計算式に戻すことができます。

デフォルトでクロステーブルリージョンマージ機能を有効にする

ユーザー向けドキュメント

バージョン5.0より前は、TiDBはデフォルトでクロステーブルリージョンマージ機能を無効にしていました。バージョン5.0以降では、空のリージョンの数を減らし、ネットワーク、メモリ、CPUのオーバーヘッドを削減するために、この機能がデフォルトで有効になっています。この機能はschedule.enable-cross-table-merge構成項目を変更することで無効にできます。

バックグラウンドタスクとフォアグラウンドの読み書き間のI/Oリソースの競合のバランスを取るために、システムがデフォルトでデータ圧縮速度を自動的に調整できるようにします。

ユーザー向けドキュメント

バージョン5.0より前は、バックグラウンドタスクとフォアグラウンドの読み書きにおけるI/Oリソースの競合を緩和するため、データ圧縮速度をシステムが自動的に調整する機能はデフォルトで無効になっていました。バージョン5.0以降、TiDBはこの機能をデフォルトで有効にし、アルゴリズムを最適化することで、レイテンシーのジッターを大幅に低減します。

rate-limiter-auto-tuned設定項目を変更することで、この機能を無効にすることができます。

GCのCPUおよびI/Oリソース消費を削減するために、GCコンパクションフィルタ機能をデフォルトで有効にします。

ユーザー向けドキュメント、 #18009

TiDBがガベージコレクション（GC）とデータ圧縮を実行する際、パーティションはCPUとI/Oリソースを消費します。これらの2つのタスクの実行中は、データが重複している状態が発生します。

GC の CPU および I/O リソースの消費を削減するために、GC コンパクション フィルタ機能は、これら 2 つのタスクを 1 つに結合し、同じタスクで実行します。この機能はデフォルトで有効になっています。 gc.enable-compaction-filter = falseを設定することで無効にできます。

TiFlashは、圧縮とデータソートにおけるI/Oリソースの使用を制限します（実験的機能）。

この機能は、バックグラウンドタスクとフォアグラウンドの読み書き処理の間で発生するI/Oリソースの競合を軽減します。

この機能はデフォルトでは無効になっています。 bg_task_io_rate_limit設定項目を変更することで、この機能を有効にできます。

大規模クラスタにおけるスケジューリング制約のチェック性能と、異常リージョンの修復性能を向上させる。

パフォーマンスの変動を避けるため、実行計画はできる限り変更しないようにしてください。

ユーザー向けドキュメント

SQLバインディングは、 INSERT 、 REPLACE 、 UPDATE 、 DELETEステートメントをサポートします。

パフォーマンスの調整やデータベースの保守を行う際に、実行プランの不安定さが原因でシステムパフォーマンスが不安定になっていることが判明した場合、ご自身の判断またはEXPLAIN ANALYZEによるテストに基づいて、手動で最適化されたSQL文を選択できます。最適化されたSQL文をアプリケーションコードで実行されるSQL文にバインドすることで、安定したパフォーマンスを確保できます。

SQL BINDING ステートメントを使用して SQL ステートメントを手動でバインドする場合、最適化された SQL ステートメントが元の SQL ステートメントと同じ構文であることを確認する必要があります。

SHOW {GLOBAL | SESSION} BINDINGSコマンドを実行すると、手動または自動でバインドされた実行プラン情報を表示できます。出力はバージョン 5.0 より前のバージョンと同じです。

実行プランを自動的にキャプチャしてバインドします

TiDBをアップグレードする際、パフォーマンスの不安定性を回避するために、ベースラインキャプチャ機能を有効にして、システムが最新の実行プランを自動的にキャプチャしてバインドし、システムテーブルに保存するように設定できます。TiDBのアップグレード後、 SHOW GLOBAL BINDINGコマンドを実行してバインドされた実行プランをエクスポートし、これらのプランを削除するかどうかを決定できます。

この機能はデフォルトでは無効になっています。サーバーを変更するか、グローバルシステム変数tidb_capture_plan_baselines ONに設定することで有効にできます。この機能が有効になると、システムはbind-info-leaseごと (デフォルト値は3s )、ステートメントサマリーから少なくとも 2 回出現する SQL ステートメントを取得し、これらの SQL ステートメントを自動的にキャプチャしてバインドします。

TiFlashクエリの安定性を向上させる

TiFlash が失敗した場合にクエリを TiKV にフォールバックするように、システム変数tidb_allow_fallback_to_tikvを追加します。デフォルト値はOFFです。

TiCDCの安定性を向上させ、過剰な増分データの複製によって引き起こされるメモリ不足の問題を軽減する。

ユーザー向けドキュメント、 #1150

TiCDC v4.0.9以前のバージョンでは、データ変更を過剰に複製するとメモリ不足（OOM）が発生する可能性があります。v5.0では、以下のシナリオで発生するOOMの問題を軽減するために、統合ソーター機能がデフォルトで有効になっています。

• TiCDCにおけるデータ複製タスクが長時間一時停止され、その間に大量の増分データが蓄積され、複製する必要が生じる。
• データ複製タスクは初期のタイムスタンプから開始されるため、大量の増分データを複製する必要が生じる。

Unified Sorterは、以前のバージョンのmemory / fileソートエンジンオプションと統合されています。変更を手動で設定する必要はありません。

制限事項：

• 追加データ量に応じて、十分なディスク容量を確保する必要があります。128GB以上の空き容量を持つSSDの使用をお勧めします。

高可用性とディザスタリカバリ

リージョンメンバーシップ変更時のシステム可用性を向上させる

ユーザー向けドキュメント、 #18079 、 #7587 、 #2860

リージョンメンバーシップの変更処理では、「メンバーの追加」と「メンバーの削除」という2つの操作が2つのステップで実行されます。メンバーシップ変更処理の完了時にエラーが発生した場合、リージョンは利用できなくなり、フォアグラウンドアプリケーションのエラーが返されます。

導入されたRaft共同合意アルゴリズムは、リージョンメンバーシップ変更時のシステム可用性を向上させることができます。メンバーシップ変更時の「メンバーの追加」と「メンバーの削除」操作は1つの操作に統合され、すべてのメンバーに送信されます。変更処理中、リージョンは中間状態になります。変更されたメンバーのいずれかが故障した場合でも、システムは引き続き利用可能です。

この機能はデフォルトで有効になっています。 pd-ctl config set enable-joint-consensusコマンドを実行してenable-joint-consensusの値をfalseに設定することで無効にできます。

メモリ管理モジュールを最適化して、システムOOMリスクを低減する

集計関数のメモリ使用量を追跡します。この機能はデフォルトで有効になっています。集計関数を含む SQL ステートメントが実行されると、現在のクエリの合計メモリ使用量mem-quota-queryで設定されたしきい値を超えた場合、システムはoom-actionで定義された操作を自動的に実行します。

ネットワーク分断時のシステム可用性を向上させる

データ移行

S3/ AuroraからTiDBへデータを移行する

TiDBのデータ移行ツールは、データ移行の中間段階としてAmazon S3（およびその他のS3互換storageサービス）を使用し、 AuroraスナップショットデータをTiDBに直接初期化することをサポートしており、Amazon S3/ AuroraからTiDBへのデータ移行に関するより多くの選択肢を提供します。

この機能を使用するには、以下のドキュメントを参照してください。

• データをAmazon S3クラウドstorageにエクスポートする、 #8
• TiDB Lightningを使用してAmazon Aurora MySQLから移行する、 #266

TiDB Cloudのデータインポートパフォーマンスを最適化する

TiDB Lightningは、特にAWS T1.standard構成（または同等の構成）のTiDB Cloud向けにデータインポートのパフォーマンスを最適化します。テスト結果によると、 TiDB Lightningは1TBのTPC-CデータをTiDBにインポートする速度を40%向上させ、254 GiB/hから366 GiB/hに向上させます。

データ共有と購読

TiCDCを使用してTiDBをKafka Connect（Confluent Platform）に統合する（実験的機能）

ユーザー向けドキュメント #660

TiDBデータを他のシステムにストリーミングするというビジネス要件をサポートするため、この機能を使用すると、TiDBデータをKafka、Hadoop、Oracleなどのシステムにストリーミングできます。

Confluentプラットフォームが提供するKafkaコネクタプロトコルは、コミュニティで広く利用されており、さまざまなプロトコルでリレーショナルデータベースと非リレーショナルデータベースの両方へのデータ転送をサポートしています。TiDBは、TiCDCをConfluentプラットフォームのKafka Connectに統合することで、TiDBデータを他の異種データベースやシステムにストリーミングする機能を拡張します。

診断

ユーザー向けドキュメント

SQLのパフォーマンス問題のトラブルシューティングでは、パフォーマンス問題の原因を特定するために詳細な診断情報が必要です。TiDB 5.0より前は、 EXPLAINステートメントで収集される情報は十分詳細ではありませんでした。問題の根本原因は、ログ情報、監視情報、あるいは推測に基づいてしか特定できず、非効率的でした。

TiDB v5.0では、パフォーマンスの問題をより効率的にトラブルシューティングできるよう、以下の改善が行われました。

• EXPLAIN ANALYZEステートメントを使用してすべての DML ステートメントを分析し、各演算子の実際のパフォーマンス プランと実行情報を表示する機能をサポートします。 #18056
• EXPLAIN FOR CONNECTIONステートメントを使用して、実行中のすべての SQL ステートメントのリアルタイム ステータスを確認できるようにしました。たとえば、このステートメントを使用して、各演算子の実行時間と処理された行数を確認できます。 #18233
• EXPLAIN ANALYZEステートメントの出力に、オペレーターの実行に関する詳細情報（オペレーターが送信した RPC リクエストの数、ロック競合の解決にかかった時間、ネットワークレイテンシー、RocksDB でスキャンされた削除済みデータのボリューム、RocksDB キャッシュのヒット率など）を記載してください。 #18663
• SQL文の詳細な実行情報をスローログに自動的に記録する機能をサポートします。スローログの実行情報は、 EXPLAIN ANALYZE文の出力情報と一致しており、各演算子の消費時間、処理された行数、送信されたRPCリクエスト数などが含まれます。 #15009

導入と保守

クラスタ展開操作のロジックを最適化し、DBAが標準的なTiDB本番クラスタをより迅速に展開できるようにします。

ユーザー向けドキュメント

以前のTiDBバージョンでは、 TiUPを使用してTiDBクラスタをデプロイするDBAは、環境初期化が複雑で、チェックサム構成が過剰であり、クラスタトポロジーファイルの編集が困難であるという問題に直面していました。これらの問題はすべて、DBAのデプロイ効率の低下につながっていました。TiDB v5.0では、以下の項目により、 TiUPを使用したTiDBデプロイの効率がDBA向けに改善されています。

• TiUP クラスタは、より包括的なワンクリック環境チェックを実行し、修復に関する推奨事項を提供するcheck topo.yamlコマンドをサポートしています。
• TiUP クラスタは、環境チェック中に検出された環境問題を自動的に修復するcheck topo.yaml --applyコマンドをサポートしています。
• TiUP クラスタ は、DBA が編集するためのクラスタ トポロジ テンプレート ファイルを取得し、グローバル ノード パラメータの変更をサポートするtemplateコマンドをサポートしています。
• TiUPはremote_configコマンドを使用してedit-configパラメータを編集し、リモートPrometheusを設定することをサポートしています。
• TiUPはexternal_alertmanagersコマンドを使用して異なるAlertManagerを設定するために、 edit-configパラメーターの編集をサポートしています。
• tiup-clusterのedit-configサブコマンドを使用してトポロジ ファイルを編集する場合、構成項目の値のデータ型を変更できます。

アップグレードの安定性を向上させる

TiUP v1.4.0より前は、 tiup-clusterを使用してTiDBクラスタをアップグレードする際に、クラスタのSQL応答が長時間ジッターし、PDオンラインローリングアップグレード中にクラスタのQPSが10秒から30秒の間でジッターしていました。

TiUP v1.4.0では、ロジックを調整し、以下の最適化を行いました。

• PDノードのアップグレード中、 TiUPは再起動されたPDノードの状態を自動的にチェックし、状態が準備完了であることを確認した後、次のPDノードのアップグレードに進みます。
• TiUPはPDの役割を自動的に識別し、まずフォロワーの役割を持つPDノードをアップグレードし、最後にPDLeaderノードをアップグレードします。

アップグレード時間を最適化する

TiUP v1.4.0より前は、DBAがtiup-clusterを使用してTiDBクラスタをアップグレードする場合、ノード数が多いクラスタでは、アップグレードにかかる合計時間が長く、一部のユーザーのアップグレード時間枠の要件を満たせないことがありました。

バージョン1.4.0以降、 TiUPは以下の項目を最適化します。

• tiup cluster upgrade --offlineサブコマンドを使用した高速オフラインアップグレードをサポートします。
• デフォルトで、アップグレード中にローリングアップグレードを使用するユーザーのリージョンLeaderの再配置を高速化することで、TiKVのローリングアップグレードにかかる時間を短縮します。
• ローリングアップグレードを実行する前に、 checkサブコマンドを使用してリージョンモニターの状態を確認します。アップグレード前にクラスターが正常な状態であることを確認することで、アップグレードの失敗の可能性を低減します。

ブレークポイント機能をサポートする

TiUP v1.4.0より前のバージョンでは、DBAがtiup-clusterを使用してTiDBクラスタをアップグレードする際に、コマンドの実行が中断された場合、すべてのアップグレード操作を最初からやり直す必要がありました。

TiUP v1.4.0 では、 tiup-cluster replayサブコマンドを使用して、ブレークポイントから失敗した操作を再試行することがサポートされており、アップグレードの中断後にすべての操作を再実行する必要がなくなります。

保守および運用機能を強化する

TiUP v1.4.0では、TiDBクラスタの運用と保守に関する機能がさらに強化されています。

• TiDBおよびDMクラスタのダウンタイム中のアップグレードまたはパッチ適用操作をサポートし、より多くの利用シナリオに対応できるようにします。
• tiup-clusterの--versionサブコマンドにdisplayパラメータを追加して、クラスタバージョンを取得します。
• スケールアウト対象のノードにPrometheusのみが含まれている場合、Prometheusノードの不在によるスケールアウトの失敗を回避するため、監視設定の更新操作は実行されません。
• TiUPコマンドの入力結果が正しくない場合に、エラーメッセージにユーザー入力を追加することで、問題の原因をより迅速に特定できるようにします。

テレメトリー

TiDBは、データテーブルの数、クエリの数、新機能が有効になっているかどうかなど、クラスタの使用状況に関するメトリクスをテレメトリに追加します。

詳細およびこの動作を無効にする方法については、テレメトリーを参照してください。