CN112540875B - 一种基于xtrabackup的mysql数据库备份、恢复校验可用性的方法 - Google Patents

Abstract

本发明公开了一种基于xtrabackup的mysql数据库备份、恢复校验可用性的方法，属于实时数据库在信息化系统应用领域，解决了Xtrabackup对数据库进行逻辑备份或物理备份后缺少校检，以及备份效率低和备份容易损坏文件的问题。包括以下步骤：通过xtrabackup备份现有的数据库集群；将备份文件上传至备份服务器；记录备份完成时间并定时恢复所述备份文件；启动mysql检查所述备份文件的各个表。本发明旨在：提高备份文件的工作效率，减少备份文件故障发生以及对备份文件进行校检。本发明应用于数据库的备份、恢复以及校检。

Description

一种基于xtrabackup的mysql数据库备份、恢复校验可用性的 方法

技术领域

本发明属于实时数据库在信息化系统应用领域，具体涉及一种基于xtrabackup的mysql数据库备份、恢复校验可用性的方法。

背景技术

xtrabackup是一款基于InnoDB(mysql的默认存储引擎)的在线热备工具，具有开源，免费，支持在线热备，备份恢复速度快，占用磁盘空间小等特点，并且支持不同情况下的多种备份形式。

mysql是一个开放源代码的关系数据库管理系统，和其它数据库相比，mysql有点与众不同，它的架构可以在多种不同场景中应用并发挥良好作用，主要体现在存储引擎的架构上，插件式的存储引擎架构将查询处理和其它的系统任务以及数据的存储提取相分离。这种架构可以根据业务的需求和实际需要选择合适的存储引擎。mysql数据库是目前较流行的关系型数据，mysql常用的备份方法有mysqldump(mysql的数据库备份工具)方法、xtrabackup方法。mysqldump方法在备份过程中会加锁影响数据库业务，xtrabackup是mysql热备份软件，可以为InnoDB和XtraDB(mysql的一个存储引擎)数据库执行非阻塞备份，可快速、可靠的完成备份，备份期间不间断事务处理，同时自带备份验证功能，出现故障时能够快速的备份恢复。

现有技术中一般通过数据库的备份工具xtrabackup对数据库进行逻辑备份或物理备份，在备份过程中可能出现一台机器执行多个备份文件，造成备份效率低或者使备份文件损坏，但是缺少对数据备份文件是否可用的校验，当备份文件损坏后无法查知，等文件恢复后出现文件不可用等事故。

发明内容

针对现有技术中通过数据库的备份工具Xtrabackup对数据库进行逻辑备份或物理备份后缺少校检，以及备份效率低和备份容易损坏文件等问题，本发明提供一种基于xtrabackup的mysql数据库备份、恢复校验可用性的方法，其目的在于：提高备份文件的工作效率，减少备份文件故障发生以及对备份文件进行校检。

本发明采用的技术方案如下：

一种基于xtrabackup的mysql数据库备份、恢复校验可用性的方法，包括以下步骤：

步骤A：通过xtrabackup将mysql数据库集群的数据备份至备份数据库；

步骤B：将备份数据库中的备份文件上传至备份服务器；

步骤C：通过计时器记录所述mysql数据库集群的备份完成时间；

步骤D：轮训备份完成的文件，根据所述数据库集群的重要程度对所述备份文件进行排序并恢复；

步骤E：在备份数据库的存储介质中建立备份数据库的表空间结构；

步骤F：通过mysql检查所述备份文件的各个表。

xtrabackup备份的原理如下：

1.innobackupex(xtrabackup工具包的命令行工具)在启动后，会先fork(创建)一个进程，启动xtrabackup进程，然后就等待xtrabackup备份完ibd(存了每个表的元数据的文件，包括表结构的定义等数据)数据文件；

2.xtrabackup在备份InnoDB(mysql的默认存储引擎)相关数据时，是有两种线程的，一种是redo(重做)拷贝线程，负责拷贝redo文件(记录数据修改后的记录的文件)，另一种是ibd拷贝线程，负责拷贝ibd文件；redo拷贝线程只有一个，在ibd拷贝线程之前启动，在ibd线程结束后结束。xtrabackup进程开始执行后，先启动redo拷贝线程，从最新的checkpoint(检查点)开始顺序拷贝redo日志(存储引擎InnoDB生成的日志)；然后再启动ibd数据拷贝线程，在xtrabackup拷贝ibd过程中，innobackupex进程一直处于等待状态，等待文件被创建；

