高峰只对攀登它而不是仰望它的人来说才有真正意义。

ES集群如何进行挨个重启?

Elasticsearch | 作者 sterne vencel | 发布于2018年06月06日 | 阅读数:15436

对于持续的不断进行数据写入的ES集群,如何对集群所有的节点挨个重启?要求就是:正在写入的数据不丢失。
集群背景:
master-eligible节点三个,client-node节点3个,其他是data-node
 
官方重启方案执行状况:
1)设置如下配置后,ES集群无法新建索引,所以不能设置。cluster.routing.allocation.enable" : "none" 
2)执行同步刷新,由于有些索引不断更新,所以效果不好。_flush/synced?pretty
3)重启mater节点时,master选举期间,集群不可用。默认为3s后选举
 
所以,问题来了?怎么重启?劳烦大家指教?
 
 
已邀请:
我来科普一下吧。
 
当cluster.routing.allocation.enable设置为"none"的时候,不会allocate任何UNASSIGNED状态的shard,但是有一个特例:


本地的因为重启而变成UNASSIGNED状态的primary  shard不受这个参数约束


 
怎么理解这个规则呢?举个例子吧。
 
假设集群索引都有设置复制片,然后重启了某一个结点,该结点上的shard会经历下面这个过程:
  1. replica变成UNASSIGNED
  2. primary在其他结点上对应的replica被推举为primary,而本地的这些primary变成replica,并且状态变成UNASSIGNED
  3. 由于cluster.routing.allocation.enable设置为none, 这些replica不会再其他结点上复制恢复,保持在UNASSIGNED状态
  4. 因此集群状态应该是yellow,意味着所有索引的primary都存在可用,只是部分复制片因为上述参数设置的原因,没有立即进行恢复。
  5. 重启的结点加入集群,通过master恢复状态信息以后,可以得知那些UNASSIGNED的shard,在这个结点上存在数据。
  6. 重新设置cluster.routing.allocation.enable" : "all" ,master得到指令,开始恢复那些UNASSIGNED的shard
  7. 对于不再更新的冷shard,由于synced_flush, master知道这些数据在重启的结点上存在并且和primary一致,只需要更新一下集群的状态,将他们allocate到刚启动的结点,并且状态置为started。所以这个过程非常快,看起来瞬间可以完成。
  8. 由于集群持续有数据写入,部分primary由于新写入了数据,重启结点上对应的replica已经out of sync,因此需要进入数据的recovery过程,这个过程可能需要在主副片之间拷贝数据,或者利用translog重放热数据。 该过程取决于shard大小,以及实时数据写入量的大小,需要一些时间,可能几分钟到几个小时,直到primary -replica完全in-sync,才会将replica置为started。

 
如果同时重启2个或者更多结点,会是怎样的?
 
这种情况下,有可能某个shard的primary和replica同时变成UNASSIGNED了,集群状态变成red。  如果结点重启好全部加入集群,即使cluster.routing.allocation.enable设置为none,本地的primary shard因为不受这个参数约束,会立即开始做existing_store类别的恢复。 等全部primary恢复好以后,集群状态变成yellow,然后不再继续恢复replica,直到重新设置cluster.routing.allocation.enable为all。
 
所以,cluster.routing.allocation.enable: "none",实际上影响的是已有索引(local存在)的replica,以及新创建索引的primary和replica。
 
 
至于停掉结点后,集群查询延迟增加,是因为重启结点上的查询会由剩余的结点分担,多少延迟会增加一些。
 

laoyang360 - 《一本书讲透Elasticsearch》作者,Elastic认证工程师 [死磕Elasitcsearch]知识星球地址:http://t.cn/RmwM3N9;微信公众号:铭毅天下; 博客:https://elastic.blog.csdn.net

赞同来自:

实际应用场景是:只要集群没有挂掉(避免出现脑劣问题),保证有候选的master节点,有数据可以写入data节点。
其他的节点重启顺序没有要求,都可以的。

bill

赞同来自:

重启一个节点过程中,如果要写的主分片在这个节点的,会不会出现写入失败。

ES的主备分片切换在节点下线时是瞬时的吗,是个问题。

sterne vencel - 90

赞同来自:

我对一个ES集群进行重启的结果是:
背景;集群有20多个节点,每天的数据写入量为3TB左右
各节点的角色分开
重启设置:
1)写入不停止
2)cluster.routing.allocation.enable" : "none" 
3)执行同步刷新
 
当重启一个data节点时,出线一下几个情况:
1)停掉节点后,unassigned_shards为309, 但是当节点加入集群后,这个数字没有变化,只有设置cluster.routing.allocation.enable" : "all" 后,unassigned_shards才会变小(很快)-直到0。之后集群状态并不会变为green,因为出现3个initializing_shards,initializing_shards变为0的时间需要10多分钟。为什么会出现这种情况?不应该当节点加入集群后,unassigned_shards会瞬间降低(不会变为0的原因是有分片更新了),为什么cluster.routing.allocation.enable" : "all" 后,才会unassigned_shards发生变化。
2)停掉节点后,集群的查询延迟增加?为什么?

jianjianhe

赞同来自:

设置如下配置后,ES集群无法新建索引,所以不能设置。cluster.routing.allocation.enable" : "none" 
这个现象是指当前节点无法创建索引,还是整个集群无法创建索引,node代表任何分片都不允许被分配,是不是这个原因导致无法创建索引?

luyuncheng

赞同来自:

1. 你重启单个节点的时候一般是需要停写的,不然当停止单个节点的过程中有分片写入数据,那么就会产生恢复数据。
2. 如果你不想停写,可以在其他节点上建立一个新的索引,把alias指向新的索引,然后停止原索引的写,再设置在这个索引下的index级别的 allocation 为 none。在重启节点。
3. 重启节点之前记得需要sync数据。并且最好是等待5分钟再sync一下。因为在5.x版本下会发生不活跃节点的自动再sync一次导致syncid不一致

要回复问题请先登录注册