那天凌晨3点，我盯着监控大盘上的主从延迟曲线——突然飙到半小时。心里一万匹草泥马奔腾而过。老板电话马上就响了，对吧？主从复制，这个几乎每个后端工程师都烂熟于心的词，关键时刻总给你“惊喜”。
说实话，很多团队用主从复制，无非就是读写分离、数据备份。可这东西，简直是个双刃剑。用好了，平滑扛量；用砸了，数据丢到你怀疑人生。今天我不谈概念，只拆内核，聊聊我踩过的坑、看到的数字，还有那些让你提心吊胆的架构陷阱。
IO线程、SQL线程：一对不那么靠谱的“影分身”
主从复制说穿了，不就是主库把写操作发给从库重放一遍吗？但背后的线程模型，很多人可能都没仔细想。MySQL主从复制（基于Binlog）依赖两个核心线程：IO线程和SQL线程。主库上一个Binlog Dump线程负责推送，从库IO线程接收并写入Relay Log，然后SQL线程读取Relay Log并执行。
这个设计看起来挺清晰——可现实是，SQL线程是单线程的（至少传统做法是这样）。这意味着什么？主库多线程并发写入扛几万QPS，到从库全部排队串行回放。延迟就是这么来的。我一个做金融支付的朋友，线上主库写TPS 5000，从库SQL线程累死累活只能消化2000。你猜延迟会怎么样？指数级增长，直到从库直接挂掉。这就像让一个速记员去抄写十个人同时说的话，能不走神吗？前一阵子我还见过一个案例，主从延迟超过2小时，最后切主的时候丢了一个小时的数据——那真叫一个惨。
解决方向？后来的版本引入了并行复制（比如基于组提交的LOGICAL_CLOCK模式），让SQL线程也能多线程干活。但别高兴太早，并行复制又会引入新的坑——事务顺序问题，这也是我后面要说的。
半同步？增强半同步？——数据安全的一里路，可能真要命
最初，MySQL默认是异步复制。主库把Binlog发出去就不管了，从库收没收到、收完没，主库一概不知。这在性能上几乎零损耗——压测对比：异步复制下主库事务提交延迟只增加0.1ms以内（本地写Binlog开销），但从库挂了可能丢失最新一秒甚至更多的数据。我记得有次压测，异步模式在突发流量下，主库宕机后丢失了327个事务，相当于几万块钱的订单。
于是半同步复制（semi-sync）来了：主库写完后，必须等至少一个从库确认收到Binlog（但不保证执行完），才给客户端返回成功。延迟增加多少？我们实测，网络良好的同机房，半同步额外延迟大概1-3ms。看着不多，可高并发下事务吞吐量会下降15%-20%。这还算能接受。最坑的是，如果从库挂掉，主库会降级为异步——这期间如果再宕机，数据照丢不误。这就是经典的“半同步退化”问题。
后出的增强半同步（after_sync）更狠：不仅确认收到，还要确保Relay Log刷盘，并且主库降级会设超时，超时后从库自动踢出，新事务切换成异步但至少知道谁靠得住。我们在一个订单系统上线增强半同步，配合GTID，成功把主备切换数据丢失的概率从万分之五压到十万分之一以下——代价是平均延迟又多了2ms。值不值？看你的业务，拿真金白银说事。
所以，不要听信什么“半同步绝对安全”，数据安全的最后一里路，永远是取舍。
坑！三个让你半夜惊醒的陷阱与压箱底解法
下面全是干货，踩出来的经验。
陷阱一：读写分离下的陈旧读。你用了主从复制，就必然有复制延迟。哪怕只有几十毫秒，用户刚下完单，一刷新“订单去哪儿了？”就开始骂娘。最笨的办法：强迫读主。但某些场景可以用GTID或semi-sync保证从库至少已收到当前事务。我们实践是在写后立即读关键数据（比如订单详情）走主库，其他列表走从库，通过一个简单的ThreadLocal标记控制。粗暴，但有效。别迷恋复杂的方案，稳定性第一。
陷阱二：大事务引发的复制风暴。一个UPDATE删改上千万行数据，主库跑了30分钟，从库回放也要30分钟。这期间复制彻底堵死。我亲眼见过因一个大事务导致从库延迟暴涨到2000秒，然后监控报警刷屏，运维差点把键盘吃了。解法？切记：任何线上DDL或大批量DML，必须拆小。用pt-online-schema-change分片执行，或者业务上限制一次操作行数。还有个狠招，开启binlog_row_image=minimal和binlog_row_format=ROW，减少Row日志量，但这治标不治本。
陷阱三：主从切换时的幽灵事务。切换工具（比如MHA, Orchestrator）再牛，也怕网络分区。曾出现原主库以为自己是主，新主库提拔后，两边同时写入，最后数据冲突。怎么破？Server-UUID + GTID联动，新主启动时扫描所有从库的Executed_Gtid_Set，计算差异后补齐。再加上增强半同步，彻底杜绝“脑裂”写入。这套组合拳，我们演练过几十次，切换时间从分钟级降到10秒内，且零数据异常。
好了，就这些。想起来再补。主从复制不是什么高端技术，但想玩透，真得扒几层皮。
