分布式系统数据复制

分布式系统数据复制（精选五篇）

分布式系统数据复制 篇1

分布式数据库系统是物理上分散而逻辑上统一的系统,就是将整个数据库结构按照某种情况分解为功能上相对独立的若干部分,放置在不同的数据库服务器上,并通过某种事务机制保证数据的一致性。在一个纯分布式数据库系统中,数据可以在很多个站点获得,但只有一个站点存储该数据;而在一个采用复制技术的分布数据库系统中,数据不仅可以在多个站点获得,而且可以就近或在本地获取,即同一数据可以在不同的站点上建立副本。数据复制提高了分布式数据库系统的可靠性及可用性。

2 数据复制运行机制

2.1 基本概念

复制是一种实现数据分布的方法,就是指把一个系统中的数据通过网络分布到另外一个或者多个地理位置不同的系统中,以适应可伸缩组织的需要、减轻主服务器的工作负荷和提高数据的使用效率。这个过程中,将分布式数据库中某个节点的数据拷贝到不同物理地点的数据库中,以支持分布式应用。在实现过程中,数据复制的物理过程分成两步:修改过程和复制过程。对一个数据拷贝进行插入、修改和删除的过程为修改过程;将修改过的拷贝的数据复制到其它拷贝的过程为复制过程。

数据复制技术能给分布式数据库系统带来如下几点好处:1)提高了系统的可靠性。通过将数据冗余分布提高了系统的容错能力。使得当一个站点或某段网络出现故障时,数据库可选择其它站点完成操作并对客户透明。并且由于数据在系统中存在多个副本,出现故障的站点也较为容易恢复。2)提高了系统的可用性。复制提供了对共享数据快速的本地访问,它通过将远程数据库中的数据复制到本地,使得应用能够就近访问数据,从而降低网络传输负载,提高效率。而且在数据复制系统中,可以提供多个站点之间的负载平衡,让这几个用户使用这个服务器,另外几个用户可以使用其他的服务器,以避免某些站点负载过重从而提高了分布式数据库系统的性能。3)减少网络通信,缩短数据存取时间。通过复制技术把用户可能用到的部分或者全部数据拷贝到本地数据库中,对数据的操作可以直接在本地进行,减少了网络通信开销,同时也提高了响应速度。

2.2 数据复制的分类

数据复制的分类有很多种,每种分类有不同的侧重点。

1)根据更新传播的方式不同,分为同步复制和异步复制:

同步复制(Eager Replication),同步复制方式要求修改过程和复制过程应同时进行,即所有副本在任何时间都应保持一致,这种方式主要采用两阶段提交或两阶段提交的变体来实现的。此类复制保证所有数据更新后的完整性优先于事务操作的完整性,即所有副本的数据在任何时候都是同步的,如果某个目标节点由于某种原因崩溃了,则正在进行的事务操作失败。同步复制可以保障所有副本的实时一致性但也带来易死锁、通信量增加、节点规模受限及事务响应时间较长等问题。目前看来,同步复制模式只适合在局域网上运行。

异步复制(Lazy Replication),异步复制方式允许修改过程和复制过程可异步进行,两者之间存在一个时间延迟。事务可以在任意时刻更新数据,稍后再更新其他副本的数据,使数据的每个拷贝之间一致。在异步复制中各副本间允许在一定的时间范围内部同步,但在完成复制过程后能达到数据的最终一致。当参与复制的某个站点有故障时,那个节点的复制过程暂时停止,等待发生故障的节点解除故障后再进行。异步复制对网络的要求大大降低,能够减少网络资源和硬件资源的消耗,对网络的连接状况呈现出更大的灵活性。异步复制的缺点是存在数据不一致的时间段并可能有潜在的数据冲突。此外,解决异构数据库间的复制问题时,还必须解决因模式定义上的差异引起的模式转换问题。

2)根据参与复制节点间的关系不同,分为主从复制和对等复制:

主从复制(Primary/Backup)中系统仅指定一个Primary节点,只有该节点能够接受更新请求,所有的修改过程只能在此节点上进行再由它将数据复制到其它副本中去。Primary/Backup方式并发控制较为简单,由Primary本地的事务控制即可实现,事务的原子性的实现也较为简单,一般由Primary节点作为协调节点来实现。但是,其缺陷也显而易见:仅仅单个节点提供更新请求处理能力,对于更新密集类型的应用,如OLTP,容易形成单点性能瓶颈。

