CN104881418A - 用于MySQL的快速回收回滚空间的方法和装置 - Google Patents

Abstract

本申请公开了一种用于MySQL的快速回收回滚空间的方法，包括：采用在关闭过程中清除无效回滚数据的方式关闭MySQL数据库；以待回收回滚空间的原始系统表空间文件为基础，生成一个不包含回滚空间的新的系统表空间文件；用所述新的系统表空间文件替换所述原始系统表空间文件。本申请同时提供一种用于MySQL的快速回收回滚空间的装置。采用本申请提供的方法，可以快速回收MySQL的回滚空间，提高整个数据库系统的可用性。

Description

用于MySQL的快速回收回滚空间的方法和装置

技术领域

本申请涉及数据库回滚空间的回收技术，具体涉及一种用于MySQL的快速回收回滚空间的方法。本申请同时涉及一种用于MySQL的快速回收回滚空间的装置。

背景技术

MySQL是一个关系型数据库管理系统，支持多种数据库引擎，其主流是支持事务机制的InnoDB存储引擎，而回滚日志（undo log）则是InnoDB引擎中用于实现事务回滚的日志，通常存储在InnoDB的系统表空间文件（例如：ibdata1文件）中。Undo log的工作原理是这样的：在执行事务中的任何数据库操作之前，首先将与该操作相关的数据备份到undo log中，然后执行该数据库操作，如果后续需要撤销该操作或者获取执行该操作之前的数据信息，系统可以利用undo log中的备份实现上述功能。

MySQL InnoDB使用undo log主要实现以下两个方面的用途：一方面，用于保证事务的原子性，当数据库事务未能正确完成，或者在执行期间由于异常原因需要恢复到事务开始的状态，这种情况下需要使用undo log进行回滚操作；另一方面，用于进行多版本并发控制（MVCC），从而实现InnoDB事务间的缺省隔离级别：可重复读（repeatable-read），该隔离级别要求用户在事务持续期间看到的数据视图与事务开始前一致，当某个事务中的一个数据库操作发现其要访问的数据的最新版本已经被修改（从本事务启动到当前的这段时间内，该数据已被其他事务修改），这时就需要结合最新版本的undo log获取该数据未更新前的值，即本事务本应看到的版本。当数据库事务结束后，InnoDB会判定并标记与该事务相关的undo log可以被回收且重新利用，之后其他事务再次需要申请新的undo log时，就可以从这些被标记为已回收且可重新利用的回滚空间（即：系统表空间文件中用于记录undo log的部分）中申请。

虽然已经申请并且分配的回滚空间可以重复利用，但是InnoDB对上述可重复读隔离级别的支持，可能会导致回滚空间的过度膨胀。如果系统启动了一个执行时间较长的事务，例如select*from tb_name where id=x，为了能够维持这个事务始终能够看到开始执行时的相同视图，那么在这个事务启动后的undo log都不能被InnoDB回收并重新利用，这就导致当空闲undo log使用完成以后，必须向操作系统申请新的空间，从用户角度看，就是系统表空间文件变大了。膨胀后的回滚空间虽然可以重复利用，但是却没有机会返回给操作系统，因此回滚空间只可能越来越大，甚至可能出现接近100G的情况，那么包含该回滚空间的系统表空间文件就会始终占据磁盘空间，造成磁盘浪费。

针对上述MySQL回滚空间过大的问题，现有技术采用重建用户数据的方式回收回滚空间，通常采用以下步骤：

1）将待回收回滚空间的数据库的数据全部导出；

2）删除待回收回滚空间的数据库实例；

3）重新创建一个空的数据库实例；

4）将之前全部导出的数据导入新创建的空数据库实例中。

上述现有技术方案虽然可以有效地回收回滚空间，使系统表空间文件的长度缩小为系统配置文件中设置的初始值，例如200M，但是上述回收回滚空间的过程非常耗时，主要是步骤1）和步骤4）的数据导出和导入操作，对于数据量大的、达到百G级别的实例来说，通常需要一个甚至数个小时才能完成数据的导出和导入操作。而在具体的应用中，为了保证服务的可用性，MySQL数据库系统通常采用主备服务器的架构，那么当其中一台服务器执行上述耗时的回收回滚空间操作时，另一台作为主库工作的服务器就缺少实时备份实例，这意味着在此期间若主库出现故障，系统无法提供直接可用的备机，从而直接影响数据库服务的可用性。

发明内容

本申请提供一种用于MySQL的快速回收回滚空间的方法，以解决现有技术回收MySQL回滚空间耗时长的问题。本申请另外提供一种用于MySQL的快速回收回滚空间的装置。

本申请提供一种用于MySQL的快速回收回滚空间的方法，包括：

采用在关闭过程中清除无效回滚数据的方式关闭MySQL数据库；

以待回收回滚空间的原始系统表空间文件为基础，生成一个不包含回滚空间的新的系统表空间文件；

用所述新的系统表空间文件替换所述原始系统表空间文件。

可选的，在执行所述用所述新的系统表空间文件替换所述原始系统表空间文件的步骤后，重新启动所述MySQL数据库。

可选的，所述采用在关闭过程中清除无效回滚数据的方式关闭MySQL数据库的步骤，包括：

将所述MySQL数据库的关闭选项设置为，MySQL数据库系统预定义的在关闭过程中包含清除无效回滚数据操作的特定值；

关闭所述MySQL数据库。

可选的，执行所述关闭MySQL数据库的步骤之前，执行下述操作：

减少缓冲池中的未同步到磁盘的已修改数据页的数量，使其小于预先设定的值。

可选的，所述减少缓冲池中的未同步到磁盘的已修改数据页的数量，使其小于预先设定的值，包括：

设置未同步到磁盘的已修改数据页在缓冲池中所占比例为0；

监测缓冲池中的未同步到磁盘的已修改数据页的数量，直至所述数量小于预先设定的值。

可选的，所述以待回收回滚空间的原始系统表空间文件为基础，生成一个不包含回滚空间的新的系统表空间文件，包括：

创建一个新的系统表空间文件；

按照系统表空间文件的格式，将所述原始系统表空间文件中包含的、且类型不是回滚页的数据页写入所述新的系统表空间文件中；

更新所述新的系统表空间文件中与回滚空间相关的统计信息的内容为，系统表空间文件默认的代表当前无回滚空间的值；

判断所述新的系统表空间文件的长度是否小于系统设定的系统表空间文件的初始长度；若是，调整所述新的系统表空间文件的长度，使其大于或者等于系统设定的系统表空间文件的初始长度。

可选的，所述按照系统表空间文件的格式，将所述原始系统表空间文件中包含的、且类型不是回滚页的数据页写入所述新的系统表空间文件中，包括：

以系统设定的数据页的长度为单位，依次读取所述原始系统表空间文件中的数据页；

判断当前所读数据页的类型是否为系统字典页或者二次写缓冲页；

若是，将当前数据页的内容写入所述新的系统表空间文件；并更新该数据页在新的系统表空间文件中的位置信息、以及该数据页与同类型的前一个数据页之间的相对位置关系信息。

重复执行上述步骤，直至将所述原始系统表空间文件中的系统字典页和二次写缓冲页都写入所述新的系统表空间文件为止。

可选的，所述调整所述新的系统表空间文件的长度，使其大于或者等于系统设定的系统表空间文件的初始长度，包括：

以系统设定的数据页的长度为单位，向所述新的系统表空间文件的尾部追加一个类型为空闲页的数据页；