3.xtrabackup拷贝完成ibd后，通过创建文件通知innobackupex，同时自己进入等待，此时redo线程仍然继续拷贝；

4.innobackupex收到xtrabackup通知后，执行FLUSH TABLES WITH READ LOCK(FTWRL，该命令主要用于备份工具获取一致性备份，数据与binlog(binary log，二进制日志文件)位点匹配)，取得一致性位点，然后开始备份非InnoDB文件。拷贝非InnoDB文件过程中，数据库处于全局只读状态；

5.当innobackupex拷贝完所有非InnoDB表文件后，通过删文件通知xtrabackup，同时自己进入等待另一个文件被创建；

6.xtrabackup收到innobackupex备份完非InnoDB通知后，就停止redo拷贝线程，然后通过创建文件通知innobackupex，redo log拷贝完成；

7.innobackupex收到redo备份完成通知后，就开始解锁，执行UNLOCK TABLES(当前线程锁定表)；

8.最后innobackupex和xtrabackup进程各自完成收尾工作，如资源的释放、写备份元数据信息等，innobackupex等待xtrabackup子进程结束后退出。

在备份数据库中建立数据库的表空间结构，对备份完成后所有表进行查询校验，避免文件损坏，在备份文件存在的时间范围内，有效的对备份文件进行校验，避免出现需要恢复备份文件时，所有备份都不可用的情况。

进一步的，所述步骤A包括：

步骤A1：通过元数据管理查询出mysql集群备份的实例机器；

步骤A2：在所述mysql集群允许的备份时间范围内连接到备份机器并执行xtrabackup备份脚本；

步骤A3：通过ssh不落本地磁盘的方式将备份文件直接上传到所述备份服务器。

进一步的，所述步骤A1包括：

步骤A11：元数据管理对每个所述mysql集群的实例机器进行权重管理；

步骤A12：选出权重符合要求的实例机器并确定所述权重符合要求的实例机器的当前备份执行状态。

进一步的，所述步骤A2包括：

步骤A21：上传备份文件至调度服务器上；

步骤A22：生成最新的xtrabackup备份脚本到权重符合要求的实例机器；

步骤A23：执行所述xtrabackup备份脚本。

进一步的，所述步骤A3具体为：

通过所述ssh的端口通道将备份文件，以不落本地磁盘的方式直接上传到所述备份服务器。

利用xtrabackup提供的Xbstream备份模式(xtrabackup的xbstream流备份，直接备份后，通过管道直接压缩，这样把原来多次，减少为一次，整个使用时间也变短了)，然后在通过nc(netcat计算机网络共用程序)或者ssh(Secure shell安全外壳协议)传输到对应备份服务器上，不会落地到本地。

所述步骤C包括：

步骤C1：将所述xtrabackup备份脚本执行完成情况记录到元数据库；

步骤C2：将成功执行完成xtrabackup备份脚本的记录分类。

进一步的，所述步骤C包括：

步骤D1：根据单独维护的数据库集群恢复顺序表；

步骤D2：选择最新完成的备份文件进行恢复文件的验证；

步骤D3：将验证情况记录到所述mysql数据库。

恢复的目的是把备份集中的数据恢复到一个一致性位点，所谓一致就是指原数据库某一时间点各引擎数据的状态，比如MyISAM(mysql区别于InnoDB的默认搜索引擎)中的数据对应时间点与InnoDB中的数据对应的时间是相同的，这种状态的数据就是一致的。PXB(percona xtrabackup的缩写，percona xtrabackup是xtrabackup的全称)备份集对应的一致点，就是备份时FTWRL的时间点，恢复出来的数据，就对应原数据库FTWRL时的状态。

