灾备故障上了红头文件,容灾技术到底哪家强?

dbaplus 2015-10-24 15:01:00


昨天上午,中国银监会下发的关于“数据库文件损坏风险提示”的文件图片在朋友圈和大部分IT微信群里刷屏了。这是继2014年7月1日宁夏银行核心系统数据库出现故障,导致该行(含异地分支机构)存取款、转账支付、借记卡、网上银行、ATM和POS业务全部中断之后,又一家城市商业银行爆出的灾备故障,数据库容灾问题一时被推到了风口浪尖。
事件回放

 

根据《中国银监会办公厅关于数据库文件损坏风险提示的通知》中描述:2015年5月8日,某城市商业银行核心系统使用的甲骨文数据库系统发生故障,数据库自动存储管理(ASM)头文件异常损坏,由于该行配置数据备份缺失,在此情况下,数据库无法加载存储磁盘组,数据服务中断。此外,该行同城灾备中心采用了存储级同步复制技术,数据库损坏文件被复制到灾备系统,导致灾备系统的数据库也存在同样问题,无法正常启用,造成该行柜面和渠道业务较长时间的中断。
 
据提示,该行数据库服务器为IBM P7-780;操作系统版本为IBM AIX 6100-07-05-1228(64位);数据库版本为甲骨文Oracle 11.2.0.3.4(64位),采用双节点实时应用集群(RAC)架构;存储设备型号为IBM DS8800,固件版本为86.20.111.0;同城灾备中心采用IBM Metro Mirror存储级数据复制技术。
 

 

专家经验谈

 
 

王晓征(浙江移动信息技术部副总经理):一、现在黑O记是一种时髦;二、任何数据库容灾技术都有优缺点,底层复制对此次逻辑损坏确实无能为力,但这个方式也绝非一无是处。与时俱进,找到适合自己的方式就是王道;三、从人性角度,没出事的时候技术部门要花钱搞灾备总是很容易被卡,然后出了事之后估计又往往只有技术部门出来顶包,这也是普遍规律,醉一下。

 

吴东昕(15年IT系统资深架构师):嘿嘿,非要用存储复制,非要体验这种会故障传递的风险,放着DG或者别的数据库类似的方案例如HADR不用,这下歇菜了吧。再提醒一下那些搞所谓双活extend RAC或者GDPC的,小心双死。

 

 

老李:实际案例,存储复制关键时候切换不了。以下是Oracle科技部信息规划的博士做的总结:

 

 

复制方式

容灾切换实际情况

Exadata(数据类应用,如CRM、绩效、报表、反洗钱、征信等)

ADG/OGG

1分钟内完成切换

传统Oracle IOE架构(包括信贷、财务、二代支付等)

ADG

1分钟内完成切换

DB2(包括网银、中间业务系统)

存储复制

切换存在问题

 

容灾方法

技术实现

方法描述

宽带要求

成本

基于存储复制

SAN存储复制

通过SAN进行存储之间的数据拷贝

极高

存储虚拟化

利用虚拟技术提供存储数据的服务(镜像/快照/迁移/NAS/远程复制/写入保护)

卷管理复制

通过卷管理器的快照功能实现数据同步

极高

数据库级复制

基于数据库日志的物理复制

通过把数据库的日志传送到远程数据库,借助数据库的恢复机制将数据恢复出来。如:Oracle的Active Data Guard的日志传送功能

逻辑方法

通过第三方数据库复制应用软件来实现。如:Oracle的GoldenGate等

较低

 


 

老耿的工具箱:peony,gdul,osync.:硬件灾备可能无法应对逻辑损坏的状况,但有人说有些存储级也可以回复到某个时间点,不知道真的假的。【babyblue:存储级可以通过快照来实现。】我也是听说的,如果是可以闪回到任何时间点,那也是可用的。

 


 

洪烨:hadr基于日志传输复制,目前可以做到三备库,免费。花钱的话可以考虑cdc。【杨建荣_北京:我知道很多海外的电信都是使用bcv的这种方式,不过自从有了11g的adg以后,还是比较方便,很多都在大规模采用。】【Marvelyu:银联的容灾是什么技术架构组建?灾备没用HADR吧?是存储级别复制吗?】存储+应用,银联的业务类型很简单,全都是交易流水,不涉及账务,银联数据SharePlex。灾备没用HADR,是存储级别复制。

 


 

Lei:客户准备实施cdp(连续数据保护),我准备下狠手给否定了。大体是这样的,rac中用两个存储,主存储和cdp的旁路镜像存储,asm diskgroup使用normal冗余。主存储上的lun构成一个fg,cdp的旁路镜像存储构成一个fg。【乘风破浪:cdp的稳定性很让人担心。】【lastwinner:现在用cdp的基本都是大白鼠。】

 


 

清泉石:以前更多考虑的是在线实时备份,主要应对操作性故障、硬件故障,很少考虑这种故障。只能寄希望于完整备份和不完整恢复了。

 


 

谁动了我的琴弦:应该定期做备份恢复测试。

 


 

