背景
数据库的可用性对于客户是至关重要的，根据CAP理论，分布式和一致性、可用性只能二选一，所以在云原生数据库（依赖多副本）或者分布式TP系统中，大多都选择牺牲一些一致性来保证分布式和可用性，足以看出可用性的地位是及其重要的，所以任何数据库内核都会针对可用性做很多特性改进，比如热备、双活多活、异地灾备、增强一致性协议和主从复制能力、甚至增强备份恢复能力等等。
我们了解，影响可用性的无外乎几种场景，如严重的HANG、CRASH和功能的BUGs导致的不可用，数据库的运维升级、数据库相关依赖的基础组件BUGs或者升级，硬件故障或者硬件升级，灾难恢复时间长，主备切换时间长，备份恢复时间长等等。本文重点要说的是针对升级造成的不可用的原因、背后的原理以及采取的策略。升级之所以重要的原因是因为，客户通常由于碰到严重BUGs问题不可用后，不得不升级数据库版本导致的二次不可用。虽然可以在主动运维时间去升级，但是他们仍旧希望降低该时间或者能够了解升级黑盒背后的故事。因此，解决缩短升级时间也是数据库内核非常重要的技术方向。
商业数据库DB2架构和Rolling Update升级策略
说到升级技术和方案，那不得不依赖于各个数据库内核的原理和技术架构。比如这里先来说下DB2的purescale和PolarDB MySQL的架构来更好的理解他们之间的差异。这两个数据库都是共享存储，DB2 purescale目前支持行级多写架构。
在DB2 purescale的架构下，如何升级的呢。假如两个member节点的rolling update如何做？两个Member从GA生成到FP1上。
可以看到DB2的计算节点是可以支持两个版本同时存在，顺利在不影响客户应用的情况下，达到逐步升级的过程。
AWS RDS升级策略
RDS通常是MySQL的托管服务，通常提供备节点和只读节点来进行服务。我们先来通过AWS的RDS for MySQL了解RDS的升级过程。
该过程展示了如何利用只读实例来做滚动升级。
PolarDB架构和升级策略
PolarDB也是共享存储模式，支持一写15读，多租户多写、热备已经上线，行级多写在开发中，所以这里架构和升级策略暂时还是基于一写多读的架构。
由于PolarDB MySQL 100%兼容官方MySQL，并且增加了物理复制能力，日志的物理复制技术+PolarDB中三种角色PRIMARY、REPLICA和STANDBY，那么为集群升级带来的很大的不同。下面我们就介绍下PolarDB MySQL中的热升级、冷升级和大版本升级。
我们知道对于单机MySQL或者主备MySQL模式下，采用binlog同步机制的方式进行复制，天然可以支持跨版本和跨数据源类型，因此采用AWS RDS的升级策略，只要做到管控无缝切换，客户在升级小版本和大版本时基本上可以达到闪断而降低对业务的影响。闪断这个名字也是云数据库的发明的名字，即客户端重连既可以恢复正常业务，而非一直等待实例启动才能恢复业务。
然而对于PolarDB MySQL的架构而言，采用了物理复制+共享存储和一写多读的架构，那就意味着升级过程变得比较复杂。这里有几个痛点和传统MySQL单机有不同：
-
升级中必须考虑物理复制+一写多读架构造成的升级影响，物理复制无法进行双向复制，只能由PRIMARY节点来进行写入。
-
升级策略根据MySQL的版本中是否影响元数据（DD） 、Information Schema表（IS）、Performance Schema表（PS）和Server层系统表（Server System Table）来决定是否采用闪断或者中断模式。
热升级策略
热升级策略解决同版本中的小版本升级，也就是升级过程用户应用程序只需要闪断。整个顺序是按照STANDBY-REPLICA-PRIMARY的顺序。为什么按照这个顺序？其实也很好理解，由于元数据等信息并没有改变，升级过程并不需要修改Page信息而导致必须先升级PRIMARY。
Standby:
RO:
RW:
搭建复制关系
冷升级策略
冷升级策略是由于大版本修改元数据信息、IS、PS等无法通过升级版本后，通过执行SQL的方式来同步，通过热升级会破坏物理复制机制而采取的升级策略，由于升级顺序是按照PRIMARY-REPLICA-STANDBY的顺序，因此会中断业务。冷升级由于很好理解，这里就列出步骤：
-
检查 REPLICA和STANDBY同步延迟正常
-
对于 REPLICA和STANDBY节点，停止物理复制线程
-
对于 PRIMARY节点，停止服务，替换二进制，启动后，进行系统升级，升级完成后启动检查版本和角色
-
升级所有REPLICA节点，替换二进制，启动后，查看版本和角色
-
升级STANDBY节点，替换二进制，启动后，查看版本和角色，追加物理复制
目前PolarDB MySQL的小版本为了能够让客户平滑的使用，已经不采用冷升级的方式，而从设计新功能角度已经考虑了热升级的方式。而目前的8.0.1版本（基于MySQL 8.0.13）升级到8.0.2版本（基于MySQL 8.0.18）版本，由于官方元数据等信息变化必须采取冷升级的方式。另外还有一些GDN集群的场景，升级过程也会遇到冷升级的情况。
大版本升级策略
PolarDB MySQL由于目前支持5.6版本（基于MySQL 5.6）、5.7版本（基于MySQL 5.7）和8.0.x版本（基于MySQL 8.0.x），很多新的功能在8.0.x，因此需要从5.6和5.7版本升级到最新的8.0.x版本，因此提供了一键式升级的方式。虽然是大版本升级，但是仍然能提供用户应用程序闪断的机制，通过内部的管控流程来减少用户升级带来的影响。
升级支持方式
-
PolarDB MySQL引擎5.6升级至PolarDB MySQL引擎5.7。
-
PolarDB MySQL引擎5.6升级至PolarDB MySQL引擎8.0。
-
PolarDB MySQL引擎5.7升级至PolarDB MySQL引擎8.0。
升级优势
-
可保留数据库原来的连接地址，无需修改应用程序的任何连接配置即可切换至目标版本。
-
升级完全免费。
-
升级过程数据0丢失。
-
支持增量迁移，停机时间小于10分钟。
-
支持在线热升级，升级过程仅闪断一次。
-
支持回滚操作，升级失败可以在10分钟内恢复。
和上面原地升级的方式不同，PolarDB MySQL引擎集群之间升级是免费，但需要收取新建计算节点的费用。而PolarDB MySQL引擎集群之间的升级支持带地址切换，系统会自动交换源PolarDB MySQL引擎集群和目标PolarDB MySQL引擎集群上的连接地址。
一键式大版本升级主要依赖于DTS服务和Binlog同步机制，因此可以支持更大更灵活的方式。
结论
总之，不管何种升级策略，数据库内核的目标都是要做到无论由于故障实例crash、主动运维和升级，都能够做到最小限度的影响应用，甚至通过更多的技术如热备、多写、共享内存池、高可用集群、事务保留、SCC、Voting disk等技术做到真正的云Zero Downtime。
参考链接
《Performing rolling updates in a Db2 high availability disaster recovery (HADR) environment》
《PolarDB · 新品介绍 · 深入了解阿里云新一代产品 PolarDB》
《以最短的停机时间对 Amazon Aurora MySQL 执行主要版本升级》
