CN105159818B - 内存数据管理中日志恢复方法及其仿真系统 - Google Patents

Abstract

本发明公开了一种内存数据管理中日志恢复方法及其仿真系统，涉及数据管理技术领域，包括以下步骤：1)、主节点获取集群节点的节点编号，并对所述集群节点发送数据写入命令，所述集群节点进行数据存储，主节点形成映射表；2)、主节点根据节点编号，向与所述集群节点匹配的日志节点发送集群节点日志命令，所述日志节点将日志存储，并将所述日志持久化，然后向主节点日志成功记录信息；3)、在集群节点发生故障时，停止事务执行，主节点获取故障节点的编号，获取日志节点中日志记录进行恢复，能够对集群节点中发生故障部分的节点进行自己恢复的状态并且不需要相互传递有关数据项的信息，降低了日志恢复的复杂性，提高日志恢复的速率和安全保障。

Description

内存数据管理中日志恢复方法及其仿真系统

技术领域

本发明涉及数据管理技术领域，尤其涉及一种内存数据管理中日志恢复方法及其仿真系统。

背景技术

内存数据管理技术特别是内存数据库技术，将数据的运算和存储都依托于内存，具有高并发、高吞吐量、低延时等特性，因此被广泛用于极高性能需求的场合。但是，由于内存是一种易失性的存储介质，而内存数据库往往承担着高吞吐量、高速存取的任务，数据损失的风险巨大。这种损失往往给数据库的使用者带来巨额的财产损失。

近年来，随着硬件性能的大幅度提升、成本的大幅度降低，内存数据管理研究领域的研究受到了更为广泛的关注。其中，由于内存易失性而带来的有关日志恢复的问题是主要研究方向之一。日志文件读写中非易失存储器慢速I/O对于内存和CPU造成停滞是内存数据库日志恢复需要解决的问题，并且，目前没有一个针对日志恢复有关的研究平台。

为了保证数据库信息不丢失，事务提交之前必须将日志记录在稳定存储器中(一般为磁盘)，那么大容量内存、高负载环境容易使日志的读写成为瓶颈。一种直观的解决方式是使用非易失性的存储器存储日志，它具有比磁盘更快存取速度且断电后数据不丢失的特性，从而缩减了提交时间。然而类似于SSD这种存储器的价格仍然较高，不能得到广泛的使用。

发明内容

针对上述缺陷或不足，本发明的目的在于提供一种内存数据管理中日志恢复方法及其仿真系统。

为达到以上目的，本发明的技术方案为：

一种内存数据管理中日志恢复方法，包括以下步骤：

主节点获取集群节点的节点编号，并对所述集群节点发送数据写入命令，所述集群节点进行数据存储，主节点形成映射表；

主节点根据节点编号，向与所述集群节点匹配的日志节点发送集群节点日志命令，所述日志节点将日志存储，并将所述日志持久化，然后向主节点日志成功记录信息；

在集群节点发生故障时，停止事务执行，主节点获取故障节点的编号，获取日志节点中日志记录对集群节点进行恢复。

进一步的，所述主节点获取集群节点的节点编号的具体过程为：

当一个数据项被新插入存储集群时，首先需要在映射表中注册自己的键值，并取得集群反馈回的节点编号，然后这个键值对被正放入集群中。

进一步的，所述映射表使用Map容器实现。

进一步的，所述集群节点进行数据存储为分布式存储方式。

进一步的，所述日志持久化具体过程为：

使用日志节点上的RDB持久化命令SAVE，将日志节点上的内容持久化到磁盘上，并且返回成功或者失败，RDB持久化将内存中的数据完全以快照的形式录入磁盘中。

进一步的，当进行物理日志恢复过程时：

主节点获取需要恢复的集群节点的节点编号；

主节点根据上述所获取的节点编号，取出该节点对应的redo_log日志，redo_log日志是日志节点上的集合日志；

