复制

来自EEWiki.

复制是一种将数据自动地复制到其他系统的策略,其目的是为了进行备份或使数据更易于让别处的人员访问。复制还可以将数据分发到多个服务器中, 从而使不同的服务器用户都可以在权限的许可的范围内共享这份数据。负载均衡方案将输入的请求分发到合适的服务器。这是群集系统的概念,通常用于繁忙的Web站点。

镜像和某种形式的RAID(冗余廉价磁盘阵列)自动地将数据复制到其他驱动器以便提供容错功能。数据库通常要进行复制,但复制策略也可能应用到文件组或整个服务器,其中要求进行数据库分区和自动同步。同步涉及到检测和分析文件差异,特别是在设备发生故障,数据有可能损坏甚至丢失的情况下。这在实时复制方案中尤其困难,因为必须在所有的复制站点同时进行更改或者完全撤销。

具有分支机构的组织通常使用复制策略将整个数据库或数据库的一部分复制到远程机构。这使信息离该分支机构的用户更近,因此免除了用户通过WAN链接访问公司办公室中的主数据库的麻烦。其目的是为所有用户提供对数据的一致的浏览,而不管他们所处的位置如何。

使用另一种复制策略是出于安全的考虑。假设一个Web服务器在防火墙公共的一边,因此该Web服务器易受到攻击。复制服务器可以用来解决网络上相同数据多份拷贝及同步更新这一分布事务处理中的关键难题，在处理分布更新方面与传统的两阶段提交相比，明显提高了效率和可用性，为分布式联机事务处理提供了新的技术和方法。Web管理员可以在防火墙内保留一个复制服务器,所有的更新和更改都在它上面进行。对该“主”Web服务器所做的更改自动地通过防火墙复制到公共Web服务器中。如果公共Web服务器受到攻击,它可以快速地从主服务器中恢复。服务器之间的连接可使用非TCP/IP链接(例如IPX(网际数据分组交换))建立,于是可以防止基于Web的攻击者穿过复制链接访问。

下面介绍文件、目录和数据库复制方案。

Web复制

复制是万维网上的常见技术。例如,位于美国纽约的Web服务器上的信息可能被复制到位于洛杉矶的镜像站点。然后,加里福尼亚的用户可以访问洛杉矶的站点,这样就省掉了连接到纽约站点的大量路由器中继站。代理缓存服务可执行类似复制类服务,它将多次请求的网页复制到自己的内存中并确保具备那些网页的最近的更新。这是一种“拉出”技术。

Web站点使用另一种策略将其中受请求最多的网页“推送”到代理服务器中,而且将站点缓存起来(通常是紧接着进行更改之后)。网页通常被推送到“内容分布”站点,这是一些全球分布的Web站点,专门设计来将Web内容放到离用户更近的位置。

IETF Web复制和缓存(wrec) 工作组正在开发用于Web的复制策略。

文件和目录复制

目录是一个为查询、浏览和搜索而优化的专业分布式数据库，它成树状结构组织数据，就好象Linux/Unix系统中的文件目录一样。目录服务是由目录数据库和一套访问协议组成的系统。目录服务系统一般由两部分组成：第一部分是数据库，一种分布式的数据库，且拥有一个描述数据的规划；第二部分则是访问和处理数据库有关的详细的访问协议。

Microsoft Windows 2000、Novell NetWare和其他服务器操作系统使用导入/导出复制方案,其中主服务器被设计成导出服务器,而其他服务器设计成导入服务器。导出服务器将数据复制到一个或多个导入服务器中。导出服务器上的目录设计成复制目录。在目录中存储的任何文件或更改的任何文件自动地复制到导入服务器中。当向主目录添加文件或信息更改时,复制会定期地自动进行。导入服务器可能位于同一个LAN上或通过WAN链接。

网络操作系统(例如Novell NetWare 和Microsoft Windows 2000)常用到目录服务。目录服务是一种特殊类型的数据库,它保存用户帐户信息和关于网络上的资源的信息，使得我们可以根据对象的一个或多个属性来查找对象。管理员使用数据库管理用户帐号和设备。例如：管理员可能不知道一个对象的确切名称，但知道哪个对象的一个或多个属性。采用目录服务，他们便能查询目录，以获得与已知属性相匹配的对象列表。例如，他们可以查询与第3层属性相关的所有彩色打印机对象所在的目录或可能已经设为第3层的位置属性。用户访问数据库可找到打印机和存储设备之类的资源。目录还保存策略信息,该信息向网络设备描述用户将来应当获取的服务类型。

