ITPUB论坛-中国最专业的IT技术社区

 找回密码
 注册
查看: 32445|回复: 1

[转载] 主题:1.9.6 从数据块结构看目前主流容灾技术 发表时间:2011-12-20 14:05:30

[复制链接]
论坛徽章:
394
阿斯顿马丁
日期:2014-01-03 13:53:522014年世界杯参赛球队:喀麦隆
日期:2014-07-11 12:10:53马上有对象
日期:2014-04-09 16:19:542014年世界杯参赛球队: 洪都拉斯
日期:2014-06-25 08:25:55itpub13周年纪念徽章
日期:2014-09-28 10:55:55itpub13周年纪念徽章
日期:2014-10-01 15:27:22itpub13周年纪念徽章
日期:2014-10-09 12:04:18马上有钱
日期:2014-10-14 21:37:37马上有钱
日期:2015-01-22 00:39:13喜羊羊
日期:2015-02-20 22:26:07
发表于 2012-3-24 19:45 | 显示全部楼层 |阅读模式
主题:1.9.6 从数据块结构看目前主流容灾技术 发表时间:2011-12-20 14:05:30  

作者:白鳝  离线 回复:9   浏览:654


1.9.6 从数据块结构看目前主流容灾技术
谈到容灾平台,很多DBA总是觉得离自己好远。容灾系统也许真的看不到启用的那一天了。记得有一次和几个朋友在四川意外碰到,一起喝酒。朋友中有一位是以前在某省邮储搞容灾的,就说起现在的容灾平台,真正能启用的恐怕不到一半。我那个哥们表示不信,他觉得当年他们搞容灾系统的时候是很认真的,而且有专人管理,定期演练,是必须确保能够立马切换的。也许我碰到的客户都不是金融行业的,容灾建设比较马虎。

正说着这个事情,我接到一个客户的电话,这个客户是金融行业的,他们接到上级部门的通知,要搞容灾演练。在切容灾系统的时候,发现容灾系统的一套10g的Oracle 数据库启动不起来了。

后来这个问题解决了,其实也很简单,他们容灾环境是采用IBM的SVC复制的,不过只复制了数据库相关的文件,操作系统的系统目录中的文件并未同步,其中的host文件的配置是错误的,所以数据库起不来了。虽然问题不大,但是也暴露出一个问题,就是容灾平台疏于管理,当主生产环境变更的时候,没能及时变更容灾环境。在这些年的工作中,老白亲自经历过三次容灾切换,其中两次成功,一次失败。成功的两次是切换到本地容灾系统,失败的一次是切换到远程容灾系统。

先说说成功的那两次吧,当时客户的系统为了添加RAC第三节点,由于存储容量不足,无法满足第三届点UNDO表空间和归档目录的需求,决定扩充一个扩展柜,16块硬盘。由于集成商经验不足,新扩的盘柜和磁盘的微码和原系统不兼容,因此扩容工作很不顺利。原定于周五晚上添加RAC节点,周四必须完成磁盘扩容工作,但是从周三开始的盘阵扩容搞了一天半还是毫无进展。于是IBM的800介入了这个工作,经过诊断建议现场插拔一下磁盘,这个工作反复做了几次,突然磁盘整个锁死,系统无法正常工作了。而这个时候正好是下午的5点多,正是系统最高峰的时段。

当时我和客户的技术主管讨论了一下,决定马上切换到容灾系统。当时这套系统有两套容灾系统,本地容灾是采用DATAGUARD技术的,远程容灾是采用类似DATAGUARD的技术,将归档日志压缩后传输到远程进行注册和应用。远程容灾系统在离故障点100多公里以外的一个城市,配备了两台IBM P561服务器,而本地的容灾系统的建设目的并不是为了容灾,而是为了减轻备份对生产系统的负载而利用剩余设备搭建的一个备份平台,因此这台服务器是一台IBM P561,服务器仅配备了48G内存。这个配置和生产环境两台配备72G内存的P570系统相比,处理能力明显不足。按照常理,这样的情况下,切换到异地容灾系统是比较合理的。但是经过仔细分析,切换到异地容灾系统的条件并不具备,因为仅仅主生产系统在异地建立了容灾系统,十多个外围系统并未建立异地容灾系统。一旦主生产系统切换,那么需要更改上千个配置项,才能够完成全业务的切换。而这项工作并无现成的预案和操作脚本。仅凭人工操作,很难保证系统正常切换。另外还有一个更大的问题,在远程容灾机房中,仅配备了几个低级的系统管理人员,并未配备专职DBA等维���人员,一旦需要切换,大家只能在远程操作系统,很难确保切换过程中不出问题。

