（0.12）elasticsearch分布式集群原理（ES7.9）

前置概念参考：https://www.cnblogs.com/gered/p/14513207.html

【0】较为重要的默认参数

 discovery.find_peers_interval: 1     #集群发现重试间隔，默认1s
 discovery.cluster_formation_warning_timeout  #在记录未形成集群的警告之前，节点尝试形成集群的时间。默认为10s
 cluster.auto_shrink_voting_configuration: #控制投票配置是否自动丢弃离开的节点，只要它仍然至少包含3个节点即可。默认值为true

【0.1】主机发现默认

 discovery.cluster_formation_warning_timeout #设置在记录未形成集群的警告之前，节点尝试形成集群的时间。默认为10s
 discovery.find_peers_interval #设置尝试另一个发现回合之前节点将等待多长时间。默认为1s
 discovery.probe.connect_timeout #设置尝试连接到每个地址时要等待的时间。默认为3s
 discovery.probe.handshake_timeout #设置尝试通过握手识别远程节点时要等待的时间。默认为1s
 discovery.request_peers_timeout #设置节点在再次询问其对等方之后才认为请求失败之前将等待多长时间。默认为3s
 discovery.seed_resolver.timeout/discovery.zen.ping.unicast.hosts.resolve_timeout 
 #指定解析种子节点的地址时等待执行每个DNS查找的时间。默认为5s

【0.2】集群默认

 cluster.auto_shrink_voting_configuration: #投票配置是否自动丢弃离开的节点，只要它仍然至少包含3个节点。默认true
 cluster.election.duration #（静态）设置每次选举允许在节点认为失败之前安排多长时间，并安排重试时间。默认为500ms
 
 #跟随者检查（即 node.master: false 节点）
 cluster.fault_detection.follower_check.interval  #默认一秒检查一次
 cluster.fault_detection.follower_check.timeout   #默认10秒就算超时
 cluster.fault_detection.follower_check.retry_count #默认会重试3次
 
 #领导者检查（即 node.master: true 节点）
 cluster.fault_detection.leader_check.interval #默认一秒检查一次
 cluster.fault_detection.leader_check.timeout  #默认10秒就算超时
 cluster.fault_detection.leader_check.retry_count #默认会重试3次
 cluster.follower_lag.timeout #等待从节点状态更新响应，默认90S超时
 
 cluster.join.timeout #节点发送请求加入集群后，等待多久超时重试，默认60s超时
 cluster.max_voting_config_exclusions #（动态）设置最大限制投票配置排除的数量。默认值为10
 
 #publish
 cluster.publish.info_timeout #置主节点等待多长时间将每个群集状态更新完全发布到所有节点，然后记录一条消息，指示某些节点响应缓慢。默认值为10s。
 cluster.publish.timeout #设置主节点等待每个集群状态更新完全发布到所有节点的时间，默认30s
 
 #cluster

【1】集群原理

【1.0】集群节点角色

节点角色

master eligible node
- 主备节点：管理集群状态，负责index的创建、分片管理、、mapping元数据等
- 机器配置：低cpu\低内存\低磁盘
data node
- 负责数据的存储、搜索和聚合计算
- 机器配置：高cpu\高内存\高磁盘
ingest node
- 负责索引文档预处理及相关数据处理（不常用）
- 机器配置：高cpu/高内存/低磁盘
coordinate node(协调节点)
- 负责接收Client 的请求,将请求分发到合适的节点,最终把结果汇集到一起，每个节点默认都是这个角色
- 扮演loadbance 角色。降低master和node的负载，负责搜索查询结果的聚合和reduce
- 机器配置：高cpu\高内存\低磁盘
marching learning node
- 　　机器学习

【1.1】集群发现

什么是主机资格节点（主节点资格）？

就是 node.master: true 的节点

发现是集群形成模块查找与之形成集群的其他节点的过程。

当您启动Elasticsearch节点或节点认为主节点发生故障时，此过程将运行，并持续到找到主节点或选择新的主节点为止。

