为了能够在不影响线上服务，无缝的升级Druid集群，建议按照以下顺序更新Druid节点。
- Historical
- Overlord
- Middle Manager
- Standalone Real-time
- Broker
- Coordinator
Historical
历史节点一次更新一个，历史节点启动的时候将提供服务的所有Segment加载映射到内存中，这可能只需要几秒就能完成，也可能需要几分钟，取决于历史节点的硬件条件，以及数据量。两个历史节点更新的时间间隔应该大于一个历史节点的启动时间。
Overlord
Overlord节点也是一次更新一个。然后逐个更新。
Middle Managers
Middle Manager节点运行着批处理任务和时间索引任务。如果想要在不影响任务的前提下升级Middle Managers节点，可以通过以下三种策略。
Rolling restart (基于恢复)
如果 Middle Managers节点配置了druid.indexer.task.restoreTasksOnRestart=true参数。如果配置了个该参数索引任务的状态存储在磁盘， Middle Manager节点重启以后索引任务也会自动重启，而不会失败。
Rolling restart (基于优雅的终止)
Middle Manager节点可以通过"disable" API优雅的终止。这种方式适合所有的任务，包括不可恢复的任务。
在打算升级 Middle Manager节点时，首先向<MiddleManager_IP:PORT>/druid/worker/v1/disable发送post请求。这样Overlord节点不再会发送新的任务到该 Middle Manager节点。等待当前的任务运行完成。节点状态可以通过<MiddleManager_IP:PORT>/druid/worker/v1/enabled获取。通过GET请求<MiddleManager_IP:PORT>/druid/worker/v1/tasks获取当前的所有任务。当获取的列表为空时，你就可以安全的更新Middle Manager节点了。当Middle Managers节点启动以后，它会自动开启，接收任务，可以通过向<MiddleManager_IP:PORT>/druid/worker/v1/enable发送post请求来开启。
Autoscaling-based replacement(自动扩容更新)
如果Overlord节点开启了自动扩容，Overlord节点可以启动大量新的Middle Manager节点，在当老的Middle Manager节点上的任务完成以后，安全的关闭老的Middle Manager节点。这个过程可以通过druid.indexer.runner.minWorkerVersion=#{VERSION}来设置。每次更新overlord节点，VERSION的值应该递增，这样将会有大量的新的Middle Manager节点启动。druid.indexer.autoscale.workerVersion=#{VERSION}参宿也需要设置。
Standalone Real-time
Standalone Real-time节点也是一次更新一个。然后逐个更新。
Broker
Broker节点也是一次更新一个，然后逐个更新。Broker节点启动后需要加载整个集群的健康状态信息，所以两个Broker节点的更新时间间隔应该由一定的延迟。
Coordinator
Coordinator节点也是一次更新一个。然后逐个更新。