集群节点扫描所有的非redo_log日志链表，即还没有commit的事务的私有txn_redo日志，并且销毁这些私有的txn_redo日志，txn_redo日志是针对某个具体事务编号的事务私有日志；

主节点取完所有故障节点的日志后，按照LSN将日志排列好再根据排列好后redo日志重做事务片段，完成日志恢复。

进一步的，当进行逻辑日志恢复时：

主节点获取需要恢复的集群节点的节点编号；

所有需要恢复的集群节点将redo_log日志取出，并且归并到主节点上；

主节点按照LSN重新排列需要恢复的集群节点的redo_log日志；

所有集群节点扫描所有非redo_log链表，销毁存在的私有txn_redo日志；

主节点执行统一的恢复，完成日志恢复。

一种内存数据管理中日志恢复仿真系统，包括主节点以及Redis实例，其中；

主节点包括映射列表、事务模拟器、恢复模拟器；

映射列表存放了数据项和对应的集群中具体节点编号；

事务模拟器随机产生出并发或是串行的事务；

恢复模拟器通过与事务模拟器的合作，完成多种日志的生成和分发，也在故障后重新收集日志换成恢复步骤；事务开始时，记录下LSN、事务编号、start标识，提交时记录commit标识，中止时记录abort标识；

Redis实例包括作为存储节点的Redis集群和日志节点；

Redis集群中包括多个成为工作节点的Redis实例；

日志节点由多个单独的Redis实例组成，日志节点接受主节点的日志并完成日志的持久化任务。

与现有技术比较，本发明的有益效果为：

本发明提供了一种内存数据管理中日志恢复方法，还提供了一种内存数据管理中日志恢复仿真系统RecoS，通过在集群环境下使用了Redis作为底层的数据和日志存储，上层使用客户端逻辑程序控制各个节点的协调工作。将发生在某个节点上的事务日志交给这个节点去记录，达到了分配负载的效果，并采用类似ARIES日志记录的物理日志可以实现多机并行恢复(parallel recovery)，对发送故障的节点进行自己恢复的状态并且不需要相互传递有关数据项的信息，降低了日志恢复的复杂性，提高日志恢复的速率和安全保障。

附图说明

图1是本发明内存数据管理中日志恢复方法的流程框图；

图2是本发明内存数据管理中日志恢复方法中主节点的结构示意图；

图3是本发明内存数据管理中日志恢复方法中主节点的数据插入节点框图；其中(a)为数据插入节点的步骤流程框图；(b)为另一种映射表表示方式；

图4是本发明内存数据管理中日志恢复方法的仿真系统结构示意图。

具体实施方式

下面结合附图对本发明做详细描述。

实施例一

本发明使用“集群环境”或者“多机环境”来表示一种分布式的概念，集群环境下主要考虑将数据分到多台机器上存储。在集群环境下，每个机器节点称为node，由于现代计算机的多核心CPU普遍使用，一些多线程的任务可以分别在一个node中的多个核心上运行，CPU的一个核心称之为一个site。现有的内存数据库系统如VoltDB和SiloR中使用集群和集群节点中多处理器的优势，将任务分布给多个线程，由于每个处理器的核心至少可以处理一个线程(在超线程的CPU中可以处理两个线程)。系统将事务分类成为一个node中的事务和跨node的事务，并且试图将相关的事务进程放到一个node的site中，这样如果一个site中的事务回滚，只会影响到这个node而已。同样对于日志，在每个node中的所有site都共享一个日志。

如图1所示，本发明提供了一种内存数据管理中日志恢复方法，包括以下步骤：

1)、主节点获取集群节点的节点编号，并对所述集群节点发送数据写入命令，所述集群节点进行数据存储，主节点形成映射表；

主节点是RecoS负责逻辑程序执行部分的主机节点，一般使用性能强悍的机器作为主节点。工作节点是下层的Redis集群中负责存储的节点，由于在Redis集群的规范中需要使用后备节点，这时的相应master节点称为“主节点”，但是这里为了和RecoS的主节点区分，称之为“工作节点”。而日志节点是为工作节点专门配备的用于记录日志的Redis实例。

