数据复制系统

2024-07-10

数据复制系统（精选十篇）

数据复制系统篇1

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

数据复制系统篇2

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

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

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

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

数据库容灾复制的5个建议篇3

1.选择合适复制软件。选型时主要关注两个方面：一是数据库系统运行平台，因为有些复制软件只支持某种操作系统；二是考虑业务数据库类型是单一的Oracle数据库间复制，还是有SQL Server、Oracle、DB2之间的复制。目前，主要的复制软件包括Quest shareplex、Oracle Glodengate和国内的DDS、迪思杰等，在具体选择软件时要综合考虑软件功能、维护简便性、产品价格等。

2.复制目的要明确。数据库复制主要是把生产业务数据库复制到本地或异地的备用数据库。复制的目的如果只是数据级备份容灾或报表分离，在项目实施时，主要考虑生产数据是否及时、完整复制到备用数据库即可；如果数据库复制是应用级容灾，还要考虑外围系统的建设，如主机系统、网络系统、中间层业务系统、负载均衡等设备和软件的建设配置管理。

3.确保复制软件功能完备。重点注意几个方面：一是软件容错机制是否完善，如网络发生中断再连通后复制软件如何操作；二是软件是否支持DDL操作复制，是否支持RAC或多节点的数据库环境以及可支持的数据类型等。

4.复制软件维护管理应简便。软件实施一定要安装简单、快速，尤其是第一次数据复制初始化操作。另外，项目实施完毕，对复制系统进行日常维护更为重要，是否有完善的监控，实时监测数据复制过程都需要考虑。

5.要有操作规范可借鉴。成熟的复制软件都积累了大量的实施、维护经验，有一套完善、详尽的操作规范和流程。在项目实施、日常维护、切换演练等过程中，根据这些现存的流程规范，可减少人为操作风险，提高用户维护和管理水平。

数据复制系统篇4

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

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

个人所得税申报数据复制方法篇5

纳税人2011年10月份申报期申报9月1日以后取得的个人所得时必须采用最新版本的个人所得税模版填写数据上传。为了避免繁琐的数据录入，下面分三步介绍如何将旧模板中“普通纳税人基本信息表”内容复制到新的模板：

第一步下载模板

请先登录远程申报网站下载最新个人所得税申报模板。

第二步复制数据

将原有个人所得税申报模板打开并将需要复制的内容全部选中，点击鼠标右键，选择“复制”。

第三步粘贴数据

打开新下载的个人所得税申报模板，选择相对应的项目单击鼠标右键，选择“选择性粘贴”

在出现的窗口中选中“数值”，即摈弃格式只粘贴内容。

如果您在粘贴时没有按上述方法操作，也许会破坏此模板的文件格式，导致某些有列表的项目丢失下拉列表，或出现格式错误，如果出现此情况，您可以把此行删除重新填写或者重新到网站下载“个人所得税申报模板”

数据复制系统篇6

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

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} \sum_{i} \frac{[L_{n} - \bar{L}]}{\bar{L}}$ (2)

其中 $\bar{L} = \frac{1}{n} \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。

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

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

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.

数据复制系统篇7

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

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

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

数据同步复制实践篇8

银行业信息系统承载着我国金融机构核心业务和金融服务, 其中一个环节出现问题, 都可能引发多米诺骨牌式的传递效应, 导致系统性金融信息安全风险。灾备体系是保障银行业金融机构业务连续性的重要防线, 是维护银行业信息和网络安全的重要措施。虽然近年来, 我国银行业金融机构陆续建立了灾难备份体系和灾备中心, 但仍存在许多不足。

为规范银行容灾备份和灾备中心的建设, 人民银行在2005年提出要求:各银行数据灾难备份标准应至少达到2~3级, 在完成数据集中后的2年内灾难备份标准必须达到5~6级。依据GB/T 20988-2007《信息安全技术信息系统灾难恢复规范》中目标恢复时间 (RTO) /目标恢复点 (RPO) 与灾难恢复能力等级的关系, 5级系统要求RTO在数分钟到2天, RPO在0至30分钟;六级系统要求RTO为数分钟, RPO为0。提高灾备等级重点是减少RPO与RTO。从5级系统的要求来看, 目前大多数的灾备中心的切换均能满足RTO的要求, 因此, 本文将探讨如何通过数据复制技术减少RPO以提高灾备等级。

一、常见容灾技术综述

