MySQL高可用方案升级规划

我们目前有新系统和老系统，老系统因为历史原因使用的是MySQL 5.5版本，新系统有了整体的规划，使用的是MySQL 5.7版本。

在数据库高可用方案上也有多种不同的组合：

• LVS+keepalived+MHA+VIP
• MHA+VIP
• MHA+consul
• 异步主从
• 单实例

环境类型有多种：

• 线上环境
• 预发布环境
• 测试环境

现在面对这些环境，需要整体规划一下高可用方案的升级策略。

当然整体的方向是不变的，即从5.5版本升级到5.7版本，原本使用VIP的模式需要升级为DNS,原本的主从模式需要升级为高可用模式。

对于这件事情，一方面为了保证进度，另一方面保证可行性。我们决定从测试环境开始入手。

大家对于测试环境相对是比较开放的，至少权限上不会有那么多的限制，对于性能也不会有硬性需求。 新方案的落地，我们需要一个迭代的过程，即通过测试环境的整合来让开发同学对于DNS方案有一个直观的认识和熟悉的过程，整体来说，需要做以下的几件事情。

1）原本的测试环境需要做整合，单机多实例的环境需要整合的更加精简，比如原本是一台机器10个实例，我们需要整合为5个实例，类似这样的意思。

2）对于5.5版本升级，我们可以直接逻辑迁移数据库到整合后的新版本中，这种操作的可行性相对更好一些。

3）对于应用端，可以使用DNS的方式来连接，即原来的IP端口修改为域名的方式

4）后续对于测试环境的业务对接，不再使用IP,而统一对接域名的方式

测试环境试运行一段时间之后，逐步升级5.5和5.7版本的高可用方案。

对于异步主从模式的环境，如果是5.5版本，需要和业务方进行协商，升级为5.7版本+高可用模式。 可以配置新的VIP,然后系统团队协助进行IP和VIP的在线切换，这样一来应用端就无须修改IP，而直接使用VIP的方式。

如果是业务优先级不高的环境，可以直接采用升级5.5至5.7，升级高可用+DNS的模式。

对于数据量较大的5.5版本，可以考虑通过跨版本的级联从库来完成。

而对于5.7版本，其实需要做高可用方案的进一步升级，如果说MHA是1.0版本，那么基于DNS的方案就是2.0，而基于MGR的方案则是3.0

所以对于测试环境来说，需要先行测试MGR+consul的组合方案，找一个业务方来寻找落地的场景。 因为MGR一主一从是可行的，所以我们可以对原来的方案做到更加简化的高可用切换处理。

在高可用面前，时间是最好的说明，如果一个高可用方案经过了大量的时间验证，那么本身是有很高的说服力的。而对于业务来说，能够把数据库底层的依赖屏蔽掉，那么我们完全可以在工作时间完成数据库的版本升级，而对业务的影响降到最低。

以上仅仅是高可用方案的一些基本雏形，而要做到业务层的更高需求的高可用，则需要考虑机房多活的设计方案，而其中基于分布式的方案是必备的基础，今年会投入较多的精力在这个方面。