MySQL 主从延迟问题全面梳理

前言 主从延迟是 MySQL 高可用架构中最高频的问题之一。很多人对延迟的理解停留在"大事务导致延迟"这个层面,遇到问题时无从下手。本文从复制链路的两个阶段出发——IO 线程和 SQL 线程——分别梳理常见延迟原因,并结合真实案例深入分析原理。 一、主从复制链路简述 理解延迟,先要清楚复制的完整链路: 主库写入事务 ↓ 主库 Dump 线程:读取 binlog 发送给从库 ↓ (网络传输) 从库 IO 线程:接收 binlog,写入 relay log ↓ 从库 SQL 线程(或并行 Worker):读取 relay log,回放事务 ↓ 从库数据与主库一致 延迟分两类: IO 延迟:从库 IO 线程落后于主库,relay log 还没接收完整 SQL 延迟:relay log 已收到,但 SQL 线程回放跟不上 用 SHOW SLAVE STATUS\G 区分: 1 2 3 4 5 6 7 8 SHOW SLAVE STATUS\G -- 判断是 IO 延迟还是 SQL 延迟: -- Master_Log_File / Read_Master_Log_Pos → IO 线程已读到的位置 -- Relay_Master_Log_File / Exec_Master_Log_Pos → SQL 线程已执行的位置 -- 如果 Read_Master_Log_Pos 远落后于主库最新位置 → IO 延迟 -- 如果 Read_Master_Log_Pos 接近主库,但 Exec_Master_Log_Pos 落后 → SQL 延迟 二、IO 线程延迟的常见原因 原因 1:网络带宽不足 原理: ...

2026年4月1日 · 6 分钟 · DBA Student

Switch2 通过 PC 热点走 Clash 代理加速联网教程

背景 Switch2 直连家庭宽带访问日本、香港等海外服务器时延迟很高,体验极差。本地 PC 上已经运行了 Clash Verge 代理,可以快速连接香港、日本节点。目标是让 Switch2 的流量也走 PC 的代理。 方案选择 有三种方案可以实现: 方案 原理 优点 缺点 PC 热点共享代理 PC 开热点,Switch2 连热点走代理 零成本,快速配置 PC 需要一直开着 路由器刷 OpenWrt + Clash 全屋透明代理 一劳永逸 需要额外购买或刷机 PC 软路由 PC 网线直连 Switch2 不买设备 配置复杂 本文选择方案一:PC 热点共享代理,最简单实用。 环境说明 PC 系统:Windows 11 代理软件:Clash Verge,混合端口 7897 PC 上网方式:有线以太网 PC 热点网卡 IP:192.168.137.1 配置步骤 第一步:Clash Verge 设置 打开 Clash Verge → 设置 开启系统代理 开启允许局域网(Allow LAN) 确认端口设置为 7897 注意:不要开启 TUN(虚拟网卡)模式,TUN 模式会与 Windows 热点冲突,导致所有网络断开。 ...

2026年3月31日 · 2 分钟 · DBA Student

mysqldump 备份参数深度解析:--single-transaction 与 --master-data

