发现与集群形成

发现是集群形成模块查找其他节点以形成集群的过程。当您启动一个Elasticsearch节点或当一个节点认为主节点失败时，此过程会运行，并持续直到找到主节点或选举出一个新的主节点。

这个过程从来自一个或多个种子主机提供者的种子地址列表开始，以及任何已知的集群中最后一个主节点地址。该过程分为两个阶段：首先，每个节点通过连接到每个地址并尝试识别其连接到的节点并验证其是否为主节点来探测种子地址。其次，如果成功，它将与远程节点共享其所有已知的主节点对等点列表，远程节点依次响应其对等点。然后，节点探测它刚刚发现的所有新节点，请求它们的对等点，依此类推。

如果节点不是主节点候选者，那么它会继续这个发现过程，直到发现一个已选出的主节点。如果没有发现已选出的主节点，那么节点将在默认时间为1s的discovery.find_peers_interval后重试。

如果节点是主节点候选者，那么它会继续这个发现过程，直到它发现一个已选出的主节点，或者它发现了足够多的无主主节点候选者来完成选举。如果这两者都没有在足够快的时间内发生，那么节点将在默认设置为1s的discovery.find_peers_interval后重试。

一旦主节点被选举出来，它通常会继续担任选举出的主节点，直到它被故意停止。如果故障检测判定集群存在故障，它也可能停止作为主节点。当一个节点停止担任选举出的主节点时，它会重新开始发现过程。

请参阅发现问题排查以解决发现过程中的问题。

discovery.seed_hosts:
   - 192.168.1.10:9300
   - 192.168.1.11 
   - seeds.mydomain.com 

discovery.seed_providers: file

10.10.10.5
10.10.10.6:9305
10.10.10.5:10005
# an IPv6 address
[2001:0db8:85a3:0000:0000:8a2e:0370:7334]:9301

选举主节点和更改集群状态是主节点候选节点必须共同完成的两项基本任务。即使某些节点发生故障，这些活动也必须稳健地进行。Elasticsearch通过考虑每个动作在接收到来自法定人数的响应后即视为成功，从而实现了这种稳健性。法定人数是集群中主节点候选节点的一个子集。仅要求部分节点响应的优势在于，这意味着即使部分节点发生故障，集群仍可以继续运行。法定人数经过精心选择，以确保集群不会出现“脑裂”场景，即集群被分成两部分，每部分可能做出与另一部分不一致的决策。

Elasticsearch 允许您向正在运行的集群中添加和移除有资格成为主节点的节点。在许多情况下，您只需根据需要启动或停止节点即可。有关更多信息，请参阅在您的集群中添加和移除节点。

当节点被添加或移除时，Elasticsearch通过更新集群的投票配置来维持最佳的容错水平，投票配置是那些在做出决策（如选举新主节点或提交新的集群状态）时，其响应会被计数的主节点候选节点集合。只有在投票配置中超过半数的节点响应后，才会做出决策。通常，投票配置与当前集群中所有主节点候选节点的集合相同。然而，在某些情况下，它们可能会有所不同。

在主节点加入或离开集群后，被选中的主节点可能会发出一个集群状态更新，以调整投票配置以匹配，这可能需要一点时间才能完成。在从集群中移除更多节点之前，等待此调整完成非常重要。有关更多信息，请参阅移除主节点。

Elasticsearch 使用选举过程来就选举的主节点达成一致，无论是在启动时还是在现有选举的主节点失败时。任何有资格成为主节点的节点都可以启动选举，通常第一次进行的选举将会成功。选举通常只有在两个节点几乎同时启动它们的选举时才会失败，因此每个节点上的选举都是随机安排的，以减少这种情况发生的概率。节点将重试选举，直到选出主节点，失败时会退避，因此最终选举将会成功（具有任意高的概率）。主节点选举的调度由 主选举设置 控制。

许多集群维护任务涉及临时关闭一个或多个节点，然后重新启动它们。默认情况下，如果其中一个主节点被下线，例如在滚动升级期间，Elasticsearch可以保持可用。此外，如果多个节点被停止然后重新启动，它将自动恢复，例如在全集群重启期间。在这些情况下，无需使用此处描述的API采取进一步行动，因为主节点集没有永久性变化。

每个Elasticsearch集群都有一个投票配置，这是在做出诸如选举新主节点或提交新集群状态等决策时，其响应被计数的主节点的集合。只有在投票配置中的大多数（超过一半）节点响应后，才会做出决策。