判断所述新的系统表空间文件的长度是否小于系统设定的系统表空间文件的初始长度；若是，返回至以系统设定的数据页的长度为单位，向所述新的系统表空间文件的尾部追加一个类型为空闲页的数据页的步骤。

可选的，所述调整所述新的系统表空间文件的长度，使其大于或者等于系统设定的系统表空间文件的初始长度，包括：

计算所述系统设定的系统表空间文件的初始长度与所述新的系统表空间文件长度的差值；

获取所述差值与系统设定的数据页长度的比值，以大于或者等于该比值的最小整数作为需要追加的数据页的数目；

向所述新的系统表空间文件的尾部追加相应数目的类型为空闲页的数据页。

可选的，所述用所述新的系统表空间文件替换所述原始系统表空间文件，采用如下方式实现：

删除所述原始系统表空间文件，并使用所述原始系统表空间文件的文件名为所述新的系统表空间文件重新命名。

可选的，所述方法还包括：

停止MySQL主数据库和备用数据库之间的同步；

并且所述关闭数据库、生成不包含回滚空间的新系统表空间文件、以及替换原始系统表空间文件的操作，都是针对上述停止了同步操作的备用数据库进行的。

可选的，在停止MySQL主数据库和备用数据库之间的同步之后，执行下述操作：

执行所述主数据库和所述备用数据库之间的切换；

并且所述关闭数据库、以及生成不包含回滚空间的系统表空间文件并替换原始系统表空间文件的操作，都是针对执行所述切换操作后的备用数据库进行的。

本申请还提供一种用于MySQL的快速回收回滚空间的装置，包括：

数据库关闭单元，用于采用在关闭过程中清除无效回滚数据的方式关闭MySQL数据库；

文件生成单元，用于以待回收回滚空间的原始系统表空间文件为基础，生成一个不包含回滚空间的新的系统表空间文件；

文件替换单元，用于用所述新的系统表空间文件替换所述原始系统表空间文件。

可选的，所述装置包括：

数据库启动单元，用于用所述新的系统表空间文件替换所述原始系统表空间文件后，重新启动所述MySQL数据库。

可选的，所述数据库关闭单元包括：

关闭选项设置子单元，用于将所述MySQL数据库的关闭选项设置为，MySQL数据库系统预定义的在关闭过程中包含清除无效回滚数据操作的特定值；

关闭执行子单元，用于关闭所述MySQL数据库。

可选的，所述装置还包括：

未同步数据页减少单元，用于减少缓冲池中的未同步到磁盘的已修改数据页的数量，使其小于预先设定的值。

可选的，所述未同步数据页减少单元包括：

比例设置子单元，用于设置未同步到磁盘的已修改数据页在缓冲池中所占比例为0；

数量监测子单元，用于监测缓冲池中的未同步到磁盘的已修改数据页的数量，直至所述数量小于预先设定的值。

可选的，所述文件生成单元包括：

文件创建子单元，用于创建一个新的系统表空间文件；

数据页复制子单元，用于按照系统表空间文件的格式，将所述原始系统表空间文件中包含的、且类型不是回滚页的数据页写入所述新的系统表空间文件中；

统计信息更新子单元，用于更新所述新的系统表空间文件中与回滚空间相关的统计信息的内容为，系统表空间文件默认的代表当前无回滚空间的值；

长度调整子单元，用于判断所述新的系统表空间文件的长度是否小于系统设定的系统表空间文件的初始长度；若是，调整所述新的系统表空间文件的长度，使其大于或者等于系统设定的系统表空间文件的初始长度。

可选的，所述数据页复制子单元包括：

数据页读取子单元，用于以系统设定的数据页的长度为单位，依次读取所述原始系统表空间文件中的数据页；

类型判断子单元，用于判断当前所读数据页的类型是否为系统字典页或者二次写缓冲页；

数据页写入子单元，用于当所述类型判断子单元的输出为“是”时，将所述数据页读取子单元读取的数据页的内容写入所述新的系统表空间文件，并更新该数据页在新的系统表空间文件中的位置信息、以及该数据页与同类型的前一个数据页之间的相对位置关系信息。

控制子单元，用于调度上述三个子单元，直至将所述原始系统表空间文件中的系统字典页和二次写缓冲页都写入所述新的系统表空间文件为止。

可选的，所述长度调整子单元包括：

长度判断子单元，用于判断所述新的系统表空间文件的长度是否小于系统设定的系统表空间文件的初始长度；

空闲页追加子单元，用于当所述长度判断子单元的输出为“是”时，以系统设定的数据页的长度为单位，向所述新的系统表空间文件的尾部追加一个类型为空闲页的数据页，并触发所述长度判断子单元。

可选的，所述长度调整子单元包括：

长度差值计算子单元，用于计算所述系统设定的系统表空间文件的初始长度与所述新的系统表空间文件长度的差值；

空闲页数量计算子单元，用于获取所述差值与系统设定的数据页长度的比值，以大于或者等于该比值的最小整数作为需要追加的数据页的数目；

空闲页批量追加子单元，用于向所述新的系统表空间文件的尾部追加相应数目的类型为空闲页的数据页。

可选的，所述文件替换单元具体用于，删除所述原始系统表空间文件，并使用所述原始系统表空间文件的文件名为所述新的系统表空间文件重新命名。

可选的，所述装置还包括：

同步停止单元，用于停止MySQL主数据库和备用数据库之间的同步；并且所述数据库关闭单元、所述文件生成单元、以及所述文件替换单元部署在上述停止了同步操作的备用数据库上实施。

可选的，所述装置还包括：

主备切换单元，用于在停止MySQL主数据库和备用数据库之间的同步之后，执行所述主数据库和所述备用数据库之间的切换；并且所述数据库关闭单元、所述文件生成单元、以及所述文件替换单元部署在上述执行切换操作后的备用数据库上实施。

与现有技术相比，本申请具有以下优点:

本申请提供的用于MySQL的快速回收回滚空间的方法，没有采用将全部数据库数据导出并导入的方法，而是采用在关闭过程中清除无效回滚数据的方式关闭MySQL数据库，并在关闭数据库后遵循系统表空间文件的组织结构，采用顺序读写的方式，以待回收回滚空间的原始系统表空间文件为基础，生成一个不包含回滚空间的新的系统表空间文件，并采用新的系统表空间文件替换原始系统表空间文件，从而实现了快速回收回滚空间的功能，提高整个数据库系统的可用性。

本申请的用于MySQL的快速回收回滚空间的方法，提供了一种优选实施方式，在关闭MySQL数据库之前，通过降低未同步到磁盘的已修改数据页（即：脏页）在缓冲池中所占比例，尽量减少位于缓冲池中的脏页的数量，并在所述脏页的数量小于预先设定的值后再执行关闭MySQL数据库的操作，从而减少了MySQL在关闭过程中将脏页写入磁盘所需时间，加快了MySQL数据库的关闭速度，在实现本申请技术方案的同时，进一步缩短了MySQL数据库服务处于不可用状态的时间。

附图说明

图1为本申请的一种用于MySQL的快速回收回滚空间的方法的实施例流程图；

图2为本申请的生成不包含回滚空间的新的系统表空间文件的处理过程的实施例流程图；

图3为本申请的一种用于MySQL的快速回收回滚空间的装置的实施例示意图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

在本申请中，分别提供了一种用于MySQL的快速回收回滚空间的方法、以及一种用于MySQL的快速回收回滚空间的装置。在下面的实施例中逐一进行详细说明。

