一种数据库备份恢复轻量级通用检查方法、设备及介质

技术领域

本发明涉及计算机和数据库管理技术领域，尤其涉及一种数据库备份恢复轻量级通用检查方法、设备及介质。

背景技术

现代的金融交易系统多采用内存数据库设计方式，系统架构上大多支持双活或多活，因而对数据库本身的可用性RTO要求是降低的。但数据库里存放的业务数据通常是跟业务柜面操作，清算等业务直接相关重要数据，因此对数据库的RPO要求没有降低，数据的完整性在日常维护中必须严格保障。

类似停机或不停机数据库备份恢复，恢复方式上大体上分为物理备份恢复，逻辑备份恢复，基于日志和内部sequence或id进行备份恢复，以及基于存储特性的CopyOnWrite等方式的备份恢复。每种方式根据资源投入，保障恢复级别、时效等要求，都有其适用的场景。

对于数据库恢复后对比检查，现行做法有全表做记录数对比，也有通过业务验证，或通过数据库内部的变动序号等方式确认恢复目标时间点。一般很少采用实施成本较高所有表全部字段比对等方式。

现有的备份恢复检查方法无法同时对如下方面做到较好兼顾和平衡：

1、对于成功、失败的判断，在简单和可靠性方便兼顾不足；

2、对于可停机维护的和不可停机维护的备份场景兼顾不足；

3、不支持恢复前后指定库，schema，表的不同维度灵活的对比方式；

4、数据检查对比细腻度没有到表具体列比对，表创建时间对比，自上次备份以来新增的表检查，已有表修改的记录数量检查等，或者支持部分检查但成本非常高，缺乏灵活性。

因此，如何设计出一种轻量级数据备份恢复检查方法，成为本领域技术人员急需解决的技术问题。

发明内容

本发明的目的在于，提供一种数据库备份恢复轻量级通用检查方法、设备及介质，能够兼顾对可不可停机、低成本、高灵活度等其他场景方面的需求。

为达到上述目的，本发明采用下述技术方案实现：

第一方面，本发明提供一种数据库备份恢复轻量级通用检查方法，包括以下步骤：

定义数据库抽取规则；

根据数据库抽取规则，在备库测试前对数据进行第一次抽取，生成第一次抽取数据并保存；

对所述第一次抽取数据进行数据备份测试；

在所述第一次数据测试后对数据进行第二次抽取，生成第二次抽取数据并保存；

对所述第二次抽取数据进行数据恢复；

在数据恢复后对数据进行第三次抽取，生成第三次抽取数据并保存；

对数据进行实时抽取，生成实时抽取数据；

将所述第三次抽取数据与第一次抽取数据做对比，确认数据恢复前后一致，后生成对比检查结果；

基于上述对比，将所述实时抽取数据与所述第一次抽取数据做对比，从所述第一次抽取数据里提取统计时刻，实时查询各表自所述统计时刻到现在实时统计时刻记录变动数，后生成对比检查结果并邮件发送给相关方；

根据所述监控检查对比结果，制定干预处置方案。

结合第一方面，所述定义数据库抽取规则，包括：定义数据库抽查范围、库下schema检查范围以及schema下表检查范围，其具体包括：

根据数据库抽查范围，使用数据库字典/视图，抽取db的schema；

根据库下schema检查范围，使用数据库字典/视图，抽取schema下的表名称；

根据schema下表检查范围，使用数据库字典/视图，抽取表的记录数、表的修改时间和表的创建时间；

将抽取的所有记录合并输出成json文件。

结合第一方面，将所述第三次抽取数据与第一次抽取数据做对比，若确认数据恢复异常，还需将所述第二次抽取数据与第一次抽取数据做对比，用于辅助判断和反应测试过程。

结合第一方面，在定义数据库抽取规则之前，方法还包括：对备份恢复检查信息进行登记管理。

结合第一方面，在对备份恢复检查信息进行登记管理之前，方法还包括：统一数据库设计规范；

具体包括：

标志记录表的创建及修改时间。

结合第一方面，根据监控检查对比结果，制定干预处置方案，包括：

若通过监控判定检查正常，则表示巡检结束；

