数据库读写分离完全指南:从一次"用户下单后看不到自己的订单、主库宕机丢了几千条数据"看懂主从复制

2021 年我做一个交易系统,流量涨上来,数据库的读压力越来越大。第一版我做得很省事:配一套主从复制,一主一从,然后把所有的读查询,全甩给从库,写还留在主库。本地我开两个库测了测——真不错:读和写分了家,主库轻松了。我心里很踏实:"读写分离嘛,配好主从复制,读全走从库,不就行了。"可等这套架构真正上线、扛起真实流量,一串问题冒了出来。第一种最先把我打懵:用户刚刚下单成功,页面跳到"我的订单",却看不到那笔刚下的单——他以为下单失败了,又下了一遍。第二种:用户改了个人资料、保存成功,页面一刷新,显示的还是改之前的旧信息。第三种最隐蔽:平时一切正常,可某次运营在主库上跑了一个批量更新,从库的延迟瞬间飙到几十秒,那几十秒里,全站读到的全是几十秒前的陈旧数据。第四种最致命:一次主库宕机,我们把从库切成主库,事后对账才发现,从库比宕机前的主库少了几千条数据——那几千条,在主库还没来得及同步给从库的瞬间,永远地丢了。我盯着这一连串问题想了很久才彻底想明白,第一版错在一个根本的认知上:我以为"配了主从复制,把读甩给从库,读写分离就做好了"。这句话把"从库有数据"和"从库有最新数据"当成了一回事。可它不是。主从复制是异步的:主库写完自己的事,根本不等从库点头,就直接给应用返回成功了;从库永远在主库后面追赶,这中间隔着一段实实在在的复制延迟;延迟期间,从库手里的数据就是过期的;而大事务、单线程回放、网络抖动,还会让这段延迟从毫秒放大到几十秒。真正用好主从复制,核心不是"配好就把读甩出去",而是理解复制是异步且有延迟的、针对延迟设计读写策略、把延迟监控起来、并为故障切换时的数据丢失提前做好打算。这篇文章就把数据库的主从复制梳理一遍:为什么"配了就随便读"是错的、复制延迟到底从哪来、读写分离该怎么做才不读到旧数据、异步与半同步复制怎么权衡、主库宕机时故障切换要当心什么,以及延迟监控、并行回放、只读路由这些把主从复制真正做对要避开的坑。

问题背景

先把那串问题的现象和我的误判讲清楚,后面所有的设计都是冲着纠正这个误判去的。

现象:配好主从复制、把读全甩给从库之后,上线冒出一串问题:用户刚写完立刻读,读到的是旧数据(下单后看不到自己的订单、改完资料还显示旧的);某次主库一个批量更新,从库延迟飙到几十秒,全站读到的全是陈旧数据;一次主库宕机切换从库后,对账发现丢了几千条还没同步的数据。

我当时的错误认知:"配了主从复制,把读甩给从库,读写分离就做好了,从库随便读。"

真相:主从复制的本质是异步的。主库执行一个写操作,会把这次改动记进自己的 binlog;从库有一个 IO 线程,把主库的 binlog 拉过来存成本地的 relay log;再有一个 SQL 线程,把 relay log 里的改动一条条回放到自己身上。关键在于:主库写完 binlog 就直接返回成功了,它不会等从库把这条改动拉走、更不会等从库回放完。这意味着,在"主库已写好"和"从库也同步好"之间,永远存在一段时间差——这就是复制延迟。正常时它可能只有几毫秒,你几乎感知不到;可一旦遇上大事务、从库单线程回放跟不上、网络抖动,它能瞬间放大到几十秒甚至几分钟。在这段延迟里,从库的数据就是过期的。所以"读写分离"不是"配好主从、把读甩出去"那么简单,而是要承认延迟客观存在,并围绕它设计读路由、监控和故障预案。

要把主从复制做对,需要几块认知:

• 为什么"配了就随便读"是错的——复制是异步的,延迟客观存在;
• 看懂复制延迟——它从 binlog 传输和单线程回放里来;
• 读写分离的正确姿势——读自己的写、只路由给健康从库;
• 复制模式——异步、半同步,一致性与性能的权衡;
• 故障切换、延迟监控、并行回放这些工程坑怎么处理。