LDAP是一种常见的目录访问协议,大量的目录服务用它来为应用程序提供对该目录的开放访问。本协议特别针对那些简单管理程序和浏览器程序，它们提供对 X.500 目录进行简单的读/写交互式访问，同时它也是对 DAP 本身的一种补充。编写LDAP查询代码比DAP简单，但是LDAP的功能不是十分完善。例如，如果没有找到地址，DAP可以在其他的服务器上进行初始化寻找，但是LDAP就不具备这个功能。LDAP是活动目录的主要的访问协议。名为LADP Duplication/Replication/Update Protocol (ldup)的IETF工作组正在对以下复制方案进行标准化:

多主目录复制 一种允许在不首先通知其他副本的情况下对任何副本进行更改的模型。

主-从,或单个-主复制 一种存在一个主目录和一个或多个从目录的复制模型。主目录控制对复制数据的写入。 　　 NDS（Novell目录服务）是一种流行的软件，它能够从管理的角度上对计算机资源的访问进行管理并能跟踪网络用户。网络管理员通过使用NDS可以建立和控制用户数据库，并能够通过带有图形用户界面（GUI）的目录来管理他们。管理员可以对远程的计算机用户集中的进行添加、更新和管理。应用程序也可以自动分配并集中维护。NDS是树型结构,如图R-3所示；它可以拆成两个或更多的分区。某个分区可以复制到另一个位置。在示例中,整个数据库可以由位于New York的管理员管理；但数据库的WestDiv部分进行了分区并被复制到Los Angeles的办公室,所以该处的用户对数据库该部分中的信息可进行更直接地访问。

图R-3 Netware目录服务可被分区和复制

在NDS中,存在主副本、读/写副本和只读副本。数据库的结构只能在主副本上更改。读/写副本可以更改信息,但不能更改结构。只读副本只能进行读取,而不能更改。该体系确保在复制数据库间正确地对更改进行同步。进行更改之后,所有的副本进行更新。这些更新尽可能地快,但不是立即完成,因为持续的同步将会消耗网络带宽。多数情况下,目录信息复制的微小延迟不会导致错误。

Microsoft Windows 2000 Active Directory 使用多主目录复制拓扑结构,其中任何域控制器都可以处理域数据库并将更改复制到它的复制伙伴。域控制器使用USN(更新序列号)查看复制伙伴是否更新了。Active Directory包含所谓的“复制拓扑结构生成器”。管理员确定向不同的位置发送数据的成本因素。然后,使用该信息建立站点间复制拓扑结构。

Active Directory分到各个站点,这些站点是基于积子网的数据库的分区。站点对拓扑结构生成器很重要,因为后者生成的拓扑结构更多地是用于站点内部,而不是站点之间。站点内的消息不进行压缩(这节省了CPU循环)。此外,站点内复制是即时的,而且基于更改,而站点间复制则安排成不影响WAN带宽。

数据库复制

Oracle、Microsoft SQL、Informix和其他数据库要求高级别的同步数据库复制。在很多情况下,要求使用实时复制来在贸易事务数据库之间保持同步。此外,跨平台支持是一种重要的功能,其中复制可以跨多个平台发生——例如,在Microsoft SQL Server 和 Enterprise Server之间。

PeerDirect,Inc.致力于实时复制体系结构的开发。它的Web站点中有大量的白皮书简述对企业数据库复制非常重要的关键性功能。该公司提倡一种基于连接的复制方案来与基于消息的方案竞争:

基于消息的方案 该方案也称为消息排队或存储和转发复制。它将更改的内容捕获并存储到历史队列中,过一段时间后再进行传输。排队的消息数据分组通过电子邮件、FTP、消息排队产品或相关的方法进行投递。

基于连接的复制 该方案在网络连接上实时地执行点到点的面向会话的复制；在网络连接中,两个数据库积极地参与复制会话并同时发送和接收更改。其中不存在更改日志或更改排队。　PeerDirect的实时复制产品直接从数据库读取最新的数据,并通过引用固定大小的控制表来动态地确定哪些数据进行了更改。该方法比其他方法要简单,因此效率更高。

Microsoft SLQ Server 7.0版本使用的复制模型可提供大量的功能。它建立在先前的“发布和订购”模型基础上并包含大量管理复制进程的代理。后面即刻对它们进行描述。这里先简要介绍Microsofts SQL Server复制模型的基本组件:

Publisher为订阅者进行复制时提供数据并检测已更改的数据。

Subscribers 存储副本并接收更新的服务器。