如图2所示，图2为主节点的拓扑结构图，主节点通过网络连接保持对Redis实例的控制和获取状态。主节点的程序运行在一台性能配置较高的计算机上，它主要用来负责除了数据和日志存储之外的所有功能，包括发送读写命令、模拟事务的进行、控制日志的读写时机等。主节点程序采用Redis推荐的Java程序语言客户端Jedis编写，Jedis可以调用API来操控集群的运行。

具体的，所述主节点获取集群节点的节点编号的过程为：

当一个数据项被新插入存储集群时，首先需要在映射表中注册自己的键值，并取得集群反馈回的节点编号，然后这个键值对被正放入集群中。

本发明中，映射表中存放了数据项和对应的集群中具体节点编号(集群内部对于每个节点有相应的编号，可以看成是节点组成的数组，编号就是其数组下标)，实际上充当了索引的结构。当一个数据项被新插入存储集群时，需要经过两个步骤：

首先需要在映射表中注册自己的键值并取得集群反馈回的节点编号，这是需要主节点程序自己管理的部分。然后这个键值对被真正放入集群中，虽然这由集群自动管理，但是仍然需要上一步中记录下它的存放位置，这是为了对单独的集群节点做单独的日志记录。映射表可以使用Map容器实现。

主节点向集群内节点发送读写命令，包括基本的GET、SET命令和利用Redis提供的多种数据结构的相应命令，例如在存储日志的时候使用list数据结构的存取命令LPUSH、LPOP。发送读写命令是最基本也是最频繁使用的功能，在不超过集群内存的使用范围的条件下，集群提供了高速有效的存取性能。

2)、主节点根据节点编号，向与所述集群节点匹配的日志节点发送集群节点日志命令，所述日志节点将日志存储，并将所述日志持久化，然后向主节点日志成功记录信息；

所述日志持久化具体过程为：

使用日志节点上的RDB持久化命令SAVE，将日志节点上的内容持久化到磁盘上，并且返回成功或者失败，RDB持久化将内存中的数据完全以快照的形式录入磁盘中。

3)、在集群节点发生故障时，停止事务执行，主节点获取故障节点的编号，获取日志节点中日志记录对集群节点进行恢复。

本发明中，主要提供了两种恢复过程：

第一种，物理日志恢复过程：

3.1物理日志格式：只记录LSN，TxnID，Type，TupleID，OldValue(NewValue)这几个信息

·LSN。LSN(Log Sequence Number，日志序号)表示日志在全局范围内的序号。一些文献使用timestamp(时间戳)的方式来代替LSN。这样十分容易编程实现——使用Java中的System系统包下的System.currentTimeMillis()这个方法获得的时间代表了从1970年1月1日午夜开始到那时所经过的毫秒数，随着时间的进行，这个数字一定是递增的，这一点显然满足LSN的递增需求。然而在实验中发现，如果单纯使用以毫秒时间戳的话，即使将主节点的程序布置在一台普通的PC上，在同一毫秒内也能产生多个相同的timestamp所以在试图去模拟高速吞量的情况下，可能遇到相同毫秒时间而恢复时无法根据timestamp进行日志排序的情况。为了防止此类情况发生，需要预备另一种方案，让程序提供递增的数字序列供给日志使用，这样就避免了上述情况，而由此带来的额外开销是维护一个静态的全局方法成员。

·TxnID。采用事务模拟器提供的ID作为日志的TxnID，即事务ID，在事务模拟器中也应当保证防止相同的ID出现。

·Type。在ARIES中通常需要记录下日志的类型，比如这是日志的start、end、commit日志，update/delete/insert日志，或者其他的一些特殊的日志标识类型，都会通过这个字段标出，在实现中使用一个枚举的类型来表示这个值，使得存储的时候更加方便。为了方便阅读，在后文的日志举例中如果不再显示Type字段，那么可以将这种日志视为update类型。

