存档

2011年1月 的存档

数据仓库环境,ORACLE RAC,100T数据,每日归档那个量5T(对于不需要产生备份的数据,已经采用了nologging方式,以减少归档数量),如何制定备份和恢复方案?
方案一:DataGuard
DataGuard是性价比最高的备份和容灾方案,但是当归档超过一定规模之后,DG的恢复就成为了瓶颈,每天产生的归档无法及时恢复完,我们也尝试过很多调优的方法,包括并行恢复,都无法解决,恢复的瓶颈不在存储的吞吐量,而在于standby的恢复方式,因为恢复的过程就是应用归档文件,RAC各个节点产生的归档必须在一个节点恢复,这个过程必须是遵循一定顺序的,大大限制了恢复的并发速度。
方案二:传统RMAN备份
采用传统RMAN备份,采用大吞吐量的虚拟带库设备,一周全备一次,每天备归档日志。很多时候,我们在做备份方案时,只考虑了备份,却没有考虑恢复。这个方案最大的问题就在于:恢复的代价非常高,一旦数据库出现问题,恢复可能需要数天之久,这是无法接受的。另外,还要额外购买备份设备。
方案三:存储镜像
数据库采用noarchivelog模式,采用ASM镜像两套存储。这个方案并不是备份方案,只是为了解决存储的单点问题而提出的,相当于对不同的存储做RAID 1。这个方案最大的问题是无法解决数据库逻辑错误,比如误删除数据。因为主库和备库通过存储镜像来实现,无法实现异地备份和容灾。
方案四:存储级别复制
采用存储级别的复制,各存储厂家都有解决方案,比如EMC SRDF等。Veritas也有类似的解决方案,比如卷复制(VERITAS Volume Replicator)。这种方案的基本原理都是通过捕获底层存储的IO,并通过网络同步到备份系统上。如果采用存储厂商的方案,那么主备库就必须使用同一家公司的产品,而且,能否承受每天4.5T的数据变化量,我们并没有验证过。另外,软件license费用不菲。
有人说:能用钱解决的问题不是问题。可是,问题是没钱!Alibaba虽然不缺钱,但是我们的目标就是花小钱办大事。我个人也不推荐使用存储厂商的解决方案,这不仅仅是钱的问题,而是这种方案基本上就是个黑盒,我们还是喜欢更简单开放的解决方案。
既然ORACLE DG是性价比最高的备份和容灾方案,我们还是想通过DG来解决这个问题。DG的好处在于可以随时打开备份,验证有效,standby延迟恢复还可以解决逻辑错误,防范ORACLE软件bug可能带来的损失。解决方案的核心就是要解决DG恢复速度慢的问题。
方案五:ORACLE DG+块级别增量备份/恢复+归档
从10g开始,ORACLE提供了一个功能:块改变跟踪(block change tracking),通过bitmap记录block的变化,通过这个块改变跟踪文件,就知道哪个block发生了变化,大大提高了增量备份的效率。具体方案为:首先为数据库建立一个0级备份(standby),然后将1级备份应用到0级备份上,相当于恢复的过程,这个恢复比应用归档日志要快很多,为什么?因为备份都是变化的block,只要将旧的block覆盖就可以了,所以不存在日志恢复过程中的顺序问题,所以恢复的并行度可以很大,可以充分发挥出设备的吞吐能力。另外,当一个block被重复变更多次时,增量备份只需要备份最新的block,恢复也只要覆盖旧的block即可,定期增量备份实际可以减少备份需要的空间使用量。而redo文件中记录了block变化的记录,所以应用redo恢复时需要多次变更该块,必须保留所有的归档文件才可以恢复成功。当然,应用1级备份之后,standby并不能打开,因为block并不是一致状态的(因为增量备份会持续很长的时间,在这个过程中,备份的block的时间点是不一致的),所以要利用归档文件将standby推到一致的状态才可以打开。
我们目前的方案:建立standby数据库,每周做一次增量备份,首先应用增量备份,然后应用归档日志文件将数据库推到一致状态,可以打开数据库,验证备份有效,归档日志文件循环备份到磁带库,整个过程通过脚本实现自动化。这个方案采用增量备份+archivelog恢复standby,可以打开standby验证备份有效,出现故障时可以直接standby switchover,大大节省了恢复的时间。而且,这个方案都是基于现有硬件基础,基本上没有采购额外的硬件设备和软件license,花小钱办大事。
我的技术理念:做解决方案就是搭积木,用简单的技术去解决问题,并不一定要发明新的东西,最佳实践也是很有价值的。
–EOF–
后记:这个问题,我曾经在OOW上问过ORACLE的技术专家,他们也没有很好的解决方案,建议我们买两套Exadata来解决(我并没有搞清楚为什么Exadata恢复归档的速度会变快,是设备本身的能力提高了,还是ORACLE恢复的方式发生了变化),或者放弃数据库级别的备份,由应用程序写多份数据来解决。所以说,ORACLE也没有考虑到如此大数据量环境的备份问题,ORACLE可以考虑推广我们的解决方案。

