一种数据备份方法及系统与流程

文档序号:33321591发布日期:2023-03-03 20:57阅读:52来源:国知局
一种数据备份方法及系统与流程

1.本发明实施例涉及数据处理技术领域,尤其涉及一种数据备份方法及系统。


背景技术:

2.随着信息技术的不断发展,所产生的数据也越来越多,对数据的安全保护也越来越重要。备份是数据安全的最后一道防线,对于任何数据丢失的场景,备份虽然不一定能恢复百分之百的数据(取决于备份周期),但至少能将损失降到最低。
3.目前,针对数据库(如kingbase数据库)的数据备份,通常是关闭数据库服务器,以暂停数据库的运行,将数据库中的数据文件和归档日志文件进行拷贝保存以实现数据库中数据的备份。但是,上述方法在备份过程中将数据库服务器关闭,会造成间断备份期间数据库所执行事务的问题;且接收什么备份指令就直接执行该备份指令,若在没有进行过完全备份的情况下就接收增量备份的指令并执行,会造成备份数据的不完整或备份失败等问题,从而影响备份的准确性和可靠性。


技术实现要素:

4.本发明实施例提供了一种数据备份方法及系统,以提高备份的准确性和可靠性。
5.根据本发明实施例的一方面,提供了一种数据备份方法,包括:
6.服务端下发备份任务至客户端,所述备份任务指示对待备份数据库实例的数据的备份;
7.所述客户端在确定所述备份任务可执行的情况下,根据所述备份任务确定目标备份任务,并将所述目标备份任务所对应的备份数据备份至所述服务端;
8.所述服务端存储所述备份数据。
9.根据本发明实施例的另一方面,提供了一种数据备份系统,所述系统包括:客户端和服务端;
10.所述服务端,用于下发备份任务至客户端,所述备份任务指示对待备份数据库实例的数据的备份;
11.所述客户端,用于在确定所述备份任务可执行的情况下,根据所述备份任务确定目标备份任务,并将所述目标备份任务所对应的备份数据备份至所述服务端;
12.所述服务端,用于存储所述备份数据。
13.本发明实施例的技术方案,首先服务端下发备份任务至客户端,备份任务指示对待备份数据库实例的数据的备份;然后客户端在确定备份任务可执行的情况下,根据备份任务确定目标备份任务,并将目标备份任务所对应的备份数据备份至服务端;最后服务端存储备份数据。该方法通过确认备份任务是否可执行,在备份任务可执行情况下又根据备份任务确定目标备份任务,执行目标备份任务以实现数据的备份,不仅能够在执行数据备份时无需暂停数据库的运行,还能够避免现有中造成备份数据的不完整或备份失败的问题,从而提高备份的准确性和可靠性。
14.应当理解,本部分所描述的内容并非旨在标识本发明的实施例的关键或重要特征,也不用于限制本发明的范围。本发明的其它特征将通过以下的说明书而变得容易理解。
附图说明
15.为了更清楚地说明本发明实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
16.图1为本发明实施例一提供的一种数据备份方法的流程示意图;
17.图2为本发明实施例二提供的一种数据备份方法的流程示意图;
18.图3为本发明实施例二提供的一种数据备份方法的实现示意图;
19.图4为本发明实施例二提供的一种数据恢复方法的实现示意图;
20.图5为本发明实施例三提供的一种数据备份系统的结构示意图。
具体实施方式
21.为了使本技术领域的人员更好地理解本发明方案,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分的实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本发明保护的范围。
22.需要说明的是,本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
23.实施例一
24.图1为本发明实施例一提供的一种数据备份方法的流程示意图,该方法可适用于对数据进行备份的情况,该方法可以由数据备份系统来执行,所述系统包括:客户端和服务端。
25.如图1所示,本发明实施例一提供的一种数据备份方法,该方法包括如下步骤:
26.s110、服务端下发备份任务至客户端。
27.在本实施例中,备份任务可以指示对待备份数据库实例的数据的备份。待备份数据库实例可理解为等待备份的数据库实例;数据库实例也可认为是指示数据库。在本实施例中,待备份数据库实例可认为是kingbase数据库。待备份数据库实例与客户端可以同属于一个电子设备(如服务器);可理解的是,服务端所属电子设备与客户端所属设备不是同一个电子设备。
28.服务端在接收到备份任务(如用户输入的备份任务)之后,可以将备份任务下发至
客户端。
29.s120、所述客户端在确定所述备份任务可执行的情况下,根据所述备份任务确定目标备份任务,并将所述目标备份任务所对应的备份数据备份至所述服务端。
30.在本实施例中,对客户端如何确定备份任务可执行不作具体限定。如客户端可以通过判断待备份数据库实例是否存在、是否处于备份中来判断备份任务是否可执行;具体的,如若待备份数据库实例不存在,则备份任务就不可执行;若待备份数据库实例存在,则可以继续判断待备份数据库实例是否处于备份中,若待备份数据库实例正在处于备份中,则待备份数据库实例不能同时进行两个备份任务,此时确定备份任务不可执行;若待备份数据库实例未处于备份中,则可以确定备份任务可执行。
31.目标备份任务可理解为最终确定要执行的备份任务。本实施例对根据备份任务确定目标备份任务也不作具体限定,可以根据不同的备份任务确定不同的目标备份任务确定方式。如,若备份任务是完全备份,则可以直接确定目标备份任务为完全备份。
32.若备份任务是增量备份,则可以通过判断待备份数据库实例之前是否执行过数据恢复和完全备份,来确定目标备份任务;具体的如,若待备份数据库实例之前执行过数据恢复,则需要重新对待备份数据库实例进行完全备份,此时可以将增量备份的备份任务转换为完全备份,即确定目标备份任务为完全备份;若待备份数据库实例之前未执行过数据恢复,则可以继续判断待备份数据库实例之前是否执行过完全备份,若执行过完全备份,表明无需再执行一次完全备份,则可以确定目标备份任务为增量备份;若未执行过完全备份,表明需执行一次完全备份,则可以将增量备份的备份任务转换为完全备份,即确定目标备份任务为完全备份。
33.其中,完全备份可理解为对数据库实例中的所有数据进行完整备份。增量备份可理解为在完全备份的基础上,对新增加的数据的备份。可理解的是,数据库实例的数据备份可以是先将数据库实例的所有数据先完全备份一次作为基础,之后每隔一段时间可以进行一次增量备份,即只备份这一段时间内新增加的数据。
34.若备份任务是日志备份,则可以通过判断待备份数据库实例之前是否执行过完全备份来确定目标备份任务;具体的,若执行过完全备份,表明无需再执行一次完全备份,则可以确定目标备份任务为日志备份;若未执行过完全备份,表明需执行一次完全备份,则可以将日志备份的备份任务转换为完全备份,即确定目标备份任务为完全备份。其中,日志备份可理解为对待备份数据库实例中的归档日志文件的备份。归档日志文件可理解为指示归档日志的文件,一个归档日志可对应一个归档日志文件。
35.备份数据可理解为对待备份数据库实例执行目标备份任务所备份得到的数据。客户端在确定备份任务可执行的情况下,根据备份任务确定目标备份任务,并可以执行目标备份任务以将目标备份任务所对应的备份数据备份至服务端。
36.s130、所述服务端存储所述备份数据。
37.在本实施例中,服务端在接收到客户端传输的备份数据之后,可以存储备份数据,以实现数据的备份。
38.本发明实施例一提供的一种数据备份方法,首先服务端下发备份任务至客户端,备份任务指示对待备份数据库实例的数据的备份;然后客户端在确定备份任务可执行的情况下,根据备份任务确定目标备份任务,并将目标备份任务所对应的备份数据备份至服务
端;最后服务端存储备份数据。该方法通过确认备份任务是否可执行,在备份任务可执行情况下又根据备份任务确定目标备份任务,执行目标备份任务以实现数据的备份,不仅能够在执行数据备份时无需暂停数据库的运行,还能够避免现有中造成备份数据的不完整或备份失败的问题,从而提高备份的准确性和可靠性。
39.实施例二
40.图2为本发明实施例二提供的一种数据备份方法的流程示意图,本实施例二在上述各实施例的基础上进行细化。在本实施例中,对确定备份任务是否可执行的过程进行了具体描述。需要说明的是,未在本实施例中详尽描述的技术细节可参见上述任意实施例。如图2所示,该方法包括:
41.如图2所示,本发明实施例二提供的一种,包括如下步骤:
42.s210、服务端下发备份任务至客户端。
43.本实施例中,备份任务可以指示对待备份数据库实例的数据的备份。
44.s220、客户端判断是否存在运行的待备份数据库实例,若是,则执行s230;否则执行s270。
45.本实施例中,客户端判断是否存在运行的待备份数据库实例,若存在运行的待备份数据库实例,则可以执行s230;若不存在运行的待备份数据库实例,则可以执行s270,即可以确定备份任务不可执行。
46.此处对如何判断是否存在运行的待备份数据库实例不作具体限定,如可以通过备份任务中所包含的指示待备份数据库实例的标识,与客户端所属电子设备中运行的各个数据库进行匹配,若能匹配到,则可以表明存在运行的待备份数据库实例;相应的,若不能匹配到,则可以表明不存在运行的待备份数据库实例。
47.s230、客户端判断待备份数据库实例是否处于备份状态,若是,则执行s270;否则执行s240。
48.本实施例中,备份状态可理解为处于备份的状态。
49.客户端判断待备份数据库实例是否处于备份状态,若待备份数据库实例处于备份状态,由于待备份数据库实例在备份的时候不能进行其他备份,故可以执行s270,即可以确定备份任务不可执行;若待备份数据库实例未处于备份状态,则可以执行s240。
50.s240、客户端获取第一数据文件夹和第一归档日志文件夹,并判断目标属主与设定用户是否一致,若是,则执行s250;否则执行s270。
51.本实施例中,第一数据文件夹可理解为当前时刻的待备份数据库实例中的数据文件夹。数据文件夹可理解为包含待备份数据库实例中所有数据文件的文件夹。
52.第一归档日志文件夹可理解为当前时刻的待备份数据库实例中的归档日志文件夹。归档日志文件夹可理解为包含待备份数据库实例中所有归档日志文件文件的文件夹。
53.目标属主可理解为第一数据文件夹和第一归档日志文件夹的属主。可理解的是,第一数据文件夹的属主和第二归档日志文件夹的属主可以是相同的。属主可理解为创建文件夹的用户。设定用户可理解为预先设定的待备份数据库实例对应的用户,如可以是kingbase用户。备份任务中可包含有设定用户的设置。
54.客户端获取待备份数据库实例中的第一数据文件夹和第一归档日志文件夹,并判断目标属主与设定用户是否一致,若目标属主与设定用户一致,则可以表明备份任务所对
应的设定用户有权限访问第一数据文件夹和第一归档日志文件夹内的内容,则可以执行s250。若目标属主与设定用户不一致,则可以表明备份任务所对应的设定用户没有权限访问第一数据文件夹和第一归档日志文件夹内的内容,则可以执行s270,即可以确定备份任务不可执行。
55.s250、客户端判断第一归档日志文件夹的空间是否大于或等于设定阈值,若是,则执行s260;否则执行s270。
56.本实施例中,设定阈值可理解为预先设定的阈值;此处对设定阈值不作具体限定,如可以是2千兆字节(giga byte,gb)或3gb等。
57.客户端判断第一归档日志文件夹的空间是否大于或等于设定阈值;由于在数据备份的过程中还会继续产生新的归档日志文件,因此需要占用第一归档日志文件夹的空间;若第一归档日志文件夹的空间大于或等于设定阈值,则可以表明第一归档日志文件夹的空间足以用于存储新的归档日志文件,则可执行s260,即确定备份任务可执行。若第一归档日志文件夹的空间小于设定阈值,则可以表明第一归档日志文件夹的空间不足以用于存储新的归档日志文件,则可执行s270,即确定备份任务不可执行。
58.s260、客户端确定备份任务可执行,继续执行s280。
59.s270、客户端确定备份任务不可执行,备份失败。
60.s280、客户端根据备份任务确定目标备份任务,并将目标备份任务所对应的备份数据备份至服务端。
61.s290、服务端存储备份数据。
62.本发明实施例二提供的一种数据备份方法,具体化了确定备份任务是否可执行的过程。该方法通过确认是否存在运行的待备份数据库实例、所存在的待备份数据库实例是否处于备份状态、目标属主是否与设定用户一致、以及第一归档日志文件夹的空间是否符合要求等,能够较为准确的确认备份任务是否可执行,以避免盲目执行备份任务以造成备份失败或备份数据不完整的情况,从而提高备份的准确性和可靠性。
63.可选的,备份任务为完全备份;根据备份任务确定目标备份任务,包括:若备份任务为完全备份,则确定目标备份任务为完全备份。
64.本实施例中,若备份任务为完全备份,则可直接确定目标备份任务为完全备份。
65.可选的,备份任务为增量备份;根据备份任务确定目标备份任务,包括:
66.若待备份数据库实例之前执行过数据恢复,则确定目标备份任务为完全备份;
67.若待备份数据库实例之前未执行过数据恢复,且待备份数据库实例存在设定插件,则判断待备份数据库实例之前是否执行过完全备份,设定插件为用于监控待备份数据库实例的增量块变化的插件;
68.若未执行过完全备份,则确定目标备份任务为完全备份;
69.若执行过完全备份,则确定第一对比结果和第二对比结果,其中,第一对比结果为对比第一数据文件夹的位置和第二数据文件夹的位置是否一致的结果,第二对比结果为对比第一归档日志文件夹的位置和第二归档日志文件夹的位置是否一致的结果,第二数据文件夹为上一次完全备份所对应备份的数据文件夹,第二归档日志文件夹为上一次完全备份所对应备份的归档日志文件夹;
70.若第一对比结果和第二对比结果均为一致,则确定目标备份任务为增量备份,否
则,确定目标备份任务为完全备份。
71.本实施例中,数据恢复可理解为基于所备份的备份数据对待备份数据库实例的数据进行恢复的过程。设定插件可理解为用于监控待备份数据库实例的增量块变化的插件;如设定插件可以为kingbase数据库中的ktrack插件。增量块可理解为增加的数据块。
72.第一对比结果可理解为对比第一数据文件夹的位置和第二数据文件夹的位置是否一致的结果。第二对比结果可理解为对比第一归档日志文件夹的位置和第二归档日志文件夹的位置是否一致的结果。第二数据文件夹可理解为上一次完全备份所对应备份的数据文件夹。第二归档日志文件夹可理解为上一次完全备份所对应备份的归档日志文件夹。
73.在本实施例中,在备份任务为增量备份的情况下,若待备份数据库实例之前执行过数据恢复,则确定目标备份任务为完全备份;若待备份数据库实例之前未执行过数据恢复,且待备份数据库实例存在设定插件,则可以判断待备份数据库实例之前是否执行过完全备份;若未执行过完全备份,则可以确定目标备份任务为完全备份;若执行过完全备份,则可以确定第一对比结果和第二对比结果。
74.由于增量备份是在完全备份的基础上备份的,因此若增量备份所对应的第一数据文件夹和完全备份所对应的数据文件夹是不一致的,增量备份所对应的第一归档日志文件夹和完全备份所对应的归档日志文件夹也是不一致的,则可能无法进行增量备份;因此若第一对比结果和第二对比结果均为一致,则可以确定目标备份任务为增量备份;否则,即第一对比结果为不一致,和/或,第二对比结果为不一致,则可以确定目标备份任务为完全备份。
75.可选的,备份任务为日志备份;根据备份任务确定目标备份任务,包括:
76.判断待备份数据库实例之前是否执行过完全备份;
77.若未执行过完全备份,则确定目标备份任务为完全备份;
78.若执行过完全备份,则确定第一对比结果和第二对比结果;
79.若第一对比结果和第二对比结果均为一致,则确定目标备份任务为日志备份,否则,确定目标备份任务为完全备份。
80.本实施例中,在备份任务为日志备份的情况下,若待备份数据库实例之前未执行过完全备份,则可以确定目标备份任务为完全备份。若待备份数据库实例之前执行过完全备份,则可以确定第一对比结果和第二对比结果;若第一对比结果和第二对比结果均为一致,则可以确定目标备份任务为日志备份;否则,可以确定目标备份任务为完全备份。
81.可选的,目标备份任务为完全备份;将目标备份任务所对应的备份数据备份至服务端,包括:
82.从第一数据文件夹中依次读取数据文件并传输数据文件至服务端,直至第一数据文件夹中不存在未被读取的数据文件;
83.从第一归档日志文件夹中依次读取归档日志文件并传输归档日志文件至服务端,直至第一归档日志文件夹中不存在未被读取的归档日志文件;
84.其中,备份数据包括第一数据文件夹中的所有数据文件和第一归档日志文件夹中的所有归档日志文件。
85.本实施例中,在目标备份任务为完全备份的情况下,可以从第一数据文件夹中依次读取数据文件并传输所读取的数据文件至服务端,直至第一数据文件夹中不存在未被读
取的数据文件,至此实现了第一数据文件夹中所有数据文件的备份。
86.在此基础上,可以继续从第一归档日志文件夹中依次读取归档日志文件并传输所读取的归档日志文件至服务端,直至第一归档日志文件夹中不存在未被读取的归档日志文件,至此实现了第一归档日志文件夹中所有第一归档日志文件的备份。
87.可选的,目标备份任务为增量备份;将目标备份任务所对应的备份数据备份至服务端,包括:
88.通过设定插件获取目标增量块信息,目标增量块信息为上一次完全备份时间点至当前时刻之间的增量块信息,上一次完全备份时间点为上一次完全备份所对应的完全备份时间点;
89.依次读取目标增量块信息对应的增量块,并传输增量块至服务端,直至目标增量块信息对应的增量块被读取完毕;
90.从待备份数据库实例中查找目标归档日志文件集合,从目标归档日志文件集合中依次读取归档日志文件,并传输归档日志文件至服务端,直至目标归档日志文件集合中不存在未被读取的归档日志文件,目标归档日志文件集合为由上一次完全备份时间点至当前时刻之间的归档日志文件所构成的集合。
91.本实施例中,目标增量块信息可理解为上一次完全备份时间点至当前时刻之间的增量块信息,也可认为是指示上一次完全备份时间点至当前时刻间这个时间段内所增加的数据块的信息。上一次完全备份时间点可理解为上一次完全备份所对应的完全备份时间点。完全备份时间点可理解为完全备份完成时所对应的时间点。
92.在目标备份任务为增量备份的情况下,可以通过设定插件获取目标增量块信息;然后依次读取目标增量块信息对应的增量块,并传输所读取的增量块至服务端,直至目标增量块信息对应的增量块被读取完毕,至此完成了增量块的备份。
93.在此基础上,可以从待备份数据库实例中查找目标归档日志文件集合,从目标归档日志文件集合中依次读取归档日志文件,并传输所读取的归档日志文件至服务端,直至目标归档日志文件集合中不存在未被读取的归档日志文件,至此完成了归档日志文件的备份。
94.其中,目标归档日志文件集合可理解为由上一次完全备份时间点至当前时刻之间的归档日志文件所构成的集合,也可认为是由上一次完全备份时间点至当前时刻间这个时间段内的所有归档日志文件所构成的集合。
95.可选的,目标备份任务为日志备份;将目标备份任务所对应的备份数据备份至服务端,包括:
96.从目标归档日志文件集合中依次读取归档日志文件,并传输归档日志文件至服务端,直至目标归档日志文件集合中不存在未被读取的归档日志文件。
97.本实施例中,在目标备份任务为日志备份的情况下,可以从目标归档日志文件集合中依次读取归档日志文件,并传输所读取的归档日志文件至服务端,直至目标归档日志文件集合中不存在未被读取的归档日志文件。
98.可选的,服务端存储备份数据,包括:在备份数据为完全备份所对应的备份数据时,服务端创建完全备份卷,将备份数据存储至完全备份卷中,并复制完全备份卷得到完全备份复制卷;
99.在备份数据为增量备份所对应的备份数据时,服务端将备份数据存储至完全备份复制卷中;
100.在备份数据为日志备份所对应的备份数据时,服务端将备份数据存储至完全备份复制卷中。
101.本实施例中,完全备份卷可理解为用于存储备份数据的数据卷。完全备份复制卷可理解为复制完全备份卷所得到的数据卷。
102.在备份数据为完全备份所对应的备份数据时,服务端可以创建完全备份卷,将备份数据存储至完全备份卷中,并复制完全备份卷得到完全备份复制卷;此处对如何复制完全备份卷不作具体限定,如可以通过实克隆技术得到完全备份卷的克隆卷,即完全备份复制卷。
103.在备份数据为增量备份所对应的备份数据时,由于完全备份是数据备份的基础,完全备份通常是在增量备份和日志备份之前执行的,故服务端可以将备份数据存储至完全备份复制卷中。
104.在备份数据为日志备份所对应的备份数据时,服务端可以将备份数据存储至完全备份复制卷中。
105.本实施例通过将备份数据存储至完全备份复制卷中,能够避免将备份数据存储至完全备份卷中而造成完全备份卷的数据更改,保留完全备份卷最初的备份数据,以在将增量备份或日志备份所对应的备份数据存储至完全备份复制卷的过程发生故障时,能够再次基于所保留的完全备份卷复制一个新的完全备份复制卷,以备用。
106.以下对本发明进行示例性说明。
107.本发明以kingbase数据库的数据备份为例进行说明。kingbase备份可包括三种方法,结构化查询语言(structured query language,sql)转储备份,文件系统级备份以及连续归档备份。
108.kingbase的sql转储方式为生成sql命令文件,通过将该sql命令文件应用到数据库服务器,将数据库的状态重建为转储时的数据库状态,kingbase自身提供了sql转储的工具以适配,sql转储可以在数据库实例运行的时候进行转储,通过sql语句的重现。但是,当数据库的数据量庞大时,sql重建因为要执行数据库对应的所有语句,所以sql转储恢复是需要消耗大量的时间,在生产数据库的恢复需要快速恢复起可以使用的数据库实例,sql转储的恢复速度太慢,不适合生产的场景。
109.kingbase文件系统级备份方式是,关闭kingbase数据库服务器,将数据目录下的所有文件进行拷贝保存,需要恢复时,将数据文件拷贝到需要恢复的机器,重启kingbase服务器即可。但在生活环境中,因为生产机器需要持续提供服务,所以文件级备份方式不适用生产业务。
110.文件系统级备份的另一种方式可以是冻结快照,支持在数据库运行时进行一致性备份,但是数据库数据文件庞大,无法同时获取所有数据卷的完全同步快照,当数据文件和wal日志位于不同的文件系统上,则可能无法使用快照备份,这种具有随机性的备份同样不适用于生产。
111.kingbase的连续归档备份是目前首选的备份技术,连续归档备份的方式是将文件系统级备份和预写日志(write ahead log,wal)归档日志文件进行组合,不需要完全一致
的文件系统备份作为恢复的起点,备份中的任何不一致都可以通过wal归档日志文件的重放进行更正,由于可以将wal归档日志文件的无限长的序列组合进行重放,只需要持续保持wal归档日志文件即可实现连续的数据备份,可以大量减少完全备份的次数。kingbase提供了备份的接口,可以根据业务场景,灵活调用底层备份应用程序编程接口(application programmer interfaces,api),实现灵活数据库实例的备份。
112.kingbase的连续归档备份虽然依赖于全量备份并具有高度灵活性,对于数据库系统奔溃也有良好的支持,但是随着生产业务的繁荣和业务规模逐渐增大,数据库实例数据文件增量庞大,kingbase连续归档依赖的全量备份,全量备份是对数据文件目录所有文件的完全备份,每次全量备份都是海量数据文件,每次备份的数据量相当大,备份所需时间随着数据文件大小不断增加,即使是小数据量的增加,进行全量备份时也必须进行全量数据文件的备份,磁盘占用和空间利用率很低,可维护性差,而且全量备份时间过长,导致wal归档日志文件的归档时间增加,对于备份的数据库实例拉起时也需要大量的时间应用wal归档日志文件,和备份快速拉起的需求冲突,难以满足生产环境快速的恢复时间目标(restore time objective,rto)需求。
113.本发明通过采用kingbase数据库ktrack块变化监控拓展插件和wal归档日志全备的方式,基于全量备份,实现了数据库备份只备份数据块级别增量数据。能够在不用关闭kingbase生产服务器、不影响kingbase对外服务的情况下,节约备份资源空间,提高空间利用率,并且能够快速拉起数据库备份实例。
114.完全备份可理解为数据库数据文件的完整文件内容的备份,基于完全备份时间点,调用ktrack插件,获取增量块信息,仅传输变化的增量数据块,合并增量数据块至完全备份卷中,统一为增量后数据库的数据文件。
115.在恢复期间,可以基于实克隆技术生成对应时间点的数据副本(即完全备份复制卷),后续的恢复作业,为了将数据库实例快速拉起,将对应的时间点的数据库数据副本通过网络文件系统(network file system,nfs)挂载协议挂载至恢复目标目录,配置kingbase数据库恢复文件,拉起数据库实例,这样的方式可以在恢复万亿字节(tera byte,tb)级别的数据时,达到秒级恢复的速度。超额满足数据库的高rto需求,再通过完整的wal归档日志文件,可以保证数据的一致性。
116.本发明通过使用kingbase拓展插件ktrack插件对于数据库增量块进行监控,使用wal归档日志文件保证数据一致性。通过备份增量块,当数据库的数据文件为tb级别,某段时间内的增量数据为gb级别,此时普通备份的备份数据量达到tb级别,而增量备份只需备份gb级别的增量数据。仅备份增量数据的方案,基础数据量越庞大,节约的存储空间越多,而且通过增量块备份生成的副本数据卷,可以达到秒级挂载,快速配置拉起数据库实例,满足客户高rto的需求场景。
117.在本发明实施例中,服务端的存储介质可认为是用于数据存放的逻辑单元,可负责管理所有的底层存储,例如磁盘、对象存储、云存储以及磁带等多种存储单元,并将其规划为一个个逻辑卷,通过提供统一适配数据的读取接口,满足数据的存取管理要求。
118.在本发明实施例中,服务端作为备份的管理控制台,可以设置有备份软件,以用于承担和用户交互的任务;同时服务端还可以统筹管理所有的资源调度,其中包含存储介质及客户端,同时负责下发备份指令或恢复指令给对应的客户端执行,接收客户端返回的数
据。服务端也可以负责和存储介质进行交互,将数据卷(即存储数据文件的数据卷)和归档日志卷(即存储归档日志文件的数据卷)进行挂载和取消挂载。
119.在备份阶段,客户端可以启动一个进程,进程启动线程以调用数据库底层备份api,以调用ktrack插件获取增量块变化,并实时备份增量块,通过网络传输至服务端存储系统的存储介质中,将增量块合并至完全备份复制卷中存储,同时实时监控wal归档日志文件的变化,wal归档日志文件夹中的增量部分(即完全备份时间点至当前时刻之间所增加的归档日志文件)同样可以通过网络传输至服务端存储系统中,存储至完全备份复制卷中。在恢复阶段(即数据恢复阶段),客户端客可以启动一个进程,进程可以在用户输入的数据挂载路径下生成挂载点,将对应的副本数据(即备份数据)挂载至挂载点,然后将完全备份的wal归档日志文件数据挂载至副本数据对应的归档日志目录(即归档日志文件夹)下。通过拉起副本数据并应用归档日志文件,实现生产数据服务的快速恢复。
120.在本发明实施例中,数据文件可以是kingbase实例(即kingbase数据库实例)的磁盘文件;其中存放表数据,可以包含有syscontrol,sysfilenode.map等关键表信息,备份物理文件主要来源于此。
121.在本发明实施例中,生产业务数据库kingbase是数据库的核心组件,负责接收数据库的sql指令,并对指令进行解析执行,然后返回执行结果,完成正常的业务访问。
122.在本发明实施例中,需要安装客户端,作为备份软件在客户端上的代理,负责和服务端进行交互,接受服务端下达的命令,并针对命令做出相应的处理,并将执行的结果返回给服务端。此处的处理代表和kingbase数据库进行交互,加载数据库,获取相关信息等。
123.在本发明实施例中,wal归档日志文件可以代表数据库的备份期间开启归档保存的全量wal归档日志,可以用于负责存放所有对于数据库更改的所有操作记录及更改的数据,wal归档日志文件的文件个数和空间大小受数据库影响。
124.在本发明实施例中,nfs主要功能是通过网络文件系统将服务端管理的快照系统中的时间点副本数据(即对完全备份时间点等进行复制后得到的副本数据)共享至客户端下,实现数据库恢复的快速拉起。
125.在本发明实施例中,实克隆可以是源卷某快照的一份真实物理复制,如果将克隆卷存放在与源卷不同的独立冗余磁盘阵列(redundant array of independent disk,raid)组中,即使源卷的riad组发生故障,那么克隆卷依然存在,可以直接将克隆卷挂载到主机继续使用:由于是存在于另一个raid组,对实克隆的读数据的输入输出(input/output,io),由于是访问不同的物理磁盘,所以不会影响到源卷。
126.在本发明实施例中,完全备份时间点可以是指完成对kingbase数据库的完全备份时的时间点。完全备份的备份数据可以包含完整的数据库数据文件和归档日志文件。
127.在本发明实施例中,增量备份时间点可以是指在存储完全备份时间点数据的基础上,合并增量块变化数据,合并形成的完整的增量备份数据时的时间点。
128.在本发明实施例中,快照系统的主要功能可以是通过存储介质中的时间点数据,使用快照功能将对应的数据文件生成一份完全相同的快照文件。
129.图3为本发明实施例二提供的一种数据备份方法的实现示意图。如图3所示,该数据备份方法的实现过程如下:
130.s1、客户端接收备份任务之后,判断是否存在运行的kingbase实例;若是则执行
s2;否则执行s20。
131.操作员在服务端所提供的可视化界面上选择需要备份保护的数据库实例(如以kingbase实例为例),并建立和发起备份任务。服务端接收用户输入的备份任务,并将备份任务下发至客户端。
132.s2、客户端判断kingbase实例是否处于备份状态,若是则执行s20;否则执行s3;
133.s3、客户端获取kingbase当前时刻的数据文件夹和kingbase当前时刻的归档日志文件夹。
134.s4、客户端判断所获取数据文件夹和归档日志文件夹的属主,与kingbase用户是否一致;若是则执行s5,否则执行s20。
135.s5、客户端判断归档日志文件夹的空间是否大于或等于设定阈值,若是则执行s6;否则执行s20。
136.s6、客户端判断备份任务是否是完全备份,若是则执行s7;否则执行s8。
137.s7、客户端备份kingbase实例中,数据文件夹中的所有数据文件和归档日志文件夹中的所有wal归档日志文件,直至备份完毕,继续执行s17。
138.s8、客户端判断备份任务是否是增量备份,若是则执行s9;否则执行s15。s9、客户端判断kingbase实例之前是否执行过数据恢复,若是则返回执行s7;否则执行s10。
139.s10、客户端判断kingbase实例中是否包含ktrack插件,若是则执行s11;否则执行s20。
140.s11、客户端判断kingbase实例之前是否执行过完全备份,若是则执行s12;否则返回执行s7。
141.客户端可以向服务端发送指示获取kingbase实例所对应完全备份时间点的请求;服务端根据这个请求去查询kingbase实例所对应的存储区域中是否包含完全备份时间点,若是包含则可以将完全备份时间点返回至客户端,若是不包含则可以返回一个空值给客户端。客户端若接收到完全备份时间点,则可表明kingbase实例之前执行过完全备份;客户端若接收到控制,则可表明kingbase实例之前未执行过完全备份。
142.s12、客户端对比当前kingbase实例的数据文件夹位置和上次完全备份时所对应数据文件夹的位置是否一致;若是则执行s13;否则返回执行s7。
143.s13、客户端对比当前kingbase实例的归档日志文件夹位置和上次完全备份时所对应归档日志文件夹的位置是否一致。在备份任务为增量备份时,若是则执行s14;否则返回执行s7。在备份任务为日志备份时,若是则执行s16;否则返回执行s7。
144.s14、备份任务为增量备份,客户端执行增量备份,将增量备份所对应备份数据备份至服务端,继续执行s17。
145.s15、客户端所接收的备份任务为日志备份,返回执行s11。
146.s16、备份任务为日志备份,客户端执行日志备份,将日志备份所对应备份数据备份至服务端,继续执行s17。
147.s17、客户端发送备份时间点至服务端存储,继续执行s18。
148.若是完全备份,则发送完全备份时间点至服务端。若是增量备份,则发送增量备份时间点至服务端。若是日志备份,则发送日志备份时间点至服务端。增量备份时间点可理解我增量备份结束时对应的时间点。日志备份时间点可理解为日志备份结束时所对应的时间
点。
149.s18、客户端删除备份记录文件,继续执行s19。
150.备份记录文件可理解为用于记录备份相关信息的文件,如可以包括备份开始时的时间点和备份结束时的时间点等。
151.s19、备份成功,清理资源,备份结束。
152.清理资源可理解为关闭掉客户端所启动的与备份任务所关联的进程和线程。
153.s20、备份失败,清理资源,备份结束。
154.图4为本发明实施例二提供的一种数据恢复方法的实现示意图。如图4所示,该数据恢复方法的实现过程如下:
155.s310、客户端接收到恢复任务之后,检查是否支持nfs挂载协议;若是则执行s320;否则执行s3120。
156.操作员在服务端所提供的可视化界面上,根据增量备份时间点创建对应的时间点副本数据(即复制一份增量备份时间点),新建挂载恢复任务,并发起恢复任务。服务端接收用户输入的恢复任务,并将恢复任务下发至客户端。客户端接收到恢复任务之后,可以创建用于执行恢复任务的进程。
157.s320、客户端检查挂载点是否存在;若是则执行s330;否则执行s3120。
158.恢复任务中可包括有挂载点。
159.s330、客户端检查挂载恢复数据库所需端口是否可用;若是则执行s340;否则执行s3120。
160.s340、客户端执行nfs挂载。
161.s350、客户端判断当前是否为第一次挂载,若是则执行s360;否则执行s370。
162.s360、客户端新建恢复任务所对应的数据库恢复配置文件,继续执行s390。
163.数据库恢复配置文件可包括恢复的时间点、恢复对应的数据库拉起端口以及拷贝归档日志文件的命令等信息。
164.s370、客户端判断是否修改数据库拉起端口,若是则执行s380;否则执行s390。
165.恢复任务中可包括有所配置的数据库拉起端口,客户端可恢复任务中所指示的端口和当前数据库恢复配置文件中所配置的端口进行对比,若是不一致,则需要修改数据库拉起端口;若是一致则不需要修改。
166.s380、客户端修改数据库恢复配置文件,继续执行s390。
167.客户端可以将数据库恢复配置文件中的数据库拉起端口修改为恢复任务中所指示的端口。
168.s390、客户端判断是否直接拉起kingbase数据库;若是则执行s3100,否则执行s3110。
169.s3100、客户端拉起数据库实例,进行数据库恢复。
170.s3110、客户端挂载成功,清理资源,恢复任务结束。
171.s3120、客户端挂载失败,清理资源,恢复任务结束。
172.清理资源可理解为关闭掉客户端所启动的与恢复任务所关联的进程和线程。
173.本发明实施例所提供的数据备份方法,可以直接复制数据库实例中的数据文件,安全可靠。在执行数据备份时无需关闭数据库的运行,保证在备份期间执行的事务不会间
断,备份数据不会影响业务。备份期间只是读取数据库中的数据进行备份,并不会增加数据库的性能压力。只备份增量数据可以有效地节约服务端的存储空间,消除大量冗余备份数据。只备份增量数据可以实现在tb级别基础数据文件和gb级别变化量场景下,仅备份gb级别数据,缩减tb级别数据的备份时间。
174.本发明实施例所提供的数据恢复方法,通过挂载恢复克隆副本数据(即完全备份复制卷),tb级别数据可以达到秒级恢复,实现超高恢复rto。通过挂载全量的归档日志文件,可以保证数据的一致性。
175.实施例三
176.图5为本发明实施例三提供的一种数据备份系统的结构示意图。如图5所示,该数据备份系统包括:客户端410和服务端420;
177.服务端420,用于下发备份任务至客户端410,备份任务指示对待备份数据库实例的数据的备份;
178.客户端410,用于在确定备份任务可执行的情况下,根据备份任务确定目标备份任务,并将目标备份任务所对应的备份数据备份至服务端420;
179.服务端420,用于存储所述备份数据。
180.本实施例所提供的数据备份系统,首先服务端下发备份任务至客户端,备份任务指示对待备份数据库实例的数据的备份;然后客户端在确定备份任务可执行的情况下,根据备份任务确定目标备份任务,并将目标备份任务所对应的备份数据备份至服务端;最后服务端存储备份数据。该系统通过确认备份任务是否可执行,在备份任务可执行情况下又根据备份任务确定目标备份任务,执行目标备份任务以实现数据的备份,不仅能够在执行数据备份时无需暂停数据库的运行,还能够避免现有中造成备份数据的不完整或备份失败的问题,从而提高备份的准确性和可靠性。
181.可选的,确定所述备份任务是否可执行的操作,包括:
182.判断是否存在运行的待备份数据库实例;
183.若不存在运行的待备份数据库实例,则确定所述备份任务不可执行;
184.若存在运行的待备份数据库实例,则判断所述待备份数据库实例是否处于备份状态;
185.若处于备份状态,则确定所述备份任务不可执行;
186.若不处于备份状态,则获取第一数据文件夹和第一归档日志文件夹,并判断目标属主与设定用户是否一致,其中,所述第一数据文件夹为当前时刻的所述待备份数据库实例中的数据文件夹,所述第一归档日志文件夹为当前时刻的所述待备份数据库实例中的归档日志文件夹,所述目标属主为所述第一数据文件夹和所述第一归档日志文件夹的属主;
187.若不一致,则确定所述备份任务不可执行;
188.若一致,则判断所述第一归档日志文件夹的空间是否大于或等于设定阈值;
189.若小于设定阈值,则确定所述备份任务不可执行;
190.若大于或等于设定阈值,则确定所述备份任务可执行。
191.可选的,所述备份任务为完全备份;
192.根据所述备份任务确定目标备份任务,包括:
193.若所述备份任务为完全备份,则确定目标备份任务为完全备份。
194.可选的,所述备份任务为增量备份;
195.根据所述备份任务确定目标备份任务,包括:
196.若所述待备份数据库实例之前执行过数据恢复,则确定目标备份任务为完全备份;
197.若所述待备份数据库实例之前未执行过数据恢复,且所述待备份数据库实例存在设定插件,则判断所述待备份数据库实例之前是否执行过完全备份,所述设定插件为用于监控所述待备份数据库实例的增量块变化的插件;
198.若未执行过完全备份,则确定目标备份任务为完全备份;
199.若执行过完全备份,则确定第一对比结果和第二对比结果,其中,所述第一对比结果为对比所述第一数据文件夹的位置和第二数据文件夹的位置是否一致的结果,所述第二对比结果为对比所述第一归档日志文件夹的位置和第二归档日志文件夹的位置是否一致的结果,所述第二数据文件夹为上一次完全备份所对应备份的数据文件夹,所述第二归档日志文件夹为上一次完全备份所对应备份的归档日志文件夹;
200.若第一对比结果和第二对比结果均为一致,则确定目标备份任务为增量备份,否则,确定目标备份任务为完全备份。
201.可选的,所述备份任务为日志备份;
202.根据所述备份任务确定目标备份任务,包括:
203.判断所述待备份数据库实例之前是否执行过完全备份;
204.若未执行过完全备份,则确定目标备份任务为完全备份;
205.若执行过完全备份,则确定第一对比结果和第二对比结果;
206.若第一对比结果和第二对比结果均为一致,则确定目标备份任务为日志备份,否则,确定目标备份任务为完全备份。
207.可选的,所述目标备份任务为完全备份;
208.将所述目标备份任务所对应的备份数据备份至服务端420,包括:
209.从第一数据文件夹中依次读取数据文件并传输所述数据文件至服务端420,直至所述第一数据文件夹中不存在未被读取的数据文件;
210.从第一归档日志文件夹中依次读取归档日志文件并传输所述归档日志文件至服务端420,直至所述第一归档日志文件夹中不存在未被读取的归档日志文件;
211.其中,所述备份数据包括所述第一数据文件夹中的所有数据文件和所述第一归档日志文件夹中的所有归档日志文件。
212.可选的,所述目标备份任务为增量备份;
213.将所述目标备份任务所对应的备份数据备份至服务端420,包括:
214.通过设定插件获取目标增量块信息,所述目标增量块信息为上一次完全备份时间点至当前时刻之间的增量块信息,所述上一次完全备份时间点为上一次完全备份所对应的完全备份时间点;
215.依次读取所述目标增量块信息对应的增量块,并传输所述增量块至服务端420,直至所述目标增量块信息对应的增量块被读取完毕;
216.从所述待备份数据库实例中查找目标归档日志文件集合,从所述目标归档日志文件集合中依次读取归档日志文件,并传输所述归档日志文件至服务端420,直至所述目标归
档日志文件集合中不存在未被读取的归档日志文件,所述目标归档日志文件集合为由上一次完全备份时间点至当前时刻之间的归档日志文件所构成的集合。
217.可选的,所述目标备份任务为日志备份;
218.将所述目标备份任务所对应的备份数据备份至服务端420,包括:
219.从目标归档日志文件集合中依次读取归档日志文件,并传输所述归档日志文件至服务端420,直至所述目标归档日志文件集合中不存在未被读取的归档日志文件。
220.可选的,服务端420存储所述备份数据,包括:
221.在备份数据为完全备份所对应的备份数据时,服务端420,用于创建完全备份卷,将所述备份数据存储至所述完全备份卷中,并复制所述完全备份卷得到完全备份复制卷;
222.在备份数据为增量备份所对应的备份数据时,服务端420,用于将所述备份数据存储至所述完全备份复制卷中;
223.在备份数据为日志备份所对应的备份数据时,服务端420,用于将所述备份数据存储至所述完全备份复制卷中。
224.本实施例三提供的一种数据备份系统可以用于执行上述任意实施例提供的数据备份方法,具备相应的功能和有益效果。
225.应该理解,可以使用上面所示的各种形式的流程,重新排序、增加或删除步骤。例如,本发明中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行,只要能够实现本发明的技术方案所期望的结果,本文在此不进行限制。
226.上述具体实施方式,并不构成对本发明保护范围的限制。本领域技术人员应该明白的是,根据设计要求和其他因素,可以进行各种修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等,均应包含在本发明保护范围之内。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1