而如果切换到本地容灾系统,只需要将DATAGUARD服务器的IP改为生产环境的IP,然后激活DATAGUARD,就可以完成了,维护人员也可以在本地操作。不过最大的问题是本地的硬件配置明显不足以支撑生产环境50%的业务。于是我建议将生产环境上的内存拔一部分插到容灾系统的服务器上。这个主意似乎很不错,不过拔下内存一看,由于生产环境上是P570,而本地容灾是P561,大部分从P570上拔下的内存条并不能在P561上使用。于是又在备件库房凑了凑,才凑了42G内存,将容灾服务器的内存扩充到了90G。重启容灾服务器的过程中,又碰到了网卡不能自动激活的问题,总之经过一系列的折腾,终于在1个半小时后,恢复了系统的运行。虽然本次切换最终成功了,不过由于业务高峰期系统停止了近100分钟,导致了大量业务积压,并影响了货物通关,最终导致了惊人的损失。

在本次事故中,投入大量资金的异地容灾系统并未能发挥应有的作用,反而是不在规划中的,DBA的无心之作解救了这次危机。这个案例也暴露出了我们容灾平台建设中存在的问题。这个问题其实是普遍存在的。

第二个案例差不多是10年前的事情了,这个客户采用的容灾技术和第一个案例不同,是采用存储级复制技术的,容灾平台配备了70%的处理能力。那次老白正好在客户现场帮客户的另外一套系统做优化。当时由于生产系统的存储突然掉电,大量的数据文件损坏了。当时用户还很淡定,因为他们投入巨资建设了先进的容灾系统。而且这套容灾系统在几个月前还做过切换演练。不过容灾系统启动的时候,他突然发现其中的一台数据库服务器起不来了,从错误信息上看,报了ORA-704和ORA-600 错误。那个DBA折腾了个把钟头还是没办法解决问题,突然想到这边还有一个做优化的DBA,于是就请我帮他解决这个问题。现在看来,那个问题并不难,主要是UNDO表空间存在坏块导致数据库无法正常启动,通过_offline_rollback_segments和_allow_resetlogs_corruption参数,再辅以BBED,强制打开数据库就有可能解决问题。不过那时候老白的技术还比较潮,整整折腾了一天还是无法解决这个问题。由于客户建设了容灾系统,就没有再建设备份系统,因此这个系统没有可用的备份集。最终老白只能祭出dul这个法宝,导出了数据并重建了整个数据库。虽然数据最终大多数被恢复了,不过整个业务中断了5天。

和十年前不同,现在的容灾系统建设已经成为一种主流,一般来说核心的业务系统都会建设容灾平台。不过和十年前类似的是,现在的IT部门的决策者还是不了解容灾技术的本质。因此在选择容灾平台的策略上,还是存在很多误区。如果不能真正从原理上理解容灾技术的本质,那么就难保上面容灾切换不成功的悲剧不再重演。

目前的主流容灾技术包括下面几种:

l 存储同步复制技术

l 存储异步复制技术(包括各种类型的存储复制,包括卷复制)

l Oracle dataguard

l 逻辑复制技术(比如STREAMS,GOLDENGATE,DSG等)

l 应用级数据复制技术

存储同步复制技术也就是平常所说的镜像(MIRROR)技术,一个写IO必须在本地和容灾上同时完成写操作才能够算这个操作完成。任何一个写错误将导致整个写IO失败。这是一种十分严格的同步机制,因此能够确保容灾平台的数据随时都是可用的。这项技术是十分成熟的,甚至Oracle 提供了一个解决方案RAC on Extended Distance Clusters,就是一套远程的RAC系统,两个节点不共享一个磁盘阵列,而是共享两个互为镜像的磁盘阵列,每个读写都会发送到两个磁盘阵列上。一旦某个地方出现故障,那么另外一个地方的系统还可以独立工作。这是一种兼顾RAC高可用和异地容灾的解决方案。虽然目前在国内还缺乏成功案例,但是其技术成熟度还是得到验证的。不过采用镜像技术的系统,一旦某个存储出现故障,必须尽快隔离,否则就会影响系统的运行,因为一个IO必须同时成功才能够完成。