请参考图1，其为本申请的一种用于MySQL的快速回收回滚空间的方法的实施例流程图。所述方法包括如下步骤：

步骤101：采用在关闭过程中清除无效回滚数据的方式关闭MySQL数据库。

为了便于理解，在描述本申请技术方案的具体步骤前，先对MySQL的系统表空间作简要说明。MySQL的InnoDB存储引擎将数据放在一个逻辑的表空间中，这个表空间就像黑盒一样由InnoDB自身进行管理。InnoDB有两种管理表空间的方法：共享表空间、独立表空间。使用共享表空间存储方式时，Innodb的所有数据保存在一个单独的表空间里面，而这个表空间可以由很多个文件组成，一个表可以跨多个文件存在，其表空间的最大限制为64TB。

采用独立表空间存储方式（通过启用innodb_file_per_table参数选项实现）时，每个表的数据以一个单独的.idb文件来存放，与共享表空间无法确定每个表在表空间中的位置不同，独立表空间可以做到每个表有自己的表空间，一方面表数据不必再和共享表空间中的其他数据在一个文件中争用空间，另一方面也可以使每个表的数据分布在磁盘上更为连续。

不管采取哪种管理表空间的方式，InnoDB都需要共享表空间（通常是ibdata1文件），为了便于表述，本申请文件中将两种方式下都需要的共享表空间文件ibdata1，称为系统表空间文件。从包含的数据类型来看，如果采用主流应用的推荐配置，系统表空间文件中主要包含四类数据：系统字典、插入缓冲（insertbuffer）、二次写缓冲（double write buffer）、回滚日志（undo log）。其中，系统字典主要包括了表的定义、表空间文件序号(如果启用innodb_file_per_table)，以及一些日志信息等，插入缓冲和二次写缓冲将在下面的文字中陆续介绍，而回滚日志则是用来记录回滚数据的。本申请所述的回滚空间，就是指系统表空间文件中用于存放回滚日志的部分。

从系统表空间的组成单元来看，系统表空间包括：数据页（page）、区域（extent）、段（segment）、回滚段（rollback segment）。系统表空间由默认16k大小的数据页组成，数据页是组成系统表空间的最小单位；64个连续的数据页组成一个区域；多个区域和数据页构成一个段；而回滚段则是一种特殊的段，一个回滚段通常包含了多个段（segment）。InnoDB根据数据库操作的不同需求，在系统表空间内动态分配上述数据单元，并采用链表的方式将空闲的、半满的、全满的数据单元分别组织在一起，从而可以采用不同的粒度实现对系统表空间文件的分配、回收以及重复利用。

前面对系统表空间、回滚空间的概念作了简要介绍，下面重点说明本申请的技术方案是如何实现的。为了以待回收回滚空间的系统表空间文件为基础生成新的表空间文件，必须先执行本步骤停止数据库服务，即关闭数据库。

本申请提供的用于MySQL的快速回收回滚空间的方法，其基本思路是这样的：关闭MySQL数据库，并且确保下次重启时不再需要用到任何undo log数据，这样在关闭数据库后执行的删除系统表空间文件中的回滚空间操作，才不会导致MySQL在重新启动的过程中因为读取不到所需的undo log而无法正常启动。

如果采用系统默认的方式正常关闭MySQL（关闭选项innodb_fast_shutdown=1），由于InnoDB采用write-ahead-logging模式管理undo log数据，意味着磁盘上的数据与内存数据并非实时相同，因此MySQL在重新启动时，需要读取ibdata1中的undo log数据，并与重做日志（redo log）配合，恢复成最新版本的undo log数据。也就是说，如果采用默认方式关闭MySQL数据库，那么重新启动后，innodb还需要读取undo log数据。

基于上述原因，本申请提供的快速回收回滚空间的方法，没有采用默认方式关闭MySQL服务器，而是采用关闭选项innodb_fast_shutdown=0的方式关闭MySQL数据库。

innodb_fast_shutdown选项用于告知innodb在关闭数据库的时候应该执行哪些操作。针对本申请技术方案所采用的innodb_fast_shutdown=0的设置，在关闭数据库时innodb需要执行以下三个方面的操作：清除无效的undo log（Fullpurge）、合并插入缓冲（merge insert buffer）、刷新脏页到磁盘（flush dirty page）。

其中，Full Purge操作主要是清除无用的undo log数据。innodb为了提供对MVCC（多版本并发控制）的支持，一方面，对于主键索引，每个行都有一个事务ID和一个undo ID，这个undo ID指向了这行的先前版本的位置，对于非主键索引，也就是常说的secondary index，是通过先找主键索引再找到undo数据；另一方面，对于删除和更新操作，innodb也采取了相应的特殊处理方式，对于删除操作并不是立刻删除当前行，而只是将要删除的那一行标记为删除，而对于更新操作，则是先标记为删除，然后再插入一个新的行，那么如果有事务提出对该行的一致性读需求，就可以根据与该行相关的undo ID信息，找到事务所需的先前版本。

在正常关闭MySQL数据库的时候，所有的数据库事务都已经执行完成，一方面没有因为未执行完而需要回滚的操作，另一方面，也不存在还需要根据undolog数据获取本事务开始时数据版本的事务，因此可以强制InnoDB执行Purge操作，一方面对之前被标记为已删除的行执行真正的删除操作，释放物理页空间，另一方面，清除不再使用的、无效的undo log数据。因为在数据库的关闭阶段执行上述清除操作，因而在数据库重新启动的过程中就不会再执行读取undo log数据的操作，从而为采用本申请提供的方法回收回滚空间做好了必要的准备。

设置innodb_fast_shutdown=0后，系统在关闭MySQL服务时，还会执行合并插入缓冲的操作。插入缓冲是InnoDB存储引擎的关键特性之一，插入缓冲虽然也可以缓存在InnoDB的缓冲池中，但却是系统表空间的一个组成部分，也即：是物理页的一个组成部分。每个InnoDB表只有一个聚集索引，同时还可能存在多个非聚集的且不是唯一索引的辅助索引，InnoDB在设计时采用了按照聚集索引的顺序、将聚集索引和数据一起存放的方式，辅助索引则仅仅包含聚集索引的信息，而不包含数据，因此执行依据辅助索引的查询时，需要先找到聚集索引，然后利用聚集索引访问所需的数据，InnoDB的索引以B-tree的形式存到各个叶子节点上。

通过上面的介绍可以看出，插入聚集索引，是一个顺序IO的过程，而对于辅助索引来说，叶子节点的插入不再是顺序的了，而是一个离散的随机IO过程，为了提高IO操作的执行效率，InnoDB先判断插入的非聚集索引页是否在缓冲池中，如果在，则直接插入，否则先放入一个插入缓冲中，然后再以一定的频率执行插入缓冲和非聚集索引叶子节点的合并操作，这时可以将针对同一个索引页的多个插入操作合并为一个操作执行，也就是说将多个随机IO merge成为一个，从而大大减少随机IO。

在本步骤中，通过设置innodb_fast_shutdown=0，在数据库的关闭过程中，既清除了无效的undo信息，同时也强制innodb执行了上述合并插入缓冲的操作，那么系统表空间文件中的插入缓存中的信息都被合并到真正的索引文件中，这意味着关闭数据库之后，下次重新启动时也不再需要插入缓冲中的内容，因此在后续生成新的系统表空间文件时，可以不复制原始系统表空间文件中的插入缓冲页（insert buffer page）。

