CN104376017B - 在数据库之间进行数据同步的方法及系统 - Google Patents

Abstract

本申请公开了在数据库之间进行数据同步的方法及系统，其中，所述方法包括：接收到第一数据库向第二数据库发送的同步变更信息时，开启一事务；通过结构化查询语言SQL规范，在所述事务中插入预先为第一数据库定义的标识以及所述同步变更信息中携带的业务数据，以便触发第二数据库在变更日志中记录下第一数据库的标识；将事务提交到所述第二数据库，以便第二数据库根据所述业务数据执行数据同步变更；在第二数据库同步变更完成产生新的变更数据后，判断变更日志中记录的标识与预先为第一数据库定义的标识是否相同，如果相同，则略过这条变更数据，以便不再向第一数据库发送同步变更信息。通过本申请，可以实现在异构数据库之间避免死循环同步。

Description

在数据库之间进行数据同步的方法及系统

技术领域

本申请涉及数据库双向同步技术领域，特别是涉及在数据库之间进行数据同步的方法及系统。

背景技术

目前，在一些大型的业务处理系统中，为了提高业务处理速度，一般需要在多地部署机房，当然，不同机房的数据库之间需要保持数据的同步。例如，某电子商务交易平台的国际站，主要的业务是对外出口，其业务的特性为：卖家用户在国内，买家用户在国外，因此，需要在国外（例如，美国）部署异地机房，最终形成了卖家在国内机房上发布商品，通过数据库同步技术同步到美国机房，国外的买家用户通过美国机房访问商品数据，并生成相应产品订单，再通过数据库同步技术同步回国内的机房（例如，设在杭州），和买家进行交互，从而形成一个数据闭环。

异地机房之间需要采用双向的数据同步技术。例如，在前述例子中，杭州的数据库中发生数据变更时，需要同步到美国，同样，美国的数据库中发生数据变更时，也要同步到杭州，但是，要避免出现死循环同步的情况。例如，杭州数据库同步美国数据库的数据，不能再从美国数据库回到杭州数据库，等等。

现有技术中，mysql为同为mysql类型的数据库之间进行数据同步时，提供了避免出现死循环同步的解决方案。也即，mysql为每个机房的数据库设置一个serverId，用于标识每条变更数据的原始产生于哪个数据库。假如存在两个mysql数据库，mysql-A和mysql-B，并且分别设置了serverId-A和serverId-B。在mysql-A上产生的数据变更都会记录该serverId-A，同时在发送每份数据变更记录的时候，都会包含对应的serverId-A。同步到目标机房的mysql-B数据库时，会在日志中记录发送过来变更数据对应的serverId-A。mysql-A同步到mysql-B的数据变更也会触发变更同步，从mysql-B发送给mysql-A时，会带上对应的serverId-A，到达mysql-A时，mysql-A发现数据的serverId-A和自己的serverId-A相同，这意味着数据的原始产生者为自己，因此忽略这数据，从而避免产生死循环同步。

但是，上述现有技术只是mysql数据库内部的解决方案，这也就意味着只能在mysql数据库之间才有效，无法支持异构数据库，也就是说，如果不同的机房中使用了不同类型的数据库，则上述方案将无法解决死循环同步问题。例如，假设某数据库为mysql-A，另一个数据库为oracle-B，此时，如果mysql-A上产生的数据变更同步到oracle-B，即使mysql-A的变更数据记录了serverId-A，也无法将其写入到oracle-B的变更日志进行保留（因为mysql无法修改oracle的日志），进而，当同步到oracle-B的数据变更再次出发变更同步之后，oracle-B会作为普通的数据变更操作来处理，无法携带上serverId-A，因此，mysql-A收到之后，就不会忽略，而是再进行更新，以此又进入了死循环同步。

因此，迫切需要本领域技术人员解决的问题就在于，在存在非mysql数据库的情况下，如果避免死循环同步现象。

发明内容

本申请提供了在数据库之间进行数据同步的方法及系统，即使不同的机房之间存在异构的数据库，也仍然可以保证在进行双向数据同步的过程中，避免发生死循环的现象，并且可以减少网络传输量，提高实现的效率。

本申请提供了如下方案：

一种在数据库之间进行数据同步的方法，包括：

接收到第一数据库向第二数据库发送的同步变更信息时，开启一事务；

