TiDBのタイムアウト

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

GCタイムアウト

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

デフォルトでは、各MVCCバージョン（整合性スナップショット）は10分間保持されます。読み取りに10分以上かかるトランザクションは、エラーGC life time is shorter than transaction durationを受け取ります。

読み取り時間を長くする必要がある場合、たとえば、フルバックアップにMydumperを使用している場合（ Mydumperは一貫性のあるスナップショットをバックアップします）、TiDBのmysql.tidbテーブルの値tikv_gc_life_timeを調整して、MVCCバージョンの保持時間を増やすことができます。 tikv_gc_life_timeはグローバルかつ即座に有効になることに注意してください。値を大きくすると、既存のすべてのスナップショットの寿命が長くなり、値を小さくすると、すべてのスナップショットの寿命がすぐに短くなります。 MVCCバージョンが多すぎると、TiKVの処理効率に影響します。したがって、 Mydumperを使用して完全バックアップを実行した後、 tikv_gc_life_timeを以前の設定に戻す必要があります。

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

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

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 。 max_execution_timeは現在、 SELECTのステートメントだけでなく、すべてのタイプのステートメントに対して有効です。単位はmsですが、実際の精度はミリ秒レベルではなく100msレベルです。

JDBCクエリタイムアウト

MySQL JDBCのsetQueryTimeout()のクエリタイムアウト設定は、TiDBでは機能しません。これは、クライアントがタイムアウトを検出すると、データベースにKILLコマンドを送信するためです。ただし、tidb-serverは負荷分散されており、間違ったtidb-serverでの接続の終了を回避するために、この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実行のタイムアウトを制御します。デフォルトの値は0です。これにより、接続が無限にビジーになります。つまり、SQLステートメントが無限に長時間実行されます。

ただし、実際の実稼働環境では、アイドル状態の接続と無期限に実行されるSQLステートメントは、データベースとアプリケーションの両方に悪影響を及ぼします。アプリケーションの接続文字列でこれらの2つのセッションレベル変数を構成することにより、アイドル状態の接続やSQLステートメントの無期限の実行を回避できます。たとえば、次のように設定します。

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