IST不是SST用於節點重新加入嗎？我們有解決方案！
鑑於上述痛點，我們將介紹 gcache.freeze_purge_at_seqno Percona XtraDB Cluster 5.7.20。
這可以控制gcache的清除，從而在節點重新加入時保留更多數據以便於IST。
Galera集羣中的所有事務都被分配了唯一的全局序列號（seqno）。使用此seqno跟蹤事件（例如wsrep_last_applied，wsrep_last_committed，wsrep_replicated，wsrep_local_cached_downto等等）。 wsrep_local_cached_downto表示gcache被清除的序列號。假設wsrep_local_cached_downto = N，則gcache具有來自[N，wsrep_replicated]的數據並且已從[1，N）中清除數據。
gcache.freeze_purge_at_seqno 有三個值：
-1（默認值）：無凍結，清除操作正常。
x（在gcache中應該是有效的seqno）：凍結寫入集> = x。選擇x的最佳方法是使用wsrep_last_applied值作爲計劃關閉的節點的指示符。 （wsrep_applied * 0.09。保留額外的10％來欺騙IST的安全間隙啓發式算法。）
now：凍結寫入集的清除> =當前在gcache中的最小seqno。即時凍結gcache-purge。 （如果跟蹤x（上面）很困難，只需使用“now”就可以了。）
在集羣的現有節點上設置它（它將繼續作爲集羣的一部分，並可充當潛在的DONOR）。
此節點繼續保留寫集，從而允許重新啓動節點使用IST重新加入。
（您可以在重新啓動所述重新加入節點時通過wsrep_sst_donor將所述節點作爲首選DONOR提供。）
一旦節點重新加入，請記住將其設置回-1。
這避免了在所述時間線之外佔用捐贈者的空間。
在下一個清除週期中，所有舊的保留寫入集也被釋放（將空間回收回原始空間）。
IST donor選擇
show status like 'wsrep_local_cached_downto';
假設我們有3個節點集羣：N1，N2，N3。
首先，所有3個節點都是同步的（wsrep_last_committed對於所有3個節點都是相同的，假設爲100）。
N3是維護計劃並被取消。
同時，N1和N2處理工作量，從而將它們從100 -> 1100移動。
N1和N2也清除了gcache。假設N1和N2的 wsrep_local_cached_downto 分別爲110和90。
現在N3重新啓動並發現集羣已從100 -> 1100進展，因此它需要來自（101,1100）的write-sets。
它開始尋找潛在的DONOR。
N1可以從（110,1100）服務數據，但請求是（101,1100），所以N1不能作爲DONOR
N2可以從（90,1100）服務數據，並且請求是（101,1100），因此N2可以充當DONOR。
Safety gap及其如何影響DONOR的選擇
到現在爲止還挺好。但N2能否可靠地充當捐贈者？雖然N3正在評估潛在的捐贈者，但如果N2清除更多數據，現在N2上的wsrep_local_cached_downto是105，該怎麼辦？爲了適應這種情況，N3算法增加了安全間隙。
Safety gap =（當前羣集狀態 - 來自羣集的任何現有節點的最低可用seqno）* 0.008
因此，N2範圍被認爲是（90 +（1100-90）* 0.008,1100）=（98,1100）。
現在N2可以作爲捐贈者嗎？是：（98,1100）<（101,1100）
如果N2已經淨化到95然後N3開始尋找潛在的捐贈者怎麼辦？
在這種情況下，N2範圍將是（95 +（1100-95）* 0.008,1100）=（103,1100），從預期的捐贈者清單中排除N2。