当前位置：首页 > 问答 > 正文

MySQL双向复制那些事儿，聊聊技术细节和实战经验分享

邝冷亦
问答
2026-01-14 07:54:12
2

说到MySQL的双向复制,这玩意儿听起来挺酷的，就像是给两个数据库装上了对讲机，你在这边说一句，那边马上能听到，反过来也一样，但真用起来，你会发现这个“对讲机”有时候会串线，甚至会两个人同时说话导致谁也听不清，今天咱就聊聊这里面的门道和我自己踩过的一些坑。

双向复制到底是个啥？

简单说,就是让两个MySQL数据库（比如叫A和B）互相把对方当成自己的“小跟班”，A数据库里有任何数据变化（比如插入一条新订单），会立刻告诉B数据库：“嘿，我这儿变了，你照着改一下。” 同样地，B数据库有任何风吹草动，也会马上通知A，这样，无论用户访问A还是B，看到的数据都是一样的，感觉上就像是一个数据库，实现了所谓的“双活”。

技术上的核心：如何避免“自己打自己”？

这是双向复制最核心、也最让人头疼的问题，想象一下这个场景：

MySQL双向复制那些事儿，聊聊技术细节和实战经验分享

一个写操作发到了数据库A,A插入了一条数据。
A的复制机制把这条插入语句打包成一个“事件”，发给了数据库B。
数据库B收到后,乖乖地执行了这条插入语句。
问题来了： B执行完这个“别人”的操作后，它自己会不会又把这个操作当成一个新变化，再发回给A呢？如果会，A就会收到一个一模一样的插入命令，导致数据重复，或者主键冲突，这就乱套了。

为了解决这个“循环复制”的鬼打墙问题，MySQL引入了一个非常关键的配置参数，叫做 server_id，根据MySQL官方文档的说明，每个参与复制的数据库都必须有一个独一无二的server_id，它的工作原理是这样的：

当数据库A要复制一个事件给B时,它会在这个事件上盖个章，写上“此事件由A（server_id=1）产生”。当数据库B收到这个事件并准备执行时，它会先看看事件的“盖章”，如果发现这个事件的原产地是A（server_id=1），而B自己的server_id是2，那么B在执行完这个事件后，就不会再把这个事件放入自己的二进制日志（就是记录所有变更的日志）里，这样一来，这个事件到了B这里就终止了，不会又被传回A。

通过这个机智的“盖章验票”机制，就避免了数据变更在两个数据库间无限循环。

实战中的坑，远比想象的多

MySQL双向复制那些事儿，聊聊技术细节和实战经验分享

你以为配好了server_id就高枕无忧了？Naive！真正的挑战才刚刚开始，根据我在实际项目中的经验，主要有这么几个大坑：

数据冲突：这是最大的噩梦！ 双向复制的假设是，你不会在两个数据库上同时修改同一行数据，但系统一复杂，或者程序有bug，这种情况很难避免，两个用户在不同机房（分别连接A和B）几乎同时修改了同一个用户的手机号，A这边改成了13800138001，B这边改成了13900139001，这两个变更会分别流向对方，这行数据会以哪个值为准？答案是：后到的那个会覆盖先到的，但哪个后到，取决于网络延迟，具有不确定性，结果就是数据混乱，而且几乎无法追溯，这比数据重复更可怕。
自增主键撞车： 如果表用的是自增主键（AUTO_INCREMENT），你得非常小心，如果A和B都自己生成主键，很可能出现A生成了ID=100，B也生成了ID=100，当这两条数据互相复制时，就会因为主键冲突而复制失败，常见的解决办法是，让A只生成奇数ID（比如从1开始，步长为2），让B只生成偶数ID（从2开始，步长为2），但这又增加了管理的复杂性。
网络抖一下，全家等半天： 复制是完全依赖网络的，如果A和B之间的网络延迟变大，或者短暂中断了几秒钟，复制就会卡住，等网络恢复了，B会拼命追赶A在这期间产生的所有数据变更，如果中断时间长了，堆积的变更太多，B可能会“累趴下”，导致复制延迟一直很大，用户体验到数据不一致，监控复制的延迟时间（Seconds_Behind_Master）是每天的必修课。
DDL操作要人命： 给表加个字段、改个索引（这些叫DDL操作），在双向复制里是高风险操作，你必须非常谨慎地安排，通常的做法是：先停掉一端的业务，让所有流量切到另一端，然后在停掉业务的数据库上执行DDL，等DDL复制到对端后，再恢复双向复制，如果两边同时执行DDL，或者顺序不对，很容易导致复制中断。