滚动升级
对于不停机的滚动升级Apache Druid集群，我们推荐按照以下顺序来升级更新Druid进程
- Historical
- *Overlord
- *MiddleManager/Indexers
- Standalone Real-time
- Broker
- Coordinator(或者合并的Coordinator+Overlord)
*在0.12.0中，Kafka supervisor和Kafka索引任务之间存在协议更改，并且对磁盘上保存的元数据格式也有一些更改。因此，为了支持滚动升级，所有的MiddleManager都需要在Overlord之前先升级。请注意，此顺序与标准升级顺序不同，还请注意，此顺序仅在使用Kafka索引服务时才有必要。如果您不使用Kafka索引服务或可以处理Kafka Supervisor的停机时间，则可以按任何顺序升级。
Historical
Historical可以一次更新一个。 每一个Historical进程都有一个启动时间来内存映射更新之前它所有服务的segment。 启动时间通常是需要几秒钟到几分钟，具体取决于主机的硬件。 只有更新每个Historical进程时有足够的的延迟（大于启动单个进程所需的时间），就可以滚动更新整个Historical集群
Overlord
Overlord进程可以以滚动的方式一次更新一个
MiddleManagers/Indexers
MiddleManagers或者Indexers节点运行着批任务或者实时索引任务。 通常，我们需要以一种特定的方式来更新MiddleManager以保证实时索引任务不会失败。 有以下三种策略可供使用
滚动重启（基于状态保存）
当设置 druid.indexer.task.restoreTasksOnRestart=true 时，MiddleManager可以以滚动的方式一次更新一个。 在这种情况下，支持恢复的索引任务将在MiddleManager重新启动时恢复其状态，并且不会失败。
目前，只有实时任务支持恢复，因此非实时索引任务将失败，需要重新提交。
滚动重启（基于优雅停机）
MiddleManager可以通过disable API来优雅的停止服务。 这种方式针对所有的类型都有效，包括那些不可恢复的任务
在准备升级MiddleManager之前，对 <MiddleManager_IP:PORT>/druid/worker/v1/disable 发送一个POST请求， Overlord将不会再发送任务到该MiddleManager，而已经在运行的任务将会运行完成。 当前的状态可以通过 <MiddleManager_IP:PORT>/druid/worker/v1/enabled 来检测。
通过向 <MiddleManager_IP:PORT>/druid/worker/v1/tasks 发送一个GET请求可以获得所有的当前任务。 当这个队列为空的时候，就可以安全的更新该MiddleManager了，当MiddleManager重新启动后，将会自动的enable，也可以通过手动的发送一个POST请求到 <MiddleManager_IP:PORT>/druid/worker/v1/enable 来启用
基于自动伸缩的替换更新
如果在您的Overlord上启用了自动缩放，则Overlord进程可以整体启动新的MiddleManager进程，然后在其任务完成时优雅地终止旧进程。该进程通过设置 druid.indexer.runner.minWorkerVersion=#{VERSION} 来进行配置。 每当更新Overlord进程时， VERSION 的值需要被增加，这将触发一批新的MiddleManager的启动
同时， druid.indexer.autoscale.workerVersion=#{VERSION} 这个配置也需要设置
Standalone Real-time
Standalone Real-time进程可以以滚动的方式一次更新一个
Broker
Broker进程可以以滚动的方式一次更新一个. 更新每个进程之间需要一些延迟，因为Broker必须在返回有效结果之前加载集群的整个状态。
Coordinator
Coordinator进程可以以滚动的方式一次更新一个