news 2026/5/1 8:08:06

MySQL主从复制原理详解

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
MySQL主从复制原理详解

MySQL 主从复制(Master-Slave Replication)是一种数据复制技术,它将一个 MySQL 服务器(主库)的数据实时复制到一个或多个 MySQL 服务器(从库),主要用于实现读写分离、数据备份、高可用性和负载均衡。下面是其核心原理的详细说明:

一、 核心流程

主从复制基于“日志同步”实现,主要分为三步:

  1. 主库写入并记录日志:主库将数据变更写入二进制日志(Binary Log)。

  2. 从库拉取日志:从库的 I/O 线程读取主库的二进制日志并写入中继日志(Relay Log)。

  3. 从库重放日志:从库的 SQL 线程读取中继日志,重放 SQL 操作,实现数据同步。

二、 详细步骤

步骤一:主库记录二进制日志(Binary Log)
  • 当主库执行写操作(INSERT/UPDATE/DELETE 等)时,会将这些操作按顺序记录到二进制日志中。

  • 二进制日志的格式可以是:

    • Statement-based:记录 SQL 语句(MySQL 5.7 及之前默认,可能因函数、时间戳等导致数据不一致)。

    • Row-based:记录数据行的变更(MySQL 8.0及之后默认,推荐,更安全)。

    • Mixed:混合模式,自动选择以上两种。

-- 查看当前格式 sql -- 查看全局和会话级别的 binlog 格式 SHOW GLOBAL VARIABLES LIKE 'binlog_format'; SHOW VARIABLES LIKE 'binlog_format'; -- 查看所有 binlog 相关设置 SHOW VARIABLES LIKE '%binlog%';
步骤二:从库拉取日志(I/O 线程)
  • 从库启动一个I/O 线程,连接到主库。

  • 主库为每个连接启动一个Binlog Dump 线程,将二进制日志发送给从库。

  • 从库的 I/O 线程接收日志后,将其写入本地的中继日志(Relay Log)

步骤三:从库重放日志(SQL 线程)
  • 从库启动一个SQL 线程,读取中继日志中的事件,并重放 SQL 操作,更新从库数据。

  • 重放完成后,从库会记录已经应用的二进制日志位置,以便断点续传。

三、关键组件

  • 二进制日志(Binlog):主库的数据变更记录。

  • 中继日志(Relay Log):从库临时存储主库日志的文件。

  • Binlog Dump 线程:将二进制日志发送给从库的线程

  • I/O 线程:从库用于拉取主库日志的线程。

  • SQL 线程:从库用于重放日志的线程(MySQL 5.6+ 支持多线程复制,可并行重放)。

四、 复制模式

(1)异步复制(默认)
  • 主库提交事务后,不等待从库响应,直接返回客户端。

  • 优点:性能高。

  • 缺点:可能丢失数据(主库宕机时未同步的日志会丢失)。

(2)半同步复制
  • 主库提交事务后,至少等待一个从库接收并写入中继日志后才返回客户端。

  • 优点:保证数据至少有一个副本,增强数据安全性。

  • 缺点:性能略低于异步复制。

(3)组复制(Group Replication,MySQL 5.7+)
  • 基于 Paxos 协议实现多主同步,所有节点数据强一致。

  • 适用于高可用集群(如 InnoDB Cluster)。

五、 配置要点

主库配置
ini # 启用二进制日志 log_bin = mysql-bin # 设置服务器唯一ID server_id = 1 # 指定复制的数据库(可选) binlog_do_db = mydb
从库配置
ini server_id = 2 # 指定主库信息 CHANGE MASTER TO MASTER_HOST='主库IP', MASTER_USER='repl_user', MASTER_PASSWORD='密码', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154; # 启动复制 START SLAVE;

六、 常见问题与优化

  • 数据延迟

    • 原因:从库 SQL 线程重放慢、网络延迟、主库并发高。

    • 优化:启用多线程复制(slave_parallel_workers)、使用行格式日志、升级硬件。

  • 主从数据不一致

    • 定期校验数据(如pt-table-checksum工具)。

    • 使用GTID(全局事务标识)自动跟踪事务位置(MySQL 5.6+)。

  • 复制中断

    • 常见于主键冲突、从库写入误操作等。

    • 可通过SHOW SLAVE STATUS查看错误信息,手动修复后执行START SLAVE

七、 扩展:GTID 复制

GTID(Global Transaction Identifier)为每个事务分配唯一ID,简化故障恢复和主从切换:

sql -- 主从配置中启用GTID gtid_mode = ON enforce_gtid_consistency = ON -- 从库自动定位主库日志位置 CHANGE MASTER TO MASTER_AUTO_POSITION = 1;

总结

MySQL 主从复制的核心是“日志同步 + 重放”,通过异步、半同步等模式平衡性能与可靠性。在实际应用中,需结合监控工具(如SHOW SLAVE STATUS)和数据校验机制确保复制稳定。对于高可用场景,可进一步结合MHA、InnoDB Cluster 或 ProxySQL实现自动故障切换。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/5/1 7:24:29

Agentic AI上下文工程隐私保护实战:提示工程架构师的5个调试技巧

Agentic AI上下文工程隐私保护实战:提示工程架构师的5个核心调试技巧 元数据框架 标题:Agentic AI上下文工程隐私保护实战:提示工程架构师的5个核心调试技巧关键词:Agentic AI、上下文工程、隐私保护、提示工程、差分隐私、隐式推…

作者头像 李华
网站建设 2026/5/1 8:55:14

稳定性性能系列之十二——Android渲染性能深度优化:SurfaceFlinger与GPU

引言 你有没有遇到过这样的场景:应用在自己的手机上丝般顺滑,但换到某些设备上就卡得像PPT?或者复杂列表滑动时掉帧严重,但CPU和内存占用看起来都正常? 这通常不是代码逻辑的问题,而是渲染性能的瓶颈。在Android系统中,从应用UI绘制到屏幕显示,中间经历了一个复杂的渲染管…

作者头像 李华
网站建设 2026/5/1 8:16:19

静态综合实验~

省略IP配置,在R4成功实现到R5\R2\R3 的畅通在R1上实现到R2\R3的访问成功实现R1到达R5的环回5.5.5.0 24网段的访问在关闭千兆线路后仍可通过备份线路实现沟通在R3上的下一跳与缺省,其他同理

作者头像 李华
网站建设 2026/5/1 8:18:02

【毕业设计】基于python-CNN卷积神经网络的宠物行为训练识别

博主介绍:✌️码农一枚 ,专注于大学生项目实战开发、讲解和毕业🚢文撰写修改等。全栈领域优质创作者,博客之星、掘金/华为云/阿里云/InfoQ等平台优质作者、专注于Java、小程序技术领域和毕业项目实战 ✌️技术范围:&am…

作者头像 李华
网站建设 2026/5/1 6:57:20

【课程设计/毕业设计】基于python-CNN卷积神经网络的宠物行为训练识别

博主介绍:✌️码农一枚 ,专注于大学生项目实战开发、讲解和毕业🚢文撰写修改等。全栈领域优质创作者,博客之星、掘金/华为云/阿里云/InfoQ等平台优质作者、专注于Java、小程序技术领域和毕业项目实战 ✌️技术范围:&am…

作者头像 李华