看到这个标题我第一反应是看了一眼日历——确认今天不是愚人节。MySQL 8.2 支持读写分离了我差点把手边的水杯碰倒。作为一个从 MySQL 5.5 时代一路折腾到 8.x 的老家伙我对“原生读写分离”这几个字太敏感了。但冷静下来翻了翻发行说明只能说这个说法有水分且听我慢慢拆。先说最要紧的结论MySQL 8.2 并没有直接在服务端内置一个“读写分离开关”。读和写走不同的节点仍然是靠主从复制加路由层配合完成的。但 8.2 作为 Innodb 和复制链路的一个“创新版本”确实把很多底层能力打磨得更顺了加上官方在 Router 和连接器上的持续发力才让不少人产生了“8.2 支持读写分离”的误解。这篇文章我就把这层窗户纸捅破讲讲 8.2 到底改了什么、读写分离的本质是什么、以及怎么在真实环境里搭一套能跑的方案。1. 先泼盆冷水MySQL 8.2 到底“支持”了什么1.1 版本号背后的恩怨Innovation Release 与 LTS 之谜很多同学看到 8.2下意识以为这是 8.0 的下一个大版本就像当年 5.7 升 8.0 一样。实际上 MySQL 从 8.1 开始调整了发布节奏把版本分成两类Innovation Release创新版和Long Term Support长期支持版。8.0.34 是 8.0 系列的最后一个 LTS之后 8.1、8.2、8.3 都属于创新版每三个月左右发一个特性激进、支持周期短通常只有到下一个创新版发布为止。真正的下一代长期支持版是 8.4 LTS。所以你如果跑的是 8.2想靠这个版本“一劳永逸”撑几年那是想多了。这也解释了为什么 8.2 出来后社区里关于“读写分离”的声音突然变多了。创新版更新频率高官方在版本说明里提到了一些与 Router、复制性能相关的改动营销语境下很容易被放大成“内置读写分离”。但真相是读写分离从来都不是一个单节点上的功能而是整套架构具备的能力。1.2 8.2 在 Innodb 和复制链路上的真实变化那 8.2 有没有干活有但干的是底层苦力活不是前端那个光鲜的功能开关。8.2 对 InnoDB 的只读事务和读视图read view管理做了进一步优化在高并发只读场景下锁竞争和事务启动开销比 8.0 末尾版本更低。同时复制链路上的并行复制能力也持续增强从库在应用 binlog 时能更好地利用多线程。这些改进放在读写分离架构里意味着从库承受只读洪峰时更抗压延迟相对更小。不过要泼第二盆冷水这些优化是“锦上添花”不是“雪中送炭”。如果你在 8.0.30 上把主从复制参数调好了架构本身不会因为升到 8.2 就产生质变。那为什么标题会认为“牛掰支持读写分离了”我推测真正的主角是官方 Router 与连接器的配套增强。MySQL Router 在 8.2 时代已经非常成熟它读 MySQL 副本集拓扑信息自动区分 PRIMARY 和 SECONDARY然后按策略路由流量。加上官方连接器对 Router 的透明支持变好很多用户体验下来感觉就是“升级到 8.2业务读写自动分流了”。实际上分流的是 Router不是 MySQL 内核。2. 读写分离的本质主从复制 路由层的组合拳2.1 主从复制读写分离的地基一砖一瓦都不能歪读写分离这套东西底层的地基是主从复制。主库写 binlog从库拉取 binlog 并重放数据从一个节点流到另一个节点。没有复制你没法把读流量打到从库上因为数据对不上。复制有个关键点数据永远有延迟。哪怕半同步复制也只保证主库提交时事务日志至少被一个从库接收了但从库什么时候重放完没人给你打保票。这带了第一个设计原则能容忍短时间读到旧数据的业务才适合读写分离不能容忍的老老实实全部走主库。地基怎么打现代 MySQL 我建议直接上 GTID。8.2 里 GTID 是默认推荐开启的主从之间用 GTID 自动定位位点比老式的MASTER_LOG_FILE和MASTER_LOG_POS省心太多。以前我踩过人工选错日志位点导致复制管道错乱的坑换了 GTID 之后再没犯过这种低级错误。2.2 路由层才是关键Router、ProxySQL 还是应用层复制搭好了真正决定读写分离能不能优雅落地的是路由层。我见过不少团队把“读写分离”等同于“搭主从”结果从库建了一堆应用根本没用上。流量不会自动分流必须在某个位置做路由判断。主流方案有四种方案路由位置优点缺点MySQL Router连接层部署轻、零侵入、官方维护路由规则相对简单单点需要守护ProxySQLSQL层规则灵活、可灰度、可缓存多一层架构运维难度上升应用层框架业务代码控制最细、事务感知最准侵入代码每个语言都要实现一遍中间件注册中心配置中心可动态切换重小团队没必要在这四个里MySQL Router 是官方配套和 8.2 的“读写分离”话题绑定最紧。它有两个监听端口一个指向 PRIMARY一个指向 SECONDARY。业务只配两个地址Router 帮你把流量分发出去。更妙的是它能识别异步复制拓扑主从切换后自动调整路由目标。ProxySQL 则是老牌网红支持按用户、按 schema、按正则表达式做查询路由。比如SELECT走从库、INSERT/UPDATE/DELETE走主库。但它本质上是个代理多一跳就会多一层延迟和故障点不是必须就尽量别上。2.3 高可用加持MGR 与读写分离如何协同读写分离和高可用通常一起出现。MySQL 8.2 时代Group ReplicationMGR已经是成熟方案。MGR 是一种多主或单主模式的复制集群成员间通过 Paxos 协议选主节点挂掉后自动切换 PRIMARY。把 MGR 和读写分离结合就是一套挺经典的架构MGR 负责高可用主库宕机自动选出新主。Router 负责读写分离监听 MGR 的拓扑变化把写流量交给新 PRIMARY。从库甚至 MGR 里的其他节点负责扩展读能力。这样组合下来业务侧几乎无感知。我实际验证过杀掉 PRIMARY 之后Router 切换到新主的时间窗口大约在十几秒到几十秒取决于探测间隔和故障检测速度。这个窗口期应用可能报短连接失败所以应用层必须有重试机制否则光有架构还不够。3. 动手实践从零搭建一套 MySQL 8.2 读写分离架构3.1 规划环境与版本选型理论说完了开始动手。我这次用的是一主一从的经典拓扑两个节点跑的都是 MySQL 8.2Router 用官方 8.2 配套版本。操作系统是干净的 Linux 测试环境SELinux 直接 disabled防火墙先关掉不然一会儿 3306、6446、6447 端口互相访问会被折腾疯。节点规划如下角色主机名IP端口PRIMARYdb-primary192.168.1.103306SECONDARYdb-secondary192.168.1.113306Routerrouter01192.168.1.126446/6447选型上我的建议是如果你在 8.0 上已经有生产业务别为了“支持读写分离”这句话特意升 8.2。8.2 是创新版支持周期短适合测试环境和想要尝鲜新特性的场景。生产环境求稳等 8.4 LTS 出来再评估迁移。3.2 主库、从库配置实战主库配置最关键的是开 binlog、开 GTID、配 server-id。我把最小可用配置贴出来[mysqld] server-id 1 log-bin mysql-bin binlog_format ROW gtid_mode ON enforce_gtid_consistency ON binlog_expire_logs_seconds 604800binlog_format我用了 ROW因为混合模式在跨版本升级和特殊 SQL 下容易出妖蛾子。ROW 模式日志量大一点但一致性最好。binlog_expire_logs_seconds设置 7 天防止磁盘被日志打满。从库配置稍微多点[mysqld] server-id 2 read_only ON skip_replica_start ON gtid_mode ON enforce_gtid_consistency ONread_only ON是必须的防止有人不小心直连从库写数据。skip_replica_start的意思是实例启动后不要自动开始复制等我把复制源配好再手动启动避免启动顺序错乱导致复制线程异常。3.3 用 MySQL Router 完成自动路由两个数据库节点启动后创建复制用户并建立复制链路。这一步比较机械但细节容易错。主库上执行CREATE USER repl% IDENTIFIED BY YourPass123; GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl%;从库上执行CHANGE REPLICATION SOURCE TO SOURCE_HOST 192.168.1.10, SOURCE_USER repl, SOURCE_PASSWORD YourPass123, SOURCE_AUTO_POSITION 1; START REPLICA;SOURCE_AUTO_POSITION 1是关键它让从库通过 GTID 自动找到主库的 binlog 位点不需要手工填日志文件名和偏移量。这在 8.2 里是默认推荐的复制方式。确认复制正常SHOW REPLICA STATUS\G重点看Replica_IO_Running和Replica_SQL_Running都是YesSeconds_Behind_Source为 0。接下来是 Router 的配置。Router 支持--bootstrap自动配置这条命令会连上主库抓取拓扑信息生成一份配置文件mysqlrouter --bootstrap root192.168.1.10:3306 \ --directory /opt/mysql-router \ --usermysqlrouter执行完以后主目录下会生成mysqlrouter.conf。打开看一眼里面已经自动生成了两个 routing 组。但是自动生成的配置往往要按场景调一调我最终调整成这样的关键段[routing:primary] bind_address 0.0.0.0 bind_port 6446 destinations 192.168.1.10:3306,192.168.1.11:3306 routing_strategy first-available [routing:secondary] bind_address 0.0.0.0 bind_port 6447 destinations 192.168.1.10:3306,192.168.1.11:3306 routing_strategy round-robin注意primary组里我把主从两个节点都放进去了routing_strategy first-available保证写流量永远落在第一个可用节点上也就是 PRIMARY。secondary组用round-robin轮流把读流量分散到主从两个节点。等等读流量会打到主库上对。这是很多人的误区——读写分离不代表主库不承担读。如果你希望从库扛所有读压力可以在destinations里只写从库的地址。但从架构冗余角度主库也参与只读路由既能分摊压力也能在主从切换后避免路由黑洞。3.4 验证读写分离与故障切换配置完 Router启动它mysqlrouter --config /opt/mysql-router/mysqlrouter.conf 接着用客户端测两个端口mysql -h 192.168.1.12 -P 6446 -u testuser -p -e SELECT server_id; mysql -h 192.168.1.12 -P 6447 -u testuser -p -e SELECT server_id;server_id能看出当前连接落在哪个节点上。正常情况下6446 返回 1主库6447 按轮询返回 1 或 2。多执行几次 6447 的查询你能看到 server_id 在 1 和 2 之间切换说明读流量确实被分发到了两个节点。别忘了在实际业务表上做一次验证在主库插入一条记录从库执行SELECT COUNT(*)能看到这条记录然后通过 6447 端口也能查到说明数据链路通、路由也通。故障切换验证比较暴力。我直接kill -9掉主库的 mysqld 进程然后观察 Router 的日志。用first-available策略时Router 会探测到主库不可用把写流量自动切到备节点上。这个过程中业务侧可能报出几次连接错误但新连接会在探测周期结束后恢复正常。切记Router 不是零感知切换应用层要做好短连接重试。4. 实战避坑延迟、路由和版本回退4.1 主从延迟与一致性读己之写怎么解决读写分离第一个大坑就是“读己之写”。用户提交一个表单下一秒刷新页面结果查从库发现数据还没同步过来页面空空如也。这在生产环境算事故级别。解决思路无非几种关键业务强制穿透读主库把必须实时的数据操作在代码里标注为走 PRIMARY 连接。比如 mysql 驱动里配置 HINT或者单独开一个数据源。合理容忍短暂延迟大部分展示型数据延迟一两秒根本看不出来没必要所有请求都穿透。从库并行复制调优加大并行复制线程数把延迟压到毫秒级。可以在从库配置里加slave_parallel_type LOGICAL_CLOCK slave_parallel_workers 8但线程数不要盲调太高我曾经在一个 16 核的机器上把slave_parallel_workers调到 32结果从库复制冲突频繁反而比 8 线程还慢。具体线程数要结合主库写并发来观察。4.2 Router 路由失效问题排查Router 最常出问题的地方是“配置看着没问题但流量就是不分流”。排查思路我建议按这个顺序来先确认业务连的是 Router 的端口而不是数据库裸端口。真有人配完 Router 忘了改应用连接串。看 Router 日志。默认日志路径在配置目录下/opt/mysql-router/log/mysqlrouter.log。如果拓扑抓取失败日志里会有明显报错。用mysqlrouter --verify-config校验配置文件的语法和连通性。还有一个高频问题因为事务内读不需要分离。比如一个事务里先UPDATE再SELECT如果 SELECT 走了从库而主库的变更还没同步过去事务内部读到旧值就闹笑话了。Router 是全连接级路由感知不到事务状态所以需求复杂时还得靠 ProxySQL 或应用层。这个取舍要心里有数。4.3 半同步复制配置不当引发丢数据读写分离场景下很多人认为主库写完就完事了从库丢了再从主库拉。这话对异步复制成立但在某些金融类业务里不可接受。MySQL 8.2 支持半同步复制可以保证事务提交前binlog 已经传给了至少一个从库。半同步配置其实不复杂主库装插件INSTALL PLUGIN rpl_semi_sync_source SONAME semisync_source.so; SET GLOBAL rpl_semi_sync_source_enabled 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;注意rpl_semi_sync_source_timeout 1000这个参数。它的意思是如果从库 ACK 超时超过 1000 毫秒主库自动降级为异步复制保证主库写入不卡死。这是双刃剑从库网络抖动时一致性保护会短暂失效。我见过有人把这个值设成 60000结果从库宕机后主库写入直接阻塞一分钟业务大面积超时。合理值应该是几百毫秒到 2 秒之间具体看你对一致性和可用性的取舍。4.4 版本回退与升级路径建议最后聊版本。如果你真在测试环境把 8.2 跑起来了想回退到 8.0 系列有两个麻烦一是 GTID 模式默认开启后直接降级到不支持 GTID 的旧配置会失败。降级前要先把复制停掉清理 GTID 执行记录或者干脆重新搭建从库。二是 ROW 格式的 binlog 在跨大版本升级后可能不被旧版本识别。严谨的降级流程应该是停止写入、确认主从数据一致、备份、然后在新实例上导入备份而不是直接把数据目录指回去。我的实际建议是8.2 这类创新版适合拿来做新功能验证和技术预研但生产环境还是守着 8.0 LTS 或等 8.4 LTS 稳定了再考虑。你的业务不会因为版本号新而变得更快反而可能因为激进升级引入不可控风险。5. 一些真实感受折腾完这一整套我最大的感受是读写分离根本不是某个版本“支持”一下就能搞定的事它是主从复制、路由策略、高可用、数据一致性四件事交织在一起的长跑。MySQL 8.2 确实带来了一些底层性能优化也让 Router 的配合更顺滑但你要是直接说“MySQL 8.2 支持读写分离了”那是对架构设计的一种简化也是对这个话题的误解。如果让我给新人一个建议我会说先把主从复制玩透再上 Router最后再考虑要不要碰 ProxySQL。跑通一套基础读写分离不难真正难的是一致性保证和故障切换时的业务兜底。别被版本号的营销噱头带偏先把地基打牢比什么都强。 
长河君 · 2026/10/14 22:02:56 · 阅读 1.2k MySQL 8.2支持读写分离？拆解主从复制与Router路由架构
看到这个标题我第一反应是看了一眼日历——确认今天不是愚人节。MySQL 8.2 支持读写分离了我差点把手边的水杯碰倒。作为一个从 MySQL 5.5 时代一路折腾到 8.x 的老家伙我对“原生读写分离”这几个字太敏感了。但冷静下来翻了翻发行说明只能说这个说法有水分且听我慢慢拆。先说最要紧的结论MySQL 8.2 并没有直接在服务端内置一个“读写分离开关”。读和写走不同的节点仍然是靠主从复制加路由层配合完成的。但 8.2 作为 Innodb 和复制链路的一个“创新版本”确实把很多底层能力打磨得更顺了加上官方在 Router 和连接器上的持续发力才让不少人产生了“8.2 支持读写分离”的误解。这篇文章我就把这层窗户纸捅破讲讲 8.2 到底改了什么、读写分离的本质是什么、以及怎么在真实环境里搭一套能跑的方案。1. 先泼盆冷水MySQL 8.2 到底“支持”了什么1.1 版本号背后的恩怨Innovation Release 与 LTS 之谜很多同学看到 8.2下意识以为这是 8.0 的下一个大版本就像当年 5.7 升 8.0 一样。实际上 MySQL 从 8.1 开始调整了发布节奏把版本分成两类Innovation Release创新版和Long Term Support长期支持版。8.0.34 是 8.0 系列的最后一个 LTS之后 8.1、8.2、8.3 都属于创新版每三个月左右发一个特性激进、支持周期短通常只有到下一个创新版发布为止。真正的下一代长期支持版是 8.4 LTS。所以你如果跑的是 8.2想靠这个版本“一劳永逸”撑几年那是想多了。这也解释了为什么 8.2 出来后社区里关于“读写分离”的声音突然变多了。创新版更新频率高官方在版本说明里提到了一些与 Router、复制性能相关的改动营销语境下很容易被放大成“内置读写分离”。但真相是读写分离从来都不是一个单节点上的功能而是整套架构具备的能力。1.2 8.2 在 Innodb 和复制链路上的真实变化那 8.2 有没有干活有但干的是底层苦力活不是前端那个光鲜的功能开关。8.2 对 InnoDB 的只读事务和读视图read view管理做了进一步优化在高并发只读场景下锁竞争和事务启动开销比 8.0 末尾版本更低。同时复制链路上的并行复制能力也持续增强从库在应用 binlog 时能更好地利用多线程。这些改进放在读写分离架构里意味着从库承受只读洪峰时更抗压延迟相对更小。不过要泼第二盆冷水这些优化是“锦上添花”不是“雪中送炭”。如果你在 8.0.30 上把主从复制参数调好了架构本身不会因为升到 8.2 就产生质变。那为什么标题会认为“牛掰支持读写分离了”我推测真正的主角是官方 Router 与连接器的配套增强。MySQL Router 在 8.2 时代已经非常成熟它读 MySQL 副本集拓扑信息自动区分 PRIMARY 和 SECONDARY然后按策略路由流量。加上官方连接器对 Router 的透明支持变好很多用户体验下来感觉就是“升级到 8.2业务读写自动分流了”。实际上分流的是 Router不是 MySQL 内核。2. 读写分离的本质主从复制 路由层的组合拳2.1 主从复制读写分离的地基一砖一瓦都不能歪读写分离这套东西底层的地基是主从复制。主库写 binlog从库拉取 binlog 并重放数据从一个节点流到另一个节点。没有复制你没法把读流量打到从库上因为数据对不上。复制有个关键点数据永远有延迟。哪怕半同步复制也只保证主库提交时事务日志至少被一个从库接收了但从库什么时候重放完没人给你打保票。这带了第一个设计原则能容忍短时间读到旧数据的业务才适合读写分离不能容忍的老老实实全部走主库。地基怎么打现代 MySQL 我建议直接上 GTID。8.2 里 GTID 是默认推荐开启的主从之间用 GTID 自动定位位点比老式的MASTER_LOG_FILE和MASTER_LOG_POS省心太多。以前我踩过人工选错日志位点导致复制管道错乱的坑换了 GTID 之后再没犯过这种低级错误。2.2 路由层才是关键Router、ProxySQL 还是应用层复制搭好了真正决定读写分离能不能优雅落地的是路由层。我见过不少团队把“读写分离”等同于“搭主从”结果从库建了一堆应用根本没用上。流量不会自动分流必须在某个位置做路由判断。主流方案有四种方案路由位置优点缺点MySQL Router连接层部署轻、零侵入、官方维护路由规则相对简单单点需要守护ProxySQLSQL层规则灵活、可灰度、可缓存多一层架构运维难度上升应用层框架业务代码控制最细、事务感知最准侵入代码每个语言都要实现一遍中间件注册中心配置中心可动态切换重小团队没必要在这四个里MySQL Router 是官方配套和 8.2 的“读写分离”话题绑定最紧。它有两个监听端口一个指向 PRIMARY一个指向 SECONDARY。业务只配两个地址Router 帮你把流量分发出去。更妙的是它能识别异步复制拓扑主从切换后自动调整路由目标。ProxySQL 则是老牌网红支持按用户、按 schema、按正则表达式做查询路由。比如SELECT走从库、INSERT/UPDATE/DELETE走主库。但它本质上是个代理多一跳就会多一层延迟和故障点不是必须就尽量别上。2.3 高可用加持MGR 与读写分离如何协同读写分离和高可用通常一起出现。MySQL 8.2 时代Group ReplicationMGR已经是成熟方案。MGR 是一种多主或单主模式的复制集群成员间通过 Paxos 协议选主节点挂掉后自动切换 PRIMARY。把 MGR 和读写分离结合就是一套挺经典的架构MGR 负责高可用主库宕机自动选出新主。Router 负责读写分离监听 MGR 的拓扑变化把写流量交给新 PRIMARY。从库甚至 MGR 里的其他节点负责扩展读能力。这样组合下来业务侧几乎无感知。我实际验证过杀掉 PRIMARY 之后Router 切换到新主的时间窗口大约在十几秒到几十秒取决于探测间隔和故障检测速度。这个窗口期应用可能报短连接失败所以应用层必须有重试机制否则光有架构还不够。3. 动手实践从零搭建一套 MySQL 8.2 读写分离架构3.1 规划环境与版本选型理论说完了开始动手。我这次用的是一主一从的经典拓扑两个节点跑的都是 MySQL 8.2Router 用官方 8.2 配套版本。操作系统是干净的 Linux 测试环境SELinux 直接 disabled防火墙先关掉不然一会儿 3306、6446、6447 端口互相访问会被折腾疯。节点规划如下角色主机名IP端口PRIMARYdb-primary192.168.1.103306SECONDARYdb-secondary192.168.1.113306Routerrouter01192.168.1.126446/6447选型上我的建议是如果你在 8.0 上已经有生产业务别为了“支持读写分离”这句话特意升 8.2。8.2 是创新版支持周期短适合测试环境和想要尝鲜新特性的场景。生产环境求稳等 8.4 LTS 出来再评估迁移。3.2 主库、从库配置实战主库配置最关键的是开 binlog、开 GTID、配 server-id。我把最小可用配置贴出来[mysqld] server-id 1 log-bin mysql-bin binlog_format ROW gtid_mode ON enforce_gtid_consistency ON binlog_expire_logs_seconds 604800binlog_format我用了 ROW因为混合模式在跨版本升级和特殊 SQL 下容易出妖蛾子。ROW 模式日志量大一点但一致性最好。binlog_expire_logs_seconds设置 7 天防止磁盘被日志打满。从库配置稍微多点[mysqld] server-id 2 read_only ON skip_replica_start ON gtid_mode ON enforce_gtid_consistency ONread_only ON是必须的防止有人不小心直连从库写数据。skip_replica_start的意思是实例启动后不要自动开始复制等我把复制源配好再手动启动避免启动顺序错乱导致复制线程异常。3.3 用 MySQL Router 完成自动路由两个数据库节点启动后创建复制用户并建立复制链路。这一步比较机械但细节容易错。主库上执行CREATE USER repl% IDENTIFIED BY YourPass123; GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl%;从库上执行CHANGE REPLICATION SOURCE TO SOURCE_HOST 192.168.1.10, SOURCE_USER repl, SOURCE_PASSWORD YourPass123, SOURCE_AUTO_POSITION 1; START REPLICA;SOURCE_AUTO_POSITION 1是关键它让从库通过 GTID 自动找到主库的 binlog 位点不需要手工填日志文件名和偏移量。这在 8.2 里是默认推荐的复制方式。确认复制正常SHOW REPLICA STATUS\G重点看Replica_IO_Running和Replica_SQL_Running都是YesSeconds_Behind_Source为 0。接下来是 Router 的配置。Router 支持--bootstrap自动配置这条命令会连上主库抓取拓扑信息生成一份配置文件mysqlrouter --bootstrap root192.168.1.10:3306 \ --directory /opt/mysql-router \ --usermysqlrouter执行完以后主目录下会生成mysqlrouter.conf。打开看一眼里面已经自动生成了两个 routing 组。但是自动生成的配置往往要按场景调一调我最终调整成这样的关键段[routing:primary] bind_address 0.0.0.0 bind_port 6446 destinations 192.168.1.10:3306,192.168.1.11:3306 routing_strategy first-available [routing:secondary] bind_address 0.0.0.0 bind_port 6447 destinations 192.168.1.10:3306,192.168.1.11:3306 routing_strategy round-robin注意primary组里我把主从两个节点都放进去了routing_strategy first-available保证写流量永远落在第一个可用节点上也就是 PRIMARY。secondary组用round-robin轮流把读流量分散到主从两个节点。等等读流量会打到主库上对。这是很多人的误区——读写分离不代表主库不承担读。如果你希望从库扛所有读压力可以在destinations里只写从库的地址。但从架构冗余角度主库也参与只读路由既能分摊压力也能在主从切换后避免路由黑洞。3.4 验证读写分离与故障切换配置完 Router启动它mysqlrouter --config /opt/mysql-router/mysqlrouter.conf 接着用客户端测两个端口mysql -h 192.168.1.12 -P 6446 -u testuser -p -e SELECT server_id; mysql -h 192.168.1.12 -P 6447 -u testuser -p -e SELECT server_id;server_id能看出当前连接落在哪个节点上。正常情况下6446 返回 1主库6447 按轮询返回 1 或 2。多执行几次 6447 的查询你能看到 server_id 在 1 和 2 之间切换说明读流量确实被分发到了两个节点。别忘了在实际业务表上做一次验证在主库插入一条记录从库执行SELECT COUNT(*)能看到这条记录然后通过 6447 端口也能查到说明数据链路通、路由也通。故障切换验证比较暴力。我直接kill -9掉主库的 mysqld 进程然后观察 Router 的日志。用first-available策略时Router 会探测到主库不可用把写流量自动切到备节点上。这个过程中业务侧可能报出几次连接错误但新连接会在探测周期结束后恢复正常。切记Router 不是零感知切换应用层要做好短连接重试。4. 实战避坑延迟、路由和版本回退4.1 主从延迟与一致性读己之写怎么解决读写分离第一个大坑就是“读己之写”。用户提交一个表单下一秒刷新页面结果查从库发现数据还没同步过来页面空空如也。这在生产环境算事故级别。解决思路无非几种关键业务强制穿透读主库把必须实时的数据操作在代码里标注为走 PRIMARY 连接。比如 mysql 驱动里配置 HINT或者单独开一个数据源。合理容忍短暂延迟大部分展示型数据延迟一两秒根本看不出来没必要所有请求都穿透。从库并行复制调优加大并行复制线程数把延迟压到毫秒级。可以在从库配置里加slave_parallel_type LOGICAL_CLOCK slave_parallel_workers 8但线程数不要盲调太高我曾经在一个 16 核的机器上把slave_parallel_workers调到 32结果从库复制冲突频繁反而比 8 线程还慢。具体线程数要结合主库写并发来观察。4.2 Router 路由失效问题排查Router 最常出问题的地方是“配置看着没问题但流量就是不分流”。排查思路我建议按这个顺序来先确认业务连的是 Router 的端口而不是数据库裸端口。真有人配完 Router 忘了改应用连接串。看 Router 日志。默认日志路径在配置目录下/opt/mysql-router/log/mysqlrouter.log。如果拓扑抓取失败日志里会有明显报错。用mysqlrouter --verify-config校验配置文件的语法和连通性。还有一个高频问题因为事务内读不需要分离。比如一个事务里先UPDATE再SELECT如果 SELECT 走了从库而主库的变更还没同步过去事务内部读到旧值就闹笑话了。Router 是全连接级路由感知不到事务状态所以需求复杂时还得靠 ProxySQL 或应用层。这个取舍要心里有数。4.3 半同步复制配置不当引发丢数据读写分离场景下很多人认为主库写完就完事了从库丢了再从主库拉。这话对异步复制成立但在某些金融类业务里不可接受。MySQL 8.2 支持半同步复制可以保证事务提交前binlog 已经传给了至少一个从库。半同步配置其实不复杂主库装插件INSTALL PLUGIN rpl_semi_sync_source SONAME semisync_source.so; SET GLOBAL rpl_semi_sync_source_enabled 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;注意rpl_semi_sync_source_timeout 1000这个参数。它的意思是如果从库 ACK 超时超过 1000 毫秒主库自动降级为异步复制保证主库写入不卡死。这是双刃剑从库网络抖动时一致性保护会短暂失效。我见过有人把这个值设成 60000结果从库宕机后主库写入直接阻塞一分钟业务大面积超时。合理值应该是几百毫秒到 2 秒之间具体看你对一致性和可用性的取舍。4.4 版本回退与升级路径建议最后聊版本。如果你真在测试环境把 8.2 跑起来了想回退到 8.0 系列有两个麻烦一是 GTID 模式默认开启后直接降级到不支持 GTID 的旧配置会失败。降级前要先把复制停掉清理 GTID 执行记录或者干脆重新搭建从库。二是 ROW 格式的 binlog 在跨大版本升级后可能不被旧版本识别。严谨的降级流程应该是停止写入、确认主从数据一致、备份、然后在新实例上导入备份而不是直接把数据目录指回去。我的实际建议是8.2 这类创新版适合拿来做新功能验证和技术预研但生产环境还是守着 8.0 LTS 或等 8.4 LTS 稳定了再考虑。你的业务不会因为版本号新而变得更快反而可能因为激进升级引入不可控风险。5. 一些真实感受折腾完这一整套我最大的感受是读写分离根本不是某个版本“支持”一下就能搞定的事它是主从复制、路由策略、高可用、数据一致性四件事交织在一起的长跑。MySQL 8.2 确实带来了一些底层性能优化也让 Router 的配合更顺滑但你要是直接说“MySQL 8.2 支持读写分离了”那是对架构设计的一种简化也是对这个话题的误解。如果让我给新人一个建议我会说先把主从复制玩透再上 Router最后再考虑要不要碰 ProxySQL。跑通一套基础读写分离不难真正难的是一致性保证和故障切换时的业务兜底。别被版本号的营销噱头带偏先把地基打牢比什么都强。