elasticsearch 节点关闭流程分析
问题
当为 es 集群更新配置，升级版本时，需要滚动升级：关闭数据平衡，依次 kill 节点。但是 kill 一个节点的操作是否安全？如果此时节点有正在执行的读写操作会有什么影响，如果节点是 master 是如何处理的？关闭流程是怎么实现的？kill 节点都会带来哪些风险？
结论
滚动重启期间，主节点被关闭，集群重新选主，进入 gateway 和 index 的恢复流程，期间，无主，gateway，及主分片未恢复期间，写请求会被阻塞
数据节点被关闭，读写请求的 TCP 连接被关闭，客户端失败。但写流程已经到达 Engine 环节的会正常写完，只是客户端无法感知结果。此时客户端重试，使用自动生成 ID 的情况下会多数据。
综合来说，滚动升级产生影响是中断当前写请求，以及导致主节点重启引起的集群启动流程。所有这些情况会导致写入请求立即，或等待一段时间后失败，只要客户端重试，业务数据不会丢失。但是可能会多数据。其次，主节点被重启后，新主被选出，到主分片分配完毕需要的过程较长，导致较长客户端需要失败重试的时期。
当索引部分主分片未分配时，使用自动生成 ID 的情况下，期间如果持续写入，客户端对失败重试可能会成功，但是可能会产生数据倾斜，视数量而定。
节点关闭基本流程：
入口：o.e.b.Bootstrap#setup 中添加了 shutdown hook，当收到 SIGTERM 或 SIGINT 信号时执行节点关闭流程
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
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时，模块的先后顺序很重要：
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。因此，滚动重启期间会有一段时间处于无主状态。
（转载请注明作者和出处 easyice.cn ，请勿用于任何商业用途）
(欢迎评分)
Loading...