Posts

问题现象 使用 XtraBackup 对 MySQL 进行热备份时，出现如下报错，备份任务中断： [ERROR] [MY-011825] [Xtrabackup] unable to open /innodb_redo/ib_redo368 err 1504 [ERROR] [MY-011825] [Xtrabackup] read_logfile() failed 根本原因 XtraBackup 的工作机制 XtraBackup 热备的核心流程如下： 记录备份开始时的 LSN（Log Sequence Number） 拷贝 InnoDB 数据文件（此过程数据仍在变化） 后台持续监听并复制 redo log，确保能捕获备份期间所有数据变化 备份完成后，通过 --prepare 阶段对拷贝的数据做 crash recovery，使其达到一致性状态 第 3 步是问题的关键：XtraBackup 需要不间断地读取 redo log 文件。 MySQL 8.0.30 的 redo log 变更 MySQL 8.0.30 对 InnoDB redo log 做了重大架构调整： 对比项 8.0.30 之前 8.0.30 及之后 存储位置 datadir 根目录 #innodb_redo/ 子目录 文件名 ib_logfile0、ib_logfile1 #ib_redo<N>（活跃）、#ib_redo<N>_tmp（备用） 管理方式 固定 2 个文件，循环写入 多文件动态创建与回收 容量配置 innodb_log_file_size × 2 innodb_redo_log_capacity 新机制下，MySQL 会动态回收已经不再需要的 redo log 文件。在没有任何保护的情况下，XtraBackup 后台线程正在读取某个 #ib_redo<N> 文件时，MySQL 可能已将其回收，导致 XtraBackup 打开文件失败，从而报出 unable to open ... read_logfile() failed。 ...

前言 主从延迟是 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：网络带宽不足 原理： ...

前言 在 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 # 不在活跃列表中，说明已提交，可见 可见性判断示例： ...

三个指标的定义 在数据库性能评估中，经常会遇到 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 笔新订单： ...

一、如何评估并行复制能力是否需要调整？ 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 个事务可以并行回放。 ...

前言 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) ...

基础章节-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岁进行分区； ...

基础章节-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研发， ...

基础章节-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研发， ...

基础章节-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操作； ...