Elasticsearch 集群路由机制与仲裁机制

Elasticsearch 集群路由机制与仲裁机制

一、ES的路由机制

ES的路由算法有一个公式：

shard_num = hash(_routing) % num_primary_shards

其中 _routing 是路由字段的值，默认使用文档的ID字段： _id 。如果想自己控制数据的路由规则的话，那可以修改这个默认值。修改的方式非常简单，只需要在插入数据的时候指定路由的key即可。

为什么我们的primary shard数量不可变？

假设我们的id为1，然后我们hash过后的值为10，这个时候我们三台服务器，我们就可以10%3得到1，也就是我们应该放在P1上，然后这个时候假设我们的分片数现在改变了，变成了4，我存储的时候是放在P1上的，结果我现在需要进行操作，比如我想要获取我们的文档，这个时候我们计算一下分片，10%4 = 2，我们就回去P2上进行寻找，我们的P2上面必然是没有这条数据的。

所以这个时候就会间接造成我们数据的丢失，或者说不可访问。所以我们的primary shard数量不可变，但是我们的replica shard是可以随时修改的，因为我们的路由算法跟我们的副本分片没有任何关系。

二、脑裂

ES在主节点上产生分歧，产生多个主节点，从而使集群分裂，使得集群处于异常状态。这个现象叫做脑裂。

ES脑裂可能的原因：

• 未做节点分离。 master与data为同一节点。当我们的节点既为主节点，又为数据节点的时候，这个时候我有非常多的数据，数据全部集中在我们的主节点，然后当我们的数据访问量过大的时候，是不是也可能会导致Master节点停止响应（假死状态）。从而导致我们的集群重新选主

解决方案：

• 设置超时时间，或者设计一个类似自我保护机制。
• 修改JVM内存，在config/jvm.options 文件里将 -Xms 和 -Xmx 修改得更大，一般建议为服务器的内存一半。
• 节点分离

主节点配置为
 •node.master: true
 •node.data: false
 •数据节点配置为
 •node.master: false
 •node.data: true

三、集群协调

Elasticsearch 集群可以执行需要多个节点协同工作的任务，它使用了节点仲裁机制，只有在多数节点接受集群状态更新之后，集群状态的更新才被认为是成功的。

仲裁是集群中符合主节点条件的节点的一个集合。仲裁的优势在于，一些节点可能会连接失败，但不会影响集群的可用性。

通常，建议集群最少需要三个符合主节点条件的节点，如果其中一个节点失败，其他两个节点仍然可以形成仲裁。如果一个集群少于三个符合主节点条件的节点，那它就不能安全地容忍其中任何一个节点发生故障。相反，如果一个集群有超过三个符合主节点条件的节点，那么选举和集群状态更新可能需要更长的时间。

四、故障模式

从 7.0 开始，如果你想要启动一个全新的集群，并且集群在多台主机上都有节点，那么你必须指定该集群在第一次选举中应该使用的一组符合主节点条件的节点作为选举配置。这就是所谓的集群引导，只在首次形成集群时才需要。

已经加入集群的节点将选举配置存储在它们的数据文件夹中，并在重新启动后重用这些配置，而正在加入现有集群的新节点可以从集群的当前主节点接收这些信息。

什么意思呢？

简单说就是你要加一个参数cluster.initial_master_nodes，参数设置一系列符合主节点条件的节点的主机名或 IP 地址来引导启动集群。你还需要配置发现子系统，这样节点就知道如何找到彼此。这也就是我们新加入的cluster.initial_master_nodes参数的含义