通过结构化查询语言SQL规范，在所述事务中插入预先为第一数据库定义的标识以及所述同步变更信息中携带的业务数据，以便触发第二数据库在变更日志中记录下第一数据库的标识；

将所述事务提交到所述第二数据库，以便第二数据库根据所述业务数据执行数据同步变更；

在第二数据库同步变更完成产生新的变更数据后，判断所述变更日志中记录的标识与预先为第一数据库定义的标识是否相同，如果相同，则略过这条变更数据，以便不再向所述第一数据库发送同步变更信息。

一种在数据库之间进行数据同步的系统，包括：

事务开启单元，用于接收到第一数据库向第二数据库发送的同步变更信息时，开启一事务；

插入单元，用于通过结构化查询语言SQL规范，在所述事务中插入预先为第一数据库定义的标识以及所述同步变更信息中携带的业务数据，以便触发第二数据库在变更日志中记录下第一数据库的标识；

事务提交单元，用于将所述事务提交到所述第二数据库，以便第二数据库根据所述业务数据执行数据同步变更；

判断单元，用于在第二数据库同步变更完成产生新的变更数据后，判断所述变更日志中记录的标识与预先为第一数据库定义的标识是否相同，如果相同，则略过这条变更数据，以便不再向所述第一数据库发送同步变更信息。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，由于是利用的SQL规范，向事务中插入变更同步发起方数据库的标识，进而触发目标数据库将发起方数据库的标识写入到变更日志中，因此，只要是支持的SQL规范的数据库，就都可以支持，这样，即使不同的机房之间存在异构的数据库，也仍然可以保证在进行双向数据同步的过程中，避免发生死循环的现象。另外，在第二数据库发生了一次数据变更时候，对于是否为从第一数据库发送过来的同步变更信息引发的变更的判断过程，是直接在第二数据库一侧进行的，如果发现是，则可以不再向第一数据库发送同步变更信息。而在传统的mysql内部的数据同步方案中，即使第二数据库是根据第一数据库发送的同步变更信息而产生的数据变更，也需要再从第二数据库向第一数据库发送同步变更消息，在第一数据库一侧进行判断是否需要忽略。因此，本申请实施例相对于现有技术而言，还可以减少网络传输量，提高实现的效率。

另外，针对可能出现的不同的数据库同时对同一记录进行修改的情况下导致的数据不一致的情况，还提供了相应的一致性补救方案。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的方法的流程图；

图2是本申请实施例提供的标识插入方法的示意图；

图3是本申请实施例提供的数据同步过程的示意图；

图4是本申请实施例提供的另一数据同步过程的示意图；

图5是本申请实施例提供的时间交集判断的示意图；

图6是本申请实施例提供的系统的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例中，并不是对某一种具体类型的数据库内部代码进行改进，而是在使用各种类型的数据库来部署异地机房的过程中，开发了一套同步管理系统。这种同步管理系统使用的SQL（Structured Query Language，结构化查询）规范对各种数据库进行操作，因此，只要是支持SQL规范的数据库，就可以使用本申请实施例中的同步管理系统进行数据库间的双向同步，例如，可以是mysql数据库，也可以是oracle数据库，还可以是两种类型的数据库组成的异构数据库，等等。下面从该同步管理系统的角度出发，对本申请实施例提供的数据同步方法进行详细地介绍。

参见图1，本申请实施例首先提供了一种数据同步方法，该方法各步骤的执行主体即为前述同步管理系统，该方法可以包括以下步骤：

S101：接收到第一数据库向第二数据库发送的同步变更信息时，开启一事务；

在各个机房中可以部署本申请实施例的同步管理系统，这样，关于各个数据库之间的同步处理，就可以由该同步管理系统来处理。当然，在一次数据同步的过程中，会有其中一个数据库是最初发生数据变更的来源数据库，其他数据库则是需要进行同步变更的目标数据库。对于同步管理系统而言，在来源数据库中以及在目标数据库中需要进行的处理会有所不同。例如，假设某地的机房中，业务系统通过操作第一数据库，产生一些业务数据，如，用户发布一个产品数据、提交一个订单等等，此时，这些数据会被记录在第一数据库的变更日志中，因此，本申请实施例的同步管理系统就可以通过第一数据库的日志协议，从变更日志中获取到发生变更的业务数据，例如，可能获取到数据库的DML/DDL事件等。进而，就可以生成一条同步变更信息，并通过某种机制，将第一数据库中获取到的变更信息，向目标数据库发送。假设第二数据库就是该目标数据库（当然目标数据库可能有多个）其中之一，则第二数据库就可以接收到第一数据库发送的同步变更信息。此时，在第二数据库执行具体的数据变更的同时，该同步管理系统可以首先进行一些处理，来避免同步变更进入死循环状态。具体的，就可以首先开启一个事务，然后在该事务中进行一些处理，再提交到第二数据库执行具体的数据变更。需要说明的是，本申请实施例中所谓的事务，就是指数据库事务(Database Transaction)，也就是作为单个逻辑工作单元执行的一系列操作。事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。通过将一组相关操作组合为一个要么全部成功要么全部失败的单元，可以简化错误恢复并使应用程序更加可靠。下面通过步骤S102对本申请实施例对事务的处理进行介绍。

S102：通过结构化查询语言SQL规范，在所述事务中插入预先为第一数据库定义的标识以及所述同步变更信息中携带的业务数据，以便触发第二数据库在变更日志中记录下第一数据库的标识；

在开启一个事务之后，首先可以在事务中插入一个预先为第一数据库定义的标识。也就是说，在同步管理系统中，可以预先为各个数据库定义一个标识，例如可以是channel_id，每个数据库在系统内对应一个唯一的channel_id。当某个数据库发起变更同步时，在目标数据库侧，则会首先开启一个事务，然后在事务中插入该变更同步发起方的channel_id。之后，还可以将同步变更信息中携带的业务数据，插入到事务中。

这里需要说明的是，在本申请实施例中，通过向事务中插入channel_id的方式，可以触发第二数据库记录变更日志，也即，可以将变更同步发起方的channel_id通过产生数据库变更的方式，记录到目标数据库的变更日志中。而向事务中插入channel_id的过程，可以按照SQL规范来进行，因此，只要目标数据库符合SQL规范，就均可以通过这种方式，将来源数据库的channel_id写入到变更日志中。

在插入了来源数据库的channel_id之后，还需要在事务中插入同步变更信息中携带的业务数据，以便第二数据库据此对具体的记录进行修改。当然，在插入了业务数据之后，还可以执行清理之前插入的channel_id标识的操作，以保证下次再进行变更同步时，不会受到影响。

例如，参见图2，假设其代表数据库的一个事务，则在事务的开头可以插入第一数据库的channel_id标识，接着，在插入了具体的业务数据之后，再将插入的channel_id标识清理掉，以代表此次变更结束。换言之，由于数据库是当数据库中的某条记录发生变化时，才会记录变更日志，因此，本申请实施例中就是通过update语句将数据库中某条记录的值改为channel_id，这样数据库就会将channel_id这一信息记录在变更日志中，之后，为了避免对后续的同步变更过程造成影响，可以将之前更新过的值重新改回默认值。

S103：将所述事务提交到所述第二数据库，以便第二数据库根据所述业务数据执行数据同步变更；

在事务中插入了来源数据库的channel_id标识以及具体的业务数据之后，就可以将事务提交到第二数据库，这样，第二数据库就可以执行具体的数据更新操作，使得其具体的数据条目与来源数据库中变更后的状态一致。也就是说，在第二数据库上进行事务提交操作，然后第二数据库会在事务提交之后确保能将事务对应的变更操作记录到变更日志中。其中，由于第一数据库的channel_id标识也是通过的SQL规范进行数据库变更操作，所以也可以和其他的业务变更一起，记录到第二数据库的变更日志中。

S104：在第二数据库同步变更完成产生新的变更数据后，判断所述变更日志中记录的标识与预先为第一数据库定义的标识是否相同，如果相同，则略过这条变更数据，以便不再向所述第一数据库发送同步变更信息。

对于第二数据库而言，在根据第一数据库中的同步变更信息完成数据的变更之后，由于其具体的数据条目也发生了变化，因此，也相当于产生了一条变更数据，在其变更日志中也会出现具体的变更信息，原则上讲，也需要向其他数据库进行同步。但此时，同步管理系统在获取到这种变更信息的同时，还可以从第二数据库的变更日志中读取出之前记录的来源数据库的channel_id标识，发现该channel_id是第一数据库的标识，因此，对于第一数据库而言，该条变更数据就可以忽略，也就是说，相当于第二数据库识别出该条变更数据是根据来源于第一数据库的同步变更信息产生的变化，因此，就可以不再向第一数据库发送同步变更信息。当然，如果第二数据库还需要向第一数据库以外的其他数据库进行同步变更，而这些其他数据库的标识并没有出现在第二数据库的变更日志中，因此，仍然可以向这种其他数据库发送同步变更信息。

