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);
          }
      }
  });
}

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

TribeServiceHttpServerTransportSnapshotsServiceIndicesClusterStateServiceDiscoveryRoutingServiceClusterServiceGatewayServiceSearchServiceTransportServicepluginIndicesService

总体来看：

• 关闭快照和 HTTPServer
• 关闭集群拓扑管理，不再响应 ping 请求
• 关闭网络模块，让节点离线
• 执行各个插件的关闭流程
• 关闭 IndicesService

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

分片读写过程中执行关闭

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

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

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

主节点被关闭

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