·TupleID。不再需要记录元组所在关系表的编号(TableID)，因为可以通过Redis集群的特性自动将这个元组号对应到相应的节点。

·OldValue(NewValue)。UNDO日志保存旧值，REDO日志保存新值。

由于Redis的键值对都以字符串的形式来组织，那么一条日志＜LSN，TxnID，TupleID，Value＞可以适用“冒号表示法”记录成字符串：123456：1：A：100，对应表示了LSN为123456、事务ID为1、将元组A的旧值(新值)记录为100的这样一条日志，相关的字符串用冒号相连接成为一个长的字符串也是Redis文档所推崇的一种记录方式。

3.2、日志记录在日志节点的数据库中(内存中)，然后将redo日志刷入那个节点的磁盘，undo日志在事务提交后清空。Redis提供了双端链表(list)的数据结构，可以很好地用来仿真日志记录。

例如这两段简单的命令：

RPUSH redo_log“123456：1：A：100”

RPUSH redo_log“123457：1：B：20”

记录了TxnID为1的事务的两条redo日志，这两条日志分别作为节点从尾部插入了名称为“redo_log”的链表中。利用链表来记录日志有其优点，首先链表是一种清晰的、非常适合表示日志条目的数据结构，此外，通过特定的命令，如LTRIM命令，可以实现一定范围内的日志截取，这非常适用于一个需要固定节点数的情形，当链表长度超过这个固定值，就可以自动截取。在仿真系统中运用到了另外一个命令LLEN，即返回链表的长度，可以设定日志链在长度到达一个定值之后截断并刷入磁盘。

3.3、使用日志节点上的RDB持久化命令SAVE，可将该节点上的内容持久化到磁盘上，并且返回成功或者失败。RDB持久化是一种快照式的持久化方法，即将内存中的数据完全以快照的形式录入磁盘中。仿真系统中设置了每次在日志节点中写入日志条目后就立即刷入磁盘。

3.4、物理日志恢复过程：

1)、主节点获取需要恢复的集群节点的节点编号；

2)主节点根据上述所获取的节点编号，取出该节点对应的redo_log日志，redo_log日志是日志节点上的集合日志；

3)、集群节点扫描所有的非redo_log日志链表，即还没有commit的事务的私有txn_redo日志，并且销毁这些私有的txn_redo日志，txn_redo日志是针对某个具体事务编号的事务私有日志；

4)、主节点取完所有故障节点的日志后，按照LSN将日志排列好根据排列好后redo日志重做事务片段，完成日志恢复。

具体的恢复程序为：

在发生故障后系统自动停止事务执行，故障节点的内存中数据和相应日志节点内存中数据丢失(被销毁)。具体的恢复过程如下：

以上恢复过程也有一处与磁盘数据库有所不同。可以看到，在取出故障节点的redo_log后，还销毁了所有日志节点中没有commit的日志链表(只有txn_redo没有txn_undo因为txn_undo日志在故障后随着内存内容丢失了而txn_redo日志已经被提前刷新到磁盘上)。因为故障时没有commit的事务所做的更改不能反应在数据库中，所以在DRDB中，需要将没有commit的事务从后向前根据日志进行undo，而在MMDB中，事务对数据库的更改已经随着内存数据的丢失而丢失，所以只需要将它们的redo日志销毁即可。

由于采用WAL机制，那么存在这样一种情况——如果故障发生在日志被写入后而事务被真正执行前，那么这个事务没有被真正执行成功，而日志却被记录下来。由于在的策略中，事务在commit日志被写入后才能真正地去将事务真正提交，如果在这段时间内发生故障，则会造成矛盾——日志上已经有了commit而故障前并没有真正提交日志。一种很常见的方式是系统仍然去完成这个事务，将其置于commit状态，即使用户并没有在故障前获得这个事务已经commit的消息。这种情况不考虑在仿真系统中。

第二种为逻辑日志恢复过程：