1 27th, 2011 | Filed under 大话技术
标签:

数据库HA的最基本要求是:1.应用透明切换;2.切换速度快;3.保证数据完整一致。ORACLE数据库的HA方案都要基于共享存储,即shared storage架构,不管是RAC还是Active-Standy方式。Data Guard更多是作为备份和容灾的方案,由于standby数据库在恢复的过程无法打开读写,Standby必须经过switch over之后才可以读写,即便11g提供了Active standby功能,DG并不是特别适合做HA方案,主要原因是:1.需要人工干预,应用不透明;2.切换速度慢,Standby必须经过切换才能读写;3.可能数据丢失,如果采用LGWR同步传输日志,可以保证数据不丢失,但是可能会影响性能。
MySQL在这方面比ORACLE要灵活许多,因为是类似逻辑复制的方式,复制的过程中数据库不仅可读写,而且还可以采用双向复制的模式,通过DB Proxy,可以提供非常灵活的HA方案,见下图:

于是,我们想到让ORACLE借鉴MySQL的方案,采用逻辑复制的方法,通过DB Proxy实现应用透明切换,方案的核心就是ORACLE日志解析与数据同步。采用这种方案的优点:1.应用透明切换;2.切换速度快;3.切换时可能会丢失部分数据。这种方案虽然无法完全保证数据一致性,但是只要日志文件不丢失,数据可以达到最终一致的状态(MySQL也是如此)。对于那些对于一致性要求不高的应用,只要将同步时延控制在一定的范围内,这个方案可以提供很好的灵活性,而且DG依然可以作为备份和容灾的角色存在。
这个方案的最大意义在于:ORACLE数据的HA不再依赖共享存储,存储设备通常都非常昂贵,而目前PC+SSD就可以提供非常高的处理能力,唯一的软肋就是可用性无法保证,如果这个方案可以实现,就可以用PC+SSD取代小型机+存储,真是很令人期待。
当然还需要解决很多问题:1.实时解析日志,减少时延;2.同步变更字段,减少网络传输;3.并行应用,提高应用速度。目前,我们正在努力解决,很快可以看到曙光。敢想敢为,就没有不可能!
–EOF–

1 19th, 2011 | Filed under 大话技术
标签:

