elasticsearch参数配置

Posted 2023-04-21

参考技术A 前一段时间配置了公司offline,online的ES服务两组，根据节点分工不同，分为master，client，data三种类型节点；

服务器参数修改如下：

/etc/sysctl``.conf

增加：vm.max_map_count=262144 然后执行sysctl -p生效

/etc/security/limits.conf

elastic soft memlock unlimited
elastic hard memlock unlimited

（退出当前用户，重新登录生效）

修改配置参数如下：

master节点（内存8G）

node.name: master-56-1
node.master: true
node.voting_only: false
node.data: false
node.ingest: true
node.ml: false

cluster.remote.connect: false

http.cors.enabled: true
http.port: 9210

network.host: 100.100.200.56
transport.port: 9300
transport.compress: true

数据节点（data节点）（内存31G）

node.master: false
node.voting_only: false
node.data: true
node.ingest: false
node.ml : false

http.enabled: false

http.port: 0

network.host: 100.100.200.50
transport.port: 9300
transport.compress: true

bootstrap.memory_lock: true

cluster.remote.connect: false
cluster.routing.allocation.same_shard.host: true
indices.breaker.request.limit: 90%

thread_pool.search.max_queue_size 默认值为1000，与thread_pool.search.min_queue_size默认值一样，都为1000； 所以max_queue_size可以调为2000

thread_pool.search.size，默认生成与cpu核心数一至，可以改为cpu核心数2倍；

协调节点（client节点）（内存16G)

node.master: false
node.voting_only: false
node.data: false
node.ingest: false
node.ml : false

cluster.remote.connect: false

http.cors.enabled: true
http.port: 9200

http.cors.allow-headers: Authorization
xpack.security.enabled: true

network.host: 0.0.0.0
transport.port: 9310
transport.compress: true

bootstrap.memory_lock: true

discovery.seed_hosts: ["100.100.200.55:9300","10.110.200.56:9300","100.100.200.57:9300"]

主分片和副本分片分布在不同物理机上（这会防止同一个shard的主副本在一个物理机上）：
cluster.routing.allocation.same_shard.host: true。

elasticsearch(es) 集群恢复触发配置（Local Gateway参数）

elasticsearch(es) 集群恢复触发配置（Local Gateway）

当你集群重启时，几个配置项影响你的分片恢复的表现。 首先，我们需要明白如果什么也没配置将会发生什么。

想象一下假设你有 10 个节点，每个节点只保存一个分片，这个分片是一个主分片或者是一个副本分片，或者说有一个有 5 个主分片／1 个副本分片的索引。有时你需要为整个集群做离线维护（比如，为了安装一个新的驱动程序）， 当你重启你的集群，恰巧出现了 5 个节点已经启动，还有 5 个还没启动的场景。

假设其它 5 个节点出问题，或者他们根本没有收到立即重启的命令。不管什么原因，你有 5 个节点在线上，这五个节点会相互通信，选出一个 master，从而形成一个集群。 他们注意到数据不再均匀分布，因为有 5 个节点在集群中丢失了，所以他们之间会立即启动分片复制。

最后，你的其它 5 个节点打开加入了集群。这些节点会发现 它们 的数据正在被复制到其他节点，所以他们删除本地数据（因为这份数据要么是多余的，要么是过时的）。 然后整个集群重新进行平衡，因为集群的大小已经从 5 变成了 10。

在整个过程中，你的节点会消耗磁盘和网络带宽，来回移动数据，因为没有更好的办法。对于有 TB 数据的大集群, 这种无用的数据传输需要 很长时间 。如果等待所有的节点重启好了，整个集群再上线，所有的本地的数据都不需要移动。

本地网关

本地网关模块在整个集群重新启动时存储集群状态和分片数据。

以下参数是配置 尝试恢复集群状态和集群数据 的触发点，必须在每个主节点上都做做如下配置。

• gateway.expected_nodes
  预期在集群中的（数据或主）节点数。只要预期的节点数已加入集群，就会启动本地分片的恢复。默认为0

• gateway.expected_master_nodes
  预期在集群中的主节点数。一旦预期的主节点数加入集群，就会开始恢复本地分片。默认为0

• gateway.expected_data_nodes
  预期在集群中的数据节点数。一旦预期数量的节点已加入集群，就会启动本地分片的恢复。默认为0

• gateway.recover_after_time
  如果未达到预期的节点数，则恢复过程将等待配置的时间量，然后再尝试恢复。如果只要配置了expected_nodes，则默认这个参数值为5m

一旦recover_after_time持续时间超时，只要满足以下条件，恢复就会开始：

• gateway.recover_after_nodes
  只要此许多数据或主节点已加入集群，即可恢复。

• gateway.recover_after_master_nodes
  只要这么多主节点已加入集群，就可以恢复。

• gateway.recover_after_data_nodes
  只要这么多数据节点已加入集群，就可以恢复。

上述描述来自官方文档Local Gateway的描述，看完之后有点绕，还是不能完全理解。

stack overflow 上的解释

stack overflow 上的描述相对好理解很多：Difference between expected_nodes and recover_after_nodes parameters。这里做一下搬运工，给出结论。
满足 gateway.recover_* 条件之后会触发记时器，有两种情况

1. 在 recovery_after_time 为用完，满足 gateway.excepted_* 条件则立即执行数据同步
2. recovery_after_time 时间用完，那么也会开始执行数据同步

举个栗子

gateway:
    recover_after_nodes: 3
    expected_nodes: 5

虽然上面没有配置 recovery_after_time 属性，但是因为配置了 expected_nodes 所以会有默认值 5m，就是5分钟。
假设集群中有5个node，其中3个node已经恢复正常使用，也就是达到了 recover_after_nodes: 3 的条件。那么如果5分钟之内一共有5个node恢复正常使用，那么会立即进行集群的数据恢复，要不然就是过了5分钟node数量打不到5个，也会触发数据恢复。
欢迎转载，但请注明本文链接，谢谢你。
2018.7.7 17:31