近年来, 容灾已经成为数据中心建设的热门课题。目前容灾技术多样, 分类也比较复杂, 总体上可以分为离线容灾 (冷容灾) 和在线容灾 (热容灾) 两种类型。

离线容灾主要依靠备份技术来实现, 主要有两种方式:一种是将数据通过备份系统备份到磁带再将磁带运送到灾备中心保存管理, 另一种是将数据先备份到本地磁盘再通过网络传输到灾备中心存储。离线式容灾具有实时性低、可备份多个副本、备份范围广、投资较少等特点。由于备份方式是压缩后存放到磁带 (磁盘) , 所以数据恢复较慢, 而且备份窗口内的数据都会丢失, 因此离线容灾一般用于数据恢复的RTO和RPO要求较低的容灾。也有很多客户将离线式容灾和在线容灾结合起来增加系统容灾的完整性和安全性。目前主流的备份软件主要有:Symantec Veritas Net Backup, EMC Legato Net Worker, IBM Tivoli Storage Manager, Quest Bak Bone Net Vault。

在线容灾要求生产中心和灾备中心同时工作, 生产中心和灾备中心之间由传输线路连接。数据自生产中心实时复制传送到灾备中心, 因此实现在线容灾的关键是数据的复制。和数据备份相比, 数据复制技术具有实时性高、数据丢失少或零丢失、容灾恢复快、投资较高等特点。根据数据复制的层次, 数据复制技术的实现可以分为3种:存储系统层数据复制、操作系统数据复制和数据库数据复制。

(一) 存储系统层数据复制

基于存储的复制一般都是采用ATM或光纤通道作为远端的链路连接, 不仅可以做到异步复制, 还可以做到同步复制, 使两端数据实时同步, 保证了数据的一致性。缺点是存储设备是由存储硬件厂商提供的, 在兼容性方面有局限性。用户要使用同一厂商的设备, 选择面太小, 成本高, 并且对线路带宽的要求也较高。

存储系统层的数据复制基于同构的存储, 各个存储厂商都有自己的复制软件, 如IBM PPRC, EMC SRDF, HP Continues Access, HDS True Copy等。

近年来, 随着存储技术的不断发展, 存储系统层次技术上还出现基于网络的存储虚拟化设备来实现数据复制。这种方式的特点是依靠外加的网络层设备来实现两个存储设备之间的数据复制, 数据复制过程不占用主机资源, 两个存储之间的数据同步在网络层完成。CDP技术就是虚拟化容灾方式所衍生出来的一种实时系统备份技术, 是一种容灾和备份的合成技术。

(二) 操作系统数据复制

操作系统数据复制主要通过操作系统数据卷管理器来实现数据远程复制。这种复制技术要求本地系统和远端系统主机同构, 其实现方式是基于主机的数据复制, 容灾方式工作在主机卷管理器层, 通过磁盘卷镜像复制, 实现数据容灾。这种方式也不需要在两边采用同样的存储设备, 具有较大的灵活性, 但是复制功能会占用一些主机的CPU资源, 对主机的性能有一定的影响。

目前基于原厂的逻辑卷管理软件如IBM AIX LVM, HP-UINX Mirror Disk, Sun Solaris SVM等可以实现在本厂平台上的逻辑卷镜像;专业的数据复制软件包括Symantec VERITAS Storage Foundation等, 提供了更大的灵活性, 支持多个平台的逻辑卷镜像。

(三) 数据库数据复制

数据库数据复制技术通常采用日志复制功能, 依靠本地和远程主机间的日志归档与传递来实现两端的数据一致。这种复制技术对系统的依赖性小, 有很好的兼容性。缺点是本地复制软件向远端复制的是日志文件, 这需要远端应用程序重新执行和应用才能生产可用的备份数据。

目前基于数据库的复制技术主要有:O r a cle Data Guard, Oracle Golden Gate, DSG Real Sync, Quest Share Plex, IStream DDS等。

二、基于存储的数据复制原理

基于存储的数据复制不依赖主机系统、文件系统、数据库系统。工作机制是利用存储系统控制器的控制台来启动、监控、控制远程数据备份的操作。优点是能节省主机系统的CPU资源, 提供用户高可用性的开放服务。

(一) 同步复制

基于存储的数据同步复制技术为用户的任何数据提供了实时的、同步的远程镜像保护功能, 远端的拷贝数据与本地的拷贝数据或生产数据保持一致, 远端拷贝永远是本地数据盘的镜像, 具体流程如图1所示。

