Part 16：Raft论文翻译-《CONSENSUS BRIDGING THEORY AND PRACTICE》（集群成员变更-通过联合共识支持任意的配置变更&系统集成）
4.3 ** Arbitrary confifiguration changes using joint consensus**（集群成员变更-通过联合共识支持任意的配置变更）
本节介绍了一种更复杂的方法来处理集群成员更改，以实现在一次处理中实现任意的成员变更。例如，可以同时将两个服务器添加到一个集群中，或者也可以一次替换一个五个服务器集群中的所有服务器。这是我们最先提出的成员变更的方法，对它的描述只是为了完整性。现在我们知道了更简单的单服务器变更方法，我们建议使用单服务器变更，因为处理任意更改需要额外的复杂性。任意成员变化通常是学术界喜欢讨论的问题，我们不认为在现实系统中需要这样的能力。
（此处先不看这个小节的内容，毕竟Raft也不推荐这样的方法）
4.4 System integration（系统集成）
Raft提供了很对RPC方法来实现集群中成员的变更（单个成员/次）。例如图4.1给出的AddServer和RemoveServer RPC，这些RPC可以被系统管理员调用或者使用脚本的方式使用。
可能需要在集群中服务器失效的时候自动化的调用上述RPC以实现自动的成员加入。然而，这需要在有合理的理由的情况下使用。例如，集群自动删除出现故障的服务器可能是危险的，因为它可能会留下太少的副本以满足预期的持久化属性和容错要求。一种合理的方法是让系统管理员配置所需的集群大小，在此限制下，可用的服务器可以自动替换发生故障的服务器。
当需要多次进行单服务器变更时，最好在删除服务器之前添加服务器。例如，要替换三服务器集群中的服务器，添加一个服务器，然后删除另一个服务器，将允许系统在整个过程中始终处理一个服务器故障。但是，如果在添加另一个服务器之前首先删除了它，系统将暂时无法屏蔽任何故障（因为两个服务器集群需要两个服务器都可用）。
成员变更引发了一种新的集群启动方法。如果没有动态成员身份，每个服务器都有一个静态配置文件。随着动态成员身份更改，不再需要静态配置文件，因为系统通过Raft日志来管理集群的配置；它还可能容易出错（例如，应该使用新服务器初始化哪个配置？）。相反，我们建议在第一次创建集群时，初始化一个服务器的配置log entry作为其日志中的第一个log entry。此配置仅列出了一个服务器；集群中的多数派就是这个服务器自己，因此他可以认为集群配置已经提交。从那时起，其他服务器应该使用空日志进行初始化；并通过集群变更机制加入到集群中并学习集群变更配置。
成员变更还需要客户端的动态方法来找到集群；这将在第6章中讨论。