Lunar:换adg就屏蔽db下面一层的灾备问题,再结合flashback,有条件做个实时,再做个延迟,基本各类物理损坏都扛过去了。至少上面那个存储复制如果换成Oracle的ADG,解决上面说的存储复制没问题。我说的是更全面的设计,容灾的RPO、RTO要结合预算和需求。【Joseph:ADG不如本地CDP,我见过两家客户做的dg都不稳定,偶尔会发生问题,需要全库重新同步。ADG好处是只要同步过去的必然事物一致。】【babyblue:嗯,ADG切换过程中我们这没少出过lost write的问题。】【清泉石:我的理解是CDP与数据库无关,它是基于操作系统的文件行备份,并不关心文件的内容和属性。】这个adg哪里不行啊?adg需要啥维护?CDP依赖于db,然后还能超越db本身的功能?adg是物理的,跟事物完全没关系。【Joseph:CDP怎么会依赖于db呢,他是底层块级别的。】要启动,需要check db的一致性吧?【Joseph:你就算是物理standby,也是log apply啊。】CDP怎么check?adg是物理的redo apply。【Joseph:精确到微秒…可以指定没有io的时间点。】【清泉石:主要问题是在于如果被攻击,可能会渗透进数据库内部破坏数据文件或者控制文件。这样的话,任何实时同步都没用。】【Joseph:redo不算事物?log记录的在我看来都算。】当然不是,都是block直接apply。在玩Oracle的人看都知道redo apply是block的apply。类似存储复制的存储block apply,只不过adg是数据库自己的block,大家不一个层次。【Joseph:block的apply就不算事务了……对于Oracle来说依然是他内部的事务。当然lunar说的ADG也有很大好处,比如有些平台和应用场景CDP做不了,ADG就可以应对几乎所有的场景。价值方面来说,不好判断,你说故障了,然后备份就立功了,你之前花的多少个十万八万的,根本就没差别。没事的时候,都是放在那,连花瓶都不如。】

 


 

情系天下:存储级别复制不知道备库能不能打开,这是个未知数。

 


 

陈渊:不同容灾软件或方法,都只能处理部分问题,不可能解决所有问题。

 


 

杨志洪:银行其实搞容灾搞得非常早,基本上到目前为止,主要搞的还是存储级容灾。上面其实有朋友说了,存储级Oracle数据库的灾备,有一个很大的风险点,就是灾备端数据库是offline的,真要起来的时候,很可能打不开。另外就是银监会通报的这种情况,源端的物理错误,目标端无法判断,只会照样的复制。【扣扣:所以很少有看到真实的切换救灾的,绝大多数,只要供电在、设备在、人在,都是在本地完成修复和救灾。】这中间有很多因素,不单纯是技术问题。【情系天下:灾备端的数据完整性不好验证。】【扣扣:所以存储产品都希望用快照来解决问题。可是,要保证快照的可用性,就必须让存储与应用能够通信,也就是说,要拍照前,存储会通过安装在主机上的通信agent,通知数据库,转为热备或其他暂停IO的动作。这个动作最大缺点就是对数据库的影响,不可能频繁去做。对未知且无保障的事情,没人愿意冒风险去做,所以存储复制的问题就是扩大性和传染性。如果只是一台数据库出了问题,是只切换一台?还是全部切过去?切换就意味着要上报领导主管层级,一般技术部门是无权做决策的。】【番薯藤:我的感觉,要做灾备就必须做到存储和逻辑复制两种方式才有可靠性。】【扣扣:正解!灾备方案难就难在全面性,因为永远无法预知未来可能发生的灾难类型,所以不能有死角。】【樊双贵:至于怎么实现,可以细化,同时也建议灾备系统上部分生产任务或只读任务。】在电信运营商,用DG/ADG方式来做容灾和应急的已经比较多了。一方面当然要做好切换演练;另一方面,备库可以分担一部分报表业务压力。

 


 

反思
为何灾备系统成摆设
 

 

灾备,由于是一种保险性质的东西,因此常常不被企业所重视。许多企业的领导都会认为,天知道灾难什么时候会掉下来呢?这几千万甚至上亿的灾备成本何苦要去花?

 

尽管有些领导懂得灾备的重要性,或者是由于行业的硬性要求而做了灾备,但到底有没有效果往往是没有持续验证的。对于系统越复杂的企业来说,做灾备演练的难度也就越大。

 

有的企业就算做了验证,但是验证的角度不够广,只是采用固定的套路。因此灾备演练发现不了死角,没有起到应有的效果。

 

综上种种,都造成了灾备系统变成摆设的局面。

 

灾备系统建设到底应该怎么建?针对此问题,DBA+社群将会进行后续解析和分享,敬请持续关注我们的微信公众号:dbaplus。

 

鸣 谢

在“DBA+社群”热议话题讨论活动中,得到了以下联合发起人以及群友们的积极参与和支持。在此,小编整理成文,并附上所有发表观点的人员头像汇总图(排名不分先后),特此鸣谢!

 
 

 

 

“DBA+社群”根据业内热点话题及DBA所遇疑难杂症,即时在各大城市群进行【热议话题】讨论,欢迎大家积极加入我们,各抒己见。想了解我们的小伙伴们可关注微信公众号:dbaplus

 

 


 

扫码关注

DBAplus社群

来自各领域的牛逼DBA正在向我们汇聚

最新评论
访客 2023年08月20日

230721

访客 2023年08月16日

1、导入Mongo Monitor监控工具表结构(mongo_monitor…

访客 2023年08月04日

上面提到: 在问题描述的架构图中我们可以看到,Click…

访客 2023年07月19日

PMM不香吗?

访客 2023年06月20日

如今看都很棒

活动预告