相比物理日志，逻辑日志在格式、方案、恢复上都会有所不同。其中有两个方面最为特殊，一是command logging需要结合存储过程和参数来进行记录和恢复，二是在集群环境下的日志记录不能够简单地让某个节点只记录自己节点的日志，这就带来了恢复上的种种问题。

4.1、日志格式

记录LSN、TxnID、SPP、Params，其中SPP是指已经保存的存储过程指针(storedprocedure pointer)。之所以称之为指针，是因为它不是记录这个存储过程，而是记录存储过程的位置。这个存储过程以类的对象形式存放在主节点中，并且随着时间的推移，存储过程并不会消失。

4.2、逻辑日志恢复过程

1)主节点获取需要恢复的集群节点的节点编号；

2)、所有需要恢复的集群节点将redo_log日志取出，并且归并到主节点上；

3)、主节点按照LSN重新排列需要恢复的集群节点的redo_log日志；

4)、所有集群节点扫描所有非redo_log链表，销毁存在的私有Txn_redo日志；

5)、主节点执行统一的恢复，完成日志恢复。

以command logging为代表的逻辑日志的恢复耗时且是不能并行的，这两点是其不能得到广泛应用的主要原因。

恢复过程需要在主机节点中重新建立日志中的SPP和存储过程的对应关系，即主节点需要装入以前的类再重新执行一段程序代码。相比只要根据日志执行Redis的SET命令，需要更多的计算资源，这就是逻辑日志在恢复过程中十分耗时的原因。

更为重要的是，逻辑日志的恢复不支持并行，因为恢复的时候需要集中到全局日志。以一个情景为例：假设一条语句的结果影响了a和b两个节点，另一条语句影响了b和c两个节点。在系统运行的过程中，a遇到故障需要重启恢复。此时若要重新执行SQL语句，那么没有发生故障的b也需要进行恢复，然而b如果需要恢复，那么跟b有联系的c节点也要恢复……以此类推，形成了一种洪水泛滥(flood)效应——结果就是如果节点中一个故障，所有节点都必须从头开始恢复。回顾物理日志，每个节点记录自己的新旧值，不和别的节点发生数据上的联系，在某个节点发生故障后别的节点只是停下来等待它恢复而不是跟着一起恢复。

逻辑日志恢复中程序具体为：

RecoS中的逻辑日志恢复过程如下：

通过构建每个逻辑日志的依赖图(dependency graph)来确定这个SQL语句到底会影响到多少节点，依赖图的创建需要占用记录日志时多余时间和空间，有效较少了恢复时的负载。

实施例二

如图4所示，一种内存数据管理中日志恢复仿真系统，包括主节点以及Redis实例，其中；

主节点包括映射列表、事务模拟器、恢复模拟器；主节点通过网络连接保持对Redis实例的控制和获取状态。主节点的程序运行在一台性能配置较高的计算机上，它主要用来负责除了数据和日志存储之外的所有功能，包括发送读写命令、模拟事务的进行、控制日志的读写时机等。主节点程序采用Redis推荐的Java程序语言客户端Jedis编写，Jedis可以调用API来操控集群的运行。主节点的主要组成部分见图2。

映射列表存放了数据项和对应的集群中具体节点编号；映射表中存放了数据项和对应的集群中具体节点编号(集群内部对于每个节点有相应的编号，可以看成是节点组成的数组，编号就是其数组下标)，实际上充当了索引的结构。当一个数据项被新插入存储集群时，需要经过两个步骤，如图3(a)所示。

首先需要在映射表中注册自己的键值并取得集群反馈回的节点编号，这是需要主节点程序自己管理的部分。然后这个键值对被真正放入集群中，虽然这由集群自动管理，但是仍然需要上一步中记录下它的存放位置，这是为了对单独的集群节点做单独的日志记录。映射表可以使用Map容器实现。

主节点向集群内节点发送读写命令，包括基本的GET、SET命令和利用Redis提供的多种数据结构的相应命令，例如在存储日志的时候使用list数据结构的存取命令LPUSH、LPOP。发送读写命令是最基本也是最频繁使用的功能，在不超过集群内存的使用范围的条件下，集群提供了高速有效的存取性能。

