mysql在分布式架构中使用主从复制的应用场景

主从复制通过读写分离缓解读多写少压力，但需应用层路由、处理复制延迟、避免从库误写，并注意跨机房容灾限制。

主从复制解决读多写少的流量压力

当业务中 SELECT 请求远高于 INSERT/UPDATE/DELETE，比如电商商品页、内容平台详情页、报表后台查询，单库扛不住并发读请求。主从复制让写操作只走 master，读请求分发到一个或多个 slave，实际是把读吞吐横向扩展了。

注意：应用层必须显式区分读写路由，MySQL 本身不自动做这个决策。常见做法是用中间件（如 ShardingSphere、ProxySQL）或在 ORM 层（如 MyBatis 的 AbstractRoutingDataSource）做数据源切换。

• 不能把所有读都扔给从库——比如刚插入一条订单，紧接着查这条记录，若查从库可能因复制延迟还没同步，导致“查不到”
• 强一致性读必须打到主库，或等待 MASTER_POS_WAIT() 确认位点已同步
• 从库数量不是越多越好，每个从库都会增加主库的二进制日志解析和网络开销

从库承担备份与高可用切换任务

主从结构天然提供一份实时热备。当 master 故障时，可快速提升某个 slave 为新主库（需配合 GTID + semi-sync 避免数据丢失）。但注意：这不属于“自动故障转移”，MySQL 原生不提供集群管理能力，必须依赖外部工具（如 Orchestrator、MHA 或云厂商的 RDS 自动主从切换）。

典型误操作是直接在从库执行 STOP SLAVE; RESET SLAVE ALL; 后就当它是新主库——没清理 relay log 位点、没重置 GTID_EXECUTED，后续再挂回原主库可能引发事务重复或跳过。

• 生产环境务必开启 gtid_mode=ON 和 enforce_gtid_consistency=ON
• 从库应关闭 binlog（除非它还要当其他实例的主库），否则会额外写日志并影响性能
• 监控项不能只看 Seconds_Behind_Master，它在空闲或大事务时可能为 0 却实际卡住；更可靠的是比对 SHOW MASTER STATUS 和 SHOW SLAVE STATUS 中的 Exec_Master_Log_Pos 与 Read_Master_Log_Pos

从库用于离线分析与报表生成

跑复杂聚合查询（如 GROUP BY + 多表 JOIN + 全表扫描）会严重拖慢主库响应。把这类低优先级、允许分钟级延迟的任务定向到专用从库，是最小成本的资源隔离方案。

关键点在于避免影响线上服务：专用从库建议配置更低规格（CPU/内存），并设置 max_execution_time 限制长查询，同时开启 read_only=ON 防止误写。

• 不要在报表从库上建索引优化——主库 DDL 不会同步到从库，且索引会影响复制性能
• 如果报表 SQL 需要访问大量历史归档数据，考虑用 mysqldump 导出后导入独立分析库，而不是长期占用一个从库实例
• 某些 BI 工具（如 Tableau）默认启用连接池并复用连接，若未配置只读模式，仍可能把写语句发到从库导致报错 ERROR 1290 (HY000): The MySQL server is running with the --read-only option

跨机房容灾与地理就近读

主库放在北京 IDC，从库部署在上海或深圳，用户请求按 DNS 或负载均衡就近接入本地从库，降低跨城网络延迟。这种架构下，复制链路变成跨公网或长距专线，network latency 成为最大瓶颈。

此时必须调优：增大 slave_net_timeout（默认 60 秒，长距易超时断连），启用 slave_compressed_protocol=ON 减少带宽占用，并强烈建议用 semi-sync replication 避免主库提交后长时间不知道从库是否收到。

• 不要在跨机房场景下依赖 async replication 做强一致容灾——网络抖动时主库可能已提交，但从库一条没收到
• 从库所在机房若发生整体故障，仅靠主从无法自动恢复服务；真正容灾需要多活设计或单元化拆分
• CHANGE MASTER TO ... MASTER_SSL=1 必须开启，否则复制账号密码等敏感信息明文传输

主从复制不是银弹。它缓解读压力、提供基础冗余，但解决不了分片、分布式事务、全局一致性这些分布式核心问题。最容易被忽略的是：复制延迟在任何规模下都存在，而业务代码里那些“先写后读”的隐含假设，往往比数据库配置更容易引发线上故障。