一、为什么"配了主从就随便读"是错的

先把这件最根本的事钉死:主库和从库,不是同一份数据的两个完全一致的镜子。它们更像是一个人在写、另一个人隔着一段距离照着抄——抄的人,永远比写的人慢一拍。主库每完成一个写操作,只负责把这件事记进自己的账本(binlog),然后立刻就去忙下一件事了;它绝不会停下来,等从库把这一笔也抄完。从库则在自己的节奏里,不紧不慢地把主库的账本一笔一笔誊到自己身上。所以任何一个瞬间,从库手里的,都不是"此刻主库的数据",而是"主库不久之前的数据"。你把读甩给从库,读到的就是这份"不久之前"。

下面这段代码,就是我那个"上线就读到旧数据"的第一版:

# 反面教材:无脑读写分离 —— 所有读全甩给从库
import random

PRIMARY = connect("primary-db")            # 主库,负责写
REPLICAS = [connect("replica-1"),          # 从库,负责读
            connect("replica-2")]


def execute_write(sql, params):
    # 写,永远走主库
    return PRIMARY.execute(sql, params)


def execute_read(sql, params):
    # 破绽:读,无条件随机甩给某个从库
    replica = random.choice(REPLICAS)
    return replica.execute(sql, params)
    # 破绽一:主从复制是异步的,从库的数据可能比主库旧。
    # 破绽二:用户写完立刻读,极可能读到从库上那份还没同步的旧数据。
    # 破绽三:从库延迟飙高时,这里照样把读甩过去 —— 读到几十秒前的数据。

这段代码在本地两个库上测试时表现完美,因为本地几乎没有写压力、没有网络延迟,主从之间的差距小到可以忽略。它的问题不在代码本身,而在一个被忽略的前提:它默认"从库的数据,和主库是一样新的"。可这个前提,只在没有真实并发写、没有延迟的理想环境里才成立。于是那串问题就有了解释:写完读到旧数据,是因为写刚落到主库,从库还没来得及同步;批量更新后全站读旧数据,是因为大事务把从库的延迟撑大了;切换丢数据,是因为主库宕机时,还有一批写没传到从库。问题的根子清楚了:用好主从复制的工程量,全在"承认从库的数据永远慢主库一拍"之后——你不围绕这个"慢一拍"去设计,就只能眼看着用户读到过期数据。先从看懂这个"慢一拍"到底从哪来说起。

二、看懂复制延迟:它到底从哪来

要对付复制延迟,先得知道它从哪儿产生。一次写从主库到从库,要走三步:主库把改动写进 binlog;从库的 IO 线程把 binlog 拉过来、存成本地 relay log;从库的 SQL 线程把 relay log 里的改动回放到自己身上。延迟,主要就积压在最后一步——回放。在从库上,可以直接查到复制的实时状态:

-- 在从库上执行,查看复制的实时状态
SHOW REPLICA STATUS\G

-- 几个关键字段,是判断复制健康的核心仪表盘:
--   Replica_IO_Running:   IO 线程是否在跑(从主库拉 binlog)
--   Replica_SQL_Running:  SQL 线程是否在跑(回放 relay log)
--   Seconds_Behind_Source: 从库落后主库大约多少秒 —— 复制延迟的直接读数
--   Source_Log_File / Read_Source_Log_Pos:   已从主库读到的 binlog 位置
--   Relay_Source_Log_File / Exec_Source_Log_Pos: 已回放到的位置

把这个状态读进代码,就能让程序自己判断一台从库能不能用:

def get_replica_lag(replica_conn):
    """读取从库的复制延迟(秒);复制断了或拿不到,一律视为不可用。"""
    row = replica_conn.execute("SHOW REPLICA STATUS").fetchone()
    if row is None:
        return None                        # 这台根本没在做复制
    io_ok = row["Replica_IO_Running"] == "Yes"
    sql_ok = row["Replica_SQL_Running"] == "Yes"
    if not (io_ok and sql_ok):
        return None                        # 复制线程断了,延迟读数已无意义
    lag = row["Seconds_Behind_Source"]
    return lag                             # 单位:秒,None 表示复制异常

