GC の概要

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

GCプロセス

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

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

  1. ロックを解決します。このステップでは、TiDB はすべてのリージョンのセーフ ポイントの前のロックをスキャンし、これらのロックをクリアします。
  2. 範囲を削除します。この手順では、 DROP TABLE / DROP INDEX操作から生成された範囲全体の古いデータがすぐにクリアされます。
  3. 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 つの方法のいずれかで実装されます。

  • 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 モードに代わるものです。

このページは役に立ちましたか?

Playground
登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。
製品
TiDB Dedicated
TiDB Serverless
TiDB
価格
PoC お問い合わせ
エコシステム
TiKV
TiFlash
OSS Insight
© 2024 PingCAP. All Rights Reserved.
Privacy Policy.