这是学习笔记的第 1904 篇文章
前段时间和同事对公司运维系统的数据库架构做了升级，从单点实例升级为了MGR架构，算是一个初版的改进，也算是一个新鲜的尝试。
目前的服务架构现状：
目前使用了2台服务器，每台上面部署了2个实例。算是两类没有交集的业务。
通过上面的图可以看到，既然没有交集，其实对于数据的并发写入也是影响最单一的，其实完全可以整合起来，做一个双主架构。
预期改进的结果：
预期是把两类业务整合到一套环境中，提升资源使用效率和可用率。
要做这样的一件事情，我是希望绝对可控之后才动手。一般来说真实的线上操作时间很短，前期的测试要充分细致，这个时间会相对长一些。
我把这个过程分为了测试验收阶段和线上升级两个阶段。
测试验收阶段的重要输出结果就是：是否具备线上操作的可行性。
整体上我划分了额13个步骤，是尽可能希望把一些不确定的问题提前发现，提前排错。
测试验收阶段：
1.搭建MGR环境,单主模式，先配置单节点
192.168.9.208 4318 400M
搭建这套环境的初衷是希望能够在新的环境中完全模拟和复现，评估操作时间之后和潜在问题之后，提高技术可控性和系统稳定性。
2.导出devopsdb数据
导出9.208-4306的devopsdb数据
3.搭建MGR 集群节点2
10.30.119.221 4318 400M
加入集群
这个步骤是刻意这样安排的，是希望通过这个过程来查看GR复制中的数据一致性效率，是否存在阈值和限制，同时也算是模拟了一个新增节点加入集群的步骤。
4.导出taskopsdb的数据
导出119.221-4316的数据
5.MGR单主模式到多主模式在线切换
9.208-4318 + 119.221-4318
明确需要修改的参数
这个步骤的重要总结是需要梳理重要的参数，提前测试
7.119.221-4318导入taskopsdb的数据
8.测试验证
这个步骤是对数据的双写进行验证，从性能和功能的角度查看是否能够满足预期的业务场景。
正式切换阶段：
9. .9.208-4306 + 119.221-4306从单主模式切换为多主模式
这个步骤是线上的操作，时间可以按照分钟来计算了。
10.导出119.221-4316 taskops的数据
11.119.221-4306导入 taskops的数据
12.修改taskops配置，重启调度worker
13.测试验证两个业务的数据情况
