一主多从需确保读请求真正分流且保障一致性：主库开启row格式binlog，各从库server-id唯一并设read_only=1；通过proxysql、应用层路由或shardingsphere实现读写分离；强一致场景强制走主库，监控seconds_behind_master并剔除延迟过高从库；配套数据校验与故障切换机制方可实现高可用。
一主多从不是单纯“多加几台从库”就行，核心是让读请求真正分流出去，同时不破坏数据一致性。主库专注写入，多个从库分担查询压力，既提升读并发能力，又为故障切换留出冗余空间。
主从基础配置要稳
主库必须开启 binlog 并设为 ROW 格式，每个从库的 server-id 必须唯一，且不能与主库冲突；从库建议开启 read_only=1，防止误操作写入。主库执行 SHOW MASTER STATUS 获取当前 binlog 文件名和位置，从库用 CHANGE REPLICATION SOURCE TO（MySQL 8.0+）或 CHANGE MASTER TO（旧版本）指向主库并指定起始点，再执行 START REPLICA（或 START SLAVE）。验证时重点看 Replica_IO_Running 和 Replica_SQL_Running 是否均为 Yes，以及 Seconds_Behind_Master 是否稳定在合理范围（如 ≤1s）。
读请求必须真正路由到从库
MySQL 本身不识别“读/写”，所有路由逻辑需外部控制：
- 用 ProxySQL 或 MaxScale：把主库加入 writer hostgroup，多个从库加入 reader hostgroup；配置规则将
SELECT自动发往 reader 组，INSERT/UPDATE/DELETE强制走 writer 组 - 应用层实现（如 Spring Boot + AbstractRoutingDataSource）：按方法注解（如
@ReadOnly）或 SQL 类型自动选择数据源；事务内所有操作必须走主库，否则可能读到未提交或已回滚的数据 - 客户端代理（如 ShardingSphere-JDBC）：通过 YAML 声明主库、多个从库及负载策略，无中心节点，对代码零侵入
延迟和一致性不能只靠“等”
主从延迟是常态，不能默认“最终一致就万事大吉”：
- 对强一致性场景（如下单后立即查订单状态），应支持强制走主库——可通过 SQL Hint（如
/*+ MASTER */）、自定义注解或上下文标记实现 - 监控
Seconds_Behind_Master，超过阈值（如 3 秒）自动将该从库从读池剔除，避免持续返回过期数据 - 避免长事务或大事务在主库执行，这类操作会显著拖慢复制进度
灾备能力得靠机制保障，不是靠数量堆砌
一主多从本身不等于高可用，需配套机制：
- 定期校验主从数据一致性（如用 pt-table-checksum 工具），及时发现隐性同步异常
- 准备故障切换预案：明确谁触发切换、如何确认主库宕机、如何提升某从库为主、如何重置其他从库指向新主
- 从库也需合理配置：开启
relay_log_recovery=ON防止崩溃后 relay log 损坏，设置slave_parallel_workers > 0加速 SQL 线程回放（尤其在 MySQL 8.0+）