前言 在 MySQL 备份实践中,mysqldump --single-transaction --master-data=2 是最常见的组合。但很多 DBA 只知道"这样用不锁表",却不清楚底层原理。今天我们深入剖析这两个参数的工作机制,以及为什么它们必须配合使用。 一、MVCC 可见性规则(理论基础) 在理解 --single-transaction 之前,必须先掌握 InnoDB 的 MVCC 机制。 1.1 Read View 结构 当事务执行 START TRANSACTION WITH CONSISTENT SNAPSHOT 时,InnoDB 会创建一个 Read View: 1 2 3 4 5 6 7 struct read_view_t { trx_id_t m_low_limit_id; // 系统中尚未分配的最小事务ID(当前最大事务ID + 1) trx_id_t m_up_limit_id; // 活跃事务列表中的最小事务ID trx_id_t m_creator_trx_id; // 创建此 Read View 的事务ID trx_id_t *m_ids; // 创建 Read View 时的活跃事务ID数组(降序) ulint m_n_trx_ids; // 活跃事务数量 }; 注意:InnoDB 的命名反直觉 m_low_limit_id 虽然叫 “low limit”,但实际是最大值(下一个要分配的事务ID) m_up_limit_id 虽然叫 “up limit”,但实际是最小值(最小活跃事务ID) 1.2 可见性判断规则 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 def is_visible(row_trx_id, read_view): # 规则1:如果是当前事务自己修改的,可见 if row_trx_id == read_view.m_creator_trx_id: return True # 规则2:如果行的事务ID < m_up_limit_id(最小活跃事务ID),说明在 Read View 创建前已提交,可见 if row_trx_id < read_view.m_up_limit_id: return True # 规则3:如果行的事务ID >= m_low_limit_id(下一个要分配的ID),说明在 Read View 创建后才开始,不可见 if row_trx_id >= read_view.m_low_limit_id: return False # 规则4:如果在 [m_up_limit_id, m_low_limit_id) 区间内 # 需要检查是否在活跃事务列表 m_ids 中 if row_trx_id in read_view.m_ids: return False # 在活跃列表中,说明创建 Read View 时未提交,不可见 else: return True # 不在活跃列表中,说明已提交,可见 可见性判断示例: ...

2026年3月29日 · 6 分钟 · DBA Student

tpmC、tpm、tps — 数据库性能指标的定义与换算

三个指标的定义 在数据库性能评估中,经常会遇到 tpmC、tpm、tps 这三个指标,它们的含义如下: 指标 全称 含义 tpmC Transactions Per Minute (TPC-C) 每分钟处理的新订单事务数(TPC-C 基准) tpm Transactions Per Minute 每分钟处理的总事务数 tps Transactions Per Second 每秒处理的总事务数 注意区别:tpmC 只统计新订单,tpm 和 tps 统计所有类型的事务。 TPC-C 基准测试的事务模型 tpmC 来自 TPC-C 基准测试。TPC-C 模拟的是一个完整的订单处理系统,包含 5 种事务类型: 事务类型 占比 New Order(新订单) 45% Payment(支付) 43% Order Status(订单查询) 4% Delivery(发货) 4% Stock Level(库存查询) 4% tpmC 只统计其中的 New Order 事务,但系统实际上同时在处理其他 4 种事务。这就是换算公式中 0.45 这个系数的来源。 换算公式 1 tpmC = (1 / 0.45) / 60 ≈ 0.037 tps 逐步推导 假设系统性能为 1 tpmC,即每分钟处理 1 笔新订单: ...

2026年3月26日 · 1 分钟 · DBA Student

MySQL 并行复制调优:slave_parallel_workers 与 Group Commit 深度解析

一、如何评估并行复制能力是否需要调整? 1.1 核心思路 MySQL 并行复制(MTS,Multi-Threaded Slave)的并行粒度由 last_committed 决定: last_committed 相同的事务,可以并行回放 sequence_number 是事务的全局递增序号 1.2 解析 binlog 查看并行度 1 2 # 解析 binlog,查看 last_committed 和 sequence_number mysqlbinlog --no-defaults -v /var/lib/mysql/binlog.000052 | grep -E "last_committed|sequence_number" | head -40 输出示例: #250101 10:00:01 server id 1 end_log_pos 256 GTID last_committed=10 sequence_number=11 #250101 10:00:01 server id 1 end_log_pos 512 GTID last_committed=10 sequence_number=12 #250101 10:00:01 server id 1 end_log_pos 768 GTID last_committed=10 sequence_number=13 #250101 10:00:01 server id 1 end_log_pos 1024 GTID last_committed=10 sequence_number=14 上面 4 个事务 last_committed 都是 10,说明这 4 个事务可以并行回放。 ...

2026年3月26日 · 3 分钟 · DBA Student

relay_log_recovery 的陷阱 — MTS 多线程复制下的数据静默丢失

前言 relay_log_recovery=ON 是 MySQL 主从复制中常见的安全配置,官方文档描述它的作用是:从库重启时,丢弃未执行的 relay log,从主库重新拉取。听起来很安全,但在特定条件下,它不仅救不了你,反而会导致 数据静默丢失 — 复制显示正常,实际上数据已经少了。 本文通过一个完整的实验,从环境确认、故障触发、原因分析到最终修复,逐步展示这个陷阱的全貌。 一、实验环境 角色 实例 服务器 主库 3308 120.48.119.118 从库 3309 101.34.248.57 MySQL 版本:8.0.35,GTID 模式,半同步复制。 从库关键参数 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 mysql> SHOW VARIABLES LIKE 'relay_log_recovery'; +--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | relay_log_recovery | ON | +--------------------+-------+ mysql> SHOW VARIABLES LIKE 'relay_log_info_repository'; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | relay_log_info_repository| TABLE | +--------------------------+-------+ mysql> SHOW VARIABLES LIKE 'slave_parallel_workers'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | slave_parallel_workers| 4 | +-----------------------+-------+ -- ↑ 多线程复制,这是出问题的关键! mysql> SHOW VARIABLES LIKE 'slave_parallel_type'; +--------------------+---------------+ | Variable_name | Value | +--------------------+---------------+ | slave_parallel_type| LOGICAL_CLOCK | +--------------------+---------------+ mysql> SHOW VARIABLES LIKE 'gtid_mode'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | gtid_mode | ON | +---------------+-------+ 配置总结:GTID + AUTO_POSITION + relay_log_recovery + MTS(4 worker) ...

2026年3月26日 · 7 分钟 · DBA Student

Day13 - MySQL分区优化与运维工具

基础章节-01-MySQL数据库服务中级课程 1.00 课程知识章节说明 目前在互联网的实际应用中,各个企业都会比较关注自身网站的数据信息,既要保证数据信息的安全性,同时也要保证数据存储读取效率 并且在特殊的场景下,还要对存储的数据信息进行检索和分析;因此数据库服务业务已经在各行各业应用非常的广泛 对于互联网领域的技术人员,对于数据库服务知识的掌握,也将是在求职时必备的技能,有些时候还会绝对入职的定级和薪资水平。 1.19 数据库服务分区应用 1.19.1 数据库服务分区概述 MySQL从5.1版本开始支持分区的功能;分区是指根据一定的规则,数据库把一个大表分解成多个更小的、更容易管理的部分; 通俗说明:表分区就是将一个大表,根据条件分割成若干个小表; 日常项目开发中经常会遇到大表的情况,所谓大表是指存储了百万级乃至千万级条记录的表。 这样的表过于庞大,导致数据库在查询和插入的时候耗时太长,性能低下;如果涉及联合查询情况,性能会更加糟糕; 对表进行分区,目的就是减少数据库的负担,提高数据库的效率,通常来讲就是提高表的增删改查效率 分区是将数据分段划分在多个位置存放,可以是同一块磁盘也可以在不同的机器; 分区后,表面上还是一张表,但数据散列到多个位置了; 应用程序读写的时候操作的还是大表名字,数据库系统自动去组织分区的数据 就访问数据库的应用而言,逻辑上只有一个表或一个索引,但是实际上这个表可能由数10个物理分区对象组成; 每个分区都是一个独立的对象,可以独自处理,可以作为表的一部分进行处理 分区对应用来说是完全透明的,不影响应用的业务逻辑 例如:某个用户表的记录超过了600万条会员信息,那么就可以根据入会日期将表分区,也可以根据所在地将表分区; 当然也可以根据其他的条件分区; 为了改善大型表以及具有各种访问模式的表的可伸缩性,可管理性和提高数据库效率,因此具有了对表分区的需求; MySQL分区的优点主要包括以下4个方面: 和单个磁盘或者文件系统分区相比,可以存储更多数据;(ext2分区单个文件2T ext3 ext4分区单个文件16T) 优化查询,在where子句中包含分区条件时,可以只扫描必要的一个或多个分区来提高查询效率; 使一些查询操作可以得到极大的优化; 对于已经过期或者不需要保存的数据,可以通过删除与这些数据有关的分区来快速删除数据; 通过删除与增加那些数据有关的分区,很容易地删除或增加那些数据; 通过跨多个磁盘甚至服务器来分散数据查询,以获得更大的查询吞吐量; 在MySQL5.5之后支持所有函数的分区优化,限定只查询有效数据的分区 同时在涉及SUM()和COUNT()这类聚合函数的查询时,可以容易地在每个分区上并行处理,最终只需要汇总所有分区得到的结果 1 select count(*) from employees where gender='F'; 1.19.2 数据库服务分区技术 分区有利于管理非常大的表,它采用了"分而治之"的逻辑,分区引入了分区键(partition-key)的概念; 分区键用于根据某个区间值(或者范围值)、特定值列表或者HASH函数值执行数据的聚集,让数据根据规则分布在不同的分区中; 最终让一个大对象变成一些小对象。 1.19.3 数据库服务分区类型(mycat 分布式存储策略–分表策略) *** 对于MySQL基本常用的分区类型有:基本分区类型 RANGE分区: 基于属于一个给定连续区间的列值,把多行分配给分区; LIST分区: 类似于按RANGE分区,区别在于LIST分区是基于列值匹配一个离散值集合中的某个值来进行选择; HASH分区: 基于用户定义的表达式的返回值来进行选择的分区,该表达式使用将要插入到表中的这些行的列值进行计算; 这个函数可以包含MySQL中有效的,产生非负整数值的任何表达式 KEY分区: 类似于按HASH分区,区别在于KEY分区只支持计算一列或多列,且MySQL服务器提供其自身的哈希函数。必须有一列或多列包含整数值 实战演示分区操作:RANGE分区 基于属于一个给定连续区间的列值,把多行分配给分区; 这些区间要连续且不能相互重叠,使用values less than操作符来进行定义 创建分区操作:在创建表的过程中也可以直接创建分区 例如:将用户表按照年龄每个10岁进行分区; ...

2026年3月13日 · 35 分钟 · DBA Student

Day12 - MySQL性能调优

基础章节-01-MySQL数据库服务中级课程 1.00 课程知识章节说明 目前在互联网的实际应用中,各个企业都会比较关注自身网站的数据信息,既要保证数据信息的安全性,同时也要保证数据存储读取效率 并且在特殊的场景下,还要对存储的数据信息进行检索和分析;因此数据库服务业务已经在各行各业应用非常的广泛 对于互联网领域的技术人员,对于数据库服务知识的掌握,也将是在求职时必备的技能,有些时候还会绝对入职的定级和薪资水平。 1.15 数据库服务冗余架构 1.15.1 数据库服务高可用前言介绍 数据库中的高可用功能,主要是用于避免数据库服务或数据信息的损坏问题,其中数据损坏的类型有: 数据物理损坏:磁盘、主机、程序实例、数据文件误删除 数据逻辑损坏:drop update … 其中,数据库高可用技术的出现主要解决的是数据逻辑损坏问题,而主从架构技术主要解决的是数据物理损坏问题; 数据库高可用解决方案选型依据:(全年无故障率) 无故障率 故障时间 解决方案 99 . 9 % 0 . 1 % ( 525 .6 min) keepalived + 双主架构,但需要人为干预 99 . 99 % 0 . 01 % ( 52 .56 min) MHA ORCHTMHA ,具有自动监控,自动切换,自动数据补偿,但还是属于半自动化比较适合非金融类互联网公司 eg : facebooktaobao 前端-TMHA – >polaradb 99 . 999 % 0 . 001 % ( 5 .256 min) PXC MGR MGC ,数据是高一致性比较适合金融类互联网公司 99 . 9999 % 0 . 0001 % ( 0 .5256 min) 自动化、云计算化、平台化,仍然属于概念阶段 1.15.2 数据库服务高可用软件介绍 MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton研发, ...

2026年3月12日 · 46 分钟 · DBA Student

Day11 - MySQL高可用架构

基础章节-01-MySQL数据库服务中级课程 1.00 课程知识章节说明 目前在互联网的实际应用中,各个企业都会比较关注自身网站的数据信息,既要保证数据信息的安全性,同时也要保证数据存储读取效率 并且在特殊的场景下,还要对存储的数据信息进行检索和分析;因此数据库服务业务已经在各行各业应用非常的广泛 对于互联网领域的技术人员,对于数据库服务知识的掌握,也将是在求职时必备的技能,有些时候还会绝对入职的定级和薪资水平。 1.15 数据库服务冗余架构 1.15.1 数据库服务高可用前言介绍 数据库中的高可用功能,主要是用于避免数据库服务或数据信息的损坏问题,其中数据损坏的类型有: 数据物理损坏:磁盘、主机、程序实例、数据文件误删除 数据逻辑损坏:drop update … 其中,数据库高可用技术的出现主要解决的是数据逻辑损坏问题,而主从架构技术主要解决的是数据物理损坏问题; 数据库高可用解决方案选型依据:(全年无故障率) 无故障率 故障时间 解决方案 99 . 9 % 0 . 1 % ( 525 .6 min) keepalived + 双主架构,但需要人为干预 99 . 99 % 0 . 01 % ( 52 .56 min) MHA ORCHTMHA ,具有自动监控,自动切换,自动数据补偿,但还是属于半自动化比较适合非金融类互联网公司 eg : facebooktaobao 前端-TMHA – >polaradb 99 . 999 % 0 . 001 % ( 5 .256 min) PXC MGR MGC ,数据是高一致性比较适合金融类互联网公司 99 . 9999 % 0 . 0001 % ( 0 .5256 min) 自动化、云计算化、平台化,仍然属于概念阶段 1.15.2 数据库服务高可用软件介绍 MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton研发, ...

2026年3月11日 · 23 分钟 · DBA Student

Day10 - MySQL主从复制

基础章节-01-MySQL数据库服务中级课程 1.00 课程知识章节说明 目前在互联网的实际应用中,各个企业都会比较关注自身网站的数据信息,既要保证数据信息的安全性,同时也要保证数据存储读取效率 并且在特殊的场景下,还要对存储的数据信息进行检索和分析;因此数据库服务业务已经在各行各业应用非常的广泛 对于互联网领域的技术人员,对于数据库服务知识的掌握,也将是在求职时必备的技能,有些时候还会绝对入职的定级和薪资水平。 1.13 数据库服务克隆应用 1.13.1 数据库克隆概念介绍 在数据库MySQL 8.0(8.0.17+)版本中,引入了数据库的克隆功能,主要是借助clone-plugin实现的,是对数据页底层克隆; 克隆的数据是InnoDB存储引擎中的物理快照信息,包括schemas, tables, tablespaces, and data dictionar y metadata; 在数据库中出现克隆功能,主要是为了满足目前云原生的技术应用场景,同时也是为了海量数据备份而诞生的; 在数据库中实现克隆功能应用有两种方式: 本地克隆(Local Cloning): 启动克隆操作的MySQL数据库服务器实例中的数据,将会克隆到同服务器或同节点上的一个目录里; 1669564772486 远程克隆(Remote Cloning): 默认情况下,远程克隆操作会删除接受者(recipient)数据目录中的数据,并将其替换为捐赠者(donor)的克隆数据; 也可以将数据克隆到接受者的其他目录中,以避免删除现有数据;(属于可选操作); 主要用于实现数据远程的快速热迁移操作,在迁移过程中,除了DDL操作情况,其他操作都不会出现阻塞情况; 还可以利用远程克隆技术,实现快速构建数据库的主从架构环境,实现主从数据信息快速复制同步; 1669564937916 1.13.2 数据库克隆原理说明 在进行数据库克隆操作时,会经历几个重要的过程或步骤: 01 Page copy: 在进行数据页复制操作时,会涉及到两个操作动作: 开启redo archiving功能,从当前点开始存储新增的redo_log,这样从当前位置点开始所有的增量修改都不会丢失; 同时上一步在page track的page被发送到目标端,确保当前位置点之前所有做的变更一定发送到目标端; 关于redo archiving实际上这是官方早就存在的功能,主要用于官方的企业级备份工具,clone利用了该特性来维持记录增量产生的redo 在开始克隆前会做一次checkpoint; 对于redo archiving功能应用,会开启一个后台线程log_archiver_thread()来做日志归档; 当有新的写入时(notify_about_advanced_write_lsn),也会通知线程去进行归档,当arch_log_sys处于活跃状态时, 线程会控制日志写入以避免未归档的日志被覆盖(log_write_wait_on_archiver),注意如果log_write等待时间过长的话, archive任务会被中断掉; 02 Redo copy: 停止redo archiving功能,所有归档的日志被发送到目标端,这些日志包含了从page copy阶段开始到现在的所有日志; 另外可能还需要记下当前的复制点,例如:最后一个事务提交时的binlog位置点或者gtid信息,在系统页中可以找到; 03 Done: 目标端重启实例,通过crash recover y将redo log应用上去; 克隆原理过程分析参考链接:https://zhuanlan.zhihu.com/p/437760913 说明:整个克隆过程都会以事件信息记录,可以很清晰的看到克隆的流程,如果克隆过程中断,也会以追加方式进行继续克隆; 在进行克隆功能应用时,也是存在一些限制性操作的:(结合官方列出的限制) 对于MySQL 8.0.27之前版本,在进行克隆操作期间,是不允许在捐赠者和接受者上进行DDL操作,包括:truncate table操作; ...

2026年3月10日 · 38 分钟 · DBA Student