高可用mysql主从复制集群需围绕一致性、可观测性、可切换性系统构建：一要固化主从角色与网络基础，二要按角色精准配置参数，三要规避人工位点误差启用gtid或自动化同步，四要上线后立即接入健康监控与响应机制。
高可用架构下部署MySQL主从复制集群，核心目标是实现故障自动承接、读写分离可控、数据零丢失可溯。它不是简单配通复制链路，而是围绕一致性、可观测性、可切换性三方面系统构建。下面分四个关键环节讲清楚怎么做。
主从角色与网络基础必须提前固化
主库（Master）和从库（Slave/Replica）的物理或逻辑边界要清晰，不能混用。生产环境推荐至少一主两从，且满足：
- 主从节点分布在不同物理机或可用区，避免单点硬件/网络故障影响全链路
- 所有节点关闭防火墙或明确放行 3306 端口，并配置 /etc/hosts 或 DNS 解析，确保 host 名可互 ping
- 主库开启
log_bin，从库禁用skip-slave-start（除非使用 GTID + 自动启动策略） - 统一时钟（如 chrony 同步），防止 binlog 时间戳错乱引发 GTID 冲突或延迟误判
配置参数必须按角色精准区分
仅靠 server-id 不同远远不够。关键参数差异直接影响复制稳定性：
-
主库重点项：
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必须相同，避免字符集转换异常
同步建立必须规避人工位点误差
手动执行 SHOW MASTER STATUS 记录 File/Position，再粘贴进 CHANGE MASTER TO，极易出错。更可靠的方式是：
- 启用 GTID（MySQL 5.7+ 默认支持），用
CHANGE MASTER TO MASTER_AUTO_POSITION = 1，完全跳过位点管理 - 若必须用传统位点，通过脚本自动获取并下发：主库执行
SELECT FILE, POSITION FROM mysql.gtid_executed或解析SHOW BINLOG EVENTS，再 SSH 调用从库执行CHANGE MASTER - 首次同步建议用
mysqldump --single-transaction --master-data=2导出，其中--master-data=2会自动在 dump 文件中插入CHANGE MASTER注释，导入后直接启用
上线后必须立即接入健康监控与响应机制
复制链路“看起来在跑”不等于“真正可用”。需主动验证三项指标：
-
线程状态：检查
SHOW SLAVE STATUS\G中Slave_IO_Running和Slave_SQL_Running是否均为Yes -
延迟水位：关注
Seconds_Behind_Master（非 GTID 场景）或Retrieved_Gtid_Set与Executed_Gtid_Set差值（GTID 场景） -
数据一致性：用
pt-table-checksum定期校验主从表级数据差异，发现不一致立即告警并暂停写入 - 配套动作：部署轻量监控脚本（如每分钟 curl 检查
mysqladmin ping+show slave status），异常时触发邮件/SMS 并尝试START SLAVE自愈