事务模拟器随机产生出并发或串行的事务，由于恢复策略和事务的开始、提交是紧密相关的，事务的每段执行都需要相应的日志记录，所以即使仿真系统主要仿真的是恢复过程，也需要一个简单的事务管理部分与之协调工作。事务模拟器的任务是生成一系列事务，这些事务对数据库的影响可以是程序既定的，也可以是随机出来的；可以是串行的，也可以是并发的，系统可以记录当前事务的发生和结束时间，也可以原子地给事务生成LSN以写入日志中。

真正数据库事务是十分复杂的，仿真平台将重点放在事务与日志的关系上，即事务模拟器产生一组对元组操作的序列，在WAL的背景下，事务管理器产生一个操作，就将其放入恢复模拟器中以生成日志，恢复模拟器接收这个操作并提交日志，经过日志的持久化后，这个操作真正执行，结果反映在存储节点上。

有关事务的并发。事务模拟方式产生出并发的事务，这些事务有不同的开始时刻与执行时间，并在随机的时刻产生操作。和并发事务相关的加锁等步骤，则是交给了下层的存储节点，Redis集群会处理并发操作对数据产生的冲突问题。

对于物理日志，需要元组的新值和旧值，那么事务模拟器仅需要指定一个元组并产生新值、旧值，然后将这些信息传递给恢复管理器的日志部分。对于逻辑日志，采用H-Store中的方法将事务用存储过程的概念来展示，存储过程是用Java类实现的，一个特定的存储过程就是一个类对象，需要执行事务的时候在执行队列的方法参数列表中放入一个类对象和相应参数，最后执行这个方法表示开始执行该事务。

恢复模拟器通过与事务模拟器的合作，完成多种日志的生成和分发，也在故障后重新收集日志换成恢复步骤；事务开始时，记录下LSN、事务编号、start标识，提交时记录commit标识，中止时记录abort标识；

Redis实例包括作为存储节点的Redis集群和日志节点；

Redis集群的主要作用就是存储数据和检查点。

Redis集群(cluster)通过Redis提供的Ruby脚本工具，可以生成含有多个工作节点(也就是集群中的主节点master)和从节点(slave)的集群，为仿真系统去模拟多机环境的恢复提供了良好的分布式和容错环境，上层程序逻辑不用去关心下层存储的细节，只需发送正确的存取指令即可，就好像是对一个Redis实例进行操作一样。

日志节点是由多个单独的Redis实例组成，日志节点接受主节点的日志并完成日志的持久化(刷入磁盘)任务。在Redis集群节点去存储数据的情况下，完成日志存取的任务交给了日志节点。RecoS中的多个日志节点是与集群节点相匹配的，一个日志节点去承担一个集群节点的日志任务。

当日志记录存储到日志节点后可以被立即持久化，主节点将会收到这个日志节点返回的日志成功记录信息，便可以确认上一条日志被成功写入磁盘上。结合前文的描述，主节点需要维持如下几个连接：集群节点的整体连接、集群节点中每个节点的单独连接、日志节点的单独连接。

很重要的一点是，如果一个恢复策略需要一个全局的日志，而不是多个节点单独存储的日志，那么全局日志将会存储在主节点中；或者是将所有分散的日志集中到主节点中。

Redis集群生成含有多个工作节点和从节点的集群；

Redis集群中不存在中心节点或是代理节点，集群中各个节点存储的数据没有交集，可以视为一个shared-nothing(无共享)结构。在配置集群初试参数时，可以为每个工作节点(master)设定一个或者多个从节点(slave)，master和slave用相同的服务器实现并且有相同的功能，从节点同步工作节点的内容，并且通过选举的方式产生一个用于替换失效的主节点，实现了容错的功能。但是从节点的作用并没有在本文后续的工作中体现，或许在研究容错时需要考虑进去。

