关于数据库灾备,你想知道的都在这里

云灾备-英方云 发布于:2019-04-30 20:01:22

编者按:本文为参赛作品,本文作者为英方技术经理庄辉,文章从一名DBA的角度,介绍了数据库灾备业务中常见的一些问题,这些内容,对于每一位想要接触或正在接触数据库灾备的人来说,都是大有裨益的。以下为文章正文。


 




 


说到数据库,就不得不提灾备,灾备话题常年占据着各个DBA社区的头条位置,而说到数据库灾备,首先要说的就是Oracle数据库灾备,说到Oracle数据库灾备就不得不提两个与之相关的概念,一个是架构层面的RAC,一个是技术层面的数据复制。


 


RAC本质上是一种集群,即cluster,主要的作用是负责故障切换和高可用。


 


首先,RAC可以做到故障切换,即两台服务器如果其中一台发生宕机,那么另一台服务器可以继续对外提供服务,继而保证业务的连续运行。


 


其次,RAC还可以实现负载均衡。假设上层应用要接收两千个订单,那么RAC可以将两千个订单平均低分配给不同的节点,当然,在实际中更多的是根据应用来分配订单,并做进一步的负载均衡。


 


虽然RAC有着诸多的优点,但是也具有一个较为明显的问题,即数据为单份——RAC的数据只有一份共享存储。所以严格意义上的RAC并不是一个完整的灾备手段,他的更大的意义体现在高可用层面。


 



 


除了RAC,我们还需要对Oracle自带的灾备软件DG/ADG有所了解,常用的容灾软件采用的技术方案是主库将redo log传递到备库,备库对redo log进行应用,实现数据库异地复制。但这种技术存在一些问题,比如数据传递为单向传递,只能从主库传递到备库,且不能跨版本传递等。


 


此外,这种日志应用方式可以分为物理和逻辑两个层面。


 


物理层面中,备库对于redo log(默认archivelog)进行block级别的media recovery,相当于主库的克隆,和主库有相同的DBNAME和DBID。备库打开后,在只读状态下,构建读写分离的应用环境(ActiveDG),可以通过snapshot DG构建可读写的测试环境。


 


而逻辑层面中,备库会自动对redo log进行日志挖掘(logminer),执行相应的SQL。且备库和主库是两个独立的库,具有不同的DBNAME和DBID。最后,部分DDL和数据类型不受支持,相较于物理层面具有一定的局限性。


 


这种方式对数据库有三种保护模式。


 


1. 最大保护:数据100%零丢失。但是生产环境中很少使用最大保护模式,因为如果备库出现问题或网络延迟,都会给主库的事物带来性能的影响。且最大保护模式要求必须两个以上的备库,对客户来讲,需要准备三台服务器,因此,最大性能模式更加受到客户的青睐。


 


2. 最大性能:相较于最大保护需要三台服务器,最大性能只需要一台服务器便可以满足业务需求。虽然最大性能无法做到数据100%零丢失,可能主库和备库之间会存在数据差异,但是,网络和备库都不会对主库的事物处理带来影响,这也是最大性能模式的最大优势。


 


3. 最大可用:最大可用模式也可以保证数据100%零丢失,但是和最大保护模式一样,备库和网络延迟都会对主库造成影响,且需要两台以上的服务器。但是在最大可用模式下,如果主库没有接到备库发出的信号,将自动转换成最大性能模式。


 


总结来说,想要应用Oracle这种灾备技术,首先必须要开归档。Oracle的所有备份,都需要数据库开归档。对于没有开归档的数据库,则无法解决。其次,对带宽要求极高,且切换麻烦,对运维的DBA要求极高。第三,对数据库的要求必须是同版本,且只能做到实例级别的同步。


 


SQL Serve的Cluster也是高可用级别的集群,即故障转移群集。与RAC相似的事,SQL Serve也为数据单份,但是相比RAC,SQL Serve要求必须有域控,且域控本身的使用相对麻烦,并需要服务器。因此对于传统的cluster,SQL Serve对服务器要求很高。但是由于数据单份,因此切换很快,且过程不会有数据丢失。另外SQLServer2012中新增的AlwaysOn是一个新增高可用性解决方案。在AlwaysOn之前,SQL Server已经有的高可用性和数据恢复方案,比如数据库镜像,日志传送和故障转移集群,都有其自身的局限性。而AlwaysOn作为微软新推出的解决方案,提取了数据库镜像和故障转移集群的优点。SQL Serve AlwaysOn的主节点既可以是集群,也可以是单机,且SQLServe的备库可读。其模式既有异步提交,也有同步提交模式。但是AlwaysOn依赖域控,对带宽要求高,出现故障排错麻烦。


 


MySQL在原理上也是应用日志,并且备库可读,但是MySQL为命令行安装,缺乏图形化和统一的管理平台。


 


英方的i2Active即为逻辑日志技术原理。可以在数据库高并发事务场景下实现数据库全量同步、增量同步,通过同步校验确保数据库源端和目标端的事务级最终一致性 ; 同时提供备库接管和增量回切等高级功能,帮助用户在复杂的应用环境下完 成数据库的容灾备份、异构数据迁移、数据分发、构建数据仓库等数据整合工作。


 


通过以上叙述,我们会发现在实际场景中,几乎没有PRO=0、RTO=0的灾备解决方案,这样的绝对情况,更多的是出现在理论中;其次,如果做IDC或者全业务级管理将十分麻烦,而未来的灾备业务将是一个系统工程,因此一个统一的管理平台是必不可少的;最后,在技术和业务场景不断更新换代的当下,对于每一位DBA的学习能力、解决问题的能力要求也是越来越高,唯有不断学习与实践才是常胜之道。