采用设置innodb_fast_shutdown=0的方式关闭MySQL数据库，InnoDB不仅执行上述清除无效undo信息、合并插入缓冲的操作，还要执行刷新脏页到磁盘的操作，下面对所述刷新操作、以及本申请针对该刷新操作所提出的一种优选实施方式进行说明。

为了提高系统的处理效率，InnoDB采用通过缓冲池（buffer pool）来延缓写操作的处理方式，InnoDB针对写操作的执行过程是这样的：先将写操作的改动写到缓冲池中，再将该改动写入日志文件log file中，然后就返回结果到客户端，由于不需要执行写磁盘的操作，仅仅是执行了写缓冲池的内存操作，这样就提高了InnoDB的响应速度，也就出现了位于缓冲池中的未同步到磁盘的已修改的数据页，也就是通常所说的“脏页（dirty page）”。针对这些脏页，InnoDB使用一个后台的线程执行刷新（flush）操作，将脏页刷新到磁盘上，具体说：InnoDB会监测脏页占据缓冲池中的比例，当该比例达到系统设置的参数innodb_max_dirty_pages_pct所指定的值时，InnoDB就会使用刷新线程将脏页数据写到磁盘。

无论是采用默认方式关闭数据库还是采用设置innodb_fast_shutdown=0的方式关闭数据库，InnoDB都会执行上述刷新操作，由于可能存在大量的脏页，因此执行关闭操作的时间可能很长，为了使整个关闭、重启的过程尽可能快，减少数据库服务处于不可用状态的时间，本申请提供了一种优选实施方式，通过在关闭数据库之前预先减少脏页的数量，达到快速关闭数据库的效果。具体采用如下方式实现：

首先，设置innodb_max_dirty_pages_pct=0。正如上面介绍的，当脏页占据缓冲池中所有数据页的比例达到该参数设定的值时，InnoDB会执行将脏页数据写到磁盘上的刷新操作。如果将该参数设置为0，InnoDB自然会频繁地执行刷新操作，从而减少位于缓冲池中的脏页的数量。

然后，持续监测Innodb_buffer_pool_pages_dirty变量的值，该变量记录的是位于缓冲池中的脏页的数量，由于已经设置了innodb_max_dirty_pages_pct=0，可以看到该变量的值逐渐变小，当该变量的值小于预先设定的值，例如：100时，就可以停止监测，并采用设置innodb_fast_shutdown=0的方式关闭数据库，此时关闭数据库的操作很快就可以执行完毕，通常可能只需要几秒钟的时间。

在本实施例的上述具体例子中，为了获得使MySQL数据库快速关闭的更为优化的实施效果，采用了预先减少脏页数量的步骤，在采用本申请方法的其他实施方式中，可以省略该步骤，同样可以实现对回滚空间的快速回收；在本实施例的一个具体例子中，为了减少脏页，设置innodb_max_dirty_pages_pct参数为0，并且监测脏页的数量直至小于预先设定的脏页数量100，在其他实施方式中，可以采用不同于上述具体例子的设置，只要能够将脏页数量减少到预先定义的较少数量就可以了；至于监测脏页数量，可以采用查看Innodb_buffer_pool_pages_dirty变量的方式，也可以在命令行输入下述命令：/usr/local/mysql/bin/mysqladmin-uroot-p ext-i10|grep dirty，从而界面上将会实时显示脏页的数量；上述这些不同的设置或者操作方式，都只是实施方式的变更，都不偏离本申请的核心，因此都在本申请的保护范围之内。

上面介绍了将脏页刷新到磁盘的过程，在这个过程中还会涉及二次写缓冲（double write buffer），由于double write buffer也是系统表空间文件的一部分，在后续生成新的系统表空间文件的过程中，也涉及到关于double write buffer数据页的处理，因此在这里作一个简要的说明。

InnoDB为了提高操作的性能，采用先将对数据页的更新写入缓冲池，再刷新到磁盘的方式，那么在发生意外的情况下，例如：数据库服务器宕机，则可能发生从缓冲池写入磁盘的刷新操作被中断、而该刷新操作所涉及的某个数据页只写了一部分的情况，即：发生了部分写失败的现象。为了解决这一问题，InnoDB采用了二次写的机制，实现二次写机制需要两个数据区域：一部分是内存中的double write buffer，大小为2MB；另一部分是物理磁盘上的系统表空间文件中的中连续的128个double write buffer数据页，即两个区（extent），大小同样为2MB。

当缓冲池的脏页刷新时，并不直接写磁盘，而是会通过memcpy函数将脏页先拷贝到内存中的double write buffer，之后通过double write buffer再分两次，每次写入1MB到共享表空间的物理磁盘上，然后马上调用fsync函数，同步磁盘。在这个过程中，因为系统表空间文件中的double write buffer页是连续的，因此相关的写入过程是顺序执行的，开销并不是很大。在完成double write buffer页的写入后，再将double write buffer中的页写入各个表空间文件中，此时的写入则是离散的。如果发生部分写失败的现象，则可以通过double write buffer页中的信息还原发生写失败的数据页，并根据需要执行相关的redo操作。

由此可见，InnoDB在将数据从内存写入磁盘期间，通过在系统表空间文件的double write buffer中临时保存完整页面的方式，提供了数据可靠性保障。在本申请提供的技术方案中，由于采用的是正常关闭数据库的方式，也就是说不会发生部分写失败的现象，因此在系统表空间文件的double write buffer中存放的临时数据在重启后都不需要保留。但是由于double write buffer是系统表空间文件的一个固定大小的组成部分，因此在后续生成新的系统表空间文件的步骤中只需要直接复制即可。

步骤102：以待回收回滚空间的原始系统表空间文件为基础，生成一个不包含回滚空间的新的系统表空间文件。

本申请提供的用于MySQL的快速回收回滚空间的方法，其关键就在于，没有采用现有的将全部数据库数据导出、重建数据库实例、再导入的方法，而是以顺序读写的方式，以待回收回滚空间的原始系统表空间文件为基础，生成一个不包含回滚空间的新的系统表空间文件，并替换原始系统表空间文件，从而实现了对原始系统表空间文件所占用的磁盘空间的快速回收。在本步骤中，主要涉及对系统表空间文件的读写操作，为了便于理解，首先对系统表空间文件的组织结构作简要说明。

系统表空间文件的组织结构比较复杂，下表简要描述了系统表空间文件的基本组成。从该表中可以看出，系统表空间文件是以页为基本单位顺序组织的一个文件，其中，page5是一个类型为FIL_PAGE_TYPE_SYS系统页，记录与事务系统操作相关的信息，其中包括undo log的统计信息，在本申请的技术方案中，除了在复制过程中要跳过回滚页，还要相应更新该页中的undo log统计信息才能够正确完成对回滚空间的回收。

表一，系统表空间基本结构示意

page0	FSP_HDR（系统表空间头部页）
		page1	IBUF_BITMAP（插入缓冲位图页）
page2	INODE（包含与segment相关的链表管理信息）
		page3	IBUF_HDR（插入缓冲头部）
page4	INDEX（用于插入缓冲的索引结构信息）
		page5	TRX_SYS（与事务系统操作相关的信息）
page6	SYS（第一个回滚段相关信息）
		page7	SYS（数据字典头）
page8-page63	其他数据页
		page64-page127	二次写缓冲数据块1（包含64个数据页）
page128-page191	二次写缓冲数据块2（包含64个数据页）
		page192-......	其他数据页