Publication 要发布的信息,包括表、表中的特定行或列或存储的过程。

Distributor 包含分布数据库的服务器。

Pull subscription 请求获取在发布者处所做的更改的更新的订户。自动移动用户的最佳选择。

Push subscription 在订户没有特别请求的情况下,发布者在更改发生时将它们传送给订户。

Snapshot agent 在某个时刻为数据库创建一张图片,图片可复制到其他站点。具有当前价格的产品目录是其中一个例子。

Distribution agent 将在分布数据库中保存的事务和快照作业移到订户。

Merge agent 合并代理移动并协调在创建最初的快照之后发生的增量数据更改。

Microsoft SQL Server支持大量的复制解决方案,因为商业活动具有不同的复制要求。而一方面需要保持事务一致性,即应保证所有的站点在同一时刻具有相同的数据值；这样的一个例子是应收帐款应用程序,其中,所有站点必须具有相同的发票更新。而另一方面,又允许一定程度的站点自主性；例如,无线销售小组用膝上计算机接收订单,而直到销售人员连接到中央办公室才将订单输入系统。

SQL Server提供三种类型的复制,这里分别进行说明。

快照复制

在一定时刻对数据库中要进行复制的数据进行快照,然后将快照发送到订户。例如,对最新的产品价格进行快照并将它复制给销售人员。快照复制并不像事务复制那样要不断地监视、跟踪在出版数据库中发生的数据变化，它所复制的内容不是 INSERT、UPDATE、DELETE语句（事务复制的特征），也不是仅限于那些被修改数据（合并复制的特征）。它实际上是对订购数据库进行一次阶段性的表刷新，把所有出版数据库中的数据从源数据库送至目标数据库，而不仅仅是那些发生了变化的数据。

快照复制是最为简单的一种复制类型，能够在出版者和订购者之间保证事务的潜在一致性。快照复制通常使用在以下场合：不需要实时数据时，如在进行决策支持、查询静态表信息时；只读订购者（订购者不对出版数据进行修改），并且不需要最近的数据；使用立即更新订购者时对数据库的修改次数和数据量较少。

事务复制

事务复制在网络中传送的是事务（由一条或多条INSERT、 DELETE、UPDATE）；从传输的数据量来看，事务复制仅将发生的变化传送给订购者，是一种增量复制。其中对数据所做的更改进行检测,并将更改连续地或隔一定的时间间隔发送到一个或多个订户。发送更改差不多是实时的,只有几秒的延迟。要进行真正的实时发送,需要在发布者和订户之间建立直接的网络连接。为确保事务一致性,所有的更改应当在发布站点进行,而且只将完全提交的事务发送到订户。订户可以修改复制的数据。事务复制只允许出版者对复制数据进行修改，而不像合并复制那样，所有的节点（出版者和订购者）都被允许修改复制数据，因此事务复制保证了事务的一致性。它所实现的事务一致性介于立即事务一致性和潜在事务一致性之间。 　　 合并复制

合并复制作为一种从发行者向订户分发数据方法允许发行者和订户对出版数据进行修改，而不管订户与发行者是相互连接或断开，然后当所有（或部分）节点相连时便合并发生在各个节点的变化。合并复制在发行者和订户之间提供高度的自治,它允许二者在一定时间内独立地操作。当发行者和订户之间重新连接时,对它们的更改进行合并自动地解决它们之间的冲突。快照代理和合并代理执行合并复制。快照代理预备包含架构和已发行表的数据的快照文件,将文件存储在分发服务器上,并将同步作业记录在发行数据库中。合并代理使用于最初的快照作业在分发数据库表中保存的订户。它还合并在创建最初快照之后发生的增量数据更改,以及按照您配置的规则或使用您创建的自定义冲突解决程序解决冲突。

在合并复制中，每个节点都独立完成属于自己的任务，不像事务复制和快照复制那样订购者与出版者之间要相互连接，完全不必连接到其它节点，也不必使用MS DTC来实现两阶段提交就可以在多个节点对出版进行修改，只是在某一时刻才将该节点与其它节点相连（此时所指的其它节点并不一定指所有其它节点），然后将所发生的数据变化复制到这些相连节点的数据库中。 如果在复制时因更新同一数据而发生冲突，则数据的最终结果并不总是出版者修改后的结果，也不一定包含在某一节点上所做的所有修改。因为各节点都有自主权，都可以对出版物（复制数据）进行修改，这样在按照所设定的冲突解决规则对冲突处理之后，数据库最终的结果往往是包含了多个节点的修改。