对等复制(Update Anywhere)中的任何节点都可以接受更新请求,在检测事务冲突、事务提交前或后将各个节点的更新传播到其他副本节点。对等复制的实现较为复杂,由于数据可在任意的副本上更新,必然会引起事务冲突,因此采用对等复制的系统必须引入解决冲突的办法。

3)根据复制内容的不同,分为快照复制和事务复制:

快照(snapshot)复制是把数据库中存储对象在某一时刻的即时映像,通过为复制对象定义一个快照或采用类似方法,将它的当前映像作为更新副本的内容通过网络发送到其它副本。多长时间进行一次快照的复制,要根据实际的需求和环境决定。快照的复制是基于数据库中存储对象即时映像的复制。由于不是以事务为基础,所以副本缺乏基本的关系完整性。

事务(translation)复制是异步地把更新数据的事务通过网络发送给其它的副本,复制可以是修改的表项事务或事务日志。复制的时间可根据应用需求、网络情况和站点情况而确定。其它副本接收到复制内容后,要重复一遍接收到的事务。

3 数据复制在Oracle中的应用

数据复制被广泛的应用到当前各种商业数据库系统中如:Oracle,MS SQL server,Sybase,DB2,My SQL等都提供了许多数据复制的工具,针对不同的应用提出并研究了各种数据复制方法。这里主要介绍Oracle数据库中的数据复制技术。

首先介绍Oracle复制的几个基本组件:

1)复制对象(Replication Object):复制对象是一个数据库对象,它是存在于分布式数据库系统中多个服务器上的对象。利用O-racle的复制功能,可以复制表和其他支持的对象如视图、数据库触发器、包、索引和同义词等。

2)复制组(Replication Group:)通过将相关的数据库对象集中到一个复制组中来管理复制对象,这样使对象的维护变得简单。一种典型情况是,一个复制组支持一组与应用相关联的计划对象。复制组中的对象可以来自许多不同的计划;反之,一个计划被划分为许多复制组,只要每个对象只属于一个组即可。

3)复制节点(Replication site):它指的是复制组驻留的位置。对应于两种oracel复制方式(快照和多宿主),存在两种复制节点:宿主节点和快照节点。

4)主节点(Master Site):它维护复制组中所有对象的完整拷贝。多宿主复制环境中,所有宿主节点之间彼此通信,传送复制组中的计划和数据内容的变化。典型地,宿主节点的复制组称为宿主组。所有的宿主组都只有一个宿主定义节点(所有宿主节点的宿主),它是管理复制组和组中对象的节点。

5)快照节点S(snapshot Site):它既支持宿主节点中表的只读快照,又支持可更新快照。快照能从一个复制组的表数据中检索所有行或其子集。这些快照可能只是简单快照,不需要连接到宿主节点就能直接处理表。

Oracle支持三种复制机制:

1)多宿主复制(Multimaster Replication):多宿主复制方案支持全表在各个主节点间的对称复制,允许所有主节点对主表都有更新操作的权利。任何一个主节点上的复制表的更新都会被传播并被直接应用到其他所有主表。一个主节点出现问题,不会对其他主节点之间变化的传播造成影响。多宿主复制采用一种称为“延迟远程过程调用’’的机制作为主要的传播和应用变化的机制。各节点之间变化的传播,既可以以基于事件的方式立即传播,也可以在某个特定的时间点,如在网络空闲时(如晚上)传播。

2)可更新快照复制(Modified Snapshot Replication):这是一种允许快照可更新的复制机制。快照更新的传播方式和如何应用到快照主节点采用了和多宿主复制一样的延迟远程过程调用机制。快照在主节点的刷新是按照一定的时间间隔或用户单独请求进行的。最后一次刷新后主表的任何变化也同样被传播并应用到快照。多个快照的刷新是在一个一致的事务中完成的,这就确保了数据和引用的完整性。在传播变化时,如果其中的一个远端系统没有准备好,传播变化的延迟远程过程调用(即RPCs)就会保存在其本地队列中,等到系统准备好以后再执行。