本步骤是快速回收回滚空间的关键步骤，主要包括创建新文件、复制文件、更新统计信息、调整文件长度这样4个子步骤，请参见附图2，其为本申请的生成不包含回滚空间的新的系统表空间文件的处理过程的实施例流程图，下面结合附图2对这4个子步骤逐一加以说明。

步骤102-1：创建一个新的系统表空间文件。

创建一个新的系统表空间文件，该文件是一个空文件，其文件长度为0。可以使用操作系统提供的接口或者工具新建一个文件，例如MySQL安装在windows操作系统平台上，那么就可以使用windows资源管理器的新建功能，或者在命令行模式下采用copy con filename的方式新建一个文件。创建新文件有很多种方式，具体采用何种方式，不是本申请的核心，本申请不作限定。

步骤102-2：按照系统表空间文件的格式，将所述原始系统表空间文件中包含的、且类型不是回滚页的数据页写入所述新的系统表空间文件中。

首先，以系统设定的数据页的长度为单位，读取所述原始系统表空间文件中的数据页。InnoDB引擎设定数据页长度的缺省值为16KB，其定义是在源代码中，因此在系统安装完毕之后是无法修改的。在系统安装之前，可以采用如下方式修改关于UNIV_PAGE_SIZE的定义：

例如：在storage/innobase/incluce/univ.i中，采用如下定义：

#define UNIV_PAGE_SIZE(1*8192)

#define UNIV_PAGE_SIZE_SHIFT13

再编译对应的源代码，并进行安装，这样就将InnoDB数据页的长度修改为8KB了。在本实施例的一个具体例子中，采用了InnoDB的默认设置，因此以16KB为单位，执行从原始系统表空间文件ibdata1中读取数据页的操作。

然后，判断当前所读数据页的类型是否为系统字典页或者二次写缓冲页。

在步骤101中已经介绍过，如果采用主流应用的推荐配置，系统表空间文件中主要包含四类数据：系统字典、插入缓冲（insert buffer）、二次写缓冲（doublewrite buffer）、回滚日志（undo log），本申请的技术方案是为了快速回收回滚空间，因此从原理上说，只要跳过回滚页（不将回滚页复制到新的系统表空间文件中）就实现了对回滚空间的回收。但是由于在步骤101中关闭数据库的同时执行了合并插入缓冲的操作，插入缓冲中的数据已经处理完毕，在下次启动时不会再使用这部分数据，因此在生成新的系统表空间文件的过程中，也可以不复制插入缓冲页，因此本步骤的判断条件中没有包括插入缓冲页。

对于二次写缓冲来说，在正常关闭数据库的情况下，因为内存数据已经全部成功地同步到磁盘上，因此在重启的过程中，也不会使用二次写缓冲中的数据，但是通过表一可以看到，二次写缓冲数据块在系统表空间文件中是一个固定的数据区域，因此不能采用与插入缓冲页或者回滚页相同的跳过方式，而是需要执行复制操作，因此本步骤的判断条件中包含了二次写缓冲页。

本步骤判断中所述的系统字典页，是一个相对宽泛的概念，其中包括了与系统表空间的整个系统相关的数据页，例如：系统页、索引页、插入缓冲位图页、数据字典页、事务系统页等都是本申请所述的系统字典页。这些类型的数据页和二次写缓冲数据页都是本申请技术方案需要复制的数据页。

至于数据页类型，固定存放在每个数据页的头部的第25-26字节（从0开始计数就是byte24-byte25），因此直接读取当前数据页的第25-26字节就可以获取当前数据页类型。关于数据页头部的基本格式可以参见表二。

最后，将类型为系统字典页或者二次写缓冲页的数据页写入所述新的系统表空间文件；并更新该数据页在新的系统表空间文件中的位置信息、以及该数据页与同类型的前一个数据页之间的相对位置关系信息。

将类型符合要求的数据页复制到新的系统表空间文件中，只是实现了数据页的简单搬移，但是作为系统表空间文件来说，仅有一系列数据页面的堆积是无法正常运作的，还必须将类型相同的页面通过类似链表的方式有序地组织起来，这样InnoDB才能对系统表空间文件实施正确有效的管理。每个数据页都是由数据页头（page header）、数据页体（page body）、数据页尾（page trailer）三部分内容构成，其中数据页的头部包括38个字节的内容，其格式如表二所示：

表二：数据页头部的格式

byte0-byte3	Checksum（校验和）
		byte4-byte7	FIL_PAGE_OFFSET（数据页序号）
byte8-byte11	FIL_PAGE_PREV（上一个数据页的序号）
		byte12-byte15	FIL_PAGE_NEXT（下一个数据页的序号）
byte16-byte23	LSN
		byte24-byte25	FIL_PAGE_TYPE（数据页类型）
byte26-byte33	FLUSH LSN
		byte34-byte37	Space ID

每个数据页都有一个长度为4字节的数据页序号FIL_PAGE_OFFSET，通常也称为偏移量，反应了该数据页从系统表空间头部开始的偏移量位置，以缺省16KB的页面大小为例，page0位于系统表空间的偏移量为0的位置，page1则位于系统表空间的偏移量为16384字节的位置；数据页类型FIL_PAGE_TYPE用于存放当前数据页的类型；上一个数据页FIL_PAGE_PREV则用于存放与当前数据页类型相同的前一个数据页的序号，下一个数据页FIL_PAGE_NEXT则用于存放与当前数据页类型相同的下一个数据页的序号。在功能上，通过对FIL_PAGE_PREV和FIL_PAGE_NEXT字段的正确设置，实现了同类型的数据页的双向链表，便于InnoDB进行快速地查找和定位。

在本步骤中，由于复制过程中会跳过一些数据页（例如：插入缓冲页、回滚页），因此必须对FIL_PAGE_OFFSET、FIL_PAGE_PREV、FIL_PAGE_NEXT这三个字段的值进行修改，反映当前数据页的正确位置，以及与同类型相邻数据页的正确位置关系。具体说，在复制完每个数据页后，要执行下面三个操作：

1）在上一个数据页序号的基础上计算当前数据页序号，并写入当前数据页的FIL_PAGE_OFFSET字段中；

2）在当前数据页的FIL_PAGE_PREV字段中写入与当前数据页的类型相同的前一个数据页的页序号；

3）在与当前数据页的类型相同的前一个数据页的FIL_PAGE_NEXT字段中写入当前数据页的页序号。

执行完上述三个修改操作，才算完成了当前数据页的复制，然后继续读取下一个数据页，并执行上述判断数据页类型、数据页写入、以及修改数据页信息的步骤，重复执行该过程，直到将原始系统表空间文件的全部系统字典页和二次写缓冲页都复制到新的系统表空间文件中。

步骤102-3：更新所述新的系统表空间文件中与回滚空间相关的统计信息的内容为，系统表空间文件默认的代表当前无回滚空间的值。

执行完步骤102-2后，由于原始系统表空间文件中的所有回滚页都被跳过了（没有复制），因此新的系统表空间文件中就已经不包含回滚空间了，为了与当前状态相一致，还需要修改新的系统表空间文件中与回滚空间相关的统计信息。

请参见表一，系统表空间中的page5用于记录与事务系统操作相关的信息，该数据页是一个类型为FIL_PAGE_TYPE_SYS的系统页，其中保存了回滚日志的统计信息。在系统表空间中，整个回滚空间被分成128个回滚段（rollbacksegment），每个回滚段又是由多个用于存放回滚日志的回滚区域和回滚页组成，其中每个回滚段的起始页序号都保存在上述系统页中，因为新的系统表空间文件不包含回滚页，自然也没有回滚段，因此应该将上述系统页中用于存放128个回滚段的起始页序号的字段，都设置为代表回滚段不存在的初始值0xFFFFFFFF。

