aws RDS 版本升级最佳实践的探讨

这篇文章其实在草稿箱中存在了挺长的一段时间，去年10月就已经开始写了，但是由于工作上的其他事情的干扰，一直还没写完。所以你可以看到我画的图中，now其实是指2018年10月（OCT）。趁着过年休假，把这个文章终于写完了。

aws rds被强制升级是个无奈的事情，版本不支持，而被强制升级会影响业务可用性。与其被动强制升级，不如制定主动升级战略。

1. aws RDS 的升级周期说明：
根据亚马逊的文档 Amazon RDS FAQs上的说明，aws RDS的大版本，至少能支持3年，小版本至少会支持1年。

根据和aws的交流得知，一般社区基本版本发布约5个月之后，aws会发布基于aws的RDS。

因此，aws的RDS升级周期是，待社区版本发布后，约5个月，aws发布对应的版本，每个大版本至少支持3年，每个小版本至少支持1年。

2. aws RDS的版本过期的后果：
根据亚马逊的文档 Amazon RDS FAQs上的说明，当某个大版本或者小版本，过了亚马逊的服务支持期，亚马逊会提前提醒客户（大版本提前6个月提醒，小版本提前3个月提醒），在提醒期过后，aws会强制自动升级数据库到最新的版本（即使客户选择的是关闭了自动小版本升级）。升级的过程，应用程序无法连接数据库，造成业务影响。

注1：无论大版本，还是小版本，一旦过了亚马逊的服务支持期，都会面临强制升级的过程。
注2：小版本的升级过程，会包含备份，升级，再次备份。经验值是第一次备份和最后一次备份，不影响业务正常访问，升级数据库的过程，影响业务正常访问。整个升级的过程，大约30分钟，其中影响业务访问的时间为3分半钟。但具体的业务影响时间，以实际测试为准。
注3：小版本在提醒期的deadline来之前的一周，已经不能对数据库做任何modify的操作，包括搭建replica或者更改维护窗口。但是可以从备份的snapshot还原出来一个数据库，用于测试升级的时长。
注4：小版本升级步骤是先升级从库，再升级主库。

3. 内部升级步骤解析：

即：
a). 在升级前，做一次快照，注意这个快照的时间，和数据库的大小的有关。 b). 进行slow shutdown，即set global innodb_fast_shutdown=0然后进行shutdown。由于设置了slow shutdown，因此dirty buffer会刷到磁盘上+insert buffer 也会刷到磁盘上（即system tablespace，ibdata1中）+full purge（即清理无用的undo页） c). 将mysql挂载到新的存储引擎下，并且禁止远程网络访问； d). 运行mysql_upgrade程序，升级数据字典。 e). 运行RDS特殊的一些脚本，以便升级RDS封装的表和存储过程。 f). 重启实例，开放网络远程连接。

注1，在某些情况下，mysql_upgrade这个步骤会物理的重建表，表的大小会影响升级时间，所以实际升级的时间，需要以测试为准。如 MySQL 5.6.4 升级到5.7版本，因为 5.6.4 版本中的TIME, DATETIME, 和TIMESTAMP类型的存储有改变，升级的时候，需要重建表。
注2，由于大版本不能跨大版本升级，如升级MySQL 5.5.46到5.7.19，不能直接升级，需要先将5.5.46升级到5.6，如5.6.37，再升级到5.7.19。因此业务受影响的时间，是两次升级的时间。而不是一次。故不做大版本的交替升级。如分成5.5 升级 5.7，5.4升级5.6。

4.版本发布路线图：
根据社区发布的版本时间，和aws已经发布的版本的时间，我们可以作出下面的发布路线图。
MySQL：

Postgresql：

注1，最开始的浅绿色表示社区版第一版的发布时间，后面的灰色，表示社区版基于第一版之后的小版本GA的时间，而其对应的aws发布的版本是彩色的。
注2，通常情况，aws小版本至少支持一年（即12个月），但是有些小版本，aws已经支持超过了12个月，有可能会随时终止支持，所以我画到了截止当前时间（2018年10月），后面的时间没有继续画。（即没有画的不表示不支持，只是表示aws版本发布超过了12个月，在此之后可能会被终止支持而强制下线）