存储异步复制技术目前在容灾系统上应用的十分广泛,这种方式既提供了维护较为简单的高效的容灾复制,又避免了备用存储故障导致生产系统无法正常工作的问题。不过如果仔细研究一下这种容灾技术的本质,我们还是会发现其中潜在的风险的。为什么老白会碰到这样的案例呢?这个问题在10年前老白还是十分困惑的,不过随着对Oracle 内部结构的认识,特别是数据块结构的认识,老白终于明白了,导致当年那个问题的最根本的原因就是“块断裂”。块断裂产生的根源是Oracle 的数据块和操作系统的块大小是不一致的。一般的UNIX系统,磁盘块的大小是512字节,而Oracle 的数据块大小是8K。也就是说一个Oracle 数据块包含了N个磁盘块。虽然Oracle 数据块的定义上来看,Oracle的数据块分配的磁盘空间是连续的,不过由于底层存储条带技术,不能确保一个Oracle 数据块在磁盘上是连续分布的。甚至有可能一个Oracle 数���块存储在多个磁盘上。由于Oracle 数据块和操作系统磁盘块之间的不同,就产生了一种可能性,一个Oracle 数据块被操作系统分成多个IO写盘了,这些IO之间的时间点是不同的。因此,在某个瞬间,远程容灾系统上数据中可能包含了一个数据块的某个部分的变更,但是缺少了其他一部分的变更。这就导致这个数据块中的各个组成部分是不一致的,通过block head和block tail的比较和checksum的比较,就能发现数据块处于不一致状态。遇到这种情况,Oracle表现出来就是读到了坏块,这也就是我们常说的块断裂现象。这也是我们用存储异步复制技术做的容灾系统,在数据库打开后经常会发现坏块一样。如果这个坏块正好出现在UNDO表空,或者出现在一些关键的系统数据字典表中,那么这个数据库阵子打开的时候就可能会有问题了。

对于一般的系统,块断裂发生的几率并不是太高,但是对于数据变更十分频繁的7×24系统来说,这个机会大得多。之所以那个客户做容灾演练的时候没有发生问题,主要是因为一般客户做容灾演练的时候往往会停掉业务,这样数据库处于想对静态,出现问题的机会很小,而实际生产系统故障需要切换时往往又是业务高峰,出现块断裂的机会几乎是100%。

既然存储容灾的方式容易出现块断裂,那么存储复制容灾是不是就没有用武之地了呢?这种情况也不能一概而论。随着存储复制容灾技术的发展,现在的技术又有了新的发展。为了提高存储容灾系统启用时的可用性,可以在每天业务不是很高的时候,对主要表空间设置BEGIN BACKUP状态,然后做一个快照,再END BACKUP。一旦激活容灾系统时出现了ORA-704或者ORA-600这样的错误,可以从那个时间点通过归档日志RECOVER DATABASE恢复数据,从而获得一个可用的数据库。

Oracle DATAGUARD是以种很适合本地容灾的解决方案,由于DATAGUARD是基于Oracle 数据块的复制技术,因此Dataguard不会存在块断裂的方式。因此很适合做作为本地容灾系统使用。DATAGUARD的缺点是如果采用LGWR同步模式,一旦DATAGUARD出现故障,将导致生产库也无法使用。而使用LGWR异步模式或者ARCH传输模式,一旦主库故障,丢失的数据量可能会多于存储复制技术。

除了上述几种常见的数据库容灾技术外,近年来,出现了以Oracle  GoldenGate、DSG、Oracle Streams为代表的逻辑复制解决方案。这些解决方案基本上都是基于对Oracle 日志进行挖掘,将逻辑变化记录捕获后传输到目标端,转换为SQL语句,应用到目标数据库,从而实现数据同步。目前已经有很多用户使用这些产品建立了自己的容灾平台。不过这种基于逻辑复制的技术存在一个很大的缺点,就是无法有效控制数据复制的延时。这些复制技术,对于大事务的控制都存在一定的缺陷。比如生产环境做了一个UPDATE操作,修改了2000完条记录,这个操作在生产环境可能10分钟就完成了。而在目标端,这个UPDATE操作就变成了2000万个独立的UPDATE语句,执行完成这些UPDATE操作,可能需要1个小时,甚至更长的时间,这样就会造成复制的延迟。如果这个时候生产系统出现故障,那么恢复业务可能需要较长的时间。甚至出现一些更为严重的问题,比如说GOLDENGATE,其捕获进程在某个事务没有提交的时候不会捕获数据,只有当事务提交时才会捕获,如果某个事务执行的时间比较长,那么捕获进程会等待该事务提交,那么捕获进程会产生较大的延时,如果这时候系统出现故障,那么就会有大量的数据没有来得及捕获,这些数据可能会彻底丢失了。

针对大事务,GOLDENGATE做了一定的优化,比如说对于INSERT操作,GOLDENGATE会自动合并类似的语句,采用BULK INSERT的方式处理,这种方式已经被证明是十分有效的,对于批量插入操作的复制效果十分好。不过对于UPDATE和DELETE操作,这种处理并没有实现。而我们的系统是复杂多变的,实际环境总不是以我们个人的意愿而改变。

