MySQL主从复制怎么配置_实现高可用需要注意哪些？

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进行修复，但要在维护窗口执行，避免影响正常业务。

另外，主从之间不要手动修改数据，除非你非常清楚后果，否则很容易破坏一致性。

基本上就这些。主从复制本身不难配置，但想用得好、保证高可用，还得注意监控、容灾、数据一致性等多个方面。