前言:
现在看官们对“mysql高可用架构方案”可能比较着重,姐妹们都需要学习一些“mysql高可用架构方案”的相关资讯。那么小编在网摘上网罗了一些关于“mysql高可用架构方案””的相关知识,希望咱们能喜欢,朋友们快快来学习一下吧!这是学习笔记的第 1898 篇文章
今天对运维系统的MySQL架构做了下升级,从单点实例升级到了MGR跨机房集群。当然目前也是一个迭代的方案,后续的架构升级还需要持续的补充,算是一个开始吧。
首先运维系统建设也有一些日子了,已经支撑了不少线上的业务,所以从原来的测试版本逐步过渡到了一个正式的线上版本,系统优先级提高了,系统的高可用就是一个需要重点考虑的问题,如果说元数据的信息丢失了,我们无法恢复,那么这个修复的代价就非常高了。
当前系统的状态如下:
目前在两个机房存在两台服务器,彼此都是独立的,分别负责了3个独立的业务方向。
现在需要对9.208所在的机房数据库做下架构升级,改造为MGR有一个硬性要求就是表需要有主键。对于xwiki业务的表因为是采用的一个开源版本,基于hibernate实现,我们无法保证这个数据库的业务逻辑中对于自增列的使用场景和hibernate的完全匹配,基本上这个业务就是最小化运维,拿来能用即可,所以就不打算投入太多精力去调研这方面的需求匹配,所以经过权衡,在不影响已有的权限和业务的情况下,把xwiki业务分离出去,使得运维系统devopsdb的业务能够直接升级到MGR架构环境下。
为了避免升级的时候,我们才开始部署MGR环境,我们需要预先搭建一套MGR环境,到时候需要导出线上数据,导入MGR环境。
准备的环境如下,尤其需要注意下图中的端口,这是我们为了保持业务连接和权限不变,对于业务使用来说能够透明一些。
线上环境升级时的架构如下,我们需要切换为MGR环境,原来环境的devopsdb数据可以备份出来就不再使用了,同时为了兼容和统一端口,119.221服务器上面的数据库需要调整端口,从4306修改为4316.
调整后的的架构改进图如下:
看起来简单的需求,为了保证兼容和统一,需要做不少的工作来承接这个相对平滑的过程,目前采用的是单主的模式,在经过了反复测试之后,和同事一起做了下升级的完整过程,算是一个好的开始。
我们把整个过程分成了18个步骤,每个步骤都做了下时间统计,供参考。
MGR切换前工作
MGR-4310修改increment_offset为3检查xwiki的数据库配置和服务配置(tomcat)从mysql-4306导出devopsdb数据导入MGR-4310,评估导入时间,查看是否有导入错误MGR-4310切换测试Shutdown mysql_9.208-4310,预期切换到119.221-4310,测试写入数据Startup mysql_9.208-4310,加入集群Shutdown mysql_119.221-4310,预期切换到mysql_9.208-4310MGR-4310端口切换测试,修改端口为4301 11:30确认是否可行梳理字典表用户,生成sql正式切换停止opsmange,xwiki服务Mysql_9.208-4306备份 mysqldump 备份devopsdbxwiki备份Shutdown Mysql-9.208-4306修改mysql-9.208-4306为mysql-9.208-4308,降低buffer_pool配置修改xwiki的数据库配置为4308,启动xwiki切换MGR-4301为MGR-4306,修改buffer_pool配置,两个节点都修改启动MGR-4306,恢复devopsdb的数据测试工单流程和cmdb的数据情况,验证升级的有效性。
整个过程还是比较紧凑的,中间碰到了不少的实战问题,在有限的时间内推动完成还是挺不容易的。
标签: #mysql高可用架构方案