CN108062358A - innodb引擎删除记录的离线恢复方法、存储介质 - Google Patents
innodb引擎删除记录的离线恢复方法、存储介质 Download PDFInfo
- Publication number
- CN108062358A CN108062358A CN201711213512.6A CN201711213512A CN108062358A CN 108062358 A CN108062358 A CN 108062358A CN 201711213512 A CN201711213512 A CN 201711213512A CN 108062358 A CN108062358 A CN 108062358A
- Authority
- CN
- China
- Prior art keywords
- record
- deletion
- offset address
- recording mechanism
- page
- 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.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2228—Indexing structures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
Abstract
本发明提供一种innodb存储引擎删除记录的离线恢复方法、存储介质,方法包括依据表空间文件的数据字典信息获取索引页的根节点页号;从所述根节点页号开始,遍历每个节点;通过遍历每个节点对应索引页的正常记录链表以及删除记录链表中的每条记录,依据每条记录的偏移地址和记录号,以及当前索引页内所有的记录数,获取未维护删除记录对应的记录号以及偏移地址范围;依据未维护删除记录的记录号,从对应的偏移地址范围中解析得到与所述未维护删除记录的记录号一致的记录。能够实现基于innodb索引页结构、记录结构以及字段特征实现全面、准确地恢复出系统未维护的删除记录的准确恢复。
Description
技术领域
本发明涉及数据库数据处理领域,具体说的一种innodb存储引擎删除记录的恢复方法以及对应的计算机可读存储介质。
背景技术
Mysql数据库是当前最流行数据库之一,而innodb作为mysql最常用的存储引擎,其删除记录的恢复在信息安全领域一直是备受关注的热点。
目前已有一些innodb恢复的技术资料及恢复软件,这些技术基本都是基于日志和备份数据库的在线手动恢复或者基于页结构离线重组文件的恢复,而对于页结构内部被删除的记录恢复却相对缺乏。其中,基于日志和备份数据库的方法需有及时备份数据库且服务运行正常,对于没有及时备份,或相关文件损坏严重服务无法正常运行的情况该方法不可行。而基于页结构的离线恢复方法是针对索引页的结构提取数据页恢复记录,这种方法对于页内部被删除记录无法恢复,或者恢复误判概率高。
因此,有必要提供一种有别于上述恢复方式,同时更全面准确地恢复出被删除记录的方法。
本文提出一种页结构,记录结构及字段特征结合的方法,更全面恢复出被删除数据。
发明内容
本发明所要解决的技术问题是:本发明提供一种innodb存储引擎删除记录的离线恢复方法、存储介质,基于innodb索引页结构、记录结构以及字段特征实现全面、准确地恢复出被删除的记录。
为了解决上述技术问题,本发明采用的技术方案为:
一种innodb存储引擎删除记录的离线恢复方法,包括:
依据表空间文件的数据字典信息获取索引页的根节点页号;
从所述根节点页号开始,遍历每个节点;
通过遍历每个节点对应索引页的正常记录链表以及删除记录链表中的每条记录,依据每条记录的偏移地址和记录号,以及当前索引页内所有的记录数,获取未维护删除记录对应的记录号以及偏移地址范围;
依据未维护删除记录的记录号,从对应的偏移地址范围中解析得到与所述未维护删除记录的记录号一致的记录。
本发明提供的另一个技术方案为:
一种计算机可读存储介质,其内存储有计算机程序,该程序被处理器执行时实现上述方法。
本发明的有益效果在于:本发明能够基于innodb索引页结构、记录结构以及字段特征实现全面、准确地恢复出系统未维护(没有保存在删除链表中)的删除记录的准确恢复。为计算机数据取证安全领域作出巨大贡献。
附图说明
图1为本发明索引页结构;
图2为本发明索引页的B+树结构;
图3为本发明索引页为Compact行记录的格式组成;
图4为本发明索引页为Redundant行记录的格式组成;
图5为本发明一种innodb存储引擎删除记录的离线恢复方法的流程示意图;
图6为本发明实施例一的删除记录恢复流程示意图;
图7为图6中的步骤6)解析系统未维护删除记录的具体流程示意图。
具体实施方式
为详细说明本发明的技术内容、所实现目的及效果,以下结合实施方式并配合附图予以说明。
本发明最关键的构思在于:基于innodb索引页结构、记录结构以及字段特征实现全面、准确地恢复出系统未维护(没有保存在删除链表中)的删除记录的准确恢复。
为了更好的理解本文,下面就innodb存储引擎的存储结构进行说明:
一、整体结构
Innodb存储引擎在磁盘上由表空间文件(ibdata文件)、日志文件以及表结构定义文件(frm文件)组成。
依据引擎版本的不同,其表空间文件具有两种不同的生成形式:
1、对应现有的高版本的引擎(5.1以上版本),系统将会为每个表自动生成单独的表空间文件。如在数据库testdb创建一个表testtable,则在testdb目录下生成表结构定义文件testtable.frm和单独的表空间文件testtable.ibd。
2、对应前期较低版本的引擎,其表空间文件默认为共享空间文件。只要通过在系统配置文件my.ini(Windows)或my.cnf(Linux)中设置innodb_file_per_table=1,系统才会为每一个表生成单独的表空间文件(ibd文件)。
二、组成表空间文件的页
表空间文件由页组成,每个页默认大小为16KB,页结构由38字节页头部(PAGE_HEADER)和页数据组成。如下表1所示,为页头部的结构;页根据功能划分成多种不同的类型,页类型记录在页头部中。其中,索引页即记录数据页,在恢复过程中尤为重要。
表1
三、索引页
innodb存储引擎支持B+树索引,所有的索引页通过B+树关联。假设R1,R2R3,...,Rn为索引页的记录列表,则B+树结构如图2所示。其中的非叶子节点(存在下一级节点的节点)记录了索引信息,每条记录的最后一个字段指向下一级页;B+树的所有非叶子节点为组成一个索引段。叶子节点(不存在下一级节点的节点)记录了所有数据,所有叶子节点组成一个数据段。
如图1所示,索引页的组成结构包括5个部分:38字节的页头部、36字节的索引页头部(其结构如下表2所示)、20字节段信息、2条系统记录及用户记录列表。所有记录在物理上顺序存储,系统记录分别为infimum(上确界)记录号为0和supremum(下确界)记录号为1,用户记录则从记录号为2开始顺序记录。记录在逻辑结构上用链表的方式链接起来。
表2
四、索引页的记录格式
innodb存储引擎中主要有两种行记录格式,分别为Compact和Redundant。通过索引页头部中的页内所有记录数(PAGE_N_HEAP)确定页的记录格式;如表2的索引页头部中PAGE_N_HEAP的第一位设置为1时,则表示page为compact格式。
4.1、Compact格式
Compact格式如图3所示。变长字段长度列表中以逆序的方式记录列数据中可变长度字段的长度信息,NULL标志位记录对应列是否为NULL,记录头信息位固定5字节,其记录头信息中每个位的含义如下表3。
表3
4.2、Redundant格式
Redundant格式如图4所示。字段长度列表中以逆序的方式记录列数据中所有字段的长度信息,记录头信息位固定6字节,其记录头信息中每个位的含义如下表4所示。
表4
需要说明的是,当前较高版本的innodb存储引擎默认都采用Compact格式格式存储。版本较低的innodb存储引擎默认采用Redundant格式存储。
本申请的innodb存储引擎删除记录的离线恢复的原理说明
(1)innodb的索引页中维护两条链表:正常记录链表和删除记录链表。
当删除一条记录,会把该记录从正常记录链表中删除,放置到删除链表当中,并没有被擦除,依然保留在文件中。但是实际测试发现删除链表仅仅维护最新被删除的几条记录,更多删除记录没有在这两条链表当中。
由于所有的记录在页内是以记录号从小到大依次排序的,因此可以根据记录号(Compact格式对应判断REC_NEW_HEAP_NO/Redundant格式对应判断REC_OLD_HEAP_NO)是否匹配(是否等于需要恢复的记录号);slot所拥有记录数(REC_NEW_N_OWNED/REC_OLD_N_OWNED)是否正确(是否等于0或者大于等于4且小于等于8正确,其他值错误);若为Compact格式,则还可以同时判断记录状态(REC_NEW_STATUS)是否正确(叶子节点记录值为0或非叶子节点记录值为1正确,其他值错误);若为Redundant格式,则可判断字段长度是否正确(如int类型字段长度为4字节,读取长度不为4则错误。长度同理tinyint字段长度为1,samllint字段长度为2,mediumint字段长度为3,float字段长度为4,bigint,double为8字节等)等记录结构的一些特性遍历数据内容即可恢复出被删除且没有保存在删除链表中的数据。
例如:假设RS={R1,R2R3,...,Rn}表示一个索引页内的所有记录列表。那么,这些记录在索引页内部按照记录号(HEAP NO)以0开始从小到大依次排序。假设记录R3是一条删除记录,且R3没有在系统维护的删除记录链表中,即可认为在R2和R4之间还存在一条删除记录且记录号为3;记录R3的范围:起始位置为R2结束位置设为start_off,结束位置为R4的开始位置设为end_off。按字节从start_off开始遍历读取记录R3的记录号,slot拥有记录数,Compact格式的记录状态,每个字段的字段长度。若记录号为3且slot拥有记录数为0或者4-8之间且每个字段长度正确则认为正确解析了记录R3,否则偏移位置加1继续遍历直到结束。若R3之后的记录全部被删除,则记录R3删除记录范围在R2和页尾之间,根据上述方法恢复出记录R3,然后可以确定记录R4的范围在R3和页尾之间,同样根据上述方法恢复出R4,依次类推可恢复出所有删除记录。
(2)判断所恢复记录是否正确可以根据一些字段的特性。Innodb中时间字段以integer(整数、整型数)存储在磁盘,解析成时间后如不符合时间规则(月份1-12之间,日期1-31之间等),则解析错误;字符串类型,根据字符编码格式判断长度是否正确,如latin1编码字符串长度为10,实际长度小于10,则解析错误。
(3)Ibdata文件(表空间文件)中包含有数据字典信息,用于依据数据字典映射至源文件。
数据字典主要由4张系统表组成,分别是SYS_TABLES、SYS_COLUMNS、SYS_INDEXS,以及SYS_FIELDS。
其中,SYS_TABLES记录了每张表的表名,表ID,字段数,表空间ID等信息;SYS_COLUMNS记录了所属表ID,字段名,字段类型,字段长度等信息;SYS_INDEXS记录了所属表ID,索引ID,索引名称(如主键索引的名称为PRIMARY),索引字段数,及索引B+数的RootPage等信息;SYS_FIELDS记录了所属的索引ID,索引字段名等信息。通过表空间文件中包含的数据字典信息,可以依据数据字典获取到每张表的列信息,索引信息,数据所在表空间以及B+树的Root page等信息。
当删除一个表,这张表的信息会从4张系统表中删除,并且如果是单独表空间对应ibd文件(目前高版本通用的存储引擎)也会从磁盘中删除,这时还需要根据(1)恢复字典信息记录;再通过数据字典记录的表空间id,索引id和索引页结构等信息从ibdata文件或者磁盘中搜索出所有索引页从而恢复出数据。
据此,同时参照图5,本发明提供一种innodb存储引擎删除记录的离线恢复方法,包括:
依据表空间文件的数据字典信息获取索引页的根节点页号;
从所述根节点页号开始,遍历每个节点;
通过遍历每个节点对应索引页的正常记录链表以及删除记录链表中的每条记录,依据每条记录的偏移地址和记录号,以及当前索引页内所有的记录数,获取未维护删除记录对应的记录号以及偏移地址范围;
依据未维护删除记录的记录号,从对应的偏移地址范围中解析得到与所述未维护删除记录的记录号一致的记录。
进一步的,所述依据未维护删除记录的记录号,从对应的偏移地址范围中解析得到与所述未维护删除记录的记录号一致的记录,具体为:
获取一未维护删除记录对应的记录号以及偏移地址范围;
获取偏移地址范围内记录号与所述一未维护删除记录对应的记录号相同的记录。
进一步的,所述通过遍历每个节点对应索引页的正常记录链表以及删除记录链表中的每条记录,依据每条记录的偏移地址和记录号,以及当前索引页内所有的记录数,获取系统未维护的删除记录对应的记录号以及偏移地址范围;具体为:
S01:遍历当前节点对应的索引页的正常记录链表,获取所有正常记录,同时记录每条正常记录的记录号和偏移地址;
遍历当前节点对应的索引页的删除记录链表,获取所有删除记录,同时记录每条删除记录的记录号和偏移地址;
S02:获取当前索引页内所有的记录数;
S03:依据所述所有的记录数,以及所述每条正常记录的记录号和偏移地址、每条删除记录的记录号和偏移地址,确定未维护删除记录的记录号和偏移地址范围。
进一步的,所述依据未维护删除记录的记录号,从对应的偏移地址范围中解析得到与所述未维护删除记录的记录号一致的记录,具体为:
S04:获取一未维护删除记录对应的记录号、起始偏移地址以及结束偏移地址;
S05:从起始偏移地址开始,随着当前指针的移动,判断当前指针指向的偏移地址所对应的记录的记录号是否等于所述一未维护删除记录对应的记录号;若是,则执行S06;
S06:判断所述偏移地址对应的记录的slot所拥有的记录数是否匹配;若是则执行S07;
S07:判断所述偏移地址对应的记录的每个字段长度是否正确;若是,则执行S08;
S08:获取所述偏移地址对应的记录;
S09:获取下一未维护删除记录对应的记录号、起始偏移地址以及结束偏移地址;返回执行S05。
由上述描述可知,依据记录号确定一记录后,还将依据字段特定进一步确定该记录是否确实为所需恢复的记录,保证所恢复记录的准确性。
进一步的,若记录的格式为Redundant;则所述S07具体为:
判断所述偏移地址对应的记录的每个字段长度是否正确;
若是,则判断所述偏移地址对应的记录的记录状态是否正确;
若是,则执行S08。
由上述描述可知,针对低版本的存储引擎索引表存储格式对应存储字段的特性,进一步判断待恢复记录是否正确性;提高通用性。
进一步的,所述依据表空间文件的数据字典信息获取索引页的根节点页号;具体为:
分析表空间文件,获取其数据字典信息;
依据所述数据字典信息,从数据字典中的系统表中获取所述表空间文件的索引页的根节点页号。
由上述描述可知,依据存储引擎的存储特性获取索引页的根节点页号,为后续据此实现对索引页各节点的遍历提供支持。
进一步的,还包括:
判断解析得到的记录的时间字段是否符合规则要求,以及对照其字符串类型判断其字符串长度是否正确;
若均符合,则判定解析成功。
由上述描述可知,提供解析结果正确与否的判断方式,保证解析得到的记录的正确性。
本发明提供的另一个技术方案为:
一种计算机可读存储介质,其内存储有计算机程序,该程序被处理器执行时实现上述innodb存储引擎删除记录的离线恢复方法。
实施例一
请参照图1-图7,本实施例提供一种innodb存储引擎删除记录的离线恢复方法,能够实现全面、准确地恢复出系统未维护的删除记录。
如图6所示,本实施例可以包括以下步骤:
1)解析Ibdata(表空间文件)中的数据字典信息,获取每张数据表的元数据信息(即数据字典信息)。
2)依据上述获取的元数据信息,通过数据字典维护的4张系统表中获取一张表包括表空间文件、索引ID,索引页B+树的根节点页号等信息。
如数据库testdb下有张表testtable,通过查询系统SYS_TABLES表,获取该表对应的表空间id;若表空间id为0,则对应表空间文件为独立的表空间文件ibdata;若不为0,则表空间文件为testdb\testtable.ibd,即存储在系统数据库testdb磁盘中。通过表空间id查询系统SYS_COLUMNS表的所有行即可得到表的所有字段名,字段类型等信息;通过表空间id查询系统SYS_INDEXS表,能获取表的索引id及Root page(根节点页号)等信息.
3)从对应的表空间文件读取根节点页号。
具体的,通过表空间id查询系统SYS_INDEXS表,获取表的Root page(根节点页号)。
4)从根节点页号开始,遍历每个节点对应的索引页中的正常记录链表以及删除记录链表中的每条记录,并记录下每条记录的记录号以及对应的偏移地址。
具体的,对应正常记录链表:
通过偏移99(PAGE_NEW_INFIMUM)/101(PAGE_OLD_INFIMUM)个字节获取到第一条记录,通过记录前两个字节REC_NEXT记录的下一条记录相对位置,依次遍历所有正常记录,并记录的所有记录的HEAP NO(记录号)及在页内的相对位置(偏移地址)。
其中,由于Compact格式为固定99字节(38字节页头部PAGE_HEADER+36字节的索引页头部+20字节段信息+5字节记录头,后面紧跟的便是第一条记录也是系统infimum)。因此通过偏移99获取第一条记录;
Redundant格式固定101字节(38字节页头部PAGE_HEADER+36字节的索引页头部+20字节段信息+1个无效字节+6字节记录头),因此对应偏移101字节确定第一条记录。
对应删除记录链表:
通过偏移44(PAGE_HEADER+PAGE_FREE)个字节读取到第一条删除记录的偏移地址从而获取到第一条系统维护删除记录,通过记录前两个字节REC_NEXT记录的下一条记录相对位置,依次遍历所有删除记录,并记录的所有记录的HEAP NO(记录号)及在页内的相对位置(偏移地址)。
其中,偏移44字节为固定值,38字节页头部+索引头部的第6(PAGE_FREE)个字节,具体参考索引头部内容。
5)通过偏移42(PAGE_HEADER+PAGE_N_HEAP)个字节读取到页内所有的记录数(总记录数),再根据第4步记录的记录号和相对偏移地址确定其余系统未维护的删除记录的范围和记录号。原理请参阅上述原理说明的内容。
其中,偏移42个字节为固定值,38字节页头部+索引头部的第4(PAGE_N_HEAP)个字节,参考索引头部内容。
6)基于上述4)和5),在确定的系统未维护的删除记录号所在范围内按字节依次遍历,按照上述原理说明的(1)和(2)恢复出删除记录。
7)判断该页是否为叶子节点即B+树的高度是否为0。若为非叶子节点,则分析每条记录的最后一个字段记录的下一级页号,并读取该页,然后重复第4)步中偏移44字节部分进行分析数据,直至读取到叶子节点,若为叶子节点,则保存所有解析和恢复出来的记录。
由于同一索引的所有索引页组成一个B+树结构,B+树的非叶子节点仅起到索引下一级索引页的作用。非叶子节点中的记录仅包含索引字段和下一级索引页的页号,非完整记录。所以需要判断是否叶子节点,如果是非叶子节点则获取下一级索引页的页号,依次类推,直到获取到叶子节点,保存恢复记录。
其中,请参阅图7,第6)步骤解析系统未维护删除记录的具体过程,可以包括以下:
6.1、开始;
6.2、设记录号HEAP_NO=2,起始偏移地址为start_off指向系统记录suprmum;结束偏移地址为end_off指向页尾;当前指针为cur_off;
其中,由于记录号0为infimum(上确界),记录号为1是supremum(下确界),用户记录是从记录号2开始顺序记录的,因此,从记录号2开始判断。
6.3、判断HEAP_NO是否大于等于总记录数;若是,则结束流程;
若否,则进一步判断HEAP_NO对应记录是否已解析过;
若是,则start_off指向HEAP_NO对应记录的起始位置;HEAP_NO+=1;然后返回执行6.3;
若否,则执行6.4;
6.4、end_off指向下一条成功解析记录的地址,若没有则指向页尾;cur_off=start_off;
6.5、判断cur_off是否大于等于end_off;
若是,则判定解析失败;HEAP_NO+=1;返回执行6.3;
若否,则读取记录的记录号判断是否等于HEAP_NO;若否,则cur_off+=1;然后返回执行6.5;若是,则
进一步读取记录状态值判断是否合法;若否,则cur_off+=1;然后返回执行6.5;若是,则
进一步读取记录OWNED值(slot所拥有记录数)判断是否合法;若否,则cur_off+=1;然后返回执行6.5;若是,则
进一步判断每个字段长度是否合法;若否,则cur_off+=1;然后返回执行6.5;若是,则可以基本确定该记录就是所要恢复的未维护的删除记录;
如果记录中包含时间字段,则进一步判断是否符合时间规则,若否则cur_off+=1;然后返回执行6.5;若是,则
如果记录中包含字符串类型字段,则进一步判断读取的字符串长度是否等于记录头部记录的字段长度,若否则cur_off+=1;然后返回执行6.5;若是,则
判定解析成功,保存记录;start_off指向cur_off;HEAP_NO+=1;然后返回执行6.5,继续判断下一条记录。
实施例二
本实施例对应实施例一,提供一种计算机可读存储介质,其内存储有计算机程序,该程序被处理器执行时实现实施例一所述的一种innodb存储引擎删除记录的离线恢复方法。
综上所述,本发明提供的一种innodb存储引擎删除记录的离线恢复方法、计算机可读存储介质,能够基于innodb索引页结构、记录结构以及字段特征实现全面、准确地恢复出系统未维护的删除记录的准确恢复。从而为计算机数据取证安全领域作出巨大贡献。
以上所述仅为本发明的实施例,并非因此限制本发明的专利范围,凡是利用本发明说明书及附图内容所作的等同变换,或直接或间接运用在相关的技术领域,均同理包括在本发明的专利保护范围内。
Claims (8)
1.一种innodb存储引擎删除记录的离线恢复方法,其特征在于,包括:
依据表空间文件的数据字典信息获取索引页的根节点页号;
从所述根节点页号开始,遍历每个节点;
通过遍历每个节点对应索引页的正常记录链表以及删除记录链表中的每条记录,依据每条记录的偏移地址和记录号,以及当前索引页内所有的记录数,获取未维护删除记录对应的记录号以及偏移地址范围;
依据未维护删除记录的记录号,从对应的偏移地址范围中解析得到与所述未维护删除记录的记录号一致的记录。
2.如权利要求1所述的一种innodb存储引擎删除记录的离线恢复方法,其特征在于,所述依据未维护删除记录的记录号,从对应的偏移地址范围中解析得到与所述未维护删除记录的记录号一致的记录,具体为:
获取一未维护删除记录对应的记录号以及偏移地址范围;
获取偏移地址范围内记录号与所述一未维护删除记录对应的记录号相同的记录。
3.如权利要求1所述的一种innodb存储引擎删除记录的离线恢复方法,其特征在于,所述通过遍历每个节点对应索引页的正常记录链表以及删除记录链表中的每条记录,依据每条记录的偏移地址和记录号,以及当前索引页内所有的记录数,获取系统未维护的删除记录对应的记录号以及偏移地址范围;具体为:
S01:遍历当前节点对应的索引页的正常记录链表,获取所有正常记录,同时记录每条正常记录的记录号和偏移地址;
遍历当前节点对应的索引页的删除记录链表,获取所有删除记录,同时记录每条删除记录的记录号和偏移地址;
S02:获取当前索引页内所有的记录数;
S03:依据所述所有的记录数,以及所述每条正常记录的记录号和偏移地址、每条删除记录的记录号和偏移地址,确定未维护删除记录的记录号和偏移地址范围。
4.如权利要求1或3所述的一种innodb存储引擎删除记录的离线恢复方法,其特征在于,所述依据未维护删除记录的记录号,从对应的偏移地址范围中解析得到与所述未维护删除记录的记录号一致的记录,具体为:
S04:获取一未维护删除记录对应的记录号、起始偏移地址以及结束偏移地址;
S05:从起始偏移地址开始,随着当前指针的移动,判断当前指针指向的偏移地址所对应的记录的记录号是否等于所述一未维护删除记录对应的记录号;若是,则执行S06;
S06:判断所述偏移地址对应的记录的slot所拥有的记录数是否匹配;若是则执行S07;
S07:判断所述偏移地址对应的记录的每个字段长度是否正确;若是,则执行S08;
S08:获取所述偏移地址对应的记录;
S09:获取下一未维护删除记录对应的记录号、起始偏移地址以及结束偏移地址;返回执行S05。
5.如权利要求4所述的一种innodb存储引擎删除记录的离线恢复方法,其特征在于,若记录的格式为Redundant;则所述S07具体为:
判断所述偏移地址对应的记录的每个字段长度是否正确;
若是,则判断所述偏移地址对应的记录的记录状态是否正确;
若是,则执行S08。
6.如权利要求1所述的一种innodb存储引擎删除记录的离线恢复方法,其特征在于,所述依据表空间文件的数据字典信息获取索引页的根节点页号;具体为:
分析表空间文件,获取其数据字典信息;
依据所述数据字典信息,从数据字典中的系统表中获取所述表空间文件的索引页的根节点页号。
7.如权利要求1所述的一种innodb存储引擎删除记录的离线恢复方法,其特征在于,还包括:
判断解析得到的记录的时间字段是否符合规则要求,以及对照其字符串类型判断其字符串长度是否正确;
若均符合,则判定解析成功。
8.一种计算机可读存储介质,其内存储有计算机程序,其特征在于,该程序被处理器执行时实现权利要求1-7任意一项所述的一种innodb存储引擎删除记录的离线恢复方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201711213512.6A CN108062358B (zh) | 2017-11-28 | 2017-11-28 | innodb引擎删除记录的离线恢复方法、存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201711213512.6A CN108062358B (zh) | 2017-11-28 | 2017-11-28 | innodb引擎删除记录的离线恢复方法、存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN108062358A true CN108062358A (zh) | 2018-05-22 |
CN108062358B CN108062358B (zh) | 2020-12-29 |
Family
ID=62135086
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201711213512.6A Active CN108062358B (zh) | 2017-11-28 | 2017-11-28 | innodb引擎删除记录的离线恢复方法、存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN108062358B (zh) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109358989A (zh) * | 2018-12-25 | 2019-02-19 | 四川效率源信息安全技术股份有限公司 | 一种基于图论的雕复mysql-innodb数据库的方法 |
CN109408290A (zh) * | 2018-10-19 | 2019-03-01 | 厦门市美亚柏科信息股份有限公司 | 一种基于InnoDB的碎片文件恢复方法、装置及存储介质 |
CN109491861A (zh) * | 2018-10-19 | 2019-03-19 | 厦门市美亚柏科信息股份有限公司 | 一种溢出页异常的数据库修复方法、装置及存储介质 |
CN109753382A (zh) * | 2018-12-10 | 2019-05-14 | 厦门市美亚柏科信息股份有限公司 | 一种数据库删除记录的恢复方法及系统 |
CN110058969A (zh) * | 2019-04-18 | 2019-07-26 | 腾讯科技(深圳)有限公司 | 一种数据恢复方法及装置 |
CN110569147A (zh) * | 2019-09-05 | 2019-12-13 | 厦门市美亚柏科信息股份有限公司 | 一种基于索引的删除文件恢复方法、终端设备及存储介质 |
CN111143130A (zh) * | 2019-12-25 | 2020-05-12 | 腾讯科技(深圳)有限公司 | 数据恢复方法、装置、计算机可读存储介质和计算机设备 |
CN111259004A (zh) * | 2020-01-08 | 2020-06-09 | 腾讯科技(深圳)有限公司 | 一种存储引擎中数据索引的方法以及相关装置 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080183953A1 (en) * | 2006-12-06 | 2008-07-31 | David Flynn | Apparatus, system, and method for storage space recovery in solid-state storage |
CN103605657A (zh) * | 2013-10-14 | 2014-02-26 | 华为技术有限公司 | 一种在线重建索引的方法和装置 |
CN104881418A (zh) * | 2014-02-28 | 2015-09-02 | 阿里巴巴集团控股有限公司 | 用于MySQL的快速回收回滚空间的方法和装置 |
CN106326421A (zh) * | 2016-08-24 | 2017-01-11 | 中国科学院上海微系统与信息技术研究所 | 基于索引树和数据链表的fpga并行排序方法及系统 |
CN106844089A (zh) * | 2015-12-03 | 2017-06-13 | 阿里巴巴集团控股有限公司 | 一种用于恢复树形数据存储的方法与设备 |
-
2017
- 2017-11-28 CN CN201711213512.6A patent/CN108062358B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080183953A1 (en) * | 2006-12-06 | 2008-07-31 | David Flynn | Apparatus, system, and method for storage space recovery in solid-state storage |
CN103605657A (zh) * | 2013-10-14 | 2014-02-26 | 华为技术有限公司 | 一种在线重建索引的方法和装置 |
CN104881418A (zh) * | 2014-02-28 | 2015-09-02 | 阿里巴巴集团控股有限公司 | 用于MySQL的快速回收回滚空间的方法和装置 |
CN106844089A (zh) * | 2015-12-03 | 2017-06-13 | 阿里巴巴集团控股有限公司 | 一种用于恢复树形数据存储的方法与设备 |
CN106326421A (zh) * | 2016-08-24 | 2017-01-11 | 中国科学院上海微系统与信息技术研究所 | 基于索引树和数据链表的fpga并行排序方法及系统 |
Non-Patent Citations (1)
Title |
---|
孙偏偏: "InnoDB数据库数据恢复技术研究", 《CNKI硕士论文》 * |
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109408290B (zh) * | 2018-10-19 | 2021-02-26 | 厦门市美亚柏科信息股份有限公司 | 一种基于InnoDB的碎片文件恢复方法、装置及存储介质 |
CN109408290A (zh) * | 2018-10-19 | 2019-03-01 | 厦门市美亚柏科信息股份有限公司 | 一种基于InnoDB的碎片文件恢复方法、装置及存储介质 |
CN109491861A (zh) * | 2018-10-19 | 2019-03-19 | 厦门市美亚柏科信息股份有限公司 | 一种溢出页异常的数据库修复方法、装置及存储介质 |
CN109491861B (zh) * | 2018-10-19 | 2022-08-12 | 厦门市美亚柏科信息股份有限公司 | 一种溢出页异常的数据库修复方法、装置及存储介质 |
CN109753382B (zh) * | 2018-12-10 | 2022-01-07 | 厦门市美亚柏科信息股份有限公司 | 一种数据库删除记录的恢复方法及系统 |
WO2020119143A1 (zh) * | 2018-12-10 | 2020-06-18 | 厦门市美亚柏科信息股份有限公司 | 一种数据库删除记录的恢复方法及系统 |
CN109753382A (zh) * | 2018-12-10 | 2019-05-14 | 厦门市美亚柏科信息股份有限公司 | 一种数据库删除记录的恢复方法及系统 |
EP3798842A4 (en) * | 2018-12-10 | 2022-04-13 | Xiamen Meiya Pico Information Co., Ltd | METHOD AND SYSTEM FOR RECOVERING DELETED DATABASE RECORDS |
CN109358989B (zh) * | 2018-12-25 | 2021-08-03 | 四川效率源信息安全技术股份有限公司 | 一种基于图论的雕复mysql-innodb数据库的方法 |
CN109358989A (zh) * | 2018-12-25 | 2019-02-19 | 四川效率源信息安全技术股份有限公司 | 一种基于图论的雕复mysql-innodb数据库的方法 |
CN110058969A (zh) * | 2019-04-18 | 2019-07-26 | 腾讯科技(深圳)有限公司 | 一种数据恢复方法及装置 |
CN110058969B (zh) * | 2019-04-18 | 2023-02-28 | 腾讯科技(深圳)有限公司 | 一种数据恢复方法及装置 |
CN110569147A (zh) * | 2019-09-05 | 2019-12-13 | 厦门市美亚柏科信息股份有限公司 | 一种基于索引的删除文件恢复方法、终端设备及存储介质 |
CN110569147B (zh) * | 2019-09-05 | 2022-06-07 | 厦门市美亚柏科信息股份有限公司 | 一种基于索引的删除文件恢复方法、终端设备及存储介质 |
CN111143130B (zh) * | 2019-12-25 | 2021-05-25 | 腾讯科技(深圳)有限公司 | 数据恢复方法、装置、计算机可读存储介质和计算机设备 |
CN111143130A (zh) * | 2019-12-25 | 2020-05-12 | 腾讯科技(深圳)有限公司 | 数据恢复方法、装置、计算机可读存储介质和计算机设备 |
CN111259004A (zh) * | 2020-01-08 | 2020-06-09 | 腾讯科技(深圳)有限公司 | 一种存储引擎中数据索引的方法以及相关装置 |
CN111259004B (zh) * | 2020-01-08 | 2023-04-14 | 腾讯科技(深圳)有限公司 | 一种存储引擎中数据索引的方法以及相关装置 |
Also Published As
Publication number | Publication date |
---|---|
CN108062358B (zh) | 2020-12-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108062358A (zh) | innodb引擎删除记录的离线恢复方法、存储介质 | |
US6185569B1 (en) | Linked data structure integrity verification system which verifies actual node information with expected node information stored in a table | |
US8959125B2 (en) | File system having inverted hierarchical structure | |
Frühwirt et al. | Innodb database forensics: Reconstructing data manipulation queries from redo logs | |
US20070005874A1 (en) | File system storing transaction records in flash-like media | |
CA2818472C (en) | Optimized startup verification of file system integrity | |
US8396840B1 (en) | System and method for targeted consistency improvement in a distributed storage system | |
CN109710455A (zh) | 基于fat32文件系统的删除文件恢复方法及系统 | |
WO2020119143A1 (zh) | 一种数据库删除记录的恢复方法及系统 | |
Frühwirt et al. | InnoDB database forensics: Enhanced reconstruction of data manipulation queries from redo logs | |
CN108388569B (zh) | 一种快速的键值数据库的系统及建立方法 | |
CN104199888A (zh) | 弹性文件系统的数据恢复方法和装置 | |
JP5959592B2 (ja) | データベース管理方法、プログラム及び該管理システム、並びにデータベースのツリー構造 | |
CN103617277A (zh) | 一种还原误删除的数据表内容的方法 | |
CN109918386A (zh) | 一种数据恢复方法和装置、计算机可读存储介质 | |
CN108009049B (zh) | Myisam存储引擎删除记录离线恢复方法、存储介质 | |
CN105068887A (zh) | 一种基于SQLServer数据库的数据恢复方法 | |
CN107944041A (zh) | 一种hdfs的存储结构优化方法 | |
CN105068888A (zh) | 一种基于Oracle数据库的数据恢复方法 | |
US6457014B1 (en) | System and method for extracting index key data fields | |
Schierl et al. | Abstract specification of the UBIFS file system for flash memory | |
CN112395851A (zh) | 一种文本比对方法、装置、计算机设备及可读存储介质 | |
CN103838780A (zh) | 数据库的数据恢复方法及相关的设备 | |
CN106897174B (zh) | 一种针对mysql数据库的碎片恢复方法 | |
KR20020035093A (ko) | 데이타베이스 테이블 복구 시스템 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |