oracle同步数据adg_关于数据库灾备，你想知道的都在这里

最新推荐文章于 2024-08-29 09:12:53 发布

SMS Parry

最新推荐文章于 2024-08-29 09:12:53 发布

阅读量1k

点赞数

文章标签： oracle同步数据adg

本文链接：https://blog.csdn.net/weixin_30067913/article/details/112459579

版权

编者按：本文为“千字千金！中国首届灾备行业征文大赛”参赛作品，本文作者为英方技术经理庄辉，文章从一名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的学习能力、解决问题的能力要求也是越来越高，唯有不断学习与实践才是常胜之道。