AWSRDS强制升级的应对之道——版本升级的最佳实践

AWS RDS被强制升级是个无奈的事情，版本不支持，而被强制升级会影响业务可用性。与其被动强制升级，不如制定主动升级战略。本文给大家介绍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

下载链接：https://oracleblog.org/working-case/aws-rds-upgrade-best-practise/

5.2. 小版本升级：

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

aws mysql minor version upgrade best practise.pdf

下载链接：https://oracleblog.org/working-case/aws-rds-upgrade-best-practise/

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

aws mysql minor version upgrade best practise_2.pdf

下载链接：https://oracleblog.org/working-case/aws-rds-upgrade-best-practise/

• 注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的版本支持规则。

作者：何剑敏，某无人机公司运维部，数据库架构师，负责公司云上和云下数据库的架构、规划和运维，专注于整体运维的思路，发挥平台效应，实现云上和云下数据库的统一运维。