<返回更多

运维系统数据库升级到MGR小结

2021-04-12    杨建荣的学习笔记
加入收藏

今天对运维系统的MySQL架构做了下升级,从单点实例升级到了MGR跨机房集群。当然目前也是一个迭代的方案,后续的架构升级还需要持续的补充,算是一个开始吧。

首先运维系统建设也有一些日子了,已经支撑了不少线上的业务,所以从原来的测试版本逐步过渡到了一个正式的线上版本,系统优先级提高了,系统的高可用就是一个需要重点考虑的问题,如果说元数据的信息丢失了,我们无法恢复,那么这个修复的代价就非常高了。

当前系统的状态如下:

目前在两个机房存在两台服务器,彼此都是独立的,分别负责了3个独立的业务方向。

运维系统数据库升级到MGR小结

 

现在需要对9.208所在的机房数据库做下架构升级,改造为MGR有一个硬性要求就是表需要有主键。对于xwiki业务的表因为是采用的一个开源版本,基于hibernate实现,我们无法保证这个数据库的业务逻辑中对于自增列的使用场景和hibernate的完全匹配,基本上这个业务就是最小化运维,拿来能用即可,所以就不打算投入太多精力去调研这方面的需求匹配,所以经过权衡,在不影响已有的权限和业务的情况下,把xwiki业务分离出去,使得运维系统devopsdb的业务能够直接升级到MGR架构环境下。

为了避免升级的时候,我们才开始部署MGR环境,我们需要预先搭建一套MGR环境,到时候需要导出线上数据,导入MGR环境。

准备的环境如下,尤其需要注意下图中的端口,这是我们为了保持业务连接和权限不变,对于业务使用来说能够透明一些。

运维系统数据库升级到MGR小结

 

线上环境升级时的架构如下,我们需要切换为MGR环境,原来环境的devopsdb数据可以备份出来就不再使用了,同时为了兼容和统一端口,119.221服务器上面的数据库需要调整端口,从4306修改为4316.

运维系统数据库升级到MGR小结

 

调整后的的架构改进图如下:

运维系统数据库升级到MGR小结

 

看起来简单的需求,为了保证兼容和统一,需要做不少的工作来承接这个相对平滑的过程,目前采用的是单主的模式,在经过了反复测试之后,和同事一起做了下升级的完整过程,算是一个好的开始。

我们把整个过程分成了18个步骤,每个步骤都做了下时间统计,供参考。

MGR切换前工作

  1. MGR-4310修改increment_offset为3
  2. 检查xwiki的数据库配置和服务配置(Tomcat
  3. 从mysql-4306导出devopsdb数据导入MGR-4310,评估导入时间,查看是否有导入错误
  4. MGR-4310切换测试
  5. Shutdown mysql_9.208-4310,预期切换到119.221-4310,测试写入数据
  6. Startup mysql_9.208-4310,加入集群
  7. Shutdown mysql_119.221-4310,预期切换到mysql_9.208-4310
  8. MGR-4310端口切换测试,修改端口为4301 11:30确认是否可行
  9. 梳理字典表用户,生成sql
  10. 正式切换
  11. 停止opsmange,xwiki服务
  12. Mysql_9.208-4306备份 mysqldump 备份devopsdb
  13. xwiki备份
  14. Shutdown Mysql-9.208-4306
  15. 修改mysql-9.208-4306为mysql-9.208-4308,降低buffer_pool配置
  16. 修改xwiki的数据库配置为4308,启动xwiki
  17. 切换MGR-4301为MGR-4306,修改buffer_pool配置,两个节点都修改
  18. 启动MGR-4306,恢复devopsdb的数据
  19. 测试工单流程和cmdb的数据情况,验证升级的有效性。

 

整个过程还是比较紧凑的,中间碰到了不少的实战问题,在有限的时间内推动完成还是挺不容易的。

声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍相关推荐
更多资讯 >>>