数据容灾架构中的数据复制技术.docx

数据容灾架构中数据复制技术
伴随全球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 Guard

3.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或者类似分布式文件系统软件。存放层面需要两套存放空间分别布署于两个站点作为主库存放和备库存放，他们相互之间独立。
3.2.2 复制原理
对于ASM和LVM模式来讲，都是将底层来自不一样站点两个物理存放卷作为镜像对组合成一个可用逻辑存放卷提供给上层应用来存放数据，当地物理卷和远程物理卷分别是由存放经过当地SAN环境以及跨数据中心SAN环境提供给服务器操作系统层。LVM是对操作系统PP写入进行实时双向复制，而ASM是对Oracle数据文件AU写入进行实时双向复制。当地写完而且远端写完才能算是一个完整写入，假设远端存放卷写入超时就会被标为故障或者是离线状态，当远端存放写入恢复之后，对于LVM来讲需要重新进行手动同时实现镜像副本完全一致。而对于ASM来讲，会有一个短时间内日志统计会帮助恢复离线镜像恢复数据，不过假如超出这个时间，一样需要一个全新同时来确保数据一致性。二者区分在于LVM逻辑卷与物理卷映射关系在创建逻辑卷时候就已经定义好了，所以对于坏块儿问题，LVM无法完成块儿指针动态转移。而ASM是在数据写入时才会分配详细AU，完全能够做到经过指针转移方式防止坏块儿造成数据写入失败问题。
对于GPFS模式来讲，它是经过将底层来自不一样站点两个物理存放卷归属到不一样Failure Group当中，然后由这些物理存放卷经过文件系统格式化形成份布式文件系统，提供给上层应用以文件形式写入数据。文件本身会被GPFS文件系统打散形成若干文件碎片，这些碎片在落盘时分别落入不一样Failure Group当中物理磁盘，从而确保底层数据双副本。这种模式与前两种模式最大区分在于它数据落盘是依照NSD磁盘定义服务实例次序来决定，正常情况下我们需要定义本站点服务节点为磁盘主服务节点，这么话两个镜像写入时候是靠GPFS位于不一样中心两个服务实例节点分别写入，两个服务实例之间也需要私有协议交互，相当于数据双写多了一个步骤。
3.2.3 关键原因
基于系统级逻辑卷镜像技术实现数据复制，相对于其余类型数据复制技术来讲风险性较高，主要表现为以下几个方面：
一、性能方面问题
对于LVM和GPFS方式来讲，对于数据库结构化数据复制性能会有较大损耗。因为数据库读写需要经过数据库本身存放映射以及操作系统层存放映射之后才能真正写入存放缓存。纵向路劲很长，性能损耗会比较大。而ASM本身是将数据库映射和系统级映射做到了一起，相对性能损耗会低很多。所以假如利用这类型数据复制技术话，数据库层存放块儿参数和操作系统层存放块儿参数设置要经过一系列优化。
二、容错性问题
假如我们用做当地存放高可用实现这种方式镜像，那么容错性就不会有问题。因为两个镜像副本链路指标能够认为是同质，镜像之前IO读写不会有差异。不过假如用在容灾场所下，因为两个镜像副本链路指标完全不一样，那么就要求系统层能对正常场所下、故障场所下以及故障恢复后场所下读写差异有很好容错性。比如说故障场所下IO超时反馈速度、故障恢复之后数据再同时问题。再有就是关于应用数据容错性，对于纯粹操作系统层面复制，完全无法防止应用逻辑错误。
三、负担过载问题
其实这种技术在设计之初并没有过多考虑过其在容灾中数据复制问题，设计初衷还是系统层存放卷虚拟化管理。所以其灵活性以及扩展性优于其在容灾数据复制中作用。假如非要把这类技术应用到容灾场所数据复制当中，那么操作系统层首先要完成应用功效载体作用，另外首先要完成当地存放卷虚拟化作用，还要一个重量级容灾数据复制作用。这种负担会直接影响到其承载数据库应用。
3.3 基于存放网关双写复制技术
所谓存放网关双写复制技术，就是在物理存放层之上增加一层网关技术用以实现存放底层虚拟化以及高可用镜像，而且由存放网关来控制镜像写入策略和模式。IBM、EMC、NETAPP等企业都有对应技术产品方案。基于写入原理及策略不一样，又各有区分。图3.3-1、图3.3-2、图3.3-3分别是IBM SVC Split Cluster、EMC Vplex Stretch Cluster、Netapp Metro Cluster。下面我们就其图示、从原理上分别进行分析和阐述。
图3.3-1 IBM SVC Split Cluster

