江苏龙网

  1. 主页 > 生活百科 > >

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

数据库升级

今天对运维系统的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小结】 
调整后的的架构改进图如下：
运维系统数据库升级到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的数据情况，验证升级的有效性 。
 
整个过程还是比较紧凑的，中间碰到了不少的实战问题，在有限的时间内推动完成还是挺不容易的 。




    推荐阅读


    上一篇：蜥蜴和壁虎的区别各有什么不同之处 马蛇子和壁虎是同一种动物吗

    下一篇：蛇是不是害虫 农村家里有蛇好吗