备份磁盘系统在更新时总是与生产同步, 在不需要主机干预的情况下, 生产磁盘与备份磁盘同步进行相同的I/O更新。磁盘系统保持完全一致的顺序 (一个I/O就发送一次) , 以保证数据和连续更新的完整性。当生产中心发生灾难时, 就不会出现数据丢失的情况。由于备份数据总是最新的, 应用程序就能够在最短的时间内重新启动。

由于需要等待远程写入数据的完成, 同步方式有性能上的缺陷, 系统和应用程序的性能因此受到一些影响。受应用系统I/O读写的活动频率、网络带宽、可以容忍的交易响应时间和其他因素的影响, 远程同步工作方式有距离的限制, 一般小于25千米。

(二) 异步复制

基于存储的数据异步复制以异步方式实现可靠的、经济的、可实施的容灾解决方案, 解决由于远程同步镜像方式给生产应用系统性能造成的巨大冲击和系统的压力, 以及异地长距离的场地部署问题, 具体流程如图2所示。

在异步方式下, 生产系统所发出的I/O操作至本地存储系统, 本地存储系统处理结束后立即通知主机本次I/O结束。然后, 本地生产存储系统将多个累计的I/O异步 (几乎实时发送) 且不一定按顺序传送到备份中心的存储系统中。

由于I/O操作不是同步地传送到备份中心, 存在数据的传送顺序与实际的数据的操作顺序不一致问题。为了解决这一问题, 容灾软件对每个写入生产中心存储系统的I/O都打上一个时间戳 (Time Stamp) 并进行一致性分组 (Consistency Group) , 在数据传输至备份中心时, 备份中心存储系统严格按照此时间戳的时间顺序重新排列并写入相应的逻辑卷中, 同一个一致性组内的I/O将被同时写入或者同时放弃, 从而保证备份数据逻辑的一致性与完整性。

由于数据异步远程更新, 应用程序不必等待远程更新的完成, 因此远程数据备份的性能影响通常较小, 并且备份磁盘的距离和生产磁盘间的距离理论上没有限制。只有在当传送中的数据在生产磁盘控制器或在TCA中还没有形成数据一致组时生产中心发生灾难, 这些“in-flight”的数据才会丢失。但True Copy通过Consistency Group技术保证灾难发生时已经发送到备份中心的数据将保持一致性, 因此在系统和应用程序重新启动之前, 需要恢复那些“in-flight”丢失的数据。所花费的时间和造成的影响取决于客户的环境, 例如应用程序和设备配置的复杂性、更新的完整性等。

三、基于存储的数据同步复制实践

为提高灾备等级, 各大商业银行都进行了数据复制保护, 多数采用了基于存储的数据复制技术, 其中光大银行、民生银行等用了惠普的CA技术, 中行、农行、工行、建行等使用了日立的True Copy技术。考虑到人行主要集中存储, 品牌一致性比较高, 人行选择了True Copy数据远程容灾解决方案。

为降低实施复杂度, 作为数据复制的一个探索性实践, 我们选择了灾备等级要求较高但数据量相对较小的货金系统进行了数据复制探索。该系统原来每天晚上由生产中心自动进行数据备份并将备份通过网络传输到同城灾备中心, 然后在灾备中心将备份恢复成为可用环境。其RTO<2小时, RPO为1天, 灾备等级为3级, 不满足人行对重要系统的灾备等级为5级的要求。我们使用True Copy同步复制技术, 实时将生产系统存储与灾备系统存储进行数据同步, 如图3所示。

我们将生产中心的HDS存储与同城灾备中心的HDS存储通过数据复制专用的光纤交换机 (博科5320) 连通 (由于距离大于25千米, 使用了华为DWDM设备) 。使用CCI服务器给HDS存储下发True Copy数据同步复制命令, 实施后货金系统所有写到生产集中存储的写I/O都将被同步写到灾备存储, 并且当灾备存储回复写入完成后才会返回。

由于NAS的数据放在了集中存储上, 因此也具备了实现NAS数据同步复制的条件。原有的创先科NAS并不能够很好地支持True Copy同步复制技术, 因此, 我们将货金系统的NAS迁移到了一台日立NAS上, 通过存储层的同步复制实现了对NAS数据的实时保护。

四、实施经验总结

(一) 方案设计要切合实际

每个单位的物理部署和网络都不大一样, 每个系统的情况和特点也可能不同, 因此在方案设计过程中, 对于重要参数应该搭建测试系统充分测试, 在获取实验数据的基础上合理选择。