图3.3-2 EMC Vplex Stretch Cluster

图3.3-3 NetaApp Metro Cluster

3.3.1 前提条件
容灾站点之间需要SAN环境联通，TCP/IP实现三层可达。两个站点分别要布署各自存放集群节点，共同组成存放网关集群。假设要实现双中心自动化仲裁及切换，那么第三个仲裁站点以及站点中承载仲裁软件计算及存放载体也是必须。
3.3.2 复制原理
对于Vplex Stretch Cluster来讲，首先两个存放网关节点是一对类似ORACLE RAC模式AA模式集群节点。如图3.3.2-2所表示，两个节点都能够接收来自上层应用读写请求。假设来A和B分别是来自底层存放两个物理卷，那么经过Vplex集群化之后，这两个物理卷被虚拟化集成为一个分布式共享卷C，对于C来讲，两边应用节点都能够看得到，都能够读写，它底层又是有A和B两个物理镜像组成。两个站点在写请求到来时，首先要完成当地A或B写入，然后需要把写入请求传送给另外一个VPLEX节点来完成镜像盘B或A写入。很显然，两边同时写入就有可能带来同一个数据块儿访问竞争，这个时候Vplex节点靠他们共同维护分布式一致性缓存目录来对竞争数据块儿进行加锁以及释放等协同操作，最终完成对数据块儿最终更新。当发生链路故障而造成一边节点无法写入时，那么节点会保留对应存放日志用以故障恢复之后数据同时。我们能够了解该同时模式类似于Oracle最大可用模式，正常情况下确保镜像数据写入同时完成，当故障时刻会有timeout时间阈值来决定是否暂时切断其中一个镜像写。
对于IBM SVC和NETAPP MCC架构来讲，它们一样在存放网关节点上实现对底层两个物理卷镜像绑定，不过这个卷并不是一个分布式共享卷模式，仅仅是一个实现了镜像绑定虚拟卷，对于卷读写只能以其中一侧节点为主，另外一侧节点为备。节点发生故障场所下实现节点主备切换，它比传统HA模式切换先进在哪里呢？它备节点是要从主节点上同时缓存，所以一旦切换发生，时间仅仅花费在虚拟卷Ownership转换上，缓存不需要重新读入，从切换时间上来讲要比传统HA快很多，从而保障了容灾RTO。
那么MCC和SVC区分在于什么地方呢？对于SVCSplit Cluster两个节点来讲，它们是两个控制器节点组成一个IO组，这个IO组意味着故障切换只能发生在这两个控制器节点之间，而且对于一个物理卷来讲只能归属于一个IO组，当这个IO组不可用时，那么这个卷也就无法读写了。对于MCC来讲，承载虚拟卷读写载体是SVM虚拟机，这个虚拟机是一个资源组合体，能够动态组合网络、存放以及存放操作系统等资源，所以它能在组成集群四个控制器节点上进行动态切换，理论上能够切换到任何一个控制器节点上，只不过其切换本身有一个故障优先级控制其切换次序。如图，SVM能够首先切换到A2节点上，当A2节点也发生故障时，能够切换到B1节点上，当B1节点也发生故障时能够切换到B2节点上。
3.3.3 关键原因
基于存放网关双写技术实现容灾数据复制，能够将数据容灾管理功效从应用及系统层剥离，从而对上层影响相对很小，而且容灾针对性设计保障其功效实现上会更优。不过其实施复杂度相对较高，而且对于以上不一样架构来讲，其所负担风险也是不一样，所以在这类技术应用上，我们需要尤其关注以下几个方面：
一、架构复杂性
不论是以上哪种存放网关复制技术，那么从硬件条件上来讲，存放这一层需要经过硬件节点组成一层统一存放集群。要想实现自动切换话，那需要仲裁站点参加。也就是说从存放这一层来讲，其实两个站点就是一个系统整体了，底层复杂性就很高了。假如数据库层、网络层以及应用层架构再稍微复杂一些话，那么整个容灾架构复杂度就会直线上升。
二、架构扩展性问题
在这种容灾架构下，其实存放层不但仅是作了一层虚拟化和集群化，更主要是作了一层存放集中化，存放网关成为存放统一出口。那么存放网关集群横向拉伸能力制约了整个存放系统可扩展能力。当我们业务出现快速膨胀场所下，存放网关集群最大扩展能力以及其本身纵向性能扩展性就会是一个关键性问题，我们必须考虑。
3.4 基于存放底层块儿复制技术
基于物理存放层之间软件复制技术是相对比较传统存放复制技术，应用时间也比较长。几乎每一个存放厂商都会有针对性处理方案。图3.4-1是基于存放软件复制技术基本原理图。
图3.4-1 存放层软件复制

