MySQL 主从复制涉及到了几个线程?

文章介绍了MySQL的主从同步原理,包括主从复制模式、主主复制模式、链式和环形复制模式。主从同步主要涉及三个线程:主库的BinlogDump线程,从库的I/O线程和SQL线程,通过二进制日志和中继日志实现数据同步。在主从复制过程中,从库的I/O线程读取主库的二进制日志内容,存储到中继日志,再由SQL线程重放事件以保持数据一致。

ms-mysql



前言

说到主从,我相信大家在 MySQL 这一节面试经常被问到MySQL 的主从复制原理,而且大家背得滚瓜烂熟。但是在主从复制的过程中,是如何进程数据同步的,又涉及到了哪些线程呢?这些线程又是充当的什么角色呢?

首先,MySQL 有如下几种复制模式:

  • 主从复制模式:A - - > B
  • 主主复制模式:A < - - > B
  • 链式复制模式:A - - > B - - > C
  • 环形复制模式:A - - > B - - > C - - > A

生产环境中一般建议部署为主从模式,这也是比较稳健的一种 MySQL 复制方式,如果想实现一定程度上的高可用,可选择使用主主模式,但是主主模式必须确保任何一个时刻都只有一个数据库是 Active 状态(即读写状态),另一个数据库作为备用,否则就要解决自增键/主键的冲突问题。

一、主从同步原理

简单的主从复制基本原理如下:

  • 主库将更新写入二进制文件,并维护文件的一个索引来跟踪日志循环;
  • 从库复制主库的二进制日志事件到本地的中继日志(relay log);
  • 从库重放中继日志实现与主库的数据同步。

这里不进行深入的源码分析,有兴趣的自行查阅官方文档

二、主从同步分析

MySQL 使用 3 个线程来实现同步(复制)功能,一个线程在主库上,另两个线程在从库上。

当从库执行 start slave指令时,从库将创建一个 I/O 线程,该线程用于连接主库并让主库发送记录在其二进制日志(主库二进制日志)中的语句。此时,主库会创建一个线程将其二进制日志的内容发送到从库,如下图,就是其创建的线程,有两个线程,是因为我的 MySQL 复制是双主双从架构(关于如何部署双主,可看看我前面的博文《基于 Docker 的 MySQL GTID 主从复制与测试》),下图是在某个一个主库上查询的,因此它有两个从库,所有就会生成两个 Binlog Dump 线程,该线程会发送更新的二进制内容到从库,并等待新的二进制日志更新,有更新就会推送。

show processlist\G

image-20230505182639729

然后从库的 I/O 线程读取主库 Binlog Dump 线程发送的内容并将读取的数据存储到从库的中继日志文件中,最后从库的 SQL 线程会将中继日志中的事件重演并最终落盘。I/O 线程与 SQL 线程位于从库上,如下图:

image-20230508095040342

而且要确保这两个线程均处于 Yes 状态,才能实现主从复制。

以上就是 MySQL 主从复制过程涉及到的三个线程!

