主从架构部署需围绕业务连续性、数据一致性与运维可维护性设计复制策略，核心是同步的可靠性、可控性与可验证性；读写分离场景下须按业务需求明确延迟容忍度。
主从架构部署不是简单配通复制链路，而是要围绕业务连续性、数据一致性与运维可维护性来设计复制策略。关键不在“能不能同步”，而在“同步得是否可靠、可控、可验证”。
明确复制目标与业务约束
不同场景对复制的要求差异很大，策略必须先对齐实际需求：
- 若用于读写分离，重点是延迟容忍度（比如报表类查询允许5秒延迟，但订单状态查询需
- 若用于灾备切换，核心是数据零丢失能力，需评估半同步或增强半同步是否启用
- 若用于备份源，需隔离备份操作影响——例如设置专用延迟从库（如延迟30分钟），防误删误更新扩散
- 高并发写入场景下，要考虑从库回放瓶颈，避免SQL线程成为单点，必要时启用并行复制（基于逻辑时钟或事务分组）
配置层面的硬性规范
基础配置直接决定复制稳定性，以下为不可妥协项：
- server-id全局唯一：每台MySQL实例必须配置非零且互不重复的server-id，否则复制会静默失败
- binlog格式强制ROW：STATEMENT模式在函数、时间戳、自增等场景下易导致主从不一致；MIXED模式行为不可控，生产环境禁用
- 从库设为read_only=ON：仅对SUPER权限用户无效，配合REPLICATION_SLAVE_ADMIN权限管控，杜绝意外写入
- 启用GTID（推荐）：简化故障恢复与主从切换，避免位点错乱；若必须用传统位点复制，需严格禁用gtid_mode并确保log-slave-updates开启（级联场景）
监控与验证必须常态化
复制链路一旦建立，不能“配完即忘”，需持续验证其健康度：
- 实时监控Seconds_Behind_Master，但注意它可能为0却存在隐性延迟（如长事务阻塞SQL线程），建议结合pt-heartbeat工具打点校验
- 定期比对主从表级数据一致性（如使用pt-table-checksum），尤其在大表DDL后或网络抖动后
- 每月至少一次主从切换演练：手动stop slave → 提升从库为新主 → 验证应用连通性与写入正确性 → 回切
- 所有从库必须开启relay_log_recovery=ON，防止崩溃后中继日志损坏导致复制中断
备份与容灾协同设计
复制本身不是备份，但可大幅优化备份体系：
- 逻辑备份（mysqldump）一律在从库执行，避免锁表影响主库TPS；导出时加--single-transaction和--master-data=2，保留精确位点
- 物理备份（xtrabackup）建议在专用备份从库做，该节点可配置innodb_max_dirty_pages_pct=0降低刷脏压力
- 保留至少两个角色分离的从库：一个实时从库（供读流量），一个延迟从库（如delay=1800），作为“时间机器”应对逻辑错误
- binlog需单独归档（如上传至对象存储），保留周期≥全量备份周期+1天，支撑PITR（基于时间点恢复）
