当前位置: 首页 > news >正文

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实现自动故障切换。

http://www.cnnetsun.cn/news/576278.html

相关文章:

  • 探索企业AI转型路线图,AI应用架构师经验分享
  • 基于Matlab的数字PID控制系统设计(源码+万字报告+讲解)(支持资料、图片参考_相关定制)
  • 微服务分布式SpringBoot+Vue+Springcloud医疗挂号就诊平台
  • 数据结构2.0 线性表
  • ARM架构中APSR状态寄存器里的Q位
  • Linux 系统规范配置:建立标准目录结构、 repo 源获取、修改终端变色
  • AI应用架构师的认知升级:接受AI的“不完美”,拥抱人机协作的灰度
  • 巴菲特的品牌价值理论:无形资产的重要性
  • 2026最新网络安全学习路线(完整版)
  • 学长亲荐!继续教育必备TOP8 AI论文软件深度测评
  • 深度学习毕设项目推荐-基于python-CNN卷积神经网络对猫是否疲劳识别
  • AI大模型时代:提示系统市场表现评估的挑战与应对策略
  • 空洞骑士模组管理器Scarab:让模组管理变得前所未有的简单
  • DeepSeek将推出代码生成王者V4模型,性能碾压GPT/Claude,程序员必学必藏!
  • 番茄小说下载器:简单三步打造离线图书馆的终极方案
  • Zoplicate插件完整指南:彻底告别Zotero重复条目困扰
  • XGBoost终极安装指南:从零开始的机器学习库配置教程
  • 深度学习毕设项目:基于python-CNN卷积神经网络对猫是否疲劳识别
  • 深度学习毕设选题推荐:基于python-CNN卷积神经网络对猫是否疲劳识别
  • 国企“高级”程序员写的那些问题代码
  • 【计算机毕业设计案例】基于python-CNN卷积神经网络对海洋壳类生物识别
  • 计算机深度学习毕设实战-基于python-CNN卷积神经网络对猫是否疲劳识别
  • 深度学习毕设项目推荐-基于python-CNN深度学习对宠物体型识别
  • 吐血推荐!自考必用9款AI论文平台深度测评
  • 【小程序】订单数据缓存 以及针对海量库存数据的 懒加载+数据分片 的具体实现方式
  • 1月12日起航,16周全速通关!软考老金团队为2026年高项考生定制“上岸专列”
  • Nuxt3全栈开发实战指南
  • 深度学习毕设选题推荐:基于python-CNN深度学习的卷积神经网络对狗的行为识别
  • 深度学习计算机毕设之基于python-CNN深度学习对胡萝卜是否新鲜识别基于卷神经网络对胡萝卜是否新鲜识别
  • 不用卡尺怎么测量复杂零件尺寸?告别卡尺,精准高效:SIMSCAN-E手持扫描仪在复杂零件检测中的革命性应用