集群中的节点具有以下功能：

·存取数据，保持键值对模型。

·拥有整个集群的状态，可以找到一个特定值在集群中的位置，也就是说，每个节点都知道一个特定的值在那个节点上，这是通过下一条“分布模型”中的“数据槽”计算实现的。

·自动发现新加入的节点和失效的节点，并且及时更新数据槽信息。

集群中两个节点之间都有TCP连接，使用二进制协议进行通信，并且实现一个典型的基于Gossip协议的分布式模型。主要的特性有：

·不断传播(propagate)集群的相关信息，用来发现新节点

·向其他节点发送PING消息，检测这个节点是否正常工作

·可以在特定时间发生时发送全局的集群信息

这些与分布式系统有关的特性不仅有利于集群的健壮性保证，也使得数据存储仿真环境更加接近于真实环境。

日志节点由多个单独的Redis实例组成，日志节点接受主节点的日志并完成日志的持久化任务。

本发明中，提供了故障模型

故障模型决定了故障发生后系统各个部分所处的状态。系统可能发生多种故障，每种故障也需要不同的处理方式。一般来说最需要考虑的故障有以下几种：

(1)事务故障。事务故障是指事务执行失败的情况，一般由两种原因导致

·逻辑错误。事务由于程序内部的执行条件出错而导致事务无法继续进行，表现各类情况导致的程序异常，例如非法输入，数据溢出等。

·系统错误。系统进入不良状态，导致暂时无法执行下去(如死锁)，事务可以在以后的某个时间内再重新执行。这种不良状态不一定能够重现。

(2)系统崩溃。数据库系统、操作系统漏洞，各种硬件故障，导致易失性存储器的内容直接丢失，而硬件层和软件层中良好的内部检查使得非易失性存储器中的内容完好无损。这是一种合理的故障-停止假设(fail-stop assumption)

(3)磁盘故障。磁头损坏或者出现坏道导致磁盘内容丢失或无法读取。

本发明仿真系统中主要模拟出上述的事务故障和系统崩溃，假定某个节点故障之后必须要重启，并且认为出现故障后内存数据必然丢失而磁盘的数据不会丢失。仿真系统并没有去直接去让系统断电、损坏硬件等方式来实现故障，也没有重启故障节点来开始恢复。可以从故障的直接结果来模拟出系统故障，那就是：

(1)内存中没有了数据。内存没有了数据即集群节点中的数据都被抹去，可以通过FLUSHDB命令直接完全清空集群节点数据，并且通知系统不再进行任何工作。这种方式只能清空节点持有的键值对，并不会抹去有关集群内部相互连接的信息，也不会抹去集群中的槽信息。恢复的过程只需重新写入键值对即可。

(2)事务中断不再继续进行。在发送FLUSHDB命令的同时，事务模拟器将同时收到通知，不再产生新的事务，通知恢复模拟器系统进入了故障模式。恢复模拟器停止当前的日志记录，如果存在未刷新到磁盘的日志，也是被放弃掉。由于这些日志并没有写成功，不符合WAL的条件，所以与日志相关的数据项更改并没有反应到数据库里。

(3)故障节点重启。RecoS直接在被清空的节点上开始执行恢复。

在集群环境下，可能会出现其中的一个或者多个工作节点发生故障，那么发生故障节点此时数据库内容被清空(重启的结果)，正常的节点没有清空数据但是也不能继续接受事务执行。根据恢复策略的不同，正常节点也有可能需要参与恢复。

是否需要模拟主节点故障。其实，仿真系统最主要关注的就只是内存数据丢失后系统的应对策略。主节点放置了一段程序，这段程序逻辑引发事务操作，主节点的故障属于事务故障，又回到了上面的讨论范围内。所以文章不考虑主节点的故障情况。