通常，投票配置与当前集群中所有符合主节点资格的节点集合相同。然而，在某些情况下，它们可能会有所不同。

当一个节点加入或离开集群后，Elasticsearch 会自动对投票配置进行相应的更改，以确保集群尽可能具有弹性。在从集群中移除更多节点之前，等待此调整完成非常重要。更多信息，请参阅 在集群中添加和移除节点。

当前的投票配置存储在集群状态中，因此您可以按如下方式检查其当前内容：

GET /_cluster/state?filter_path=metadata.cluster_coordination.last_committed_config

较大的投票配置通常更具弹性，因此Elasticsearch通常倾向于在它们加入集群后将符合主节点资格的节点添加到投票配置中。同样，如果投票配置中的节点离开集群，并且集群中还有另一个不在投票配置中的符合主节点资格的节点，那么最好将这两个节点交换。因此，投票配置的大小保持不变，但其弹性增加。

在节点离开集群后，自动从投票配置中移除节点并不是那么简单。不同的策略有不同的优缺点，因此正确的选择取决于集群的使用方式。您可以通过使用cluster.auto_shrink_voting_configuration设置来控制投票配置是否自动收缩。

在某些情况下，Elasticsearch 可能会容忍多个节点的丢失，但这并不能保证在所有故障序列下都能实现。如果 cluster.auto_shrink_voting_configuration 设置为 false，您必须手动从投票配置中移除已离开的节点。使用 投票配置排除 API 来实现所需的弹性级别。

无论配置如何，Elasticsearch都不会遭受“https://en.wikipedia.org/wiki/Split-brain_(computing)[脑裂]”不一致的问题。 cluster.auto_shrink_voting_configuration设置仅影响其在某些节点发生故障时的可用性，以及在节点加入和离开集群时必须执行的管理任务。

在一个集群中，通常应该有奇数个主节点候选节点。如果存在偶数个，Elasticsearch会将其中的一个排除在投票配置之外，以确保投票配置的大小为奇数。这种排除并不会降低集群的容错能力。实际上，它稍微提高了容错能力：如果集群遭受网络分区，将其分成两个大小相等的部分，那么其中一个部分将包含投票配置中的大多数，并且能够继续运行。如果所有主节点候选节点的投票都被计算在内，那么双方都不会包含严格多数的节点，因此集群将无法取得任何进展。

例如，如果集群中有四个符合主节点资格的节点，并且投票配置包含所有这些节点，那么任何基于法定人数的决策都需要至少三个节点的投票。这种情况意味着集群只能容忍丢失一个符合主节点资格的节点。如果这个集群被分成两个相等的部分，两个部分都不会包含三个符合主节点资格的节点，集群将无法进行任何进展。然而，如果投票配置只包含四个符合主节点资格节点中的三个，集群仍然只能完全容忍丢失一个节点，但基于法定人数的决策需要两个投票节点的投票。在出现均分的情况下，一半将包含三个投票节点中的两个，因此这一半将保持可用。

当一个全新的集群首次启动时，它必须选举其第一个主节点。为了进行这次选举，它需要知道一组有资格成为主节点的节点，这些节点的投票应该被计入。这个初始的投票配置被称为引导配置，并在集群引导过程中设置。

引导配置必须准确识别哪些节点应在第一次选举中投票。仅仅配置每个节点对集群中应有多少节点的期望是不够的。还需要注意的是，引导配置必须来自集群外部：集群自身无法安全地确定正确的引导配置。

如果引导配置没有正确设置，当你启动一个全新的集群时，可能会意外形成两个独立的集群，而不是一个。这种情况可能导致数据丢失：你可能会在注意到出现问题之前开始使用这两个集群，而之后无法将它们合并在一起。

初始法定人数仅在集群首次启动时需要。新节点加入已建立的集群可以安全地从选举出的主节点获取所需的所有信息。曾经是集群一部分的节点在重启时会将所需的所有信息存储到磁盘。

首次启动Elasticsearch集群时，需要在集群中的一个或多个主节点候选节点上显式定义初始的主节点候选节点集合。这被称为集群引导。这仅在集群首次启动时需要。新启动的节点加入正在运行的集群时，会从集群的选定主节点获取此信息。

初始的主节点集合在 cluster.initial_master_nodes 设置中定义。这应该设置为一个包含每个主节点的一个以下项目的列表：

不要在不符合主节点资格的节点上设置cluster.initial_master_nodes。