3)混合配置:可以将多主复制和可更新快照复制结合在一起,构成一种新的混合配置,这种配置可以完成对全表或者子表的复制。例如下面这种应用就是一个典型的混合配置方案,一个系统具有两个位于不同地理区域的中心节点,这两个不同的地理区域下面还有一些分支机构,两个中心节点可以彼此看作是自己的备份节点。采用多主复制方法在两个中心站点之间复制数据,同时采用只读或者可更新快照复制方法在每个区域范围中的主节点之间复制全表或者子表。这种配置的一个显著之处就是当其中的一个中心节点发生问题时,这些快照的主节点可以被重新定义到另一个运行良好的中心节点,从而提高了系统的可靠性。

Oracle除了前面讨论的三种复制机制以外,还提供了另外两种复制机制:过程级复制和同步复制。过程级复制主要应用在存在大量数据更新以及采取批处理方式操作数据时需要复制数据的情况。在同步复制方式下,一个采用同步复制的表发生变化时,Oracle会确保这种变化能够成功地作用在本地表和其他节点的复制表,如果失败则整个事务会被成功回滚。同步复制在网络的稳定性比较高的情况下是可行的,可以保证复制节点之间的复制数据一直保持同步。

4 结束语

数据复制技术提高了分布式数据库系统的可靠性、可用性和可扩展性,解决了系统中各节点间同步数据,协同工作的问题。本文介绍了数据复制技术的基本概念,数据复制技术的分类及其实行原理,最后介绍了Oracle中复制技术的应用。随着越来越多研究者的关注,数据复制的研究成果也越来越丰富。但是,随着因特网和移动通信技术的发展,新兴的应用给该领域的研究带来了新的挑战,大量的问题有待进一步探索。

摘要：数据复制是分布式数据库系统中一项非常重要的技术,它提高了分布式数据库的容灾能力,降低了事务的响应时间。该文对数据复制技术进行了详细的研究,并介绍了数据复制在Oracle数据库中的应用。

关键词：分布式数据库,数据复制

参考文献

[1]Bernstein P A,Hadzilacos V,Goodman N.Concurrency Control and Recovery in DatabaseSystems[M].Massachu-setts:Addison Wesley,1987.

[2]Gray J,Helland P,O'Neil P E,et al.The Dangers of Repli-cation and a Solution[C]//Proc of the ACM SIGMOD Int'lConf on Manage-ment of Data,1996.

[3]赖万钦.Oracle复制技术在分布式信息系统中的同步应用[J].计算机时代,2007(3):37-39.

[4]高春雷,尹燕敏.分布式实时库的一致性实现[J].电力自动化设备,2005,25(4):83-85

分布式系统数据复制 篇2

介绍了基于中央数据库维修工程管理系统的.功能、网络结构以及系统性能,针对其存在的时效性问题,结合维修工程管理系统实际的运行环境提出了改善和优化的方案,即采用ORACLE高级复制技术重新设计系统的网络结构、数据库对象同步和异常处理机制以及高级复制环境的配置方法.

作 者：孙春林 刘如尧 张东培  作者单位：孙春林,刘如尧(中国民航大学)

张东培(中国国际航空公司工程技术分公司)

刊 名：航空维修与工程  PKU英文刊名：AVIATION MAINTENANCE & ENGINEERING 年，卷(期)：2009 “”(1) 分类号：V2 关键词： 

数据复制系统的研究 篇3

数据复制从执行复制的时间上分为定时复制和实时复制。定时复制是一种早期的备份技术, 备份设备多采用磁带设备, 其特点是成本低, 便于长期保存, 备份速度慢, 现在一般用来备份需要长期保存的数据, 这些数据的已经不是那么重要, 更多的是作为一种历史档案来保存, 等到数据的生命期结束, 即可销毁。实时复制又可分为同步复制和异步复制。同步复制和异步复制的关键区别在与源设备和目标备份设备对应用服务的响应是否一起返回。同步复制, 源设备与目标设备的一起返回响应。一般来说, 由于网络延迟因素的影响, 源设备的写入速度比目标设备的写入速度快, 所以出于同步的要求, 源设备的响应暂时被阻塞, 直到目标设备也返回响应后, 才一起反馈给应用一个共同的响应, 然后应用服务继续下一个IO请求。

一、实时复制中的同步复制