因为备份时FTWRL后，数据库是处于只读的，非InnoDB数据是在持有全局读锁情况下拷贝的，所以非InnoDB数据本身就对应FTWRL时间点；InnoDB的ibd文件拷贝是在FTWRL前做的，拷贝出来的不同ibd文件最后更新时间点是不一样的，这种状态的ibd文件是不能直接用的，但是redo log是从备份开始一直持续拷贝的，最后的redo日志点是在持有FTWRL后取得的，所以最终通过redo应用后的ibd数据时间点也是和FTWRL一致的。

所以恢复过程只涉及InnoDB文件的恢复，非InnoDB数据是不动的。备份恢复完成后，就可以把数据文件拷贝到对应的目录，然后通过mysqld(mysql的守护进程，每次在使用mysql前必须先用它)来启动了。

综上所述，由于采用了上述技术方案，本发明的有益效果是：

1.由于备份完成后所有表进行查询校验，避免文件损坏，在备份文件存在的时间范围内，有效的对备份文件进行校验，解决了对数据库进行逻辑备份或物理备份后缺少校检，以及备份效率低和备份容易损坏文件等问题，进而避免出现需要恢复备份文件时，所有备份都不可用的情况。

2.由于整个备份过程中能保证单台实例机器只有一个备份发生，当实例机器正在进行某个备份任务时，其他待备份任务不可执行，只有执行完毕该备份任务后，其他带备份任务才能被处理，解决了现有技术中多个实例机器容易出现备份错误的问题，进而避免资源消耗以及出现资源备份错误。

3.由于通过轮训恢复备份文件，并通过binlog(binary log，二进制日志文件)恢复到指定时间点，解决了现有技术中备份文件错误而无法恢复的问题，保证至少有一天的文件是可靠的。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是mysql数据库备份及恢复校验可用性的方法的流程图；

图2是xtrabackup备份的原理图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请技术方案的一部分实施例，而不是全部的实施例。基于本申请文件中记载的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请技术方案保护的范围。

下面对本申请实施例中涉及的部分概念进行介绍。

xtrabackup：一款基于InnoDB(mysql的默认存储引擎)的在线热备工具，具有开源，免费，支持在线热备，备份恢复速度快，占用磁盘空间小等特点，并且支持不同情况下的多种备份形式。

mysql：一个开放源代码的关系数据库管理系统，和其它数据库相比，mysql有点与众不同，它的架构可以在多种不同场景中应用并发挥良好作用，主要体现在存储引擎的架构上，插件式的存储引擎架构将查询处理和其它的系统任务以及数据的存储提取相分离。这种架构可以根据业务的需求和实际需要选择合适的存储引擎。

数据库集群：利用至少两台或者多台数据库服务器，构成一个虚拟单一数据库逻辑映像，像单数据库系统那样，向客户端提供透明的数据服务。

元数据管理：包括业务词汇表的发展，数据元素和实体的定义，业务规则和算法以及数据特征。

xtrabackup备份脚本：第一次执行它的时候它会检查是否有完全备份,否则先创建一个全库备份；当你再次运行它的时候，它会根据脚本中的设定来基于之前的全备或增量备份进行增量备份。

ssh不落本地磁盘的方式：利用xtrabackup提供的Xbstream备份模式(xtrabackup的xbstream流备份，直接备份后，通过管道直接压缩，这样把原来多次，减少为一次，整个使用时间也变短了)，然后在通过nc(netcat计算机网络共用程序)或者ssh(Secure shell安全外壳协议)传输到对应备份服务器上，不会落地到本地。

轮训：对数据库集群进行优先级排序，优先恢复高优先级数据库集群，然后优先选择最近备份的文件，最后是其他文件。

Innobackupex：xtrabackup工具包的命令行工具。

Ibd：存了每个表的元数据的文件，包括表结构的定义等数据。

FLUSH TABLES WITH READ LOCK：FTWRL，该命令主要用于备份工具获取一致性备份，数据与binlog(binary log，二进制日志文件)位点匹配。

以下结合说明书附图对本申请的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本申请，并不用于限定本申请，并且在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

实施例

如图1所示，其为数据库备份及恢复校验可用性的方法的流程图。

步骤A：通过xtrabackup将mysql数据库集群的数据备份至备份数据库。

如图2所示，xtrabackup备份原理如下：

