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 存続時間)。 GC の 1 ラウンドの実行時間が長すぎると、このラウンドの GC が完了する前に、次の GC をトリガーする時間になっても、次の GC ラウンドは開始されません。さらに、GC ライフタイムを超えた後に長期間のトランザクションが適切に実行されるためには、安全点は進行中のトランザクションの開始時刻 (start_ts) を超えません。

実装の詳細

ロックの解決

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

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

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

警告

現在、 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 モードが使用されます。これは、各リージョンに GC リクエストを送信する TiDB サーバーによって実装されていた以前のCENTRAL gc モードを置き換えます。