昨天上午，中国银监会下发的关于“数据库文件损坏风险提示”的文件图片在朋友圈和大部分IT微信群里刷屏了。这是继2014年7月1日宁夏银行核心系统数据库出现故障，导致该行（含异地分支机构）存取款、转账支付、借记卡、网上银行、ATM和POS业务全部中断之后，又一家城市商业银行爆出的灾备故障，数据库容灾问题一时被推到了风口浪尖。
专家经验谈
王晓征（浙江移动信息技术部副总经理）：一、现在黑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+社群”热议话题讨论活动中，得到了以下联合发起人以及群友们的积极参与和支持。在此，小编整理成文，并附上所有发表观点的人员头像汇总图（排名不分先后），特此鸣谢！
本文来自云栖社区合作伙伴"DBAplus"，原文发布时间：2015-10-24