为了更好地理解本申请实施例提供的具体方法，下面通过一个具体的例子进行详细地介绍。

参见图3，具体的数据同步过程可以包括：

S301：数据库A的业务系统通过操作数据库，产生了一些业务数据，例如用户发布一个产品数据等；

S302：同步管理系统通过mysql/oracle的日志协议，获取对应的数据变更信息，例如，DML/DDL事件；

S303：通过某种机制，将数据库A中获取到的变更信息，发送到数据库B上，通过SQL规范，将数据载入到数据库B中，载入过程可以包括：

S3031：开启一个事务Txa；

S3032：向事务中插入数据库A的channel_id标识；

S3033：向事务中插入业务数据；

S3034：清理掉数据库A的channel_id标识；

S3035：将事务Txa提交到数据库B；

S304：数据库B根据提交上来的事务执行完数据同步之后，在数据库B中也会产生关于这次变更的数据信息；

S3041：获取数据库B的变更日志中记录的channel_id标识；

S3042：在向数据库A发生同步变更信息之前，首先检查变更日志中记录的channel_id标识与同步管理系统为数据库A定义的channel_id是否相同，如果是，则这条新产生的变更数据属于回环数据，因此，对于数据库A而言，忽略这条变更数据，不再向数据库A发送，从而避免发生死循环。

可见，在本申请实施例中，由于是利用SQL规范，向事务中插入变更同步发起方数据库的标识，进而触发目标数据库将发起方数据库的标识写入到变更日志中，因此，只要是支持SQL规范的数据库，就都可以支持，这样，即使不同的机房之间存在异构的数据库，也仍然可以保证在进行双向数据同步的过程中，避免发生死循环的现象。另外，在第二数据库发生了一次数据变更时候，对于是否为从第一数据库发送过来的同步变更信息引发的变更的判断过程，是直接在第二数据库一侧进行的，如果发现是，则可以不再向第一数据库发送同步变更信息。而在传统的mysql内部的数据同步方案中，即使第二数据库是根据第一数据库发送的同步变更信息而产生的数据变更，也需要再从第二数据库向第一数据库发送同步变更消息，在第一数据库一侧进行判断是否需要忽略。因此，本申请实施例相对于现有技术而言，还可以减少网络传输量，提高实现的效率。

以上所述的数据同步方法可以防止在双向同步的过程中发生死循环，而在实际应用中，还可能存在以下现象：对于第一数据库和第二数据库而言，可能存在同时时间修改同一记录的情况，其中，所谓的“同一记录”可以具体到某张数据库表上的一条记录的一个字段，所谓的“同时”是指：第一数据库的数据发生了更新，在第二数据库中还尚未可见的时间范围内，第二数据中的该数据也发生了更新。例如，在t1时刻，数据库A的某条记录中某字段的取值由L1变为L2，随后数据库A中的同步管理系统就可以向数据库B发送同步变更信息，通知数据库B将对应字段的值由L1变为L2；但在数据库B尚未变更完成时，在t2时刻，数据库B中的该条记录中同样是该字段的值由L1变为L3（例如，可以是由于数据库B的业务系统中用户操作而引发的数据变化），此时，数据库B中的同步管理系统也会向数据库A发送同步变更信息，要求数据库A将对应字段的值由L1修改为L3；结果，在t3时刻，数据库B中对应字段的值变为L2，而数据库A中该字段的值却变为L3，使得两个数据库中同一记录上的取值不一致。但实际上，在出现这种不同的数据库同时对同一记录发生修改的情况时，应该是以其中一个数据库中的值为准，并保证两个数据库中的数据的一致性，否则，不同地域的用户看到的具体页面内容可能会不一致。

为了解决数据的一致性问题，在本申请实施例中，可以预先根据业务特点的需要，指定一个主站点，在步骤S104中，在第二数据库同步变更完成，并且检查发现变更日志中记录的标识与预先为第一数据库定义的标识相同后，还可以继续判断第二数据库是否为主站点的数据库，如果不是，则略过这条数据，以便不再向所述第一数据库发送同步变更信息。而如果是，则可以开启数据一致性补救方案，根据第一数据库发送的同步变更信息中携带的业务数据，重新向第一数据库发送同步变更信息。

