kudu之更改Raft配置的设计

怼烎@ 2021-12-22 09:07 184阅读 0赞

出于可操作性和可用性的原因，我们希望能够动态更改tablet server集群。此功能的使用场景包括：

*  更换故障的tablet server以维持tablet数据的副本数。
 *  给Kudu群扩容。这可能需要重新分配tablet位置，以平衡tablet server的负载。
 *  如果表的一个或多个tablet变成热数据，则增加它们的副本（例如，按照时间划分tablet，使得今天的tablet有更多副本）。

# 范围 #

本文档包含以下主题：

*  在保证一致性的情况下设计和实现成员变更。
 *  向正在运行的tablet配置添加/删除tablet服务器。
 *  将tablet副本从一台tablet server 移动到另一个tablet server
 *  在灾难性故障（大多数节点永久性故障）之后尝试最小化数据丢失的同时恢复可用性。由于在这种情况下可能无法保证或限制可能丢失的数据量，因此我们仅提供高级方法以允许尝试手动修复。

# 成员变更 #

在Kudu，我们根据Diego Ongaro博士论文中的一对一成员变更设更改成员。我们提供了论文中概述的逐一设计的概述，但是该文档主要关注Kudu特定的细节和与Raft的偏差。

## 一对一的成员变更 ##

我们只能原子性地对配置进行一次加法或减法。在此类更改（即更改配置事务）提交或中止之前，不会启动其他任何更改。这为我们提供了安全保障。

## 将新节点添加到集群的过程 ##

此过程由驱动程序执行，该驱动程序可以是客户端程序或主服务器。我们将要添加到集群的节点成为new\_node。

1.  驱动程序使用RPC调用启动new\_node的Tablet Copy进程，从当前leader copy\_source拷贝数据。等到Tablet  
    Copy完成，就这意味着启动Tablet Copy时的所有数据和日志都将复制到new\_node。驱动程序通过轮询new\_node得知Tablet Copy过程已完成。 如果copy\_source node在Tablet Copy完成之前节点崩溃，则复制失败，驱动程序必须从头开始整个过程。如果驱动程序或new\_node崩溃并且tablet从未加入配置，则Master应该最终删除已放弃的tablet副本。
2.  驱动程序调用leader上的AddServer（）RPC调用将new\_node做为PRE\_FOLLOWER添加到配置中。这是一种新的角色类型，没有投票权。将此配置更改复制到集群其他节点（不会更改voting majority）。当leader检测到new\_node在选举超时时间内复制剩余的日志entry时，将会把PRE\_FOLLOWER提升为 FOLLOWER（具有投票权，更改voting majority）。在给定时间内，几个节点可能同时处于PRE\_FOLLOWER模式，但是转换到FOLLOWER仍然遵循一对一规则。如果添加PRE\_FOLLOWER失败（通常由于leader变更或弱一致性）将需要稍后由驱动程序重试。
3.  只要副本收到ConfigChangeRequest，它就会在内存中应用配置更改。
4.  一旦将节点转换为PRE\_FOLLOWER的配置已提交，new\_node，copy\_source之间的ablet Copy 回话就会被关闭。这意味着在日志上释放锚点。由于new\_node已经是配置的成员，能够接收日志更新，它应该从尚未复制的数据开始在领导者上保持一个日志锚点，因此这种重叠是安全的。
5.  最终提交ConfigChangeTransaction并使成员更改持久化。

## 配置更改事务实现细节 ##

当收到指示成员身份更改的配置更改事务时，我们将更改应用为WIP配置更改，而不将其提交到磁盘。ChangeConfigTransaction的共识提交使我们将ConsensusMeta同步到磁盘（Raft依赖于日志持久性，但我们不希望因配置更改条目而阻止日志GC）。

这种方法允许我们在更改配置事务被中止并由新的领导者替换的情况下“回滚”到最后提交的配置成员资格。

## 从群集中删除节点的过程 ##

从群集中删除给定节点（让我们称这个节点为doomed\_node）遵循与添加节点相同的规则。该过程也由“驱动程序”进程运行。以下是详细信息：

1.  驱动程序在配置leader上调用RemoveServer（）RPC，指示要从配置中删除哪个服务器。
2.  如果doomed\_node不是配置leader，则leader使用ConfigChangeTransaction发动成员资格更改，将不包括doomed\_node的配置一致性同步到其他跟随者。
3.  如果doomed\_node是领导者，领导者将配置所有权转移到配置中状态最新的跟随者，并向客户端返回RPC回复  
    STEPPING\_DOWN，这意味着驱动程序应刷新其元数据缓存并稍后再试。

# 在灾难性数据丢失后的恢复可用性 #

在大多数tablet配置永久丢失的情况下，所有耐久性和一致性保证都会丢失。假设配置中至少有一个剩余成员，我们可以通过复制剩余数据来恢复一些数据并重新获得配置可用性。然而，这是非常危险的，并且一旦完成诸如此类的手动过程就无法返回。

步骤：

1.  运行工具以确定最新的剩余副本。
2.  使用Tablet Copy从最新的剩余副本创建其他副本。等待所有节点上的Tablet Copy完成。
3.  使拥有受影响tablet的所有tablet server脱机。
4.  运行工具以重写每个tablet server的ConsensusMetadata文件，以强制更新配置成员资格，以将复制的节点添加为follower。
5.  将受影响的tablet/tablet server重新上线