延迟为什么会突然飙高?核心原因有三个:其一,大事务——主库上一个改动了几百万行的事务,在主库可能并行执行,但传到从库,必须作为一个整体、完整回放完才算数,这一条就能让从库卡住几十秒。其二,单线程回放——从库的 SQL 线程默认单线程,主库是多个连接并发地写,一个单线程的从库去追多个并发的主库,天生就追不平。其三,从库自身的压力——从库一边要回放,一边还要扛你甩过来的读流量,读太重,回放就被挤慢了。这里的认知要点是:复制延迟不是一个固定的小数字,而是一个会随着主库写入压力、事务大小剧烈波动的变量。你不能假设它"一直很小",而要把它当成一个必须实时监控的指标。知道了延迟的存在和来源,下一步就是:读写分离到底该怎么做,才不会读到旧数据。

三、读写分离的正确姿势:读自己的写

读写分离最容易踩的坑,就是开头那个"写完立刻读到旧数据"。它有一个经典的名字,叫"读自己的写"(read-your-writes):一个用户做完写操作,他紧接着的读,必须能看到自己刚写的东西——这是用户体验的底线。解决它的办法很朴素:一个会话刚写过,那么在接下来的一小段时间里,它的读,强制走主库。因为主库永远是最新的,等过了这段时间、从库大概率已经同步上了,再放心走从库:

import time
import random


class ReadWriteRouter:
    """读写分离路由:写后一小段时间内,这个会话的读强制走主库。"""

    def __init__(self, primary, replicas, stick_ms=1000):
        self.primary = primary
        self.replicas = replicas
        self.stick_ms = stick_ms           # 写后"粘"在主库的时长
        self.last_write_at = 0.0

    def write(self, sql, params):
        result = self.primary.execute(sql, params)
        self.last_write_at = time.monotonic() * 1000
        return result

    def read(self, sql, params):
        # 距上次写还不够久 —— 从库可能还没同步,强制走主库
        elapsed = time.monotonic() * 1000 - self.last_write_at
        if elapsed < self.stick_ms:
            return self.primary.execute(sql, params)
        # 写后已隔了足够久,放心走从库
        return self._pick_replica().execute(sql, params)

但走从库这一步也不能闭眼乱走。第二节说了,从库的延迟会波动——一台延迟飙到几十秒的从库,不该再接收读流量。所以挑从库时,要先筛掉延迟超标的:

    def _pick_replica(self):
        """只在延迟达标的从库里挑;全都不达标,就回退到主库。"""
        healthy = []
        for r in self.replicas:
            lag = get_replica_lag(r.conn)
            if lag is not None and lag <= 1:   # 延迟在 1 秒内才算健康
                healthy.append(r)
        if not healthy:
            # 没有一台健康从库 —— 宁可让主库扛一下,也不读陈旧数据
            return self.primary
        return random.choice(healthy)

下面这张图,把一次读写路由的决策过程串起来:

这里的认知要点是:读写分离的精髓,不是"读一律走从库",而是"读默认走从库,但要为它装两道闸"——第一道闸拦住"刚写完的会话",让它的读暂时回主库;第二道闸拦住"延迟超标的从库",不让读流量流向陈旧的数据。两道闸合起来,才既分担了压力,又守住了数据的新鲜度。不过,上面这套都是客户端的补救。要从根上减少延迟带来的风险,还得看复制本身的模式选择。

四、复制模式:异步与半同步的权衡

第一节说主从复制是"异步"的,但这其实是默认模式,并非唯一选择。MySQL 的复制,常见有两档:

• 异步复制(默认):主库写完 binlog 就立刻返回,完全不管从库收没收到。性能最好,但主库一宕机,那些还没传到从库的写,就丢了。
• 半同步复制:主库写完 binlog 后,要等至少一个从库回话"我收到 binlog 了",才返回成功。主库宕机时,数据基本不丢(至少有一个从库收到了),代价是每个写都多等一个网络来回。

