发现和集群形成
发现
发现是集群形成模块找到其他节点以形成集群的过程。当您启动Elasticsearch节点时，或当节点认为主节点出现故障时，此过程将运行，并持续到找到主节点或选择新的主节点为止。
这个过程从一个或多个种子主机提供程序的种子地址列表开始，以及最后已知集群中任何符合主节点的地址。这个过程分两个阶段进行:首先，每个节点通过连接每个地址来探测种子地址，并尝试识别它连接的节点，并验证它是否是主节点。其次，如果成功，它将与远程节点共享其所有已知的符合主节点条件的节点列表，远程节点依次与它的节点进行响应。然后，节点探测它刚刚发现的所有新节点，请求它们的节点列表，等等。
如果该节点不符合主节点条件，则继续此发现过程，直到发现了选定的主节点。如果没有发现所选的主节点，则该节点将在发现后重试。discovery.find_peers_interval，默认值为1s。
如果节点符合主节点条件，则它将继续此发现过程，直到它发现了一个选定的主节点，或者发现了足够多的符合主节点条件的不是主节点来完成选择。如果这两种情况都发生得不够快，则节点将在发现后重试。discovery.find_peers_interval默认为1s。
种子节点提供者
默认情况下，集群形成模块提供两个种子主机提供程序来配置种子节点列表：基于设置和基于文件的种子主机提供程序。种子主机提供程序使用 discovery.seed_providers 设置进行配置，默认为基于设置的主机提供程序。此设置接受不同提供程序的列表，允许您使用多种方法发现集群中的种子主机。
每个种子主机提供者都会生成种子节点的 IP 地址或主机名。如果它返回任何主机名，则使用 DNS 查找将这些主机名解析为 IP 地址。如果主机名解析为多个 IP 地址，则 Elasticsearch 会尝试在所有这些地址上查找种子节点。如果主机提供程序到那时还没有显式地给出节点的TCP端口，它将隐式地使用transport.profiles.default.port或transport.port范围中的第一个端口。并发查找的数量由discovery.seed_resolver.max_concurrent_resolvers 控制，默认为10，每次查找的超时由discovery.seed_resolver.timeout 控制，默认为5s。
基于配置的种子主机提供者
基于配置的种子主机提供者使用节点设置来配置种子节点的地址静态列表。这些地址可以配置成主机名或者IP，主机名最后会被解析成IP地址。
主机列表使用discovery.seed_hosts来配置。例如：
discovery.seed_hosts:
- 192.168.1.10:9300
- 192.168.1.11
- seeds.mydomain.com
基于文件的种子主机提供者
基于文件的种子主机提供程序通过外部文件配置主机列表。Elasticsearch会在这些文件被修改的时候重新加载该文件，以便种子节点列表可以动态更改，而不需要重新启动每个节点
要启用基于文件的发现，请在 elasticsearch.yml 文件中按如下方式配置文件主机提供程序：
discovery.seed_providers: file
然后以下面描述的格式在 $ES_PATH_CONF/unicast_hosts.txt 中创建一个文件。每当对 unicast_hosts.txt 文件进行更改时，Elasticsearch 重新加载改文件并使用该更改后的新的主机列表。
请注意，基于文件的发现插件增加了 elasticsearch.yml 中的单播主机列表：如果 discovery.seed_hosts 中存在有效的种子地址，那么除了 unicast_hosts.txt 中提供的地址之外，Elasticsearch 还会使用这些地址。
unicast_hosts.txt 文件每行包含一个节点条目。每个节点条目由主机（主机名或 IP 地址）和可选的传输端口号组成
例如，这是一个unicast_hosts.txt的示例，该集群有四个节点参与发现，其中一些节点没有在默认端口上运行:
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
允许使用主机名代替 IP 地址，并如上所述由 DNS 解析。 IPv6 地址必须在括号中给出，如果需要，在括号之后加上端口。
基于法定人数的选举
选举主节点和更改集群状态是符合主节点条件的节点必须协同执行的两项基本任务。即使某些节点出现故障，这些活动也能稳健运行，这一点很重要。ElasticSearch通过收到法定人数的响应后，才会认为该项行动是成功的，以此来实现ElasticSearch的健壮性，法定人数是复合主节点条件的节点子集。只需要部分节点响应的优点是，即使集群中的节点故障，也不会影响集选举的进行。法定人数是经过仔细选择的，这样集群就不会出现“分裂大脑”的情况。Elasticsearch 允许您向正在运行的集群添加和删除符合主节点的节点。在许多情况下，您只需根据需要启动或停止节点即可完成此操作。请参阅添加和删除节点。
在添加或删除节点时，Elasticsearch通过更新集群的投票配置来保持最佳容错水平，投票配置是一组符合主节点条件的节点，在做出选择新主节点或提交新集群状态等决策时，将计算这些节点的响应。只有在投票配置中超过一半的节点做出响应后，才会做出决策。通常，投票配置与集群中当前符合主节点的所有节点的集合相同。然而，在某些情况下它们可能是不同的。
要确保集群仍然可用，您不能同时停止投票配置中的一半或更多节点。只要有超过一半的投票节点可用，集群就可以正常工作。这意味着如果有3或4个符合主节点条件的节点，集群可以容忍其中一个不可用。如果有两个或更少的符合主条件的节点，它们必须都保持可用。
在一个节点加入或离开集群后，当选的主节点必须发布一个集群状态更新来调整投票配置，这可能需要很短的时间来完成。在从集群中删除更多节点之前，等待调整完成是很重要的。
主节点的选举
ElasticSearch使用一个选举过程来商定一个主节点。任何符合主节点条件的节点都可以参与主节点的选举，通常情况下，第一次选举都会成功。只有当两个节点同时选举的时候，才会选举失败，所有选举是随机安排在每个节点上的，以减少此类几率的发生。主节点的选举会不断的重试，直到主节点被选举出来，主节点的选举由master election settings来控制。
投票配置
每个Elasticsearch集群都有一个投票配置，这是一组符合主节点条件的节点，当做出诸如选举新主节点或提交新集群状态等决策时，将计算它们的响应。只有在投票配置中的大多数节点(超过一半)响应后，才会做出决策。
通常投票配置与当前集群中所有符合主节点的节点的集合相同。但是，在某些情况下，它们可能会有所不同。
当前投票配置存储在集群状态中，因此您可以按如下方式检查其当前内容：
curl -X GET "localhost:9200/_cluster/state?filter_path=metadata.cluster_coordination.last_committed_config&pretty"
提示：当前的投票配置不一定与集群中所有可用的符合主条件的节点集相同。
较大的投票配置通常更有弹性，因此Elasticsearch通常倾向于在主节点加入集群后将其添加到投票配置中。类似地，如果投票配置中的一个节点离开集群，而集群中有另一个符合主节点条件的节点不在投票配置中，那么最好交换这两个节点。因此，投票配置的大小没有变化，但其弹性增加了。
在节点离开集群后，从投票配置中自动删除节点并不那么简单。不同的策略有不同的优点和缺点，因此正确的选择取决于如何使用集群。您可以通过使用 cluster.auto_shrink_voting_configuration setting.参数来设置来控制投票配置是否自动伸缩。
提示：如果cluster.auto_shrink_voting_configuration设置为true（这是默认值和建议值），并且群集中至少有三个符合主节点条件的节点，则Elasticsearch仍然能够处理群集状态更新，只要其符合主节点条件的节点中只有一个正常。
在某些情况下，Elasticsearch可能会容忍多个节点的丢失，但并非在所有故障序列下都能保证这一点。如果cluster.auto_shrink_voting_configuratio设置为false，则必须手动从投票配置中删除离开的节点。使用voting exclusions API 实现所需的弹性级别。
偶数个符合主节点的节点
在一个集群中，通常应该有奇数个符合主节点的节点。如果有一个偶数，Elasticsearch会将其中一个排除在投票配置之外，以确保其大小为奇数。这个排除不会降低集群的容错能力。
如果集群的网络分区将其划分为两个大小相等的部分，那么其中一个部分将包含大多数投票配置，并能够继续运行。如果从主合格节点的所有选票都被统计，那么任何一方都不会包含严格的大多数节点，因此集群将无法取得任何进展。
例如，如果集群中有四个符合主节点的节点，并且投票配置包含所有这些节点，则任何基于仲裁的决策都需要至少三个节点的投票。这种情况意味着集群只能容忍一个主节点的丢失。如果这个集群被分成相等的两半，那么任何一半都不会包含三个符合主节点的节点，集群将无法取得任何进展。然而，如果投票配置只包含四个主节点中的三个，集群仍然只能完全容忍一个节点的丢失，但基于仲裁的决策需要三个投票节点中的两个投票。在偶数分裂的情况下，一半将包含三个投票节点中的两个，这样一半将保持可用。
设置初始投票配置
当一个全新的集群第一次启动时，它必须选择它的第一个主节点。要进行这次选举，它需要知道符合主节点的节点集合，这些节点的投票应该被计算。这个初始投票配置称为引导配置，是在集群引导过程中设置的。
如果引导配置设置不正确，当您启动一个全新的集群时，您可能会意外地形成两个独立的集群而不是一个。这种情况可能会导致数据丢失：您可能会在发现任何问题之前就开始使用这两个集群，并且以后无法将它们合并在一起。
为了说明将每个节点配置为期望特定集群大小的问题，请想象一下启动一个三节点集群，其中每个节点都知道它将成为一个三节点集群的一部分。三个节点中的大多数节点是两个，因此通常前两个相互发现的节点形成一个集群，第三个节点稍后加入它们。但是，假设四个节点错误地启动，而不是三个节点。在这种情况下，有足够的节点形成两个独立的集群。当然，如果手动启动每个节点，则不太可能启动过多节点。但是，如果您使用的是自动编排器，则肯定有可能出现这种情况——特别是当编排器无法适应网络分区等故障时。
初始仲裁仅在整个集群第一次启动时才需要。加入已建立集群的新节点可以安全地从选定的主节点获得它们需要的所有信息。以前属于集群的节点将在重新启动时将所有需要的信息存储到磁盘上。
引导一个集群
第一次启动Elasticsearch集群时，需要在集群中的一个或多个符合主条件的节点上显式定义初始的主条件节点集。这被称为集群引导。
初始主节点集在 cluster.initial_master_nodes 设置中定义。对于每个符合主节点的节点，这应该设置为包含以下项目之一的列表：
- 节点的节点名。
- 如果未设置node.name，则为节点的主机名
- 如果无法使用节点的node.name，则为节点的传输发布地址的IP地址。这通常是network.host解析到的IP地址，但可以重写
- 如果无法使用节点的node.name并且有多个节点共享一个IP地址，则节点发布地址的IP地址和端口的形式为IP:port。
当启动主节点时，可以在命令行或elasticsearch.yml文件中提供此设置。在集群形成后，就不再需要这个设置了。并且对于新加入的符合主节点的节点以及重启集群都不需要重新配置该配置，请记住，该配置只有在新集群第一次启动的时候才会配置。
因此最好使用至少三个符合主节点的节点进行引导，每个节点都有一个包含所有三个节点的 cluster.initial_master_nodes 设置。在集群中的单个符合主节点的节点上设置 cluster.initial_master_nodes 在技术上就足够了
提示：您必须在每个符合主节点的节点上设置 cluster.initial_master_nodes 值为相同节点列表，以确保在引导期间仅形成一个集群，从而避免数据丢失的风险。
对于具有 3 个符合 master 资格的节点（节点名称为 master-a、master-b 和 master-c）的集群，配置将如下所示：
cluster.initial_master_nodes:
- master-a
- master-b
- master-c
与所有节点设置一样，也可以在用于启动 Elasticsearch 的命令行上指定初始主节点集：
$ bin/elasticsearch -Ecluster.initial_master_nodes=master-a,master-b,master-c
提示：集群中使用的节点名称。initial_master_nodes列表必须与节点的node.name属性完全匹配。默认情况下，节点名设置为机器的主机名，这可能是完全限定的，也可能不是完全限定的，这取决于您的系统配置。如果每个节点名都是完全限定的域名，如master-a.example.com，则必须在集群中使用完全限定的域名。initial_master_nodes列表;相反，如果节点名是裸主机名(没有.example.com后缀)，则必须在集群中使用裸主机名。initial_master_nodes列表。如果您混合使用完全限定主机名和裸主机名，或者node.name和cluster之间存在其他不匹配。初始化master_nodes，那么集群将无法成功形成，您将看到如下日志消息。
选择集群名称
使用cluster.name设置可以创建多个彼此分离的集群。当节点第一次连接时，它们会验证它们的集群名称是否一致，而Elasticsearch只会从所有具有相同集群名称的节点组成集群。集群名称的默认值是elasticsearch，但是建议将其更改为反映集群的逻辑名称。
发布集群状态
主节点是集群中唯一可以更改集群状态的节点。主节点每次处理一批集群状态更新，计算所需的更改并将更新后的集群状态发布给集群中的所有其他节点。每次发布都从主服务器向集群中的所有节点广播更新后的集群状态。每个节点响应一个确认，但还没有应用新接收到的状态。一旦主节点从足够多的符合主节点条件的节点收集到确认信息，就称新的集群状态已提交，并且主节点广播另一条消息，指示节点应用现在提交的状态。每个节点接收到此消息，应用更新后的状态，然后向主节点发送第二次确认。
master允许在有限的时间内将每个集群状态更新完全发布到所有节点。它是由cluster.publish.timeout设置定义的，默认为30s，从发布开始的时间开始度量。如果在提交新的集群状态之前到达了这个时间点，那么集群状态更改将被拒绝，并且主服务器认为自己失败了。它退出并开始尝试选举一个新的主人。
如果在cluster.publish.timeout超时之前提交了新的集群状态，则主节点认为更改已经成功。它等待超时，直到收到集群中的每个节点都应用了更新状态的确认，然后开始处理和发布下一个集群状态更新。如果一些节点还没有收到确认(例如，一些节点还没有确认他们已经应用了当前的更新)，这些节点被称为滞后，因为它们的集群状态已经落后于主节点的最新状态。主节点等待滞后的节点时间再追加段时间，有cluster.follower_lag参数控制，默认值为90。如果某个节点在此时间内仍然没有成功应用集群状态更新，则认为该节点失败，并将其从集群中删除。
集群状态更新通常以不同于上一个集群状态的方式发布，这减少了发布集群状态更新所需的时间和网络带宽。例如，当仅更新集群状态中索引子集的映射时，只需将这些索引的更新发布到集群中的节点。如果一个节点缺少以前的集群状态，例如重新加入集群时，主节点将向该节点发布完整的集群状态。
提示：Elasticsearch是一个基于点对点的系统，其中节点之间直接通信。高吞吐量api(索引、删除、搜索)通常不与主节点交互。主节点的职责是维护全局集群状态，并在节点加入或离开集群时重新分配分片。每次集群状态改变时，新状态就会像上面描述的那样发布到集群中的所有节点。
集群故障检测
选定的主节点定期检查集群中的每个节点，以确保它们仍处于连接状态和健康状态。集群中的每个节点还会定期检查所选主服务器的运行状况。这些检查分别被称为跟随者检查和领导者检查。
Elasticsearch允许这些检查偶尔失败或超时而不采取任何行动。只有在连续多次检查失败后，它才认为节点是故障的。您可以使用cluster.fault_detection.* settings。
但是，如果当选的主服务器检测到某个节点已断开连接，则这种情况将被视为立即故障。主节点会绕过超时和重试设置，并尝试将节点从集群中移除。类似地，如果一个节点检测到所选的主节点已断开连接，这种情况将被视为立即故障。该节点跳过超时和重试设置，并重新启动其发现阶段，以尝试查找或选择新主服务器。
此外，每个节点通过将一个小文件写入磁盘，然后再次删除，定期验证其数据路径是否正常。如果节点发现其数据路径不正常，则会将其从集群中删除，直到数据路径恢复。你可以通过monitor.fs.health settings来控制此行为。
