CN103136070B - 一种数据容灾处理的方法和装置 - Google Patents
一种数据容灾处理的方法和装置 Download PDFInfo
- Publication number
- CN103136070B CN103136070B CN201110391482.4A CN201110391482A CN103136070B CN 103136070 B CN103136070 B CN 103136070B CN 201110391482 A CN201110391482 A CN 201110391482A CN 103136070 B CN103136070 B CN 103136070B
- Authority
- CN
- China
- Prior art keywords
- database
- disk
- data
- log recording
- online log
- 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.)
- Active
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请提供了一种数据容灾处理的方法和装置,所述数据容灾涉及采用通信链路相连的第一系统与第二系统之间的数据备份处理,所述第一系统包括第一数据主机,第一数据库和第一存储设备,所述第二系统包括第二数据主机,第二数据库和第二存储设备;在所述第一数据库中的第一磁盘和第四磁盘同步记录相同的在线日志记录并向第二系统传送,若第二系统未收到所述在线日志记录,则执行以下步骤:判断所述第一数据库是否可访问;若否,则判断所述第一数据主机是否可访问;若否,则通过第二数据主机激活位于第一数据库中的第四磁盘,并在所述第四磁盘中定位所述在线日志记录。本申请可以在确保主库高可用性的前提下,实现数据的零丢失。
Description
技术领域
本申请涉及数据安全的技术领域,特别是涉及一种数据容灾处理的方法和一种数据容灾处理的装置。
背景技术
数据容灾,就是指建立一个异地的数据系统,该系统是本地关键应用数据的一个可用复制。在本地数据及整个应用系统出现灾难时,系统至少在异地保存有一份可用的关键业务的数据。该数据可以是与本地生产数据的完全实时复制,也可以比本地数据略微落后,但一定是可用的。其采用的主要技术是数据备份和数据复制技术。数据容灾的处理,实际上是异地数据复制的处理。
以Oracle数据库(Oracle Database,又名Oracle RDBMS,或简称Oracle)的数据容灾为例,Oracle数据库为保证高可用性,高可靠性,在同城的两个机房内分别部署主库(主数据库)和备库(备份数据库),并使用Oracle DataGuard(Oracle数据保护)技术进行主库和备库间的数据同步,为了确保主库的高可用性,DataGuard使用MaxPerformace模式,即以异步的方式将主库日志信息写到备库。
数据同步的基本流程是当主库产生日志时,通过事先配置的传送方式,以同步或者异步的方式传送到备库,备库通过恢复进程将日志进行应用,实现主库备库间的数据复制。现有的Oracle DataGurad技术提供了三种标准数据复制的方式,即MaxPerformance(最大持久化)模式、MaxAvailability(最大可行性)模式和MaxProtection(最大保护度)模式。
具体而言,采用MaxPerformance模式,主库向备库传递日志的方式是异步的,也就是说,当主库的数据产生变化时,主库在保证本地日志文件写完毕后,不会等待远端备库正确、完整地接收了日志文件,就会继续完成后续的数据更新请求,如果此时主数据库发生故障,而备库没有完整的接收日志文件,则会发生数据丢失的情况。
采用MaxProtection和MaxAvailability模式,主库向备库传递日志的方式都是同步的,也就是说,当主库的数据产生变化时,主库在确保本地及远程全部正确接收日志前,是不会进行后续数据处理的,即可实现数据的零丢失。但MaxProtection模式下,当备库出现问题时,即备库无法接收日志文件时,主库将自动关闭,即备库的状态将会影响到主库,导致主库的高可用性得不到保障。再者,在MaxProtection模式和MaxAvailability模式下,日志的传送都是通过网络的,网络具有一定的不稳定性,如延迟现象,在高并发、高压力的应用环境下,主库容易受到备库接收日志的影响,造成主库运行缓慢。
综上,采用现有的Oracle DataGurad技术,其中的MaxPerformance模式将无法保证数据的零丢失,而MaxAvailability模式和MaxProtection模块无法保证数据库主库在高并发压力下数据库的持续稳定,即无法保证数据库主库的高可用性。
因此,目前需要本领域技术人员迫切解决的一个技术问题就是:提出一种全新的数据容灾处理机制,用以在确保主库高可用性的前提下,实现数据的零丢失。
发明内容
本申请的目的是提供一种数据容灾处理的方法和装置,用以在确保主库高可用性的前提下,实现数据的零丢失。
为了解决上述问题,本申请公开了一种数据容灾处理的方法,所述数据容灾涉及采用通信链路相连的第一系统与第二系统之间的数据备份处理,所述第一系统包括第一数据主机,第一数据库和第一存储设备,所述第二系统包括第二数据主机,第二数据库和第二存储设备;所述第一存储设备在第一数据库中分配第一磁盘,在第二数据库中分配第二磁盘;第二存储设备在第二数据库中分配第三磁盘,在第一数据库中分配第四磁盘;
在所述第一数据库中的第一磁盘和第四磁盘同步记录相同的在线日志记录并向第二系统传送,若第二系统未收到所述在线日志记录,则执行以下步骤:
判断所述第一数据库是否可访问;
若否,则判断所述第一数据主机是否可访问;
若否,则通过第二数据主机激活位于第一数据库中的第四磁盘,并在所述第四磁盘中定位所述在线日志记录。
优选的,所述的方法,还包括:
当所述第一数据库不可访问,但所述第一数据主机可以访问时,通过所述第一数据主机提取所述在线日志记录的信息,并依据所述在线日志记录的信息在第一数据库中定位所述在线日志记录。
优选的,根据第一数据库的数据变更在所述第一磁盘和第四磁盘同步记录在线日志记录,所述的方法还包括:
根据所述定位的在线日志记录,对第二数据库进行相应的数据变更。
优选的,所述第一系统为主系统,所述第一数据库为主库,所述第二系统为备系统,所述第二数据库为备库,所述的方法还包括:
切换所述第二数据库为新的主库。
优选的,所述的方法,还包括:
当所述第一数据库和第一数据主机可访问时,切换所述第一数据库为新的备库;
打开所述新的主库接收访问,并重置在线日志记录的传递关系为,在第二数据库的第二磁盘和第三磁盘同步记录相同的在线日志记录并向第一系统传递。
优选的,所述第二系统还采用通信链路与第三系统相连,所述第三系统中包括第三数据库、第三数据主机和第三存储设备,第二存储设备在第二数据库中分配第五磁盘,在第三数据库中分配第六磁盘;所述第三存储设备在第三数据库中分配第七磁盘,在第二数据库中分配第八磁盘,所述第七磁盘和第八磁盘被同步写入相同的在线日志记录;
所述的方法,还包括:
切换所述第三数据库为新的备库;
打开所述新的主库接收访问,并重置在线日志记录的传递关系为,在第二数据库的第五磁盘和第八磁盘同步记录相同的在线日志记录并向第三系统传递。
优选的,所述的方法,还包括:
若所述第一数据库可以访问,则在作为主库的第一数据库上发起切换请求,依据该请求关闭并重启所述第一数据库;
若作为备库的第二数据库可接收访问,则将所述第二数据库切换为新的主库;
打开所述新的主库接收访问,并重置在线日志记录的传递关系为,在第二数据库的第二磁盘和第三磁盘同步记录相同的在线日志记录并向第一系统传递。
本申请实施例还公开了一种数据容灾处理的装置,包括采用通信链路相连的第一系统与第二系统;
其中,所述第一系统包括第一数据主机,第一数据库和第一存储设备,所述第二系统包括第二数据主机,第二数据库和第二存储设备;所述第一存储设备在第一数据库中分配第一磁盘,在第二数据库中分配第二磁盘;第二存储设备在第二数据库中分配第三磁盘,在第一数据库中分配第四磁盘;
所述装置还包括:
第一日志记录模块,用于在所述第一数据库中的第一磁盘和第四磁盘同步记录相同的在线日志记录;
日志传送模块,用于在所述在线日志记录在第一数据库中记录完后向第二系统传送;
日志恢复模块,用于在第二系统未收到所述在线日志记录时,调用以下子模块:
数据库访问判断子模块,用于判断所述第一数据库是否可访问;若否,则触发数据主机访问判断子模块;
主机访问判断子模块,用于判断所述第一数据主机是否可访问;若否,则触发激活定位子模块;
激活定位子模块,用于通过第二数据主机激活位于第一数据库中的第四磁盘,并在所述第四磁盘中定位所述在线日志记录。
优选的,所述日志恢复模块还包括:
日志提取子模块,用于在所述第一数据库不可访问,但所述第一数据主机可以访问时,通过所述第一数据主机提取所述在线日志记录的信息,并依据所述在线日志记录的信息在第一数据库中定位所述在线日志记录。
优选的,所述第一系统为主系统,所述第一数据库为主库,所述第二系统为备系统,所述第二数据库为备库,所述的装置还包括:
主库切换模块,用于切换所述第二数据库为新的主库。
与现有技术相比,本申请包括以下优点:
本申请通过对架构的调整,采用通信链路替代原来的以太网络,现有技术中数据库依赖很不稳定的网络层实现,以太网络环境的不稳定将导致本申请实施例在现实中无法有效实施。若通过光纤链路替代原来的以太网络,利用数据库在线日志组在本地同步写的特点和光纤网络高吞吐量低延迟的特点,应用本申请实施例的数据库容灾架构及恢复流程,即可满足在高并发压力下数据零丢失的需求,即兼顾数据的零丢失和高可用性。
附图说明
图1是本申请的一种数据容灾处理所涉及的硬件架构的结构框图;
图2是本申请一种数据容灾处理硬件架构的结构示意图;
图3是本申请的一种数据容灾处理硬件架构中存储设备与数据库的结构示意图;
图4是本申请基于上述数据容灾处理的硬件架构提出的一种数据容灾处理的方法实施例1的步骤流程图;
图5是本申请的一种数据容灾处理的方法实施例2的步骤流程图;
图6是本申请基于上述数据容灾处理的硬件架构提出的一种数据容灾处理的方法实施例3的步骤流程图;
图7是本申请的一种数据容灾处理的装置实施例的结构框图。
具体实施方式
为使本申请的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本申请作进一步详细的说明。
参照图1,其示出了本申请的一种数据容灾处理所涉及的硬件架构的结构框图,具体可以包括第一系统11和第二系统12,其中,所述第一系统11可以包括第一数据主机111,第一数据库112和第一存储设备113,所述第二系统12可以包括第二数据主机121,第二数据库122和第二存储设备123;所述第一存储设备113在第一数据库112中分配有第一磁盘1121,在第二数据库122中分配有第二磁盘1221;第二存储设备123在第二数据库122中分配有第三磁盘1222,在第一数据库中分配有第四磁盘1122。所述第一系统11和第二系统12之间采用通信延时非常短(如不超过1毫秒)的通信链路相连。
参照图2所示的数据容灾处理硬件架构的结构示意图,在具体实现中,所述第一系统11和第二系统12可以为同城的两个机房A和B的系统,所述第一数据库和第二数据库可以为Oracle数据库,所述第一数据主机和第一数据库可以设置在第一服务器110内,所述第二数据主机和第二数据库可以设置在第二服务器120内,这两个机房系统可以通过光纤交换机13互联,构成一个大的光纤网络,两个机房系统中的服务器和存储设备通过这个光纤网络实现相互连接,即所述第一服务器110通过所述光纤网络与第一存储设备113连接,所述第二服务器120通过所述光纤网络与第二存储设备123连接。
在具体实现中,Oracle数据库可以通过Online Redo Log file Group(在线日志组)记录数据变化,其中,每个在线日志组包括多个日志成员(Member),多个日志成员间的数据(内容)保持一致,而且同一个日志组中的日志成员的写入是同步的。可以将不同的日志成员放在不同的磁盘上,以实现容灾。所述多个日志组Group循环使用,如数据库有三组日志组,分别是A,B,C,则写入顺序为A->B->C->A->B->……。
参照图3所示的数据容灾处理硬件架构中存储设备与数据库的结构示意图,所述第一存储设备113在第一数据库112中分配有放在第一磁盘1121中的日志成员redo1,在第二数据库122中分配有放在第二磁盘1221中的日志成员redo2;第二存储设备123在第二数据库122中分配有放在第三磁盘1222中的日志成员redo3,在第一数据库中分配有放在第四磁盘1122中的日志成员redo4。在这种情形中,第一数据库112中有两个日志成员redo1和redo4,redo1是由第一存储设备分配的,redo4是由第二存储设备分配的,redo1和redo4被第一数据主机同步写入相同的在线日志记录;第二数据库122中有两个日志成员redo2和redo3,redo2是由第一存储设备分配的,redo3是由第二存储设备分配的,在第二系统被切换为主系统时,redo2和redo3被第二数据主机同步写入相同的在线日志记录。
需要说明的是,第一系统通过网络向第二系统传递的日志文件,第二系统并不是保存在第二磁盘和第三磁盘上,而是保存在第二数据库上的其他磁盘上,以供第二系统恢复。第二系统的第二磁盘和第三磁盘,当其为备库角色时是没有使用到的,只有在其是主库角色时,用于写入在线日志文件才起到作用。
参照图4所示的,本申请基于上述数据容灾处理的硬件架构提出的一种数据容灾处理的方法实施例1,其步骤包括:
步骤41、在所述第一数据库中的第一磁盘和第四磁盘同步记录相同的在线日志记录并向第二系统传送,若第二系统未收到所述在线日志记录,则执行步骤42~44;
在线日志文件可以用于保护数据丢失,数据库在任何数据变更时都会先将变更日志作为在线日志记录写入在线日志文件。参考图3,采用本步骤,当第一数据库发生数据变更时,会在日志成员redo1和redo4中同步记录相同内容的在线日志记录,在某个在线日志记录记录完成后,便传送至第二系统。
步骤42、判断所述第一数据库是否可访问;若否,则执行步骤43;
步骤43、判断所述第一数据主机是否可访问;若否,则执行步骤44;
步骤44、通过第二数据主机激活位于第一数据库中的第四磁盘,并在所述第四磁盘中定位所述在线日志记录。
根据上述步骤41可以得知,第一系统向第二系统传递在线日志记录的方式是异步的,也就是说,当第一系统的数据产生变化时,在保证第一系统本地的在线日志记录记录完毕后,不会等待第二系统是否正确完整地接收了在线日志记录,如果此时第一数据库发生故障,如电源故障,而第二系统没有完整地接收在线日志记录,则会发生数据丢失的情况。
针对这种情况,本申请实施例提出了在第一数据主机发生故障,并且第一数据库也发生故障时的处理机制,简而言之,即在所述第一数据库不可访问,且所述第一数据主机也不可访问的情况下,在第二数据主机上将其对应的第二存储设备分配给第一数据库中的第四磁盘(日志成员redo4)激活,并在所述第四磁盘中查找到第一数据主机写入的在线日志记录(未传递的在线日志记录),以确保第二数据库能获得对应的在线日志记录,进而实现数据的零丢失。
具体而言,由于第二系统的第二存储设备在第一数据库中分配有第四磁盘(日志成员redo4),即所述第四磁盘虽然是与第二数据主机连接的第二存储设备中的磁盘,但其位于第一数据库中,接受第一数据主机的在线日志记录,即所述第四磁盘中记录了第一数据主机在传递所述在线日志记录之前写入的日志信息。因此,在当在线日志记录未能传递到第二系统,但第一数据库和第一数据主机均不可访问的情况下,可以通过在第二数据主机上执行相应的操作系统命令激活所述第四磁盘。以IBM AIX操作系统为例,激活所述磁盘的命令为varyonvg。
激活所述磁盘后,则可以定位当前第二系统缺失的在线日志记录,如通过Oracle数据库提供的视图,确定缺失的在线日志记录,具体可以采用如下代码:
SELECT THREAD#,LOW_SEQUENCE#,HIGH_SEQUENCE#FROM V$ARCHIVE_GAP;
THREAD#LOW_SEQUENCE#HIGH_SEQUENCE#;
1 90 92
根据上述sequence#号码,可以通过ftp或scp的方式,从第一数据库的第四磁盘中定位到相应的在线日志记录。
在具体实现中,可能缺失的日志文件主要有历史日志文件和在线日志文件两种。例如,第一数据库当前已有1~100号日志文件,第二数据库当前仅有1~97号日志文件,则98、99号日志文件为历史日志文件,100为当前的在线日志记录。
在实际应用中,第一系统向第二系统传递日志信息主要是通过网络异步方式传送,第二系统一般只会缺少第一系统正在写的在线日志文件的一部分,即该在线日志文件中的一部分在先日志记录。首先,历史日志文件第二系统已经获取,比如第一系统目前的在线日志文件为100,则前99个日志文件可以称为历史日志文件,这部分第二系统都已经通过网络方式获取了。历史日志文件缺失及补救不是本申请考虑的重点,在实际中有多种解决方法,本领域技术人员采用现有技术中的任一种方法均可。本申请关注的是当前在线日志记录的缺失及补救的情况。
针对第100号在线日志文件,第一系统是在不断地边写入边向第二系统传递,但这个动作时异步的,第一系统不能保证写入第100号在线日志文件的内容都已经传递到第二系统,本申请就是为了保护这部分还没有传递到第二系统的在线日志记录,即在当第一系统故障时,对于未传递到第二系统的第100号日志文件中的相应部分的在线日志记录,通过在第二数据主机上激活第二存储设备分配给第一数据库的第四磁盘,定位对应的在线日志记录。
作为本申请实施例具体应用的一种示例,所述第二数据库在第四磁盘中定位所述在线日志记录的操作可以通过如下代码实现:
recover standby database until cancel;
Specify log:{<RET>=suggested|filename|AUTO|CANCEL};
/u01/oracle/oradata/bmw/redo01_???;
Log applied.
Media recovery complete.
在本申请的一种优选实施例中,还可以包括如下步骤:
步骤45、根据所述定位的在线日志记录,对第二数据库进行相应的数据变更。
如前所述,定位在线日志记录的目的是为了实现数据库中数据的零丢失。在本实施例中,在线日志记录是根据第一数据库的数据变更在所述第一磁盘和第四磁盘同步记录的,当所述在线日志记录未能传递到第二系统时,只要第二数据主机能够定位到所述在线日志记录,即可根据该在线日志记录对第二数据库中的相应数据进行对应变更。
在实际中,可以先激活第二数据库,如采用如下代码激活第二数据库:alter database activate standby database;再根据当前所定位的在线日志记录对第二数据库的相应数据进行对应的变更。
为使本领域技术人员更好地理解本发明,以下通过一个具体应用的示例进行说明。
假设有两个机房,分别为机房A和机房B,两个机房通过光纤交换机互连,在机房A中部署有数据主机A,数据库A和存储设备A,所述数据主机A,数据库A和存储设备A通过光纤网络相连,在机房B中部署有主机B,数据库B和存储设备B,所述数据主机B,数据库B和存储设备B通过光纤网络相连。
两个存储设备分别向两个数据库分配两个磁盘,其中一个磁盘分配给本地机房数据库,另一个磁盘分配给远程机房数据库。即所述存储设备A在数据库A中分配第一磁盘,在数据库B中分配第二磁盘;所述存储设备B在数据库B中分配第三磁盘,在A数据库中分配第四磁盘;数据主机在创建在线日志组时,确保其中一个日志成员位于本地存储设备分配的磁盘,另一个日志成员位于远程存储设备分配的磁盘。在这种情况下,数据库A有两个日志成员redo1和redo4,redo1位于存储设备A分配的第一磁盘,redo4位于存储设备B分配的第四磁盘,redo1和redo4被数据主机A同步写入相同的在线日志记录;数据库B中有两个日志成员redo2和redo3,redo2位于存储设备A分配的第二磁盘,redo3位于存储设备B分配的第三磁盘。
根据Oracle数据库的特性,任何数据库中的数据修改都会在修改真实数据前,将数据修改的内容写入在线日志记录,同时一个在线日志组内的各个日志成员间是同步写入,其内容完全一致。
当机房A发生故障时,机房B的数据主机B可以激活当初分配给机房A的第四磁盘,获取redo4中记录的在线日志记录,然后根据该在线日志记录恢复数据库B,从而实现数据库B与数据库A中的数据完全一致,实现数据零丢失。
参照图5,其示出了本申请的一种数据容灾处理的方法实施例2的步骤流程图,所述数据容灾涉及采用通信链路相连的主系统与备系统之间的数据备份处理,所述主系统包括主数据主机,主库和主存储设备,所述备系统包括备数据主机,备库和备存储设备;所述主存储设备在主库中分配第一磁盘,在备库中分配第二磁盘;所述备存储设备在备库中分配第三磁盘,在主库中分配第四磁盘。
本实施例具体可以包括如下步骤:
步骤51、在所述主库中的第一磁盘和第四磁盘同步记录相同的在线日志记录并向备系统传送,若备系统未收到所述在线日志记录,则执行步骤52~56;
步骤52、判断所述主库是否可访问;若否,则执行步骤54;
步骤53、判断所述主数据主机是否可访问;若否,则执行步骤55;
步骤54、通过备数据主机激活位于主库中的第四磁盘,并在所述第四磁盘中定位所述在线日志记录;
步骤55、根据所述定位的在线日志记录,对备库进行相应的数据变更;
步骤56、切换所述备库为新的主库。
本实施例可以在当前主库和主数据主机不可访问的情况下,通过备数据主机定位到未传递到备系统的在线日志记录,并根据该在线日志记录对备库进行数据变更,然后将正常工作的备库切换为新的主库。
在具体实现中,本实施例还可以包括如下步骤:
步骤57、当所述主数据库和主数据主机可访问时,切换所述主库为新的备库;
步骤58、打开所述新的主库接收访问,并重置在线日志记录的传递关系为,在新主库的第二磁盘和第三磁盘同步记录相同的在线日志记录并向新备库传递。
应用本实施例,可以置换系统的主备关系,即在主系统出现的故障的情况下,将原来的备系统切换为主系统,而在原来的主系统恢复正常(可接受访问)后,将其切换为备系统,并重置其日志传递关系。
在实际中,若主系统在一定时间内未能恢复正常或在其他情况下,备系统也可以与其它相连的系统重置主备关系。例如,所述备系统还采用通信链路与第三系统相连,所述第三系统中包括第三数据库、第三数据主机和第三存储设备,备存储设备在备库中分配有第五磁盘,在第三数据库中分配有第六磁盘;所述第三存储设备在第三数据库中分配有第七磁盘,在备库中分配有第八磁盘,所述第七磁盘和第八磁盘被同步写入相同的在线日志记录;
在这种情况下,则可以通过以下步骤重置系统间的主备关系:
切换所述备库为新的主库,切换所述第三数据库为新的备库;
打开所述新的主库接收访问,并重置在线日志记录的传递关系为,在备库的第五磁盘和第八磁盘同步记录相同的在线日志记录并向第三系统传递。
可以理解,本申请实施例不仅适用于同城双机房的部署,还适用于不限位置范围的多机房部署,或者单机房内多服务器之间的部署,但需要保证机房之间通信链路的延时非常短,如在1毫秒之内。就目前的技术而言,所述通信链路可以采用光纤链路以保证所述延时,主库与备库可以采用通用的Oracle数据库。现有技术中Oracle数据库依赖很不稳定的网络层实现,以太网络环境的不稳定将导致本申请实施例在现实中无法有效实施。若通过光纤链路替代原来的以太网络,利用Oracle数据库在线日志组在本地同步写的特点和光纤网络高吞吐量低延迟的特点,应用本申请实施例的数据库容灾架构及恢复流程,即可满足在高并发压力下数据零丢失的需求,即兼顾数据的零丢失和高可用性。
参照图6所示的,本申请基于图1、图2和图3所示的数据容灾处理的硬件架构,提出了一种数据容灾处理的方法实施例3,其步骤包括:
步骤61、在所述第一数据库中的第一磁盘和第四磁盘同步记录相同的在线日志记录并向第二系统传送,若第二系统未收到所述在线日志记录,则执行步骤62~67;
步骤62、判断所述第一数据库是否可访问;若是,则执行步骤63;若否,则执行步骤64;
在实际中,可以通过一个测试账号,循环访问所述第一数据库,查询某个测试数据,当可以取得数据时,即可判定该第一数据库可访问;当无法取得数据时,即可判定该第一数据库发生故障,不可访问。
步骤63、执行主备库切换(switchover)的操作,具体可以包括如下执行子步骤:
子步骤S11、若所述第一数据库可以访问,则在作为主库的第一数据库上发起切换请求,依据该请求关闭并重启所述第一数据库;
子步骤S12、若作为备库的第二数据库可接收访问,则将所述第二数据库切换为新的主库;
子步骤S13、打开所述新的主库接收访问,并重置在线日志记录的传递关系为,在第二数据库的第二磁盘和第三磁盘同步记录相同的在线日志记录并向第一系统传递。
以Oracle数据库执行switchover为例,需要在主库和备库上执行的命令及操作如下:
1)在主库上发起切换:
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICALSTANDBY;
2)关闭并重启原主库:
SQL>SHUTDOWN IMMEDIATE;
SQL>STARTUP MOUNT;
3)确认备库可切换:
SELECT SWITCHOVER_STATUS FROM V$DATABASE;
4)切换备库为新主库:
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
5)打开新主库接收访问:
ALTER DATABASE OPEN;
6)如果需要,可以重新配置日志传送关系为从新主库到新备库。
步骤64、判断所述第一数据主机是否可访问;若是,则执行步骤65;若否,则执行步骤66;
一般而言,数据主机可以包括主机名,主机IP,数据库名称等信息,在实际中,可以通过ssh主机名,验证数据主机是否可以登录访问。
步骤65、通过所述第一数据主机提取所述在线日志记录的信息,并依据所述在线日志记录的信息在第一数据库中定位所述在线日志记录,然后转步骤67;
在第一数据主机未发生故障的情况下,可以直接通过第一数据主机从操作系统层面定位当前未传递给第二系统的在线日志记录,如通过Oracle数据库提供的视图,确定缺少的在线日志记录,具体可以采用如下代码:
SELECT THREAD#,LOW_SEQUENCE#,HIGH_SEQUENCE#FROM V$ARCHIVE_GAP;
THREAD#LOW_SEQUENCE#HIGH_SEQUENCE#;
1 90 92
根据上述sequence#号码,可以通过ftp或scp的方式,从第一数据库的第一磁盘中定位到相应的在线日志记录。
步骤66、通过第二数据主机激活位于第一数据库中的第四磁盘,并在所述第四磁盘中定位所述在线日志记录,然后转步骤67;
步骤67、根据所述定位的在线日志记录,对第二数据库进行相应的数据变更。
需要说明的是,对于方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本申请并不受所描述的动作顺序的限制,因为依据本申请,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本申请所必须的。
再者,上述各个方法实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。
参照图7,其示出了本申请的一种数据容灾处理的装置实施例的结构框图,本装置实施例基于如图1所示的硬件架构实现,主要可以包括以下模块:
第一日志记录模块71,用于在所述第一数据库中的第一磁盘和第四磁盘同步记录相同的在线日志记录;
日志传送模块72,用于在所述在线日志记录在第一数据库中记录完后向第二系统传送;
日志恢复模块73,用于在第二系统未收到所述在线日志记录时,调用以下子模块:
数据库访问判断子模块731,用于判断所述第一数据库是否可访问;若否,则触发数据主机访问判断子模块733;
主机访问判断子模块733,用于判断所述第一数据主机是否可访问;若否,则触发激活定位子模块735;
激活定位子模块735,用于通过第二数据主机激活位于第一数据库中的第四磁盘,并在所述第四磁盘中定位所述在线日志记录。
在本申请的一种优选实施例中,所述日志恢复模块还可以包括:
日志提取子模块734,用于在所述第一数据库不可访问,但所述第一数据主机可以访问时,通过所述第一数据主机提取所述在线日志记录的信息,并依据所述在线日志记录的信息在第一数据库中定位所述在线日志记录。
在具体实现中,所述在线日志记录根据第一数据库的数据变更在第一磁盘和第四磁盘中同步记录,在这种情况下,所述装置实施例还可以包括以下模块:
数据更新模块74,用于根据所述定位的在线日志记录,对第二数据库进行相应的数据变更。
当所述第一系统为主系统,所述第一数据库为主库,所述第二系统为备系统,所述第二数据库为备库时,所述装置实施例还可以包括以下模块:
主库切换模块,用于切换所述第二数据库为新的主库。
在本申请的一种优选实施例中,所述装置实施例还可以包括以下模块:
第一备库切换模块,用于在所述第一数据库和第一数据主机可访问时,切换所述第一数据库为新的备库;
第一重置模块,用于打开所述新的主库接收访问,并重置在线日志记录的传递关系为,在第二数据库的第二磁盘和第三磁盘同步记录相同的在线日志记录并向第一系统传递。
本申请实施例还可以应用于多机房的数据容灾部署方案中,在这种应用中,所述第二系统还可以采用通信延时非常短(不超过1毫秒)的通信链路与第三系统相连,所述第三系统中包括第三数据库、第三数据主机和第三存储设备,第二存储设备在第二数据库中分配第五磁盘,在第三数据库中分配第六磁盘;所述第三存储设备在第三数据库中分配第七磁盘,在第二数据库中分配第八磁盘,所述第七磁盘和第八磁盘被同步写入相同的在线日志记录;
在这种情况下,作为本申请的另一种优选实施例,所述装置实施例还可以包括以下模块:
第二备库切换模块,用于切换所述第三数据库为新的备库;
第二重置模块,用于打开所述新的主库接收访问,并重置在线日志记录的传递关系为,在第二数据库的第五磁盘和第八磁盘同步记录相同的在线日志记录并向第三系统传递。
在本申请的一种优选实施例中,所述日志恢复模块还可以包括:
主备切换子模块732,用于在所述第一数据库可以访问时,依次调用以下单元:
切换发起单元,用于在作为主库的第一数据库上发起切换请求;
数据库重启单元,用于依据所述请求关闭并重启所述第一数据库;
主库调整单元,用于在作为备库的第二数据库可接收访问时,将所述第二数据库切换为新的主库;
主库打开单元,用于打开所述新的主库接收访问;
日志传递关系重置单元,用于重置在线日志记录的传递关系为,在第二数据库的第二磁盘和第三磁盘同步记录相同的在线日志记录并向第一系统传递。
作为本申请实施例具体应用的一种示例,所述通信链路可以为光纤通信链路,所述第一数据库、第二数据库和第三数据库均为Oracle数据库。
对于系统实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
本申请可用于众多通用或专用的计算系统环境或配置中。例如:个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
最后,还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上对本申请所提供的一种数据容灾处理的方法和一种数据容灾处理的装置进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。
Claims (10)
1.一种数据容灾处理的方法,其特征在于,所述数据容灾涉及采用通信链路相连的第一系统与第二系统之间的数据备份处理,所述第一系统包括第一数据主机,第一数据库和第一存储设备,所述第二系统包括第二数据主机,第二数据库和第二存储设备;所述第一存储设备在第一数据库中分配第一磁盘,在第二数据库中分配第二磁盘;第二存储设备在第二数据库中分配第三磁盘,在第一数据库中分配第四磁盘;
在所述第一数据库中的第一磁盘和第四磁盘同步记录相同的在线日志记录并向第二系统传送,若第二系统未收到所述在线日志记录,则执行以下步骤:
判断所述第一数据库是否可访问;
若否,则判断所述第一数据主机是否可访问;
若否,则通过第二数据主机激活位于第一数据库中的第四磁盘,并在所述第四磁盘中定位所述在线日志记录。
2.根据权利要求1所述的方法,其特征在于,还包括:
当所述第一数据库不可访问,但所述第一数据主机可以访问时,通过所述第一数据主机提取所述在线日志记录的信息,并依据所述在线日志记录的信息在第一数据库中定位所述在线日志记录。
3.根据权利要求1或2所述的方法,其特征在于,根据第一数据库的数据变更在所述第一磁盘和第四磁盘同步记录在线日志记录,所述的方法还包括:
根据所述定位的在线日志记录,对第二数据库进行相应的数据变更。
4.根据权利要求3所述的方法,其特征在于,所述第一系统为主系统,所述第一数据库为主库,所述第二系统为备系统,所述第二数据库为备库,所述的方法还包括:
切换所述第二数据库为新的主库。
5.根据权利要求4所述的方法,其特征在于,还包括:
当所述第一数据库和第一数据主机可访问时,切换所述第一数据库为新的备库;
打开所述新的主库接收访问,并重置在线日志记录的传递关系为,在第二数据库的第二磁盘和第三磁盘同步记录相同的在线日志记录并向第一系统传递。
6.根据权利要求4所述的方法,其特征在于,所述第二系统还采用通信链路与第三系统相连,所述第三系统中包括第三数据库、第三数据主机和第三存储设备,第二存储设备在第二数据库中分配第五磁盘,在第三数据库中分配第六磁盘;所述第三存储设备在第三数据库中分配第七磁盘,在第二数据库中分配第八磁盘,所述第七磁盘和第八磁盘被同步写入相同的在线日志记录;
所述的方法,还包括:
切换所述第三数据库为新的备库;
打开所述新的主库接收访问,并重置在线日志记录的传递关系为,在第二数据库的第五磁盘和第八磁盘同步记录相同的在线日志记录并向第三系统传递。
7.根据权利要求5所述的方法,其特征在于,还包括:
若所述第一数据库可以访问,则在作为主库的第一数据库上发起切换请求,依据该请求关闭并重启所述第一数据库;
若作为备库的第二数据库可接收访问,则将所述第二数据库切换为新的主库;
打开所述新的主库接收访问,并重置在线日志记录的传递关系为,在第二数据库的第二磁盘和第三磁盘同步记录相同的在线日志记录并向第一系统传递。
8.一种数据容灾处理的装置,其特征在于,包括采用通信链路相连的第一系统与第二系统;
其中,所述第一系统包括第一数据主机,第一数据库和第一存储设备,所述第二系统包括第二数据主机,第二数据库和第二存储设备;所述第一存储设备在第一数据库中分配第一磁盘,在第二数据库中分配第二磁盘;第二存储设备在第二数据库中分配第三磁盘,在第一数据库中分配第四磁盘;
所述装置还包括:
第一日志记录模块,用于在所述第一数据库中的第一磁盘和第四磁盘同步记录相同的在线日志记录;
日志传送模块,用于在所述在线日志记录在第一数据库中记录完后向第二系统传送;
日志恢复模块,用于在第二系统未收到所述在线日志记录时,调用以下子模块:
数据库访问判断子模块,用于判断所述第一数据库是否可访问;若否,则触发数据主机访问判断子模块;
主机访问判断子模块,用于判断所述第一数据主机是否可访问;若否,则触发激活定位子模块;
激活定位子模块,用于通过第二数据主机激活位于第一数据库中的第四磁盘,并在所述第四磁盘中定位所述在线日志记录。
9.根据权利要求8所述的装置,其特征在于,所述日志恢复模块还包括:
日志提取子模块,用于在所述第一数据库不可访问,但所述第一数据主机可以访问时,通过所述第一数据主机提取所述在线日志记录的信息,并依据所述在线日志记录的信息在第一数据库中定位所述在线日志记录。
10.根据权利要求9所述的装置,其特征在于,所述第一系统为主系统,所述第一数据库为主库,所述第二系统为备系统,所述第二数据库为备库,所述的装置还包括:
主库切换模块,用于切换所述第二数据库为新的主库。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201110391482.4A CN103136070B (zh) | 2011-11-30 | 2011-11-30 | 一种数据容灾处理的方法和装置 |
HK13108384.2A HK1181153A1 (zh) | 2011-11-30 | 2013-07-17 | 種數據容災處理的方法和裝置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201110391482.4A CN103136070B (zh) | 2011-11-30 | 2011-11-30 | 一种数据容灾处理的方法和装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN103136070A CN103136070A (zh) | 2013-06-05 |
CN103136070B true CN103136070B (zh) | 2015-08-05 |
Family
ID=48495922
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201110391482.4A Active CN103136070B (zh) | 2011-11-30 | 2011-11-30 | 一种数据容灾处理的方法和装置 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN103136070B (zh) |
HK (1) | HK1181153A1 (zh) |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105045678B (zh) * | 2015-07-09 | 2018-10-26 | 小米科技有限责任公司 | 数据库恢复方法及装置 |
CN109766219A (zh) * | 2015-07-23 | 2019-05-17 | 深圳市沃信科技有限公司 | 一种数据库容灾系统 |
CN105554114B (zh) * | 2015-12-17 | 2018-11-02 | 深圳市从晶科技有限公司 | 一种数据同步方法及数据同步固件平台 |
CN105975579B (zh) * | 2016-05-05 | 2019-09-17 | 北京思特奇信息技术股份有限公司 | 一种内存数据库的主备复制方法及内存数据库系统 |
CN107480014B (zh) * | 2017-07-24 | 2021-01-01 | 奇安信科技集团股份有限公司 | 一种高可用设备切换方法及装置 |
CN108259613B (zh) * | 2018-01-24 | 2019-12-24 | 平安科技(深圳)有限公司 | 容灾数据的在线同步装置、方法及计算机可读存储介质 |
CN109710675A (zh) * | 2018-12-26 | 2019-05-03 | 深圳乐信软件技术有限公司 | 一种存储数据库切换方法、装置、服务器及存储介质 |
CN111159237B (zh) * | 2019-12-25 | 2023-07-14 | 中国平安财产保险股份有限公司 | 系统数据分发方法、装置、存储介质及电子设备 |
CN113127259B (zh) * | 2019-12-30 | 2024-03-12 | 北京懿医云科技有限公司 | 数据部署方法、装置、设备及存储介质 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030208511A1 (en) * | 2002-05-02 | 2003-11-06 | Earl Leroy D. | Database replication system |
CN1790278A (zh) * | 2005-12-29 | 2006-06-21 | 张�林 | 利用辅助操作系统远程进行软件服务的方法 |
CN1852455A (zh) * | 2005-11-22 | 2006-10-25 | 华为技术有限公司 | 一种数据容灾系统及其容灾方法 |
CN101667181A (zh) * | 2008-09-05 | 2010-03-10 | 华为技术有限公司 | 一种数据容灾的方法、装置及系统 |
CN102043686A (zh) * | 2009-10-20 | 2011-05-04 | 华为技术有限公司 | 一种内存数据库的容灾方法、备用服务器及系统 |
CN102194009A (zh) * | 2011-06-09 | 2011-09-21 | 北京新媒传信科技有限公司 | 一种数据库托管方法和一种数据库托管平台系统 |
-
2011
- 2011-11-30 CN CN201110391482.4A patent/CN103136070B/zh active Active
-
2013
- 2013-07-17 HK HK13108384.2A patent/HK1181153A1/zh unknown
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030208511A1 (en) * | 2002-05-02 | 2003-11-06 | Earl Leroy D. | Database replication system |
CN1852455A (zh) * | 2005-11-22 | 2006-10-25 | 华为技术有限公司 | 一种数据容灾系统及其容灾方法 |
CN1790278A (zh) * | 2005-12-29 | 2006-06-21 | 张�林 | 利用辅助操作系统远程进行软件服务的方法 |
CN101667181A (zh) * | 2008-09-05 | 2010-03-10 | 华为技术有限公司 | 一种数据容灾的方法、装置及系统 |
CN102043686A (zh) * | 2009-10-20 | 2011-05-04 | 华为技术有限公司 | 一种内存数据库的容灾方法、备用服务器及系统 |
CN102194009A (zh) * | 2011-06-09 | 2011-09-21 | 北京新媒传信科技有限公司 | 一种数据库托管方法和一种数据库托管平台系统 |
Also Published As
Publication number | Publication date |
---|---|
HK1181153A1 (zh) | 2013-11-01 |
CN103136070A (zh) | 2013-06-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103136070B (zh) | 一种数据容灾处理的方法和装置 | |
CN100543690C (zh) | 用于管理故障的方法和系统 | |
EP2281240B1 (en) | Maintaining data integrity in data servers across data centers | |
CN100461122C (zh) | 应用容错和恢复的系统和方法 | |
US9280430B2 (en) | Deferred replication of recovery information at site switchover | |
US7941622B2 (en) | Point in time remote copy for multiple sites | |
JP4668763B2 (ja) | ストレージ装置のリストア方法及びストレージ装置 | |
CN101578586A (zh) | 在故障转移和故障回复环境中使用虚拟拷贝 | |
CN106815097A (zh) | 数据库容灾系统和方法 | |
CA2655911A1 (en) | Data transfer and recovery process | |
US11036600B2 (en) | Preventing non-detectable data loss during site switchover | |
US20220164266A1 (en) | Client-less database system recovery | |
CN103186348B (zh) | 存储系统及其数据读写方法 | |
CN111158955B (zh) | 一种基于卷复制的高可用系统以及多服务器数据同步方法 | |
Zhu et al. | IT disaster tolerance and application classification for data centers | |
CN104850628A (zh) | 一种数据库数据的同步方法及装置 | |
US20150317226A1 (en) | Detecting data loss during site switchover | |
CN110309226A (zh) | 一种云数据库统一备份与恢复系统 | |
Schulman | Disaster recovery issues and solutions | |
US10891205B1 (en) | Geographically dispersed disaster restart multitenancy systems | |
Bajpai et al. | Remote mirroring: A disaster recovery technique in cloud computing | |
Kyne et al. | GDPS Family: An Introduction to Concepts and Capabilities | |
JP2011253400A (ja) | 分散ミラードディスクシステム、コンピュータ装置、ミラーリング方法およびそのプログラム | |
Wang et al. | The design of finite state machine for asynchronous replication protocol | |
Ivanov et al. | Unveiling IBM's Strategy for Advanced Copy Services Replications |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 1181153 Country of ref document: HK |
|
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: GR Ref document number: 1181153 Country of ref document: HK |