图1是同步镜像的流程图, 接受到I/O请求后, 镜像器把这个请求镜像出一个发送给备份设备, 接着源设备和备份设备独立返回I/O请求执行完毕的响应给镜像器, 镜像器收到两个响应后, 最后才返回一个I/O响应给应用服务。在只得到源设备或者目标设备任意一个响应期间镜像器会一直阻塞, 直到得到源设备与目标设备的两个响应后, 才返回一个I/O响应。

同步复制共同返回响应的特点决定同步复制的应用领域为延迟小的存储子系统, 即源设备和目标备份设备同属一个存储子系统, 包括同属一个阵列, 一个局域网内的设备, 专用的城际数据存储网络比如以光纤链路为主的FC-SAN。

二、实时复制中的异步复制

异步复制的流程图如图2。接收到I/O请求后, 镜像器把这个请求镜像出一个发送给备份设备, 接着源设备和备份设备依然是独立返回I/O请求执行完毕的响应给镜像器, 镜像器收到一个响应, 就立即返回一个I/O响应给应用服务。在只得到源设备或者目标设备任意一个响应期间镜像器并不会阻塞, 而是直接返回一个I/O响应。

相对同步来说, 异步复制不阻塞响应的特点非常适合用在用在延迟比较大的存储子系统中, 尤其是IP-SAN这种网络延迟不可预知的存储环境。

既然异步复制不能保证相同时刻源设备和目标备份设备上的更新是一致的, 那么两个设备上的数据必然存在差异性, 如何尽量缩小这个差异性, 提高源设备出故障后备份设备的数据完整性和高可用性, 就成为异步复制中重点研究的内容。

摘要：对各种数据复制不同实现机制进行介绍, 并详细阐述了它们之间的优缺点, 从而对数据复制系统的体系结构有所了解。

关键词：数据复制,数据一致性,写合并

参考文献

[1]刘颖娜:《一种基于IP的磁盘镜像方法:[优秀硕士学位论文]》, 四川大学图书馆, 2006:10～13。

[2]赵晓南、李战怀、曾雷杰:《保证多volume数据一致性的远程复制机制》, 《计算机应用研究》, 2008, 25 (10) :2951～2955。

[3]刘卫平、蔡皖东:《一种基于日志的异步远程镜像协议的设计》, 《计算机科学》, 2006, 33 (10) :80～83。

分布式系统数据复制 篇4

关键词：负载均衡,元数据服务系统,目录迁移,目录复制

0 引 言

随着计算机技术的发展,信息存储容量爆炸性增长,分布式系统提供了高性能、高可用、高扩展的数据访问服务。元数据作为“关于数据的数据”,提供关于信息资源或数据的一种结构化描述,能够帮助数据生产者有效地保存、管理和维护这些数据,也帮助了用户更快地发现所需的数据,更好地了解其内容和限制,并恰当地获取和使用它们。虽然元数据的大小在存储容量上仅占很小的比例,然而由于元数据访问非常频繁,因此,元数据的访问成为一个提高系统性能的瓶颈,对元数据的有效管理是获取存储系统高性能和高伸缩性的前提[1]。通常的做法是将文件的元数据访问与数据访问分离,由独立的元数据服务系统承担元数据服务MDS(Meta Data Server)。

随着分布式存储系统规模的增大以及元数据访问热度的增加,为保证对海量数据系统进行访问操作的速度,元数据服务系统中需要设置多个MDS节点。为了保证MDS节点能够提供高性能、可扩展的元数据服务就需要利用负载均衡来动态调整MDS节点的工作负载,以防任意一个MDS节点成为系统的瓶颈。

本文针对MDS节点的负载状态变化的情况,提出了一种元数据服务系统负载均衡策略,通过将目录迁移和目录复制相结合的方法,实现元数据服务系统的负载均衡,有效地提高了系统的速度、效率、稳定性和可靠性。

1 相关研究

传统的基于状态变化的负载均衡策略通常通过转移策略来确定负载均衡策略的驱动条件,通过负载迁移将负载重的MDS上的部分元数据转移到负载轻的MDS上来达到均衡的目的[2,3],然而当接收节点接收了热点节点迁移来的新的目录树,便加重了该接收节点的访问热度,可能会促使该节点成为热点节点,这样便出现了MDS系统进入新的不均衡状态,即出现“抖动”现象[4]。复制是通过创建同一个文件的多个副本来提高资源的可用性并且提高整个系统的有效性,在出现负载过重的情况时,同样可以通过复制解决,如图1所示。根据对目录迁移和目录复制的研究,提出一种将两者相结合的、由节点状态变化驱动的负载均衡策略。

