投票配置
编辑投票配置编辑
每个 Elasticsearch 集群都有一个*投票配置*，它是一组可成为主节点的节点，在做出诸如选举新的主节点或提交新的集群状态等决策时，会统计它们的响应。只有在投票配置中超过一半的节点（即多数节点）做出响应后，才会做出决策。
通常，投票配置与集群中当前所有可成为主节点的节点的集合相同。但是，在某些情况下，它们可能会有所不同。
为了确保集群保持可用，您不得同时停止投票配置中一半或更多节点。只要超过一半的投票节点可用，集群就可以正常工作。这意味着，如果有三个或四个可成为主节点的节点，则集群可以容忍其中一个节点不可用。如果只有两个或更少的可成为主节点的节点，则它们必须全部保持可用。
如果您同时停止投票配置中一半或更多节点，则集群将不可用，直到您重新上线足够多的节点以再次形成仲裁。当集群不可用时，任何剩余的节点将在其日志中报告它们无法发现或选举主节点。有关更多信息，请参阅发现故障排除。
在节点加入或离开集群后，Elasticsearch 会通过自动对投票配置进行相应的更改来做出反应，以确保集群尽可能具有弹性。在从集群中删除更多节点之前，请务必等待此调整完成。有关更多信息，请参阅在集群中添加和删除节点。
当前投票配置存储在集群状态中，因此您可以按如下方式检查其当前内容
resp = client.cluster.state(
filter_path="metadata.cluster_coordination.last_committed_config",
)
print(resp)
response = client.cluster.state( filter_path: 'metadata.cluster_coordination.last_committed_config' ) puts response
GET /_cluster/state?filter_path=metadata.cluster_coordination.last_committed_config
当前投票配置不一定与集群中所有可用的可成为主节点的节点的集合相同。更改投票配置涉及进行投票，因此随着节点加入或离开集群，调整配置需要一些时间。此外，在某些情况下，最具弹性的配置包括不可用节点或不包括某些可用节点。在这些情况下，投票配置与集群中可用的可成为主节点的节点的集合不同。
较大的投票配置通常更具弹性，因此 Elasticsearch 通常更愿意在可成为主节点的节点加入集群后将它们添加到投票配置中。类似地，如果投票配置中的节点离开集群，并且集群中还有另一个不在投票配置中的可成为主节点的节点，则最好交换这两个节点。因此，投票配置的大小保持不变，但其弹性会增加。
在节点离开集群后自动将其从投票配置中删除并不那么简单。不同的策略有不同的优缺点，因此正确的选择取决于集群的使用方式。您可以使用cluster.auto_shrink_voting_configuration 设置来控制投票配置是否自动缩减。
如果cluster.auto_shrink_voting_configuration 设置为true（这是默认值和建议值），并且集群中至少有三个可成为主节点的节点，则只要除一个可成为主节点的节点外，所有节点都正常，Elasticsearch 就可以继续处理集群状态更新。
在某些情况下，Elasticsearch 可能容忍多个节点的丢失，但这在所有故障序列下都不能保证。如果cluster.auto_shrink_voting_configuration 设置为false，则必须手动从投票配置中删除已离开的节点。使用投票排除 API 来实现所需的弹性级别。
无论如何配置，Elasticsearch 都不会遭受“https://en.wikipedia.org/wiki/Split-brain_(computing)[脑裂]”不一致的困扰。cluster.auto_shrink_voting_configuration 设置仅影响其在某些节点发生故障时的可用性，以及在节点加入和离开集群时必须执行的管理任务。
偶数个可成为主节点的节点编辑
集群中通常应该有奇数个可成为主节点的节点。如果存在偶数个，Elasticsearch 会将其中一个排除在投票配置之外，以确保其大小为奇数。这种省略不会降低集群的容错能力。事实上，它略微提高了容错能力：如果集群遭受网络分区，将其分成两个大小相等的部分，则其中一部分将包含投票配置的多数，并且能够继续运行。如果统计来自可成为主节点的节点的所有投票，则任何一方都不会包含严格多数的节点，因此集群将无法取得任何进展。
例如，如果集群中有四个可成为主节点的节点，并且投票配置包含所有这些节点，则任何基于仲裁的决策都需要至少三个节点的投票。这种情况意味着集群只能容忍单个可成为主节点的节点的丢失。如果将此集群分成两个相等的部分，则任何一部分都不会包含三个可成为主节点的节点，并且集群将无法取得任何进展。但是，如果投票配置仅包含四个可成为主节点的节点中的三个，则集群仍然只能完全容忍一个节点的丢失，但基于仲裁的决策需要三个投票节点中的两个的投票。如果发生平均分配，则其中一部分将包含三个投票节点中的两个，以便该部分保持可用。
设置初始投票配置编辑
当一个全新的集群第一次启动时，它必须选举它的第一个主节点。为了进行这次选举，它需要知道应该统计其投票的可成为主节点的节点集。此初始投票配置称为*引导配置*，并在集群引导过程中设置。
引导配置准确标识哪些节点应该在第一次选举中投票非常重要。为每个节点配置对集群中应该有多少个节点的预期是不够的。同样重要的是要注意，引导配置必须来自集群外部：集群没有安全的方法可以自行正确确定引导配置。
如果引导配置设置不正确，则在启动全新的集群时，可能会意外形成两个独立的集群，而不是一个。这种情况可能会导致数据丢失：您可能会在注意到任何错误之前就开始使用这两个集群，并且以后不可能将它们合并在一起。
为了说明为每个节点配置预期集群大小的问题，假设启动一个三节点集群，其中每个节点都知道它将成为三节点集群的一部分。三个节点的多数是两个，因此通常前两个发现彼此的节点形成一个集群，而第三个节点在短时间后加入它们。但是，假设错误地启动了四个节点而不是三个。在这种情况下，有足够的节点形成两个独立的集群。当然，如果每个节点都是手动启动的，那么不太可能启动太多节点。但是，如果您使用的是自动编排器，则很有可能进入这种情况，尤其是在编排器无法抵御网络分区等故障时。
只有在整个集群第一次启动时才需要初始仲裁。加入已建立集群的新节点可以安全地从当选的主节点获取所需的所有信息。以前是集群一部分的节点将在重新启动时将所需的所有信息存储到磁盘。