CN109426585A - 一种备份、恢复数据库数据的方法和装置 - Google Patents
一种备份、恢复数据库数据的方法和装置 Download PDFInfo
- Publication number
- CN109426585A CN109426585A CN201710722908.7A CN201710722908A CN109426585A CN 109426585 A CN109426585 A CN 109426585A CN 201710722908 A CN201710722908 A CN 201710722908A CN 109426585 A CN109426585 A CN 109426585A
- Authority
- CN
- China
- Prior art keywords
- persistence
- file
- delta file
- delta
- database
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1448—Management of the data involved in backup or backup restore
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请公开了一种用于备份数据库数据的方法,包括:创建持久化增量文件;接收写命令,记录所述写命令到所述持久化增量文件中;在所述持久化增量文件中添加时间戳。本申请还公开了一种用于恢复数据库数据的方法,其包括:获取目标时间戳,确定待恢复的时间点;根据所述待恢复的时间点,获取对应的数据库全量文件和持久化增量文件列表;依据所述对应的数据库全量文件和持久化增量文件列表,恢复数据库数据到所述待恢复的时间点。本申请可实现对数据库数据在任意指定时间点的恢复。
Description
技术领域
本申请涉及数据库技术领域,具体涉及一种备份数据库数据的方法。本申请同时涉及一种恢复数据库数据的方法及装置、备份数据库数据的装置、计算机可读介质以及电子设备。
背景技术
随着互联网web2.0网站的兴起,传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS(Social Network Software,社交网络服务)类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题,而非关系型的数据库NoSQL(Not OnlySQL,泛指非关系型的数据库)则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战,尤其是大数据应用难题。
键值(key/value)存储数据库是NoSQL数据库四大分类中的一种,这一类数据库主要会使用到一个哈希表,这个表中有一个特定的键和一个指针指向特定的数据。key/value模型对于IT系统来说的优势在于简单、易部署,例如,Redis数据库。Redis是一个高性能的key/value数据库,Redis的出现,很大程度补偿了memcached(分布式内存对象缓存系统)这类key/value存储的不足,在部分场合可以对关系数据库起到很好的补充作用。Redis支持丰富的数据结构,同时也支持数据的持久化。
Redis的持久化方式,包括:RDB(Redis DataBase)持久化和AOF(Append OnlyFile)持久化,目前只支持一个当前数据库的快照(snapshot),恢复数据的时候也只能根据一次性恢复整个快照(snapshot),如果想恢复到两次快照之间的任意时间点事无法做到的,即不能按任意时间点恢复数据。
发明内容
本申请提供一种用于备份数据库数据的方法,以解决现有Redis这类非关系键值(key/value)存储数据库不能在任意时间点的恢复数据库数据的问题。本申请另外提供一种用于恢复数据库数据的方法、一种用于备份数据库数据的装置、一种用于恢复数据库数据的装置、电子设备以及一种计算机可读介质。
本申请提供的一种用于备份数据库数据的方法,其包括:
创建持久化增量文件;
接收写命令,将所述写命令写入到所述持久化增量文件中;
在所述持久化增量文件中添加时间戳。
可选的,所述创建所述持久化增量文件,包括将所述持久化增量文件的文件名记录到持久化增量索引文件中。
可选的,所述创建所述持久化增量文件,还包括为所述持久化增量文件添加增量文件容量属性,所述增量文件容量属性用于表示所述持久化增量文件的最大数据长度。
可选的,还包括:根据设定的方式切分持久化增量文件。
可选的,所述根据设定的方式切分持久化增量文件,具体为按照设置的时间频率切分持久化增量文件。
可选的,所述根据设定的方式切分持久化增量文件,包括:
根据所述设置的时间频率判断是否切分持久化增量文件;
若不切分,继续接收写命令,并将所述写命令写入到所述持久化增量文件;若切分,则检查所述持久化增量文件大小是否超过所述增量文件容量属性;
若不超过,继续将写命令写入所述持久化增量文件;若超过,关闭所述持久化增量文件,并创建新持久化增量文件。
可选的,所述根据设定的方式切分持久化增量文件还包括,维护所述持久化增量索引文件。
可选的,所述维护所述持久化增量索引文件,包括:清除增量文件和强制切分增量文件。
可选的,所述清除增量文件,具体为在所述持久化增量索引文件中删除指定持久化增量文件前的所有持久化增量文件,包括:
接收所述清除增量文件命令;
根据所述清除增量文件命令中的增量文件参数,在所述持久化增量索引文件中删除指定持久化增量文件前的所有持久化增量文件。
可选的,在所述持久化增量文件中添加时间戳,包括:
写入所述写命令时,为每一写命令添加时间戳;
或
根据设置的时间频率,在所述持久化增量文件中为写命令添加时间戳。
可选的,包括:将生成的持久化增量文件及已有的数据库全量文件合并,生成新数据库全量文件。
可选的,所述生成新数据库全量文件还包括,
将所述新数据库全量文件与对应的持久化增量文件偏移记录到全量索引文件中。
可选的,根据预设条件,将生成的持久化增量文件及已有的数据库全量文件合并,生成新数据库全量文件;所述预设条件根据持久化增量文件的增长量参数决定。
可选的,根据预设条件,将生成的持久化增量文件及已有的数据库全量文件合并,生成新数据库全量文件具体为:
在持久化增量文件在内存中增长量超过所述预设增长量参数,且与当前数据库全量文件内存占用大小的比值大于预设的内存占有百分率时,将生成的持久化增量文件及已有的数据库全量文件合并,生成新数据库全量文件。
可选的,根据预设的备份全量文件参数,控制定期生成新数据库全量文件。
本申请还提供一种用于恢复数据库数据的方法,其包括:
获取目标时间戳,确定待恢复的时间点;
根据所述待恢复的时间点,获取对应的数据库全量文件和持久化增量文件列表;
依据所述对应的数据库全量文件和持久化增量文件列表,恢复数据库数据到所述待恢复的时间点。
可选的,所述获取目标时间戳,确定待恢复的时间点具体为:
通过配置文件获取目标时间戳,确定待恢复的时间点。
可选的,所述根据所述待恢复的时间点,获取对应的数据库全量文件和持久化增量文件列表包括,
解析全量索引文件及持久化增量索引文件,由所述全量索引文件及持久化增量索引文件中确定对应的数据库全量文件和持久化增量文件列表;其中所述全量索引文件用于记录不同版本的数据库全量文件和对应持久化增量列表的关系。
可选的,所述依据所述对应的数据库全量文件和持久化增量文件列表,恢复数据库数据到所述待恢复的时间点包括:
根据所述全量索引文件中确定的所述待恢复的时间点对应的数据库全量文件,并加载所述全量文件;
根据所述持久化增量文件列表,按时间先后顺序加载持久化增量文件;
针对加载的持久化增量文件,判断是否包含所述时间戳对应的待恢复时间点,若包含则停止载入后续的持久化增量文件;
若不包含,则加载整个所述持久化增量文件,并继续加载下一个持久化增量文件,直至加载的持久化增量文件包含所述时间戳对应的待恢复时间点为止。
此外,本申请还提供一种用于备份数据库数据的装置,其包括:
创建单元,用于创建持久化增量文件;
写入单元,用于接收写命令,将所述写命令写入到所述持久化增量文件中;
添加时间戳单元,用于在所述持久化增量文件中添加时间戳。
此外,本申请还提供一种用于恢复数据库数据的装置,其包括:
获取时间戳单元,用于获取目标时间戳,确定待恢复的时间点;
获取数据单元,用于根据所述待恢复的时间点,获取对应的数据库全量文件和持久化增量文件列表;
恢复数据单元,用于依据所述对应的数据库全量文件和持久化增量文件列表,恢复数据库数据到所述待恢复的时间点。
此外,本申请还提供一种电子设备,其包括:处理器和存储器,
所述存储器用于存储计算机可执行指令,所述处理器用于执行所述计算机可执行指令:
创建持久化增量文件;
接收写命令,记录所述写命令到所述持久化增量文件中;
在所述持久化增量文件中添加时间戳。
此外,本申请还提供一种计算机可读介质,其上存储有指令,所述指令被执行以用于:
创建持久化增量文件;
接收写命令,记录所述写命令到所述持久化增量文件中;
在所述持久化增量文件中添加时间戳。
此外,本申请还提供一种电子设备,其包括:处理器和存储器,
所述存储器用于存储计算机可执行指令,所述处理器用于执行所述计算机可执行指令:
获取目标时间戳,确定待恢复的时间点;
根据所述待恢复的时间点,获取对应的数据库全量文件和持久化增量文件列表;
依据所述对应的数据库全量文件和持久化增量文件列表,恢复数据库数据到所述待恢复的时间点。
此外,本申请还提供一种计算机可读介质,其上存储有指令,所述指令被执行以用于:获取目标时间戳,确定待恢复的时间点;
根据所述待恢复的时间点,获取对应的数据库全量文件和持久化增量文件列表;
依据所述对应的数据库全量文件和持久化增量文件列表,恢复数据库数据到所述待恢复的时间点。
与现有技术相比,本申请具有以下优点:通过创建持久化增量文件,并将对数据库操作的写命令写入持久化增量文件,在所述增量文件中添加时间戳。添加时间戳的方式可以是针对每一写命令添加,也可以按照设定的频率在数个写命令后添加时间戳。通过添加时间戳,可以记录对数据库操作的操作日志。配合全量备份文件,可以依据添加的时间戳将数据库恢复到相应的时间。特别是对Redis这类非关系型键值(key/value)存储数据库,本申请的持久化方法可实现对数据库数据在任意时间点的恢复,通过拉取增量日志及对应的全量备份文件来实现将Redis的数据库状态恢复到指定时间点。
此外,根据对数据库增量文件的切分和按预设方式打入时间戳,可减轻对数据库性能和磁盘空间的消耗。
附图说明
图1是本申请第一实施例提供的一种用于备份数据库数据的方法流程图。
图2是本申请第一实施例提供的一种切分持久化增量文件的方法流程图。
图3是本申请第二实施例提供的一种用于恢复数据库数据的方法流程图。
图4是本申请第二实施例提供的恢复数据库数据过程的流程图。
图5是本申请第三实施例提供的一种用于备份数据库数据的装置示意图。
图6是本申请第四实施例提供的一种用于恢复数据库数据的装置示意图。
图7为对持久化增量文件合并持续生成数据块全量文件的示意图。
具体实施方式
在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施,本领域技术人员可以在不违背本申请内涵的情况下做类似推广,因此本申请不受下面公开的具体实施的限制。
请参考图1,其为本申请第一实施例提供的一种用于备份数据的库数据方法流程图。
以下详细说明本申请实施例的方法在Redis这类非关系型键值(key/value)存储数据库的实现方式,Redis为开源数据库,本申请实施例的方法在Redis数据库上能够达到较佳的实施效果。需要说明的是,本申请实施例的方法可以应用于与Redis结构和原理相类似的其他数据库中,这里不做具体限定。
步骤S101:创建持久化增量文件。
数据库在实际使用中需要提供备份和恢复数据的方法,用以防止数据损坏等情况导致的数据丢失和数据出错。数据库实例同时会被大量请求访问,需要一段时间间隔对该数据库实例进行一次备份,持久化增量文件为对应记录这段时间内访问请求的具体情况的文件。
数据损坏,即数据无法恢复。写到磁盘上的数据可能由于各种原因而被损坏,导致无法恢复。例如,一次写请求会进行两次不同的写操作,当意外发生时,可能会导致一次写操作安全完成,但是另一次还没有进行。如果数据库的数据文件结构组织不合理,可能就会导致数据完全不能恢复的状况出现。所以,数据库不进行已有数据的修改,只是以追加方式去完成写操作,这样就会避免出现数据无法恢复的情况。所谓持久化狭义上是指将数据存放到断电后数据不会丢失的设备中,例如我们通常理解的硬盘中。
Redis数据库的持久化有两种方式:RDB持久化和AFO持久化。RDB持久化,是指将数据库的快照以二进制的方式保存到磁盘。具体而言,执行BGSAVE命令后,Redis会在内存中fork一个子进程,子进程会复制Redis父进程的内存空间,此时相当于Redis拥有了一个在内存中的数据快照,子进程将复制的内存空间中对应的key/value对dump到持久化的数据文件中,将该文件改成为RDB文件,当该dump操作完成时,RDB持久化过程完成。
AOF持久化,是指将所有写入命令及相关参数以协议文本的方式写入文件并持久保存磁盘。具体而言,Redis在运行过程中开启AOF持久化功能,同样会fork一个子进程,用和dump RDB文件类似的方式dump出一个AOF文件,此外,Redis会将后续的写更新操作都追加记录在该AOF文件中,当AOF文件增长到一定的大小时,会基于AOF重写策略重新执行一次fork子进程,dump AOF文件的流程,给现有的AOF文件做一次“瘦身”。
本申请实施例所述的所述创建所述持久化增量文件,还包括将所述持久化增量文件的文件名记录到持久化增量索引文件中。具体而言,开启一个数据库实例,创建持久化增量索引文件,同时创建一个持久化增量文件,将所述持久化增量文件文件名记录到持久化增量索引文件中。例如,Redis启动时会创建aof_inc.index文件,用于记录AOF文件列表,然后创建新的AOF文件并在AOF的index文件中记录。
本申请实施例所述的所述创建所述持久化增量文件,还包括为所述持久化增量文件添加增量文件容量属性,所述增量文件容量属性表示所述持久化增量文件的最大数据长度,该属性用于持久化增量文件的切分中。例如,在Redis中为AOF文件添加如下配置:参数名:aof_max_size;值:500mb;解释:单个AOF文件的最大数据长度。
所述持久化增量文件用来记录对数据库实例的访问请求情况,即对数据库实例进行的写操作。
步骤S102:接收写命令,将所述写命令写入所述持久化增量文件中。
当有新的写命令对数据库进行访问时,数据库会在当前的持久化增量文件中记录写命令。例如,当客户端有新的写命令到来时,Redis会在当前AOF文件中记录写命令。写命令具体是对数据库进行更改的命令,以二进制的形式存在内存中的持久化增量文件中。本实施例中,任何对数据库操作引起数据库改变的命令都可以称为本实施例的写命令。具体可以包括:创建数据库命令、删除数据库命令、创建数据表命令、删除数据表命令、添加数据表属性命令、修改数据表属性命令、删除数据表属性命令、增加数据命令、更改数据命令、删除数据命令等,这里不再一一列举。
单个数据库实例支持十几万或更多的QPS(Query per second,每秒查询量)。对持久化增量文件进行切分,可便于数据备份和恢复。故本实施例中,可以通过设定的方式对持久化增量文件进行切分。请参考图2,其为本申请第一实施例提供的一种切分持久化增量文件的方法的流程图。
如上所述,可以根据设定的切分方式切分持久化增量文件,其中本实施例中所述切分方式具体为按照设置的时间频率切分持久化增量文件。切分所述持久化增量文件的方法,具体包括:
步骤S102-1,针对创建的持久化增量文件,根据设置的时间频率判断是否切分持久化增量文件;
若不切分,则返回步骤S102,继续接收写命令,将所述写命令写入到所述持久化增量文件中;
若切分,执行步骤S102-2,检查所述持久化增量文件大小是否超过所述增量文件容量属性;
若不超过,则返回步骤S102,继续接收写命令,将所述写命令写入到所述持久化增量文件中;
若超过,关闭所述持久化增量文件,并返回步骤S102,创建新持久化增量文件,并将所述持久化增量文件文件名记录到所述持久化增量索引文件中,记录新写命令到所述新持久化增量文件中。
具体而言,当Redis数据库实例中的时间事件触发时,会去检查是否需要执行切分持久化增量文件(例如,serverCron()函数,serverCron()函数是Redis中非常重要的一个函数,所有和定期执行相关的任务都在该函数中实现,其本身是作为Redis的时间事件来触发执行的,执行的时间粒度是由Redis的频率参数决定,频率参数表示每秒执行的频率;在serverCron()中实现定量切分AOF的任务);若不需要执行,则继续等待写命令到来,并执行写命令,记录到AOF文件;若需要,则执行切分AOF的操作:检查当前AOF文件大小是否超过量文件容量属性(例如,aof-max-size属性);如超过,则关闭当前AOF文件,创建新的AOF文件并记录到AOF的index文件中,新的写命令写入新创建的AOF文件;如没有超过,则继续写入当前AOF文件。
在对数据库进行写操作的过程中,循环执行上述的步骤,生成不超过设定大小的多个按照时间顺序记录的持久化增量文件,每一持久化增量文件均为设定时间段内对数据库操作的操作日志。
所述切分持久化增量文件时还需维护所述持久化增量索引文件,维护所述持久化增量索引文件的方法,包括清除增量文件列表和强制切分增量文件。
其中,所述清除增量文件,具体为在所述持久化增量索引文件中删除指定持久化增量文件前的所有持久化增量文件,包括:接收所述清除增量文件命令;根据所述清除增量文件命令中的增量文件参数,在所述持久化增量索引文件中删除指定持久化增量文件前的所有持久化增量文件;若删除成功,返回删除持久化增量文件数量;若删除失败,返回错误信息。也就是说,为减轻内存负担,需要定期清理持久化增量文件。例如,例如通过如下命令实现所述清理:命令名:purgeaofto(清除增量文件命令);参数:AOF增量文件名;作用:删除指定AOF增量文件(包含)前的所有AOF文件;返回值:成功,返回删除的AFO增量文件的数量(success,成功删除AFO增量文件的数量:105);失败,返回错误信息(error,清除增量文件失败,失败原因:未找到指定AFO增量文件)。
根据实际需求,数据库还提供手动强制切分持久化增量文件的方法或命令。例如,命令名:aofflush(强制切分增量文件命令);作用:强制切分AFO增量文件;返回值:成功,返回成功信息(OK),失败返回错误信息(error)。
步骤S103:在所述持久化增量文件中添加时间戳。
为了实现按任意时间点恢复数据库数据,需要监控每一次对数据库进行更改的方法和命令,记录其写入数据库的时间点,时间戳即指存入该时间点的命令。
本申请的实施例中,时间戳是以Redis命令的形式存在于AOF文件中的,这是一种比较巧妙的实现方式,有如下优点:一、无需改变AOF文件本身的协议格式。因为AOF就是一个Redis原生协议格式的文件,这样可以尽量复用现有的AOF写入流程;二、Redis在做重启和基于时间点恢复时,需要解析AOF文件,保持AOF格式不变,不需要额外的AOF解析逻辑,同时也很容易兼容其他的AOF检查和回放工具。
本实施例中,所述在所述持久化增量文件中添加时间戳,包括如下方式:记录所述写命令时,直接为写命令添加时间戳;或根据配置的时间频率,在所述持久化增量文件中添加时间戳。
目前的应用环境中,单个Redis实例可以支撑十几万的QPS(Query per second,每秒查询量),如果每个写命令执行都打上操作时间戳,对性能和磁盘空间的消耗都比较大。而基于任意时间点(秒级)的数据恢复也不需要每个操作都记录时间戳,按配置的设定频率打入时间戳已经足够。例如,可以通过前述的serverCron()函数添加时间戳。
所述持久化增量文件记录对数据库结构或数据库数据更改的命令,这些命令是相对于当前或已有的数据库全量文件的增量文件,在持久化增量文件数量或者以后持久化增量文件的大小之和达到一定的阈值时,需要将持久化增量文件进行合并,并将合并后的文件整合到已有数据库全量文件中,生成新数据库全量文件;然后继续执行形成新的持久化增量文件,对持久化增量文件进行合并,再次生成更新的数据库全量文件……如图7中所示。
所述新数据库全量文件包含所述当前数据库全量文件(若存在)和持久化增量文件列表。
所述数据库全量文件即指备份的当前数据库的快照。Redis数据库是通过CronBGSAVE命令(BGSAVE命令执行之后立即返回OK,然后Redis会fork出一个新子进程,原来的Redis进程(父进程)继续处理客户端请求,而子进程则负责将数据保存到磁盘,然后退出)实现生成数据库全量文件。
在启动数据库实例时,同时会生成一个全量索引文件;生成新数据库全量文件,将所述新数据库全量文件与对应的持久化增量文件偏移记录到所述全量索引文件中。例如,启动一个Redis实例时,创建一个全量索引文件(例如,rdb.index文件),内核维护这个rdb.index文件,该文件用于记录当前的数据库全量文件(rdb文件)和AOF增量文件的对应关系;本地重启恢复该实例时需要:先载入rdb文件(Load RDB文件),然后顺序加载一个或多个AOF增量文件。
在实际设计生成数据库全量文件方法中,需要考虑几个问题:
对于小内存的实例,BGSAVE的成本比较低,如果AOF增量文件量设置过大,会导致实例重启时间过长,和用户期望不符;
对于大内存的实例,BGSAVE的成本很高,根据固定量AOF增量文件量来进行自动BGSAVE,在实例QPS很高的时候,会频繁进行BGSAVE,对系统的稳定性和用户实例的影响太大。
本实施例方法中,提供根据预设条件,自动生成新数据库全量文件;所述预设条件根据预设增长量参数决定。
具体地,当持久化增量文件在内存中增长量超过所述预设增长量参数,且与前一次生成的当前数据库全量文件内存占用大小的比大于预设的内存占有百分率时,自动生成新数据库全量文件。
例如,增加参数两个参数:预设的内存占有百分率(例如,cron-bgsave-rewrite-percentage)和预设增长量参数(例如,cron-bgsave-rewrite-min-size)用于控制定期BGSAVE的时机,手动设置cron-bgsave-rewrite-percentage为100%,cron-bgsave-rewrite-min-size为1GB,前次BGSAVE时Redis的内存使用量为X,那么只有当距上次BGSAVE之后,AOF文件数据量的增长超过X且大于1GB时候才会触发自动BGSAVE。
具体而言,当AOF文件中写命令数据量的增长满足条件时(大于cron-bgsave-rewrite-min-size且和上次BGSAVE完成时Redis内存占用大小的比大于cron-bgsave-rewrite-percentage),就会触发Cron BGSAVE方法或命令。BGSAVE会生成一个数据库全量文件(例如,dump.rdb),并把自己和AOF增量文件的对应偏移写入全量索引文件(rdb.index)文件中。
自动备份全量文件参数,控制定期生成新数据库全量文件。例如,增加一个自动备份全量文件参数(例如,auto-cron-bgsave),用于控制内核是否定期做BGSAVE,值为yes时,该开关打开。
以上即为一种用于备份数据库的一种实施例的方法,通过以上实施例的方法,即可生成可按照任意时间点恢复数据的备份数据库。
在下面的第二实施例中,提供一种用于恢复数据库数据的方法。请参考图3,其本申请第二实施例提供的一种用于恢复数据库数据的方法流程图。
以下详细说明本方法在Redis这类非关系型键值(key/value)存储数据库的实现方式,Redis为开源数据库,本方法在Redis数据库上能够达到较佳的实施效果,但本方法能够使用在与Redis结构和原理相似的其他数据库中,这里不做具体限定。
请参考图3,步骤S201:获取时间戳,得到待恢复的时间点。
数据库系统通过前述实施例的备份数据库的方法定期备份数据库全量文件(RDB文件)和持久化增量文件(AOF增量文件),服务器控制台接收指定要恢复数据库数据的命令,所述恢复数据命令包含恢复数据指令和时间戳。其中。所述时间戳通过配置文件获取。具体地,数据库开启,获取要读取的RDB文件及AOF文件列表,然后读取restore.timestamp文件获取待恢复的时间点。
所述接收的恢复数据命令也符合操作数据库命令的结构形式,前述备份数据库数据的方法实施例中对操作数据库命令(例如,写命令)结构进行了具体说明,在此不再赘述。
步骤S202:根据所述待恢复的时间点,获取对应的数据库全量文件和持久化增量文件列表。
服务器控制台接收指定要恢复数据库数据的命令后,解析所述恢复数据命令的所述时间戳;再根据所述时间戳获取对应的数据库全量文件(RDB文件)和持久化增量文件(AOF增量文件)列表,准备恢复数据。
所述数据库全量文件(RDB文件)和所述持久化增量文件(AOF增量文件)列表为前述备份数据库数据方法实施例中的文件结构,详细内容请参考前述一种用于备份数据库数据方法的实施例说明。
所述根据所述待恢复的时间点,获取对应的数据库全量文件和持久化增量文件列表步骤具体为解析全量索引文件及持久化增量索引文件,由所述全量索引文件及持久化增量索引文件中确定对应的数据库全量文件和持久化增量文件列表。其中所述全量索引文件记录不同版本的数据库全量文件和对应持久化增量列表的关系。
例如,接受接收恢复数据命令,Redis实例启动,先解析全量索引文件(rdb.index),获取要读取的数据库全量文件(RDB文件)及持久化增量文件(AOF增量文件)列表,然后读取恢复数据命令中待恢复的时间点,准备恢复数据库数据到该时间点。所述待恢复时间点可以为任意指定的时间点。
步骤S203:依据所述对应的数据库全量文件和持久化增量文件列表,恢复数据库数据到所述待恢复的时间点。
此步骤实现恢复数据库数据到所述待恢复时间点。请参考图4,其为本申请第二实施例提供的恢复数据库数据过程的流程图。具体过程如下:
步骤S203-1:在所述全量索引文件中找到对应的数据库全量文件,将所述全量文件载入内存中;具体而言,根据所述全量索引文件中确定的所述待恢复的时间点对应的数据库全量文件,并加载所述全量文件至内存或虚拟内存;
步骤S203-2:判断载入是否成功;
若成功,执行步骤S203-3:继续载入持久化增量文件到内存中,所述载入持久化增量文件到内存按时间顺序进行载入;
若失败,步骤S203-6:结束恢复数据库数据,返回失败信息。
步骤S203-4:针对加载的持久化增量文件,判断是否包含所述时间戳对应的待恢复时间点,若包含则执行步骤S203-6:停止载入;
否则,执行步骤S203-5:判断是否载入整个所述持久化增量文件;若是,步骤S203-3:载入整个所述持久化增量文件后,继续载入下一个所述持久化增量文件;若否,步骤S203-6:结束恢复数据库数据,返回失败信息。
例如,Redis在启动时,会先解析全量索引文件(rdb.index),获取要读取的RDB文件及AOF增量文件列表;Redis先载入RDB文件到内存中,如果载入成功则继续载入AOF增量文件,否则失败结束;载入AOF文件时会按时间顺序进行载入,如果正在载入的AOF文件包含要恢复的时间点则停止载入,恢复成功并结束;否则判断是否载入整个AOF文件成功;如果失败,则结束;否则继续载入下个AOF文件;如果已经没有AOF文件可以载入,则恢复失败并结束。
如上所述,上述实施例描述了通过拉取增量日志及对应的全量备份文件来实现将Redis的数据库状态恢复到待恢复时间点。
本申请同时提供了一种用于恢复数据库数据到任意时间点的装置;请参考图5,其为本申请第三实施例提供的一种用于恢复数据库数据的装置示意图。该装置与用于备份数据的库数据方法实施方式和原理一致,这里描述较简单,具体请参考对应的方法实施例。以下实施例的描述基于Redis数据库,实际实施中不对数据库进行限定。
请参考图5,本实施例的装置包括:
创建单元301,用于创建持久化增量文件。
接收单元302,用于接收写命令,将所述写命令写入到所述持久化增量文件中。
添加时间戳单元303,用于在所述持久化增量文件中添加时间戳。
以上是基于备份数据库的方法的对应装置运行方式,根据以上装置,实现按任意时间点恢复数据库数据。请参考图6,是本申请实施例提供的一种用于恢复数据库数据的装置示意图。
获取时间戳单元601,用于获取目标时间戳,确定待恢复的时间点。
获取数据单元602,用于根据所述待恢复的时间点,获取对应的数据库全量文件和持久化增量文件列表。
恢复数据单元603,用于依据所述对应的数据库全量文件和持久化增量文件列表,恢复数据库数据到所述待恢复的时间点。
本申请虽然以较佳实施例公开如上,但其并不是用来限定本申请,任何本领域技术人员在不脱离本申请的精神和范围内,都可以做出可能的变动和修改,因此本申请的保护范围应当以本申请权利要求所界定的范围为准。
此外,本申请实施例还提供一种电子设备,其包括:处理器和存储器,
所述存储器用于存储计算机可执行指令,所述处理器用于执行所述计算机可执行指令:
创建持久化增量文件;
接收写命令,记录所述写命令到所述持久化增量文件中;
在所述持久化增量文件中添加时间戳。
本申请实施例还提供一种计算机可读介质,其上存储有指令,所述指令被执行以用于:
创建持久化增量文件;
接收写命令,记录所述写命令到所述持久化增量文件中;
在所述持久化增量文件中添加时间戳。
本申请实施例还提供一种电子设备,其包括:处理器和存储器,
所述存储器用于存储计算机可执行指令,所述处理器用于执行所述计算机可执行指令:
获取目标时间戳,确定待恢复的时间点;
根据所述待恢复的时间点,获取对应的数据库全量文件和持久化增量文件列表;
依据所述对应的数据库全量文件和持久化增量文件列表,恢复数据库数据到所述待恢复的时间点。
本申请实施例还提供一种计算机可读介质,其上存储有指令,所述指令被执行以用于:获取目标时间戳,确定待恢复的时间点;
根据所述待恢复的时间点,获取对应的数据库全量文件和持久化增量文件列表;
依据所述对应的数据库全量文件和持久化增量文件列表,恢复数据库数据到所述待恢复的时间点。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括非暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
2、本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
Claims (25)
1.一种用于备份数据库数据的方法,其特征在于,包括:
创建持久化增量文件;
接收写命令,将所述写命令写入到所述持久化增量文件中;
在所述持久化增量文件中添加时间戳。
2.根据权利要求1所述的一种用于备份数据库数据的方法,其特征在于,所述创建所述持久化增量文件,包括将所述持久化增量文件的文件名记录到持久化增量索引文件中。
3.根据权利要求1所述的一种用于备份数据库数据的方法,其特征在于,所述创建所述持久化增量文件,还包括为所述持久化增量文件添加增量文件容量属性,所述增量文件容量属性用于表示所述持久化增量文件的最大数据长度。
4.根据权利要求3所述的一种用于备份数据库数据的方法,其特征在于,还包括:根据设定的方式切分持久化增量文件。
5.根据权利要求4所述的一种用于备份数据库数据的方法,其特征在于,所述根据设定的方式切分持久化增量文件,具体为按照设置的时间频率切分持久化增量文件。
6.根据权利要求5所述的一种用于备份数据库数据的方法,其特征在于,所述根据设定的方式切分持久化增量文件,包括:
根据所述设置的时间频率判断是否切分持久化增量文件;
若不切分,继续接收写命令,并将所述写命令写入到所述持久化增量文件;若切分,则检查所述持久化增量文件大小是否超过所述增量文件容量属性;
若不超过,继续将写命令写入所述持久化增量文件;若超过,关闭所述持久化增量文件,并创建新持久化增量文件。
7.根据权利要求4所述的一种用于备份数据库数据的方法,其特征在于,所述根据设定的方式切分持久化增量文件还包括,维护所述持久化增量索引文件。
8.根据权利要求7所述的一种用于备份数据库数据的方法,其特征在于,所述维护所述持久化增量索引文件,包括:清除增量文件和强制切分增量文件。
9.根据权利要求8所述的一种用于备份数据库数据的方法,其特征在于,所述清除增量文件,具体为在所述持久化增量索引文件中删除指定持久化增量文件前的所有持久化增量文件,包括:
接收所述清除增量文件命令;
根据所述清除增量文件命令中的增量文件参数,在所述持久化增量索引文件中删除指定持久化增量文件前的所有持久化增量文件。
10.根据权利要求1所述的一种用于备份数据库数据的方法,其特征在于,在所述持久化增量文件中添加时间戳,包括:
写入所述写命令时,为每一写命令添加时间戳;
或
根据设置的时间频率,在所述持久化增量文件中为写命令添加时间戳。
11.根据权利要求1所述的一种用于备份数据库数据的方法,其特征在于,包括:将生成的持久化增量文件及已有的数据库全量文件合并,生成新数据库全量文件。
12.根据权利要求11所述的一种用于备份数据库数据的方法,其特征在于,所述生成新数据库全量文件还包括,
将所述新数据库全量文件与对应的持久化增量文件偏移记录到全量索引文件中。
13.根据权利要求11或12所述的一种用于备份数据库数据的方法,其特征在于,根据预设条件,将生成的持久化增量文件及已有的数据库全量文件合并,生成新数据库全量文件;所述预设条件根据持久化增量文件的增长量参数决定。
14.根据权利要求13所述的一种用于备份数据库数据的方法,其特征在于,根据预设条件,将生成的持久化增量文件及已有的数据库全量文件合并,生成新数据库全量文件具体为:
在持久化增量文件在内存中增长量超过所述预设增长量参数,且与当前数据库全量文件内存占用大小的比值大于预设的内存占有百分率时,将生成的持久化增量文件及已有的数据库全量文件合并,生成新数据库全量文件。
15.根据权利要求11所述的一种用于备份数据库数据的方法,其特征在于,根据预设的备份全量文件参数,控制定期生成新数据库全量文件。
16.一种用于恢复数据库数据的方法,其特征在于,包括:
获取目标时间戳,确定待恢复的时间点;
根据所述待恢复的时间点,获取对应的数据库全量文件和持久化增量文件列表;
依据所述对应的数据库全量文件和持久化增量文件列表,恢复数据库数据到所述待恢复的时间点。
17.根据权利要求16所述的一种用于恢复数据库数据的方法,其特征在于,所述获取目标时间戳,确定待恢复的时间点具体为:
通过配置文件获取目标时间戳,确定待恢复的时间点。
18.根据权利要求16所述的一种用于恢复数据库数据的方法,其特征在于,所述根据所述待恢复的时间点,获取对应的数据库全量文件和持久化增量文件列表包括,
解析全量索引文件及持久化增量索引文件,由所述全量索引文件及持久化增量索引文件中确定对应的数据库全量文件和持久化增量文件列表;其中所述全量索引文件用于记录不同版本的数据库全量文件和对应持久化增量列表的关系。
19.根据权利要求18所述的一种用于恢复数据库数据的方法,其特征在于,所述依据所述对应的数据库全量文件和持久化增量文件列表,恢复数据库数据到所述待恢复的时间点包括:
根据所述全量索引文件中确定的所述待恢复的时间点对应的数据库全量文件,并加载所述全量文件;
根据所述持久化增量文件列表,按时间先后顺序加载持久化增量文件;
针对加载的持久化增量文件,判断是否包含所述时间戳对应的待恢复时间点,若包含则停止载入后续的持久化增量文件;
若不包含,则加载整个所述持久化增量文件,并继续加载下一个持久化增量文件,直至加载的持久化增量文件包含所述时间戳对应的待恢复时间点为止。
20.一种用于备份数据库数据的装置,其特征在于,包括:
创建单元,用于创建持久化增量文件;
写入单元,用于接收写命令,将所述写命令写入到所述持久化增量文件中;
添加时间戳单元,用于在所述持久化增量文件中添加时间戳。
21.一种用于恢复数据库数据的装置,其特征在于,包括:
获取时间戳单元,用于获取目标时间戳,确定待恢复的时间点;
获取数据单元,用于根据所述待恢复的时间点,获取对应的数据库全量文件和持久化增量文件列表;
恢复数据单元,用于依据所述对应的数据库全量文件和持久化增量文件列表,恢复数据库数据到所述待恢复的时间点。
22.一种电子设备,其特征在于包括:处理器和存储器,
所述存储器用于存储计算机可执行指令,所述处理器用于执行所述计算机可执行指令:
创建持久化增量文件;
接收写命令,记录所述写命令到所述持久化增量文件中;
在所述持久化增量文件中添加时间戳。
23.一种计算机可读介质,其特征在于,其上存储有指令,所述指令被执行以用于:
创建持久化增量文件;
接收写命令,记录所述写命令到所述持久化增量文件中;
在所述持久化增量文件中添加时间戳。
24.一种电子设备,其特征在于包括:处理器和存储器,
所述存储器用于存储计算机可执行指令,所述处理器用于执行所述计算机可执行指令:
获取目标时间戳,确定待恢复的时间点;
根据所述待恢复的时间点,获取对应的数据库全量文件和持久化增量文件列表;
依据所述对应的数据库全量文件和持久化增量文件列表,恢复数据库数据到所述待恢复的时间点。
25.一种计算机可读介质,其特征在于,其上存储有指令,所述指令被执行以用于:获取目标时间戳,确定待恢复的时间点;
根据所述待恢复的时间点,获取对应的数据库全量文件和持久化增量文件列表;
依据所述对应的数据库全量文件和持久化增量文件列表,恢复数据库数据到所述待恢复的时间点。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710722908.7A CN109426585A (zh) | 2017-08-22 | 2017-08-22 | 一种备份、恢复数据库数据的方法和装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710722908.7A CN109426585A (zh) | 2017-08-22 | 2017-08-22 | 一种备份、恢复数据库数据的方法和装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN109426585A true CN109426585A (zh) | 2019-03-05 |
Family
ID=65498738
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710722908.7A Pending CN109426585A (zh) | 2017-08-22 | 2017-08-22 | 一种备份、恢复数据库数据的方法和装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109426585A (zh) |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109933632A (zh) * | 2019-04-04 | 2019-06-25 | 杭州数梦工场科技有限公司 | 一种数据库的数据迁移方法、装置及设备 |
CN111159313A (zh) * | 2019-12-31 | 2020-05-15 | 广州鼎甲计算机科技有限公司 | 一种数据库快速合成备份方法、系统、装置及存储介质 |
CN111290882A (zh) * | 2020-02-11 | 2020-06-16 | 北京松果电子有限公司 | 数据文件备份方法、数据文件备份装置及电子设备 |
CN111752913A (zh) * | 2019-03-28 | 2020-10-09 | 阿里巴巴集团控股有限公司 | 分布式系统的数据恢复方法、介质、计算机设备、装置 |
CN111813758A (zh) * | 2020-07-02 | 2020-10-23 | 深圳乐信软件技术有限公司 | 数据库文件分布式分析方法、装置、服务器及存储介质 |
CN111949439A (zh) * | 2019-05-17 | 2020-11-17 | 中国移动通信集团河南有限公司 | 基于数据库的数据文件更新方法和装置 |
CN112114999A (zh) * | 2020-09-01 | 2020-12-22 | 阿里云计算有限公司 | 一种数据备份方法、数据恢复方法、装置及电子设备 |
CN112486732A (zh) * | 2020-12-02 | 2021-03-12 | 北京金山云网络技术有限公司 | 基于Redis的数据恢复方法、装置、设备及介质 |
CN112685230A (zh) * | 2021-01-05 | 2021-04-20 | 浪潮云信息技术股份公司 | 一种分布式数据库实现指定时间点备份还原的方法 |
CN113032349A (zh) * | 2019-12-25 | 2021-06-25 | 阿里巴巴集团控股有限公司 | 数据存储方法、装置、电子设备及计算机可读介质 |
CN113419896A (zh) * | 2020-07-24 | 2021-09-21 | 阿里巴巴集团控股有限公司 | 数据恢复方法、装置、电子设备及计算机可读介质 |
CN113568715A (zh) * | 2021-09-28 | 2021-10-29 | 武汉四通信息服务有限公司 | 数据处理方法、装置及电子设备 |
CN114416426A (zh) * | 2021-12-17 | 2022-04-29 | 阿里巴巴(中国)有限公司 | 进程拷贝方法以及装置 |
CN117435403A (zh) * | 2023-12-21 | 2024-01-23 | 成都云祺科技有限公司 | 永久增备中处理索引合并方法、系统及无效数据处理方法 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101326496A (zh) * | 2005-12-07 | 2008-12-17 | 国际商业机器公司 | 持续保护数据的装置、系统和方法 |
CN101739313A (zh) * | 2009-11-27 | 2010-06-16 | 华中科技大学 | 一种连续数据保护和恢复方法 |
CN102142024A (zh) * | 2010-02-01 | 2011-08-03 | 微软公司 | 在分布式数据库中使用递增捕捉来进行逻辑数据备份和回退 |
US20110191533A1 (en) * | 2010-02-02 | 2011-08-04 | Legal Digital Services | Digital forensic acquisition kit and methods of use thereof |
CN105989160A (zh) * | 2015-03-03 | 2016-10-05 | 大唐软件技术股份有限公司 | 一种针对Redis数据库的内存数据持久化方法和装置 |
-
2017
- 2017-08-22 CN CN201710722908.7A patent/CN109426585A/zh active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101326496A (zh) * | 2005-12-07 | 2008-12-17 | 国际商业机器公司 | 持续保护数据的装置、系统和方法 |
CN101739313A (zh) * | 2009-11-27 | 2010-06-16 | 华中科技大学 | 一种连续数据保护和恢复方法 |
CN102142024A (zh) * | 2010-02-01 | 2011-08-03 | 微软公司 | 在分布式数据库中使用递增捕捉来进行逻辑数据备份和回退 |
US20110191533A1 (en) * | 2010-02-02 | 2011-08-04 | Legal Digital Services | Digital forensic acquisition kit and methods of use thereof |
CN105989160A (zh) * | 2015-03-03 | 2016-10-05 | 大唐软件技术股份有限公司 | 一种针对Redis数据库的内存数据持久化方法和装置 |
Cited By (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111752913B (zh) * | 2019-03-28 | 2024-03-01 | 阿里云计算有限公司 | 分布式系统的数据恢复方法、介质、计算机设备、装置 |
CN111752913A (zh) * | 2019-03-28 | 2020-10-09 | 阿里巴巴集团控股有限公司 | 分布式系统的数据恢复方法、介质、计算机设备、装置 |
CN109933632B (zh) * | 2019-04-04 | 2021-04-27 | 杭州数梦工场科技有限公司 | 一种数据库的数据迁移方法、装置及设备 |
CN109933632A (zh) * | 2019-04-04 | 2019-06-25 | 杭州数梦工场科技有限公司 | 一种数据库的数据迁移方法、装置及设备 |
CN111949439B (zh) * | 2019-05-17 | 2023-08-01 | 中国移动通信集团河南有限公司 | 基于数据库的数据文件更新方法和装置 |
CN111949439A (zh) * | 2019-05-17 | 2020-11-17 | 中国移动通信集团河南有限公司 | 基于数据库的数据文件更新方法和装置 |
CN113032349A (zh) * | 2019-12-25 | 2021-06-25 | 阿里巴巴集团控股有限公司 | 数据存储方法、装置、电子设备及计算机可读介质 |
CN111159313B (zh) * | 2019-12-31 | 2020-11-13 | 广州鼎甲计算机科技有限公司 | 一种数据库快速合成备份方法、系统、装置及存储介质 |
CN111159313A (zh) * | 2019-12-31 | 2020-05-15 | 广州鼎甲计算机科技有限公司 | 一种数据库快速合成备份方法、系统、装置及存储介质 |
CN111290882A (zh) * | 2020-02-11 | 2020-06-16 | 北京松果电子有限公司 | 数据文件备份方法、数据文件备份装置及电子设备 |
CN111290882B (zh) * | 2020-02-11 | 2024-02-09 | 北京小米松果电子有限公司 | 数据文件备份方法、数据文件备份装置及电子设备 |
CN111813758A (zh) * | 2020-07-02 | 2020-10-23 | 深圳乐信软件技术有限公司 | 数据库文件分布式分析方法、装置、服务器及存储介质 |
CN113419896A (zh) * | 2020-07-24 | 2021-09-21 | 阿里巴巴集团控股有限公司 | 数据恢复方法、装置、电子设备及计算机可读介质 |
CN113419896B (zh) * | 2020-07-24 | 2023-12-22 | 阿里巴巴集团控股有限公司 | 数据恢复方法、装置、电子设备及计算机可读介质 |
WO2022048495A1 (zh) * | 2020-09-01 | 2022-03-10 | 阿里云计算有限公司 | 一种数据备份方法、数据恢复方法、装置及电子设备 |
CN112114999A (zh) * | 2020-09-01 | 2020-12-22 | 阿里云计算有限公司 | 一种数据备份方法、数据恢复方法、装置及电子设备 |
CN112486732A (zh) * | 2020-12-02 | 2021-03-12 | 北京金山云网络技术有限公司 | 基于Redis的数据恢复方法、装置、设备及介质 |
CN112685230B (zh) * | 2021-01-05 | 2022-03-15 | 浪潮云信息技术股份公司 | 一种分布式数据库实现指定时间点备份还原的方法 |
CN112685230A (zh) * | 2021-01-05 | 2021-04-20 | 浪潮云信息技术股份公司 | 一种分布式数据库实现指定时间点备份还原的方法 |
CN113568715A (zh) * | 2021-09-28 | 2021-10-29 | 武汉四通信息服务有限公司 | 数据处理方法、装置及电子设备 |
CN114416426A (zh) * | 2021-12-17 | 2022-04-29 | 阿里巴巴(中国)有限公司 | 进程拷贝方法以及装置 |
CN117435403A (zh) * | 2023-12-21 | 2024-01-23 | 成都云祺科技有限公司 | 永久增备中处理索引合并方法、系统及无效数据处理方法 |
CN117435403B (zh) * | 2023-12-21 | 2024-03-12 | 成都云祺科技有限公司 | 永久增备中处理索引合并方法、系统及无效数据处理方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109426585A (zh) | 一种备份、恢复数据库数据的方法和装置 | |
US11531484B1 (en) | Distributed dataset modification, retention, and replication | |
US9703640B2 (en) | Method and system of performing incremental SQL server database backups | |
US10942814B2 (en) | Method for discovering database backups for a centralized backup system | |
US9904603B2 (en) | Successive data fingerprinting for copy accuracy assurance | |
US9798629B1 (en) | Predicting backup failures due to exceeding the backup window | |
US11093387B1 (en) | Garbage collection based on transmission object models | |
US9304998B2 (en) | Main-memory database checkpointing | |
US8856080B2 (en) | Backup using metadata virtual hard drive and differential virtual hard drive | |
CN108804253B (zh) | 一种用于海量数据备份的并行作业备份方法 | |
US20090319582A1 (en) | Database snapshot management | |
US11003364B2 (en) | Write-once read-many compliant data storage cluster | |
US10628298B1 (en) | Resumable garbage collection | |
EP2590078A2 (en) | Shadow paging based log segment directory | |
US20190370377A1 (en) | Change management for shared objects in multi-tenancy systems | |
US11176004B2 (en) | Test continuous log replay | |
US7085962B1 (en) | Method and system for completing a backup job that was interrupted during a backup process | |
US20220121527A1 (en) | Dynamically updating database archive log dependency and backup copy recoverability | |
CN112463450A (zh) | 一种增量备份管理方法、系统、电子设备及存储介质 | |
US11500812B2 (en) | Intermediate file processing method, client, server, and system | |
Ouaknine et al. | Optimization of rocksdb for redis on flash | |
US11042454B1 (en) | Restoration of a data source | |
US11966297B2 (en) | Identifying database archive log dependency and backup copy recoverability | |
US20130117221A1 (en) | Moving Data Within A Distributed Data Storage System Using Virtual File Links | |
US11023434B2 (en) | No rollback threshold for audit trail |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20190305 |
|
RJ01 | Rejection of invention patent application after publication |