背景技术
MySQL是一种小型关系型数据库管理系统。一般的,MySQL包括主库和备库,主库用于提供数据管理和数据查询等功能,备库用于备份主库中的数据,用以在主库发生故障时代替主库提供相应的功能。
图1为现有技术中MySQL中的主库将自身的数据备份到备库的过程,具体包括以下步骤:
S101:主库在对自身的数据进行操作时,生成对应的操作记录并记录在二进制日志(binlog)中。
其中,主库对自身的数据的操作包括:更新操作、插入操作、删除操作。
例如,主库将自身的数据A更新为数据B时,生成将该数据A更新为数据B的操作记录,并记录在binlog日志中。
S102:备库通过I/O线程读取主库保存的binlog日志。
S103:备库将读取到的binlog日志转换成中继日志(relay)。
其中,主库保存的binlog日志中记录的操作记录,与备库转换的relay日志中记录的操作记录相同,只是binlog日志与relay日志的格式不同。
继续沿用上例,由于主库的binlog日志中记录有将数据A更新为数据B的操作记录,因此备库转换的relay日志中也包含将数据A更新为数据B的操作记录。
S104:备库通过一个SQL线程依次读取relay日志中记录的每个操作记录。
继续沿用上例,备库读取到的操作记录即为将数据A更新为数据B的操作记录。
S105:备库根据读取到的操作记录,将该操作记录对应的数据读取到内存中,并根据该操作记录对内存中的该数据进行相应操作。
继续沿用上例,由于读取到的操作记录为将数据A更新为数据B的操作记录,因此该操作记录对应的数据即为备库中保存的数据A。备库则将该数据A读取到内存中,再将该操作记录(将数据A更新为数据B的操作记录)解析为相应的执行语句并执行,用以将内存中的该数据A更新为数据B,完成对主库数据的备份。
由上述图1所示的过程可以看出,备库在备份主库中的数据时,是通过一个SQL线程依次读取relay日志中的操作记录进行操作的,也即备库是通过一个SQL线程串行的执行relay日志中各操作记录对应的执行语句,实现数据的备份的。而在实际应用中,主库通常是通过多个线程并行的对保存的各数据进行操作的,例如主库可以同时通过几十个线程并行的对相应数量的数据进行操作,而备库在备份这些数据时,只能通过一个线程串行的备份这些数据,这就会导致备库对主库数据的备份速度远远落后于主库对自身保存的数据进行操作的速度。
为了提高备库对主库数据进行备份的速度,现有技术中主要有以下三种方法。
第一种,对于relay日志中任意两个事务,如果一个事务中包含的操作记录对应的数据在主库中所属的分库,不同于另一个事务中包含的操作记录对应的数据在主库中所属的分库,则备库通过两个线程并行的对这两个事务中包含的操作记录进行处理,以备份主库中这两个事务中包含的操作记录对应的数据。如果一个事务中包含的操作记录对应的数据在主库中所属的分库,与另一个事务中包含的操作记录对应的数据在主库中所属的分库相同,则备库仍然通过一个线程串行的对这两个事务中包含的操作记录进行处理,以备份主库中这些操作记录对应的数据。
其中,binlog日志和relay日志均是以事务的形式对操作记录进行记录的,一个事务中包含若干个操作记录,这若干个操作记录一般是用户在进行一个业务操作时,数据库根据这个业务操作对自身保存的数据所要做出的若干个操作所对应的若干个操作记录。并且,在binlog日志和relay日志中,每个事务均具有一个事务开始标记和事务结束标记。
例如,某用户有四个账号,分别为账号A、账号B、账号C、账号D,这四个账号中均有10000元,现该用户从账号A向账号B转入1000元,再从账号C向账号D转入1000元,那么主库中的binlog日志和备库中的relay日志则均会记录有两个事务。
第一个事务是从账号A向账号B转入1000元的事务,该第一个事务中包含的操作记录即为:将账号A的余额由10000元更新为9000元的操作记录,以及,将账号B的余额由10000元更新为11000元的操作记录,共2个操作记录。第二个事务是从账号C向账号D转入1000元的事务,该第二个事务中包含的操作记录即为:将账号C的余额由10000元更新为9000元的操作记录,以及,将账号D的余额由10000元更新为11000元的操作记录,也是2个操作记录。这两个事务在binlog日志和relay日志中分别具有各自的事务起始标记和事务结束标记,以区分不同事务中包含的操作记录。
如果上例中账号A的余额数据和账号B的余额数据属于主库中的分库1,账号C的余额数据和账号D的余额数据属于主库中的分库2,则备库在备份这4个数据时通过两个SQL线程进行并行的备份,一个线程用于根据第一个事务中包含的2个操作记录备份账号A的余额数据和账号B的余额数据,另一个线程用于根据第二个事务中包含的2个操作记录备份账号C的余额数据和账号D的余额数据。相反的,如果上例中账号A的余额数据和账号B的余额数据属于主库中的分库1,账号C的余额数据和账号D的余额数据也属于主库中的分库1,则备库仍然通过一个SQL线程串行的对这两个事务中包含的操作记录进行处理,以备份这4个数据。
但是,采用第一种方法时,由于主库中的分库的数量往往较少,一般只有2~3个,而第一种方法备库可以采用的并行线程的数量最多就是主库中的分库的数量,因此第一种方法并不能有效的提高备库对主库数据进行备份的速度。
第二种,对于relay日志中的任意两个操作记录,如果这两个操作记录对应的数据在主库中所属的数据表不同,则备库通过两个线程并行的对这两个操作记录进行处理。如果这两个操作记录对应的数据在主库中所属的数据表相同,则备库仍然通过一个线程串行的对这两个操作记录进行处理。
其中,主库中包含若干个数据表,每个数据表中包含若干个数据。
第三种,对于relay日志中任意两个操作记录,如果这两个操作记录对应的数据不同,则备库通过两个线程并行的对这两个操作记录进行处理。如果这两个操作记录对应的数据相同,则备库仍然通过一个线程串行的对这两个操作记录进行处理。
可见,第二种方法和第三种方法并不是一个线程处理一个事务中包含的所有操作记录,而是可能通过两个或多个线程分别处理一个事务中包含的操作记录。
例如,某用户有三个账号,分别为账号A、账号B、账号C,这三个账号中均有10000元,现该用户从账号A向账号B转入1000元,再从账号A向账号C转入1000元,那么主库中的binlog日志和备库中的relay日志则均会记录有两个事务。
第一个事务是从账号A向账号B转入1000元的事务,该第一个事务中包含的操作记录即为:将账号A的余额由10000元更新为9000元的操作记录,以及,将账号B的余额由10000元更新为11000元的操作记录,共2个操作记录。第二个事务是从账号A向账号C转入1000元的事务,该第二个事务中包含的操作记录即为:将账号A的余额由9000元更新为8000元的操作记录,以及,将账号C的余额由10000元更新为11000元的操作记录,也是2个操作记录。
按照第二种方法,假设账号A的余额数据、账号B的余额数据、账号C的余额数据在主库中所属的数据表各不相同,则备库通过三个线程进行数据备份,一个线程用于串行的处理第一个事务中账号A的余额由10000元更新为9000元的操作记录,以及第二个事务中账号A的余额由9000元更新为8000元的操作记录,另外两个线程分别用于处理第一个事务中账号B的余额由10000元更新为11000元的操作记录,以及,第二个事务中账号C的余额由10000元更新为11000元的操作记录。并且,这三个线程是并行处理各自的操作记录的。
按照第三种方法,由于账号A的余额数据、账号B的余额数据、账号C的余额数据各不相同,因此备库通过三个线程进行数据备份,一个线程用于串行的处理第一个事务中账号A的余额由10000元更新为9000元的操作记录,以及第二个事务中账号A的余额由9000元更新为8000元的操作记录,另外两个线程分别用于处理第一个事务中账号B的余额由10000元更新为11000元的操作记录,以及,第二个事务中账号C的余额由10000元更新为11000元的操作记录。并且,这三个线程是并行处理各自的操作记录的。
然而,采用第二种或第三种方法时,由于备库的一个线程并不处理一个事务中包含的所有操作记录,因此当某个线程出现故障时,备库不能保证对同一事务中包含的所有操作记录进行处理的一致性。
如:在上例中,用于备份账号B的余额数据的线程如果出现故障,则会导致处理第一个事务中的操作记录时,将账号A的余额由10000元更新为9000元,但是账号B的余额并未由10000元更新为11000元。显然,对于第一个事务中包含的两个操作记录而言,一个被成功的处理,而另一个未被成功的处理,导致了备库对该第一个事务中包含的两个操作记录处理缺乏一致性,直观的来讲,由账号A转入账号B的1000元丢失了。由于保证对同一事务中包含的所有操作记录处理的一致性是保证数据库正确处理事务的基本要素之一,因此采用第二种方法和第三种方法时,无法保证备库处理事务的准确性。
具体实施方式
本申请实施例为了提高备库对主库数据进行备份的速度,采用多个线程并行的处理relay日志中的多个事务中包含的操作记录,并且,为了保证对同一事务中包含的所有操作记录处理的一致性,一个事务中包含的所有操作记录只由一个线程进行处理,使备库在提高备份速度的同时,保证处理事务的准确性。
下面结合说明书附图,对本申请实施例进行详细描述。
图2为本申请实施例提供的数据备份的过程,具体包括以下步骤:
S201:备库将relay日志中记录的未处理的事务作为待分配事务,针对待分配事务,确定该待分配事务中包含的表标识以及表标识对应的分库标识。
在本申请实施例中,备库读取主库保存的binlog日志,并转换成relay日志后,可通过一个relay线程依次读取relay日志中记录的每个事务,将relay日志中记录的当前尚未处理的事务作为待处理事务,针对待处理事务,备库先确定该待处理事务中包含的每个操作记录对应的数据所在的表的表标识,以及该表对应的分库的分库标识,也即,该表所在的分库的分库标识。
其中,主库和备库中的每个分库都具有一个唯一的标识,即为分库标识,主库和备库中的每个表也具有一个唯一的标识,即为表标识。主库(或备库)、分库、表、数据的关系是:主库(或备库)中包含若干个分库,分库中包含若干个表,表中包含若干个数据。在relay日志中,每个事务中包含的操作记录对应的数据所在的表标识,以及该表标识对应的分库标识是直接记录在relay日志中的。
例如,relay日志中顺序记录了若干个事务,前四个事务为:T1、T2、T3、T4。
T1包含的表标识为t1,表标识t1对应的分库标识为d1,记为(d1,t1);
T2包含的表标识为t1和t2,表标识t1对应的分库标识为d1,表标识t2对应的分库标识为d1,记为(d1,t1),(d1,t2);
T3包含的表标识为t3,表标识t3对应的分库标识为d1,记为(d1,t3);
T4包含的表标识为t2和t3,表标识t2对应的分库标识为d1,表标识t3对应的分库标识为d1,记为(d1,t2),(d1,t3)。
则备库先将T1作为待分配事务,确定T1中包含的表标识为t1,分库标识为d1。
S202:根据该待分配事务中包含的表标识及其对应的分库标识,以及各已分配事务中包含的表标识以及表标识对应的分库标识,判断是否存在与该待分配事务冲突的已分配事务,若是,则执行步骤S203,否则执行步骤S204。
在本申请实施例中,备库在判断是否存在与该待分配事务冲突的已分配事务时,可以在各已分配事务中,判断是否存在包含的至少一个表标识及其对应的分库标识,与该待分配事务中包含的表标识及其对应的分库标识相同的已分配事务。若是,则判定存在与该待分配事务冲突的已分配事务,与该待分配事务冲突的已分配事务即为:包含至少一个表标识及其对应的分库标识,与该待分配事务中包含的表标识及其对应的分库标识相同的已分配事务。否则,判定不存在与该待分配事务冲突的已分配事务。
也即,本申请实施例中,对于两个事务,如果这两个事务中包含的数据所属的表和分库均相同,则认为这两个事务冲突,反之,如果这两个事务中包含的数据所属的表和分库均不相同,则认为这两个事务不冲突。
继续沿用上例,针对事务T1,由于此时备库尚未分配事务给任何一个线程进行处理,也即,当前并无已分配事务,因此,备库判定没有与事务T1冲突的已分配事务,执行后续的步骤S204。
S203:将该待分配事务分配到冲突的已分配事务所在的等待队列中等待处理,其中,已分配事务为已经分配到线程的等待队列中等待处理的事务。
由于为了保证数据备份的准确性,冲突的事务需要由一个线程串行的进行处理,因此,当通过上述步骤S202确定存在与该待分配事务冲突的已分配事务时,则将该待分配事务分配到冲突的已分配事务所在的等待队列中等待处理。其中,备库为每个线程(具体是SQL线程)都预设了一个等待队列,对于一个SQL线程,该SQL线程可依次处理等待队列中分配的各事务(即,已分配事务)。
S204:在各线程的等待队列中选择一个等待队列,并将该待分配事务分配到选择的等待队列中等待处理。
当通过上述步骤S202确定不存在与该待分配事务冲突的已分配事务时,说明该待分配事务可被分配到任意一个线程进行处理,因此,备库可在各线程的等待队列中任意选择一个等待队列,并将该待分配事务分配到选择的该等待队列中等待处理。
较佳的,为了均衡各SQL线程的负载,进一步提高备库的备份速度,在步骤S204中,备库可在各线程的等待队列中选择分配的已分配事务的数量最少的等待队列,并将该待分配事务分配到选择的等待队列中等待处理。或者,备库也可以针对每个等待队列,确定该等待队列中各已分配事务中分别包含的表标识及其对应的分库标识的并集,选择确定出的包含元素的数量最少的并集对应的等待队列。
继续沿用上例,假设当前备库有两个SQL线程W0和W1,这两个线程的等待队列中都没有分配事务,则备库可任选一个线程的等待队列,将事务T1分配到选择的等待队列中。假设选择的是线程W0的等待队列,则将T1分配到W0的等待队列中,等待W0处理。
另外,由于一个事务中可能包含多个不同的表标识或分库标识,因此,对于一个待分配事务来说,已分配事务中存在的与该待分配事务冲突的事务可能不止一个,这些与待分配事务冲突的已分配事务所在的等待队列也可能不同,因此,在上述步骤S203中,当存在与该待分配事务冲突的已分配事务时,备库将该待分配事务分配到冲突的已分配事务所在的等待队列中等待处理的方法具体为:当与该待分配事务冲突的各已分配事务所在的等待队列的数量为一个时,将该待分配事务分配到与该待分配事务冲突的已分配事务所在的等待队列中等待处理;当与该待分配事务冲突的各已分配事务所在的等待队列的数量为两个以上时,等待各线程处理各自等待队列中的已分配事务,直至与该待分配事务冲突的各已分配事务所在的等待队列的数量为一个时,将该待分配事务分配到冲突的已分配事务所在的等待队列中等待处理。
继续沿用上例,将事务T1分配到线程W0的等待队列中等待处理后,备库继续通过relay线程读取relay日志中的下一个事务,即事务T2,将T2作为待分配事务。
由于T2中包含(d1,t1)和(d1,t2),而已分配事务T1中也包含(d1,t1),因此已分配事务T1与待分配事务T2冲突,并且与T2冲突的已分配事务(T1)所在的等待队列只有一个,即为线程W0的等待队列,因此,备库将待分配事务T2也分配到W0的等待队列中,等待W0的处理。
分配了T2后,备库继续通过relay线程读取relay日志中的下一个事务,即事务T3,作为待分配事务。
由于T3中包含的(d1,t3)与已分配事务T1中包含的(d1,t1)不同,与已分配事务T2中包含(d1,t1)和(d1,t2)也不同,因此,已分配事务中不存在与待分配事务T3冲突的事务,而此时线程W0的等待队列中已经分配了两个事务(T1和T2),W1的等待队列中没有事务,因此,备库在W0和W1的等待队列中选择已分配事务的数量最少的等待队列,即W1的等待队列,将待分配事务T3分配到W1的等待队列中,等待W1进行处理。当然,也可以确定当前W0的等待队列中已分配的两个事务T1和T2分别包含的表标识及其对应的分库标识的并集,即为[(d1,t1),(d1,t2)],包含2个元素,而当前W1的等待队列中尚未分配任何事务,因此W1的等待队列中已分配事务分别包含的表标识及其对应的分库标识的并集为空集,包含0个元素,从而,备库选择包含元素的数量最少的并集对应的等待队列,即,选择W1的等待队列,将待分配事务T3分配到W1的等待队列中,等待W1进行处理。
分配了T3后,备库继续通过relay线程读取relay日志中的下一个事务,即事务T4,作为待分配事务。
由于T4中包含的(d1,t2)与已分配事务T2包含的(d1,t2)相同,因此,已分配事务T2与待分配事务T4冲突,由于T4中包含的(d1,t3)与已分配事务T3包含的(d1,t3)相同,因此,已分配事务T3也与待分配事务T4冲突。而由于已分配事务T2所在的等待队列为W0所在的等待队列,已分配事务T3所在的等待队列为W1所在的等待队列,因此与待分配事务T4冲突的已分配事务(T2和T3)所在的等待队列为两个,因此,备库等待线程W0和W1处理各自等待队列中的已分配事务,直至与待分配事务T4冲突的已分配事务所在的等待队列的数量为一个为止。
由于此时W0的等待队列中分配了两个事务,即T1和T2,W1的等待队列中只分配了一个事务T3,因此,假设某一时刻线程W0处理了已分配事务T1,线程W1处理了已分配事务T3,则此时与待分配事务T4冲突的已分配事务(只剩事务T2是与T4冲突的)所在的等待队列就只剩一个,即为W0的等待队列,因此,备库将待分配事务T4分配到当前与该待分配事务冲突的已分配事务所在的等待队列中等待处理,即,将T4分配到当前与其冲突的T2所在的W0的等待队列中,等待W0的处理。
通过上述方法,备库可通过多个SQL线程并行的处理互不冲突的多个事务,因此可以有效提高备库的备份速度,并且,由于上述方法一个线程处理一个事务中包含的所有操作记录,因此可以保证对同一事务中包含的所有操作记录处理的一致性,从而提高了备库处理事务的准确性。
另外,现有技术中也存在基于数据的并行备份方法,即,如果两个事务中包含的数据标识均不相同,则认为这两个事务不冲突,可通过不同的线程进行处理。
但是,由于relay日志中仅记录了事务中包含的数据所属的表的表标识和所属的分库的分库标识,而并未记录数据标识,因此,采用这种基于数据的并行备份方法,备库在通过relay线程读取relay日志中的事务时,需要通过该relay线程将读取的该事务中的每个操作记录都转换成执行语句,并通过假执行的方式执行转换的执行语句,以提取出该事务中的数据标识。
然而,备库在读取relay日志中记录的各事务时,必须按照记录的顺序串行的进行读取,也即,relay线程只有一个,而处理事务的SQL线程却有多个,由上述现有技术中基于数据的并行备份方法可以看出,这唯一的一个relay线程除了需要读取事务以外,还需要转换执行语句并进行假执行,以确定出该事务中包含的数据标识,这样,relay线程为各SQL线程分配事务的效率必然较低,导致备份速度较低,因此,现有技术中基于数据的并行备份方法仅适用于主库(或备库)中的分库和分表都比较少的场景。
而由于relay日志中已经记录了事务中包含的数据所属的表的表标识和所属的分库的分库标识,因此,本申请实施例提供的上述如图2所示的备份方法,备库的relay线程只需直接读取relay日志记录的事务中的表标识和分库标识即可,而无需转换执行语句并假执行,因此,可提高为各SQL线程分配事务的效率,从而提高备份速度,尤其适用于分库或分表较多的场景。
进一步的,在本申请实施例中,当将一个待分配事务分配到一个线程的等待队列中时,可建立该待分配事务中包含的每个表标识及其对应的分库标识与该线程的绑定关系,后续则可根据建立的绑定关系,以及待分配事务中包含的表标识及其对应的分库标识,将该待分配事务分配到相应线程的等待队列中。后续针对某个待分配事务,如果与其冲突的已分配事务所在的等待队列的数量为两个以上,则等待各线程处理各自等待队列中的已分配事务,当与该待分配事务冲突的已分配事务所在的等待队列中只有一个时,可将该待分配事务分配到当前冲突的已分配事务所在的等待队列中,并根据该待分配事务中包含的表标识及其对应的分库标识,更新保存的绑定关系。
继续沿用上例,将T1分配到W0的等待队列中时,则建立T1中包含的(d1,t1)与W0的绑定关系。
在分配T2时,由于还未建立(d1,t2)与某个线程的绑定关系,因此可确定与T2冲突的已分配事务所在的等待队列只有一个,从而,根据保存的(d1,t1)与W0的绑定关系,直接将T2分配到W0的等待队列中,并建立(d1,t2)与W0的绑定关系((d1,t1)与W0的绑定关系已经在分配T1时建立)。
在分配T3时,由于还未建立(d1,t3)与某个线程的绑定关系,因此可确定没有与T3冲突的已分配事务,从而,备库选择等待队列中的已分配事务最少的等待队列,或者,选择建立绑定关系的数量最少的等待队列,即线程W1的等待队列,将T3分配到W1的等待队列中,并建立(d1,t3)与W1的绑定关系。
在分配T4时,由于(d1,t2)已经与W0建立了绑定关系,(d1,t3)已经与W1建立了绑定关系,因此,可确定与T4冲突的已分配事务所在的等待队列可能有两个,从而,等待W0和W1处理各自等待队列中的事务,并监控W0和W1的等待队列,当监控到W0和W1的等待队列中只剩一个等待队列存在事务时,将T4分配到尚存在事务的等待队列中,并更新绑定关系。进一步的,由于W0的等待队列中分配了T1和T2,W1的等待队列中只分配了T3,因此,在某一时刻,可监控到W0处理了T1,W1处理了T3,此时,只有W0的等待队列中尚存在事务T2(与T4冲突),因此,将T4分配到W0的等待队列中,并建立T4中包含的(d1,t3)与W0的绑定关系((d1,t2)与W0的绑定关系已经在分配T2时建立),删除已建立的(d1,t3)与W1的绑定关系。
此时的绑定关系为(d1,t1)、(d1,t2)、(d1,t3)均与W0绑定,W1未与任何表标识及其对应的分库标识绑定。后续可基于上述绑定关系继续对待分配事务进行分配,这里就不在一一赘述。
以上为本申请实施例提供的数据备份方法,基于同样的思路,本申请实施例还提供一种数据备份装置,如图3所示。
图3为本申请实施例提供的数据备份装置结构示意图,具体包括:
确定模块301,用于将relay日志中记录的未处理事务作为待分配事务,针对待分配事务,确定所述待分配事务中包含的表标识以及表标识对应的分库标识;
判断模块302,用于根据所述确定模块301确定的所述待分配事务中包含的表标识及其对应的分库标识,以及各已分配事务中包含的表标识以及表标识对应的分库标识,判断是否存在与所述待分配事务冲突的已分配事务;
分配模块303,用于在所述判断模块302的判断结果为是时,将所述待分配事务分配到冲突的已分配事务所在的等待队列中等待处理,其中,已分配事务为已经分配到线程的等待队列中等待处理的事务;当所述判断模块302的判断结果为否时,在各线程的等待队列中选择一个等待队列,并将所述待分配事务分配到选择的等待队列中等待处理。
所述判断模块302具体用于,在各已分配事务中,判断是否存在包含的至少一个表标识及其对应的分库标识,与所述待分配事务中包含的表标识及其对应的分库标识相同的已分配事务;若存在,则判定存在与所述待分配事务冲突的已分配事务;否则,判定不存在与所述待分配事务冲突的已分配事务。
所述分配模块303具体用于,当所述判断模块302的判断结果为是,且与所述待分配事务冲突的各已分配事务所在的等待队列的数量为一个时,将所述待分配事务分配到与所述待分配事务冲突的已分配事务所在的等待队列中等待处理。
所述分配模块303具体用于,当所述判断模块302的判断结果为是,且与所述待分配事务冲突的各已分配事务所在的等待队列的数量为两个以上时,等待各线程处理各自等待队列中的已分配事务,直至与所述待分配事务冲突的已分配事务所在的等待队列的数量为一个时,将所述待分配事务分配到冲突的已分配事务所在的等待队列中等待处理。
所述分配模块303具体用于,当所述判断模块302的判断结果为否时,在各线程的等待队列中选择分配的已分配事务的数量最少的等待队列,并将所述待分配事务分配到选择的等待队列中等待处理;或者,针对每个等待队列,确定该等待队列中各已分配事务中分别包含的表标识及其对应的分库标识的并集,选择确定出的包含元素的数量最少的并集对应的等待队列,并将所述待分配事务分配到选择的等待队列中等待处理。
具体的上述数据备份装置可以位于备库中。
本申请实施例提供一种数据备份方法及装置,该方法备库针对待处理事务,确定该待处理事务中包含的表标识以及表标识对应的分库标识,并判断当前是否存在与该待处理事务冲突的已分配事务,若存在,则将该待分配事务分配到冲突的已分配事务所在的等待队列中等待处理,否则,在各线程的等待队列中选择一个等待队列,并将该待分配事务分配到选择的等待队列中等待处理。由于上述方法是通过多个线程并行的处理互不冲突的多个事务,因此可以有效提高备库的备份速度,并且,由于上述方法一个线程处理一个事务中包含的所有操作记录,因此可以保证对同一事务中包含的所有操作记录处理的一致性,从而提高了备库处理事务的准确性。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括非暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
显然,本领域的技术人员可以对本申请实施例进行各种改动和变型而不脱离本申请实施例的精神和范围。这样,倘若本申请实施例的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。