数据库的容灾与备份，你是如何处理的？

Topic

由于核心工作人员的相继离职，运行了15年的国内数据库著名论坛**PUB在中秋节前，因bug修复请求导致全库关闭2天多，数据丢失近4个月。因工作人员的疏忽导致数据丢失的情况屡见不鲜，那么你是怎么管理/维护所在公司的数据库的？贵公司有多少套或多少比例的数据库没有每年至少2次恢复演练？重大操作前，是否都会对可能存在的风险进行评估，并准备好相关预案和应急措施？针对此著名论坛事故，你觉得有必要调整公司的数据安全保护策略吗？（本期话题贡献人：杨志洪）

 

 

 

精彩论点  

 

 

vage：从备份方式上说，我待过的几家电商，都依赖主、备库方式备份。一主两备，两备之中，一个备库是实时恢复，作为存储级高可用。另一个备库当延时恢复，应对误用户级操作。极少量库有磁带啊这样的备份方式。

 

主、备的切换的恢复演练我们每年都会做。核心、重要的库，每年都至少做一次主备切换。我们所有库都有主备库这样模式的容灾环境。

 

 

周睿婷的爸爸：一般公司都会根据系统的重要程度，RTO、RPO的要求制定相应的数据库备份和容灾规范，像金融行业保监会，银监会都下发了明确的文档规定RTO、RPO时间。如果企业没有制定相关的规范那是管理上的问题，如果制定了规范但是正确有效的执行肯定是DBA的问题了。丢了2个月数据估计是DBA备份检查工作没做好吧。

 

我们做过一些基于PPRC、SVC和DG异地容灾的方案，我记得SVC每次同步有一个最小值（好像是25M），哪怕你更改的块不多它还是以最小值为单位传输的。我觉得从网络带宽和验证便捷的角度DG是有优势的。

 

 

Ora-Dual：我理解的（Oracle数据库）主备，用ODG来做会好于在存储上复制的主备方式，但这个也要看一些特定的场景。比如低版本的Oracle数据库用ODG会有困难，至少我们这边对于这样的环境用的是goldengate。

 

双存储做asm Failover diskgroup用IBM的remo mirror。本地磁盘陈列到本地san网络，通过电信交换再到远端的san交换，最后到远端阵列。

 

 

十一月肖邦：ogg对于磁盘级拷贝（HDS的HUR方案操作系统做镜像还是很难控制一致性），现在灾备有sanboot技术方便很多，但是对于异地灾备（北京-上海单向）还是需要做很多配置，dataguard这种方案对于异地灾备方案基本可以忽略，对于数据中心级别异地灾备，基本是HDS和EMC的天下。

 

dg异地灾备可以是可以，但要看距离，因为要铺光纤。异地灾备基本都是磁盘级别拷贝，dg的作用基本无视，只能当作高可用的功能。

 

做db就不要干什么都想着db，db的东西是应用层，等你要去恢复应用，已经是最糟糕的情况了。就像你家着火了你还在搬家电，这个时候一定要赶紧逃跑。所以一定要快，抢时间恢复，能恢复多少是多少，允许数据丢失。如果不允许数据丢失，这个世界估计没人做得到。

 

 

Joseph：应用级的好处就是可以保证事务的一致性，各有各的应用场景，磁盘级的copy在远距离传输中更有优势。远距离磁盘copy延时一般要求低于5ms，而这种要求也是针对应用的有要求，所以要在一定前提下做灾备的规划。磁盘基于块级，可以做到更小颗粒度，节约了带宽，延时更小。

 

 

白鳝：十多年前帮一个银行搞过一个工具叫开库操作管理平台，一个人写sql，一个人评审，通过才执行，在核心账务库操作只能通过这个平台。

 

架构上保证误操作可纠正是更好的办法，Oracle的闪回就是干这个的，可以在dg上开闪回。早年我们给客户设计高可用的时候设计两个dg，一个自动recover，做灾备用，一个延时apply，做误操作的恢复用。

 

 

众说纷纭  

 

alex-t：容灾还是dg靠谱，存储的最多做备份。存储底层没办法保证数据一致性，一般要用for Oracle组件配合，而且实时性不好，还是dg架构简单，管理便捷。

 

小徐：对于存储还是adg最好同时使用，存储方式虽然快，但是安全性谁都保证不了，再说现在带宽相对廉价了，使用adg也未必不可，可以与存储结合使用。

 

流氓才子：我觉得，重大操作时要按照标准化流程。建立多级审核制度，越是重要的操作，越是需要审核，最好来个评估委员会，虽然效率低了点

 

tony：容灾讲体系的，不仅仅这个那个复制技术，最重要的是符合企业业务需求。双活也好，单活也罢，都是为业务服务。

 

发起人的话   

 

杨志洪：这个话题很有意思，私下跟几个制造业的朋友聊天，我们大家都知道容灾的重要性，但是有些老板不这么认为，甚至真建设好了他都没办法跟老板说有什么成效。我想说，这就是**PUB事故的源头，当最后一个熟悉环境的人离开后，灾难随踪而至。不管你用什么技术实现，如果你的核心数据库还没有容灾，甚至还没有备份，那是时候做起来了。

 

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

  

 

本文来自云栖社区合作伙伴"DBAplus"，原文发布时间：2015-9-29

数据库故障恢复机制的前世今生 在数据库系统发展的历史长河中，故障恢复问题始终伴随左右，也深刻影响着数据库结构的发展变化。通过故障恢复机制，可以实现数据库的两个至关重要的特性：Durability of Updates以及Failure Atomic，也就是我们常说的的ACID中的A和D。文章将首先描述故障恢复问题本身；然后按照基本的时间顺序介绍传统数据库中故障恢复机制的演进及优化；之后思考新硬件带来的机遇与挑战；并引出围绕新硬件的两个不同方向的研究成果。
数据库异地备份及查询 以往的数据库异地备份方案中，往往采用本地备份压缩后上传异地的方式，不便于历史数据管理，随着时间间隔的增大，被查询的可能性越来越低，一视同仁会浪费存储资源。
数据库异地备份及不还原快速查询备份集最佳实践 传统数据库异地备份和查询中，有两个大的痛点，一个是备份数据集的管理，另外一个是备份数据的查询，本方案将通过阿里云DBS、OSS、DLA的组合，搭建一整套数据库本地/异地自动化备份和管理的方案。在备份的基础上，实现分钟级全备数据集的查询，节省大量数据库还原时间。