半同步复制的开关,要在主库和从库上分别打开:

-- 默认的异步复制:主库写完 binlog 就返回,不等从库
-- 半同步复制:主库要等"至少一个从库确认收到 binlog"才返回

-- 主库上启用半同步
INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so';
SET GLOBAL rpl_semi_sync_source_enabled = 1;
-- 等从库确认的超时:超过 1 秒没人确认,自动退回异步,避免主库被拖死
SET GLOBAL rpl_semi_sync_source_timeout = 1000;

-- 从库上启用半同步
INSTALL PLUGIN rpl_semi_sync_replica SONAME 'semisync_replica.so';
SET GLOBAL rpl_semi_sync_replica_enabled = 1;

这里要看清一个常见的误解:半同步复制,保证的是"从库收到了 binlog",不是"从库已经回放完了"。也就是说,半同步能大幅减少主库宕机时的数据丢失,但它并不能消除复制延迟——binlog 收到了,回放还是要排队。所以第三节那套读路由的闸,即便上了半同步,依然一个都不能少。这里的认知要点是:复制模式的选择,本质是在"性能"和"数据安全"之间定一个点。异步复制把性能拉满,但接受"宕机可能丢一点数据";半同步复制用每个写多一个网络来回的代价,换来"宕机基本不丢数据"。关键业务(订单、支付)值得上半同步,而它换来的是安全,不是零延迟。模式定了,还剩一个最惊险的场景:主库真的挂了,怎么办。

五、故障切换:主库宕机时最该当心什么

主库宕机,要把一台从库提升为新主库,这个过程叫故障切换。开头第四个问题——"切换后丢了几千条数据"——就是切换切错了。最危险的一步是:从库的 relay log 里,可能还积压着一批"已经从主库收到、但还没回放完"的改动。如果你不等它回放完就强行提升,这批改动就跟着旧主库一起被丢掉了。所以提升之前,必须先确认这台从库已经把积压的 relay log 全部回放干净:

def is_safe_to_promote(replica_conn):
    """把从库提升为主库前,先确认它已经追平、没有积压。"""
    row = replica_conn.execute("SHOW REPLICA STATUS").fetchone()
    if row is None:
        return False, "这台不是从库,不能提升"
    # 已从主库读到的位置,和已回放到的位置,必须一致
    # 否则 relay log 里还有积压没放完,直接切会丢掉这部分
    read_pos = (row["Source_Log_File"], row["Read_Source_Log_Pos"])
    exec_pos = (row["Relay_Source_Log_File"], row["Exec_Source_Log_Pos"])
    if read_pos != exec_pos:
        return False, "relay log 还有积压未回放,需先等它放完"
    lag = row["Seconds_Behind_Source"]
    if lag is not None and lag > 0:
        return False, f"仍落后主库约 {lag} 秒,未追平"
    return True, "已追平,可以安全提升"

确认追平后,才能执行真正的提升。下面是基于 GTID(全局事务标识)的切换步骤:

# 主库已宕机,把追平的从库提升为新主库(基于 GTID)

# 1. 停掉这台从库的复制
mysql -e "STOP REPLICA;"

# 2. 清掉它的复制配置 —— 它从此自己当主库,不再追谁
mysql -e "RESET REPLICA ALL;"

# 3. 解除只读 —— 从库通常配了 read_only / super_read_only
mysql -e "SET GLOBAL super_read_only = OFF; SET GLOBAL read_only = OFF;"

# 4. 让其余从库改指向这个新主库,继续复制
mysql -h replica-2 -e "
  STOP REPLICA;
  CHANGE REPLICATION SOURCE TO SOURCE_HOST='new-primary', SOURCE_AUTO_POSITION=1;
  START REPLICA;"

这里的认知要点是:故障切换不是"随便挑个从库顶上"那么简单。切换前必须回答两个问题:这台从库追平了吗(没追平,切了就丢数据)?旧主库被彻底隔离了吗(没隔离,它万一活过来,就会和新主库各写各的,造成"脑裂")?在异步复制下,故障切换天生就带着一个"数据丢失窗口"——你能做的不是消灭它,而是选最追平的那台从库,把窗口压到最小。

