关键在于复制稳定、切换快速、读写分离清晰、问题可观测；需物理隔离主从节点，一主两从跨可用区部署，严格配置server-id、row格式binlog、read_only等参数，优先gtid初始化，代理层结合延迟监控实现智能读写分离。
在数据库层面构建高可用主从复制与读写分离集群，关键不是配通链路，而是让复制稳、切换快、读写分得清、出问题看得见。
主从节点部署必须物理隔离且角色固化
主库和从库不能共用机器或同一可用区。生产环境建议至少一主两从，分别部署在不同物理机或云厂商不同可用区。所有节点需满足：
- 防火墙放行 3306 端口，/etc/hosts 或 DNS 配置确保 host 名可互相解析并 ping 通
- 主库开启 log_bin，从库禁用 skip-slave-start（除非启用 GTID 自动启动）
- 全集群统一使用 chrony 同步时间，避免 binlog 时间戳错乱引发 GTID 冲突或延迟误判
- 主库 server-id 全局唯一，从库 server-id 也需唯一且与主库不重复
参数配置要按角色严格区分
仅设 server-id 和 log-bin 远远不够，核心参数直接影响一致性与恢复能力：
- 主库重点：binlog_format=ROW（防函数、临时表导致不一致）、sync_binlog=1（每次事务落盘保数据不丢）、enforce-gtid-consistency=ON（若启用 GTID）
- 从库重点：read_only=ON（防止应用误写）、log_slave_updates=ON（支持级联复制）、relay_log_recovery=ON（崩溃后自动清理损坏 relay log）
- 主从共用但必须一致：max_allowed_packet（防大事务中断）、character_set_server 和 collation_server（避免字符集转换异常）
同步初始化必须绕过人工位点误差
传统 FLUSH TABLES WITH READ LOCK + SHOW MASTER STATUS 方式易因锁释放时机或网络抖动引入位点偏差。推荐两种更可靠方式：
- 启用 GTID：配置 gtid-mode=ON 并设置 auto-position=1，CHANGE MASTER TO 时无需指定 File/Position，MySQL 自动对齐事务边界
- 使用物理备份工具：如 Percona XtraBackup 做一致性快照，配合 --slave-info 导出位点，再在从库上 restore + START SLAVE，全程无锁、无位点手工干预
读写分离必须有明确路由策略与延迟兜底
不能简单把 SELECT 全部打到从库——主从延迟存在时，刚写入的数据可能查不到。实际落地需分层控制：
- 代理层（推荐）：用 ProxySQL 或 MySQL Router，配置读写分离规则（如写走 hostgroup 10，读走 hostgroup 20），并开启从库延迟监控（seconds_behind_master > 5s 则自动摘除）
- 应用层（轻量场景）：Spring Boot 可结合 AbstractRoutingDataSource 动态切换数据源，关键查询加 @ReadOnly 注解，强制走主库；普通列表页走从库
- 强一致性兜底：对“写后即读”类逻辑（如用户注册后跳转个人页），在事务提交后主动 sleep(100ms) 或轮询从库延迟值归零再查，或直接查主库