这个过程从一个或多个种子节点地址配置信息，以及最后一个已知集群中所有符合主节点资格的节点的地址。

（1）每个节点通过连接到每个地址并尝试识别其所连接的节点并验证其是否符合主节点资格

（2）如果成功，它将与远程节点共享其所有已知的符合主节点资格的对等方的列表，并且远程节点将依次与其对等方进行响应。然后，该节点将探查刚刚发现的所有新节点，请求其对等节点，依此类推。

（3）如果该节点不符合主节点资格，则它将继续此发现过程，直到发现了选定的主节点为止。如果没有发现选定的主节点，那么该节点将在这个参数间隔后重试：discovery.find_peers_interval（默认为1s）

（4）如果该节点是符合主节点资格的节点，则它将继续此发现过程，直到它找到了选举的主节点，或者它已经找到了足够的无主节点资格的节点来完成选举。

如果这两种方法都没有足够快地发生，则该节点将在这个参数间隔后重试：discovery.find_peers_interval（默认为1s）

【1.2】种子节点地址配置（主机提供者）

默认情况下，集群形成模块提供了两个种子主机提供程序来配置种子节点列表：基于设置的和基于文件的种子主机提供程序。 discovery.seed_providers配置节点IP或者主机名等信息，手动配置如下：

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

transport.profiles.default.port 默认为9300-9400递增（如果不设置，第一个启动的实例端口为9300，第二个为9301...以此类推）,手动配置如下：

 transport.port: 9300

要启用基于文件的发现，请file在elasticsearch.yml文件中按如下所示配置主机提供程序：

 discovery.seed_providers: file

然后以$ES_PATH_CONF/unicast_hosts.txt下面描述的格式创建一个文件。每当对unicast_hosts.txt文件进行更改时，Elasticsearch都会选择新的更改，并使用新的主机列表。

请注意，基于文件的发现插件会增加以下内容中的单播主机列表elasticsearch.yml：如果其中包含有效的种子地址，discovery.seed_hosts则Elasticsearch会使用中提供的地址之外的地址unicast_hosts.txt。

该unicast_hosts.txt文件每行包含一个节点条目。每个节点条目均由主机（主机名或IP地址）和可选的传输端口号组成。如果指定了端口号，则必须在主机（在同一行）上以a分隔后立即出现:。

如果未指定端口号，Elasticsearch将隐式使用transport.profiles.default.port，或未设置transport.portiftransport.profiles.default.port所给定的端口范围内的第一个端口。

例如，这是一个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

【1.3】分片机制

每个索引可以被分片，每个主分片都包含索引的数据。
副本分片是主分片的备份，主挂了，备份还是可以访问，这就需要用到集群了。
同一个分片的主与副本是不会放在同一个服务器里的，因为一旦宕机，这个分片就没了。

如下图：左边每个索引主备分片都会分配在三台服务器上的不同节点上面，右图粗方框表示主分片，细节点表示备节点。

【2】仲裁决策

【2.1】保持集群可用性

为确保集群仍然可用，您不得同时停止投票配置中的一半或更多节点。只要有一半以上的投票节点可用，集群仍可以正常工作。

这意味着，如果存在三个或四个主节点合格的节点（如果是偶数节点，则只会有奇数个节点有投票权），则集群可以容忍其中一个节点不可用。

如果有两个或更少的符合主机资格的节点，则它们必须全部保持可用。

【2.2】master node 选举

（1）无论是在启动时还是在现有的选定主节点发生故障时，Elasticsearch都会使用选举过程来协商选定的主节点。任何符合主机资格的节点都可以开始选举，并且通常发生的第一次选举将成功。

（2）通常，只有在两个节点都碰巧同时开始选举时，选举通常才会失败，因此在每个节点上随机安排选举以降低发生这种选举的可能性。节点将重试选举，直到选举出主节点为止，然后在失败时退避，这样最终选举将成功（概率很高）。主选举的时间安排由主选举设置.

