TiDBのタイムアウト

このドキュメントでは、エラーのトラブルシューティングに役立つ TiDB のさまざまなタイムアウトについて説明します。

GCタイムアウト

TiDBのトランザクション実装では、MVCC（Multiple Version Concurrency Control）メカニズムが採用されています。新しく書き込まれたデータが古いデータを上書きする場合、古いデータは置き換えられず、新しく書き込まれたデータと一緒に保持されます。バージョンはタイムスタンプによって区別されます。TiDBは、定期的なガベージコレクション（GC）メカニズムを使用して、不要になった古いデータをクリーンアップします。

TiDB バージョン v4.0 より前のバージョンの場合:
デフォルトでは、各MVCCバージョン（整合性スナップショット）は10分間保持されます。読み取りに10分以上かかるトランザクションにはエラーGC life time is shorter than transaction durationが返されます。
TiDB v4.0 以降のバージョンの場合:
24時間を超えない実行中のトランザクションの場合、トランザクション実行中はガベージコレクション（GC）がブロックされます。エラーGC life time is shorter than transaction durationは発生しません。

一時的に読み取り時間を長くする必要がある場合は、MVCC バージョンの保持時間を長くすることができます。

v5.0 より前の TiDB バージョンの場合: TiDB のmysql.tidbテーブルのtikv_gc_life_time調整します。
TiDB v5.0 以降のバージョンの場合: システム変数tidb_gc_life_time調整します。

システム変数の設定は、グローバルかつ即座に反映されます。値を増やすと、既存のすべてのスナップショットの有効期間が延長され、値を減らすと、すべてのスナップショットの有効期間が即座に短縮されます。MVCCのバージョンが多すぎると、TiDBクラスタのパフォーマンスに影響します。そのため、この変数は適切なタイミングで以前の設定に戻す必要があります。

ヒント：
具体的には、 Dumplingが TiDB (1 TB 未満) からデータをエクスポートする際に、TiDB のバージョンが v4.0.0 以降であり、 Dumpling がTiDB クラスターの PD アドレスとINFORMATION_SCHEMA.CLUSTER_INFOテーブルにアクセスできる場合、 Dumpling は自動的に GC セーフポイントを調整し、元のクラスターに影響を与えずに GC をブロックします。
ただし、次のいずれかのシナリオでは、 Dumpling はGC 時間を自動的に調整できません。
データサイズが非常に大きい（1TB以上）。
Dumpling はPD に直接接続できません。たとえば、 TiDB クラスターはTiDB Cloud上、またはDumplingとは分離された Kubernetes 上にあります。
このようなシナリオでは、エクスポートプロセス中の GC によるエクスポートの失敗を回避するために、事前に GC 時間を手動で延長する必要があります。
詳細はTiDB GC時間を手動で設定する参照。

GC の詳細については、 GCの概要参照してください。

トランザクションタイムアウト

トランザクションが開始されたものの、コミットもロールバックもされないシナリオでは、ロックの長時間保持を防ぐために、よりきめ細かな制御と短いタイムアウトが必要になる場合があります。このような場合は、 tidb_idle_transaction_timeout （TiDB v7.6.0で導入）を使用して、ユーザーセッション内のトランザクションのアイドルタイムアウトを制御できます。

GCは実行中のトランザクションには影響しません。ただし、実行可能な悲観的トランザクションの数には上限があり、トランザクションのタイムアウトとトランザクションで使用されるメモリにも制限があります。トランザクションタイムアウトは、TiDBプロファイルのカテゴリ[performance]でmax-txn-ttlずつ変更できます。デフォルトでは60分です。

INSERT INTO t10 SELECT * FROM t1ような SQL 文は GC の影響を受けませんが、 max-txn-ttl超えるとタイムアウトによりロールバックされます。

SQL実行タイムアウト

TiDB max_execution_timeは、単一のSQL文の実行時間を制限するシステム変数（デフォルトではmax_execution_time 、 0 、制限なしを意味します）も用意されています。現在、このシステム変数は読み取り専用SQL文にのみ適用されます。5の単位はmsですが、実際の精度はミリ秒単位ではなく100ms単位です。

JDBCクエリタイムアウト

v6.1.0 以降、 enable-global-kill構成項目がデフォルト値trueに設定されている場合、MySQL JDBC によって提供されるsetQueryTimeout()メソッドを使用してクエリタイムアウトを制御できます。

注記：
TiDBのバージョンがv6.1.0より前の場合、またはenable-global-kill falseに設定されている場合、 setQueryTimeout() TiDBでは機能しません。これは、クライアントがクエリタイムアウトを検出すると、データベースにKILLコマンドを送信するためです。ただし、TiDBサービスは負荷分散されているため、間違ったTiDBノードで接続が切断されるのを防ぐため、 KILLコマンドは実行されません。このような場合は、 max_execution_time使用してクエリタイムアウトを制御できます。

TiDB は、次の MySQL 互換のタイムアウト制御パラメータを提供します。

wait_timeout は、 Javaアプリケーションへの接続における非対話型アイドルタイムアウトを制御します。TiDB v5.4以降では、デフォルト値はwait_timeoutで、これは28800秒（8時間）です。TiDB v5.4より前のバージョンでは、デフォルト値は0で、これはタイムアウトが無制限であることを意味します。
interactive_timeout は、 Javaアプリケーションへの接続における対話型アイドルタイムアウトを制御します。デフォルトの値は8 hoursです。
max_execution_time は、接続におけるSQL実行のタイムアウトを制御します。これは読み取り専用SQL文にのみ有効です。デフォルトの値は0で、接続が無限にビジー状態になることを許可します。つまり、SQL文は無限に長い時間実行されます。

しかし、実際の本番環境では、アイドル接続とSQL文の無期限実行は、データベースとアプリケーションの両方に悪影響を及ぼします。アプリケーションの接続文字列でこれらの2つのセッションレベル変数を設定することで、アイドル接続とSQL文の無期限実行を回避できます。例えば、次のように設定します。

sessionVariables=wait_timeout=3600 （1時間）
sessionVariables=max_execution_time=300000 （5分）

ヘルプが必要ですか?

不和またはスラック、あるいはサポートチケットを送信するについてコミュニティに質問してください。