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

趁着休假，把这个文章终于写完了。

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.升级路线：

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，有助于提高该步骤的速度。(该步骤是业务停机操作的，因此减少该步骤的时间，等于减少停业务时间)。

5.2. 小版本升级：

方法一：

a). 先创建replica实例，或直接使用现有的replica实例；

b). 升级replica实例到高版本，此时，还保持着主从的同步关系；

c). 业务中断开始，将高版本的replica实例提升为主库；

d). 切换应用连接到高版本的数据库。应用的连接串配置，可以提前配置好，重启应用即可；

方法二：

a). 先升级replica实例到高版本，这是所有aws升级到必要前提，即必须先升级从库；

b). 中断业务和数据库之间的连接，开始升级主库；

c). 将主库升级到高版本；

d). 恢复应用连接；

注1，方法一是aws推荐的方案，但是方案二，对于小系统也是非常合适的。

注2，方法一的应用影响时间，是提升从库为主库的时间+应用重启的时间。根据我们的某个数据库的测试，提升的时间，大约是3分钟02秒。加上应用重启时间，也大约是3分半钟。

注3，方法二，我们的某个数据库测试数据是，整体的升级时间大约是34分钟(因为包含了升级前数据库做backup和升级完成后做backup，这都是升级过程中，aws自己做的)，而这34分钟，并不是应用都不可用，在做数据库backup时，数据库还是可以用的，真正业务不能连数据库的时间，是3分32秒。

注4，两个方法，服务不可用的时间都差不多，都是大约3分半钟，但是方法一有个风险，就是如果是因为需要强制升级小版本，已经快到升级的维护时间，且已经是deadline的维护时间，那么虽然我们没有去动主库，单丝玩意失败需要切换回主库，单丝强制升级的时间又到了，触发强制升级，那么此时就是一个不可控的状态了。因此我们还是选择了方法二。

注5，最终应该选择哪个方法，还是要依赖实际做升级测试的演练情况而定。

6.总结：

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

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

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

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