《详解容灾架构中的数据容错恢复技术.docx》由会员分享，可在线阅读，更多相关《详解容灾架构中的数据容错恢复技术.docx（10页珍藏版）》请在第壹文秘上搜索。
1、1 .企业容灾可能面临的数据灾难场景之前在企业容灾选型指南-2:企业容灾的数据巨制技术文章当中，我们介绍了企业容灾建设过程当中经常会用到的远程数据基制技术，主要集中笔墨在其正需场合下的数据巨制原理和机制上.那么有正常场合就有异常场合，一个成熟的数据复制技术必须能处理异常场合下的数据损坏和丢失故障.本文我们探讨的异常场景，主要是因数据中心之间的通讯故障、主数据中心数据存储设备故障等引起的其中一个数据镜像不可用（数据损坏、复制中断、镜像失效等）的场呆.归纳为以下两个问题：异常发生期间，数据变化如何保存记录？异常恢复之后，镜像数据如何恢复到正常复制状态？围绕以上两个问题，我们接下来探讨从系统层面、数
2、据库层面以及存储层面用什么样的机制或者策略来保障以上问题的完美解决.2 .操作系统层面如何完成数据镜像恢复？2.1 基于逻辑卷管理器模式的数据复制技术如图所示，发生了一个镜像不可用的场景.首先，第一个问题”异常发生期间，数据变化如何保存记录？.逻辑卷管理器是可以通过参数控制逻辑卷的读写行为是否一定要双写（例如AIX参数：KeepQuorumCheckingOn=yesno）.如果我们设置双写控制参数为是，那么这个时候整个逻辑卷的写请求就会被挂起，逻娟卷被认为不可用，业务中断.如果我们设置宽松的双写控制参数,那么这个时候整个逻辑卷的写请求会等待PV2的ACK回算，如果超过系统默认Timeout时
3、间，那么认为PV2失效，将其标注为Disable,之后的写行为就不会顾及PV2的硝像豆制了业务无中断，但是之后的数据更新不会有任何辅助手段去记录。其次，第二个问题异常恢且之后，镜像数据如何恢豆到正常复制状态？当PV2所面临的异常环境恢豆之后，虽然PV2的硬件环境和设备都已经恢豆正常,但是逻辑卷的碗像PV2已经被标注为失效状态，因此不会有任何自愈行为.这个时候需要我们手动去做以下几步操作来恢豆数据镜像同步状态：命令方式手动拆除逻娼卷对应PV2的镜像.命令方式手动创建PV2物理卷设备，并加入卷组创建成为逻辑卷的新镜像.命令方式执行境像之间的数据同步.这一系列过程,第三步的原理是PV2会作为一个新的
4、设备存储空间，逐个读取原来PVl对应钱像里面的数据，然后以PP为单元进行基制同步，本身会很耗费时间和系统的读写性能2.2 基于ASM模式的数据复制技术如图所示，FaHUreGroup2对应的数据副本部分或者全部不可用的场景.首先，第一个问俄异常发生期间，数据变化如何保存记录？.OracleASM本身对于磁盘或者整个FailureGroup是否可用的判断，也是有参数可以控制的(例如Disk-RepaicTime,Failuregroupjepaijtime).如果超过参数设置的Timeout时间，那么认为磁盘或FailureGroup失效，格其标注为Unavailable,之后的写行为就不会再往
5、FailureGroup2写入了。但是这个时候它会有一个机制来保存后续短时间内的数据熠最变化.其次，第二个问题*异常恢聂之后，镜像数据如何恢安到正常基制状态？*当FailureGroup2所面临的异常环境恢复之后，ASM会通过设置的参数来判断是否可以自愈，如果不饶在参数所限条件下迸行自施，一样需要手动通过命令进行再同步的操作.1)小于等于参数disk_rep等Jtime(默认3.6H)时,认为是暂时性failure.会一直跟踪涉及failure磁盘extents修改，等该磁盘恢总后，函新同步将修改过的extents同步到failure磁盘.此过程无感知。2).大于disk.repair.tim
6、e.ASM会自动离线failure磁盘.需要人为使用命令剔除无效设备，并添加有效设备进入FailureGroup2,然后ASM会自动通过扫描豆制方式完成镜像的同步.2.3SJ于并行文件系统模式的数据良制技术如图所示，灾难发生后，经过仲裁之后，右侧数据中心的节点Node-2和FailureGroup2当中的所有磁盘对于集群都处于不可用状态.首先，第一个问题异常发生期间，数据变化如何保存记录?.GPFS本身不会通过自身的参数控制来判断磁盘是否不可用，它完全是依赖操作系统对IO状态判断的反馈来执行它的操作。如果GPFS的主节点Node-I通过ping判断负责failureGroup2的节点Node-
7、2是可用的,但是Node-2写入磁盘的10被操作系统判断为failed或者hung.GPFS会通过Recovery1.og来记录元数据和镜像数据的培量变化；如果GPFS的主节点Node-I发现负责FailureGroup2的节点Node-2失败了，那么集群会通过选举算法别除Node-2,并选择与Node-2同数据中心的其他节点来负责FailureGroup2的读写；如果节点和磁盘同时发生了故障（数据中心级别故障），那么GPFS集群会剔除失败节点，并且启用Recovery1.og来记录元数据及镜像数据的增量变化。其次，第二个问题异常恢豆之后，镜像数据如何恢豆到正常豆制状态？”当环境所面临的异常恢
8、复之后，需要通过命令将节点和NSD磁盘组加入到集群资源当中然后GPFS集群会通过自身算法至新分配节点和磁盘组资源的映射关系，然后迸行镜像数据的同步.同步的时候由于文件系统本身的结构特点所致，它是需要有文件系统的Meta数据和文件系统用户数据两部分,GPFS会通过元数据服务器上的Jornal1.og和Recovery1.og来同步数据镜像.3.数据库层如何完成数据副本恢复？首先，我们需要明确对于数据库层要讨论的数据再同步问题，一定是同步模式设置为近似同步或者是异步的这种模式，如果是绝对同步的模式那么一旦数据复制中断,读写也就挂起了。如图所示，如果是灾备中心数据库完全损殁的场景，只有重新配置Sta
9、ndbyDB,并且正新用备份数据为基点进行增最数据的追平.我们讨论的是由于网络问题或者其他问题导致的PrimaryDB无法访问到StandbyDB的场景。首先，第一个问题异常发生期间，数据变化如何保存记录？”.数据库层面的数据豆制本身就是日志的应用过程,当PrimaryDatabase的某些日志没有成功发送到StandbyDatabase,这时就发生了归档裂隙(ArchiveGap),缺失的这些日志就是裂隙(Gap).那么自然发生异常后的时间段内，数据培量变化都会在归档的Redo日志当中记录.其次，第二个问题异常恢旦之后，镜像数据如何恢宣到正常豆制状态？”当环境所面临的异常诙宸之后，需要通过命
10、令将节点和NSD磁盘组加入到集群资源当中Dataguard具备自动检测、解决归档裂隙的能力,-三StandbyDatabase被认定是failed,那么PrimaryDatabase就会强制进行一次日志切换，以明确的标识出Failed的时间点，也就是达到零数据丢失的时间点,而在这以后产生的red。日志就不再向Standby发送了.数据库的连通性异常一旦恢复，则所有的实例会自动去解决日志裂隙问题，接着PrimaryDatabase所有的实例会进行日志切换，以启动1.NS进程，继续发送Redo.这种模式只是尽星避免数据丢失，并不能绝对保证数据完全一致。这种模式要求StandbyDatabase必须
11、配置StandbyRedo1.og,而PrimaryDATABASE必须使用1.GWR、SYNUAFFIRM方式归档.除了自动的日志缺失解决,DBA也可以手工解决,这需要作如下操作： 确认StandbyDatabaSe上缺少的日志； 把这些日志从PrimaryDatabase拷贝到StandbyDatabase; 在StandbyDatabaSe使用命令手工注册这些日志。 执行日志应用恢巨.4.存储层如何完成数据副本恢复？4.1 基于存储网关镜像的数据豆制技术如图所示，以VP1.EX为例，灾难发生后，经过仲裁之后，右侧数据中心的引擎和存储卷处于不可用状态。自然虚拟分布式卷VirtualVolu
12、me的另外一个镜像就技苦为failed状态.其实它的恢复原理与操作系统镜像恢复的原理是一致的，无非就两种方法，一个是通过日志记录增量变化，待镜像状专恢豆之后重新同步培量的变化；另外一个就是从可用境像扫描全盘进行拷贝同步。首先，第一个问题“异常发生期间，数据变化如何保存记录？.这个问题其实各家不尽相同，有的存储厂商可以通过一定量的Jornal1.og来捕获存储卷上的Block变化，也有的存储厂商相对比较传统，没有这样的记录机制，要区别产品而言.就增量事务，一旦异常恢复可以首先通过Jornal1.og来进行恢豆,原理类似于OracleASM的Resync机制.但是也有一些存储厂商采取的是快照机制来
13、进行镜像拷贝豆制，虽然对原数据副本的读写性能不会造成太大影响，但也毕竟是全盘的扫描.就用过的VP1.EX产品的实践经验来看,从VP1.EXVirtuaIVoIume多种场景的同步时间周期来判断，它是具备Jornal1.og的机能的.4.2 基于存储介质块拷贝的数据豆制技术如图所示，基于存储设备本身实现的数据豆制技术与上层对象相关性非常少，仅依靠物理存储设备展实现数据的宜制，由于源端和目标端都是同品牌甚至同规格存储设备，那么底层存储BIoCk的豆制以及异常场景后的崩像恢且也会有很多种手段，毕竟自冢的设备自家的软件，实现的手段就更多.苜先，第一个问题“异常发生期间，数据变化如何保存记录？”.各家不
14、尽相同，但是也很少看见存储厂商真正原理性的东西出来，仅仅宣传可以有增量记录、快照记录等功能可以记录数据的变化.究竟是结果捕获模式还是事务行为记录模式还是要根据具体产品来说.如果有两个以上副本的情况，可以通过其他副本延续数据的豆制，当然中断点是必须有日志文件可以参考才可以.如果没有其他副本可以通过检查点之后的日志或者增量快照文件进行熠量同步.例如SRDF就是通过增量快照实现的。这里大家可能非甫容易看到一个问题，那就是为什么存储层的数据豆制技术很多都是采用快照技术来实现增量或者全量数据的同步恢系呢，而系统层钱像复制技术却很少呢？我个人觉得有两点：存储层与上层应用及数据联系基少，实现培量记录功能就算豆杂一些也不会影响业务.快照技术本身就是存储软件层比较得意的彷生功能模块，正所谓做自己擅长的事情.