1.1 负载均衡度

在一个元数据服务系统,元数据服务节点n的负载Ln可用CPU占用率Lcpu、内存占用率Lmem、I/O网络带宽利用率Lnetwork三项负载指标的加权和[5],即:

Ln=W1·Lcpu+W2·Lmem+W3·Lnetwork (1)

其中W1+W2+W3=1,且0≤Ln≤1。

元数据服务系统负载均衡度反映了系统的负载均衡程度,它定义如下:

$L{}_s=\frac{1}{n}{\displaystyle \sum _i\frac{[L{}_n-\overline{L}]}{\overline{L}}}$ (2)

其中$\overline{L}=\frac{1}{n}{\displaystyle \sum _{i=1}^{n}L}{}_n{}_{}$,且0≤Ls≤1。

Ls越接近0,系统的负载均衡程度越高,反之,越接近1,负载均衡程度越底。

1.2 负载指标的选择

负载的定义有很多标准,对于存放数据的设备来说,负载的评估要考虑多种因素:如请求队列长度、CPU、IO处理能力、网络带宽等,任何一个组件阻塞都有可能成为系统的瓶颈,因此通常通过计算系数加权成负载权值来衡量一个设备的负载[6,7]。存放数据的设备的负载情况与MDS系统的负载情况有很大差别,文献[1]采用了元数据请求的响应时间来衡量一个MDS的负载情况,但由于响应时间受网络带宽的影响较大,负载衡量的标准具有不确定性。对于MDS系统来说,它仅仅为用户提供元数据请求服务,因此元数据的请求率很高,本文采用元数据的访问热度Popularity来衡量一个MDS系统的负载情况,具有较高的精确度和稳定性。

在对外提供元数据服务时,每到来一个元数据请求时,相应请求的目录子树节点的访问热度增加1。若一台元数据服务节点上维护有若干目录子树,则该元数据服务节点的总访问热度为这些目录子树的访问热度之和。

1.3 发送节点集合和接收节点集合的确定

本文采用阈值策略来确定两类节点集合:发送节点集合和接收节点集合。通过收集MDS目录树的访问热度信息,确定每个MDS节点各自负载即访问热度的上限MaxLoad和负载下限MiniLoad。访问热度低于下限MiniLoad的低热度节点属于接收节点集合;访问热度高于上限MaxLoad的热点节点属于发送节点集合;当节点的负载处于上限MaxLoad和下限MiniLoad之间时,则该节点工作正常。

为表述方便,设置参数如下:

Ss:发送节点集合;

Sr:接收节点集合;

Sn:正常工作节点集合;

SendNode:发送节点;

ReceiveNode:接收节点;

Popularity(N):节点N的热度;

MaxLoad:访问热度的上限;

MiniLoad:访问热度的下限。

阈值策略确定发送节点集合Ss和接收节点集合Sr可用公式(3)表述。

1.4 目录迁移中发送节点和接收节点的定位策略

在定位均衡调度的发送节点和接受节点时,可采用首次适应算法或最佳适应算法。首次适应算法即以每次所找的第一个符合要求的节点作为目的节点,它的主要优点是平均调度检测时间较少,但是均衡效率不高。因此本文采用最佳适应算法,遍历发送节点集合列表SendNodeSet,按照访问热度从大到小排序,选取访问热度最大的热点节点为发送节点SendNode;遍历接收节点集合列表ReceiveNodeSet,按照访问热度从小到大排序,选取热度最小的低热度节点为接收节点ReceiveNode。

定位策略确定目录迁移中发送节点SendNode和接收节点ReceiveNode可用公式(4)表述。

2 元数据服务系统动态负载均衡策略

本策略是通过MDS系统实时状态来驱动的。通过阈值策略来判断是否存在热点节点,由此判定MDS系统是否已处于负载不均衡状态,进而启动负载均衡算法。

本策略对于目录迁移的接收节点进行了选择,只有通过阈值策略选择产生的低热度节点才能作为接收节点。当出现没有低热度节点时,将由目录复制来完成负载均衡。通过将目录迁移和目录复制相结合的策略,有效地减少了 “抖动”现象的出现,提高了系统的稳定性和负载均衡的效率。

