Boss要求零数据丢失,Data Guard的三种保护模式如何选择?

运维 数据库运维
公司现在越来越重视数据的灾备,部署了大量的Data Guard和Oracle GoldenGate。核心系统的数据非常重要,大boss的要求很简单就是数据零丢失。仔细衡量Data Guard的三种保护模式,在最大可用和最大保护之间展开了激烈的讨论。下面从技术层面看看这两种保护模式的特点和区别。

公司现在越来越重视数据的灾备,部署了大量的Data Guard和Oracle GoldenGate。核心系统的数据非常重要,大boss的要求很简单就是数据零丢失。

仔细衡量Data Guard的三种保护模式,在最大可用和最大保护之间展开了激烈的讨论。下面从技术层面看看这两种保护模式的特点和区别。

[[190001]] 

零数据丢失:

在DataGuard中同步传输SYNC(synchronous transport)又称为零数据丢失。因为要等到确认事务恢复所需要的redo数据已经被写入备用数据库的磁盘上(StandbyLogFile),才允许LGWR认可提交操作成功。

最高可用:

  1. ALTER DATABASE SET STANDBY TO MAXIMIZE AVAILABILITY;  

这个模式最强调可用性,其次强调零数据损失保护。该模式使用SYNC(同步)方式传输redo数据,因此从备用数据库收到“redo数据已经写入磁盘”确认消息所需的时间会影响主库的性能。但是在主库出现故障时,通常可以百分百保护数据。

然而网络故障或者备用数据库出现故障,将无法向备用数据库传输redo,而主库仍能继续接收新事物。 配置最高可用时,其最长等待秒数有NET_TIMEOUT的值决定(默认30秒),此后将放弃备用目标,即使仍然无法与备用数据库通信,也允许主数据库继续进行处理。当连接重新建立后,主库将强制切换一次日志,关闭current redo log,防止在间隔再同步过程中redo传输进一步滞后。仅当在自动重新同步进程尚未完成前,主库又一次出现故障时才可能丢失数据。

最高保护:

  1. ALTER DATABASE SET STANDBY TO MAXIMIZE PROTECTION; 

采用SYNC同步redo数据传输模式,直到收到配置中至少一个备用数据库的确认消息(恢复事务所需的数据已经可靠第保存在磁盘上),主数据库才确认提交。与最高可用不同的是,它不再考虑NET_TIMEOUT参数。如果主数据库未能从SYNC备用数据库收到确认消息,主数据库将停下来并最终终止,防止出现未保护提交的情形。

最高性能:

就是快在ASYNC,异步传输模式上。LGWR进程不必等待LNS的确认消息。该种方法不再考虑范围之内。

最高可用vs最大保护

最大可用顾名思义是以可用为第一目标,安全性会为了可用性自动降级。它的阿基里斯之踵就是在NET_TIMEOUT超时后,主库会继续处理事务,等到当前redo写满,开始进入归档模式时才会再次尝试连接备用数据库。这个期间主库与备库的数据时不一致的,出现灾难场景failover后回丢失数据。

可是最大保护呢,这个反对呼声也非常高,就是担心网络问题或是备库问题导致无法及时给主库的LGWR反馈信息,使主库挂掉。

解决方案:  

其实满足boss的零数据丢失,可以采用最大保护模式。为主库创建2个或3个最大保护模式的同城灾备,一个备库在同机房不同机柜,其它的备库在不同的机房(可能相隔几公里)。当主库发起一个事物提交动作,LGWR进程将redo log buffer中的内容写入redo log file同时LNS进程将该redo log buffer中的信息发送给备用数据库。这时只要有一个最大保护模式的备用数据库成功收到该数据并写入standby log file中就会给主库的LGWR进程反馈成功,主库会继续处理事务。并不需要所有的备用数据库都向它反馈。 从某个角度来看该方法更像是解决备用数据库的“单点故障”。当然只有一台备用数据库,并且采用了最大保护模式还是有影响主库的可能性。

责任编辑:杜宁 来源: Oracle疑点通
相关推荐

2010-08-31 11:14:32

2010-09-26 17:09:22

日内数据保护

2017-07-14 15:07:23

2017-11-02 14:18:04

2022-06-13 08:18:02

操作系统CPU保护模式

2010-07-05 18:32:25

2018-08-21 10:05:59

MySQLbinlog数据库

2023-02-24 16:45:02

2017-10-13 12:01:01

甲骨文数据

2023-07-06 00:45:05

Linux保护模式

2010-09-30 14:40:45

2015-09-14 09:31:44

结对设计

2010-07-13 15:55:12

FTP数据传输模式

2022-05-27 11:33:02

前端代码设计模式

2009-11-06 13:23:27

WCF模式

2021-07-27 12:38:07

Kubernetes攻击者勒索软件

2011-11-02 11:06:50

2016-09-13 14:05:24

Spark集群管理模式

2010-06-28 17:43:44

SQL Server

2010-05-20 10:06:47

云计算数据保护第三方
点赞
收藏

51CTO技术栈公众号