本文首发于2018年。
作者：游愚，蚂蚁金服OceanBase DBA团队高级运维工程师，2016年加入OceanBase DBA团队，从事OceanBase数据库运维与运维系统建设工作。
OceanBase 2.0在性能，成本和可用性上带来了一系列的新特性，而对于数据库的一线运维人员，或许对可运维性和运维风险这两方面更加关心。面对OceanBase 2.0新版本的美好特性，运维人员如何安全无风险的对OceanBase数据库进行升级？如何防止升级引入新问题对生产系统造成故障?
OceanBase（以下简称为OB）作为一款金融场景的分布式数据库，升级必须能做到平滑，可灰度，可回滚，为业务提供24小时不间断的服务。得益于分布式架构，一个OB数据库实例由多个可用区（zone）同时提供服务（通常为3个或5个）。
在数据库升级过程中，OceanBase 2.0版本支持不同的可用区使用新旧两个数据库版本同时提供服务，新旧版本可互相兼容。多个可用区可以轮转升级，做到升级过程对应用透明无感知，可运维性大大提升。
轮转升级
OceanBase 2.0集群升级可采用多个可用区轮转升级的方式，也就是对可用区逐一进行升级。升级某个可用区前，首先将该可用区置为停止服务。此时副本的主将自动切换到其他可用区, 该可用区的数据副本将不承担业务读写流量。此时对该可用区下的OB进程进行升级和重启操作，不会影响到应用的db读写。待该可用区升级完成后，重新将其置为提供服务状态。此时该可用区将重新承担业务流量。之后以此过程再依次升级剩余可用区。整个升级过程应用无感知，应用无需配合db端做任何的停写停服务操作。
灰度切流验证
对升级较敏感的核心业务，OceanBase 2.0版本提供了灰度切流验证新版本的能力。灰度切流是指将业务流量按百分比逐步切换到新版本上。OceanBase允许用户数据的多个副本使用新旧两个OB版本。运维人员进行数据库升级时（例如从OceanBase 1.0升级到2.0），可以选择OB集群中的一部分可用区升级到新版本，之后将主副本逐步切换到新版本的可用区上，以验证新版本OB的功能和性能。一旦发现问题，可以立即回切到旧版本的可用区。保证应用持续可用，升级安全可靠。
除此之外，OceanBase 2.0的DB Replay功能也可以用于新版本的验证，运维人员可以搭建新版本的OB集群并将旧版本OB的读写流量回放到新版本的测试集群上，提前验证新版本。大大降低了运维人员做数据库升级的风险，这个功能我们也会在后续的文章中深入讲解。
新旧版本兼容
为了保证同一个OB集群可以新旧多个版本同时运行，OceanBase 2.0在内部实现上保证新旧版本的兼容和可回退。同时兼容了OceanBase 1.0的协议与数据格式，从1.0到2.0版本的升级同样也能做到如小版本升级一样平滑。新版本如果对RPC行为进行了修改，如何与旧版本的OB进行通信呢? 实际上OB新版本会保留旧版本的RPC行为。可以通过集群内部的版本号参数来控制OB使用哪个版本的RPC行为。当OB集群的所有可用区都升级到新版本后，将版本号设为新版本，此时才使用新RPC行为进行通信。
升级回滚
与1.0相比，OceanBase 2.0同时也允许将集群的版本回退到升级前的版本。运维人员只需按照和升级流程相同的方式将OB集群的多个可用区轮转降级到原版本即可。回退过程同样对应用透明。那么如果新版本的数据存储格式发生了变化，如何回退版本呢？对于这种情况，集群同样有内部参数控制存储是使用新数据格式还是旧数据格式。若要回退到旧数据格式，运维人员需要修改参数并进行一次全量合并。当存储数据回退到旧数据格式后，才可以继续做版本回退。
平台支持
OceanBase云管控平台（简称OCP）提供了对OceanBase 2.0集群一键升级的能力，支持全集群升级和集群部分可用区升级。流程包括了升级的预检查和后检查，可用区轮转升级，集群参数升级，内部表修改等升级步骤。运维人员无需黑屏操作，一键即可完成对一个集群的升级操作，大大提升了一线运维人员的幸福感。
