mysql主从复制实现高可用需注意配置、切换、延迟和一致性问题。一、主库开启binlog并创建复制账号，从库设置不同server-id并启动复制进程；二、通过mha等工具实现自动故障切换，确保数据同步后再切换主库；三、优化硬件、启用并行复制、监控延迟指标以解决复制延迟；四、使用gtid、定期校验数据、避免手动修改数据来保障主从一致性。
MySQL主从复制是数据库高可用架构中非常常见的方案，配置起来不算复杂，但要真正用好、实现高可用，还是有一些细节需要注意的。
一、主从复制的基本配置步骤
MySQL主从复制的核心是通过主库将数据变更（binlog）发送给从库，从库接收并重放这些日志，从而保持数据一致。基本配置流程如下：
-
开启主库的binlog：在my.cnf中设置
server-id=1、log-bin=mysql-bin。 -
创建用于复制的账号：例如
CREATE USER 'repl'@'%' IDENTIFIED BY 'password'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; -
获取主库当前的数据快照：可以使用
mysqldump --single-transaction来导出数据。 - 配置从库的server-id：不能与主库重复，比如设为2。
-
启动复制进程：在从库执行
CHANGE MASTER TO ...，然后执行START SLAVE;
这一步完成后，从库就会开始同步主库的数据了。
二、主从切换和故障转移怎么处理？
光有主从复制还不算高可用，必须加上故障自动切换机制才能真正提升可用性。常见做法包括：
- 使用中间件如MHA、Orchestrator或ProxySQL来监控主库状态，并在主库宕机时自动切换到从库。
- 手动切换也可以，但容易出错且响应慢，不适合生产环境。
- 在切换过程中要注意几个点：
- 确保从库已经追上主库的binlog位置，否则会丢失数据。
- 切换后新主库需要开启写权限，并更新其他从库指向它。
- 应用层也需要及时感知主库变化，避免连接旧主库导致写入失败。
如果你没有引入自动化工具，那至少得有一套清晰的手动切换流程文档。
三、复制延迟问题怎么解决？
主从复制延迟是一个很常见的问题，尤其是在写压力大的场景下。造成延迟的原因可能包括网络带宽不足、从库性能瓶颈、锁竞争等。
你可以从以下几个方面入手优化：
- 升级从库硬件或增加资源，特别是IO性能。
- 拆分业务读写流量，减少从库负担。
- 启用并行复制（Parallel Replication），MySQL 5.7以后支持基于库或事务的并行复制方式。
- 监控复制延迟指标，比如Seconds_Behind_Master，一旦超过阈值就告警。
有时候延迟不是因为性能差，而是因为某些语句本身执行时间长，比如大表alter操作，这类操作建议避开高峰期执行。
四、主从一致性如何保障？
虽然主从复制的目标是保持数据一致，但在实际运行中，偶尔会出现不一致的情况。比如主库执行了一个语句，但从库由于某种原因跳过了，导致数据差异。
为了尽量避免这种情况，可以采取以下措施：
- 使用GTID（全局事务标识符）来管理复制，这样可以更准确地定位事务是否同步完成。
- 定期做数据校验，比如使用pt-table-checksum工具检测主从一致性。
- 如果发现不一致，可以用pt-table-sync进行修复，但要在维护窗口执行，避免影响正常业务。
另外，主从之间不要手动修改数据，除非你非常清楚后果，否则很容易破坏一致性。
基本上就这些。主从复制本身不难配置，但想用得好、保证高可用，还得注意监控、容灾、数据一致性等多个方面。
