转载

Sybase RS 介绍

FROM:http://wenku.baidu.com/view/7de7eb7d27284b73f24250cb.html?from=share_qq
Sybase复制服务器用来满足日益发展的企业客户/服务器计算机环境的需要。
一个使用的复制系统必须考虑到以下的业务要求：
1、数据的可靠性
     复制系统将应用系统更加可靠，尽量减少计算机系统失败给业务处理造成的影响。
2、信息传递一致性
     分布系统必须保护系统内部数据一致性。
3、高性能
     复制系统必须不增加数据源的负担，有效的使用网络，允许每个节点优化本地数据的存取方式。
4、方便集中管理
     系统管理员能方便容易的管理分布环境的数据。
5、异构数据源访问
      复制系统有能力在不同厂商提供的数据源之间移动传递数据。
6、本地自治
      每个节点能决定自己将接受哪些数据，怎样访问修改节点数据。

下面给出一些例子，Sybase如何将复制服务器用于分布式企业客户/服务器环境，复制服务器系统中主要有以下三种类型节点：
Primary（仅本节点有主数据）
       其它节点数据均由主节点复制而得。通过修改主节点数据改变其它节点数据。
Secondary（仅含有复制数据）
       复制节点用以接收一个或多个主节点的数据。复制节点数据是只读的，不能被修改。
Peer_to Peer（既包括主数据也包含复制数据）
       既可以从这个节点复制数据到其它系统，也可从其它节点接受数据。在这种环境中要避免或解决修改冲突。

通常情况下，在一个复制系统中可以包括几种节点，这由应用系统的要求而定。

示例1：One Primary-----Multiple Secondary

Sybase RS 介绍

这种模式需用于决策支持系统（DSS）。
这是一种简单模式，SYBASE复制服务器提供一种方便有效的方法从中央节点分布数据到多个复制节点，但在复制节点数据只允许读不允许修改。这样的复制机制保护分布环境数据一致。
在图一所示系统中，某公司使用一个中央OLTP数据库，这个数据库在洛杉矶处理进入本系统的订单。订单处理过程由终端或其它客户机直接连到中央OLTP系统。管理组织中其它部门的决策人物（财务部门在洛杉矶；生产部门在达拉斯；销售部门在纽约）都希望看到订单信息来决定本部门的计划。这些决策层应用不允许访问OLTP系统，因此他们希望得到的信息只能依靠中央工作人员给出标准报表，不可能有自己的随机数据检索。
SYBASE复制服务器的使用，改善了应用系统的性能。每个部门可以向中央数据节点订阅自己所需要的数据，这些数据由中央节点传送到各部门本地节点。数据传送过程由复制服务器完成，完全不需要人工干预。一旦本地有了决策支持数据的拷贝，财务，生产，销售部门便可以在本地进行自己的数据操作，而不再需要跨越广域网注册到在洛杉矶的中央数据服务器上。各决策支持系统之间彼此独立，由于不再访问远程数据节点，他们能更快地得到查询信息。
示例2：Multi Primary-----One Secondary
Sybase RS 介绍

SYBASE复制服务器提供方法将存放在不同节点互相关联的数据聚集在同一节点。以下介绍便是一例。

这是一个跨国公司，分别有生产部门在汉城、法兰克福和墨西哥城，总部在波士顿。在远程三个节点分别存放各自生产情况数据。总部需要实时更新的数据，了解整个公司情况。复制系统将三个节点数据合并在一起，放在总部供查询。总部看到的数据与各节点实时修改的数据仅几秒钟的差异。
示例3：Peer-to-Peer( 没有update 冲突)
前两例中，复制数据是单方向的，第一例中是从一个节点到多个节点；在第二例中数据从多个节点复制到同一个节点，但是复制并不是只能将数据单方向传递。本例将展示一个复制系统环境，每个分布系统中即包含有主数据也包含有复制数据。这个公司跨越全美（亚特兰大，芝加哥，西雅图），几个节点数据系统希望将雇员信息合并在一起。但每个地区只管理本地区雇员的信息（其它地区雇员信息在本地只能阅读）。SYBASE复制服务器提供一个机制将分布的雇员信息得以共享。

