随着全球IT产业的飞速发展，金融行业的IT建设逐步成为主导金融企业业务发展的核心驱动力，基于金融行业IT系统容灾建设的各种行业标准以及监管标准也相应提高。

而决定容灾架构健壮与否的最关键因素就是数据复制技术，它是实现高标准RTO和RPO的前提条件。

本文基于业界主流数据复制技术的原理、复杂度、关键因素以及复制效果等多个维度进行分析及论述，旨在为同业在此类项目规划和建设过程中提供一些启示和帮助。

1.背景及综述在金融行业内，众所周知其对业务连续性的要求以及对各种IT风险的应对能力的要求都是非常高，尤其是对容灾能力的要求，这是由它的业务特殊性以及集中式架构所决定的。

在金融企业容灾架构中，所谓的数据复制技术主要是指能够将结构化数据进行复制，从而保证数据具备双副本或者多副本的技术。

目前业界发展来看，可以实现数据复制的技术多种多样，有基于数据库层面的数据复制技术，例如Oracle公司的Active Data Gurad、IBM公司的db2 HADR等；有基于系统层面的数据复制技术，例如赛门铁克的vxvm、传统的逻辑卷管理（LVM）、Oracle公司的自动存储管理（ASM）冗余技术、IBM公司的GPFS 等；有基于存储虚拟化实现的数据复制技术，例如EMC公司Vplex Stretch Cluster、IBM公司SVC Split Cluster、NetAPP公司Metro Cluster等；也有基于存储底层实现的数据复制技术，例如IBM公司的DS8000 PPRC技术、EMC公司的SRDF技术、HP公司的CA技术等等。

每一种技术都有其实现的前提条件，也有各自的技术特点和实现的不同效果。

本文将从复制技术的原理、特点、复杂程度以及复制效果等多方面展开分析及论述，并从多个维度进行对比分析，将业界主流数据复制技术的发展现状以及技术优劣给予一个清晰的展示，并就数据复制技术发展的未来以及趋势予以展望。

2.数据复制技术价值分析2.1 数据复制在容灾中的必要性一、RPO保障如果没有数据复制技术，那么容灾也就无从谈起。

当面临站点及故障时，由于没有数据复制技术的支撑，我们的数据无法在其他站点再现，这将意味着RPO将无法保障。

对于一个金融企业来讲，最重要的就是客户的数据，它是企业的生命。

从这个意义上来讲，金融企业不能没有容灾体系，容灾体系的前提条件是能够实现数据复制。

那么数据复制的效率如何，复制的效果如何，复制技术的先进与否也就决定了金融企业生命线的稳固与否。

二、RTO保障所谓RTO就是在容灾系统在面临站点级故障时，多长时间能够恢复业务。

假设站点故障恢复的时间不可容忍或者根本没有可能，那么业务必须能够切到另外一个数据中心，从数据、应用以及网络层都需要具备这个切换能力。

但是最终的目的就是要保障业务能正常恢复，而业务恢复的前提条件就是数据，没有数据的应用切换和网络切换没有任何意义。

也就是说数据恢复是应用切换以及网络切换的前提条件，从这个意义上讲，数据复制效率和效果直接决定了一些列切换，也就是它使得RTO成为可能。

2.2 评价数据复制技术的维度分析对于数据复制来讲，我们可以从多个层面、多种技术去实现。

各有各的特点，那么究竟哪一种数据复制技术更适合我们？活着说哪一种复制技术更科学合理？这需要一系列从不同纬度进行的科学评估。

本文认为应该从以下几个方面来展开分析，并结合我们自己的需求来选择合理的数据复制方案。

一、投资成本分析建设任何一个项目，投资成本的分析都是必不可少的分析维度。

对数据复制技术的投资成本分析来讲，我们需要从它的首次建设成本、持续维护成本以及容灾管理成本等多方面去考虑。

二、技术成熟度及健壮性分析对于数据复制技术的成熟度和健壮性分析来讲，一方面我们要从技术本身的原理上来分析，另外我们还需要从技术的发展以及应用范围以及应用的持久稳定性等方面来考虑。

三、风险评估分析数据复制技术本身来讲是要帮助我们解决站点级故障带给我们的IT风险，但是对于技术应用本身来讲，它也会存在一些技术风险。

比如说特殊场合下的一些技术风险、容灾管理过程中的一些风险、极端场合下的一些技术风险等等。

四、功能拓展性分析对于数据复制技术本身来讲，其主要功能就是完成数据的复制。

但是在完成数据复制的同时，由于其架构的特点以及技术特点等因素有可能对于我们的应用产生积极的拓展性作用，也有可能限制了我们的应用架构模式，还有可能对我们的基础架构扩展性以及灵活性造成一定的限制。

3.数据复制技术原理分析3.1 基于应用事务日志回放技术图3.1是Oracle数据库层面的数据复制技术（ADG）的架构原理图。

对于该架构原理图，本文从其实现的基本条件、数据复制原理、数据复制的模式以及数据复制的关键因素等几个方面来进行深度剖析。

图3.1-1 Oracle Active Data Guard3.1.1前提条件容灾站点之间需要有三层以太网连通，软件层面需要数据库的集群软件模块（Oracle Active Data Gurard）或者是db2 purscale hadr。

服务器层面需要至少两套服务器系统分别部署于两个数据中心。

存储层面需要两套存储空间分别部署于两个站点作为主库存储和备库存储，他们互相之间独立。

3.1.2复制原理对于主站点的数据库来讲，客户端的数据更新请求首先要由日志写入进程写到重做日志当中，然后由数据写进程再周期性地写入数据文件当中。

