elasticsearch集群分片达到最大引发的问题

Posted 2023-04-11

参考技术A 新的周一，日常打开kibana查看日志发现没有日志输出，更改条件查看最近七天日志看到的最后为两天前的日志即最近两天（周六周日）的日志都没有。优秀的公司周末都不上班但是定时任务都是不区分周六日的，肯定有问题。

详细说明

并没有发现什么异常。

由于是自建集群，同时集群也没问题。那就看下日志咯，日志很长核心内容就一句。

this action would add [1] total shards, but this cluster currently has [3000]/[3000] maximum shards open;

核心就是这一句。有个行为要添加一个分片，但是现在集群的分片使用已经最大使用3000个了。

知道了问题在哪里就很好办了，先设置解决下。设置每个节点最大分片数为2000，注意这里是每个节点。环境上下文中数据节点数量为3，这么设置之后此时集群的最大分片数目前就是6000了。

在使用的7.10版本是这么说的，每个节点的最大分片数默认是1000。在集群中计算规则是 每个节点的最大允许数 * 节点数量

原文链接

elasticsearch定义了5个阶段的索引生命周期（Index Lifecycle Management）称为ILM。

https://blog.csdn.net/gybshen/article/details/123794134

版本：kibana的7.10.0

如果创建的索引生命周期策略名称为中文，查看策略详情时会乱码，经过几次刷新又可以查看。

这里选择十天以上的数据进入删除阶段周期，但是实际上没有删除的动作。需要手动创建的才有，在界面上创建的没有。

这里为索引创建一个生命周期策略，名称为 application-logstash-clear-policy 具体周期为

这个时候再看该策略的详情就看到删除阶段就有具体的行为了

Elasticsearch 集群

参考技术A

分片：分片就是对数据切分成了多个部分，Elasticsearch 默认会把一个索引分成五个分片，

数据保存在分片内，分片又被分配到集群内的各个节点里

副本：副本就是对原分片的复制，和原分片的内容是一样的，Elasticsearch 默认会生成一份副本，所以相当于是五个原分片和五个分片副本，相当于一份数据存了两份，并分了十个分片

主节点：即 Master 节点。主节点的主要职责是和集群操作相关的内容，如创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。稳定的主节点对集群的 健康 是非常重要的。默认情况下任何一个集群中的节点都有可能被选为主节点。索引数据和搜索查询等操作会占用大量的cpu，内存，io资源，为了确保一个集群的稳定，分离主节点和数据节点是一个比较好的选择。虽然主节点也可以协调节点，路由搜索和从客户端新增数据到数据节点，但最好不要使用这些专用的主节点。一个重要的原则是，尽可能做尽量少的工作。

数据节点：即 Data 节点。数据节点主要是存储索引数据的节点，主要对文档进行增删改查操作，聚合操作等。数据节点对 CPU、内存、IO 要求较高，在优化的时候需要监控数据节点的状态，当资源不够的时候，需要在集群中添加新的节点。

负载均衡节点：也称作 Client 节点，也称作客户端节点。当一个节点既不配置为主节点，也不配置为数据节点时，该节点只能处理路由请求，处理搜索，分发索引操作等，从本质上来说该客户节点表现为智能负载平衡器。独立的客户端节点在一个比较大的集群中是非常有用的，他协调主节点和数据节点，客户端节点加入集群可以得到集群的状态，根据集群的状态可以直接路由请求。

预处理节点：也称作 Ingest 节点，在索引数据之前可以先对数据做预处理操作，所有节点其实默认都是支持 Ingest 操作的，也可以专门将某个节点配置为 Ingest 节点。

1.Master：主节点，每个集群都有且只有一个

尽量避免Master节点又是数据节点： node.data true

主节点的主要职责是负责集群层面的相关操作，管理集群变更，如创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。

2.Voting：投票节点

node.voting_only = true（仅投票节点，即使配置了data.master = true，也不会参选, 但是仍然可以作为数据节点）。

3.Coordinating：协调节点

每一个节点都隐式的是一个协调节点，如果同时设置了data.master = false和data.data=false，那么此节点将成为仅协调节点。

4.Master-eligible node（候选节点）

可以通过选举成为Master的节点

5.Data node（数据节点）

主要负责数据存储和查询服务

配置：

这是ES节点默认配置，既作为候选节点又作为数据节点，这样的节点一旦被选举为Master，压力是比较大的，通常来说Master节点应该只承担较为轻量级的任务，比如创建删除索引，分片均衡等。

只作为候选节点，不作为数据节点，可参选Master节点，当选后成为真正的Master节点。

既不当候选节点，也不作为数据节点，那就是仅协调节点，负责负载均衡

不作为候选节点，但是作为数据节点，这样的节点主要负责数据存储和查询服务。

协调节点是如何工作的，他是怎么找到对应的节点的?

每个节点都保存了集群的状态,只有Master节点才能修改集群的状态信息
集群状态(Cluster Starte),维护了一个集群中,必要的信息
所有的节点信息
所有的索引和其相关的Mapping与Setting信息
分片的路由信息

协调节点作为es节点中的一个节点，默认情况下es集群中所有的节点都能当协调节点，主要作用于请求转发，请求响应处理等轻量级操作。