因为每个雇员仅属于一个地区，那么本地区雇员信息能从归并在一起的完整数据集中识别出来，不致于造成修改冲突，每个节点上，本地区雇员数据为主数据，另两地数据在本节点为复制数据。在系统中有这样约定，亚特兰大分公司仅能修改亚特兰大雇员信息，芝加哥同样仅能修改芝加哥数据等等。这个系统中的每个节点均能阅览完整的全公司的数据，这些数据是实时更新的。
Sybase RS 介绍

示例4：Peer-to-Peer ( 有update 冲突)
在上例中，尽管每个节点存放公司全部信息，但每个节点仅允许修改本地相关数据，不可能有两个节点修改同一数据。但某些情况下，业务需求要在多于一个节点上修改共同的数据。本例描写一个跨国软件公司技术支持在广域上的运作。公司技术支持分布在亚洲，欧洲，北美，每个地区技术支持都在响应本地用户要求。

在网上的技术支持人员共享一个Bug数据库。用户的全部问题记录在这个数据库中。三个节点上的技术支持人员都应该能插入和修改Bug数据库中的信息。因为现在有多于一个节点在同一时间修改相同的数据，那么技术支持的应用程序必须有办法解决修改冲突。
Sybase RS 介绍

示例5：Single Primary-Single Secondary
从技术角度上，复制服务器有另一个潜在的能力，它提供了一个有价值的可行的方法实现了近似实时的数据库备份。这个热备份数据可在主节点失败情况下，允许用户应用程序转换到热备份数据库上继续工作。
Sybase RS 介绍

这是一个大的电力公司，在中央电站有一个主数据库控制从发电到电力传送到最终用户的整个过程。控制电力传输的应用要求相当严格，在主节点需要一些冗余的资源保障系统安全可靠。例如主节点数据镜像到本节点的几个磁盘等等。但是在一些极端的事件发生时，比如地震，水灾，火灾等，电力传输线路也将受到破坏，既使有镜像数据，也无法保障系统工作。
在此例中，在广域网的另一个端点有一个完整的数据备份，在灾难发生时，它使应用程序连接到热备份数据源上，继续工作。
在建立这样冗余系统时，有一个重要的因素必须给予考虑。由于复制服务器的热备份仅能在正常条件下保证数据实时一致。因此在设计这样的应用系统时，必须能允许某种情况下的短暂的数据不一致。

复制服务器是如何工作的？
在这节中我们将描述SYBASE复制服务器产品的各个部份及它们的功能。复制数据操作可以分为四个部分：
Sybase RS 介绍

    对一个或多个数据源改变数据事务的监测
   在网络上传送事务
   将事务分发给各个目标数据源
   复制系统管理