3.4.1 前提条件
对于物理存放底层块儿复制技术来讲，对于环境要求主要是存放层要求。容灾站点之间需要SAN环境联通，两边存放通常要求型号一致而且配置有专门存放复制软件以及相关许可。
3.4.2 复制原理
其实对于存放存放底层块儿复制技术来讲，它跟上层应用层关系不大，主要是依靠存放层两个节点来完成源到目标复制。当上层应用将数据写入存放时候，那么由存放将这一IO请求再以块儿方式传输到另外一个存放上，从而确保留储设备在块儿级别上一致性副本。对于同时复制来讲，需要应用端IO请求等到存放层复制完成之后才会正常返回，对于异步复制来讲，应用IO请求跟底层复制没有任何关系，不需要等候复制结果。对于这种复制技术来讲，两个数据副本仅仅是数据内容相同，在上层没有任何逻辑捆绑或者是虚拟化，所以上层应用也是完全隔离两套应用，一旦存放发生故障，不论上层应用节点及网络节点是否可用都需要发生站点级切换实现业务连续性，存放本身不能隔离开应用发生切换。
3.4.3 关键原因
对于物理存放层面块儿复制技术，它剥离了对上层应用依赖，直接靠存放来完成数据复制。好地方在于它架构相对简单、相关影响面较小，不好地方在于它功效狭窄，功效仅仅在于数据拷贝，对于上层应用支撑面儿很窄。所以对于这种复制技术把握需要注意以下几个点：
一、容灾切换管理
对于容灾切换管理，我们需要决定好几个问题：
1.切换决议问题。假如故障集中在存放层面，而其余层面不受任何影响场所下，那么是不是一定要执行容灾切换？这需要一个完善决议体系来支撑各种场所下故障应对。
2.切换流程以及技术管理体系建设。因为这种数据复制技术对上层依赖耦合性非常低，那么单纯存放切换无法实现，这就需要从上到下一系列技术方法和管理流程来应对容灾切换。
3.回切流程及技术管理体系建设。一样当故障恢复之后，我们需要回切时候，这个过程即使是个计划内事件，不过可能相对比容灾切换更要复杂、更需要关注。
二、技术兼容性
基于存放底层块儿复制技术，其中最主要软件依赖就是存放复制软件，不过这个存放复制软件通常都是基于特定存放设备实现，具备厂家或者设备壁垒。当我们存放展现五花八样时候，那么这个关键复制软件可能也会展现五花八门。对于存放升级换代或者更换品牌等事件更是有很多限制。所以我们在应用这类技术时候要充分考虑到这一点。