若通过监控判定检查异常，则进行告警处理并根据出错原因制定干预处置方案，等待处置完成。

第二方面，本发明提供一种数据库备份恢复轻量级通用检查设备，包括：

存储器，用于存储指令；

处理器，用于执行所述指令，使得所述设备执行实现如第一方面所述的方法的步骤。

第三方面，本发明提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时，实现如第一方面所述的方法的步骤。

与现有技术相比，本发明所达到的有益效果：

1、本发明通过定义数据库抽取规则，根据所述数据库抽取规则分别进行多次数据抽取，后对数据分析对比，并对比结果邮件发送到相关方，再由监控检查对比结果，最后根据监控检查结果，制定干预处置方案，体现出一种轻量级的数据库备份恢复对比检查的闭环流程。能够兼顾对可不可停机、低成本、高灵活度等其他场景方面的需求。

2、针对判断逻辑备份、恢复过程中的失败情况做了简化处理。

3、兼顾可停机维护的和不可停机维护的备份场景。

4、支持恢复前后指定库，schema，表的不同维度灵活的对比方式。

5、数据检查对比具体细腻到表的列比对，表的创建时间比对，历史新增的表检查，已有表的修改的记录数量检查等。

6、能够高效地识别出数据库恢复前后数据不一致、非预期的脏数据，以便及时发现、确认并处置。

附图说明

图1所示为本发明的一种实施例中检查方法精简版流程图；

图2所示为本发明的一种实施例中检查方法总流程图；

图3所示为本发明的一种实施例中未备份的流程示例示意图；

图4所示为本发明的一种实施例中备份完成测试中的流程示例示意图；

图5所示为本发明的一种实施例中测试结束待恢复的流程示例示意图；

图6所示为本发明的一种实施例中恢复结束待反馈的流程示例示意图；

图7所示为本发明的一种实施例中恢复结束检查完成的流程示例示意图。

具体实施方式

下面结合附图对本发明作进一步描述。以下实施例仅用于更加清楚地说明本发明的技术方案，而不能以此来限制本发明的保护范围。

本发明的技术构思为：考虑到对于数据库恢复后对比检查，现行做法有全表做记录数对比，也有通过业务验证，或通过数据库内部的变动序号等方式确认恢复目标时间点。但是现有的备份恢复检查方法无法在对可不可停机、低成本、高灵活度等其他场景方面做到较好兼顾和平衡。基于此，本发明介绍一种数据库备份恢复轻量级通用检查方法、设备及介质，用于兼顾上述不同场景下的需求。

实施例1

参考图1，本实施例提供一种数据库备份恢复轻量级通用检查方法，方法包括以下步骤：

A：定义数据库抽取规则；根据数据库抽取规则，在备库测试前对数据进行第一次抽取，生成第一次抽取数据并保存；对所述第一次抽取数据进行数据备份测试。

B：在所述第一次数据测试后对数据进行第二次抽取，生成第二次抽取数据并保存；对所述第二次抽取数据进行数据恢复。

C：在数据恢复后对数据进行第三次抽取，生成第三次抽取数据并保存。

D：对数据进行实时抽取，生成实时抽取数据。

F：将所述第三次抽取数据与第一次抽取数据做对比，确认数据恢复前后一致，后生成对比检查结果。

G：基于上述对比，将所述实时抽取数据与所述第一次抽取数据做对比，从所述第一次抽取数据里提取统计时刻，实时查询各表自所述统计时刻到现在实时统计时刻记录变动数，后生成对比检查结果并邮件发送给相关方；

H：根据监控检查对比结果，制定干预处置方案。

本实施例通过定义数据库抽取规则，根据所述数据库抽取规则分别进行多次数据抽取，后对数据分析对比，并对比结果邮件发送到相关方，再由监控检查对比结果，最后根据监控检查结果，制定干预处置方案。体现出一种轻量级的数据库备份恢复对比检查的闭环流程。

实施例2

参考图2，在实施例1的基础上，本实施例介绍的数据库备份恢复轻量级通用检查方法具体包括如下步骤：

Step1：数据库表设计规范

1)数据库表设计规范统一：表需要有modifiedTime和createdTime列，标志记录创建，修改时间。

Step2：备份恢复检查信息登记管理