1.innobackupex在启动后，会先fork(创建)一个进程，启动xtrabackup进程，然后就等待xtrabackup备份完ibd数据文件；

2.xtrabackup在备份InnoDB(mysql的默认存储引擎)相关数据时，是有两种线程的，一种是redo(重做)拷贝线程，负责拷贝redo文件，另一种是ibd拷贝线程，负责拷贝ibd文件；redo拷贝线程只有一个，在ibd拷贝线程之前启动，在ibd线程结束后结束。xtrabackup进程开始执行后，先启动redo拷贝线程，从最新的checkpoint(检查点)开始顺序拷贝redo日志(存储引擎InnoDB生成的日志)；然后再启动ibd数据拷贝线程，在xtrabackup拷贝ibd过程中，innobackupex进程一直处于等待状态，等待文件被创建；

3.xtrabackup拷贝完成ibd后，通过创建文件通知innobackupex，同时自己进入等待，此时redo线程仍然继续拷贝；

4.innobackupex收到xtrabackup通知后，执行FLUSH TABLES WITH READ LOCK(FTWRL)，取得一致性位点，然后开始备份非InnoDB文件。拷贝非InnoDB文件过程中，数据库处于全局只读状态；

5.当innobackupex拷贝完所有非InnoDB表文件后，通过删文件通知xtrabackup，同时自己进入等待另一个文件被创建；

6.xtrabackup收到innobackupex备份完非InnoDB通知后，就停止redo拷贝线程，然后通过创建文件通知innobackupex，redo log拷贝完成；

7.innobackupex收到redo备份完成通知后，就开始解锁，执行UNLOCK TABLES(当前线程锁定表)；

8.最后innobackupex和xtrabackup进程各自完成收尾工作，如资源的释放、写备份元数据信息等，innobackupex等待xtrabackup子进程结束后退出。

innobackupex在后台线程不断追踪InnoDB的日志文件，然后复制InnoDB的数据文件。数据文件复制完成之后，日志的复制线程也会结束。这样就得到了不在同一时间点的数据副本和开始备份以后的事务日志。完成上面的步骤之后，就可以使用InnoDB崩溃恢复代码执行redo log(事务日志)，以达到数据的一致性。

步骤B：将备份数据库中的备份文件上传至备份服务器。

通过元数据管理查询出mysql集群备份的实例机器，元数据管理对每个所述mysql集群的实例机器进行权重管理，实例初始化过后，就会对整个数据集群的实例进行权重分配，定义的权重优先级为：备份机器的权重最小，其次是提供查询机器的权重，最后是切换优先选择权重，数据库集群的主库的权重与切换优先选择权重相等，并且权重管理后的机器，根据机器的情况实时做调整，进行一个加减分控制，例如，正在备份的机器A的权重为零，提供查询数据的机器的权重为一，备份完成的机器B的权重为二，当一分钟后，正在备份的机器A完成备份任务，重新给机器A分配权重为二，在两分钟后，机器A接收到一个新的备份任务，再次重新给A分配的权重为零。选出权重符合要求的实例机器并确定所述权重符合要求的实例机器的当前备份执行状态，将生成最新的数据库备份脚本到所述权重符合要求的实例机器，执行所述xtrabackup备份脚本，利用xtrabackup提供的Xbstream备份模式，然后在通过ssh传输到对应备份服务器上，不会落地到本地，并直接上传到所述备份服务器。

步骤C：通过计时器记录所述mysql数据库集群的备份完成时间。

计时器将所述xtrabackup备份脚本执行完成情况记录到元数据库，包括备份完成的时间以及是否完成备份。

步骤D:轮训备份完成的文件，根据所述数据库集群的重要程度对所述备份文件进行排序并恢复。

将所述xtrabackup备份脚本执行完成情况记录到元数据库，轮训备份完成的文件，对数据库集群进行优先级排序，优先恢复高优先级数据库集群，然后优先选择最近备份的文件，最后是其他文件。根据集群重要程度排序恢复文件，根据单独维护的集群恢复顺序表，选择最新的完成的备份文件进行恢复还原验证，根据情况记录到数据库还原情况，不保证某个集群的所有文件都会去恢复，但是保证的是一个集群存在的备份文件中，肯定会有一个可以恢复成功的文件。

