时至今日,“虚拟化”,“云”等名词早已耳熟能详,其提供的特性:将服务器物理资源抽象成逻辑资源,可以将一台服务器变成几台甚至上百台虚拟服务器;将CPU、内存、磁盘、I/O硬件抽象化,变成可以动态管理的“资源池”,可以提高硬件资源整合密度, 减低成本,简化系统管理,提升工作效率。
保险行业升级测试工作较多,此为行业背景。从客户甲了解到,他所在的DBA团队一方面要承担数据库日常维护工作,另一方面也要为业务部门提供测试数据库。除去生产环境的日常维护,以下几项工作耗费较多精力:
客户甲向我们倾诉工作中的苦恼:核心数据库自然不必说,再多保障也是应该的。但是一些边缘业务的数据库,数量比较多,不备份肯定不行,搭建Dataguard又存在硬件资源无法完全利用的情况。
业务方要求每天都提供新的测试数据库,因为部分数据库体量较大,需要有专人每日负责该工作,仅这 一项工作就要占用2人/天,而且重复劳动,人员积极性不高;数据库多了以后,因为多人同时维护,备份就很容易出错,有时会出现备份脚本不工作,几天之后才发现的情况。
了解到客户遇到的问题之后,我们分析发现此架构中几处不合理的地方:
同一份数据,存在于文件备份服务器,DG服务器,测试服务器三个地方,浪费严重,原本只有20TB的数据库却要占至少60TB的空间。有DBA认为这样的做法虽然占用空间较大,但万一遇到故障,似乎可供恢复的选择也比较多,并举例说网上也有备份失效后从测试服务器恢复的案例。
不得不说这是一种极其错误的看法,文件备份作为冷备长期保存没什么问题,但因其恢复时间较长,不应作为数据恢复的首选项;Dataguard处于可读状态,配合Flashback似乎可以达到数据恢复的目的,但Flashback记录的是数据块变化,日志量相比Redo日志要高出十几倍,应用速度也比较慢,时间效率并不高;至于测试数据库,其内容随时可能被修改,更不应该当做常规恢复手段。
因此测试服务器多一份数据是没有必要的,并不会带来安全上的提升,每次导入完整数据只是无奈之举而已。
客户的某些数据库已达几十TB,每次导入操作对人员,带宽,IO都是极大的压力,更不用说每天都要导入一次完整数据到测试数据库,简直就是一场灾难。
经过综合分析评估,我们为客户部署一台QBackup备份容灾一体机,以替换其现有的Dataguard服务器、测试服务器。
客户收益
客户点评:部署QBackup后不仅节约了大量的硬件成本,而且创建测试数据库仅需要花费几分钟,相比之前动辄耗费一天,工作负荷大大减轻。
数据无价:不仅降低了TCO成本,QBackup提供的CDP备份,秒级恢复的特性还极大提高了数据安全性,而数据是无价的!
三大法宝
QBackup基于CDM技术,测试机可复用数据文件,省去了每次导入的时间、带宽、IO消耗。无需导入数据也极大缩短了搭建测试库时间,仅需3分钟即可一键创建。
采用沙盒机制,原始数据为只读不会受到任何影响,测试过程中修改的内容由单独的沙盒区域保存;省去了数据导入的消耗后,基于虚拟化创建出测试机性能上完全满足开发测试需要。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。