<think> 我们正在解决用户关于“排查MySQL主从复制延迟过高”的问题。根据用户提供的引用内容以及我们之前的回答,我们将详细展开排查步骤。 引用[1]中提到主从复制延迟需要持续优化,并建议建立监控体系、压力测试等。引用[2]则给出了精确监控延迟的工具pt-heartbeat的使用方法。 因此,我们的回答将分为几个步骤: 1. 确认延迟现象(使用传统方法和精确方法) 2. 分析常见原因(引用[1]中提到的原因,并补充其他原因) 3. 针对性排查方法(针对每个可能的原因给出排查命令或方法) 4. 优化建议(引用[1]和引用[2]的建议,以及其他优化手段) 注意:我们需要在回答中适当引用,并确保LaTeX格式正确(如果有数学表达式)。由于用户的问题是关于排查方法,我们将重点放在排查步骤上。 另外,我们将生成相关问题放在最后。 </think> ### 排查MySQL主从复制延迟过高的方法 MySQL主从复制延迟是分布式架构中的常见问题,会直接影响数据一致性。以下是系统化的排查流程,结合性能指标监控、日志分析和配置优化: #### 一、确认延迟现象 1. **基础监控**(初步判断) 在从库执行: ```sql SHOW SLAVE STATUS\G ``` 关注关键字段: - `Seconds_Behind_Master` > 0(延迟秒数,但可能不精确[^2]) - `Slave_IO_Running: Yes`(接收日志线程状态) - `Slave_SQL_Running: Yes`(执行日志线程状态) 2. **精确监控**(推荐) 使用`pt-heartbeat`工具(Percona Toolkit): ```bash # 主库启动心跳更新 pt-heartbeat --user=monitor --password=*** \ --create-table --database heartbeat \ --update --interval=1 --daemonize # 从库查询真实延迟 SELECT TIMEDIFF(NOW(), ts) AS delay FROM heartbeat.heartbeat; # 返回如 00:00:05(5秒延迟)[^2] ``` --- #### 二、常见原因排查(按优先级排序) | 原因类型 | 排查命令/方法 | 关键指标 | |-------------------|-----------------------------------------------------------------------------|--------------------------| | **1. 硬件/网络瓶颈** | `iostat -x 1` 观察`%util`(磁盘IO)<br>`sar -n DEV 1` 观察`rxkB/s`(网络吞吐) | 磁盘利用率 > 90%<br>网络延迟 > 1ms | | **2. SQL线程阻塞** | `SHOW PROCESSLIST;` 观察`State`字段<br>`SELECT * FROM sys.innodb_lock_waits;` | "Waiting for table metadata lock"<br>锁等待时间 > 1s | | **3. 主库写入压力** | `SHOW GLOBAL STATUS LIKE 'Threads_running';`<br>`SHOW ENGINE INNODB STATUS;` | `Threads_running` > CPU核心数×2 | | **4. 从库配置不足** | `SHOW GLOBAL VARIABLES LIKE 'innodb_flush_log_at_trx_commit';`<br>`SHOW SLAVE STATUS` | 单线程复制(`Replica_parallel_workers=0`) | --- #### 三、针对性优化措施 1. **缓解IO瓶颈** - 升级SSD磁盘或RAID阵列 - 调整刷盘策略(牺牲部分持久性换取性能): ```sql -- 从库配置(配置文件修改) innodb_flush_log_at_trx_commit = 2 sync_binlog = 0 ``` 2. **解决SQL阻塞** - 终止长事务: ```sql KILL [进程ID]; -- 通过SHOW PROCESSLIST获取ID ``` - 优化慢查询: ```sql -- 开启慢查询日志 SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 1; -- 阈值设为1秒 ``` 3. **提升复制并行度**(MySQL 5.6+) ```sql -- 启用多线程复制 STOP SLAVE; SET GLOBAL slave_parallel_workers = 4; -- 建议设为CPU核心数 START SLAVE; ``` 4. **GTID模式优化**(解决乱序问题) ```sql -- 检查GTID状态 SELECT @@GLOBAL.gtid_mode; -- 需返回ON -- 若未启用,切换步骤: SET GLOBAL ENFORCE_GTID_CONSISTENCY = WARN; SET GLOBAL ENFORCE_GTID_CONSISTENCY = ON; SET GLOBAL GTID_MODE = OFF_PERMISSIVE; SET GLOBAL GTID_MODE = ON_PERMISSIVE; SET GLOBAL GTID_MODE = ON; ``` --- #### 四、高级架构优化 1. **升级MySQL 8.0+** 利用写集并行复制(Write Set Parallelism),比传统LOGICAL_CLOCK更高效[^1]。 2. **分片集群方案** 当单集群达到性能极限时(如1TB+数据),采用分库分表: ```mermaid graph LR A[应用] --> B[Sharding Proxy] B --> C1[Shard1-Master] B --> C2[Shard2-Master] C1 --> D1[Shard1-Replica] C2 --> D2[Shard2-Replica] ``` 3. **切换高可用架构** 金融级场景建议迁移到: - MySQL Group Replication(自动故障切换) - InnoDB Cluster(整合MySQL Shell和MySQL Router) > **关键提示**:延迟超过30分钟时应**暂停读写分离**,避免应用读到过期数据[^1]。 --- #### 五、持续监控体系 建议部署监控工具组合: ```mermaid pie title 监控指标分布 “Seconds_Behind_Master” : 35 “IO_Thread_Lag” : 25 “SQL_Thread_Lag” : 20 “Network_Latency” : 15 “Disk_IOPS” : 5 ``` 推荐工具: - `Prometheus` + `Grafana`:实时可视化延迟曲线 - `Percona Monitoring and Management`(PMM):专业诊断锁竞争和IO瓶颈 通过以上系统性排查,可覆盖95%的主从延迟场景。若仍存在异常,需结合`SHOW RELAYLOG EVENTS`分析具体的未应用事务[^1]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

云计算-Security

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值