步骤E：在备份数据库的存储介质中建立备份数据库的表空间结构。

在备份数据库的存储介质中，建立备份数据库的表空间结构，在创建表空间后，使该表空间对授权该表空间的用户能够通过mysql查询备份文件的状态，进而判断备份文件是否出现错误。

步骤F：通过mysql检查所述备份文件的各个表。

通过mysql主要检测备份文件是否出现损坏，若损坏，需要重新备份，以免将来需要备份文件时，出现源文件丢失，而备份文件不可使用的问题，简单查询每个表的数据大小，若大小不对，可简单判断备份过程出现错误，造成文件丢失等情况，随机查询部分数据，对部分数据查询并执行代码，查看是否能执行以上语句，进而判断备份文件是否出错。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (5)

1.一种基于xtrabackup的mysql数据库备份、恢复校验可用性的方法，其特征在于，包括以下步骤：

步骤A：通过xtrabackup将mysql数据库集群的数据备份至备份数据库；包括如下步骤:

步骤A1：通过元数据管理查询出mysql集群备份的实例机器；

步骤A11：元数据管理对每个所述mysql集群的实例机器进行权重管理；

步骤A12：选出权重符合要求的实例机器并确定所述权重符合要求的实例机器的当前备份执行状态；

步骤A2：在所述mysql集群允许的备份时间范围内连接到备份机器并执行xtrabackup备份脚本；

步骤A3：通过ssh不落本地磁盘的方式将备份文件直接上传到备份服务器；

步骤B：将备份数据库中的备份文件上传至备份服务器；包括如下内容：

通过元数据管理查询出mysql集群备份的实例机器，元数据管理对每个所述mysql集群的实例机器进行权重管理，实例初始化过后，就会对整个数据集群的实例进行权重分配，定义的权重优先级为：备份机器的权重最小，其次是提供查询机器的权重，最后是切换优先选择权重，数据库集群的主库的权重与切换优先选择权重相等，并且权重管理后的机器，根据机器的情况实时做调整，进行一个加减分控制；选出权重符合要求的实例机器并确定所述权重符合要求的实例机器的当前备份执行状态，将生成最新的数据库备份脚本到所述权重符合要求的实例机器，执行所述xtrabackup备份脚本，利用xtrabackup提供的Xbstream备份模式，然后在通过ssh传输到对应备份服务器上，不会落地到本地，并直接上传到所述备份服务器；

步骤C：通过计时器记录所述mysql数据库集群的备份完成时间；

步骤D：轮训备份完成的文件，根据所述数据库集群的重要程度对所述备份文件进行排序并恢复；

步骤E：在备份数据库的存储介质中建立备份数据库的表空间结构；

步骤F：通过mysql检查所述备份文件的各个表。

2.根据权利要求1所述的一种基于xtrabackup的mysql数据库备份、恢复校验可用性的方法，其特征在于，所述步骤A2包括：

步骤A21：上传备份文件至调度服务器上；

步骤A22：生成最新的xtrabackup备份脚本到权重符合要求的实例机器；

步骤A23：执行所述xtrabackup备份脚本。

3.根据权利要求1所述的一种基于xtrabackup的mysql数据库备份、恢复校验可用性的方法，其特征在于，所述步骤A3具体为：

通过所述ssh的端口通道将备份文件，以不落本地磁盘的方式直接上传到所述备份服务器。

4.根据权利要求1所述的一种基于xtrabackup的mysql数据库备份、恢复校验可用性的方法，其特征在于，所述步骤C包括：

步骤C1：将所述xtrabackup备份脚本执行完成情况记录到元数据库；

步骤C2：将成功执行完成xtrabackup备份脚本的记录分类。

5.根据权利要求1所述的一种基于xtrabackup的mysql数据库备份、恢复校验可用性的方法，其特征在于，所述步骤C包括：

步骤D1：根据单独维护的数据库集群恢复顺序表；

步骤D2：选择最新完成的备份文件进行恢复文件的验证；

步骤D3：将验证情况记录到所述mysql数据库。

Images