在SYBASE复制服务器环境中，对源数据库中数据的修改由一个称为日志传输管理(Log Transfer Manager 简称LTM)的进程来实现。最典型的结构中LTM与源数据库放在同一个硬件平台上。
LTM将Log传送给复制服务器进程，复制服务器进程可以在另一机器上。在一个复制系统中，若干复制服务器的配置，可以分布在不同的局域网上，根据复制系统的配置，改变数据的Log从一个复制服务器传送到其它复制服务器，最后由这些复制服务器将数据改变传给目标数据库。完整的数据复制操作进程可以由一个基于GUI环境的复制服务器管理界面来管理和监控。因为在复制系统中使用了稳定队列（Stable Queue），数据从源数据库到目标数据库的途径中，能够避免系统中任一部分失败发生的数据丢失现象。稳定队列是一个安全机制，容错环境失败。
日志传输管理
SYBASE复制服务器产品有一部分为Log Transfer Manager(LTM).LTM是一个低调度进程，最典型的配置方法是将LTM运行在与源数据库相同的平台上。如果复制系统中将有多于一个节点的源数据被修改，则需要每个节点有一个LTM。
LTM的任务是监视并捕获与它相联数据库的事务，而且将这些事务传送给复制服务器，以便复制服务器将事务再传给其它的复制节点。
LTM有一个联接到SQL Server，读取主SQL Server的事务日志，监测它是否改变了主节点数据。事务日志是用来观察主节点数据变化的最好的信息来源，因为它包含已经提交给Server的事务，可用来恢复事务。在图六中，当某应用程序修改了主节点数据时，这个事务被记在事务日志中，以保证数据一致性，当提交时数据改变写入磁盘。复制进程不干涉数据库功能，只是LTM在监测SQL Server中的事务，当发现某个事务应该被复制时，将它传送给SYBASE复制服务器。
LTM进程，是一个由SYBASE Open Server/Open Client编写的应用程序，并有一个联接到SYBASE复制服务器。这个进程可以驻留在单独的机器上。正是由于SYBASE复制服务器进程可以运行在与主数据源不同的机器上，才使用户将复制系统对主数据库施加的负担降低到最小限度。
LTM进程可以将独立于主数据源命令的事务翻译给复制服务器。例如，一个事务中完成的是“update”，LTM将把事务传送给复制服务器并且给予解释，翻译成主节点完成的update命令。这个源数据库事务到复制服务器翻译或映射所认识的命令的机制是SYBASE复制服务器技术的一个重要策略。从LTM到复制服务器的界面对用户来说是可见的。也就是说，如果你能获得数据源的事务，就可以将它映射到SYBASE复制系统环境并且复制它。与其它竞争厂家产品不同，SYBASE复制技术允许建立应用程序来复制异构数据源。

数据在局域网和广域网上的传送
现在让我们来看，当信息从LTM传送到与之相联的复制服务器之后，又发生了什么？如果当数据与复制数据在不同的局域网上，那么复制进程将要把数据从主数据库的复制服务器传送到负责复制节点数据库的复制服务器。请注意，如果主节点与复制节点同在一个局域网上，那么可以省掉第二个复制服务器。在单一局域网复制环境中，一个复制服务器可以完成接受LTM数据并传送到复制节点两项任务，如图七。
Sybase RS 介绍

在多局域网环境中，不同SYBASE复制服务器之间路由可以是直接的，如图七不需要中间节点。也可以是间接的如图八。在主复制服务器与从复制服务器之间有中间传送节点。这些直接的或间接的路由是由系统管理员来配置的，允许系统管理员根据网络限制及应用程序传送数据的需要，有效地使用整个系统环境。在直接的及间接的配置状态中，可用复制服务器管理软件监视路由上传递的信息。
数据到达复制节点
在上两个标题中我们已看到LTM进程与服务器进程是如何协同工作的，将事务从主节点数据库送过网络到达目标节点。现在来看复制过程最后处理程序，复制服务器怎样把数据送到目标数据库。

前面已提到过，SYBASE复制服务器是由基于SYBASE Open Server/Open Client的应用程序。在复制的最后过程，复制服务器在目标数据库上建立一个联接，将从主数据库接收到的数据写入复制数据库。同样，复制节点可以是非SYBASE数据系统。

SYBASE复制服务器以标准客户/服务器联接方式连到目标数据库。并有足够的权限修改目标数据库。下面我们可以看到复制服务器怎样知道传送哪些事务，传送到什么地方。包含复制数据的节点要向复制系统订购它所需要的数据。至于订购单信息被存在与之相关的SYBASE复制服务器数据字典中。每个复制服务器有一个相应的数据字典。简称RSSD，用来存贮复制系统信息。

因为SYBASE复制服务器仅是简单地象其客户程序一样把事务传送到目标数据源，可以是非SYBASE数据源。用户可以使用SYBASE Omni SQL Gateway，让复制服务器联接到第三方数据源，使复制服务器认为复制节点就是SYBASE，从复制服务器到目标数据源之间传送数据不需做任何形式变化。

复制系统配置和管理工具

Replication Server Manager(RSM)是一个功能性很强的系统管理工具，使我们能成功地实现和管理分布复制环境。SYBASE正是认识到这一点，设计复制服务器的同时也设计了复制服务器管理程序。

正文到此结束