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