vlambda博客
学习文章列表

一、前言

备份作为容灾的基础，其重要性不言而喻。本文将以我们熟悉的MySQL数据库着手，构建企业级备份恢复系统，希望能带给大家一些借鉴意义。

二、 系统目标

1. 从库恢复：指定服务器快速恢复从库实例
2. 数据恢复：实现七天内任意时间点的数据恢复
3. 数据追踪：获取目标时间段内的相关更新，按需生成原始SQL，回滚SQL，或DML统计信息

三、实现方案

1. 全量备份：xtrabackup

xtrabackup是percona公司开源的MySQL物理热备工具，其工作原理是在启动时记录日志序列号(LSN)，然后复制所有的数据文件，同时运行一个后台进程来监视事务日志，并复制更改，最终得到一个一致性坐标点的全量备份文件。

2. 增量备份：mysqlbinlog

mysqlbinlog可以读取二进制日志文件并写入包含相同内容的新文件，借此实现以原始格式备份二进制文件。

3. 数据追踪：my2sql

my2sql是golang语言实现的MySQL Binlog解析工具，通过解析Binlog，可以生成原始SQL，回滚SQL，去除主键的INSERT SQL等，也可以生成DML统计信息。

4. 恢复数据

由于主从Binlog文件点位的不一致性，所以这里采用GTID联动全量备份和增量Binlog重放。这是由于GTID(全局事务标识)具有全局唯一性，一个事务对应一个GTID，它在整个复制拓扑中都是唯一的。借助GTID，我们就可以无视全量备份来源和增量Binlog来源的不同。

四、架构设计

系统层次

为了实现七天内极端情况下的数据恢复，我们需要对全量数据及增量Binlog进行备份，并保留七天。由此，我们将系统拆分为：存储模块，备份模块，恢复模块。为了更好地了解备份系统的运行状态，需要接入报表支持。现在我们通过系统的功能层次图进一步拆分下系统功能。

对于备份恢复系统，我将它从上到下拆分为四个部分。最上层的平台层是系统的web访问入口，为了简化DMS平台的开发任务量，所以直接使用Django框架原生的后台来管理定时任务。中间的基础服务层主要包括：负责异步调度的Celery，和轻量级的Redis作为消息队列。至于远程调度，Servant是一个通过HTTP协议执行配置命令和服务器文件读写的通用代理，这点可替代为Ansible或者SaltStack。而Ansible主要负责下发脚本，以保持主机脚本的一致性。最后我们重点看下功能层的相关模块：

1. 存储模块：管理存储相关功能，包括容量更新及备份清理。为备份策略提供数据支持以便更好地均衡数据
2. 数据备份：管理全量备份的备份任务及相关元数据，包括策略，历史，日志和黑名单等
3. Binlog：管理Binlog备份的备份任务及相关元数据。其中Binlog记录包括备份的实例信息，存储信息以及备份文件的点位信息等
4. 恢复模块：管理数据恢复及Binlog相关功能，包括恢复从库，恢复数据以及数据追踪
5. 报表模块：管理存储，实例及备份相关的统计数据。辅助管理人员更好地了解备份系统的运行状态

架构简图

其主要分为任务机和调度中心这两个任务线部分。其中：

• 任务机：除了存放软件和下发脚本外，还会根据元数据信息生成备份策略
• 调度中心：根据备份策略异步调度远程主机上的Servant执行相关任务。比如备份，清理等

五、模块设计

全量备份

1. 原则

• 分散存储：连续两次备份不能存放在同一台存储机上，避免存储机硬件异常导致备份数据丢失
• 存储均衡：依据存储机可用资源，集群备份大小生成备份策略，均衡空间使用
• 高度可控：考虑到数据库环境的复杂性，所以备份的节点，频率，时间，并发，优先级，保留天数等需要高度可配置
• 从库备份：为了避免备份影响到业务服务，数据备份需要通过从库进行

2. 状态流转
   
   

3. 辅助任务

• 备份状态检查：扫描备份中的任务，若进程不存在，则将状态更新为“已失败”
• 失败任务重试：扫描备份失败的集群，如果失败的历史记录小于10次，则将状态更新为“未开始”，以便下次调度
• 失败记录清理：扫描失败历史记录，若备份已完成，则删除失败的历史记录
• 失败任务通知：DMS平台展示+邮件通知

增量备份

1. 主任务：增量备份是持续性的，需要保持备份进程。这里采用的方式是每十分钟检查一遍备份任务。如果正在备份中，则更新Binlog记录信息。否则尝试进行修复，并根据修复的结果更新备份状态
2. 黑名单清理：停止已加黑的备份任务，并清理备份相关记录和备份产生的Binlog文件
3. 备份清理：根据保留天数清理过期的备份文件并将记录更新为“已删除”

点位恢复

1. 通过备份历史获取可用的全量备份
2. 恢复机上拉起全量备份
3. 根据全量备份的开始时间及恢复时间点获取Binlog文件
4. 解析最后一个Binlog文件获取恢复时间点的文件点位信息
5. 将Binlog作为relay log进行重放：将要恢复的Binlog调整命名后拷贝到relay log目录，然后启动sql_thread进行重放

mysql> start slave sql_thread until relay_log_file='xxx', relay_log_pos=xxx;

6. 业务确认恢复数据是否OK。若偏左，可继续重放；若偏右，解析回退期间的binlog，如无DDL，借助my2sql回滚，否则需要重做
7. 覆盖生产数据

作者介绍

欧阳逸云，信也科技集团DBA资深专家。

参考链接

1. xtrabackup参数介绍：https://www.percona.com/doc/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html
2. mysqlbinlog备份介绍：https://dev.mysql.com/doc/refman/5.7/en/mysqlbinlog-backup.html
3. my2sql解析工具介绍：https://github.com/liuhr/my2sql