在本实施例的一个具体例子中，采用了上述修改统计信息的方式，即：在完成数据页的复制过程后，定位到类型为FIL_PAGE_TYPE_SYS的系统页并修改统计信息。在其他实施方式中，也可以将本步骤与步骤102-2合并执行，也就说在步骤102-2执行复制数据页的过程中，添加一个判断语句，判断当前数据页是否是类型为FIL_PAGE_TYPE_SYS的系统页，若是，执行上述修改回滚空间相关统计信息的操作，采用这种方式在复制每个数据页的时候都要多执行一次判断，但是同样可以实现本申请的技术方案。

步骤102-4：判断所述新的系统表空间文件的长度是否小于系统设定的系统表空间文件的初始长度；若是，调整所述新的系统表空间文件的长度，使其大于或者等于系统设定的系统表空间文件的初始长度。

在MySQL数据库的配置文件my.cnf中指定了系统表空间文件的初始长度，例如：Innodb_data_file_path=ibdata1:200M，该语句指定了系统表空间文件的初始长度为200M，该值仅仅是示意性的，在实际应用中可以根据需要设置不同的初始长度值。如果通过上述步骤生成的新的系统表空间文件的长度不满足该设置的要求，可能导致MySQL数据库无法正常启动，或者启动后InnoDB无法实现对系统表空间的正确管理，因此要求新的系统表空间文件的长度不能小于上述初始设置，因此在本步骤中需要进行相关的判断，并在不满足要求的情况下采用如下两种方式调整新的系统表空间文件的长度：

1）以系统设定的数据页的长度为单位，向所述新的系统表空间文件的尾部追加一个类型为空闲页的数据页；然后判断当前新的系统表空间文件的长度是否满足初始设置的要求，如果仍不满足，再执行追加、判断....，循环执行上述过程，直到新的系统表空间文件的长度大于或者等于系统设定的初始长度；

2）计算系统设定的系统表空间文件的初始长度与新的系统表空间文件长度的差值，并计算该差值与系统设定的数据页长度的比值，以大于或者等于该比值的最小整数作为需要追加的数据页的数目；然后一次性地向新的系统表空间文件的尾部追加相应数目的类型为空闲页的数据页。

步骤103：用所述新的系统表空间文件替换所述原始系统表空间文件。

执行完上述步骤102，已经生成了一个新的、不包含回滚空间的系统表空间文件，为了实现本申请的快速回收回滚空间的目的，还需要用新的系统表空间文件替换掉原始系统表空间文件，从而实现对原始系统表空间文件所占用的磁盘空间的释放。具体替换过程可以采用多种方式实现，例如：删除原始系统表空间文件，并使用原始系统表空间文件的文件名为新的系统表空间文件重新命名；也可以采用复制操作，用新的系统表空间文件覆盖原始系统表空间文件。

在本实施例的一个具体例子中，待回收回滚空间的系统表空间文件为ibdata1，生成的新的系统表空间文件为ibdata_new，在本步骤中删除了ibdata1文件，并将ibdata_new文件重新命名为ibdata1，从而将原始ibdata1文件占据的大量磁盘空间归还给操作系统，同时重命名后的新ibdata1文件也是一个完整的系统表空间文件，因此保证了MySQL数据库的正常启动和运行。

至此，本申请提供的快速回收回滚空间的方法就执行完毕了，此时可以重新启动MySQL数据库，MySQL数据库将基于新的系统表空间文件继续提供数据库服务器。由于在步骤101中采用了预先将缓冲池中的脏页数量减少到一定数值然后再关闭数据库的方式，因此关闭过程所耗时间很短，通常只需要数秒钟的时间，而步骤102中生成新的系统表空间文件的过程，采用了以数据页为基本单位、从原始系统表空间文件中顺序读取、并顺序写入新的系统表空间文件的方式，该读写操作的执行过程也是相对比较快的，对于一个大小为100G左右的原始系统表空间文件来说，该过程耗时大约为几十秒，而重启过程也很快，因此通常能够在1分钟之内完成上述整个过程，实现对回滚空间的快速回收。

在本实施例的一个具体例子中，系统表空间文件只有一个ibdata1，在实际应用中，系统表空间文件的名称以及数目都是可以修改的，例如：可以在my.cnf中按照如下所述的方式设置Innodb_data_file_path参数：

Innodb_data_file_path=ibdata1:500M；ibdata2:200M:autoextend

上述设置方式表明，使用ibdata1和ibdata2两个文件来共同组成系统表空间。其中ibdata1文件的初始大小为500M，ibdata2文件的初始大小为200M。若采用上述方法指定位于不同磁盘上的两个或者多个文件，则可以通过负载均衡提高数据库的整体性能。在上述配置方式下，可以采用本申请提供的快速回收回滚空间的方法，依次处理共同组成系统表空间的一组系统表空间文件（例如：ibdata1和ibdata2等），从而实现对本系统内全部系统表空间文件的回滚空间的回收。

在具体的应用中，为了保证服务的可用性，MySQL数据库系统通常采用主备服务器的架构，而主数据库和备用数据库都可能出现回滚空间膨胀的现象。针对这一问题，可以在主数据库和备用数据库上依次使用本申请提供的快速回收回滚空间的方法，具体过程如下：

首先回收备用数据库的回滚空间：

1）停止MySQL主数据库和备用数据库之间的同步；

2）在备用数据库上实施本申请提供的方法，回收备用数据库的回滚空间；

3）重新启动备用数据库，主备恢复同步。

然后回收主数据库的回滚空间：

1）停止MySQL主数据库和备用数据库之间的同步；

2）执行主数据库和备用数据库之间的切换；

3）在切换后的备用数据库（即：原来的主数据库）上实施本申请提供的方法，回收切换后的备用数据库的回滚空间；

4）重新启动备用数据库，主备恢复同步。

通过上述两个阶段，完成了对主数据库回滚空间和备用数据库回滚空间的回收。由于本申请提供的用于MySQL的快速回收回滚空间的方法，采用在关闭过程中清除无效回滚数据的方式关闭MySQL数据库，并在关闭数据库后采用顺序读写的方式，以待回收回滚空间的原始系统表空间文件为基础，生成一个不包含回滚空间的新的系统表空间文件，并采用新的系统表空间文件替换原始系统表空间文件，从而实现了快速回收回滚空间的功能，大幅减少了MySQL数据库服务处于不可用状态的时间；在采用主备服务器架构的应用场景下，显著缩短了作为主数据库工作的服务器缺少实时备份实例的时间，从而提高整个数据库系统的可用性。

在上述的实施例中，提供了一种用于MySQL的快速回收回滚空间的方法，与之相对应的，本申请还提供一种用于MySQL的快速回收回滚空间的装置。

请参看图3，其为本申请提供的一种用于MySQL的快速回收回滚空间的装置的实施例示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关的部分请参见方法实施例的对应说明即可。下述描述的装置实施例仅仅是示意性的。

本实施例的一种用于MySQL的快速回收回滚空间的装置，包括：数据库关闭单元201，用于采用在关闭过程中清除无效回滚数据的方式关闭MySQL数据库；文件生成单元202，用于以待回收回滚空间的原始系统表空间文件为基础，生成一个不包含回滚空间的新的系统表空间文件；文件替换单元203，用于用所述新的系统表空间文件替换所述原始系统表空间文件。

