Elasticsearch 节点关闭流程分析

源:https://www.easyice.cn/archives/280

 

当为 es 集群更新配置,升级版本时,需要滚动升级:关闭数据平衡,依次 kill 节点。但是 kill 一个节点的操作是否安全?如果此时节点有正在执行的读写操作会有什么影响,如果节点是 master 是如何处理的?关闭流程是怎么实现的?kill 节点都会带来哪些风险?

 

结论

滚动重启期间,主节点被关闭,集群重新选主,进入 gateway 和 index 的恢复流程,期间,无主,gateway,及主分片未恢复期间,写请求会被阻塞。

 

数据节点被关闭,读写请求的 TCP 连接被关闭,客户端失败。但写流程已经到达 Engine 环节的会正常写完,只是客户端无法感知结果。此时客户端重试,使用自动生成 ID 的情况下会多数据。

 

综合来说,滚动升级产生影响是中断当前写请求,以及导致主节点重启引起的集群启动流程。所有这些情况会导致写入请求立即,或等待一段时间后失败,只要客户端重试,业务数据不会丢失。但是可能会多数据。其次,主节点被重启后,新主被选出,到主分片分配完毕需要的过程较长,导致较长客户端需要失败重试的时期。

 

当索引部分主分片未分配时,使用自动生成 ID 的情况下,期间如果持续写入,客户端对失败重试可能会成功,但是可能会产生数据倾斜,视数量而定。

 

节点关闭基本流程

入口:o.e.b.Bootstrap#setup 中添加了 shutdown hook,当收到 SIGTERM 或 SIGINT 信号时执行节点关闭流程

 

 
if (addShutdownHook) {  Runtime.getRuntime().addShutdownHook(new Thread() {      @Override      public void run() {          try {              IOUtils.close(node, spawner);              LoggerContext context = (LoggerContext) LogManager.getContext(false);              Configurator.shutdown(context);          } catch (IOException ex) {              throw new ElasticsearchException("failed to stop node", ex);          }      }  });}
  Runtime.getRuntime().addShutdownHook(new Thread() {
      @Override
      public void run() {
          try {
              IOUtils.close(node, spawner);
              LoggerContext context = (LoggerContext) LogManager.getContext(false);
              Configurator.shutdown(context);
          } catch (IOException ex) {
              throw new ElasticsearchException("failed to stop node", ex);
          }
      }
  });
}

 

每个模块的 Service 中都实现了doStop和doClose,用于处理这个模块的正常关闭流程。节点总的关闭流程位于:o.e.n.Node#close,先调用一遍各个模块的doStop,然后再次遍历各个模块执行 doClose。调用各模块的doStop时,模块的先后顺序很重要(5.5.3版本,更高版本稍有差别):

 

 

TribeService

HttpServerTransport

SnapshotsService

IndicesClusterStateService

Discovery

RoutingService

ClusterService

GatewayService

SearchService

TransportService

plugin

IndicesService

总体来看:

  • 关闭快照和 HTTPServer

  • 关闭集群拓扑管理,不再响应 ping 请求

  • 关闭网络模块,让节点离线

  • 执行各个插件的关闭流程

  • 关闭 IndicesService

 

最后才关闭 IndicesService,因为这期间需要等待释放的资源最多,时间最长。

 

分片读写过程中执行关闭

写过程中关闭:IndicesService 的doStop过程执行 removeIndex,执行到 Engine 的 flushAndClose,会对 Engine 加写锁。因此Engine 的读写操作是安全的,但是由于网络模块被关闭,客户端的连接会被断开。客户端应当作为失败处理,虽然es 的写流程还在继续。

 

同样,读过程中,由于连接被关闭,会导致客户端读失败。

 

节点关闭过程中,IndicesService 的doStop对 Engine设置了超时,如果flushAndClose 一直等待,CountDownLatch.await 默认1天才会继续后面的流程。

 

主节点被关闭

没有什么特殊处理,节点正常执行关闭流程,TransportService模块被关闭后,集群重新选举新 master。因此,滚动重启期间会有一段时间处于无主状态。

 


#### 往期推荐

1、HBase最佳实践 | 聊聊HBase核心配置参数
2、Apache Hudi:剑指数据湖的增量处理框架
3、Hadoop社区比 Ozone 更重要的事情
4、MapReduce Shuffle 和 Spark Shuffle 结业篇

Elasticsearch 节点关闭流程分析_第1张图片

 

你可能感兴趣的:(Elasticsearch 节点关闭流程分析)