本实施例首先提出了MMDB的恢复子系统——RecoS仿真平台，平台使用主节点的程序逻辑控制Redis进行日志、检查点、数据的存储，Redis为平台提供了真实有效的存储环境，而上层的Jedis程序可以支持日志恢复策略的编写。接着提出如何结合平台来实现物理日志、逻辑日志、故障恢复、主要由于内存的易失性而带来的恢复细节上的不同，实现了RecoS仿真平台。仿真平台以实现内存数据库的恢复子系统为主要目标，采用了贴近真实情况数据集群作为底层存储介质，并且为实现各种恢复策略提供了良好的接口。在平台上实现并对比了以ARIES为代表的物理日志和以command logging为代表的逻辑日志的主要过程和重要细节。同时叙述了与日志相关的故障恢复和检查点过程，并结合内存的独特性质差别对比了内存数据库和磁盘数据库的异同。

Claims (7)

1.一种内存数据管理中日志恢复方法，其特征在于，包括以下步骤：

主节点获取集群节点的节点编号，并对所述集群节点发送数据写入命令，所述集群节点进行数据存储，主节点形成映射表；

主节点根据节点编号，向与所述集群节点匹配的日志节点发送集群节点日志命令，所述日志节点将日志存储，并将所述日志持久化，然后向主节点日志成功记录信息；

在集群节点发生故障时，停止事务执行，主节点获取故障节点的编号，获取日志节点中日志记录对集群节点进行恢复；

当进行物理日志恢复过程时：

主节点获取需要恢复的集群节点的节点编号；

主节点根据上述所获取的节点编号，取出该节点对应的redo_log日志，redo_log日志是日志节点上的集合日志；

集群节点扫描所有的非redo_log日志链表，即还没有commit的事务的私有txn_redo日志，并且销毁这些私有的txn_redo日志，txn_redo日志是针对某个具体事务编号的事务私有日志；

主节点取完所有故障节点的日志后，按照LSN将日志排列好根据排列好后redo日志重做事务片段，完成日志恢复。

2.根据权利要求1所述的内存数据管理中日志恢复方法，其特征在于，所述主节点获取集群节点的节点编号的具体过程为：

当一个数据项被新插入存储集群时，首先需要在映射表中注册自己的键值，并取得集群反馈回的节点编号，然后这个键值对被正放入集群中。

3.根据权利要求2所述的内存数据管理中日志恢复方法，其特征在于，所述映射表使用Map容器实现。

4.根据权利要求1所述的内存数据管理中日志恢复方法，其特征在于，所述集群节点进行数据存储为分布式存储方式。

5.根据权利要求1所述的内存数据管理中日志恢复方法，其特征在于，所述日志持久化具体过程为：

使用Redis日志节点上的RDB持久化命令SAVE，将日志节点上的内容持久化到磁盘上，并且返回成功或者失败，RDB持久化将内存中的数据完全以快照的形式录入磁盘中。

6.根据权利要求1所述的内存数据管理中日志恢复方法，其特征在于，当进行逻辑日志恢复时：

主节点获取需要恢复的集群节点的节点编号；

所有需要恢复的集群节点将redo_log日志取出，并且归并到主节点上；

主节点按照LSN重新排列需要恢复的集群节点的redo_log日志；

所有集群节点扫描所有非redo_log链表，销毁存在的私有txn_redo日志；

主节点执行统一的恢复，完成日志恢复。

7.一种内存数据管理中日志恢复仿真系统，其特征在于，包括主节点以及Redis实例，其中；

主节点包括映射列表、事务模拟器、恢复模拟器；

映射列表存放了数据项和对应的集群中具体节点编号；

事务模拟器随机产生出并发或是串行的事务；

恢复模拟器通过与事务模拟器的合作，完成多种日志的生成和分发，也在故障后重新收集日志对集群节点进行恢复；事务开始时，记录下LSN、事务编号、start标识，提交时记录commit标识，中止时记录abort标识；

Redis实例包括作为存储节点的Redis集群和日志节点；

Redis集群包括多个成为工作节点的Redis实例；

日志节点由多个单独的Redis实例组成，日志节点接受主节点的日志并完成日志的持久化任务。