permalink: administration/rolling-update

功能目标

当需要升级server版本或者修改config配置时，都需要对集群进行升级。对于分布式集群来说，常用的升级方法就是滚动升级(Rolling-Update)，即不停止服务，对一台一台server逐个进行升级。

集群升级的重要目标在于平稳，即不停服，并且对可用性的影响降至最低。为了达到这个目标，我们先看看在升级过程中哪些地方可能会影响可用性：

replica server进程被kill后，该进程服务的replica无法提供服务：
- 对于primary replica：因为直接向客户端提供读写服务，所以进程kill后肯定会影响读写，需要等metaserver重新分派新的primary replica后才能恢复。meta server通过心跳感知replica server的存活状态，failure detection的时间延迟取决于配置参数fd_grace_seconds，通常配置为10秒，即最多需要经过10秒，meta server才能知道replica server挂了，然后重新分派新的primary replica。
- 对于secondary replica：由于不服务读，所以理论上对读无影响。但是会影响写，因为一致性协议要求一主两备都写成功，写操作才能提交。进程kill后，primary replica在执行写操作过程中会发现该secondary replica已失联，然后通知meta server将其踢掉，经过reconfiguration阶段后变成一主一备，继续提供写服务。在切换过程中尚未完成的写操作，即使有reconciliation阶段重新执行，但客户端那边大概率已经超时了，对可用性有一定影响。但是这个影响相对小些，因为reconfiguration的速度是比较快的，通常在1秒以内就能完成。
升级meta server：升级meta server对可用度的影响几乎可以忽略不计，因为客户端会在本地缓存各partition的服务节点信息，通常情况下并不需要向meta server查询，因此meta server重启过程中的短暂失联对客户端基本没有影响。不过考虑到meta server需要与replica server维持心跳，所以要避免连续kill meta server进程，造成replica server心跳失联的风险。
升级collector：升级collector对可用度没有影响。但是可用度统计是在collector上进行的，所以可能会对统计数据有轻微影响。

因此，在集群升级过程要提高可用性，需要考虑如下几点：

一次只能升级一个进程，且在该进程重启并完全恢复进入服务状态后，才能升级下一个进程。
- 因为如果升级一个进程后，集群没有恢复到完全健康状态，有的partition还只有一主一备，这时再kill一个replica server的话，很可能进入只有一主的状态，无法提供写服务。
- 另外，等待集群所有partition都恢复三备份后再继续升级下一个进程，也能有效降低数据丢失的风险。
尽量主动迁移replica，而不是被动迁移replica，避免failure detection的时间延迟影响可用度。
- 被动迁移需要等待failure detection来感知节点失联，而主动迁移就是在kill掉replica server之前，先将这个进程服务的primary replica都迁移到其他节点上，这个reconfiguration过程是很快的，基本1秒以内完成。
- 更进一步，还可以在kill掉replica server之前，将这个进程服务的secondary replica手动降级，将reconfiguration过程由“写失败被动触发”变为“主动触发”，也能降低对可用度的影响。
尽量减少进程重启时恢复过程的工作量，缩短进程重启时间。
- replica server在重启时需要replay log来恢复数据。如果直接kill掉，需要replay的数据量可能很大。但是如果在kill之前，先主动触发memtable的flush操作，让内存数据先落地，在重启时需要replay的数据量就会大大减少，重启时间会缩短很多，而整个集群升级所需的时间也能大大缩短。
尽量减少不必要的节点间数据拷贝，避免因为增加CPU/网络/IO负载影响可用度。
- replica server挂掉后，部分partition进入一主一备的状态。如果meta server立即在其他replica server上补充备份，会带来大量的跨节点数据拷贝，增加CPU/网络/IO负载压力，影响集群稳定性。Pegasus解决这个问题的办法是，允许在一段时间内维持一主一备状态，给原来的replica server进行恢复的机会。如果长时间没有恢复，才会在新的replica server上补充备份。这样兼顾了数据的安全性和集群的稳定性。可以通过配置参数replica_assign_delay_ms_for_dropouts控制等待时间，默认为10分钟。

升级流程

高可用升级

根据以上对高可用度的考虑，我们建议完善的升级流程如下：

准备好新的Server程序包和配置文件
使用shell工具将集群的meta level设置为steady，关闭负载均衡功能，避免不必要的replica迁移
```
>>> set_meta_level steady
```
升级replica server进程，采用逐个升级的策略。升级单个replica server：
- 通过shell向meta server发送远程命令，禁掉add_secondary操作：
```
>>> remote_command -t meta-server meta.lb.add_secondary_max_count_for_one_node 0
```
- 通过migrate_node命令，将replica server上的primary replica都迁走：
```
$ ./run.sh migrate_node -c $meta_list -n $node -t run
```
  通过shell的nodes -d命令查看该节点的服务replica情况，等待primary replica的个数变为0；如果长时间不变为0，重新执行上面命令。
- 通过downgrade_node命令，将replica server上的secondary replica都降级为INACTIVE：
```
$ ./run.sh downgrade_node -c $meta_list -n $node -t run
```
  通过shell的nodes -d命令查看该节点的服务replica情况，等待secondary replica的个数变为0；如果长时间不变为0，重新执行上面命令。
- 通过shell向replica server发送远程命令，将所有replica都关闭，以触发flush操作，将数据都落地：
```
>>> remote_command -l $node replica.kill_partition
```
  等待大约1分钟，让数据完成落地。
- 通过shell向meta server发送远程命令，开启add_secondary操作：
```
>>> remote_command -t meta-server meta.lb.add_secondary_max_count_for_one_node 100
```
- 替换程序包和配置文件
- 重启meta server进程
- 使用shell的ls -d命令查看集群状态，等待所有partition都完全恢复健康
- 继续升级下一个replica server
升级meta server进程，采用逐个升级的策略。升级单个meta server：
- kill掉meta server进程
- 替换程序包和配置文件
- 重启meta server进程
- 等待30秒以上，保证meta server与replica server心跳的连续性
- 继续升级下一个meta server
升级collector进程：
- kill掉collector进程
- 替换程序包和配置文件
- 重启collector进程

简化版升级

如果对可用性要求没那么高，升级流程可简化如下：

准备好新的Server程序包和配置文件
使用shell工具将集群的meta level设置为steady，关闭负载均衡功能，避免不必要的replica迁移
```
>>> set_meta_level steady
```
升级replica server进程，采用逐个升级的策略。升级单个replica server：
- kill掉replica server进程
- 替换程序包和配置文件
- 重启replica server进程
- 使用shell的ls -d命令查看集群状态，等待所有partition都完全恢复健康
- 继续升级下一个replica server
升级meta server进程，采用逐个升级的策略。升级单个meta server：
- kill掉meta server进程
- 替换程序包和配置文件
- 重启meta server进程
- 等待30秒以上，保证meta server与replica server心跳的连续性
- 继续升级下一个meta server
升级collector进程：
- kill掉collector进程
- 替换程序包和配置文件
- 重启collector进程

升级脚本

我们提供了集群升级脚本scripts/pegasus_rolling_update.sh。该脚本采用高可用升级流程，用于小米内部的集群升级。

不过这个脚本并不能直接使用，因为其依赖minos部署工具来完成以下事情：

获取集群的进程列表
自动部署更新程序包和配置文件，并重启进程

你可以修改该脚本，针对你们自己的部署系统，修改以上通过minos完成的部分，使其可以正常工作。如需帮助，请联系我们。