4.数据复制技术对比分析
4.1 关键维度对比分析
4.1.1 投资成本对比分析
对于投资成本分析，我们不但仅要看建设成本更需要关注运维成本，不但仅需要关注设备成本更需要关注管理成本。本文首先将成本划分为几个部分，然后依照每一个部分成本按照定性分为高中低三个指标，最终得出综合分析如表4.1.1所表示：
表4.1.1-1 成本分析表

A = 基于数据库事务日志回放技术。
B.1 = 基于系统级逻辑卷镜像技术（数据库管理存放卷镜像）。
B.2 = 基于系统级逻辑卷镜像技术（系统层管理存放卷镜像）。
C.1 = 基于存放网关双写复制技术（Vplex模式）。
C.2 = 基于存放网关双写复制技术（SVC&MCC模式）。
D = 基于存放底层块儿复制技术。
对于以上成本分析，有几个需要说明地方。
对于网络成本，以太网三层可达我们认为成本属于低指标，对于二层可达或者是需要FC协议环境我们认为成本属于中指标，对于二层可达或者是FC环境，而且对带宽要求非常苛刻我们认为是高；对于设备成本，对于存放兼容性没有任何要求而且不需要购置硬件设备，我们认为属于低指标。对存放设备型号关于联性要求我们认为属于中指标，对需要购置网关设备我们认为是高指标；对于软件成本，假如有在数据库层、系统层以及存放层没有任何附带软件许可我们认为属于低指标，假如现有附带软件模块儿而且还有容量许可等我们认为属于高指标；对于运维管理，不需要数据库层面做特殊运维我们认为属于低指标，需要数据库维护属于中指标，需要存放高度支持而且需要数据库应用等熟练实施整套切换属于高指标；对于容灾管理来讲，能够实现自动化切换或半自动切换我们认为低指标，需要人工切换我们认为是中指标；需要组成专门容灾决议管理体系并实施教授级切换我们认为是高指标；对于风险管理成本完全取决于架构本身风险程度高低。
4.1.2 技术健壮性对比分析
单就数据库层面数据来讲，从复制有效性上来讲基于事务日志回放技术能够有效避开底层物理存放卷物理视图，就数据库逻辑层面组成很好逻辑视图，数据复制能够很好避开底层发生逻辑块儿错误等问题。而其余任何一项技术都无法防止存放块儿逻辑错误问题，因为它们在复制数据过程中跟上层应用没有任何校验过程，那么当存放块儿上发生配置性逻辑错误就会造成上层应用数据出现校验错误。
从技术专有属性上来讲，基于系统级逻辑卷镜像技术初衷在于数据当地保护，并不是基于容灾需求所生技术，所以在跨地域链路容错技术上要弱于其余专用容灾数据复制技术。
从数据传输复杂性上来讲，除了上述C.1属于双向同时技术，其余技术全部属于单向同时技术，双向同时技术稳定性和技术可靠性相对会低于单向同时技术。
4.1.3 技术风险对比分析
一、应用数据有效性风险
举一个极端案例，假设一个系统层面误操作把数据库卷元数据去除掉了，那么主库在下次要访问到这个卷上数据时候可能就要发生宕机。这个时候假如我们是基于事务回放技术做数据复制，那么这部分误操作就不会被复制到备库，备库数据依然可用。不过假如从操作系统层或者是存放层做数据复制，它是无法感知这一误操作无效性，所以逻辑错误依然会被复制到灾备中心，那么最终结果就是两个数据中心数据库都无法工作。
二、远程链路抖动风险
容灾必定会包括到远程链路，那么远程链路相对于当地链路来讲，抖动问题就是一个极难处理掉问题。既然不能处理这个问题，那么就应该看到一旦这个问题发生了，带给我们风险是什么：
首先我们来看事务日志回放技术，假设我们使用是近似同时模式，那么链路一旦发生抖动，直接影响就是日志同时会伴随发生不间断超时，主库缓存里日志条目无法及时同时到备库。当链路恢复稳定之后，归档日志和在线日志分别发起同时请求将主备库数据追为同时，这期间主库不受任何影响。
接着我们来看系统级镜像技术，远程链路抖动造成远程镜像写入失败，当然这个失败会有一个从底层存放、光纤链路以及操作系统等多层超时传递效应，每一层都会有自己超时策略，反应到数据库层之后，这就是一个不小应用等候。当链路恢复稳定之后，会有一系列镜像同时过程，这个镜像同时过程需要对主镜像进行扫描分析，会有很高性能消耗。
然后我们再来看存放网关双写技术，链路抖动一旦超出仲裁阀值就会引发存放网关集群仲裁，这个仲裁结果不确定，有可能会发生切换而且会频繁切换，一旦发生切换不但仅要面对两边数据主备同时模式频繁改变，而且还会晤对上层应用在面临链路抖动情况下跨数据中心频繁访问，相当于将不稳定问题又向上转嫁了一层。这么复杂问题组合到一起，风险性相对较高。
最终我们再看物理存放层块儿复制技术，其实他和事务日志回放技术面临风险几乎相当，影响仅仅是远程数据副本继续同时，当地存放写入不受任何影响。链路稳定后，一样面临存放层底层数据追平问题，当然这个策略和模式依照不一样厂商设计原理会有优劣之分，这里就不再详细讨论。
三、容灾切换技术复杂度风险
探讨这个问题前提条件是抛开一切其余类似链路抖动之类问题，仅仅探讨当发生站点级故障而且短时间无法恢复故障时刻，不一样数据复制技术带给我们整个容灾切换复杂度。基于存放网关双写技术基本上会有一套完善存放层切换机制，依靠仲裁站点能够实现自动化切换，只要双中心之间SAN环境相通，数据库应用层自然也是无缝切换。基于应用事务日志回放技术就完全要靠人工来实现数据库切换以及应用访问切换了，需要依靠数据库教授来判断主备库状态以及详细切换策略。这个不但仅是技术上风险而且是管理决议上风险。基于系统级镜像技术切换需要依靠操作系统层共享卷组或者共享文件系统或者是ORACLE集群来完成切换，属于自动化或者半自动化切换。而基于物理存放块儿复制技术切换则是一系列冷切换，数据库是一个全新数据库重新初始化，只不过底层存放卷上数据是主站点上副本而已。
四、性能上风险
对于性能上风险主要是指数据复制过程本身消耗存放资源以及计算资源性能对业务上性能影响怎样。我们希望是数据复制过程本身对主业务没有任何性能影响，不过因为这二者高度关联性，尤其是同时模式或者近似同时模式场所。对此我们能够描述为下表（近似同时模式）：
表4.1.3-1 性能影响程度及范围