为了更好地理解上述一致性补救方案，下面通过一个具体的例子进行详细介绍。

参见图4，假设主站点的数据库为数据库A，则在完成一次从数据库B到数据库A的同步之后，数据库A可以再向数据库B继续执行一次同步。具体的步骤包括：

S401：业务系统在数据库A中产生一些业务数据；假设由L1变为L2；

S402：业务系统在数据库B中产生一些业务数据；假设由L1变为L3；

S403：通过mysql/oracle的日志协议，获取数据库A的业务数据，生成同步变更信息；

S404：通过mysql/oracle的日志协议，获取数据库B的业务数据，生成同步变更信息；

接下来，对于数据库B而言：

S405：通过某种机制，将数据库A中获取到的同步变更信息，发送到数据库B上，通过SQL规范，将数据载入到数据库B中，载入过程可以包括：

S4051：开启一个事务Txa；

S4052：向事务中插入数据库A的channel_id标识；

S4053：向事务中插入业务数据；

S4054：清理掉数据库A的channel_id标识；

S4055：将事务Txa提交到数据库B；

S406：数据库B根据提交上来的事务执行完数据同步之后，使得对应字段的数据变为L2，同时，在数据库B中也会产生关于这次变更的数据信息；

S4061：获取数据库B的变更日志中记录的channel_id标识；

S4062：在向数据库A发送同步变更信息之前，首先检查变更日志中记录的channel_id标识与同步管理系统为数据库A定义的channel_id是否相同，如果是，则对于数据库A而言，忽略这条同步变更信息，不再向数据库A发送，从而避免发生死循环。

可见，对于数据库B而言，与图3中所示的过程基本相同，仍然是按照前文所提供的避免产生死循环的算法进行数据同步。

但对于数据库A，由于其所在的站点为主站点，因此，处理的过程会有所不同：

S407：通过某种机制，将数据库B中获取到的同步变更信息，发送到数据库A上，通过SQL规范，将数据载入到数据库A中，载入过程可以包括：

S4071：开启一个事务Txa；

S4072：向事务中插入数据库B的channel_id标识；

S4073：向事务中插入业务数据；

S4074：清理掉数据库B的channel_id标识；

S4075：将事务Txa提交到数据库A；

S408：数据库A根据提交上来的事务执行完数据同步之后，使得对应字段上的数据变为L3，同时，在数据库A中也会产生关于这次变更的数据信息；

S4081：获取数据库A的变更日志中记录的channel_id标识；

S4082：在向数据库B发送同步变更信息之前，首先检查变更日志中记录的channel_id标识与同步管理系统为数据库A定义的channel_id是否相同，即使相同，也开启数据一致性补救方案；

S409：构造变更事件，根据变更数据，反查数据库A获取当前数据库A中最新的值，重新将这批数据发送到数据库B中。也即重新向数据库B发送同步变更信息，携带上变更后的数据L3；

S410：数据库B侧，同样通过SQL规范，将数据载入到数据库B中，载入过程可以包括：

S4101：开启一个事务Txa；

S4102：向事务中插入数据库A的channel_id标识；

S4103：向事务中插入业务数据；

S4104：清理掉数据库A的channel_id标识；

S4105：将事务Txa提交到数据库B；

S411：数据库B根据提交上来的事务执行完数据同步之后，使得对应字段的数据变为L3，同时，在数据库B中也会产生关于这次变更的数据信息；

S4111：获取数据库B的变更日志中记录的channel_id标识；

S4112：在向数据库A发送同步变更信息之前，首先检查变更日志中记录的channel_id标识与同步管理系统为数据库A定义的channel_id是否相同，如果是，则对于数据库A而言，忽略这条同步变更信息，不再向数据库A发送。

至此，整个同步过程结束，最终使得数据库A以及数据库B中对应字段上的数值都变为L3，并且不会使得同步过程进入死循环。

也就是说，在上述实现过程中，主站点的数据库，在完成一次数据更新之后，即使发现此次更新来自于另一数据库同步过来的信息，也会重新向来源数据库发送同步变更信息，以保证两个数据库中数据的一致性。当然，作为非主站点的数据库一侧，在发现一次更新是来自于另一数据库同步过来的信息之后，就不会再向来源数据库发送同步变更信息，以避免进入死循环。

