使用IST重新加入节点(5.7.20)

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。