DataGuard - 利用Cascaded Redo Log Destinations避免WAN稳定性问题

最近一直头疼于DataGuard环境中万一网络失败将导致的Primary库短时间内无法正常工作的问题。

这个问题的现象基本上是这样：
当Primary和Standby之间的网络出现问题，比如说在测试环境中我们拔掉Standby的网线，此时当Primary发生日志切换（Log Switch）的时候，Primary将试图通知Standby同样作归档，但是由于网络不通，就会默认有30秒的TimeOut，而在这30秒的时间内，Primary上的任何DML操作都将被悬停。
至今为止我还没有找到很好的办法可以有效地缩短这个TimeOut时间，虽然按照文档上说应该可以缩短到最小15秒。即使是15秒，也是无法忍受的，特别是如果DataGuard环境搭建在WAN上，比如说通过2M的DDN专线，那么出现网络故障的几率是比较高的。
如果说将有可能由于DataGuard的网络原因而导致主业务库的操作悬停，无论对于客户还是对于我个人而言都是不太容易接受的。

WAN上的网络故障几率较大，那么如果我们换到LAN上，就可以降低这种故障的发生率。由此想到可以利用DataGuard中的 Cascaded Redo Log Destinations 功能。今天作了此项测试，效果还是很理想的。
所谓Cascaded Redo Log Destinations功能，是指A机器（Primary）将redo数据传递给B机器（Standby），然后B机器再将接收到的redo传递给C机器（Standby），这种中转方式在Physical Standby和Logical Standby中都可以实现。如果A，B处于同一个LAN中，而B，C则通过WAN通信，那么即使WAN出现网络问题，也不会影响A将redo传递到B，也就不会影响A的业务进行。

大概配置如下：
1。A (Primary)的init参数：
*.log_archive_dest_1='LOCATION=/oradata/ctsdb/archive'
*.log_archive_dest_2='SERVICE=CTSDB.JUMPER LGWR ASYNC=20480 NET_TIMEOUT=15 MAX_FAILURE=2 REOPEN=10'

2。B (Standby1)的init参数：
*.log_archive_dest_1='LOCATION=/oradata/ctsdb/archive'
*.log_archive_dest_2='SERVICE=CTSDB.STANDBY'
*.standby_archive_dest='/oradata/ctsdb/archive'

3。C (Standby2)的init参数：
*.log_archive_dest_1='LOCATION=/oradata/ctsdb/archive'
*.standby_archive_dest='/oradata/ctsdb/archive'
*.fal_client='ctsdb.standby'
*.fal_server='ctsdb.jumper'

其它的配置文件，比如listener.ora和tnsnames.ora，不再赘述。

在B机器上的alertlog中一些比较有趣的地方：
Thu Jan 13 12:05:27 2005
RFS: Successfully opened standby logfile 4: '/oradata/ctsdb/redo04.log'
Thu Jan 13 12:05:33 2005
RFS: Successfully opened standby logfile 5: '/oradata/ctsdb/redo05.log'
Thu Jan 13 12:05:38 2005
RFS: Successfully opened standby logfile 6: '/oradata/ctsdb/redo06.log'
RFS: Successfully opened standby logfile 7: '/oradata/ctsdb/redo07.log'
RFS: No standby redo logfiles of size 6144 blocks available

以前的测试和 Freelists 中的一些邮件列表的讨论都表明在DataGuard环境中我们最多只能使用到2组Standby Redolog（一般情况我们只会只用到1组），这是因为Oracle对于SRL的启用机制就是从首个SRL开始找第一个可以使用的，正常情况下只有在接受下一次redo信息时，redo04.log还没有被归档成功，这时候才会使用redo05.log，而redo05被写满以后，redo04还没有被归档结束的情况我们几乎不可能碰到，所以下一次的redo信息又被写到redo04中。
而这次测试，由于B和C之间的网络中断，导致redo04－redo07这四组SRL都被启用了，并且再接下去RFS报了No standby redo logfiles的错误，这个同样很明显地表示了如果网络中断，在TimeOut时间内，redo是无法被正常归档的。
那么大家可能要问，如果B的4组SRL都无法使用了，A继续传过来的redo数据是不是也会被阻塞，从而也间接导致了A同样无法正常继续业务？
在测试之前，我也同样担心这个问题，但是测试表明这种情况没有出现。原因在于DataGuard的机制是，即使A指定了使用LGWR传递redo（如本例所示），如果出现B上的SRL无法使用的情况，B的RFS进程将把接受到的redo直接写入本机的Archivelog中，当A开始归档的时候，B同时归档刚才写入了数据的Archivelog（此归档的Sequence比A上归档的Sequence大1）。从下面的alertlog中可以确认这点：
ARC1: Evaluating archive log 6 thread 1 sequence 600
ARC1: Beginning to archive log 6 thread 1 sequence 600
Creating archive destination LOG_ARCHIVE_DEST_2: 'CTSDB.STANDBY'
Creating archive destination LOG_ARCHIVE_DEST_1: '/oradata/ctsdb/archive/1_600.dbf'
ARC1: Completed archiving log 6 thread 1 sequence 600