需要说明的是，关于如何设置主站点，可以是根据系统中的具体业务需求或者特点来确定。例如，假设某系统中包括杭州和美国两个站点，其中，卖家用户一般是在杭州的机房发布商品对象信息，而美国的用户一般是访问商品对象数据，并生成相应订单，等等。此时，如果发生变化的数据属于商品对象信息，例如，用户发布一个产品数据，则可以将杭州机房作为主站点，如果发生变化的数据属于订单数据，例如，用户生成某订单，则可以将美国机房作为主站点，等等。

另外需要说明的是，在前述例子中，相当于只要是主站点的数据库，就一定会执行一致性补救方案，但在实际应用中，如果在发生了从非主站点数据库到主站点数据库的同步更新的过程中，主站点数据库并没有就相同的记录发生其他的变化，则其实是不必要进行补救的，因为并没有发生两个数据库中的数据不一致的情况。因此，在具体实现时，在图4的步骤S4082中，还可以包括一个判断的步骤，也即判断在根据第一数据库发送的同步变更信息进行此次同步变更的过程中，第二数据库中是否对同一记录也产生了变更（例如，是否在数据库A根据数据库B发送的同步变更信息将L1变为L3的过程中，数据库A的业务系统将L1变为L2，等等），如果是，再开启数据一致性补救方案，根据第一数据库发送的同步变更信息中携带的业务数据，重新向第一数据库发送同步变更信息，也即，使得数据库B重新将取值修改为L2，保证两个数据库中同一字段数据的一致性。这样可以避免产生不必要的网络传输量，提高系统性能。

其中，具体实现时，为了能够判断出是否存在不同的数据库同时对同一记录发生变更，可以记录各个数据库发起的各次数据同步过程中，来源数据库中发生数据变更的数据变更时间，以及目标数据库中完成数据同步变更的数据同步时间，然后，判断第一数据库的此次同步变更过程的数据变更时间与数据同步时间构成的时段，与第二数据库中发起的同步变更过程的数据变更时间与数据同步时间构成的时段是否存在交集，如果存在交集，且是针对同一记录发生的变更，则判定在根据第一数据库发送的同步变更信息进行此次同步变更的过程中，第二数据库中对同一记录也产生了变更。也就是说，为了完成上述判断，可以定义两个时间概念，参见图5：

数据变更时间S：代表业务数据在原数据库中产生的时间，即图中的时间S；

数据同步时间E：代表数据变更载入到目标数据库的时间，即图中的时间E。

针对每条或者一批数据，记录变更时间S和同步时间E，同时保留历史同步过的数据记录。图5中纵轴为时间轴，A_aS代表从数据库A同步到数据库B的一个同步过程的变更时间，A_aE代表从数据库A同步到数据库B的一个同步过程的同步时间；B_aS代表从数据库B到同步到的数据库A的一个同步过程的变更时间,B_aE代表从数据库B同步到数据库A的一个同步过程的同步时间，以此类推。可见，每个同步过程在纵轴上会有两个点，分别代表变更时间A和同步时间B。首先，根据同一时间的定义，在两边数据库的各自同步过程中，以数据库A为例，在向数据库B同步变更的过程中，找到与（A_aS，A_aE）这一时间段有交集的同步过程，比如，在图5中，与（A_aS，A_aE）有交集的就包括（B_aS，B_aE）、（B_bS，B_bE）、（B_cS，B_cE）。针对有时间交集的同步过程，根据同一数据的定义，判断是否存在针对同一记录进行操作的同步过程。比如，首先判断（A_aS，A_aE）和（B_aS，B_aE）这两个同步过程对应的历史同步数据记录是否相同，例如是否都是对某数据库表中的同一条记录的同一字段进行的操作，如果是，则这两个同步过程确定为针对同一记录同时产生的数据同步。之后，还可以判断（A_aS，A_aE）和（B_bS，B_bE）这两个同步过程对应的历史同步数据记录是否相同，依次类推。最终可以确定出需要按照一致性补救算法重新进行同步的数据。

与本申请实施例提供的在数据库之间进行数据同步的方法相对应，本申请实施例还提供了一种在数据库之间进行数据同步的系统，参见图6，该系统可以包括：