1. 合理建设数据复制链路

一是应根据实际情况选择数据同步或者异步技术, 如果距离长应购买光纤交换机厂商的长距离级联许可, 如果超过20千米应考虑选择DWDM等连接设备;二是数据复制链路数据传输速率由光纤交换机、存储、长距离连接设备 (DWDM等) 中速度最低的设备决定, 采购设备时应注意短板效应;三是建议采用单独的光纤交换设备, 将数据复制链路与生产环境数据链路隔离, 避免压力情况下影响生产环境。

2. 合理设置True Copy相关参数

True Copy相关参数包括数据保护级别、同时复制的磁盘数量、通道轮询和通道失效时间等, 应根据测试情况及性能要求合理设置。我们采取了NEVER的数据保护级别, 当链路出现问题导致写操作失败时 (如出现问题一般会出现通道响应超时, 如果所有通道均不可用, 系统判定为链路故障) , 存储将自动停止True Copy, 避免DATA模式下数据复制链路出现异常导致数据库停顿, 用户端无法写入的情况。通道失效时间用于判断链路故障, 时间设置得越大, 故障发生时生产端的用户体验就越差, 时间设置得越小, 可能平时一点小抖动就可能造成True Copy被终止, 应根据具体性能要求及网络条件合理设置。复制的磁盘数量也是一个重要参数, 其值越大, 对灾备环境的性能要求越高, 应根据具体灾备端存储性能和网络条件综合考虑。

3. 适当设计冗余

实施方案一般都采取冗余设计, 确保任何一个单点故障都不会影响整个系统的独立运行。在我们的实施方案中, 数据复制链路由联通线路和歌华线路实现双路冗余, 确保其中一个运营商的线路发生故障时, 还能够使用另一个运营商的线路而不影响数据复制。但是依据邮储银行的经验, True Copy的数据复制链路如果同时使用不同运营商线路可能会对同步复制产生一定的影响。生产端操作系统层的写入操作在生产存储层将被分成多个I/O, 通过不同的线路到达灾备端存储, 由于一致性组的概念, 必须等到所有的I/O都到达后才能一次写入, 因此, 可能部分线路速度偏慢, 导致整体I/O速度慢, 从而影响生产端主机响应速度会进而影响用户体验。另外, DWDM线路本身就有工作路径和保护路径, 线路质量可靠性比较高, 因此其考虑的是每一个数据复制应用只使用一条运营商线路。具体实施过程中应根据测试结果选择适合本单位的冗余设计。

4. 一致性分组合理

将磁盘分为多少个一致性分组也是个很重要的问题, 可以根据应用来分, 也可以根据逻辑卷组 (VG) 来分。一般来说, 分组数量越多 (同一组内磁盘少) , 可能导致有的数据不可用、一致性相对较差的情况。比方说如果将数据库的索引和数据的磁盘分成不同的组, 则可能出现数据库数据写进去了, 但是索引没有写进去, 导致数据索引不可用。分组数量越少 (将更多的磁盘放到一个一致性组) , 会带来RPO上的损失, 因为发生故障后, 可能会丢掉一大堆的I/O。实施过程中应依据实际业务情况选择合适的分组。

(二) 切实防范实施风险

实施过程中最大的风险是方向的正确性, 数据复制的方向一定要从生产端到灾备端, 如果方向弄反了, 将冲垮生产环境的存储, 导致系统不可用。一般情况下, 都是在生产环境部可用时, 发生生产环境切换, 从生产切换到灾备。因此, 虽然存储技术提供了双向复制选择, 可以来去自如, 但现实情况下没有必要建立从灾备到生产环境的数据复制通道。在切换发生后, 如果生产和灾备中心的地位改变了, 再建立从灾备到生产的复制通道即可。此外, 应在实施前做好应急预案, 将生产端存储备份, 做好万一生产端存储遭受毁灭性毁坏也能恢复的准备。

(三) 实施前充分考虑运维风险

采取数据同步复制, 对生产系统有较大影响, 特别是当线路出现抖动或者光纤虚接等情况时, 可能造成生产端存储I/O堆积, 进一步引发数据库端进程堆积, 轻则导致用户响应延迟, 严重时可能导致生产环境数据库重启等后果。因此, 应探索建立一体化运维机制, 实现监控预警与自动化处理。

1. 建立监控预警机制

