tidb叢集gc簡介
GC 相關的配置和執行狀態記錄在mysql.tidb
這張系統表中，可以通過 SQL 語句進行檢測和配置：
mysql> select VARIABLE_NAME, VARIABLE_VALUE from mysql.tidb; +-----------------------+------------------------------------------------------------------------------------------------+ | VARIABLE_NAME| VARIABLE_VALUE| +-----------------------+------------------------------------------------------------------------------------------------+ | bootstrapped| True| | tidb_server_version| 18| | tikv_gc_leader_uuid| 58accebfa7c0004| | tikv_gc_leader_desc| host:ip-172-168-30-5, pid:95472, start at 2018-04-11 13:43:30.73076656 +0800 CST m=+0.068873865 | | tikv_gc_leader_lease| 20180418-11:02:30 +0800 CST| | tikv_gc_run_interval| 10m0s| | tikv_gc_life_time| 10m0s| | tikv_gc_last_run_time | 20180418-10:59:30 +0800 CST| | tikv_gc_safe_point| 20180418-10:58:30 +0800 CST| | tikv_gc_concurrency| 1| +-----------------------+------------------------------------------------------------------------------------------------+ 10 rows in set (0.02 sec)
|
csdnhy-172.168.121.231:3306:csdn_univer17:19:12> SELECT VARIABLE_NAME, VARIABLE_VALUE FROM mysql.tidb; +-----------------------+--------------------------------------------------------------------------------------------------------------------+ | VARIABLE_NAME | VARIABLE_VALUE | +-----------------------+--------------------------------------------------------------------------------------------------------------------+ | bootstrapped | TRUE | | tidb_server_version | 21 | | tikv_gc_leader_uuid | 5974c0788ac0004 | | tikv_gc_leader_desc | HOST:172.168.121.125, pid:14599, START AT 2018-09-13 20:57:20.660383356 +0800 CST m=+21.941155730 | | tikv_gc_leader_lease | 20181006-17:42:20 +0800 CST | | tikv_gc_run_interval | 10m0s | | tikv_gc_life_time | 10h | | tikv_gc_last_run_time | 20181006-15:59:20 +0800 CST | | tikv_gc_safe_point | 20181006-15:49:20 +0800 CST | | tikv_gc_concurrency | 1 | +-----------------------+--------------------------------------------------------------------------------------------------------------------+ 10 ROWS IN SET (0.00 sec) |
|---|
其中，tikv_gc_run_interval
，tikv_gc_life_time
，tikv_gc_concurrency
這三條記錄可以手動配置。其餘帶有 tikv_gc
字首的記錄為當前執行狀態的記錄， TiDB 會自動更新這些記錄，請勿手動修改。
update mysql.tidb set VARIABLE_VALUE = '24h' where VARIABLE_NAME = 'tikv_gc_life_time';
csdnhy-172.168.121.231:3306:csdn_univer17:40:27> update mysql.tidb set variable_value='10h' where variable_name='tikv_gc_run_interval';
Query OK, 1 row affected (0.01 sec)
csdnhy-172.168.121.231:3306:csdn_univer17:45:33>
時長字串的形式是數字後接時間單位的序列，如24h
、2h30m
、2.5h
。可以使用的時間單位包括 "h"、"m"、"s"。
需要注意的是，在資料更新頻繁的場景下如果將tikv_gc_life_time
設定得比較大（如數天甚至數月），可能會有一些潛在的問題：
select count(*) from t tikv_gc_life_time
tikv_gc_concurrency
是執行 GC 的併發數。預設該選項為 1，即單執行緒執行，逐個向每個涉及的 Region 發起請求並等待響應。可以增加該數值以改善效能，最大不能超過 128。
tikv_gc_leader_uuid
，tikv_gc_leader_desc
，tikv_gc_leader_lease
是當前的 GC leader 的資訊。tikv_gc_last_run_time
是上一次執行 GC 的時間。
tikv_gc_safe_point
的含義是，在該時間點以前的版本已經被 GC 清理，並保證該時間點以後的讀取可以正確進行。
實現細節
GC 的實施過程實際上比較複雜。我們要在保證一致性不被破壞的前提下，清除不再使用的資料。具體來說，每次執行 GC，要順序執行三個步驟：
1. Resolve Locks
TiDB 的事務是基於 Google Percolator 模型實現的，事務的提交是一個兩階段提交的過程。第一階段完成時，所有涉及的 key 會加上一個鎖，其中一個鎖會被設定為 Primary，其餘的鎖（Secondary）則會指向 Primary；第二階段會將 Primary 鎖所在的 key 加上一個 Write 記錄，並去除鎖。這裡的 Write 記錄就是歷史上對該 key 進行寫入或刪除，或者該 key 上發生事務回滾的記錄。Primary 鎖被替換為何種 Write 記錄標誌著該事務提交成功與否。接下來，所有 Secondary 鎖也會被依次替換。如果替換這些 Secondary 鎖的執行緒死掉了，鎖就殘留了下來。在 GC 過程中如果遇到了時間戳在 safe point 之前的這樣的鎖，就會根據該事務提交與否，將該鎖也替換成 Write 記錄。
這一步是必須的，因為如果其 Primary 的 Write 記錄被 GC 清除掉了，就再也無法知道該事務是否成功，也就難以保證一致性。
2. Delete Ranges
DeleteRanges 通常在 drop table 這樣的操作之後需要進行，用於刪除可能很大的一個區間。如果 TiKV 的use_delete_range
選項沒有開啟，那麼 TiKV 會把範圍中的 key 逐個刪除。
3. Do GC
這一步把每一個 key 的 safe point 之前的資料和 Write 記錄清除掉。有一個特例是，如果在 safe point 之前的所有Put
型別和 Delete
型別的 Write 記錄中，最後一個記錄是 Put
（即寫入），那麼該記錄（及其對應的資料）不能被直接刪除。否則，時間戳在 safe point 之後、該 key 的下一個版本之前的讀取操作將無法讀取到該資料。