事务开启单元601，用于接收到第一数据库向第二数据库发送的同步变更信息时，开启一事务；

插入单元602，用于通过结构化查询语言SQL规范，在所述事务中插入预先为第一数据库定义的标识以及所述同步变更信息中携带的业务数据，以便触发第二数据库在变更日志中记录下第一数据库的标识；

事务提交单元603，用于将所述事务提交到所述第二数据库，以便第二数据库根据所述业务数据执行数据同步变更；

判断单元604，用于在第二数据库同步变更完成产生新的变更数据后，判断所述变更日志中记录的标识与预先为第一数据库定义的标识是否相同，如果相同，则略过这条变更数据，以便不再向所述第一数据库发送同步变更信息。

其中，可以在事务的开头，通过SQL规范，插入所述预先为第一数据库定义的标识，以便将所述预先为第一数据库定义的标识通过产生数据库变更的方式，记录到第二数据库的变更日志中。

为了不会对后续的同步变更过程造成影响，还可以包括：

标识清理单元，用于在事务提交之前，清理对应的第一数据库的标识。

具体实现时，为了在出现不同的数据库同时对同一记录进行修改的情况下导致的数据不一致，所述判断单元604具体可以用于：

在第二数据库同步变更完成产生新的变更数据后，检查所述变更日志中记录的标识与预先为第一数据库定义的标识是否相同，如果相同，则判断所述第二数据库是否为主站点的数据库，如果不是，则略过这条变更数据，以便不再向所述第一数据库发送同步变更信息。

另外，系统中还可以包括：

一致性补救单元，用于如果所述第二数据库是主站点的数据库，则开启数据一致性补救方案，根据第一数据库发送的同步变更信息中携带的业务数据，重新向第一数据库发送同步变更信息。

其中，如果所述第二数据库是主站点的数据库，则判断在根据第一数据库发送的同步变更信息进行此次同步变更的过程中，第二数据库中是否对同一记录产生了变更；

如果是，则开启数据一致性补救方案，根据第一数据库发送的同步变更信息中携带的业务数据，重新向第一数据库发送同步变更信息

具体实现时，还可以包括：

记录单元，用于记录各个数据库发起的各次同步变更过程中，来源数据库中发生数据变更的数据变更时间，以及目标数据库中完成数据同步变更的数据同步时间；

所述判断单元604具体可以用于：

判断第一数据库的此次同步变更过程的数据变更时间与数据同步时间构成的时段，与第二数据库中发起的同步变更过程的数据变更时间与数据同步时间构成的时段是否存在交集；

如果存在交集，且是针对同一记录发生的变更，则判定在根据第一数据库发送的同步变更信息进行此次同步变更的过程中，第二数据库中对同一记录也产生了变更。

总之，通过本申请实施例提供的上述在数据库之间进行数据同步的系统，由于是利用的SQL规范，向事务中插入变更同步发起方数据库的标识，进而触发目标数据库将发起方数据库的标识写入到变更日志中，因此，只要是支持的SQL规范的数据库，就都可以支持，这样，即使不同的机房之间存在异构的数据库，也仍然可以保证在进行双向数据同步的过程中，避免发生死循环的现象。另外，在第二数据库发生了一次数据变更时候，对于是否为从第一数据库发送过来的同步变更信息引发的变更的判断过程，是直接在第二数据库一侧进行的，如果发现是，则可以不再向第一数据库发送同步变更信息。而在传统的mysql内部的数据同步方案中，即使第二数据库是根据第一数据库发送的同步变更信息而产生的数据变更，也需要再从第二数据库向第一数据库发送同步变更消息，在第一数据库一侧进行判断是否需要忽略。因此，本申请实施例相对于现有技术而言，还可以减少网络传输量，提高实现的效率。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的在数据库之间进行数据同步的方法及系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种在数据库之间进行数据同步的方法，其特征在于，包括：

接收到第一数据库向第二数据库发送的同步变更信息时，开启一事务；其中，所述第一数据库与第二数据库为同构数据库或者异构数据库；

通过结构化查询语言SQL规范，在所述事务中插入预先为第一数据库定义的标识以及所述同步变更信息中携带的业务数据，以便触发第二数据库在变更日志中记录下第一数据库的标识；

将所述事务提交到所述第二数据库，以便第二数据库根据所述业务数据执行数据同步变更；

