GC の概要

TiDB は MVCC を使用してトランザクションの同時実行を制御します。データを更新すると、元のデータはすぐに削除されず、バージョンを区別するためのタイムスタンプとともに新しいデータと一緒に保持されます。ガベージコレクション (GC) の目的は、古くなったデータをクリアすることです。

GCプロセス

各 TiDB クラスターには、GC プロセスを制御する GC リーダーとして選択された TiDB インスタンスが含まれています。

GC は TiDB 上で定期的に実行されます。GC ごとに、TiDB はまず「セーフポイント」と呼ばれるタイムスタンプを計算します。次に、セーフポイント以降のすべてのスナップショットがデータの整合性を保持しているという前提で、TiDB は古いデータをクリアします。具体的には、各 GC プロセスには次の 3 つのステップが含まれます。

ロックを解決します。このステップでは、TiDB はすべてのリージョンのセーフポイントの前のロックをスキャンし、これらのロックをクリアします。
範囲を削除します。この手順では、 DROP TABLE / DROP INDEX操作から生成された範囲全体の古いデータがすぐにクリアされます。
GC を実行します。このステップでは、各 TiKV ノードがその上のデータをスキャンし、各キーの不要な古いバージョンを削除します。

デフォルト設定では、GC は 10 分ごとにトリガーされます。各 GC は過去 10 分間のデータを保持するため、デフォルトでは GC の有効期間は 10 分です (安全ポイント = 現在時刻 - GC 有効期間)。1 ラウンドの GC の実行時間が長すぎる場合、このラウンドの GC が完了する前に、次の GC をトリガーする時間になっても次のラウンドの GC は開始されません。また、GC 有効期間を超えた後も長時間トランザクションが適切に実行されるように、安全ポイントは進行中のトランザクションの開始時刻 (start_ts) を超えないようにします。

実装の詳細

ロックを解決する

TiDB トランザクションモデルはGoogle のパーコレーターに基づいて実装されています。これは主に、実用的な最適化がいくつか施された 2 フェーズコミットプロトコルです。第 1 フェーズが終了すると、関連するすべてのキーがロックされます。これらのロックのうち、1 つはプライマリロックで、その他はプライマリロックへのポインターを含むセカンダリロックです。第 2 フェーズでは、プライマリロックを持つキーに書き込みレコードが取得され、そのロックが解除されます。書き込みレコードは、このキーの履歴またはトランザクションロールバックレコード内の書き込みまたは削除操作を示します。プライマリロックを置き換える書き込みレコードのタイプは、対応するトランザクションが正常にコミットされたかどうかを示します。次に、すべてのセカンダリロックが順次置き換えられます。障害などの何らかの理由でこれらのセカンダリロックが保持され、置き換えられない場合でも、セカンダリロックの情報に基づいてプライマリキーを見つけることができ、プライマリキーがコミットされたかどうかに基づいてトランザクション全体がコミットされたかどうかを判断できます。ただし、プライマリキー情報が GC によってクリアされ、このトランザクションにコミットされていないセカンダリロックがある場合、これらのロックをコミットできるかどうかはわかりません。その結果、データの整合性は保証されません。

ロックの解決ステップでは、安全ポイントの前にロックがクリアされます。つまり、ロックの主キーがコミットされている場合は、このロックをコミットする必要があります。そうでない場合は、ロールバックする必要があります。主キーがまだロックされている場合 (コミットもロールバックもされていない場合)、このトランザクションはタイムアウトと見なされ、ロールバックされます。

ロックの解決ステップは、システム変数tidb_gc_scan_lock_modeを使用して構成できる次の 2 つの方法のいずれかで実装されます。

警告

現在、 PHYSICAL (Green GC) は実験的機能です。本番環境での使用は推奨されません。

LEGACY (デフォルト): GC リーダーは、すべてのリージョンに古いロックをスキャンするリクエストを送信し、スキャンされたロックの主キーのステータスを確認し、対応するトランザクションをコミットまたはロールバックするリクエストを送信します。
PHYSICAL : TiDB はRaftレイヤーをバイパスし、各 TiKV ノード上のデータを直接スキャンします。

範囲を削除

DROP TABLE/INDEXなどの操作中に、連続するキーを持つ大量のデータが削除されます。各キーを削除して後で GC を実行すると、storageの再利用の実行効率が低下する可能性があります。このようなシナリオでは、TiDB は実際には各キーを削除しません。代わりに、削除する範囲と削除のタイムスタンプのみを記録します。次に、範囲の削除手順で、タイムスタンプが安全ポイントより前である範囲に対して高速な物理削除を実行します。

GCを実行する

Do GC ステップでは、すべてのキーの古いバージョンがクリアされます。セーフポイント以降のすべてのタイムスタンプに一貫したスナップショットがあることを保証するために、このステップではセーフポイントの前にコミットされたデータを削除しますが、削除ではない限り、セーフポイント前の各キーの最後の書き込みは保持されます。

このステップでは、TiDB はセーフポイントを PD に送信するだけで、GC ラウンド全体が完了します。TiKV はセーフポイントの変更を自動的に検出し、現在のノード上のすべてのリージョンリーダーに対して GC を実行します。同時に、GC リーダーは次の GC ラウンドをトリガーし続けることができます。

注記：
TiDB 5.0 以降、Do GC ステップでは常にDISTRIBUTED gc モードが使用されます。これは、TiDB サーバーが各リージョンに GC 要求を送信することで実装されていた以前のCENTRAL gc モードに代わるものです。