【3】投票配置

【3.0】查看当前可投票节点

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

可以通过：

　　GET /_cluster/state

来查看，上面图中的UUID 对应的具体是哪个节点

【3.1】可用性

必须要有一半以上的投票节点可用（这样才可以仲裁），集群才能正常运行；

如果有n个节点，投票节点有n 或 n-1个，仲裁选举需要 n/2+1 or (n-1)/2+1，比如：

即如果 n=3，则投票节点是 3 个
如果 n=4，则 es 会将 n 变成 n-1 来达到投票节点为奇数的目的

为什么要把偶数投票节点变成奇数？

案例：

如果是4个节点并且都是投票节点，那么仲裁需要 n/2+1=3 个节点；
那么当集群网络断开，变成了2个2个节点的网络，由于至少需要3个节点来仲裁，所以集群变得不可用
所以，如果是把投票节点变成奇数，比如这里的4个变成3个，那么仲裁就只需要 3/2+1=2 个节点即可；即使集群变成2个2个节点的网络，有一方也必定有2个可投票节点，这样就能保证至少2个节点的群集可以存活；

【3.2】自动投票配置

在节点离开集群后自动从投票配置中删除节点并不是那么简单。

如果cluster.auto_shrink_voting_configuration将设置为true（这是默认值和建议值），并且集群中至少有三个主节点，那么，除其中一个主节点中的所有节点都健康以外，Elasticsearch仍具有处理集群状态更新的能力。

【3.3】集群的初始仲裁

（1）如果引导程序配置没有正确设置，则在启动全新群集时，可能会意外地形成两个单独的群集，而不是一个群集。

这种情况可能会导致数据丢失：您可能会在发现任何错误之前就开始使用两个群集，以后再将它们合并在一起是不可能的。

为了说明将每个节点配置为期望某个特定群集大小的问题，可以想象启动一个三节点群集，其中每个节点都知道它将成为三节点群集的一部分。三个节点中的大多数是两个，因此通常前两个节点可以发现彼此，形成一个集群，而第三个节点不久之后就将它们加入。

但是，假设错误地启动了四个节点，而不是三个。在这种情况下，有足够的节点来形成两个单独的群集。当然，如果每个节点都是手动启动的，那么启动太多节点的可能性就很小。但是，如果您使用的是自动协调器，则肯定会出现这种情况，尤其是在协调器无法应对网络分区等故障的情况下。

（2）如何避免集群初始化分裂成多个集群？

 #初始化一个新的集群时需要此配置来选举master；建议3个节点，或更多奇数节点，会根据discovery.seed_hosts 参数判断需要多少个节点才能初始化选举
 cluster.initial_master_nodes: ["node-1", "node-2", "node-3"] 
 
 discovery.zen.minimum_master_nodes: 2  #集群主节点故障时，最少要有N个节点投票才能选举出主节点，这个参数其实已经可以舍弃

【4】引导集群（集群的初始仲裁）

【4.1】引导过程

主资格节点的初始集合在 cluster.initial_master_nodes 环境。对于每个符合主机资格的节点，应将其设置为包含以下项目之一的列表：

node.name未设置节点的主机名，因为node.name默认为节点的主机名。您必须使用标准主机名或裸机主机名
节点的IP地址发布地址，如果不可能使用node.name该节点的。这通常是IP地址network.host 解决但这可以被覆盖.
节点发布地址的IP地址和端口，格式为IP:PORT，如果无法使用node.name该节点的，并且有多个节点共享一个IP地址。
也可以启动脚本上添加： bin/elasticsearch -Ecluster.initial_master_nodes=master-a,master-b,master-c

从技术上讲cluster.initial_master_nodes，在集群中的一个符合主机要求的节点上进行设置就足够了，仅提及设置值中的单个节点即可，但这在集群完全形成之前没有提供容错功能。因此，最好使用至少三个符合主机资格的节点进行引导，每个节点的cluster.initial_master_nodes设置都包含所有三个节点。

