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 分)