2.1 目录迁移策略基本原理

元数据服务节点系统向用户提供元数据的相关服务,随着时间的推移,会出现系统内的服务器节点间承担的工作负载不均衡,这时需要将超载的节点的负载迁移到轻载的节点上,如图2所示。

对于迁移的目录子树,如果是主副本,则其“主副本”的身份也需随着目录子树迁移到新的节点上去;如果是普通副本,则只需做迁移即可。

2.2 目录复制策略基本原理

初始时,元数据服务节点的每个目录子树都只有一个副本,成为主副本。随着访问的增加,出现某一目录访问热度过高时,就将这一目录子树进行多副本复制,以达到分流请求、降低访问热度的目的,如图3所示。

对于复制出来的副本,仅具备只读属性,而对于目录子树的“写”请求,只能由维护主副本的元数据服务节点服务。

2.3 一种新的策略

结合以上研究,提出目录迁移与目录复制相结合的策略,流程图如图4所示。

该策略过程:

(1) 更新MDS节点列表,各MDS节点的访问热度。

(2) 通过阈值策略判断是否存在热点节点,如果存在,则继续执行负载均衡策略;如果不存在,则返回。

(3) 若存在热点节点,继续通过定位策略确定发送节点SendNode。

(4) 通过阈值策略判断是否存在低热度节点。如果存在低热度节点,则执行目录迁移策略;如果不存在低热度节点,则执行目录复制策略。

(5) 若进行目录复制,则继续确定目录复制的接收节点。遍历正常工作节点集合列表NormalNodeSet,按照访问热度从小到大排序,选取热度最小的正常工作节点为目录复制的接收节点ReceiveNode。

(6) 进行一次目录迁移或者目录复制。

在进行完一次目录迁移和目录复制后,可能不能使系统的立即回落到负载均衡状态,可以通过若干次迁移或者复制,使系统最终重新回到负载均衡状态。

传统目录迁移策略易产生“抖动”现象,主要是由于接收节点的选取不当,若以负载能力较低的节点作为接收节点,“抖动”现象产生的可能性会很大。本文提出了使用阈值策略,判断低热度节点的方法,将负载能力相对较高的节点作为接收节点,有效地减小了“抖动”现象的产生。对于不存在低热度节点的系统,则利用目录复制分流请求的特点,完成负载均衡。

3 实验与分析

编写仿真程序验证上述负载均衡策略。假设元数据服务节点系统由四个同构的元数据服务节点构成,分别是MDS1、MDS2、MDS3、MDS4,在这四个MDS节点上建立目录树,每个目录树结构为5层,每个节点有5个子节点,共781个元数据节点。分别在未启动负载均衡策略、启动传统负载均衡策略和启动新的负载均衡策略下,连续10小时发送元数据请求,并记录系统负载均衡度,通过对比来验证上述研究的负载均衡策略的可行性与有效性。这里认为系统的内存占用率较其他负载权值参数重要些,因此采用的权值为{0.2,0.6,0.2}。实验结果如图5所示。

从实验结果可以看出,启动新的负载均衡策略后,元数据服务系统的负载均衡度下降,也未出现“抖动”现象,达到预期目的。但是该策略本身也占用了一定的系统资源,并需要定期采集工作负载信息。

4 结 语

本文提出了一种基于状态驱动的元数据服务系统动态负载均衡策略,将目录迁移与目录复制相结合,解决了传统的单一利用目录迁移来进行负载均衡容易造成“抖动”的缺陷。但是这种负载均衡策略本身也占用了一定的系统资源。对于目录复制,可以通过研究最小副本数来降低目录复制的重复操作次数以获得更高的效率。对于目录迁移,也可以实行“一对多”迁移,将负载过高的节点进行“切片”然后迁移到其他节点的方法。

参考文献

[1]王娟,冯丹,王芳,等.一种元数据服务器集群的负载均衡算法[J].小型微型计算机系统,2009,4(4):757-760.

[2]Chen Zhigang,Zeng Zhiwen,Tang Xiaolong.Analyzing three tier C/Sapplication with the LPT algorithm[J].IEEE Computer Society,2000,1(5):14-17.

