运维系统数据库升级到MGR小结（数据库系统运维内容包括数据库备份与恢复）

这是学习笔记的第 1898 篇文章

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

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

当前系统的状态如下：

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

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

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

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

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

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

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

我们把整个过程分成了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的数据情况，验证升级的有效性。

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