六、工程坑:并行回放、只读保护与延迟监控

五块设计之外,还有几个工程坑,不处理就会让主从复制延迟失控、或悄悄分叉。坑 1:从库默认单线程回放,要开并行回放。这是延迟飙高的头号根源。主库是多连接并发写的,从库却用单个 SQL 线程去追,自然越追越慢。现代 MySQL 支持多线程并行回放,务必打开:

-- 复制延迟的一大根源:从库默认单线程回放 relay log
-- 主库多线程并发写,从库单线程追 —— 天生追不平

-- 在从库上开启多线程并行回放
STOP REPLICA SQL_THREAD;
-- 按事务的逻辑时钟分组,组内互不冲突的事务可并行回放
SET GLOBAL replica_parallel_type = 'LOGICAL_CLOCK';
SET GLOBAL replica_parallel_workers = 8;        -- 开 8 个回放线程
-- 保证从库上事务的提交顺序,和主库严格一致
SET GLOBAL replica_preserve_commit_order = ON;
START REPLICA SQL_THREAD;

坑 2:从库必须设只读,否则会"数据分叉"。如果从库没设只读,某个程序误连到从库去写,这条写只存在于从库、主库上没有——两边数据从此对不上,且永远对不回来。所以从库一定要开 super_read_only(它比 read_only 更严,连有 SUPER 权限的账号也禁止写)。坑 3:复制延迟必须监控,延迟高的从库要自动摘除。第三节的读路由,依赖的就是实时、准确的延迟数据。要有一个独立的巡检,周期性地查每台从库的延迟,分级告警、并把延迟超标的从库,自动从读流量里摘掉:

def monitor_replication(replicas, alarm, warn_sec=2, crit_sec=10):
    """周期性巡检每台从库的复制延迟,分级告警并自动摘除。"""
    for r in replicas:
        lag = get_replica_lag(r.conn)
        if lag is None:
            alarm.fire("critical", f"{r.name} 复制已中断")
            r.mark_unavailable()             # 立刻从读流量里摘除
        elif lag >= crit_sec:
            alarm.fire("critical", f"{r.name} 延迟 {lag}s,已摘除")
            r.mark_unavailable()
        elif lag >= warn_sec:
            alarm.fire("warning", f"{r.name} 延迟 {lag}s,偏高需关注")
        else:
            r.mark_available()               # 延迟正常,放回读流量池

坑 4:别在主库上跑大事务。一个改动几百万行的 UPDATE、一次没分批的数据清理,在主库上或许还能并行扛住,但传到从库,会作为一个不可拆分的整体阻塞回放,让延迟瞬间爆表。批量操作一定要分小批、带间隔,这既是为了主库,更是为了从库不被它拖垮。坑 5:扩容从库不能靠"复制从头追"。给一套已经跑了很久的主库新加一台从库,如果让它从最早的 binlog 开始追,可能要追上好几天。正确做法是:先用一份主库的物理备份,把新从库的数据"灌"到和某个时间点一致,再让它从那个点之后开始复制——这样它只需追那个点到现在这一小段。

关键概念速查

避坑清单

1. 主从复制是异步的,从库"有数据"不等于"有最新数据"。
2. 用户写后立刻读,极易读到从库上那份还没同步的旧数据。
3. 读自己的写:写后一小段时间内,该会话的读强制走主库。
4. 把读路由给从库前先筛掉延迟超标的,别往陈旧库甩流量。
5. 复制延迟必须监控告警,延迟飙高的从库要自动摘除。
6. 从库默认单线程回放,务必开并行回放缓解延迟堆积。
7. 大事务会让从库延迟瞬间飙高,批量操作要拆小、带间隔。
8. 异步复制宕机会丢未同步的写,关键业务上半同步复制。
9. 故障切换前必须确认从库已追平 relay log,否则切了也丢数据。
10. 从库要设 super_read_only,防止误写造成主从数据分叉。