您必须在设置 cluster.initial_master_nodes 了该节点的每个节点上都设置相同的节点列表，以确保在引导过程中仅形成一个集群，从而避免数据丢失的风险。

对于具有3主资格的节点（与群集节点名称 master-a，master-b和master-c）的结构将如下所示：

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

cluster.initial_master_nodes列表中使用的节点名称必须与node.name节点的属性完全匹配。默认情况下，节点名称设置为 计算机 的主机名，该主机名可能完全限定也可能不完全限定，具体取决于您的系统配置。

【5】发布集群状态

【5.1】集群状态修改流程

（1）主节一次性处理一批次的集群状态更新=》更新的集群状态发布（以主节点开始），广播到该集群所有节点

（2）每个节点收到信息（只是收到但还未应用）后返回确认响应=》主节点收到N/2+1 个确认后，就对外响应集群状态已更新

（3）主机广播另外一条消息，指示节点应用已提交的状态=》每个节点接收此消息，应用更新后的状态（现在才应用），然后把第二个确认响应发回给主节点

cluster.publish.info_timeout #置主节点等待多长时间将每个群集状态更新完全发布到所有节点，然后记录一条消息，指示某些节点响应缓慢。默认值为10s。
cluster.publish.timeout #设置主节点等待每个集群状态更新完全发布到所有节点的时间，默认30s

【5.2】相关内幕

（1）【5.1】中这整个过程的（1）（2）的全部，（3）的第一部分

用时有一个阈值，由参数 cluster.publish.timeout 设置定义，从发布开始算起，默认为30s；如果在提交新群集状态之前已经到达、超过这个时间，则群集状态更改将被拒绝，并且主节点会认为是自己出了故障；它会让集群发起新的投票选举，选出新的主节点；

（2）【5.1】中整个过程的（3）的第二部分

如果新的集群状态在 cluster.publish.timeout 超时之前已经提交，则主节点认为更改已经成功；它会等待，直到超时或收到群集每个节点已应用更新状态的确认响应，然后开始处理并发布下一个集群状态的更新；如果某些节点还没有收到确认更新的返回响应，则这些节点被称为滞后，因为他们的集群状态已落后在主节点的最新状态之后；主节点会等待滞后节点的追赶 cluster.follower_lag.timeout ，默认为 90s ；如果在这个时间段之内还没有追上来，则群集认为该节点已失败并把它提出集群；

（3）集群状态的发布形式

集群状态通常作为以前集群转改的差异发布，从而减少了发布群集状态更新所需的时间和网络带宽。例如，当仅更新集群状态中索引的子集的映射时，只要那些索引的更新需要发布到集群中的节点，只要那些节点具有先前的集群状态即可。如果某个节点缺少先前的群集状态（例如，在重新加入群集时），则主服务器将向该节点发布完整的群集状态，以便它可以接收将来的差异更新。

Elasticsearch是一个基于对等系统，其中节点之间直接相互通信。高吞吐量API（索引，删除，搜索）通常不会与主节点进行交互。主节点的职责是维护全局群集状态，并在节点加入或离开群集时重新分配分片。每次更改集群状态时，都会如上所述将新状态发布到集群中的所有节点。

【6】集群故障检查

当选的主节点周期性地检查每个集群中的节点，以确保它们仍连接和健康。集群中的每个节点还定期检查当选主人的健康。这些检查分别称为跟随者检查和领导者检查。

跟随者检查：其实就是非主节点

cluster.fault_detection.follower_check.interval  #默认一秒检查一次
cluster.fault_detection.follower_check.timeout   #默认10秒就算超时
cluster.fault_detection.follower_check.retry_count #默认会重试3次

领导者检查：其实就是主节点

cluster.fault_detection.leader_check.interval #默认一秒检查一次
cluster.fault_detection.leader_check.timeout  #默认10秒就算超时
cluster.fault_detection.leader_check.retry_count #默认会重试3次
cluster.follower_lag.timeout #等待从节点状态更新响应，默认90S超时

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

