前言
对于一个系统来说，进行定期的升级维护是一件比较常见的事情。但是对于复杂分布式系统的升级，系统管理员系统考虑更多的因素来做升级这个事情。同时对于分布式系统开发者来说，他们也要考虑系统升级的前后兼容性，避免升级后部分老的功能无法使用或是升级回退后之前写出的数据无法使用等等类似的情况。本文笔者来简单聊聊关于分布式系统的升级，你需要了解和注意的那些事。
分布式系统升级的状态转化
在介绍本文主要内容前，我们首先需要对分布式系统的升级有一个总的了解，了解这里面总的几个过程阶段。
在这里，我们一般会有3个阶段：
- Older Version，升级前的初始阶段。
- Pre-Finalized，升级中且并未结束的阶段。
- New Version(Finalized)，升级结束完成阶段。
在这3个阶段的状态转变过程中，需要外界来输入些action操作，来促使状态的转变，由用户来决定是否可以进入到下一个阶段了。
- 从Old Version到Pre-Finalized的action为Upgrade升级操作
- 从Pre-Finalized到New Version的action为Finalize确认操作
- 从Pre-Finalized到Old Version的action为Downgrade降级操作
上图还能表明的一点信息是在Finalized后是不能再回退到Old Version的操作了。
上述3个阶段的流程图展示如下所示：
下面我们再对里面的Upgrade和Downgrade过程具体需要注意的几点进行分析。
关于Upgrade需要注意的点
当我们替换掉系统的包从现有版本(老的版本)到一个新的版本，然后执行启动Upgrade操作。这个操作之后，其实系统就进入了一个Upgrade In-Progress的阶段。
在这个中间状态过程中，会存在以下会发生的几种情形：
- 元数据的自动备份，以方便后续可能需要的降级操作。
- 数据格式layout的转变，常见的我们会有数据存储文件格式的layout的定义，升级后如果格式发生转变，我们会对应修改layout的版本。在新老layout格式的替换中，有时我们需要进行程序自动的格式转换。
- 新版本的部分不兼容的新功能特性不应该被允许执行，因为此时升级还未完全结束，还意味着有降级的可能性。贸然允许新功能特性操作，会导致降级后的数据无法使用的情况。这里的“兼容性判断”来自于开发者给新功能特性定义的最小兼容版本号的值的设定。
- 升级过程中被执行删除的数据，应该进行trash的暂时转移而不是直接的物理删除，这是为了保护数据的安全性。
- 如果涉及比较复杂的系统，系统内还分多个字服务，还需要进行服务的依赖升级，逐个进行Upgrade。
关于Downgrade需要注意的点
上面说了关于Upgrade过程需要注意的点，那么对于Downgrade来说，我们要保证哪几点要求呢？
首先第一点，确保Downgrade后前后数据的完全一致性，这里的前指的是Downgrade操作执行前即Upgrade In-Progress的阶段。在这个In-Progress的阶段，还是有用户的请求会被系统处理到的。这里要达成的一个效果是Downgrade操作完对于用户来讲完全的透明。
其次元数据以及其layout的rollback回滚操作，退回到和之前Old Version一样的格式。
当然关于升级还有其它别的要点需要关注，类似总升级时间的限制等等，本文笔者只是取其中部分要点进行略微阐述。
引用
[1].https://issues.apache.org/jira/browse/HDFS-5535
[2].https://issues.apache.org/jira/browse/HDDS-3698