MySQL Enterprise Backup 简称MEB, 是Oracle官方出品的MySQL在线备份工具, 也是众多MySQL企业版用户首选的备份工具, 我们一起来看下MEB 4.1带来了哪些重要改进.

注: MEB 3.x 版本用于MySQL 5.7.9之前版本, MEB 4.x版本用于MySQL 5.7.9之后版本

改进FTWRL

这个问题早在2012年就有人提给Oracle了, 终于在 4.1和 3.12.4版本中改善. 此问题也是我面试必问之一.

当MEB备份进入到最后阶段, 开始拷贝非InnoDB文件时, 为了一致性需要会上锁 FLUSH TABLES WITH READ LOCK, 这是一把全局读锁, 如果恰好有长事务在运行, 将无法成功上锁, 导致备份失败, FTWRL可能会遗留在服务端, 阻塞新的写入请求, 后果很严重.

为了解决这个问题, Xtrabackup 在2.0版本对FTWRL问题增加参数进行了改进

这次MEB增加了--lock-wait-timeout=N (seconds), 默认60s, 当FTWRL上锁超时后会继续上锁, 间隙中会让被阻塞的语句执行. 虽然没有xtrabackup的参数灵活, 但也总比没有强.

多线程工作模式改进

MEB在很早就支持了多线程备份方式, 主要包括1个主线程和5种工作线程

Main threads

主线程负责产生其他工作线程, 并监控工作线程执行情况

Reader threads

负责读取数据文件, 拷贝并传递给Processor thread

Processor threads

负责对实例执行compress, encrypt and validate 等操作(如果执行了相关参数),然后再传递给 Writer threads

Writer threads

负责写数据到指定目标位置

Progress thread

在指定 --show-progress 选项时, 用于显示备份进度

Redo log thread

持续拷贝redo log, 直到Reader线程停止读取数据文件为止. 当多个Reader线程读取数据文件时, 也只有一个redo log 线程完成以下3个任务:

1. 按1MB大小读取redo log segment, 没有写入时休眠10ms, 之后继续读取

2. 验证redo log segment 不存在 损坏问题

3. 将redo log segment写入ibbackup_logfile

MEB 4.1 之前的多线程工作模式, 如下图

MEB 4.1 改进后的多线程工作模式, 如下图

改进后原来的Redo log thread被拆成了 3个独立的线程

Reader redo log thread

每次读取1MB redo log segment, 放置到16MB的buffer队列中, 便于后续的线程处理, 没有可读日志则休眠10ms-1s, 唤醒后继续读取日志.

Proceesor redo log thread

验证redo log segment, 并传递给Writer redo log thread

Writer redo log thread

将redo log segment 写入ibbackup_logfile文件

结论: 改进后加快了对于redo log 处理的速度, 避免原来因为redo log产生太快, 造成备份失败的情况发生.

乐观增量备份(Optimistic Incremental Backup)

在MEB 4.0(3.11)版本, 为了提高备份恢复效率, 支持了 Optimistic Backup, 但只支持全备方式, 并且需要手动定义 optimistic-busy-tables或 optimistic-time.

虽说是增量备份但一直都是扫描全部表文件即便只有少量表发生变更, 所以增量备份效率也不理想. 这次MEB大大改进了增量备份的效率. 新的增量备份算法被称为Optimistic Incremental Backup.

补充: xtrabackup 从2.1版本开始支持增量备份扫描变化表, 但仅限Percona Server分支, 利用XtraDB changed page tracking技术, 对于MySQL分支目前还是扫描数所有表.

在Optimistic Incremental Backup中, MEB定义了unchanged table 和 busy table , 前者表示上次备份之后没有变化的表, 后者表示发生了变化的表.Optimistic Incremental Backup只会扫描busy table, 不再扫描unchanged table. 具体是怎么做到的?

首先, MEB在备份开始时会记录Start time, 当开始备份非InnoDB文件时, 会获取一把读锁(时间很短), 此时间点被称为Consistency time, 并记录在backup_history 和backup_variables.txt中, 字段名为consistency_time_utc, 如果指定了 --no-locking 或 --no-connection 参数 start time 会作为 Consistency time.

然后, 当MEB下次执行Optimistic Incremental Backup 时, 会比对每个表的修改时间与Consistency time, 在Consistency time之后的表被当做busy table, 只扫描这部分表.

1.上次备份扫描备份了 6张表

2.上锁后记录Consistency time

3.表7在解锁后创建,随后备份结束

4. 在下次备份前, 表1和表8发生了变化

5.执行增量备份, 比对所有表的修改时间与Consistency time, 发现有3张表在上次备份的Consistency time之后, 其他表(unchanged table)则被忽略. 如果备份时unchanged table 发生变化会被记录到redo log中, 在恢复时apply log 阶段会将这些变更应用到数据文件中.

选择乐观增备模式需要指定--incremental=optimistic, 如果使用原始的增备模式 --incremental=full-scan 或不指定参数, 当遇到无法使用乐观模式的场景时,也会自动回退到原始模式.

官方对比了原始的Incremental Backup(IB) 和Optimistic Incremental Backup(OIB), 数据总量1T, 10个表, 每个表100G, 分别执行3次测试, 第一次修改1张表, 第二次修改 2张表, 第三次修改3张表. 以下是测试结果, 可以看出新的增备模式备份速度上提高了至少60-80%

改进日志输出

MEB默认在<backup_dir>/meta目录下, 会产生一个比较详细的备份日志, MEB_<Date.time>_<operation_name>.log. 日志也是分析备份任务行为, 诊断备份异常的重要途径, 老版本的MEB 在日志输出上粒度上比较粗犷, 尤其对于多线程程序, 也没有打印每个工作线程的工作情况. 4.1版本对于日志模块进行了优化, 将每个工作现场的日志信息都完整的打印出来, 并且增加了4个跟踪级别(0,1,2,3),

MEB 4.1版本之前的日志输出

MEB 4.1版本的日志输出

格式: 线程名缩写+编号

RDR1: Reader thread #1

PCR1: Processor thread #1

WTR1: Writer thread #1

CLD1: Cloud Thread #1

RLR1: Redo Log Reader thread #1

RLP1: Redo Log Processor thread #1

RLW1: Redo Log Writer thread #1

ALW1: Apply Log Worker thread #1