一、升级前准备

1.1 备份数据库

升级数据库的过程，每一步都需要严格把控，涉及到底层物理存储的变更，容易出现升级后数据库启动失败，或者是升级后数据错乱的风险。所以第一步要做的就是：备份！！
说到备份，可以说是很多DBA的心声，也经常看到没有备份导致公司损失严重的情况。毕竟数据即财产，不完善的保管，丢失了，可就损失重大。
升级后，由于数据的存储结构可能会发生变化，所以除了基本的物理备份（简单理解为复制数据库的物理文件）外，必须要做逻辑备份。逻辑备份为SQL的形式，导出的数据更加的直观可控。并且，需要在测试环境验证备份文件的有效性（例如可尝试在测试环境进行恢复验证）。
（备份的详细介绍会在后续篇章中介绍）

1.2 流程

在测试环境中，按照升级的流程老老实实走一遍。包括备份、升级、恢复、验证数据等。
（1）在原实例升级
部分场景：例如成本控制，又或者是一些小的项目，没有条件部署新的数据库实例，则需要在原实例下进行升级。这个时候就一定要注意备份，防止进退两难！！

（2）在新实例升级
新建一个新版本的数据库实例，把备份文件还原到新的实例中。物理备份的还原很快，相当于是替换了新的数据库实例的数据文件，但是存在数据物理结构不兼容的风险。逻辑恢复很慢，需要把SQL文件一条条执行结束。而且MySQL的还原是单线程的，所以不支持原生的多线程还原。
当然，可以进行一些“类并发”。我们在备份的时候，将没有关联关系的库表按照大小，可以备份为多个文件进行备份，这样，在恢复的时候，我们就可以多个文件一起执行回放，以达到并发恢复的效果。

（3）新建从库
最常用的方式。生产环境的很多应用，都是不能停机的，没有对应的维护时间段给DBA。这个时候，我们需要采取更为平滑的升级方式。
“创建从库”：
即在已有的实例上，新建一个从库，并且保持实时同步。待数据完成同步，延迟降到预测范围内时，应用可以选择在低峰的时段进行逐台切换，业务切换到新的实例上无误，即为升级成功。
（由于此方法较为常用，对于此种方式进行升级的过程，会在后续篇章中介绍）

1.3 测试

不管是上部分说到的任何一个步骤，在升级之前都需要做好测试，考虑可能发生的情况，并且作出相应的解决方案。数据库在底层，很有可能牵一发而动全身，所以任何步骤的测试，都不能松懈。

二、验证

2.1 数据验证

数据同步后，需要验证源端、目标端的数据是否一致。此时，可以自己通过脚本，或者工具（例如mysqldbcompare）进行。对于部分云厂商的工具，例如AWS的DMS（数据迁移服务），其提供了数据校验的功能，也可以作为迁移验证数据的参考。

2.2 应用切换验证

**（1）审计日志: **

对于是否切换成功，可以查看源端和目标端的审计日志。切换后：源端子啊一段时间内没有对应应用的审计日志，当然目标端会新增这个应用的审计日志。

（2）慢查询日志：
在没有开启审计日志的环境，可以使用慢查询日志进行判断，适当调低慢查询的阈值（ long_query_time， https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_long_query_time），从而根据日志判断。

（3）Processlist：
可以通过执行：
show processlist;（或者查询information_schema.processlist， https://dev.mysql.com/doc/refman/8.0/en/processlist-table.html）查看应用的连接情况。

1
2
        总之，数据迁移是一个很重要的过程，需规划严格的流程，并制定回滚方案。对于数据库系统，若能够满足业务需求，都是尽量不动，我曾看到过uptime为10+年的数据库系统，不得不佩服开发人员和产品对于该产品的把控程度。

欢迎关注公众号：朔的话：