回首过去的2010年,工作的关键词是“变化”。
首先,团队成员发生了很大的变化,一些兄弟选择离开了团队,从个人感情的角度出发,任何一个人的离开我都很难受,看到朝夕相处的兄弟们离开,曾经给我带来了很大的痛苦。但是,从个人和团队的发展来看,这其实是件很正常的事情。与此同时,也有很多新同事加入到这个团队,不仅为团队注入了新的活力,而且带来了很多不一样的思路,这正是我们所需要的。
其次,团队的工作发生了很大变化,为了给每个人更大的发展空间,我们主导了应用DBA和产品DBA的工作模式的转型。应用DBA全面接手产品数据库环境的变更,开始接收数据库报警,关注数据库性能优化,具备更大的权力和职责,同时从单纯的应用支持逐步向顾问和数据架构师转型。产品DBA实现数据库统一管理,每个人都能管理所有的数据库,开发和优化监控平台,推进数据库新技术的应用,同时关注应用优化与架构改进,与应用DBA一起合作,提升系统性能与可用性。同时,整个团队开发了很多自动化的工具,大大提升了工作效率,这是2010年最让人欣喜的地方。
第三,管理的思路发生了很大变化,我们不仅仅关注工作的结果,我们更关注每个人的发展,关注每个人的感受。应用DBA和产品DBA并不是割裂的,应用DBA需要了解底层硬件,而产品DBA需要深入了解应用架构,所以我们创造机会让大家可以学到更多领域的知识,创造机会让工作职位流动起来,让每个人都能够从团队发展的过程中受益,每个人都有公平的机会去发展和提高。
第四,技术的方向发生了很大的变化,ORACLE不再是唯一的选择,分布式MySQL为海量数据处理提供了更多选择,KV的解决方案如雨后春笋般涌现,数据存储多样化成为一种趋势,同时,SSD的大规模普及也近在咫尺,给我们带来了无限遐想。同时,太多的选择也意味着痛苦,更多时候不是技术的考验,而是心态的考验了。在经过很长一段时间的思考之后,我们形成了“集中式ORACLE,分布式MySQL,KV有效补充”的统一技术方向,明确了数据存储选型的标准,不再乱花渐欲迷人眼,让整个团队有了明确的技术方向,
2011年的关键词是“开放”,每个人都要用开放心态去拥抱变化,跳出ORACLE数据库的圈子,扩展到整个数据存储领域,不再纠结于某个具体的技术细节或者产品选型上,而是用更加开放的心态去看待问题,解决问题,这是我对团队每个人的期望,也是对我自己的要求。
2011年有更多的技术挑战等待着我们:Flashcache的大规模应用,Greenplum数据库运维,ORACLE数据库统一管理,MySQL数据库自动管理,更强大的性能监控平台,与平台架构部门合作推广分布式数据库架构,持续开发数据库日志解析同步工具,MySQL源码学习与改进等等。另外,我们需要更多的关注可用性,提升可用性,保证数据库可用性,是DBA最基本的价值。
回首2010年,个人感觉在技术上还是有所进步,能够从数据库出发,将知识面扩展到硬件,应用架构和数据存储等更大的领域,知识不再是单纯的经验积累,而且可以扩展到未知的领域,可以提出一些新的思路与方法,对于技术的领悟力有了质的提高,我觉得不断思考是进步的最大根源。当然,也有不满意的地方,写书的事情一直没有进展,博客倒是零散写了几篇,希望2011年能在这方面有所突破。
关于生活,关键词是“平淡”,相妻教子几乎是生活的全部内容,也许到了我现在的阶段,平淡就是幸福生活的真谛吧。
2010年已经过去,我希望2011年有更大的挑战和更大的收获,个人和团队都能够持续扩大影响力,可用性问题不再困扰我们,团队每个兄弟都开心快乐,我爱这个团队,我爱每个人。
–EOF–

1 13th, 2011 | Filed under 一地鸡毛

当初年少无知,对残酷的社会现实缺乏了解,导致HelloDBA在国内注册域名,这几年吃尽了苦头,被迫做了域名备案也就算了,而且多次申请转移域名不成功,因为怕麻烦就选择了续费。
今年,实在忍无可忍,投诉到ICANN,注册商终于打来电话,要求提供资料,然后又很无耻的在验证身份这个环节做文章,总之就是故意阻挠域名转移,耗费精力无数,实在不愿意再和这个注册商打交道了。
宁为玉碎不为瓦全,我决定放弃HelloDBA.net这个域名,在Godaddy上新申请了一个HelloDB.net的域名,坚决不再给这个无耻的注册商一分钱,我再次强烈呼吁大家不要在国内的任何一家域名注册服务商注册域名,也不要使用他们的任何服务。
近期我将把博客迁移到新的域名下,原有的域名我会继续投诉到ICANN,抗争到底!
–EOF–
经过再三考虑,最终将新的域名修改HelloDB.net,希望大家继续支持!

1 10th, 2011 | Filed under 大话技术