可选的，所述装置包括：

数据库启动单元，用于用所述新的系统表空间文件替换所述原始系统表空间文件后，重新启动所述MySQL数据库。

可选的，所述数据库关闭单元包括：

关闭选项设置子单元，用于将所述MySQL数据库的关闭选项设置为，MySQL数据库系统预定义的在关闭过程中包含清除无效回滚数据操作的特定值；

关闭执行子单元，用于关闭所述MySQL数据库。

可选的，所述装置还包括：

未同步数据页减少单元，用于减少缓冲池中的未同步到磁盘的已修改数据页的数量，使其小于预先设定的值。

可选的，所述未同步数据页减少单元包括：

比例设置子单元，用于设置未同步到磁盘的已修改数据页在缓冲池中所占比例为0；

数量监测子单元，用于监测缓冲池中的未同步到磁盘的已修改数据页的数量，直至所述数量小于预先设定的值。

可选的，所述文件生成单元包括：

文件创建子单元，用于创建一个新的系统表空间文件；

数据页复制子单元，用于按照系统表空间文件的格式，将所述原始系统表空间文件中包含的、且类型不是回滚页的数据页写入所述新的系统表空间文件中；

统计信息更新子单元，用于更新所述新的系统表空间文件中与回滚空间相关的统计信息的内容为，系统表空间文件默认的代表当前无回滚空间的值；

长度调整子单元，用于判断所述新的系统表空间文件的长度是否小于系统设定的系统表空间文件的初始长度；若是，调整所述新的系统表空间文件的长度，使其大于或者等于系统设定的系统表空间文件的初始长度。

可选的，所述数据页复制子单元包括：

数据页读取子单元，用于以系统设定的数据页的长度为单位，依次读取所述原始系统表空间文件中的数据页；

类型判断子单元，用于判断当前所读数据页的类型是否为系统字典页或者二次写缓冲页；

数据页写入子单元，用于当所述类型判断子单元的输出为“是”时，将所述数据页读取子单元读取的数据页的内容写入所述新的系统表空间文件，并更新该数据页在新的系统表空间文件中的位置信息、以及该数据页与同类型的前一个数据页之间的相对位置关系信息。

控制子单元，用于调度上述三个子单元，直至将所述原始系统表空间文件中的系统字典页和二次写缓冲页都写入所述新的系统表空间文件为止。

可选的，所述长度调整子单元包括：

长度判断子单元，用于判断所述新的系统表空间文件的长度是否小于系统设定的系统表空间文件的初始长度；

空闲页追加子单元，用于当所述长度判断子单元的输出为“是”时，以系统设定的数据页的长度为单位，向所述新的系统表空间文件的尾部追加一个类型为空闲页的数据页，并触发所述长度判断子单元。

可选的，所述长度调整子单元包括：

长度差值计算子单元，用于计算所述系统设定的系统表空间文件的初始长度与所述新的系统表空间文件长度的差值；

空闲页数量计算子单元，用于获取所述差值与系统设定的数据页长度的比值，以大于或者等于该比值的最小整数作为需要追加的数据页的数目；

空闲页批量追加子单元，用于向所述新的系统表空间文件的尾部追加相应数目的类型为空闲页的数据页。

可选的，所述文件替换单元具体用于，删除所述原始系统表空间文件，并使用所述原始系统表空间文件的文件名为所述新的系统表空间文件重新命名。

可选的，所述装置还包括：

同步停止单元，用于停止MySQL主数据库和备用数据库之间的同步；并且所述数据库关闭单元、所述文件生成单元、以及所述文件替换单元部署在上述停止了同步操作的备用数据库上实施。

可选的，所述装置还包括：

主备切换单元，用于在停止MySQL主数据库和备用数据库之间的同步之后，执行所述主数据库和所述备用数据库之间的切换；并且所述数据库关闭单元、所述文件生成单元、以及所述文件替换单元部署在上述执行切换操作后的备用数据库上实施。

本申请虽然以较佳实施例公开如上，但其并不是用来限定本申请，任何本领域技术人员在不脱离本申请的精神和范围内，都可以做出可能的变动和修改，因此本申请的保护范围应当以本申请权利要求所界定的范围为准。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

2、本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

Claims (24)

1.一种用于MySQL的快速回收回滚空间的方法，其特征在于，包括：

采用在关闭过程中清除无效回滚数据的方式关闭MySQL数据库；

以待回收回滚空间的原始系统表空间文件为基础，生成一个不包含回滚空间的新的系统表空间文件；

用所述新的系统表空间文件替换所述原始系统表空间文件。

2.根据权利要求1所述的用于MySQL的快速回收回滚空间的方法，其特征在于，在执行所述用所述新的系统表空间文件替换所述原始系统表空间文件的步骤后，重新启动所述MySQL数据库。

3.根据权利要求1所述的用于MySQL的快速回收回滚空间的方法，其特征在于，所述采用在关闭过程中清除无效回滚数据的方式关闭MySQL数据库的步骤，包括：

将所述MySQL数据库的关闭选项设置为，MySQL数据库系统预定义的在关闭过程中包含清除无效回滚数据操作的特定值；

关闭所述MySQL数据库。

4.根据权利要求1所述的用于MySQL的快速回收回滚空间的方法，其特征在于，执行所述关闭MySQL数据库的步骤之前，执行下述操作：

减少缓冲池中的未同步到磁盘的已修改数据页的数量，使其小于预先设定的值。

5.根据权利要求4所述的用于MySQL的快速回收回滚空间的方法，其特征在于，所述减少缓冲池中的未同步到磁盘的已修改数据页的数量，使其小于预先设定的值，包括：

设置未同步到磁盘的已修改数据页在缓冲池中所占比例为0；

监测缓冲池中的未同步到磁盘的已修改数据页的数量，直至所述数量小于预先设定的值。

6.根据权利要求1所述的用于MySQL的快速回收回滚空间的方法，其特征在于，所述以待回收回滚空间的原始系统表空间文件为基础，生成一个不包含回滚空间的新的系统表空间文件，包括：

创建一个新的系统表空间文件；

按照系统表空间文件的格式，将所述原始系统表空间文件中包含的、且类型不是回滚页的数据页写入所述新的系统表空间文件中；

更新所述新的系统表空间文件中与回滚空间相关的统计信息的内容为，系统表空间文件默认的代表当前无回滚空间的值；

判断所述新的系统表空间文件的长度是否小于系统设定的系统表空间文件的初始长度；若是，调整所述新的系统表空间文件的长度，使其大于或者等于系统设定的系统表空间文件的初始长度。

7.根据权利要求6所述的用于MySQL的快速回收回滚空间的方法，其特征在于，所述按照系统表空间文件的格式，将所述原始系统表空间文件中包含的、且类型不是回滚页的数据页写入所述新的系统表空间文件中，包括：

以系统设定的数据页的长度为单位，依次读取所述原始系统表空间文件中的数据页；

判断当前所读数据页的类型是否为系统字典页或者二次写缓冲页；

若是，将当前数据页的内容写入所述新的系统表空间文件；并更新该数据页在新的系统表空间文件中的位置信息、以及该数据页与同类型的前一个数据页之间的相对位置关系信息。

重复执行上述步骤，直至将所述原始系统表空间文件中的系统字典页和二次写缓冲页都写入所述新的系统表空间文件为止。