总结

回头看那串"写完读到旧数据、批量更新后全站陈旧、切换丢了几千条"的问题,以及我后来在主从复制上接连踩的坑,最该记住的不是某一个配置参数,而是我动手前那个想当然的判断——"配了主从复制,把读甩给从库,读写分离就做好了"。这句话错在它把"从库有这份数据"和"从库有最新的这份数据"画上了等号。我以为主库和从库,是同一份数据的两面镜子,照哪面都一样。可我忽略了一件事:这两面镜子之间,隔着一段时间——从库映出的,永远是主库不久之前的样子。把读无条件甩给从库,不是做了读写分离,而是默许了用户去读一份"可能已经过期"的数据,却还以为它是最新的。

所以用好主从复制,真正的工程量不在"把主从配置连起来"那一步上。那一步,跟着文档敲几条命令就行。真正的工程量,在于你要承认"从库的数据永远慢主库一拍",并围绕这个"慢一拍"把整套读写策略重新设计一遍:用户刚写完,你就用"读自己的写"把他的读暂时拽回主库;要走从库,你就先筛掉延迟超标的,只把读交给追得上的那几台;关键业务怕丢数据,你就上半同步复制,用一个网络来回换主库宕机时的安全;延迟会波动,你就把它监控起来、超标自动摘除;主库真挂了,你就先确认从库追平、再提升,把数据丢失窗口压到最小。这篇文章的几节,其实就是顺着这条线展开的:先想清楚"随便读"为什么错,再讲复制延迟从哪来、读写分离怎么装两道闸、异步与半同步怎么权衡、故障切换要当心什么,最后是并行回放、只读保护、延迟监控这几个把主从复制做扎实的工程细节。

你会发现,数据库的主从复制,和现实里"上课时老师在黑板上写、学生在下面抄笔记"完全相通。老师(主库)写完一行,就立刻擦掉、写下一行,他不会停下来等所有学生都抄完。学生(从库)埋头抄,但手再快,也总比黑板慢半行。一个不懂这个道理的人会怎么做?他直接低头看某个学生的笔记本,就当成是黑板上的最新内容(这就是无脑读从库)——可那一刻,这个学生恰好还没抄到最新那行,他看到的就是旧的。而一个真懂的人怎么做?需要最新、最准的内容时,他直接看黑板(这就是读自己的写、走主库);只是想了解个大概、又不那么急,才去翻学生的笔记,而且会挑那个抄得最快、最跟得上的同学(这就是筛选健康从库);他还很清楚,万一老师突然离开,要靠某个学生的笔记接着讲,就得先确认这个学生已经把黑板上的全抄下来了(这就是故障切换前的追平确认)。

最后想说,主从复制做没做对,差距永远不会在"本地两个库、配好就能读"时暴露——本地你几乎没有并发写、没有网络延迟、没有大事务,主从之间的差距小到测不出来,你会觉得"配好主从、读甩给从库"已经是全部。它只在真实的、有持续高并发写、有大事务偶尔串场、主库还可能毫无征兆宕机的线上环境里才显形。那时候它会用最伤用户信任的方式给你结账:做不好,你的用户会下完单看不到订单、改完资料还是旧的,一次主库宕机后对账发现凭空少了几千条数据;而做对了,你的读写分离会安静地分担住压力:用户永远能立刻看到自己刚写的东西,读流量只流向那些追得上的从库,延迟一飙高问题从库就被悄悄摘掉,即使主库宕机,切换也只丢极少甚至不丢数据。所以别等"用户投诉数据对不上"找上门,在你写下那行"读走从库"的那一刻就该想清楚:我面对的不是两份永远一致的数据,而是一主一从、从库永远慢一拍的一对副本——用户写完会不会立刻读、这台从库延迟达不达标、主库挂了切换会不会丢数据,这一道道关,我是不是都替它守住了?这些问题有了答案,你搭出来的才不只是一套"本地能跑"的读写分离,而是一套真正经得起高并发、扛得住故障的可靠数据库架构。

—— 别看了 · 2026