在应用定义的系统中一致性单元的复制技术方案

在应用定义的系统中复制一致性单元的体系结构。在源复制中的改变影响在改变单元及有关的一致性单元中的元数据改变。响应于由目标作出的同步请求，源列举更新的一致性单元、列举一致性单元的所有更新的改变单元、打包那些改变单元、送出打包的改变单元以发送到目标。在检测和解决冲突之后，目标在单个处理中应用该打包的改变单元。过程对每个改变持续进行。

【技术实现步骤摘要】

本专利技术涉及数据复制系统，且尤其涉及在应用定义的体系中数据的复制。
技术介绍
自从因特网出现后，复制若干不同的系统的数据组变得越来越重要。在故障情况，复制提供很大的数据冗余。复制还提供更大的数据可用性，更大的负载平衡，以及用户与数据之间地理上更大的邻近性。基于状态的复制系统利用一个被称为一致性单元的术语来定义紧密一致性的数据组。“紧密一致性”指的是给定的复制在一致性单元中包含全部数据或没有数据，这使得数据的使用者不必在只有部分数据出现时加以补偿。在基于状态的复制系统中一致性单元的概念不是新的。大多数那样的系统定义一致性单元的某些概念，但只停留在低水平上，即例如在表中具体一行中的所有数据一起发送一起应用的水平上。这些系统强制应用的程序编写者或者裁剪他们的数据以适合系统的预定的低级一致性单元(这不总是可能的)，或者写入额外的代码以检测并处理数据的不一致性，如处理不紧密一致的复制数据。如名称所表明的，应用定义的一致性单元给予应用程序规定对复制系统的紧密一致性的边界的能力。因而，那样的应用能够自由地以任何一种最适合数据的方式模型化其数据(而不是以最适合复制系统的方式)，同时减轻了处理不一致状态的复杂性。与一致性单元相对，改变单元是采用冲突检测和解决方法的数据的粒度(细节)，因而是保存“改变历史”的粒度(细节)。在大多数基于状态的复制系统中，改变单元固定于一个粒度或小选项组中的粒度之一，如具体的行或列。虽然可能定义改变单元和一致性单元相同的系统，有时也希望它们是不同的-或更特别地希望一个一致性单元包含多个改变单元。例如，考虑Customer(客户)，Order(订单)，和Order Detail(订单细则)数据库的第一复制R1和第二复制R2。若在第一复制R1上创建客户数据、订单数据和订单细则数据，最好数据作为第二复制R2上的一个单元那样一起复制和应用。即在此情况的一致性单元包括客户数据、该客户的所有订单数据和所有该客户订单的订单细则数据。现假设，在以后对该客户的记帐地址在第一复制R1上更新，且在此改变的复制对第二复制R2发生之前，在R2上输入了该客户的新订单。希望的结果是，在不做复制时，复制R1和R2均具有新的记帐地址和新的订单。这样此结果需要这两个更新不冲突，这就提出，记帐地址应在不同于该新订单的改变单元中。存在其它例子来说明需要区分改变单元和一致性单元的粒度，包括限止复制带宽等。还注意到，许多现代的基于状态的复制系统允许一致性单元包含多个改变单元。允许多点更新数据的现有的复制方案通常复制具体表格的行的纯改变，其中冲突的检测和解决发生在具体表格中一行或一列的粒度上。然而有需要复制语义上相关的诸行，因为它们是同一业务对象的一部分。传播纯改变到目标复制的传统的复制技术能传播改变到以多个表形式的多个行，那些表在语义上通过业务逻辑相关，并能在不同时间作为不同的处理的部分被应用。然而这些方案不保证在“业务对象”层上组合的诸行之间保持一致性。再次考虑包含来自三个数据库表客户、订单和订单细则的行的数据组的同步。假设用户应用插入新的客户以及新的订单和新的订单细则。传统上，复制不能保证保持在不同复制上应用这些改变的次序，但是可以传播插入项到客户表，随后到订单表插入项，最终到订单细则表插入项。若在应用订单改变和订单细则改变之间存在错误或重大的延迟，看来好像某些订单没有订单细则或对某些订单只能看到部分细则。(此情况一般只是暂时的，下次成功地完成同步时将得到解决)。然而如果象以前按照基于应用的一致性单元所定义的那样，应用要求所有逻辑相关的记录在给定时刻在任何方或者全部不出现或者一起出现，则只出现部分数据组就成了问题。另外例如，若有两个应用(或同一应用的两个实例)在系统上运行——第一个在复制R1上更新，第二个从复制R2上读信息，目的是从复制R2进行读取的应用依赖于那里的业务对象的紧密的一致性，而不限止该应用模型化它们在数据库中的业务对象的方式。在应用定义的系统中对有效的复制机制有越来越大的需求，它用于高度可伸缩的系统以便复制语义上相关的对象，使得在那些相关对象之间的关系次序约束被维持，且为向其它复制的转播保持在“业务对象”层上的一致性。如前所述，基于状态的复制系统必须一起发送和应用在给定的一致性单元中的所有更新。在单元粒度是固定的这些系统中，实现是相当直接的。然而，对于应用定义的一致性单元，需要附加的逻辑。
技术实现思路
下面提出本专利技术的简单概述，以提供对本专利技术某些方面的基本理解。此概述不是本专利技术的广泛的概论。不企图识别本专利技术的关键/重要元素或勾划出本专利技术的范围。唯一目的是以简化的形式提出本专利技术的某些概念，作为在后面提出的更详细论述的序言。本专利技术涉及一特征，用于在数据集中的复制，该数据集支持配置需要保持“业务对象”一致性的应用。本专利技术允许应用利用那样的同步行为，它严格地模型化业务对象而不是具体的行。按本主题专利技术的应用在定义复制范围的同时模型化业务对象，使得复制过程能传播整个业务对象——这就表明其它复制对业务对象的部分图像不可见。本专利技术便于使被改变的数据的业务对象被整体传播到其它复制。与按行或按列(传统系统的粒度水平)地传播改变不同，本专利技术通过将最小的粒度水平提升到在“业务对象”层上语义相关数据的组合，补充了传统的粒度。在关系型数据库的背景中描述应用定义的一致性单元时，本实施例在后面称为“逻辑记录”。在一个实施例中，组成一致性单元的诸行和列连接成公共的“父行”——一个表的唯一的一行，在“父表”中没有两行能是同一一致性单元的部分。父行是应用数据的一部分——例如若订单细则连接到订单，订单连接到客户，选择客户作为公共“父行”意味着与给定客户本身结合的该客户(如通过连接定义)的所有订单的所有订单细则组成单个一致性单元。(请回忆，每个之前的例子中，订单细则记录在一个表中，订单在第二个表，客户在第三表)。对一致性单元(如任何公共的改变历史)的复制元数据保持在“父行”上。通过分析这些行之间的连接以确定给定一致性单元的边界、一起发送任何更新到组成一致性单元的所有行、并应用目标复制上单个处理中有关的任何更新，复制系统保持紧密的一致性。因此，在需要所有逻辑相关的记录在给定时间和给定方整体出现或整体不出现的那些应用中，在一致性单元的有关行之间能保持关系和次序约束。在另外实施例中，大部分或所有应用数据能存在于单个表中，在此情况下应用希望将其组合到一致性单元的那些数据，没有到另外表中应用数据的公共连接。在目录服务中这种情况可能是普遍的，此时应用的所希望的一致性单元包括任意的目录对象组，每个目录对象可能整体包含在共同的表中。在此情况，相关对象的联系能通过共同的键值进行，如“consistencyUnitKey”目录属性的值。复制元数据能与一个对象一起存储，或存入只由目录复制系统使用的专用表中。除了在行或列的层次上以外，本专利技术还利用协调算法来在一致性单元层次上检测和解决冲突，并将解决的数据会聚到目标的复制。为实现上述和有关目的，这里将结合以下描述及附图描述本专利技术的某些示例方面。然而，这些方面仅表明了能利用本专利技术的原理的各种方法中的少数一些，而本专利技术不试图包括所有那些方面及它们的等效方案。结合附图，从下面考虑的本专利技术详述中，本专利技术的其他优点及新颖特征将变得本文档来自技高网...

【技术保护点】
一个便于数据复制的系统，包括：改变追踪组件，追踪与一致性单元的复制版本相关的元数据，所述一致性单元覆盖一个或多个同类的数据集合；和协调组件，分别比较元数据，使用元数据解决冲突，并会聚一致性单元的版本。

【技术特征摘要】
...

【专利技术属性】
技术研发人员：C纳拉亚南，RP辛格，JB帕勒姆，
申请(专利权)人：微软公司，
类型：发明
国别省市：US[美国]