从以上的测试中我们得出一个结论，只要是Primary可以跟Standby的RFS进程正常通信，那么就不会产生操作被悬停的问题，不管Standby到底是使用了SRL还是使用了Archivelog。

最后，由于这样的环境添加了额外的机器（机器B），而由于DataGuard环境必须要求同构，所以如果整个环境是UNIX的，那么也许大家要问，这样岂不是需要再购买一台小型机，这在budget方面是不是就有些问题了。
确实，需要额外的投入，但是由于B机器只是作中转redo的作用，所以我们甚至可以不将B置于managed recover模式下，也就是B只负责接受A的redo，再把redo传送到C，这样对于B机器的性能要求就可以下降很多，也许一台普通的SunRay工作站就可以满足要求了。至于是不是确实可以满足性能需求，我还会有后续的测试。
呵呵，敬请期待。

DataGuard - 利用Cascaded Redo Log Destinations避免WAN稳定性问题相关推荐

新特性速递 | InnoDB redo log archiving(归档)
导读 MySQL 8.0.17开始支持的redo log归档能干嘛用呢,好吃吗今天,MySQL 8.0.17发布了,看了下release note,发现果真如之前预期的那样,恢复了redo lo ...
Upgrade after a crash is not supported. The redo log was created with Maria的解决办法
关于[InnoDB] Unsupported redo log format (0). The redo log was created before MySQL 5.7.9的解决办法利用mkdir ...
浅谈Oracle Online redo log
Oracle online redo log是Oracle数据库中核心文件之一.在数据库操作中,只要有任何的数据块变化,都会生成相应的redo entry.redo entry首先保存在log buf ...
MySQL中的重做日志（redo log），回滚日志（undo log），以及二进制日志（binlog）的简单总结...
MySQL中有六种日志文件, 分别是:重做日志(redo log).回滚日志(undo log).二进制日志(binlog).错误日志(errorlog).慢查询日志(slow query log). ...
MySQL中的重做日志（redo log），回滚日志（undo log），以及二进制日志（binlog）的简单总结
前言 1. ''最近公司大佬让我优化sql的时候,说可以通过控制where条件,尽可能的少的较少数据库的开支,少生成一些无用的binlog.由此引出binlog这个概念,大家一起学习一下关于Binl ...
MYSQL专题-MySQL三大日志binlog、redo log和undo log
日志是mysql数据库的重要组成部分,记录着数据库运行期间各种状态信息.mysql日志主要包括重做日志(redo log).回滚日志(undo log).二进制日志(bin log).错误日志(err ...
有关 Oracle redo log
Redo的内容 Oracle通过Redo来实现快速提交,一方面是因为Redo Log File可以连续.顺序地快速写出,另一个方面也和Redo记录的精简内容有关. 两个概念: 改变向量(Change ...
mysql重做日志与binlog日志区别_MySQL日志之binlog、redo log、undo log
1. binlog(二进制日志) 1.1 binlog介绍 binlog记录了对数据库执行更改的所有操作(不包括查询),还包括了执行数据库更改操作的时间和执行时间等信息.binlog主要有两个作用:恢 ...
MySQL——binlog，redo log
一.什么是binlog.redo log binlog属于逻辑日志,是逻辑操作.innodb redo属于物理日志,是物理变更.逻辑日志有个缺点是难以并行,而物理日志可以比较好的并行操作. binlo ...

DataGuard - 利用Cascaded Redo Log Destinations避免WAN稳定性问题

DataGuard - 利用Cascaded Redo Log Destinations避免WAN稳定性问题相关推荐

最新文章

热门文章