我想,只有我们了解了主要复制技术的实现的初步原理,我们才能在设计自己的容灾平台的时候采用正确的方案。

逻辑复制技术对于数据量不大,很少有大事务的系统是有效的,不过如果你要把逻辑复制用于容灾,还需要加强对系统运行状况的监控。通过心跳表监控的方式及时发现延迟变大的问题。在一个逻辑复制环境中,目标系统出现性能问题,或者目标系统中某个不合理的查询都有可能让你的复制延时变得很大(甚至老白以前还碰到过由于目标环境中没有及时做表分析而导致复制进程采用了错误的执行计划,导致复制延时变大的问题)。另外一点是在一个逻辑复制环境中,尽可能让目标服务器的性能不要太差,从而引起复制延时。

DATAGUARD适合于本地容灾,对于一些数据变化比较大的系统,传输大量的归档日志需要很高的网络带宽。

存储级别数据复制技术由于传输的仅仅是存储数据的变化,因此传输的数据量小于DATAGUARD,因此很适合在广域网上进行数据复制。这种复制模式很适合用于异地容灾平台。

对于不同的应用,不同的SLA,选择合适的容灾技术十分关键。在本地建立DATAGUARD本地容灾系统,远程使用基于存储复制技术的远程容灾系统,也许是个不错的选择。


本文链接:http://www.oraclefans.cn/blog/showblog.jsp?rootid=39193
  
       网友评论
─ 评论人 无为而为    11-12-21 16:51  
  dsg 接触过点,好像其对于大量dml操作 并非在commit后才抓捕的,不过还是同步延时的。 不过我觉得灾备除了灾备数据 还包括应用 中间件 网络等等。最近看了emc的vplex在复旦大学的演示,其结合vmware做的跨数据中心 虚拟机在线切换还是蛮不错的,存储上底层就是2个数据中心的mirror了。用powerpath命令可以看到有vplex的虚拟链路连到另一个数据中心。 也许未来双同步中心是灾备的另一种定义了
  
─ 评论人 白鳝    11-12-21 16:54  
  我见到的一些正在用VMWARE的系统,IO性能都很差。不知道什么原因。虚拟存储技术的确值得期待
  
─ 评论人 无为而为    11-12-21 17:04  
  的确啊 IO绝对是vmware的阿克琉斯之踵啊 ,不过在上面做应用服务器应该还是不错的,配置什么都不用改。
  
─ 评论人 ghy1215    12-03-19 22:48  
  感谢大师,goldengate的确在处理大事务上存在问题,每次去客户那儿都祈祷生产系统oltp

  
─ 评论人 ghy1215    12-03-19 22:50  
  emc的vplex技术还是挺牛的,配合RAC实现真正意义上的双活同步业务系统
  
─ 评论人 白鳝    12-03-21 17:09  
  你说的是external rac?有实际的应用案例吗?关于这个技术的实际应用我目前还没看到。如果有,那真的可以认真研究下
  
─ 评论人 ghy1215    12-03-22 15:36  
  我向emc原厂工程师了解过,应该不是external rac,是rac的共享存储到备端存储间的同步双活。以前如果用emc存储同步备端的db是打不开的,现在如果用vplex的话,备端db可以open,实现goldengate的功能吧

  
─ 评论人 ghy1215    12-03-22 15:39  
  目前有一些客户在测试,具体生成环境中不知道有没有成功案例

  
─ 评论人 白鳝    12-03-22 19:57  
  这个可能性不大,存储厂商存在忽悠的成分。纯粹的存储复制方案肯定达不到100%可打开。

论坛徽章:
480
榜眼
日期:2015-09-09 10:34:21秀才
日期:2015-11-23 10:03:12秀才
日期:2015-11-23 10:03:12秀才
日期:2015-11-23 10:03:12秀才
日期:2015-11-23 10:03:12秀才
日期:2015-11-23 10:03:12秀才
日期:2015-11-23 10:03:12秀才
日期:2015-11-23 10:03:12状元
日期:2015-11-23 10:04:09举人
日期:2015-11-23 10:04:09
发表于 2012-3-26 23:08 | 显示全部楼层
白鳝总是能把高深的话题讲得引人入胜。

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则

TOP技术积分榜 社区积分榜 徽章 电子杂志 团队 统计 虎吧 老博客 知识索引树 读书频道 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档 | IT博客
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛 | SAP ERP系统
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 网站律师 隐私政策 知识产权声明
京ICP备16024965号 北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表