5.升级最佳实践：
5.1. 大版本升级：
a). 先创建2个replica实例； b). 升级其中一个实例到高版本，此时，还保持着主从的同步关系； c) .创建dms实例，配置好源和目标的endpoint，和创建好task，注意创建task时选择changes only，并且取消 Start task on create的勾勾。 d). 业务中断开始，将新建的replica实例提升为主库； d). 点击dms的task中的start ，等待其完成全量数据库的对比，开始准备同步增量数据； e). 切换应用连接到高版本的数据库；

注1，从5.6.4以下的版本升级到5.6.4之后，需要alter table table_name force，重建表，才能使用online ddl的方式create index。
注2，大版本升级，需要验证应用程序的性能，需要抓取至少一周的SQL，进行sql replay看性能的变化。
注3，升级之后，为了减少物理读，尽快的将更多的数据加载到内存，可以用mysqldump做prewarm
注4，减少downtime，其中一个步骤是dms点击task的start进行全量数据的校对，如果加大主库的IOPS，有助于提高该步骤的速度。（该步骤是业务停机操作的，因此减少该步骤的时间，等于减少停业务时间）。

aws mysql major version upgrade best practise.pdf

5.2. 小版本升级：
方法一： a). 先创建replica实例，或直接使用现有的replica实例； b). 升级replica实例到高版本，此时，还保持着主从的同步关系； c). 业务中断开始，将高版本的replica实例提升为主库； d). 切换应用连接到高版本的数据库。应用的连接串配置，可以提前配置好，重启应用即可；

aws mysql minor version upgrade best practise.pdf

方法二： a). 先升级replica实例到高版本，这是所有aws升级到必要前提，即必须先升级从库； b). 中断业务和数据库之间的连接，开始升级主库； c). 将主库升级到高版本； d). 恢复应用连接；

aws mysql minor version upgrade best practise_2.pdf

注1，方法一是aws推荐的方案，但是方案二，对于小系统也是非常合适的。
注2，方法一的应用影响时间，是提升从库为主库的时间+应用重启的时间。根据我们的某个数据库的测试，提升的时间，大约是3分钟02秒。加上应用重启时间，也大约是3分半钟。
注3，方法二，我们的某个数据库测试数据是，整体的升级时间大约是34分钟（因为包含了升级前数据库做backup和升级完成后做backup，这都是升级过程中，aws自己做的），而这34分钟，并不是应用都不可用，在做数据库backup时，数据库还是可以用的，真正业务不能连数据库的时间，是3分32秒。
注4，两个方法，服务不可用的时间都差不多，都是大约3分半钟。但是方法一有个风险，就是如果是因为需要强制升级小版本，已经快到升级的维护时间，且已经是deadline的维护时间，那么虽然我们没有去动主库，但万一失败需要切换回主库，而强制升级的时间又到了，触发强制升级，那么此时就是一个不可控的状态了。因此我们还是选择了方法二。
注5，最终应该选择哪个方法，还是要依赖实际做升级测试的演练情况而定。

6.总结：
因此，我们可以制定如下的主动升级战略：

(1). 禁止所有的小版本自动升级；

(2). 根据上面的所述，规定今后MySQL的新安装版本的为5.7.23；

(3). 在一年内，对于之前MySQL 5.5版本，小版本统一过渡到5.5.61，MySQL 5.6版本，小版本统一过渡到5.6.41。这个可以避免MySQL的小版本因为不被支持导致强制升级，并且这2个版本的下一次强制升级时间，至少是在2019年9月之后。（pg类似指导思路）；

(4). 在一年内，对于之前的MySQL 5.5版本升级到5.6版本；在两年内，对于MySQL 5.6版本，升级到5.7版本；在两到三年内，统一到MySQL 8.0版本。解决由于多版本共存，导致运维难度增加的问题。（pg类似指导思路）；

(5). 后续的版本升级，将会按照1年一升小版本，3年一升大版本的进度推进，以符合aws RDS的版本支持规则。

注：2022年更新，新方法升级，影响时间更短（约2秒）：