此外，每个节点都会通过将一个小文件写入磁盘，然后再次将其删除来定期验证其数据路径是否正常。如果节点发现其数据路径不正常，则将其从群集中删除，直到数据路径恢复为止。您可以使用monitor.fs.health设置来控制此行为。

【7】在集群中添加、删除节点

【7.1】节点的增删

（1）如果是本地计算机

您可以在本地计算机上运行多个节点，以试验多个节点的Elasticsearch集群的行为。要将节点添加到本地计算机上运行的集群中，请执行以下操作：

设置一个新的Elasticsearch实例。
使用中的cluster.name设置指定集群的名称elasticsearch.yml。例如，要将节点添加到logging-prod集群，请将行添加cluster.name: "logging-prod"到elasticsearch.yml。
启动Elasticsearch。节点会自动发现并加入指定的集群。

（2）如果是加入多台机器组成的现有集群

要将节点添加到在多台计算机上运行的集群中，必须设置：

　　elasticsearch.yml =》配置 cluster.name与现存的一样，且discovery.seed_hosts（必须是现有集群中的节点信息，建议完全一样，注意，host中的地址应在同一集群）以便新节点可以发现其其

有关发现和分片分配的更多信息，请参阅发现和集群形成以及集群级分片分配和路由设置。

总结：

　　也就是说，改一下实例配置文件中的 Clustername 参数、discovery.seed_hosts 参数即可；当然也可以设置一下jvm大小之类的

【7.2】主机资格节点(Master-eligible node，即node.master: true)

总结：

　　（1）如果要增加主机资格节点：

　　　　　　直接加就好了

　　（2）如果要删除主机资格节点：

　　　　　　注意不能一次性删太多，最好一个一个节点删；

　　　　　　注意投票节点的变化，等待

（1）符合主机资格的节点

　　在添加或删除节点时，Elasticsearch通过自动更新集群的表决配置来维持最佳的容错水平，该表决配置是符合主机资格的节点的集合，在做出决定（例如选择新的主机或提交新的集群状态）时，对它们的响应进行计数。

　　建议在群集中拥有少量固定数量的符合主机资格的节点，并通过仅添加和删除符合主机资格的节点来扩大和缩小群集。但是，在某些情况下，可能需要向群集中添加某些符合主机要求的节点或从群集中删除某些符合主机要求的节点。

（2）添加符合资格的主节点

　　如果要向集群添加一些节点，只需配置新节点以找到现有集群并启动它们即可。如果合适，Elasticsearch会将新节点添加到投票配置中。

　　在主节点选举期间或加入现有的已形成集群时，节点会向主节点发送加入请求，以便将其正式添加到集群中。

　　您可以使用该cluster.join.timeout设置来配置节点在发送加入集群的请求后等待多长时间。其默认值为30s。请参阅发现和群集形成设置。

（3）删除符合主机资格的节点

在删除符合主机资格的节点时，重要的是不要同时删除太多节点。例如，如果当前有七个符合主控条件的节点，而您希望将其减少到三个，则不可能简单地一次停止四个节点：这样做将只剩下三个节点，这不到一半投票配置，这意味着群集无法采取任何进一步的措施。

更准确地说，如果您同时关闭一半或更多的符合主机资格的节点，则该群集通常将变得不可用。如果发生这种情况，则可以通过再次启动已删除的节点来使群集恢复联机。

只要集群中至少有三个符合主条件的节点，通常，最好一次删除一个节点，从而为集群留出足够的时间来自动调整表决配置并适应故障新节点集的容差级别。

