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 アドレスにアクセスできる場合、 Dumpling は元のクラスターに影響を与えずに 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 には、単一の SQL ステートメントの実行時間を制限するためのシステム変数 (デフォルトではmax_execution_time 、 0 、制限なしを示します) も用意されています。現在、システム変数は読み取り専用 SQL ステートメントにのみ有効です。 max_execution_timeの単位はmsですが、実際の精度はミリ秒レベルではなく100msレベルです。

JDBC クエリタイムアウト

MySQL JDBC のクエリタイムアウト設定setQueryTimeout()は、TiDB では機能しません。これは、クライアントがタイムアウトを検出すると、データベースにKILLコマンドを送信するためです。ただし、tidb サーバーは負荷分散されており、間違った tidb サーバーでの接続の終了を回避するために、このKILLコマンドは実行されません。クエリタイムアウトの効果を確認するには、 MAX_EXECUTION_TIME使用する必要があります。

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

wait_timeout は、 Javaアプリケーションへの接続の非対話型アイドルタイムアウトを制御します。TiDB v5.4 以降、デフォルト値wait_timeoutは28800秒 (8 時間) です。v5.4 より前のバージョンの TiDB の場合、デフォルト値は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分)

ヘルプが必要ですか?

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