A = 基于数据库事务日志回放技术。
B.1 = 基于系统级逻辑卷镜像技术（ASM模式）。
B.2 = 基于系统级逻辑卷镜像技术（LVM模式）。
B.2 = 基于系统级逻辑卷镜像技术（GPFS模式）。
C.1 = 基于存放网关双写复制技术（Vplex模式）。
C.2 = 基于存放网关双写复制技术（SVC&MCC模式）。
D = 基于存放底层块儿复制技术。
4.1.4 功效扩展性对比分析
这一项对比分析在于我们应用数据复制技术对于应用层以及整个架构扩展性和灵活性影响程度，容灾架构当然主要，不过对于真个基础架构来讲，容灾指标是其中很主要衡量指标之一，我们还有对架构扩展性、灵活性以及性能评定等多个方面。所以容灾架构设计不能制约其余指标发展。详细对比分析参考表4.1.4-1。
表4.1.4-1 功效扩展性对比分析汇总表

5.总结及展望
本文对企业容灾过程当中包括到各种数据复制技术进行深入调研分析，而且依照其实现技术原理进行剖析，从原理底层来分析其在实际容灾应用过程中技术优势和面临风险劣势，同时依照企业容灾应用过程中所面临详细需求来对比分析几类复制技术差异，意在为同行选型及实施提供技术参考。同时也希望有更多同业基于此提出更优化更科学思绪和想法。