当需要升级server版本或者修改config配置时,都需要对集群进行升级。对于分布式集群来说,常用的升级方法就是滚动升级(Rolling-Update),即不停止服务,对一台一台server逐个进行升级。
集群升级的重要目标在于平稳,即不停服,并且对可用性的影响降至最低。为了达到这个目标,我们先看看在升级过程中哪些地方可能会影响可用性:
fd_grace_seconds
,通常配置为10秒,即最多需要经过10秒,meta server才能知道replica server挂了,然后重新分派新的primary replica。reconfiguration
阶段后变成一主一备,继续提供写服务。在切换过程中尚未完成的写操作,即使有reconciliation
阶段重新执行,但客户端那边大概率已经超时了,对可用性有一定影响。但是这个影响相对小些,因为reconfiguration
的速度是比较快的,通常在1秒以内就能完成。因此,在集群升级过程要提高可用性,需要考虑如下几点:
reconfiguration
过程是很快的,基本1秒以内完成。reconfiguration
过程由“写失败被动触发”变为“主动触发”,也能降低对可用度的影响。replica_assign_delay_ms_for_dropouts
控制等待时间,默认为10分钟。根据以上对高可用度的考虑,我们建议完善的升级流程如下:
>>> set_meta_level steady
add_secondary
操作:>>> remote_command -t meta-server meta.lb.add_secondary_max_count_for_one_node 0
$ ./run.sh migrate_node -c $meta_list -n $node -t run通过shell的
nodes -d
命令查看该节点的服务replica情况,等待primary replica的个数变为0;如果长时间不变为0,重新执行上面命令。$ ./run.sh downgrade_node -c $meta_list -n $node -t run通过shell的
nodes -d
命令查看该节点的服务replica情况,等待secondary replica的个数变为0;如果长时间不变为0,重新执行上面命令。>>> remote_command -l $node replica.kill_partition等待大约1分钟,让数据完成落地。
add_secondary
操作:>>> remote_command -t meta-server meta.lb.add_secondary_max_count_for_one_node 100
ls -d
命令查看集群状态,等待所有partition都完全恢复健康如果对可用性要求没那么高,升级流程可简化如下:
>>> set_meta_level steady
ls -d
命令查看集群状态,等待所有partition都完全恢复健康我们提供了集群升级脚本scripts/pegasus_rolling_update.sh。该脚本采用高可用升级流程,用于小米内部的集群升级。
不过这个脚本并不能直接使用,因为其依赖minos部署工具来完成以下事情:
你可以修改该脚本,针对你们自己的部署系统,修改以上通过minos完成的部分,使其可以正常工作。如需帮助,请联系我们。