创建新集群的最简单方法是从您的一个符合主节点资格的节点中选择一个，该节点将引导自身成为一个单节点集群，然后所有其他节点将加入该集群。这种简单的方法在其他符合主节点资格的节点加入集群之前不具备容错能力。例如，如果您有一个符合主节点资格的节点，其节点名称为master-a，则按如下方式配置它（从所有其他节点的配置中省略cluster.initial_master_nodes）：

cluster.initial_master_nodes: master-a

对于容错集群引导，使用所有符合主节点条件的节点。 例如，如果您的集群有3个符合主节点条件的节点，其节点名称分别为master-a、master-b和master-c，则将它们全部配置如下：

cluster.initial_master_nodes:
  - master-a
  - master-b
  - master-c

[master-a.example.com] master not discovered yet, this node has
not previously joined a bootstrapped (v7+) cluster, and this
node must discover master-eligible nodes [master-a, master-b] to
bootstrap a cluster: have discovered [{master-b.example.com}{...

当选的主节点是集群中唯一可以对集群状态进行更改的节点。当选的主节点一次处理一批集群状态更新，计算所需的更改并将更新后的集群状态发布到集群中的所有其他节点。每次发布都始于当选的主节点将更新后的集群状态广播到集群中的所有节点。每个节点都会响应一个确认，但不会立即应用新接收到的状态。一旦当选的主节点从足够多的有资格成为主节点的节点收集到确认，新的集群状态就被称为已提交，主节点会广播另一条消息，指示节点应用现在已提交的状态。每个节点接收到此消息，应用更新后的状态，然后向主节点发送第二个确认。

当选的主节点允许有限的时间将每个集群状态更新完全发布到所有节点。它由cluster.publish.timeout设置定义，默认值为30s，从发布开始时计算。如果在新的集群状态提交之前达到此时间，则集群状态更改将被拒绝，并且当选的主节点认为自身已失败。它会下台并开始尝试选举新的主节点。

如果新的集群状态在cluster.publish.timeout超时之前被提交，选定的主节点认为更改已成功。它会等待超时结束或直到它收到每个节点已应用更新状态的确认，然后开始处理和发布下一个集群状态更新。如果未收到某些确认（即某些节点尚未确认已应用当前更新），这些节点被称为滞后，因为它们的集群状态已落后于选定主节点的最新状态。选定的主节点会等待这些滞后的节点赶上一段时间，cluster.follower_lag.timeout，默认为90s。如果在此时间内节点仍未成功应用集群状态更新，则认为该节点已失败，选定的主节点会将其从集群中移除。

集群状态更新通常以与前一个集群状态的差异形式发布，这减少了发布集群状态更新所需的时间和网络带宽。例如，当仅更新集群状态中部分索引的映射时，只需将这些索引的更新发布到集群中的节点，只要这些节点具有前一个集群状态。如果某个节点缺少前一个集群状态，例如在重新加入集群时，选举出的主节点将向该节点发布完整的集群状态，以便它能够接收未来的更新作为差异。

集群状态更新的性能特征是每个符合主节点资格的节点的存储速度的函数，以及集群中所有节点之间的网络互连的可靠性和延迟。因此，您必须确保集群中的节点可用的存储和网络足够好，以满足您的性能目标。

当选的主节点定期检查集群中的每个节点，以确保它们仍然连接且健康。集群中的每个节点也定期检查当选主节点的健康状况。这些检查分别被称为跟随者检查和领导者检查。

Elasticsearch允许这些检查偶尔失败或超时而不采取任何行动。它仅在连续多次检查失败后才认为节点有故障。您可以通过cluster.fault_detection.*设置来控制故障检测行为。

如果当选的主节点检测到某个节点已断开连接，则这种情况被视为立即失败。主节点会绕过超时和重试设置值，并尝试将该节点从集群中移除。同样，如果某个节点检测到当选的主节点已断开连接，这种情况也被视为立即失败。该节点会绕过超时和重试设置，并重新启动其发现阶段，以尝试找到或选举新的主节点。

此外，每个节点定期通过向磁盘写入一个小文件然后再次删除它来验证其数据路径的健康状况。如果一个节点发现其数据路径不健康，那么它将被从集群中移除，直到数据路径恢复。您可以使用monitor.fs.health设置来控制此行为。

当选的主节点 如果在合理的时间内无法应用更新的集群状态，也会将节点从集群中移除。超时默认从集群状态更新的开始时间起2分钟。有关更详细的描述，请参阅 发布集群状态。