如果仅剩下两个符合主控条件的节点，则不能安全地删除任何一个节点，因为这两个节点都需要可靠地进行。要删除这些节点之一，您必须首先通知Elasticsearch它不应成为投票配置的一部分，而应将投票权赋予其他节点。然后，您可以使排除的节点脱机，而不会阻止其他节点取得进展。添加到投票配置排除列表中的节点仍然可以正常工作，但是Elasticsearch尝试将其从投票配置中删除，因此不再需要其投票。重要的是，Elasticsearch永远不会将投票排除列表上的节点自动移回投票配置。一旦排除节点成功从投票配置中成功自动重新配置，在不影响群集主级可用性的情况下将其关闭是安全的。可以使用以下命令将节点添加到投票配置排除列表中投票配置排除API。例如：

投票排除API

# Add node to voting configuration exclusions list and wait for the system
# to auto-reconfigure the node out of the voting configuration up to the
# default timeout of 30 seconds
POST /_cluster/voting_config_exclusions?node_names=node_name
# Add node to voting configuration exclusions list and wait for
# auto-reconfiguration up to one minute
POST /_cluster/voting_config_exclusions?node_names=node_name&timeout=1m

应使用?node_names查询参数通过名称指定应添加到排除列表的节点，或使用查询参数通过其持久节点ID来指定应添加到排除列表的节点?node_ids。

如果对表决配置排除API的调用失败，则可以安全地重试。只有成功的响应才能保证该节点实际上已从表决配置中删除，并且不会恢复。如果当选主节点从投票配置排除，然后将退位给仍处于投票的配置，如果这样的节点可用另一主合格的节点。

尽管表决配置排除API对于将两个节点缩减为一个节点群集最有用，但是也可以使用它同时删除多个符合主机要求的节点。将多个节点添加到排除列表后，系统会尝试自动从表决配置中重新配置所有这些节点，从而可以在确保群集可用的同时安全地关闭它们。

在上述示例中，将七个主节点的群集缩小为只有三个主节点，您可以将四个节点添加到排除列表中，等待确认，然后同时关闭它们。

仅在短时间内从集群中删除至少一半符合主机资格的节点时，才需要进行投票排除。删除不符合主机要求的节点时，不需要它们，或者，当删除少于一半的符合主机要求的节点时，也不需要它们。

为节点添加排除项将在投票配置排除列表中为该节点创建一个条目，该条目使系统自动尝试重新配置投票配置以删除该节点，并防止该节点在删除后返回到投票配置。当前的排除列表存储在集群状态中，可以按以下方式进行检查：

投票排除列表查看API

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

此列表的大小受cluster.max_voting_config_exclusions设置的限制，默认设置为10。请参阅发现和群集形成设置。由于投票配置排除项是持久的且数量有限，因此必须清除它们。

通常，在集群上执行某些维护时会添加排除项，并且在维护完成后应清除排除项。群集在正常操作中不应具有投票配置排除项。

如果由于要永久关闭某个节点而使其从表决配置中排除，则可以在关闭该节点并将其从群集中删除后将其排除。如果排除是错误创建的，或者仅通过指定临时需要，也可以清除这些排除?wait_for_removal=false。

清除投票排除API

# Wait for all the nodes with voting configuration exclusions to be removed from
# the cluster and then remove all the exclusions, allowing any node to return to
# the voting configuration in the future.
DELETE /_cluster/voting_config_exclusions
# Immediately remove all the voting configuration exclusions, allowing any node
# to return to the voting configuration in the future.
DELETE /_cluster/voting_config_exclusions?wait_for_removal=false

【8】Elasticsearch集群脑裂现象

1、什么是脑裂

如果发生网络中断或者服务器宕机，那么集群会有可能被划分为两个部分，各自有自己的master来管理，那么这就是脑裂。

2、脑裂解决方案

master主节点要经过多个master节点共同选举后才能成为新的主节点。就跟班级里选班长一样，并不是你1个人能决定的，需要班里半数以上的人决定。
解决实现原理：半数以上的节点同意选举，节点方可成为新的master。

discovery.zen.minimum_master_nodes=(N/2)+1

N为集群的中master节点的数量，也就是那些 node.master=true 设置的那些服务器节点总数。