[3]陈志刚,曾志文.中间应用服务器动态负载均衡的物理模型[J].计算机工程,2001,1(1):44-45.

[4]刘建,李绪志.一种动态负载均衡机制的研究与实现[J].计算机工程与应用,2006(2):142-145.

[5]舒万能,郑世钰,陈广东,等.校园网格的负载均衡算法研究[J].计算机技术与发展,2006,16(1):126-128.

[6]Shan Zhiguang,Dai Qionghai,Lin Chuang,et al.Integrated schemes of Web request dispatching and selecting and their performance analysis[J].Journal of Software,2001,12(3):355-366.

分布式系统数据复制 篇5

关键词：复制,数据库复制,采供血管理,复制点,主点

一、数据库复制技术应用的背景

sybase数据库系统已被广泛应用于各企事业单位的计算机信息系统中, 通常数据库系统管理员每天要进行手工dump备份或bcp备份, 但几乎不进行异地实时备份, 这不符合数据异地容灾的原则, 存在着数据不安全的隐患。其实, sybase先进的复制服务器技术是实现数据库实时异地备份的很好途径, 实现容易, 投资小, 易维护, 但是一般人知之甚少, 没有被广泛应用。武汉血液中心是一家不以盈利为目的的采供血机构, 承担着武汉地区的采供血任务, 不同献血者档案总计有150万人, 每年供血量超过50吨, 如何保证数据安全以及计算机信息系统24小时不间断运行成为了我们关心的重要议题。武汉血液中心自2005年起应用subase复制服务器技术, 取得了不错的效果。

二、数据库复制技术作用

复制是在多个节点完成的数据库备份, 其目的是保持数据库系统各节点中数据状态的一致性.数据库复制技术可以实现异地实时备份与负载均衡。

1.多个数据库副本情况下, 单个或多个出现故障, 其他正常副本可以继续提供服务, 实现异地实时备份。

2.多个副本一般可以并行处理请求, 从而避免单点瓶颈, 可以显著提高吞吐率, 进而提升性能。

三、采供血机构数据管理现状

(一) 可用性方面。

全国300多家采供血机构基本上都应用了血站计算机信息系统, 数据备份方式为:dump数据库全库备份、bcp数据库表备份, 可以手工备份也可以自动定时备份。如果数据库故障, 将根据故障类型分为:可以修复的数据库故障、不可修复的数据库故障。

1. 可以修复的数据库故障:

发生数据库故障后, 系统管理员立即组织对数据库日志进行分析, 评估系统恢复需要的大致时间, 并通知相关科室暂停计算机系统操作, 由科室启动手工操作应急方案并做好手工记录, 数据库修复后, 信息中心验证数据库是否可用, 数据是否有丢失现象, 无任何问题后通知各个科室恢复正常工作。这需要各个科室将手工操作记录补录至信息系统内, 各个科室工作秩序与流程被打断, 科室需要对手工操作相当熟悉。

2. 不可以修复的数据库故障。

发生数据库故障后, 如果确认数据库损坏, 无法恢复, 只能用先前的备份数据恢复, 会存在如下问题:由于备份时间点与故障时间点不一致, 会造成自备份时间点至故障时间点的数据丢失;各个科室要手工补录自备份时间点至故障时间点的数据, 会造成部分补录的数据失真, 补录数据会浪费大量人力、物力, 正常工作秩序、流程被打乱, 工作人员精神高度紧张。发生故障后, 用先前备份的数据恢复需要的时间很长, 少则3-5小时, 多则1-5天, 有的必须要软件供应商工程师到达现场后才能实施。

(二) 性能方面。

由于无其他副本, 所有请求都通过一个数据库服务器响应, 速度很慢, 有时无法忍受。

四、sybase复制服务器在武汉血液中心的应用

血站质量管理规范中明确指出, 必须建立和实施针对管理信息系统瘫痪等意外事件的应急预案和恢复程序, 以保证血液供应[1]。