重做日志当中以SCN为数据库独有的时间搓序列来记录所有数据库更新的先后顺序，从而保障数据库恢复能够按照正确的顺序执行保障数据一致性和完整性。

那么对于配置了Active Data Guard的数据库读写的完成在以上所述过程中，日志写进程在本地日志文件写入过程的同时，日志传输进程会将缓存里面的重做日志通过ADG传输给灾备站点的备库实例，备库实例的日志接收进程根据接受到的重做日志在备库上重新执行数据库的更新操作，从而保证主库和备库的事务性更新行为一致性，最终保证数据的一致。

当然也有一个前提条件，那就是在ADG作用之前，必须保证备库的数据保持与主库的某一固定时间点的完整副本，这需要靠传统数据备份技术来实现备库的初始数据复制。

因为事务复制的本质是行为复制，那么行为作用的初始数据副本必须保持一致，才能保证最终两副本的一致性。

对于事务日志的复制技术，本文根据主库IO周期特点可以分为绝对同步模式、近似同步模式和异步模式三种。

绝对同步模式是指主库的一个完整更新事务的结束既要包括主库的重做日志落盘也要包括备库的重做日志落盘，也就是说备库重做日志落盘之后返回给主库，主库才能执行下一个事务。

近似同步模式是指在传输正常情况下保持与绝对同步模式一样的模式，在网络传输超时的情况下，就会剥离备库重做日志的过程，只要保证主库重做日志落盘就可以了。

异步模式是指主库只保证本地重做日志落盘，并不会等待备库重做日志落盘的返回信号。

在后两种模式下，当主备库传输管理剥离之后，主库会主动通过以下两种方式探测并尝试重新和备库建立联系，第一是归档日志进程会周期性ping备库，成功情况下，它会根据获得的备库控制文件的记录的最后归档点和自己的归档日志决定向备库推送哪些归档日志。

第二是日志发送进程会在重做日志准备发生归档的时刻点主动去ping备库日志接受进程并把剩余的重做条目发送给备库接受进程。

3.1.3关键因素基于事务日志回放技术的数据复制架构，从技术规划上以及运维管理层面上有几个关键因素需要把握才能将这种数据复制技术运用自如，才能帮我们真正实现高标准的容灾体系建设。

一、重做日志管理策略设计我们知道对于数据库来讲，我们是靠其在线重做日志和离线重做日志来进行数据恢复的。

对于离线重做日志也就是归档日志，我们是需要周期性备份并删除的，否则离线重做日志就会无限占用数据库有限的存储资源。

那么对于事务日志型数据复制架构来讲，无论是主库还是备库，都需要有合理的日志管理策略来配合才能正常运行。

策略的规划和设计需要把握以下几个原则：1．完成应用的日志要及时转储，包括主库传输完毕的归档日志和备库应用完毕的归档日志。

2．没有完成应用的日志必须能够保留，主库没有传输到备库的归档日志如果被提前转储会造成备库数据丢失，备库没有被应用的日志如果转储，备库同样会丢失数据。

3．存储资源的科学规划，如果主备库暂时中断，又因为原则2导致归档日志堆积，那么势必造成存储资源的需求超过正常时刻的存储需求量，如果存储资源不够，又会造成数据库发生宕机事故。

以上各个原则的科学设计既需要依赖于数据库参数的合理设置，又需要依赖于备份工具的转储策略合理配合，同时更需要根据不同的业务系统以及负载特点，通过历史数据评估以及仿真测试数据来设计合理的数值并进行动态评估和优化。

二、架构扩展性及灵活性在今天的互联网线上时代，系统架构的扩展性和灵活性显得尤为重要。

对于容灾架构来讲，它的扩展性和灵活性同样非常重要。

对于业务型的数据复制架构来讲，它有两种基本架构：级联架构和串联架构。

级联架构是指一点为主多点为备，串联架构是指主备模式依次类推。

级联架构更有利于主库的多点保障，串联架构更有利于主库的性能保障。

具体采用什么样的架构组合，是要根据主库数据的具体业务需求进行合理评估和设计。

三、容灾切换管理主备库的切换，包括两种类型的切换：Fail Over & Switch Over。

Fail Over是指故障情况下的强制切换，Switch Over是指计划性的切换。

无论是哪种切换首先是要保障备库数据和主库数据一致或者可容忍范围内的近似一致。

其次当数据发生切换时，实际上主库的服务IP地址就会转化成备库的服务地址，无论是通过域名转换还是通过应用重连的方式都需要保障上层的服务地址能够无缝切换。

最后切换之后，原来的主库如果没有时间戳恢复功能的话，那么原主库里面的数据就会变成无效数据，需要重新初始化数据副本。

但是如果保持时间戳恢复功能的化，就会巨大的存储空间消耗。

3.2 基于系统级逻辑卷镜像技术下面三张图都是基于系统级逻辑卷镜像技术实现的数据双重复制。

图3.2-1是基于ORACLE自动存储卷管理技术实现的ASM磁盘卷镜像复制技术；图3.2-2是基于UNIX存储卷管理（LVM）实现的逻辑卷镜像技术；图3.2-3是基于IBM GPFS分布式文件系统底层逻辑磁盘镜像实现的数据复制。

三种技术虽然依赖的具体技术不同，但是其底层原理都是基于系统层面的双写实现的数据复制。

图3.2-1 ORACLE ASM复制镜像架构图3.2-2 LVM镜像复制架构图3.2-3分布式文件系统GPFS镜像复制架构3.2.1 前提条件容灾站点之间需要SAN环境联通。

软件层面，架构一需要具备ORACLE集群软件当中的自动存储卷管理模块，架构二需要借助UNIX操作系统层的逻辑卷管理器，架构三需要借助GPFS或者类似的分布式文件系统软件。