背景
我们使用过的、构建过的MySQL服务绝大多数都是Single-Master,整个拓扑中只有一个Master承担写请求。比如,基于主从复制的Master-Slave架构,Master与Slave之间share nothing;或者是类似Aurora基于计算与存储分离的Writer-Reader架构,Writer与Reader之间share storage。
然而,由于种种原因,我们可能需要MySQL服务具有Multi-Master的特性,希望整个拓扑中可以有不止一个Master承担写请求。业界也有几类Multi-Master架构的解决方案,但是这些方案能不能满足业务的需求呢?
最近在做异地多活的项目,关于Multi-Master架构有一些点滴想法,怕记性不好忘了,所以在这里做一些总结,主要包括Multi-Master背后的需求、几类Multi-Master架构介绍、具体实现和适用场景。
为什么
为什么要用到Multi-Master?这个问题可能每个人想法都不尽相同,每个人的遇到瓶颈不同那么他的需求也不同,列举如下:单个Master扛不住写流量了,使用Multi-Master可以实现写扩展吗?
用户分布在天南海北,想让各地域的用户就近访问, 使用Multi-Master可以实现吗?
担心region整体故障导致服务不可用,想在不同地域同时部署业务,互为灾备,平时也分摊流量, 使用Multi-Master可以实现吗?
所以可以进一步归纳为:写性能可以近似线性扩展吗?
支持跨region部署吗?
那么Multi-Master能实现这些全部需求吗,或者能实现其中个把个需求?
这里将会介绍业界的几类方案,并分析它的适用场景。
业界方案
业界有几类Multi-Master架构的解决方案,列举如下Group Replication:MGR,MySQL5.7及以上支持;Share nothing。
Async Bidirectional Replication:这个洋气的名字是我编的,其实就是现在很多“异地多活”使用的“异步双向复制”方案;Share nothing。
Aurora Mult