武汉血液中心自1999年8月份开始全面使用计算机信息系统控制采供血的主要过程, 1999年-2004年由于硬件条件所限、投入不足, 一直是单点运行, 发生过几次数据库故障, 工作了受到了很大影响。2005年初, 武汉血液中心开始应用sybase数据库复制技术, 主要完成目标为:异地数据热备份、负载均衡。武汉血液中心BIS (Blood Information System) 系统在建立主点双机集群的同时, 又在复制点上建立了用于查询的BIS数据库, 通过Sybase复制服务器实时单向数据复制, 达到两个数据库的数据一致性。我们将复制服务器 (RS) 安装在复制点服务器上 (具体的安装、表复制定义、预定等步骤略) , 结构见图1。

1.主节点1与主节点2建立双机热备集群, 主节点部署在业务楼主机房, 复制点部署在行政楼备用机房, 当主节点1发生故障时, 主节点2接管数据库服务。

2.当磁盘柜或数据库data出现故障时, 复制点ASE接管数据库服务。

3.在dump与bcp备份等差异备份存在的同时, 又实现了异地实时备份, 数据安全系数几乎达到100%。

4.复制点也可以接管一部分数据查询事务, 减轻主节点服务器的压力, 避免了反应慢, 死锁现象的发生, 提高了吞吐率, 做到了负载均衡。

五、数据复制系统的实现方法

1) 安装复制点数据库csbt, 结构与主节点数据库完全一致, 将数据库所有表的触发器停止, 删除大表索引。

2) 安装复制服务器。安装复制服务器比较简单, 只要将复制服务器的光盘放入服务器光驱, 运行其上SETUP.EXE文件, 再根据相应的提示完成安装步骤。

3) 配置复制服务器 (创建REP与RSM服务) 。配置复制服务器比较复杂, 先要配置复制服务器, 再配置数据主点和配置数据复制点, Sybase提供了一个应用程序来进行复制服务器的配置, 在windows系统, 以Sybase用户登录到服务器上, 运行install目录下的rs—init, 再根据相应的提示完成配置步骤。

武汉血液中心复制服务器的配置情况如下:

4) 添加主点及复制点数据库csbt添加到复制系统。根据图形化界面操作, 点击HIS_RSM弹出窗口, 在user name项输入sa, password项输入密码后就能进入主点、复制点配置窗口分另增加主点数据库、复制点数据库、复制服务器到RSM中。

5) 主点与复制点表的添加与预定。

a) 主点表发布。点HIS_REP下面HP下的csbt, 双击添加发布, 弹出一个新的窗口, 把要复制的表从左边选到右边, 定义该复制的名称pub1, pub2……pubn。

b) 复制点表预定。点HIS_REP下面HIS下的csbt, 双击添加预定, 选择pub1, pub2……pubn, 点完成即可。

6) 数据同步。

7) 用bcp命令将数据从主点数据库csbt导出, 然后再导入复制点数据库csbt中, 并重建索引。以正常模式重启复制服务器, 打开复制服务器与业务机和查询机的数据接口, 启动复制线程。用监控服务器RSM查看相关DSI和AGENT是否都已经UP[2], 否则检查复制错误, 一切正常后进行下一步操作。

8) 系统测试与日常巡检。1.测试数据是否同步, 利用应用程序在主点数据库csbt上操作一笔数据, 查看复制点数据库csbt中是否同样进行了修改, 若没有及时反应, 要根据复制日志的提示进行排错。2.测试复制点是否可以接管主点数据库服务。关闭主点, 修改客户端连接地址, 查看客户端是否能进入信息系统, 登记体检单并测试出库, 如果正常, 表明可以正常接管。3.每天检查复制器的复制代理、线程、队列是否正常, 每个月抽查复制点数据库表的内容、数量是否与主点一致, 发现问题及时处理。

六、结束语

目前对数据的备份手段很多, 硬件备份包括硬盘镜像、双机热备、盘柜、光盘刻录、磁带机。软件备份包括:bck全库备份、日志备份、bcp数据备份等等。但可用于建立经济、可靠、高性能、避免自然灾害的数据库备份产品, 当首推Sybase进行的数据复制, 它通过利用一个安全的远程更新模式, 远程节点能够实时地更新、插入、删除数据, 实时在异地同步复制数据。主点数据库发生故障时可以迅速切换至复制点数据库, 主点修复后可以再切回, 不影响业务的正常运行。复制点数据库也可以承担部分查询请求, 极大的提高了信息系统的性能, 有效的保证了业务不间断的运行。

参考文献

[1]中华人民共和国卫生部.血站质量管理规范[S].2006-04-25