通过对相应指标的监控, 对超过阈值的指标 (存储的Cache Write Pending、光纤交换机enc out值) 和异常的复制状态 (非PAIR状态) 进行预警, 使管理员在问题发生时能够及时介入处理。

在实施过程中我们对光纤交换机enc out值和True Copy的异常的复制状态进行了监控, enc out值超过一定阈值或者True Copy状态为非PAIR状态时, 将通过短信报警平台给管理员发送告警信息。

2. 实现复制关系自动断开

在云中复制和恢复数据篇9

梭子鱼网络存储业务经理Guy Suter表示:“只有很少的备份产品能够提供云存储, 并实现在云中恢复VMware备份。其它产品通常需要为云中的每个客户提供专门或专用的存储。Barracuda Backup的Cloud live Boot功能解决了这个问题, 提供了一个简单的方式让VMware源在云中运行, 并且无需配制即可从重复数据删除的存储中启动服务器。”

Barracuda Backup为混合的物理与虚拟服务器环境提供了完整的端到端业务解决方案。Barracuda Live Boot for VMware让虚拟机能够从Barmacuda Backup服务器的重要数据删除备份存储中直接启动, 从而使业务快速恢复运转。通过Barracuda Backup 5.2版, 客户可以把Baracuda Live Boot for VMware扩展至采用梭子鱼虚拟化基础设施的云。除了恢复并降低总体停机时间, Barracuda Cloud Live Boot for VMware提供的平台能够实现备份的验证、精细的恢复以及在生产环境之外测试应用程序。ESG高级分析师Jason Buffington表示:“现代虚拟化保护解决方案中一个真正不同之处在于能够从保护存储中快速让虚拟机上线, 而不是首先把数据恢复到最初的虚拟化主机。各种规模的客户都在寻求基于云的灾难恢复功能, 以远程保护和恢复虚拟机。整合云灾难恢复架构的即时恢复能力为寻求更敏捷地恢复的客户带来了很多可能性。”

Suter先生还表示:“包含Cloud Live Boot的Barracuda Backup 5.2版让客户从已在做的事情中获得更高价值, 例如:在云中复制和恢复数据。云中的Barracuda Backup Live Boot可以通过恢复并远程激活浏览器中的网络界面访问, 在几分钟内投入运行。

BarracudaBackup 5.2版客户将继续享受Barracuda Backup中相同的可能:

多样化的恢复与可用性选择-Barracuda Backup拥有一个直观的恢复浏览器, 让管理员能够恢复整台服务器 (物理或虚拟) 、从单个通过备份中有选择性质地恢复文件夹和单个文件, 或恢复至复制云并与其它复制用户分享数据。

弹性恢复资源—BarracudaBackup与客户的VMware环境集成, 提供灵活的计算资源用于恢复的服务器。Barracuda Backup为有保障的数据存储和检索设定了行业标准, 同时尽可能降低了数据存储成本和管理负担。

关于梭子鱼网络

数据复制系统篇10

1 批量复制的基本方法

SQLBulk Copy包含一个实例方法Write To Server,用来从数据源到目标传输数据,其操作的数据对象包括Data Row[]数组、Data Table及Data Reader。基于此,开发者可以选择选择自己擅长的数据容器,其中Data Reader是最常用的,因为Data Reader是单向的、只读的数据流,其中的数据帧是不断流动的,比其他方法更快一些。

从.NET Framework 2.0开始,在命名空间System.Data.SqlClient中包含一个类。SQLBulk Copy,批量复制操作包含两个步骤:

第一步,获得数据源。数据源可以是各种大小数据库,如Access、Excel、SQL Server、Oracle等。将数据源绑定在Data Table中,或者任何Data Reader类,实现IData Reader。

第二步,连接目标SQL数据库,执行批量复制。.Net提供的批量复制功能,能够快速复制大量数据到SQL Server。其中的原因是大量采用了SQL Server的存取机制。一行一行地插入数据,是一个非常消耗时间和系统资源操作。但是,批量复制机制能够实现一次复制大量数据,数据插入变得非常快。

下面利用SQLConnection String Builder与数据源建立连接。

然后利用Sql Command和Sql Data Reader类,从数据源中获得数据。

数据暂存在rdr变量中,下面实现初始化Sql Bulk Copy对象,并复制数据。

The Sql Bulk Copy类需要与目标数据库SQL Server建立连接。

最后,关闭所有连接,关闭SQLData Reader和SQLBulkCopy对象。

sbc.Close();

rdr.Close();

cnn.Close();

2 测试批量插入耗时的代码