提到 MySQL 这个数据库软件，相信大家再熟悉不过了，不论是市场流行度还是占有率一直一来都非常靠前。
那再提到 MySQL 5.7 这个具体的版本，大家是不是也同样感到非常熟悉？
相信不少个人或者团队的生产环境所用的 MySQL 数据库也曾经是 5.7 这一版。
然而大家也知道，MySQL 5.7这个版本在大半年前就已经EOL（End of Life）了，也就是说 MySQL 5.7 版本已经达到终止生命周期状态。
MySQL 系列发布及EOL时间 图源：Oracle
当然，这里的终止并不是说这个版本不能用了，而是说这个版本自EOL之后，就不会再有来自社区官方的更新或者说补丁升级了。
这其实就和之前所谓的CentOS停止维护有点像，产品一旦EOL之后，不仅功能性bug没人修复，而且后续可能会出现的安全漏洞也没人管了。
虽然产品本身当然还可以接着用，但是产品后续的兼容性、安全性、稳定性方面都是潜在问题，最起码生产环境里没人敢用了。
那 MySQL 5.7 版本EOL之后，后续该用什么版本呢？
没错，不少企业或者团队开始向 MySQL 8.0 版本进行迁移。
比如不少云服务在 MySQL 这块默认也是给勾选的 8.0 版了。
除此之外，这里还有一个把数据库从MySQL 5.7迁移到 MySQL 8.0的实际公司案例，这个公司就是GitHub。
之前，GitHub 团队曾在官博中分享了他们将 GitHub 的底层数据库从 MySQL 5.7 无缝升级到 MySQL 8.0 的实践经验，我们正好可以借这个实际案例来看一看他们是怎么迁移的。
众做周知，GitHub发展至今，其数据量不是一个小数目。根据官博的介绍，GitHub 正是使用的 MySQL 来存储大量的关系型数据。
这里我们也可以来盘点一下 GitHub 现有的 MySQL 基础设施部署情况：
-
系统包含1200多台主机，其中包括数据中心内的Azure虚拟机和裸机主机。
-
存储超 300+TB 的数据，并在50多个数据库集群上提供550万次查询/秒的服务。
-
每个集群都配置了高可用，采用了主备集群配置。
-
采用了数据分区，利用水平分片和垂直分片来扩展MySQL集群，以及使用特定的MySQL集群来为特定产品领域存储数据。除此之外，还设置有水平分片的Vitess集群来服务于特定的领域。
-
具备庞大的工具生态系统，包括像 Percona Toolkit、gh-ost、orchestrator、freno 以及相关的内部自动化工具。
所有这些加在一起，就构成了一个庞大且复杂的数据库系统。
而对这样一个系统进行版本升级，并且还要保证系统平稳，不影响后台数据以及网站提供的服务，所以其难度可想而知了。
GitHub团队表示，为了升级到MySQL 8.0，升级准备工作其实早在2022年7月就开始了，团队前前后后搞了一年多才完成。
所以在正式的迁移工作之前，GitHub 团队做了三个方面的工作，包括：
1、准备升级所需的基础设施
首先需要为MySQL 8.0确定适当的默认值，并执行一些基准性能测试。
另外由于需要操作新老两个版本的 MySQL，其内部所用的工具和自动化设施需要能够支持处理两个混合版本，并了解5.7和8.0之间新的、不同的或者已经弃用的语法。
2、确保软件的兼容性
这一步主要是利用CI系统来完成。
通过借助CI系统来检测各种错误和不兼容性，以帮助他们来移除任何不支持的配置或功能。
团队将MySQL 8.0添加到所有使用MySQL应用程序的CI系统中，并在CI系统中并行运行MySQL 5.7和8.0两个版本，以确保在后续漫长的升级过程中不会出现问题。
3、团队沟通和透明度
为了准备这次MySQL版本升级计划，其团队使用GitHub Projects创建了一个升级日历，以便内部沟通和跟踪具体的升级计划。
同时其也为软件团队和数据库团队创建了跟踪清单的问题模板，以便于协调升级。
具体的项目看板类似于下图，以便于跟踪问题。
而实际的升级过程中，团队则采用的是渐进的升级策略，以满足在升级过程中所需要的 checkpoint 和回滚需求。
具体步骤如下：
Step 1、滚动副本升级
从单个副本开始，逐步监控并升级，然后放入生产流量同时观察各项指标，最终逐渐将MySQL 8.0的副本上线，直至升级到整个数据中心。
下图展示了每个数据中心DC内的副本升级策略。
Step 2、备份拓扑升级
一旦所有只读流量都通过 MySQL 8.0 副本来提供服务，团队则调整复制拓扑为如下逻辑：
-
一个8.0主系统被配置为直接从当前5.7主系统下来进行复制
-
在该8.0副本的下游创建两条复制链
-
一组只有5.7副本（不提供流量，但可以用于回滚）
-
一组只有8.0的副本（服务流量）
-
在进行下一步骤之前，这种拓扑只会在很短的一段时间内（最多几个小时）处于这种状态。
Step 3、将 MySQL 8.0 主机升级为主用
这一步也采取了一种谨慎的升级策略，通过先提升一个8.0版本的副本为新的主用库，来逐步进行数据库的升级，并确保在升级过程中有足够的回滚能力和服务能力。
Step 4、内部实例类型升级
由于内部还存在用于备份或非生产性的辅助数据库服务器，为保持一致性，这些辅助机器也进行了版本升级。
Step 5、清理工作
最后一步就是清理工作。
即在确认集群不需要回滚，并且已经成功升级到8.0版本之后，这时候就可以删除老的5.7服务器了。
同时验证工作需要包括至少一个完整的24小时流量周期，以确保后续不会出现问题。
所以从上述内容可以看出，不管是升级之前所做的准备工作，还是具体升级所制定的计划，GitHub都做了大量备份、冗余、验证的工作，从而保证系统能够顺利切换至新版本机器。
对于一个公司或者团队来说，数据库都是一个非常重要且关键的组件，因此涉及数据库相关的升级或者迁移，企业和团队都会比较慎重，毕竟会涉及到数据安全和业务稳定。
从上面GitHub迁移MySQL版本的实际案例中多少也能隐约感受到，MySQL旧版本逐渐开始退场，全面拥抱MySQL新版的阶段或许也已经正在路上了。