09-主从复制与读写分离：MySQL走向分布式的第一步

主从复制与读写分离MySQL走向分布式的第一步作者黒漂技术佬适用读者单机MySQL扛不住了想搞主从但不知道原理和坑的同学关联场景无人售货柜多门店数据架构、智慧农业多基地数据汇总一、为什么需要主从复制单机的三道天花板单机MySQL用着用着会遇到三堵墙天花板1高可用 - 一台MySQL挂了整个业务停摆 - 售货柜1000台断网2小时订单全丢 - 需要一台备机顶上 天花板2读压力大 - 售货柜展示商品列表、查询订单状态——全是读 - 高峰期1000 QPS的读压到一台机器 - CPU打满写也跟着卡 天花板3数据隔离 - 报表分析跑大查询把生产库拖垮 - 想做备份又怕影响线上主从复制就是解决这三个问题的基础设施一主多从主库写从库读主挂了从顶上。二、主从复制原理binlog→relay log→回放2.1 三个角色角色说明主库(Master)接收写请求把变更记到binlog从库(Slave)连主库拉binlog回放到自己binlog/relay log主的binlog是变更源头从的relay log是中转2.2 复制的三个线程主库Binlog Dump Thread → 负责把binlog发送给从库 从库 IO Thread → 接收主库binlog写到本地relay log SQL Thread → 读relay log回放到从库数据文件2.3 完整流程主库 从库 写请求 → 修改数据 → 写binlog Binlog Dump Thread IO Thread ─────── binlog event ──────→ 收到event写relay log relay log落盘 SQL Thread 读relay log回放SQL → 修改从库数据详细步骤从库执行CHANGE MASTER TO ...配置主库地址START SLAVE从库IO Thread连接主库请求从某个binlog位点开始拉数据主库Binlog Dump Thread读binlog发给从库从库IO Thread把event写入relay log中继日志从库SQL Thread读relay log重放里面的SQL更新数据从库和主库数据一致这是个异步逻辑——主库写完binlog就返回客户端成功不等从库同步完。所以会有主从延迟。三、三种复制方式异步、半同步、组复制3.1 异步复制默认主库写完binlog立即返回客户端不等从库确认。主库 从库 写完binlog 返回客户端 ✓ 还在同步中 ... 同步完成优点性能好主库几乎不被从库拖累。缺点主库挂了从库可能还没同步完最新数据 → 数据丢失。# 主库配置 [mysqld] log_bin mysql-bin server_id 13.2 半同步复制主库写完binlog至少等一个从库收到binlog并写relay log确认才返回客户端成功。主库 从库 写binlog ──── binlog ────→ 收到写relay log回复ACK 收到从库ACK ✓ 返回客户端 ✓优点数据安全性高至少有一个从库收到了数据。缺点比异步慢一点多一个RTT从库全挂时主库会降级成异步或阻塞。# 主库配置 [mysqld] plugin_load rpl_semi_sync_mastersemisync_master.so rpl_semi_sync_master_enabled 1 rpl_semi_sync_master_timeout 3000 # 3秒等不到ACK降级为异步 # 从库配置 [mysqld] plugin_load rpl_semi_sync_slavesemisync_slave.so rpl_semi_sync_slave_enabled 13.3 组复制MGRMySQL Group Replication多个节点组成一个组用Paxos协议保证数据一致性。任何节点都能写写完同步到全组。MGR集群 节点1 (主) ←→ 节点2 ←→ 节点3 写请求 → Paxos共识 → 全组同步 → 返回优点真正的高可用任何单点挂了集群照常工作多主可写。缺点配置复杂写性能受共识协议拖累至少过半数节点确认。复制方式性能数据安全复杂度适用场景异步最高一般可能丢低读多写少、容忍少量丢失半同步中高中大多数生产场景MGR较低极高高强一致性要求高选型建议普通业务用半同步金融级用MGR。异步复制只用在纯读从库或测试环境。四、主从延迟原因和解决方案4.1 延迟怎么来的异步复制下从库的数据总是落后主库一段时间——这就是主从延迟。延迟的几个成因SQL Thread单线程回放主库多线程并发写从库单线程串行回放写压力大时从库追不上。MySQL 5.7有并行复制基于group commit5.6及之前是硬伤。网络延迟主从跨机房跨地域binlog传输慢。从库压力从库被大查询占用CPU/IO回放速度下降。大事务一个事务里有10万条UPDATE主库几秒写完从库要回放十几秒。4.2 怎么看延迟-- 从库执行SHOWSLAVESTATUS\G-- 关注-- Seconds_Behind_Master: 5 落后主库5秒-- Slave_IO_Running: Yes-- Slave_SQL_Running: Yes4.3 解决方案延迟优化清单 1. 开启并行复制MySQL 5.7 slave_parallel_type LOGICAL_CLOCK slave_parallel_workers 8 2. 减少大事务 把UPDATE 10万行拆成多次小批量 3. 从库SSD 大内存 回放是IO密集型硬件要跟上 4. 业务读走从库时容忍延迟 重要读扣库存前查余额走主库 普通读列表展示走从库真实踩坑用户刚下完单立刻查订单列表查不到——因为写走主库读走从库从库还在同步。这种叫读写一致性问题。解法关键查询走主库或用ShardingSphere的读写一致性策略。五、读写分离架构主库写、从库读5.1 架构图应用层 ↓ ┌───────────────┐ │ 读写分离中间件 │ └───────────────┘ ↓ 写 ↓ 读 主库 从库1 从库2 从库3 (写强一致读) (读分担)读写分离的核心思想写请求必须走主库只有主库能写读请求尽量走从库分担压力。5.2 哪些读必须走主库必须走主库的读 1. 写完立刻要读的场景保证读到自己刚写的数据 2. 涉及金额、库存的关键判断 3. 事务内的查询事务要读到最新数据 可以走从库的读 1. 商品列表、订单历史 2. 报表统计 3. 用户头像、昵称展示六、读写分离的实现方案6.1 ShardingSphere-JDBCApache ShardingSphere提供JDBC层的读写分离应用无需改代码配置一下就能用。spring:shardingsphere:datasource:names:master,slave0,slave1master:type:com.zaxxer.hikari.HikariDataSourcedriver-class-name:com.mysql.cj.jdbc.Driverjdbc-url:jdbc:mysql://master-db:3306/shopusername:rootpassword:xxxslave0:# 从库0配置jdbc-url:jdbc:mysql://slave0-db:3306/shopslave1:# 从库1配置jdbc-url:jdbc:mysql://slave1-db:3306/shoprules:readwrite-splitting:data-sources:readwrite_ds:write-data-source-name:masterread-data-source-names:slave0,slave1load-balancer-name:round_robinload-balancers:round_robin:type:ROUND_ROBIN# 轮询负载均衡ShardingSphere根据SQL类型自动路由INSERT/UPDATE/DELETE → 主库SELECT → 从库。事务内的所有SQL都走主库。// 普通查询走从库自动路由ListProductlistproductMapper.selectList(...);// 事务内走主库TransactionalpublicvoidplaceOrder(){productMapper.update(...);// 写主库productMapper.selectList();// 也在主库同事务}6.2 MyCatMyCat是独立的数据库中间件应用连接MyCatMyCat再连后端真实数据库。配置比ShardingSphere重但功能全。!-- schema.xml --schemanameshoptablenameproductdataNodedn1//schemadataHostnamehost1balance2writeType0writeHosthostmasterurlmaster-db:3306/readHosthostslave0urlslave0-db:3306/readHosthostslave1urlslave1-db:3306//dataHost方案部署方式改造成本适合ShardingSphere-JDBC应用内jar包低改配置Java应用为主MyCat独立中间件中多一层运维多语言混合环境选型原则纯Java应用优先ShardingSphere-JDBC部署简单、性能损耗低。多语言或需要独立DB代理层再考虑MyCat。七、主从切换和故障恢复7.1 主库挂了怎么办主库故障的恢复流程1. 检测监控发现主库不可达 2. 选新主从多个从库里选一个数据最新的 Seconds_Behind_Master最小 3. 提升把选中的从库提升为新主 STOP SLAVE; RESET SLAVE ALL; SET GLOBAL read_only OFF; 4. 应用切流量把应用的数据源指向新主 5. 旧主恢复作为从库重新加入集群7.2 自动切换工具手动切换太慢生产用自动化工具工具说明MHAMaster High Availability老牌方案监控自动切换Orchestrator拓扑管理故障切换Web界面MGR组复制自带故障切换无需外部工具壳厂中间件ShardingSphere可配合注册中心做自动切换# MHA Manager监控主库masterha_manager--conf/etc/mha/shop.cnf# 主库挂掉时MHA自动# 1. 选出从库中binlog最新的# 2. 把其他从库的relay log补到选中的从库# 3. 提升为新主把其他从库重新指向新主切换不是万能的数据丢失是切换时最头疼的问题。半同步复制延迟监控能大幅降低丢数据概率。八、结合无人售货柜多门店数据架构8.1 业务场景某无人售货柜运营平台覆盖200个城市、5000台柜子。数据架构需求每个门店区域有本地数据库写本地订单总部要查所有门店数据做报表单台柜子挂了不影响其他门店总部做活动时配置要下发到所有门店8.2 架构设计总部数据中心 ↑ 汇聚 ┌──────────────┼──────────────┐ 华北区 华东区 华南区 (主2从) (主2从) (主2从) ↓ ↓ ↓ 门店1-50 门店51-200 门店201-500设计要点分区域部署主从集群每个区域一套主从区域写本地数据避免跨区域网络延迟。总部只读从库区域主库通过半同步复制到总部只读节点总部查只读节点。门店数据通过门店ID分库db_shop_001~db_shop_500按门店ID取模分库。配置下发用消息队列总部配置变更发到Kafka各区域消费写到本地。8.3 读写分离在售货柜场景的具体应用// 用户查询商品列表 → 走从库读多容忍秒级延迟GetMapping(/products)publicListProductlistProducts(LongcabinetId){returnproductService.listByCabinet(cabinetId);// 自动走从库}// 用户下单扣库存 → 走主库必须强一致TransactionalpublicvoidplaceOrder(OrderRequestreq){productMapper.deductStock(req.getProductId());// 写主库orderMapper.insert(buildOrder(req));// 写主库}// 售货柜状态监控 → 走从库GetMapping(/cabinet/status)publicCabinetStatusstatus(LongcabinetId){returncabinetService.getStatus(cabinetId);// 从库}经验售货柜场景的读写比例通常10:1甚至更高查商品、查订单、查状态远多于下单读写分离的收益非常明显。从库分担了90%的读压力主库只专注写和关键读。九、总结概念一句话主从复制原理主写binlog→从拉relay log→SQL Thread回放三种复制异步快但可能丢、半同步折中、MGR强一致主从延迟从库回放慢于主库写入靠并行复制小事务缓解读写分离写走主库读走从库靠ShardingSphere/MyCat路由故障切换选最新从库→提升为主→应用切流量用MHA/Orchestrator自动化多门店架构区域分库总部汇聚从库读写分离分担读压力主从复制是MySQL从单机走向分布式的第一步。但单库容量到天花板单表5000万行变慢主从也救不了——这就需要分库分表。下一篇我们聊高可用与分库分表。