四年前我接手了一套业务系统的数据库改造方案定的是MyCat中间件加双主双从MySQL核心目标就是高可用和读写分离。当时系统长期跑在单机MySQL上——库表一百多张读写全走同一台实例白天高峰期主库CPU经常飘到80%以上凌晨的备份窗口也越拉越长。后来一次磁盘故障直接让业务停了半天改造才正式被提上日程。那时候网上能查到的教程大多是单主单从的demo真正把双主双向复制、MyCat故障切换、读写分离这三件事完整串起来讲的非常少。本文是那次改造的完整复盘第1章先把架构原理、MySQL双主搭建、MyCat读写分离配置和高可用切换验证讲清楚适合正在做数据库高可用改造的DBA、后端开发者和架构师参考。1. 单机MySQL撑不住的三个信号以及双主双从的解法1.1 读写相互拖累是引入读写分离的最直接原因业务系统进入稳定期之后读请求会远超写请求这是几乎所有应用的通病。尤其报表查询、列表分页这类SQL一条就能把CPU和IO打满期间所有写操作都得跟着排队。我在改造前做过一次慢查询统计系统中90%以上的慢SQL都是纯查询而且很多查的还是同一个大表。这时候最自然的思路就是把读和写拆开让写库专心处理事务让读库去扛查询压力。读写分离的本质是通过复制机制把同一份数据冗余到多台机器然后按操作类型路由。MySQL的binlog复制天然适合干这件事主库产生binlog从库拉取并回放数据会以一个很小的延迟正常情况亚秒级到达从库。中间件层则负责把select路由到从库、把insert/update/delete路由到主库。这个模型简单直接也是生产环境用得最多的方案。1.2 单主单从为什么还不够单主单从确实是最基础的读写分离形态但它有一个明显短板——主库是单点。主库磁盘坏了或者服务器宕机业务就只剩下读能力写操作全部中断。而且从库的数据是单向依赖主库的主库挂了之后从库虽然还活着却没法提升为新主库继续接收写入因为它的数据可能已经和应用层之间有滞后直接提升会产生数据丢失或主键冲突。要解决主库的单点问题常规做法就是在中间件层配置两个writeHost正常情况下写第一个第一个挂了自动切到第二个。这两个writeHost对应底层两台真实的MySQL主库两台主库之间再做双向复制保证任何一台宕机时另一台的数据仍然完整。这就是双主的含义。至于双从其实是为了让读能力也冗余起来双主各自挂一个从库读请求就可以均衡到两台从库上主库的压力进一步下降。1.3 双主双从架构的适用边界双主双从不是银弹它解决的是读写分离主库高可用读能力横向扩展这三个问题。如果写请求量极大、单库写入都扛不住那要研究的是分库分表而不是双主双从。如果业务对数据一致性要求苛刻到不能容忍亚秒级延迟的读读写分离本身就要打问号得靠缓存或队列做异步补偿。如果团队没有专职的DBA或运维角色四台MySQL的复制链路维护成本也会成为一个负担。所以在做这个架构之前我建议先认真画一遍当前系统的读写比例、峰值QPS、数据量和故障容忍度。双主双从适合的是读远大于写、写库不能挂、能接受短时间主从延迟读的业务。明确了边界再动手后面会遇到的问题会少一大半。2. 双主双从的整体拓扑角色分工与复制路径设计2.1 四台MySQL的角色与数据流我当时的部署环境是四台MySQL节点角色划分如下表节点角色复制来源职责M1主库1主写接收M2的binlog正常情况下承担全部写流量M2主库2备写/读接收M1的binlogM1宕机后接管写平时参与读负载S1从库1读接收M1的binlog承担读流量S2从库2读接收M2的binlog承担读流量这里有个容易混淆的点M1和M2互为主从所以两者都开启了binlog也都开启了log_slave_updates参数。S1只从M1拉取binlogS2只从M2拉取binlog这样每条写操作只要进了M1就能通过M1→M2→S2这条链路最终到达S2同理进了M2的写操作也会通过M2→M1→S1到达S1。四条复制链路形成了完整的数据闭环任何一台机器挂掉数据都还能在其他节点上找到完整副本。2.2 MyCat在架构中的位置MyCat是应用和MySQL之间的数据库中间件对应用层暴露一个MySQL协议端口默认8066应用把MyCat当成一个普通MySQL实例来连。MyCat收到SQL后根据配置的读写分离规则和分片规则把SQL转发到后端的某台真实MySQL上执行。在这个架构里MyCat承担了三层职责写路由按照writeType参数决定写SQL发给哪个writeHost默认写第一个也就是M1。读负载均衡按照balance参数决定读SQL如何在多个节点之间分摊。高可用切换通过心跳检测感知后端MySQL的存活状态主库不可用时自动把写流量切到另一台writeHost。这三层职责都集中在MyCat的schema.xml这一个配置文件里完成配置量不大但对参数的理解直接决定了这套架构是否真的高可用。后面第4节会详细拆解这些参数。2.3 为什么选了MyCat而不是其他中间件当年做选型时也对比过其他方案包括几个常见的数据中间件。选择MyCat有几个实际考量schema.xml配置非常直观读写分离、双主切换这类场景就是几个属性的事团队上手成本低社区活跃度高踩了坑能查到解决方案再加上团队本身就是Java技术栈MyCat也是Java写的遇到问题可以翻源码定位团队有这个能力。当然这不是说MyCat在所有场景都最优。如果项目是从零开始的Java微服务直接集成客户端模式的中间件或许更顺滑如果追求更精细的读写分离控制或者需要针对后端做更复杂的心跳检查其他方案也有各自的优势。选型还得结合团队维护能力和现有架构工具是拿来解决问题的不用迷信某一个。3. MySQL层双主双向复制搭建参数、步骤与验证3.1 关键参数server-id与自增策略双主复制有一个核心风险两台主库同时收到写入时自增主键可能冲突。比如应用层由于某种误配置把写流量同时切到了M1和M2两边同时插入id100的记录双向复制就会因为主键冲突而中断。规避这个问题要靠MySQL的自增偏移参数。我在M1和M2上分别做了如下配置my.cnf# M1的my.cnf关键配置 [mysqld] server-id 1 log-bin mysql-bin binlog-format ROW log_slave_updates ON sync_binlog 1 auto_increment_offset 1 auto_increment_increment 2 expire_logs_days 7# M2的my.cnf关键配置 [mysqld] server-id 2 log-bin mysql-bin binlog-format ROW log_slave_updates ON sync_binlog 1 auto_increment_offset 2 auto_increment_increment 2 expire_logs_days 7auto_increment_increment2表示自增步长为2auto_increment_offset1表示M1从奇数开始、offset2表示M2从偶数开始。这样M1插入的自增主键永远是奇数M2永远是偶数即使双写也不会撞车。这个参数一定要在初始化数据之前配好否则对已经存在的表不会自动生效。binlog-format建议用ROW它记录的是行级变更比STATEMENT模式更可靠在双向复制场景下能显著减少因函数、触发器产生的数据不一致。3.2 初始化数据与建立双向复制两台主库的数据基线必须一致双向复制才能成立。我当时先停掉应用写流量用mysqldump从M1导出全量数据再导入M2# 在M1上导出--master-data会自动记录当前binlog位置 mysqldump -uroot -p --single-transaction --master-data2 \ --routines --events --triggers test_db /tmp/test_db_init.sql # 在M2上导入 mysql -uroot -p test_db /tmp/test_db_init.sql--single-transaction配合InnoDB可以在不锁表的情况下获得一致性快照是生产环境导出数据最常用的方式。导出完成后用head查看一下SQL文件开头能看到类似-- CHANGE MASTER TO MASTER_LOG_FILEmysql-bin.000003, MASTER_LOG_POS154;这样的注释这就是M1当前的binlog位置待会儿配置复制要用。接着在两台主库上分别创建复制账号并建立互为主从关系-- 在M1和M2上都执行 CREATE USER repl192.168.1.% IDENTIFIED BY Repl123; GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl192.168.1.%; FLUSH PRIVILEGES;-- 在M2上执行让M2成为M1的从库 CHANGE MASTER TO MASTER_HOST192.168.1.1, MASTER_PORT3306, MASTER_USERrepl, MASTER_PASSWORDRepl123, MASTER_LOG_FILEmysql-bin.000003, MASTER_LOG_POS154; START SLAVE;-- 在M1上执行让M1成为M2的从库 CHANGE MASTER TO MASTER_HOST192.168.1.2, MASTER_PORT3306, MASTER_USERrepl, MASTER_PASSWORDRepl123, MASTER_LOG_FILEmysql-bin.000001, MASTER_LOG_POS4; START SLAVE;M2从M1同步时用的binlog位置来自导出文件的注释M1从M2同步时用的位置则是M2刚开始导库时的初始位置。这点稍有绕实际操练时要对着binlog文件和pos逐一确认两个CHANGE MASTER语句写错任何一个复制就会卡在连接阶段或者从错误的位置开始回放。3.3 从库搭建与复制状态验证双从的搭建相对简单。S1执行CHANGE MASTER指向M1S2执行CHANGE MASTER指向M2从库的my.cnf配置略有不同# S1 / S2的my.cnf关键配置S1用server-id3S2用server-id4 [mysqld] server-id 3 relay-log relay-bin read_only ON从库开启read_only是必须的防止有人直接连到从库上写数据破坏复制的一致性。不过read_only对复制线程本身无效主库同步过来的写操作依然能正常执行。配置完成后在四台机器上分别执行SHOW SLAVE STATUS确认关键状态SHOW SLAVE STATUS\G -- 重点看这三行 Slave_IO_Running: Yes Slave_SQL_Running: Yes Seconds_Behind_Master: 0两个线程都显示Yes且延迟为0复制链路就是健康的。IO线程负责从主库拉取binlog并写入中继日志SQL线程负责回放中继日志。任何一个不是Yes都要立刻去MySQL的错误日志里查原因。最后做一个全链路验证往M1插入一条数据检查M2、S1、S2是否都能查到再往M2插入一条数据检查M1、S1、S2是否都能查到。这一步能同时验证双向复制和两级复制的正确性。我当时还顺手验证了从库的read_only确实生效——直接在S1上执行INSERT会被拒绝但通过主库同步过来的INSERT可以正常落库。4. MyCat读写分离配置schema.xml与server.xml核心参数4.1 balance、writeType、switchType三个参数决定一切MyCat的dataHost配置里有三个必须吃透的参数它们直接决定了读写分离和高可用行为。balance控制读负载均衡策略取值行为0不开启读写分离读操作全部发给当前writeHost1读操作在全部readHost和备用writeHost之间分摊2读操作随机在writeHost和readHost之间分发3读操作只发给readHostwriteHost不承担读压力双主双从架构下最常用的是balance1。此时M1作为主writeHost不参与读M2备用writeHost、S1、S2三台共同承担读流量读写压力分离得比较彻底。如果希望主库完全专注于写就用balance3只让S1和S2扛读代价是M2的硬件利用率会低一些。writeType控制写路由策略0表示写操作固定发给第一个writeHostM1M1不可用时切到下一个1表示写操作随机发给任意一个writeHost。对双主架构来说writeType0是正确选择——正常情况下所有写都走M1M1挂了自动切M2。如果设成1写流量会在两台主库间随机分发虽然避免了单点但会放大双主自增冲突的风险一般不建议。switchType控制自动切换策略-1表示不自动切换1表示心跳检测失败就自动切换2表示基于show slave status的复制状态决定是否切换3是Galera集群专用。对普通双主复制switchType1配合心跳语句select user()就够了。把switchType改成2可以获得更精细的控制但前提是MyCat连后端MySQL的账号必须有REPLICATION CLIENT权限心跳语句也要换成show slave status。4.2 完整配置schema.xml和server.xml示例我的schema.xml配置如下IP和密码已脱敏?xml version1.0? !DOCTYPE mycat:schema SYSTEM schema.dtd mycat:schema xmlns:mycathttp://org.opencloudb/ schema nameTESTDB checkSQLschematrue sqlMaxLimit100 table namet_user dataNodedn1/ /schema dataNode namedn1 dataHostlocalHost1 databasetest_db/ dataHost namelocalHost1 maxCon1000 minCon10 balance1 writeType0 dbTypemysql dbDrivernative switchType1 slaveThreshold100 heartbeatselect user()/heartbeat writeHost hostM1 url192.168.1.1:3306 usermycat passwordMycat123 readHost hostS1 url192.168.1.3:3306 usermycat passwordMycat123 weight1/ /writeHost writeHost hostM2 url192.168.1.2:3306 usermycat passwordMycat123 readHost hostS2 url192.168.1.4:3306 usermycat passwordMycat123 weight1/ /writeHost /dataHost /mycat:schema几个细节补充一下schema里的table节点可以只配置核心表也可以不配置table直接走默认dataNode。第1章用单表演示足够分片规则后续章节再展开。slaveThreshold100表示当某个从库的复制延迟超过100秒时MyCat不再把读请求路由给它避免读到过旧的数据。这个参数对读写分离的数据新鲜度非常关键。maxCon/minCon是MyCat到后端MySQL的连接池参数。maxCon太大后端会被打爆太小高峰期会频繁创建连接导致延迟我这里1000/10只是一个参考值生产环境要结合后端max_connections一起算。server.xml里的用户配置是应用连接MyCat时使用的账号mycat:server xmlns:mycathttp://org.opencloudb/ system property namedefaultSqlParserdruidparser/property /system user nameapp_user defaultAccounttrue property namepasswordApp123456/property property nameschemasTESTDB/property property namereadOnlyfalse/property /user /mycat:server同时还要在四台后端MySQL上创建MyCat用来连接它们的账号-- 在M1、M2、S1、S2上分别执行 CREATE USER mycat192.168.1.% IDENTIFIED BY Mycat123; GRANT ALL PRIVILEGES ON *.* TO mycat192.168.1.%; FLUSH PRIVILEGES;这里要注意MyCat后端账号不能设成read_only因为它既要连主库写、也要连从库读。如果从库开了read_only只影响应用直连的写操作不影响MyCat读取数据。4.3 启动MyCat并验证读写分离效果配置完成后进入MyCat的bin目录启动./mycat start # 查看状态和日志 ./mycat status tail -f ../logs/mycat.log启动后用应用账号连接MyCatmysql -uapp_user -pApp123456 -h127.0.0.1 -P8066USE TESTDB; -- 写操作 INSERT INTO t_user(name) VALUES(zhangsan); -- 读操作 SELECT * FROM t_user;怎么确认读写真的分离了最直接的办法是在四台MySQL上分别开启general_log或者看processlistSHOW PROCESSLIST;如果配置正确INSERT会出现在M1的processlist中SELECT会出现在S1或S2取决于负载均衡策略的processlist中。我当时验证时还顺手做了一个小实验把S1上的t_user某一行数据手动改成错误值再连MyCat反复执行SELECT能同时查到正确值和错误值证明读请求确实被分发到了不同的从库。验证完成后再把S1的数据改回来避免污染后续测试。5. 高可用切换机制与故障演练记录5.1 MyCat如何感知主库宕机MyCat对后端MySQL的存活检测靠的就是dataHost里的heartbeat语句。默认每隔一段时间会向每个writeHost和readHost发送heartbeat如果连续几次都没有响应MyCat就判定该节点不可用。writeHost不可用的处理逻辑是找到当前可用的下一个writeHost把写流量切过去。readHost不可用则相对简单只是把它从读负载均衡的候选集合里移除不影响整体读写。这里有一个容易被忽略的细节readHost是挂在writeHost下面的。如果M1挂了它下面挂的S1也会被连带标记为不可用因为MyCat认为M1都不通了S1这个从库大概率也失去了数据来源。所以M1宕机后可用的读节点会变成S2和M2写节点变成M2。这个行为是合理的但如果S1其实还活着且数据可用就会被白白牺牲掉——这是架构设计时必须接受的取舍解决办法是在应用层做兜底而不是试图绕过这个机制。5.2 演练停掉Master1之后发生了什么故障演练强烈建议在测试环境做而且要做完整记录。以下是当年演练的真实过程。第一步模拟故障# 在M1上执行 systemctl stop mysqld第二步观察MyCat日志。日志里会出现连续的heartbeat失败记录几秒后能看到类似switch write host的切换日志。我当时的切换等待时间大概在5到10秒之间取决于心跳间隔和失败判断次数。第三步从应用侧验证。继续通过MyCat执行INSERT和SELECT。INSERT会成功因为MyCat已经把写目标切到了M2SELECT也会成功因为读节点自动切换到了S2和M2。整个故障切换期间应用不用改任何配置已有的连接可能会因为后端切换而报一次错但新连接会立即走上新路由。第四步检查复制链路。M1宕机后M2的复制IO线程会不断重连S1则因为主库不可用而停在原地。这时候S1的Seconds_Behind_Master可能显示NULL因为复制线程没有活跃的链路。这是正常的等M1恢复后会自动追平。5.3 恢复流程与脑裂预防M1恢复后不能直接把它当成主库接回去。当时我的恢复流程是这样的启动M1的MySQL确认M1从M2追平数据SHOW SLAVE STATUS两个线程都是Yes延迟为0。在M1上写入一条测试数据验证M2能同步到反向链路也正常。如果确认数据一致再考虑是否把写主切回M1。这里必须说清楚MyCat默认不会自动切回。M1恢复后写流量依然在M2上除非手动重启MyCat或者通过运维脚本切换。我当时写了一个切换脚本在确认数据一致后把写流量切回M1避免M2长期承担写压力。自动切回不是不行但要非常谨慎——如果M1恢复后数据没追平就切回去应用层新写入的数据会落在M1上而M2上可能还有M1宕机期间的增量数据两边一合并就是数据丢失或覆盖。双主架构还有一个必须预防的风险脑裂。如果M1和M2之间的网络被切断但两台机器都活着应用层在异常场景下可能出现两边都收到写请求的情况两台主库各自写入各自的数据复制恢复时就会主键冲突、环路复制。规避手段有三个层面一是MyCat层保证同一时刻只有一个writeHost接收写流量二是网络层面保证心跳和复制走不同链路三是操作层面任何一次手工切换都要先确认另一台真的停了、数据真的追平了。架构可以帮你降低风险但最后的兜底永远是操作规范。6. 生产落地最容易踩的五个坑6.1 自增主键冲突参数配了但业务表早就有数据了auto_increment_offset和auto_increment_increment只对新建表生效。如果业务表已经存在并且之前的主键已经到了10万M1同步过来的AUTO_INCREMENT值可能和M2本地的值重叠。比如M1当前自增到10001M2当前自增到9999两边同时插入一个生成10002一个生成10000刚好错开但再过一阵子两边都涨到20000附近就可能撞上。稳妥的做法是搭建完成后把业务核心表的主键自增初始值手动调成和主库一致ALTER TABLE t_user AUTO_INCREMENT 20001;如果业务上可以接受更彻底的做法是放弃数据库自增主键改用全局IDMyCat的全局序列号功能或者应用层发号器这样双主冲突问题从根上消失。这个主题后续章节会单独展开。6.2 log_slave_updates缺失复制链路莫名其妙断掉双主双从架构里两台主库都必须开启log_slave_updates参数。这个参数的意思是从库此刻M2是M1的从库在回放中继日志产生数据变更时这些变更也要写入自己的binlog。如果不开启M1写入的数据会同步到M2但M2不会把这些数据记入自己的binlog于是S2永远看不到这些数据。更危险的是如果此时M1宕机、M2接管写入S2缺失的那部分数据就再也补不回来了。这个参数MySQL默认是关闭的官方文档里的示例也没有特别强调非常容易踩。我在搭建时专门检查了四台机器的my.cnf确认M1和M2都开了log_slave_updatesS1和S2可以不关心这个参数它们只需要自己的relay log。6.3 连接数配置不当MyCat把后端MySQL打爆过MyCat的maxCon指的是单个dataHost到后端MySQL的总连接上限。我第一版配置里maxCon200看似合理但应用侧连接池有50个应用实例每个实例维持20个连接加上MyCat自身的后端连接池瞬间就能把后端MySQL的max_connections打穿。后来我把整条链路的连接数算了一遍应用连接池总数、MyCat的前端连接数、MyCat到后端的maxCon、MySQL的max_connections四者的关系必须层层有冗余。我的建议是后端MySQL的max_connections至少大于MyCat的maxCon乘以writeHost数量再留出至少50%的余量用于运维直连和意外高峰。6.4 主从延迟引发的脏读slaveThreshold设得太随意读写分离最怕读到旧数据。业务上如果有一条数据刚写入就要立刻读出来典型场景是下单后跳转到订单详情页走从库就可能在极端延迟下读到空或者旧状态。我当时做了一层双保险MyCat侧把slaveThreshold设成30秒超过30秒延迟的从库不参与读应用侧对关键读接口做了先查主库的路由开关。虽然牺牲了一点读写分离的比例但换来的是业务逻辑的正确性值。等后续把缓存加好之后读压力会进一步下降这个开关再慢慢放开。6.5 应用直连MyCat的常见误区连接池与事务应用侧把MyCat当作MySQL来连连接池配置容易踩两个坑。一是连接池的maxActive不能设得比MyCat的前端连接上限还大否则应用侧排队MyCat侧空闲两边的资源都在空转。二是事务一定要在同一个连接上完成——MyCat并不是一个分布式事务中间件如果应用的事务跨越了MyCat的多个后端连接MyCat会直接拒绝执行最好的做法是让事务内的SQL命中同一个dataNode并且只涉及一台后端MySQL。我在改造时就遇到过不少这个事务在直连MySQL时好好的走了MyCat就报错的问题最后定位下来全部是连接复用和事务路由的锅。解决办法说白了就是连接池显式设置事务隔离级别和自动提交MyCat这边把sqlMaxLimit和分片规则配清楚让SQL尽量落在单节点上。第1章的内容大致到这里。这套架构上线后稳定运行了两年多双主双从加MyCat的组合经受住了多次故障演练和真实宕机事件。我个人最大的体会是高可用架构的价值不在于它看起来多先进而在于每一次故障发生时业务能不能无感知地继续跑下去。下一章我会继续写分库分表规则和MyCat的全局序列号方案把数据量进一步增长之后遇到的问题也一并复盘。
四年前我接手了一套业务系统的数据库改造方案定的是MyCat中间件加双主双从MySQL核心目标就是高可用和读写分离。当时系统长期跑在单机MySQL上——库表一百多张读写全走同一台实例白天高峰期主库CPU经常飘到80%以上凌晨的备份窗口也越拉越长。后来一次磁盘故障直接让业务停了半天改造才正式被提上日程。那时候网上能查到的教程大多是单主单从的demo真正把双主双向复制、MyCat故障切换、读写分离这三件事完整串起来讲的非常少。本文是那次改造的完整复盘第1章先把架构原理、MySQL双主搭建、MyCat读写分离配置和高可用切换验证讲清楚适合正在做数据库高可用改造的DBA、后端开发者和架构师参考。1. 单机MySQL撑不住的三个信号以及双主双从的解法1.1 读写相互拖累是引入读写分离的最直接原因业务系统进入稳定期之后读请求会远超写请求这是几乎所有应用的通病。尤其报表查询、列表分页这类SQL一条就能把CPU和IO打满期间所有写操作都得跟着排队。我在改造前做过一次慢查询统计系统中90%以上的慢SQL都是纯查询而且很多查的还是同一个大表。这时候最自然的思路就是把读和写拆开让写库专心处理事务让读库去扛查询压力。读写分离的本质是通过复制机制把同一份数据冗余到多台机器然后按操作类型路由。MySQL的binlog复制天然适合干这件事主库产生binlog从库拉取并回放数据会以一个很小的延迟正常情况亚秒级到达从库。中间件层则负责把select路由到从库、把insert/update/delete路由到主库。这个模型简单直接也是生产环境用得最多的方案。1.2 单主单从为什么还不够单主单从确实是最基础的读写分离形态但它有一个明显短板——主库是单点。主库磁盘坏了或者服务器宕机业务就只剩下读能力写操作全部中断。而且从库的数据是单向依赖主库的主库挂了之后从库虽然还活着却没法提升为新主库继续接收写入因为它的数据可能已经和应用层之间有滞后直接提升会产生数据丢失或主键冲突。要解决主库的单点问题常规做法就是在中间件层配置两个writeHost正常情况下写第一个第一个挂了自动切到第二个。这两个writeHost对应底层两台真实的MySQL主库两台主库之间再做双向复制保证任何一台宕机时另一台的数据仍然完整。这就是双主的含义。至于双从其实是为了让读能力也冗余起来双主各自挂一个从库读请求就可以均衡到两台从库上主库的压力进一步下降。1.3 双主双从架构的适用边界双主双从不是银弹它解决的是读写分离主库高可用读能力横向扩展这三个问题。如果写请求量极大、单库写入都扛不住那要研究的是分库分表而不是双主双从。如果业务对数据一致性要求苛刻到不能容忍亚秒级延迟的读读写分离本身就要打问号得靠缓存或队列做异步补偿。如果团队没有专职的DBA或运维角色四台MySQL的复制链路维护成本也会成为一个负担。所以在做这个架构之前我建议先认真画一遍当前系统的读写比例、峰值QPS、数据量和故障容忍度。双主双从适合的是读远大于写、写库不能挂、能接受短时间主从延迟读的业务。明确了边界再动手后面会遇到的问题会少一大半。2. 双主双从的整体拓扑角色分工与复制路径设计2.1 四台MySQL的角色与数据流我当时的部署环境是四台MySQL节点角色划分如下表节点角色复制来源职责M1主库1主写接收M2的binlog正常情况下承担全部写流量M2主库2备写/读接收M1的binlogM1宕机后接管写平时参与读负载S1从库1读接收M1的binlog承担读流量S2从库2读接收M2的binlog承担读流量这里有个容易混淆的点M1和M2互为主从所以两者都开启了binlog也都开启了log_slave_updates参数。S1只从M1拉取binlogS2只从M2拉取binlog这样每条写操作只要进了M1就能通过M1→M2→S2这条链路最终到达S2同理进了M2的写操作也会通过M2→M1→S1到达S1。四条复制链路形成了完整的数据闭环任何一台机器挂掉数据都还能在其他节点上找到完整副本。2.2 MyCat在架构中的位置MyCat是应用和MySQL之间的数据库中间件对应用层暴露一个MySQL协议端口默认8066应用把MyCat当成一个普通MySQL实例来连。MyCat收到SQL后根据配置的读写分离规则和分片规则把SQL转发到后端的某台真实MySQL上执行。在这个架构里MyCat承担了三层职责写路由按照writeType参数决定写SQL发给哪个writeHost默认写第一个也就是M1。读负载均衡按照balance参数决定读SQL如何在多个节点之间分摊。高可用切换通过心跳检测感知后端MySQL的存活状态主库不可用时自动把写流量切到另一台writeHost。这三层职责都集中在MyCat的schema.xml这一个配置文件里完成配置量不大但对参数的理解直接决定了这套架构是否真的高可用。后面第4节会详细拆解这些参数。2.3 为什么选了MyCat而不是其他中间件当年做选型时也对比过其他方案包括几个常见的数据中间件。选择MyCat有几个实际考量schema.xml配置非常直观读写分离、双主切换这类场景就是几个属性的事团队上手成本低社区活跃度高踩了坑能查到解决方案再加上团队本身就是Java技术栈MyCat也是Java写的遇到问题可以翻源码定位团队有这个能力。当然这不是说MyCat在所有场景都最优。如果项目是从零开始的Java微服务直接集成客户端模式的中间件或许更顺滑如果追求更精细的读写分离控制或者需要针对后端做更复杂的心跳检查其他方案也有各自的优势。选型还得结合团队维护能力和现有架构工具是拿来解决问题的不用迷信某一个。3. MySQL层双主双向复制搭建参数、步骤与验证3.1 关键参数server-id与自增策略双主复制有一个核心风险两台主库同时收到写入时自增主键可能冲突。比如应用层由于某种误配置把写流量同时切到了M1和M2两边同时插入id100的记录双向复制就会因为主键冲突而中断。规避这个问题要靠MySQL的自增偏移参数。我在M1和M2上分别做了如下配置my.cnf# M1的my.cnf关键配置 [mysqld] server-id 1 log-bin mysql-bin binlog-format ROW log_slave_updates ON sync_binlog 1 auto_increment_offset 1 auto_increment_increment 2 expire_logs_days 7# M2的my.cnf关键配置 [mysqld] server-id 2 log-bin mysql-bin binlog-format ROW log_slave_updates ON sync_binlog 1 auto_increment_offset 2 auto_increment_increment 2 expire_logs_days 7auto_increment_increment2表示自增步长为2auto_increment_offset1表示M1从奇数开始、offset2表示M2从偶数开始。这样M1插入的自增主键永远是奇数M2永远是偶数即使双写也不会撞车。这个参数一定要在初始化数据之前配好否则对已经存在的表不会自动生效。binlog-format建议用ROW它记录的是行级变更比STATEMENT模式更可靠在双向复制场景下能显著减少因函数、触发器产生的数据不一致。3.2 初始化数据与建立双向复制两台主库的数据基线必须一致双向复制才能成立。我当时先停掉应用写流量用mysqldump从M1导出全量数据再导入M2# 在M1上导出--master-data会自动记录当前binlog位置 mysqldump -uroot -p --single-transaction --master-data2 \ --routines --events --triggers test_db /tmp/test_db_init.sql # 在M2上导入 mysql -uroot -p test_db /tmp/test_db_init.sql--single-transaction配合InnoDB可以在不锁表的情况下获得一致性快照是生产环境导出数据最常用的方式。导出完成后用head查看一下SQL文件开头能看到类似-- CHANGE MASTER TO MASTER_LOG_FILEmysql-bin.000003, MASTER_LOG_POS154;这样的注释这就是M1当前的binlog位置待会儿配置复制要用。接着在两台主库上分别创建复制账号并建立互为主从关系-- 在M1和M2上都执行 CREATE USER repl192.168.1.% IDENTIFIED BY Repl123; GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl192.168.1.%; FLUSH PRIVILEGES;-- 在M2上执行让M2成为M1的从库 CHANGE MASTER TO MASTER_HOST192.168.1.1, MASTER_PORT3306, MASTER_USERrepl, MASTER_PASSWORDRepl123, MASTER_LOG_FILEmysql-bin.000003, MASTER_LOG_POS154; START SLAVE;-- 在M1上执行让M1成为M2的从库 CHANGE MASTER TO MASTER_HOST192.168.1.2, MASTER_PORT3306, MASTER_USERrepl, MASTER_PASSWORDRepl123, MASTER_LOG_FILEmysql-bin.000001, MASTER_LOG_POS4; START SLAVE;M2从M1同步时用的binlog位置来自导出文件的注释M1从M2同步时用的位置则是M2刚开始导库时的初始位置。这点稍有绕实际操练时要对着binlog文件和pos逐一确认两个CHANGE MASTER语句写错任何一个复制就会卡在连接阶段或者从错误的位置开始回放。3.3 从库搭建与复制状态验证双从的搭建相对简单。S1执行CHANGE MASTER指向M1S2执行CHANGE MASTER指向M2从库的my.cnf配置略有不同# S1 / S2的my.cnf关键配置S1用server-id3S2用server-id4 [mysqld] server-id 3 relay-log relay-bin read_only ON从库开启read_only是必须的防止有人直接连到从库上写数据破坏复制的一致性。不过read_only对复制线程本身无效主库同步过来的写操作依然能正常执行。配置完成后在四台机器上分别执行SHOW SLAVE STATUS确认关键状态SHOW SLAVE STATUS\G -- 重点看这三行 Slave_IO_Running: Yes Slave_SQL_Running: Yes Seconds_Behind_Master: 0两个线程都显示Yes且延迟为0复制链路就是健康的。IO线程负责从主库拉取binlog并写入中继日志SQL线程负责回放中继日志。任何一个不是Yes都要立刻去MySQL的错误日志里查原因。最后做一个全链路验证往M1插入一条数据检查M2、S1、S2是否都能查到再往M2插入一条数据检查M1、S1、S2是否都能查到。这一步能同时验证双向复制和两级复制的正确性。我当时还顺手验证了从库的read_only确实生效——直接在S1上执行INSERT会被拒绝但通过主库同步过来的INSERT可以正常落库。4. MyCat读写分离配置schema.xml与server.xml核心参数4.1 balance、writeType、switchType三个参数决定一切MyCat的dataHost配置里有三个必须吃透的参数它们直接决定了读写分离和高可用行为。balance控制读负载均衡策略取值行为0不开启读写分离读操作全部发给当前writeHost1读操作在全部readHost和备用writeHost之间分摊2读操作随机在writeHost和readHost之间分发3读操作只发给readHostwriteHost不承担读压力双主双从架构下最常用的是balance1。此时M1作为主writeHost不参与读M2备用writeHost、S1、S2三台共同承担读流量读写压力分离得比较彻底。如果希望主库完全专注于写就用balance3只让S1和S2扛读代价是M2的硬件利用率会低一些。writeType控制写路由策略0表示写操作固定发给第一个writeHostM1M1不可用时切到下一个1表示写操作随机发给任意一个writeHost。对双主架构来说writeType0是正确选择——正常情况下所有写都走M1M1挂了自动切M2。如果设成1写流量会在两台主库间随机分发虽然避免了单点但会放大双主自增冲突的风险一般不建议。switchType控制自动切换策略-1表示不自动切换1表示心跳检测失败就自动切换2表示基于show slave status的复制状态决定是否切换3是Galera集群专用。对普通双主复制switchType1配合心跳语句select user()就够了。把switchType改成2可以获得更精细的控制但前提是MyCat连后端MySQL的账号必须有REPLICATION CLIENT权限心跳语句也要换成show slave status。4.2 完整配置schema.xml和server.xml示例我的schema.xml配置如下IP和密码已脱敏?xml version1.0? !DOCTYPE mycat:schema SYSTEM schema.dtd mycat:schema xmlns:mycathttp://org.opencloudb/ schema nameTESTDB checkSQLschematrue sqlMaxLimit100 table namet_user dataNodedn1/ /schema dataNode namedn1 dataHostlocalHost1 databasetest_db/ dataHost namelocalHost1 maxCon1000 minCon10 balance1 writeType0 dbTypemysql dbDrivernative switchType1 slaveThreshold100 heartbeatselect user()/heartbeat writeHost hostM1 url192.168.1.1:3306 usermycat passwordMycat123 readHost hostS1 url192.168.1.3:3306 usermycat passwordMycat123 weight1/ /writeHost writeHost hostM2 url192.168.1.2:3306 usermycat passwordMycat123 readHost hostS2 url192.168.1.4:3306 usermycat passwordMycat123 weight1/ /writeHost /dataHost /mycat:schema几个细节补充一下schema里的table节点可以只配置核心表也可以不配置table直接走默认dataNode。第1章用单表演示足够分片规则后续章节再展开。slaveThreshold100表示当某个从库的复制延迟超过100秒时MyCat不再把读请求路由给它避免读到过旧的数据。这个参数对读写分离的数据新鲜度非常关键。maxCon/minCon是MyCat到后端MySQL的连接池参数。maxCon太大后端会被打爆太小高峰期会频繁创建连接导致延迟我这里1000/10只是一个参考值生产环境要结合后端max_connections一起算。server.xml里的用户配置是应用连接MyCat时使用的账号mycat:server xmlns:mycathttp://org.opencloudb/ system property namedefaultSqlParserdruidparser/property /system user nameapp_user defaultAccounttrue property namepasswordApp123456/property property nameschemasTESTDB/property property namereadOnlyfalse/property /user /mycat:server同时还要在四台后端MySQL上创建MyCat用来连接它们的账号-- 在M1、M2、S1、S2上分别执行 CREATE USER mycat192.168.1.% IDENTIFIED BY Mycat123; GRANT ALL PRIVILEGES ON *.* TO mycat192.168.1.%; FLUSH PRIVILEGES;这里要注意MyCat后端账号不能设成read_only因为它既要连主库写、也要连从库读。如果从库开了read_only只影响应用直连的写操作不影响MyCat读取数据。4.3 启动MyCat并验证读写分离效果配置完成后进入MyCat的bin目录启动./mycat start # 查看状态和日志 ./mycat status tail -f ../logs/mycat.log启动后用应用账号连接MyCatmysql -uapp_user -pApp123456 -h127.0.0.1 -P8066USE TESTDB; -- 写操作 INSERT INTO t_user(name) VALUES(zhangsan); -- 读操作 SELECT * FROM t_user;怎么确认读写真的分离了最直接的办法是在四台MySQL上分别开启general_log或者看processlistSHOW PROCESSLIST;如果配置正确INSERT会出现在M1的processlist中SELECT会出现在S1或S2取决于负载均衡策略的processlist中。我当时验证时还顺手做了一个小实验把S1上的t_user某一行数据手动改成错误值再连MyCat反复执行SELECT能同时查到正确值和错误值证明读请求确实被分发到了不同的从库。验证完成后再把S1的数据改回来避免污染后续测试。5. 高可用切换机制与故障演练记录5.1 MyCat如何感知主库宕机MyCat对后端MySQL的存活检测靠的就是dataHost里的heartbeat语句。默认每隔一段时间会向每个writeHost和readHost发送heartbeat如果连续几次都没有响应MyCat就判定该节点不可用。writeHost不可用的处理逻辑是找到当前可用的下一个writeHost把写流量切过去。readHost不可用则相对简单只是把它从读负载均衡的候选集合里移除不影响整体读写。这里有一个容易被忽略的细节readHost是挂在writeHost下面的。如果M1挂了它下面挂的S1也会被连带标记为不可用因为MyCat认为M1都不通了S1这个从库大概率也失去了数据来源。所以M1宕机后可用的读节点会变成S2和M2写节点变成M2。这个行为是合理的但如果S1其实还活着且数据可用就会被白白牺牲掉——这是架构设计时必须接受的取舍解决办法是在应用层做兜底而不是试图绕过这个机制。5.2 演练停掉Master1之后发生了什么故障演练强烈建议在测试环境做而且要做完整记录。以下是当年演练的真实过程。第一步模拟故障# 在M1上执行 systemctl stop mysqld第二步观察MyCat日志。日志里会出现连续的heartbeat失败记录几秒后能看到类似switch write host的切换日志。我当时的切换等待时间大概在5到10秒之间取决于心跳间隔和失败判断次数。第三步从应用侧验证。继续通过MyCat执行INSERT和SELECT。INSERT会成功因为MyCat已经把写目标切到了M2SELECT也会成功因为读节点自动切换到了S2和M2。整个故障切换期间应用不用改任何配置已有的连接可能会因为后端切换而报一次错但新连接会立即走上新路由。第四步检查复制链路。M1宕机后M2的复制IO线程会不断重连S1则因为主库不可用而停在原地。这时候S1的Seconds_Behind_Master可能显示NULL因为复制线程没有活跃的链路。这是正常的等M1恢复后会自动追平。5.3 恢复流程与脑裂预防M1恢复后不能直接把它当成主库接回去。当时我的恢复流程是这样的启动M1的MySQL确认M1从M2追平数据SHOW SLAVE STATUS两个线程都是Yes延迟为0。在M1上写入一条测试数据验证M2能同步到反向链路也正常。如果确认数据一致再考虑是否把写主切回M1。这里必须说清楚MyCat默认不会自动切回。M1恢复后写流量依然在M2上除非手动重启MyCat或者通过运维脚本切换。我当时写了一个切换脚本在确认数据一致后把写流量切回M1避免M2长期承担写压力。自动切回不是不行但要非常谨慎——如果M1恢复后数据没追平就切回去应用层新写入的数据会落在M1上而M2上可能还有M1宕机期间的增量数据两边一合并就是数据丢失或覆盖。双主架构还有一个必须预防的风险脑裂。如果M1和M2之间的网络被切断但两台机器都活着应用层在异常场景下可能出现两边都收到写请求的情况两台主库各自写入各自的数据复制恢复时就会主键冲突、环路复制。规避手段有三个层面一是MyCat层保证同一时刻只有一个writeHost接收写流量二是网络层面保证心跳和复制走不同链路三是操作层面任何一次手工切换都要先确认另一台真的停了、数据真的追平了。架构可以帮你降低风险但最后的兜底永远是操作规范。6. 生产落地最容易踩的五个坑6.1 自增主键冲突参数配了但业务表早就有数据了auto_increment_offset和auto_increment_increment只对新建表生效。如果业务表已经存在并且之前的主键已经到了10万M1同步过来的AUTO_INCREMENT值可能和M2本地的值重叠。比如M1当前自增到10001M2当前自增到9999两边同时插入一个生成10002一个生成10000刚好错开但再过一阵子两边都涨到20000附近就可能撞上。稳妥的做法是搭建完成后把业务核心表的主键自增初始值手动调成和主库一致ALTER TABLE t_user AUTO_INCREMENT 20001;如果业务上可以接受更彻底的做法是放弃数据库自增主键改用全局IDMyCat的全局序列号功能或者应用层发号器这样双主冲突问题从根上消失。这个主题后续章节会单独展开。6.2 log_slave_updates缺失复制链路莫名其妙断掉双主双从架构里两台主库都必须开启log_slave_updates参数。这个参数的意思是从库此刻M2是M1的从库在回放中继日志产生数据变更时这些变更也要写入自己的binlog。如果不开启M1写入的数据会同步到M2但M2不会把这些数据记入自己的binlog于是S2永远看不到这些数据。更危险的是如果此时M1宕机、M2接管写入S2缺失的那部分数据就再也补不回来了。这个参数MySQL默认是关闭的官方文档里的示例也没有特别强调非常容易踩。我在搭建时专门检查了四台机器的my.cnf确认M1和M2都开了log_slave_updatesS1和S2可以不关心这个参数它们只需要自己的relay log。6.3 连接数配置不当MyCat把后端MySQL打爆过MyCat的maxCon指的是单个dataHost到后端MySQL的总连接上限。我第一版配置里maxCon200看似合理但应用侧连接池有50个应用实例每个实例维持20个连接加上MyCat自身的后端连接池瞬间就能把后端MySQL的max_connections打穿。后来我把整条链路的连接数算了一遍应用连接池总数、MyCat的前端连接数、MyCat到后端的maxCon、MySQL的max_connections四者的关系必须层层有冗余。我的建议是后端MySQL的max_connections至少大于MyCat的maxCon乘以writeHost数量再留出至少50%的余量用于运维直连和意外高峰。6.4 主从延迟引发的脏读slaveThreshold设得太随意读写分离最怕读到旧数据。业务上如果有一条数据刚写入就要立刻读出来典型场景是下单后跳转到订单详情页走从库就可能在极端延迟下读到空或者旧状态。我当时做了一层双保险MyCat侧把slaveThreshold设成30秒超过30秒延迟的从库不参与读应用侧对关键读接口做了先查主库的路由开关。虽然牺牲了一点读写分离的比例但换来的是业务逻辑的正确性值。等后续把缓存加好之后读压力会进一步下降这个开关再慢慢放开。6.5 应用直连MyCat的常见误区连接池与事务应用侧把MyCat当作MySQL来连连接池配置容易踩两个坑。一是连接池的maxActive不能设得比MyCat的前端连接上限还大否则应用侧排队MyCat侧空闲两边的资源都在空转。二是事务一定要在同一个连接上完成——MyCat并不是一个分布式事务中间件如果应用的事务跨越了MyCat的多个后端连接MyCat会直接拒绝执行最好的做法是让事务内的SQL命中同一个dataNode并且只涉及一台后端MySQL。我在改造时就遇到过不少这个事务在直连MySQL时好好的走了MyCat就报错的问题最后定位下来全部是连接复用和事务路由的锅。解决办法说白了就是连接池显式设置事务隔离级别和自动提交MyCat这边把sqlMaxLimit和分片规则配清楚让SQL尽量落在单节点上。第1章的内容大致到这里。这套架构上线后稳定运行了两年多双主双从加MyCat的组合经受住了多次故障演练和真实宕机事件。我个人最大的体会是高可用架构的价值不在于它看起来多先进而在于每一次故障发生时业务能不能无感知地继续跑下去。下一章我会继续写分库分表规则和MyCat的全局序列号方案把数据量进一步增长之后遇到的问题也一并复盘。