1)利用共享文档平台管理备库、恢复库的需求登记，明确库、schema，表备份恢复时间，特殊要求以及注意事项等。

2)利用共享文档平台恢复库后，重点检查表和字段。

3)变更内部与数据库相关的流程，同步出发更新共享文档平台记录。

Step3：定义数据库抽取规则

1)定义好抽查的库、schema、表、列范围，以单个db举例,可以灵活自上而下定义抽取的范围。

其中，抽取规则具体包括如下抽取细节：

11)根据数据库抽查范围，使用数据库字典/视图，抽取db的schema；

12)根据库下schema检查范围，使用数据库字典/视图，抽取schema下的表名称；

13)根据schema下表检查范围，使用数据库字典/视图，抽取表的记录数、表的修改时间和表的创建时间；

14)将抽取的所有记录合并输出成json文件。

参考如下实例：

[db_scope]

dbScope＝dbA dbB

[db_schema_scope]

dbAschemaScope＝dbA.schemaA dbA.schemaB dbA.schemaC#*大表所有

[schema_table_checkRule]

dbAschemaA＝tableA1(ModifiedTime)tableA2 tableA3#*代表所有表；

dbAschemaB＝tableB1(ModifiedTime)tableB2 tableB3#*代表所有表；

dbAschemaC＝*

Step4：抽取数据并将对比结果邮件给相关方

抽取数据：根据数据备份、恢复、对比登记需求，调整规则抽取数据，利用编程语言的数据库访问操作接口连接数据库，利用数据库字典和视图表抽取数据库下schema、schema下表的数量、表的名称、创建时间、对应表的记录数、表的修改时间，本次统计时间记录落成文件，落成比如json格式示例。

1)测试前，第一次数据抽取：根据数据库抽取规则，在备库测试前对数据进行第一次抽取，生成第一次抽取数据并保存；对所述第一次抽取数据进行数据备份测试。

其中，在本实施例中，数据库逻辑备份是基于数据库自带的命令行逻辑备份恢复命令来实现建议通用设计来实现逻辑。具体分为如下步骤：

11)命令设计:DatabaseBackupOrReoverCommand 1>err.log 2>&1&&echo`date`>ok.log；

12)执行逻辑:&&连接两条命令，&&左边备份语句执行完成正常退出，才会执行后面的echo部分；

13)判断逻辑:异常时err.log有记录，ok.log没有记录；正常时err.log为空，ok.log为恢复完成时间；

14)后台执行:将命令用shell包裹，利用nohup放到后台执行。

2)测试后，第二次数据抽取：对数据进行第二次抽取，生成第二次抽取数据并保存；对所述第二次抽取数据进行数据恢复。

3)恢复后，第三次数据抽取：对数据进行第三次抽取，生成第三次抽取数据并保存。

4)第四次数据抽取：对数据进行实时抽取，生成实时抽取数据。

第一次对比：将所述第三次抽取数据与第一次抽取数据做对比，若数据恢复前后一致，后生成对比检查结果；

若确认数据恢复异常，还需将所述第二次抽取数据与第一次抽取数据做对比，用于辅助判断和反应测试过程。

第二次对比：将所述实时抽取数据与所述第一次抽取数据做对比，从所述第一次抽取数据里提取统计时刻，实时查询各表自所述统计时刻到现在实时统计时刻记录变动数，后生成对比检查结果。

其中，在本实施例中，采用如下设计：

根据需要落抽取记录份文件。

A：比如落3份文件

备库前：1beforeBackup.json；

测试结束：2sysTestEnd.json；

恢复结束：3afterRecover.json。

需要说明的是，此处的1beforeBackup.json，2sysTestEnd.json和3afterRecover.json都属于每个时间点的实时抽取的数据，恢复结束后实时抽取的数据保存在内存的同时落3afterRecover.json，然后与加载的1beforeBackup.json和3afterRecover.json做对比。

B：每次恢复后产出两个对比结果，对比结果内容参考图3

对比结果1：3afterRecover.json与1beforeBackup.json；

对比结果2：2sysTestEnd.json与1beforeBackup.json；

对比结果2主要是用来在对比结果1有异常的情况，辅助判断，也部分反映测试过程。