在第二数据库同步变更完成产生新的变更数据后，判断所述变更日志中记录的标识与预先为第一数据库定义的标识是否相同，如果相同，则略过这条变更数据，以便不再向所述第一数据库发送同步变更信息。

2.根据权利要求1所述的方法，其特征在于，通过以下方式在所述事务中插入预先为第一数据库定义的标识：

在事务的开头，通过SQL规范，插入所述预先为第一数据库定义的标识，以便将所述预先为第一数据库定义的标识通过产生数据库变更的方式，记录到第二数据库的变更日志中。

3.根据权利要求1所述的方法，其特征在于，还包括：

在事务提交之前，清理对应的第一数据库的标识。

4.根据权利要求1所述的方法，其特征在于，所述在第二数据库同步变更完成产生新的变更数据后，判断所述变更日志中记录的标识与预先为第一数据库定义的标识是否相同，如果相同，则略过这条变更数据，以便不再向所述第一数据库发送同步变更信息，包括：

在第二数据库同步变更完成产生新的变更数据后，判断所述变更日志中记录的标识与预先为第一数据库定义的标识是否相同，如果相同，则判断所述第二数据库是否为主站点的数据库，如果不是，则略过这条变更数据，以便不再向所述第一数据库发送同步变更信息。

5.根据权利要求4所述的方法，其特征在于，还包括：

如果所述第二数据库是主站点的数据库，则开启数据一致性补救方案，根据第一数据库发送的同步变更信息中携带的业务数据，重新向第一数据库发送同步变更信息。

6.根据权利要求5所述的方法，其特征在于，所述如果所述第二数据库是主站点的数据库，则开启数据一致性补救方案，根据第一数据库发送的同步变更信息中携带的业务数据，重新向第一数据库发送同步变更信息，包括：

如果所述第二数据库是主站点的数据库，则判断在根据第一数据库发送的同步变更信息进行此次同步变更的过程中，第二数据库中是否对同一记录产生了变更；

如果是，则开启数据一致性补救方案，根据第一数据库发送的同步变更信息中携带的业务数据，重新向第一数据库发送同步变更信息。

7.根据权利要求6所述的方法，其特征在于，还包括：

记录各个数据库发起的各次同步变更过程中，来源数据库中发生数据变更的数据变更时间，以及目标数据库中完成数据同步变更的数据同步时间；

所述判断在根据第一数据库发送的同步变更信息进行此次同步变更的过程中，第二数据库中是否对同一记录产生了变更，包括：

判断第一数据库的此次同步变更过程的数据变更时间与数据同步时间构成的时段，与第二数据库中发起的同步变更过程的数据变更时间与数据同步时间构成的时段是否存在交集；

如果存在交集，且是针对同一记录发生的变更，则判定在根据第一数据库发送的同步变更信息进行此次同步变更的过程中，第二数据库中对同一记录也产生了变更。

8.一种在数据库之间进行数据同步的系统，其特征在于，包括：

事务开启单元，用于接收到第一数据库向第二数据库发送的同步变更信息时，开启一事务；其中，所述第一数据库与第二数据库为同构数据库或者异构数据库；

插入单元，用于通过结构化查询语言SQL规范，在所述事务中插入预先为第一数据库定义的标识以及所述同步变更信息中携带的业务数据，以便触发第二数据库在变更日志中记录下第一数据库的标识；

事务提交单元，用于将所述事务提交到所述第二数据库，以便第二数据库根据所述业务数据执行数据同步变更；

判断单元，用于在第二数据库同步变更完成产生新的变更数据后，判断所述变更日志中记录的标识与预先为第一数据库定义的标识是否相同，如果相同，则略过这条变更数据，以便不再向所述第一数据库发送同步变更信息。

9.根据权利要求8所述的系统，其特征在于，所述判断单元具体用于：

在第二数据库同步变更完成产生新的变更数据后，检查所述变更日志中记录的标识与预先为第一数据库定义的标识是否相同，如果相同，则判断所述第二数据库是否为主站点的数据库，如果不是，则略过这条变更数据，以便不再向所述第一数据库发送同步变更信息。

10.根据权利要求9所述的系统，其特征在于，还包括：

一致性补救单元，用于如果所述第二数据库是主站点的数据库，则开启数据一致性补救方案，根据第一数据库发送的同步变更信息中携带的业务数据，重新向第一数据库发送同步变更信息。