我们目前有新系统和老系统,老系统因为历史原因使用的是MySQL 5.5版本,新系统有了整体的规划,使用的是MySQL 5.7版本。
在数据库高可用方案上也有多种不同的组合:
环境类型有多种:
现在面对这些环境,需要整体规划一下高可用方案的升级策略。
当然整体的方向是不变的,即从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一主一从是可行的,所以我们可以对原来的方案做到更加简化的高可用切换处理。
在高可用面前,时间是最好的说明,如果一个高可用方案经过了大量的时间验证,那么本身是有很高的说服力的。而对于业务来说,能够把数据库底层的依赖屏蔽掉,那么我们完全可以在工作时间完成数据库的版本升级,而对业务的影响降到最低。
以上仅仅是高可用方案的一些基本雏形,而要做到业务层的更高需求的高可用,则需要考虑机房多活的设计方案,而其中基于分布式的方案是必备的基础,今年会投入较多的精力在这个方面。