C：对比文件生成

使用本专利工具程序dbcheck实现，命令行参考方式

实时落统计文件：

./dbcheck-name＝"3afterRecover.json"#生成当前统计信息文件，重复执行，会把当前的文件拷贝到3afterRecover.json_20221010-213050目录，再重新在当前目录喜爱生成实时记录统计文件。

记录文件对比：

./dbcheck -fname＝"3afterRecover.json" -cmp＝"1beforeBackup.json" -detail y>cmpResult.json #现有文件xtraderdb_3afterRecover.json对比xtraderdb_1beforeBackup.json，也就是说对比已有的两个文件，不会检查每个表距离上次修改后修改记录总数

加强对比：./dbcheck-name＝"3afterRecover.json"-cmp＝"1beforeBackup.json"-detail y>cmpResult.json#实时生成文件xtraderdb_3afterRecover.json与已有的xtraderdb_1beforeBackup.json对比记录文件，包含自1beforeBackup.json里到目前统计时刻表记录修改数量，也就是说会提取被对比文件里的统计时间，然后统计上次统计时间到目前统计时刻表记录修改数量，此对比方式为推荐对比方式。

D：记录样式

1.本次统计表数量对比上次统计表数量【对比结果相同则表示正常】，因为理论上恢复前后表的数量不应该有变化；

2.本次统计时间对比上次统计时间【对比结果不同则表示正常】，因为证明用于对比的记录不是同一个时间的，此处对比用于防止程序逻辑错误；

3.表变动记录【都为空则表示正常】)+增加的表对比减少的表，库恢前后各schema下的表的数量应该是一样的；

4.表修改时间，表里的modifiedTime字段恢复前后应该是一样的；

5.自上次备份依赖modifiedTime被修改的记录数据，就是代表恢复后，数据没有再次被修改，如果修改了根据modifiedTime给出修改记录数；

6.表创建时间，恢复后表的创建时间会变化，没变化说面没恢复成功或不在本次备份的表范围。

Step5：将对比检查结果利用监控检查并邮件发送给相关方监控检查对比结果，制定干预处置方案

若通过监控判定检查正常，则表示巡检结束；

若通过监控判定检查异常，则进行告警处理并根据出错原因制定干预处置方案，等待处置完成。

在本实施例中，具体采用如下设计：

邮件程序读取log文件，以及备份文件大小信息，变动幅度，发送备份邮件；

监控平台自定义shell脚本读取err.log和end.log就能判断什么时候备份恢复完或是否因内外部等原因导致出错或终止,本次备份文件与上次大小变动幅度，差异比较。

具体参考图3-图7，程序调用邮件服务，判断对比结果是否有含有×，将异常结果以邮件、短信或其它方式通知相关方，对于不一致的记录，跟相关方确认是否异常，根据异常作必要的处理。

需要说明的是，参考图3-图7展现的是数据库备份状态流转。具体状态如下：

1.未备份：表是数据库定时备份时间未到，采集信息都为空。

2.备份完成测试中：表示备份完成，备份前库表信息已采集并落文件，变成测试中，用到此库的工作人员可以开始测试，测试完成的工作人员点击下测试结束反馈，应用是否停止Xops根据收集信息定时检测。

3.测试结束待恢复：登记的schema都已反馈测试结束，Xops检测相关应用都已停止，开始变更通知恢复数据库。

4.恢复结束待反馈：库恢复结束，数据比对检查有问题的，电话通知反馈相关方已处理。

5.恢复结束检查完成：自动检查不一致的schema，表相关负责人都已反馈，恢复结束，检查完成。

6.其他定时时间检查。

实施例3

本实施例提供一种数据库备份恢复轻量级通用检查设备，包括：

存储器，用于存储指令；

处理器，用于执行所述指令，使得所述设备执行实现如实施例1或实施例2任一所述的方法的步骤。

实施例4

本实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时，实现如实施例1或实施例2任一所述的方法的步骤。

需要说明的是，整套方案里使用的CMDB文档平台、流程平台、监控平台，实现编程语言都可以根据实际情况选择合适的，备份方式逻辑备份，物理备份都可以。

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

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，这些均属于本发明的保护之内。