这意味着如果它们接收到用户请求，它们就可以处理用户请求

status 字段指示着当前集群在总体上是否工作正常。它的三种颜色含义如下：

green 所有的主分片和副本分片都正常运行。

yellow 所有的主分片都正常运行，但不是所有的副本分片都正常运行。

red 有主分片没能正常运行

当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？当我们创建文档时，它如何决定这个文档应当被存储在分片 1 还是分片 2 中呢？

首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。实际上，这个过程是根据下面这个公式决定的：

routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到 余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。

我们可以发送请求到集群中的任一节点。 每个节点都有能力处理任意请求。 每个节点都知道集群中任一文档位置，所以可以直接将请求转发到需要的节点上。 在下面的例子中，将所有的请求发送到 Node 1 ，我们将其称为 协调节点(coordinating node) 。

以下是在主副分片和任何副本分片上面 成功新建，索引和删除文档所需要的步骤顺序：

consistency 一直性： 参数的值可以设为 one （只要主分片状态 ok 就允许执行_写_操作）, all （必须要主分片和所有副本分片的状态没问题才允许执行_写_操作）, 或 quorum 。默认值为 quorum , 即大多数的分片副本状态没问题就允许执行_写_操作。

master选举当然是由master-eligible节点发起

深入理解 Elasticsearch 7.x 新的集群协调层：

https://easyice.cn/archives/332

Elasticsearch的选举机制

https://www.jianshu.com/p/bba684897544

elasticsearch 选主流程

https://www.easyice.cn/archives/164

elasticsearch的master选举机制

https://www.cnblogs.com/jelly12345/p/15319549.html

https://blog.csdn.net/ailiandeziwei/article/details/87856210

shard_num = hash(_routing) % num_primary_shards

其中 _ routing 是一个可变值，默认是文档的 _id 的值 ，也可以设置成一个自定义的值。 _routing 通过 hash 函数生成一个数字，然后这个数字再除以 num_of_primary_shards （主分片的数量）后得到余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。 这就解释了为什么我们要在创建索引的时候就确定好主分片的数量 并且永远不会改变这个数量 ：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。

解释：translog的作用：在执行commit之前，所有的而数据都是停留在buffer或OS cache之中，无论buffer或OS cache都是内存，一旦这台机器死了，内存的数据就会丢失，所以需要将数据对应的操作写入一个专门的日志问价之中，一旦机器出现宕机，再次重启的时候，es会主动的读取translog之中的日志文件的数据，恢复到内存buffer和OS cache之中。

将现有的translog文件进行清空，然后在重新启动一个translog，此时commit就算是成功了，默认的是每隔30分钟进行一次commit，但是如果translog的文件过大，也会触发commit，整个commit过程就叫做一个flush操作，我们也可以通过ES API,手动执行flush操作，手动将OS cache 的数据fsync到磁盘上面去，记录一个commit point，清空translog文件

补充：其实translog的数据也是先写入到OS cache之中的，默认每隔5秒之中将数据刷新到硬盘中去，也就是说，可能有5秒的数据仅仅停留在buffer或者translog文件的OS cache中，如果此时机器挂了，会丢失5秒的数据，但是这样的性能比较好，我们也可以将每次的操作都必须是直接fsync到磁盘，但是性能会比较差。

如果时删除操作，commit的时候会产生一个.del文件，里面讲某个doc标记为delete状态，那么搜索的时候，会根据.del文件的状态，就知道那个文件被删除了。

如果时更新操作，就是讲原来的doc标识为delete状态，然后重新写入一条数据即可。

buffer每次更新一次，就会产生一个segment file 文件，所以在默认情况之下，就会产生很多的segment file 文件，将会定期执行merge操作

每次merge的时候，就会将多个segment file 文件进行合并为一个，同时将标记为delete的文件进行删除，然后将新的segment file 文件写入到磁盘，这里会写一个commit point，标识所有的新的segment file，然后打开新的segment file供搜索使用。

段是不可改变的，所以既不能从把文档从旧的段中移除，也不能修改旧的段来进行反映文档的更新。 取而代之的是，每个提交点会包含一个 .del 文件，文件中会列出这些被删除文档的段信息。

当一个文档被 “删除” 时，它实际上只是在 .del 文件中被 标记 删除。一个被标记删除的文档仍然可以被查询匹配到， 但它会在最终结果被返回前从结果集中移除。

文档更新也是类似的操作方式：当一个文档被更新时，旧版本文档被标记删除，文档的新版本被索引到一个新的段中。 可能两个版本的文档都会被一个查询匹配到，但被删除的那个旧版本文档在结果集返回前就已经被移除。

由于自动刷新流程每秒会创建一个新的段 ，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。 每一个段都会消耗文件句柄、内存和cpu运行周期。更重要的是，每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就越慢。

Elasticsearch通过在后台进行段合并来解决这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大的段。

段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档（或被更新文档的旧版本）不会被拷贝到新的大段中。

合并大的段需要消耗大量的I/O和CPU资源，如果任其发展会影响搜索性能。Elasticsearch在默认情况下会对合并流程进行资源限制，所以搜索仍然 有足够的资源很好地执行

https://blog.csdn.net/qq_21299835/article/details/106534644