3、ES 7.X（已经自动解决这个问题，无需关心）

在最新版7.x中，minimum_master_node这个参数已经被移除了，这一块内容完全由es自身去管理，这样就避免了脑裂的问题，选举也会非常快。‘’

【9】Elasticsearch集群的文档读写原理

1、文档写原理：p1,p2,p0是主节点，r0,r1,r2是副本节点

如果客户端选择了中间节点进行写数据，那这个节点就会变成协调节点，接受用户请求，会对文档进行路由；
计算这个文档会写入到哪个主分片中，有主分片把数据同步到副本分片，都写入完成之后，在跳回到协调节点，由协调节点相应请求。

2、文档读原理：p1,p2,p0是主节点，r0,r1,r2是副本节点

如果客户端请求到了第一个节点，那第一个节点也会变成协调节点，然后根据文档的数据进行路由，然后从主分片或者副本分片轮询读数据。不管从主分片还是副本分片读取数据，最后都会跳回到协调节点，由协调节点相应客户端

3、向ES写入数据时的 4个步骤

分析: 向ES写入数据时，大致分为以下4个步骤:

1. 数据写入到buffer中。

2. 每隔一段时间 (可以在settings中通过refresh_interval手动设置值)刷新buffer，将数据组装并保存到index segment file(可以看作是一份File，只不过目前存储在内存中)

3. index segment file在被创建后，会被立刻读取并写入到OS Cache中(此时数据就可以对客户端提供搜索服务了)。

4. 默认每隔30分钟或translog过大时，ES会将当前内存中所有的index segment标记并形成一个commit point（类似git 的commit id），进行原子性的持久化操作，操作完毕后，删除本次已经已经了持久化的index segment，腾出内存空间。

【10】故障转移过程中的主分片、副本分片的变化（单主分片）

注意，这里是所有的索引都只有默认的1个主分片

【10.1】断开重连一个节点

（1）集群正常时候

最左边的五角星单表该节点是当前的主节点；

（2）关掉主节点 node_1后：

见后续文章的集群原理，过一段时间后（cluster.join.timeout：默认60秒超时）；

会因为超时，确认Node_1节点加入加入集群超时（或者说是失去连接60S）自动把该节点踢出集群；

而集群其他节点会重新选举主节点，且会把原副本分片转换成主分片，并重新生成副本分片；

（3）重新把节点1 实例加入集群（再次重新分布了副本分片、主分片的位置，我们可以发现下图和（1）图中的分片位置不一样了）

　　由于是新节点加入集群，那么最终它是1s发现一次，所以刚启动好，就秒加进来了；

　　在过程中如果一直刷新，发现head插件提供的界面，node_1刚加进来的时候没有分片，然后其他节点会有分片变成紫色，然后紫色的分片就迁移到了新的node_1节点；

【10.2】断开两个节点

直接连都连不上了

但直接 curl 还证明，单节点是活着的

【10.3】添加一个node 节点

（1）新节点实例：修改配置文件

集群名称要一样，node.name 要不一样，discovery.seed_hosts 要包含现有要加入集群的主机信息（最好全加上）

cluster.name: my_es
discovery.seed_hosts: ["192.168.175.131:9301", "192.168.175.131:9302", "192.168.175.131:9303"]

（2）添加后加入到集群后的数据分片信息（依然是自动分片了）

【10.4】为什么分片会自动平衡？

参考官方手册：有自动的平衡设置，但是默认的可能不是最佳实践

　　https://www.bookstack.cn/read/elasticsearch-7.9-en/4867631dc496d585.md

【11】常见的集群部署方式

【11.1】水平扩展：Coordinating only node

当系统中有大量的复杂查询及聚合的时候，增加 Coordinating 节点，增加查询的性能

【11.2】读写分离

【11.3】ES 集群中部署 Kibana

【11.4】异地多活

【参考文档】

官方文档：链接直接百度就好了这就不贴了吧；7.9