8.根据权利要求6所述的用于MySQL的快速回收回滚空间的方法，其特征在于，所述调整所述新的系统表空间文件的长度，使其大于或者等于系统设定的系统表空间文件的初始长度，包括：

以系统设定的数据页的长度为单位，向所述新的系统表空间文件的尾部追加一个类型为空闲页的数据页；

判断所述新的系统表空间文件的长度是否小于系统设定的系统表空间文件的初始长度；若是，返回至以系统设定的数据页的长度为单位，向所述新的系统表空间文件的尾部追加一个类型为空闲页的数据页的步骤。

9.根据权利要求6所述的用于MySQL的快速回收回滚空间的方法，其特征在于，所述调整所述新的系统表空间文件的长度，使其大于或者等于系统设定的系统表空间文件的初始长度，包括：

计算所述系统设定的系统表空间文件的初始长度与所述新的系统表空间文件长度的差值；

获取所述差值与系统设定的数据页长度的比值，以大于或者等于该比值的最小整数作为需要追加的数据页的数目；

向所述新的系统表空间文件的尾部追加相应数目的类型为空闲页的数据页。

10.根据权利要求1所述的用于MySQL的快速回收回滚空间的方法，其特征在于，所述用所述新的系统表空间文件替换所述原始系统表空间文件，采用如下方式实现：

删除所述原始系统表空间文件，并使用所述原始系统表空间文件的文件名为所述新的系统表空间文件重新命名。

11.根据权利要求1-10任意一项所述的用于MySQL的快速回收回滚空间的方法，其特征在于，还包括：

停止MySQL主数据库和备用数据库之间的同步；

并且所述关闭数据库、生成不包含回滚空间的新系统表空间文件、以及替换原始系统表空间文件的操作，都是针对上述停止了同步操作的备用数据库进行的。

12.根据权利要求11所述的用于MySQL的快速回收回滚空间的方法，其特征在于，在停止MySQL主数据库和备用数据库之间的同步之后，执行下述操作：

执行所述主数据库和所述备用数据库之间的切换；

并且所述关闭数据库、以及生成不包含回滚空间的系统表空间文件并替换原始系统表空间文件的操作，都是针对执行所述切换操作后的备用数据库进行的。

13.一种用于MySQL的快速回收回滚空间的装置，其特征在于，所述装置包括：

数据库关闭单元，用于采用在关闭过程中清除无效回滚数据的方式关闭MySQL数据库；

文件生成单元，用于以待回收回滚空间的原始系统表空间文件为基础，生成一个不包含回滚空间的新的系统表空间文件；

文件替换单元，用于用所述新的系统表空间文件替换所述原始系统表空间文件。

14.根据权利要求13所述的用于MySQL的快速回收回滚空间的装置，其特征在于，所述装置包括：

数据库启动单元，用于用所述新的系统表空间文件替换所述原始系统表空间文件后，重新启动所述MySQL数据库。

15.根据权利要求13所述的用于MySQL的快速回收回滚空间的装置，其特征在于，所述数据库关闭单元包括：

关闭选项设置子单元，用于将所述MySQL数据库的关闭选项设置为，MySQL数据库系统预定义的在关闭过程中包含清除无效回滚数据操作的特定值；

关闭执行子单元，用于关闭所述MySQL数据库。

16.根据权利要求13所述的用于MySQL的快速回收回滚空间的装置，其特征在于，所述装置还包括：

未同步数据页减少单元，用于减少缓冲池中的未同步到磁盘的已修改数据页的数量，使其小于预先设定的值。

17.根据权利要求16所述的用于MySQL的快速回收回滚空间的装置，其特征在于，所述未同步数据页减少单元包括：

比例设置子单元，用于设置未同步到磁盘的已修改数据页在缓冲池中所占比例为0；

数量监测子单元，用于监测缓冲池中的未同步到磁盘的已修改数据页的数量，直至所述数量小于预先设定的值。

18.根据权利要求13所述的用于MySQL的快速回收回滚空间的装置，其特征在于，所述文件生成单元包括：

文件创建子单元，用于创建一个新的系统表空间文件；

数据页复制子单元，用于按照系统表空间文件的格式，将所述原始系统表空间文件中包含的、且类型不是回滚页的数据页写入所述新的系统表空间文件中；

统计信息更新子单元，用于更新所述新的系统表空间文件中与回滚空间相关的统计信息的内容为，系统表空间文件默认的代表当前无回滚空间的值；

长度调整子单元，用于判断所述新的系统表空间文件的长度是否小于系统设定的系统表空间文件的初始长度；若是，调整所述新的系统表空间文件的长度，使其大于或者等于系统设定的系统表空间文件的初始长度。

19.根据权利要求18所述的用于MySQL的快速回收回滚空间的装置，其特征在于，所述数据页复制子单元包括：

数据页读取子单元，用于以系统设定的数据页的长度为单位，依次读取所述原始系统表空间文件中的数据页；

类型判断子单元，用于判断当前所读数据页的类型是否为系统字典页或者二次写缓冲页；

数据页写入子单元，用于当所述类型判断子单元的输出为“是”时，将所述数据页读取子单元读取的数据页的内容写入所述新的系统表空间文件，并更新该数据页在新的系统表空间文件中的位置信息、以及该数据页与同类型的前一个数据页之间的相对位置关系信息。

控制子单元，用于调度上述三个子单元，直至将所述原始系统表空间文件中的系统字典页和二次写缓冲页都写入所述新的系统表空间文件为止。

20.根据权利要求18所述的用于MySQL的快速回收回滚空间的装置，其特征在于，所述长度调整子单元包括：

长度判断子单元，用于判断所述新的系统表空间文件的长度是否小于系统设定的系统表空间文件的初始长度；

空闲页追加子单元，用于当所述长度判断子单元的输出为“是”时，以系统设定的数据页的长度为单位，向所述新的系统表空间文件的尾部追加一个类型为空闲页的数据页，并触发所述长度判断子单元。

21.根据权利要求18所述的用于MySQL的快速回收回滚空间的装置，其特征在于，所述长度调整子单元包括：

长度差值计算子单元，用于计算所述系统设定的系统表空间文件的初始长度与所述新的系统表空间文件长度的差值；

空闲页数量计算子单元，用于获取所述差值与系统设定的数据页长度的比值，以大于或者等于该比值的最小整数作为需要追加的数据页的数目；

空闲页批量追加子单元，用于向所述新的系统表空间文件的尾部追加相应数目的类型为空闲页的数据页。

22.根据权利要求13所述的用于MySQL的快速回收回滚空间的装置，其特征在于，所述文件替换单元具体用于，删除所述原始系统表空间文件，并使用所述原始系统表空间文件的文件名为所述新的系统表空间文件重新命名。

23.根据权利要求13-22任意一项所述的用于MySQL的快速回收回滚空间的装置，其特征在于，还包括：

同步停止单元，用于停止MySQL主数据库和备用数据库之间的同步；并且所述数据库关闭单元、所述文件生成单元、以及所述文件替换单元部署在上述停止了同步操作的备用数据库上实施。

24.根据权利要求23所述的用于MySQL的快速回收回滚空间的方法，其特征在于，还包括：

主备切换单元，用于在停止MySQL主数据库和备用数据库之间的同步之后，执行所述主数据库和所述备用数据库之间的切换；并且所述数据库关闭单元、所述文件生成单元、以及所述文件替换单元部署在上述执行切换操作后的备用数据库上实施。