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。

?

轉載于:https://www.cnblogs.com/kelvin19840813/p/10576436.html

總結

以上是生活随笔為你收集整理的使用IST重新加入节点(5.7.20)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。