MGR从单主模式向多主模式的迭代演进

这是学习笔记的第 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.测试验证两个业务的数据情况