Data Guard高级玩法:通过闪回恢复switchover主库

简介: 最近又发掘出了Data Guard的新玩法,可以通过闪回恢复switchover的主库,这种场景听起来比较特别,但是Oracle依旧支持。 我们的大体思路就是,在主库我们标记一下数据状态,然后做Switchover之后,我们truncate 某个表中的数据,也就间接模拟了一个数据库故障,这个时候需要做回退,需要把主库的数据都恢复到切换前的状态,这个听起来还是比较复杂的场景,备库还可以一如既往的跟着主库吗? 我们用图表来说明一下: 首先是一个主备库的环境: switchover是计划内的任务,就是主切备,备切主。
最近又发掘出了Data Guard的新玩法,可以通过闪回恢复switchover的主库,这种场景听起来比较特别,但是Oracle依旧支持。
我们的大体思路就是,在主库我们标记一下数据状态,然后做Switchover之后,我们truncate 某个表中的数据,也就间接模拟了一个数据库故障,这个时候需要做回退,需要把主库的数据都恢复到切换前的状态,这个听起来还是比较复杂的场景,备库还可以一如既往的跟着主库吗?
我们用图表来说明一下:
首先是一个主备库的环境:


switchover是计划内的任务,就是主切备,备切主。

这个时候发现切换出现了问题,我们需要紧急回退,需要回退到切换前的状态,要知道此时的主库已经不是原来的主库,备库也不是原来的备库了。闪回是否依旧可行,备库是否可以依旧选择一个新的断点可以重新同步?


我们来通过实战演练一下,当然这个操作需要保证主备库都开启了闪回数据库的特性,在11g中开启已经不再需要重启数据库,open阶段即可随时开关。

主库的操作如下:

我们创建一个表test,插入2行记录。
SQL> select count(*)from n1.test;
  COUNT(*)
----------
         2
然后我们得到一个初始的SCN值。         
SQL> select current_scn,database_role,flashback_on from v$database;    
CURRENT_SCN DATABASE_ROLE                  FLASHBACK_ON
----------- ------------------------------ ------------------------------------
    2084486 PRIMARY                        YES
检查DG Broker的状态,这里snewtest2是主库,newtest2是备库。
DGMGRL> show configuration;
Configuration - dg_newtest2
  Protection Mode: MaxPerformance
  Databases:
    snewtest2 - Primary database
    newtest2  - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
然后我们开始测试这个方案。

备库的操作如下:
DGMGRL> switchover to newtest2;
Performing switchover NOW, please wait...
New primary database "newtest2" is opening...
Operation requires startup of instance "newtest2" on database "snewtest2"
Starting instance "newtest2"...
...

切换之后查看DG Broker的状态,也看到主备库的角色已经调整过来了。

DGMGRL> show configuration;
Configuration - dg_newtest2
  Protection Mode: MaxPerformance
  Databases:
    newtest2  - Primary database
    snewtest2 - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
这个时候我们查看表test的数据。
SQL> select count(*)from n1.test;
  COUNT(*)
----------
         2

然后开始破坏。直接truncate
SQL> truncate table n1.test;
Table truncated.    

这个时候业务层面发现了数据的连锁错误,准备开始回退到初始的状态。    
SQL> shutdow immediate
SQL> startup mount

开始闪回数据库,恢复到初始的数据状态

SQL> flashback database to scn 2084486;
Flashback complete.

这个时候需要resetlogs
SQL> alter database open resetlogs;
Database altered.

原来的主库操作如下:

先初步验证,发现这个时候DG Broker验证失败。
DGMGRL> show configuration;
Configuration - dg_newtest2
  Protection Mode: MaxPerformance
  Databases:
    newtest2  - Primary database
    snewtest2 - Physical standby database
      Error: ORA-16810: multiple errors or warnings detected for the database
Fast-Start Failover: DISABLED
Configuration Status:
ERROR
我们关闭日志的应用。
SQL> recover managed standby database cancel;

然后开始闪回到指定的SCN
SQL> flashback database to scn 2084486;
Flashback complete.
完成之后,重新开启日志应用。
SQL> recover managed standby database disconnect from session;
Media recovery complete.

这个时候操作成功,我们就直接开启ADG,把数据库开启到open状态。
SQL> alter database open;

稍作等待,就会发现备库的状态为READ ONLY WITH APPLY.

SQL> select open_mode from v$database;
OPEN_MODE
----------------------------------------
READ ONLY WITH APPLY

这个时候DG Broker校验就没有问题了,这就达到了我们的预期目标。
DGMGRL> DGMGRL> show configuration;
Configuration - dg_newtest2
  Protection Mode: MaxPerformance
  Databases:
    newtest2  - Primary database
    snewtest2 - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
这个过程让我对闪回的强大功能又有了新的认识和了解,希望在一些极端场景中依然能够帮助到你们。
目录
相关文章
|
弹性计算 网络协议 容灾
PostgreSQL 时间点恢复(PITR)在异步流复制主从模式下,如何避免主备切换后PITR恢复(备库、容灾节点、只读节点)走错时间线(timeline , history , partial , restore_command , recovery.conf)
标签 PostgreSQL , 恢复 , 时间点恢复 , PITR , restore_command , recovery.conf , partial , history , 任意时间点恢复 , timeline , 时间线 背景 政治正确非常重要,对于数据库来说亦如此,一个基于流复制的HA架构的集群,如果还有一堆只读节点,当HA集群发生了主备切换后,这些只读节点能否与新的主节点保持
1653 0
|
4月前
|
关系型数据库 数据库 PostgreSQL
postgresql|数据库|恢复备份的时候报错:pg_restore: implied data-only restore的处理方案
postgresql|数据库|恢复备份的时候报错:pg_restore: implied data-only restore的处理方案
61 0
|
SQL 监控 关系型数据库
Data Guard高级玩法:通过闪回恢复failover备库
    今天看到有一个网友提了一个问题,描述很简短     测试DG时,主库不能宕机,如何测试failover?     其实这个需求从业务层面来说是合理的,一个数据量很大的核心数据库,如果需要做灾难演练,就希望在备库上做一下演练工作,而这个演练其实又不想影响到目前的主库,而且又希望能够尽可能模拟真实的情况,我想这样对于运维部门来说是最具有考核力度,而对于开发业务部门来说是最受欢迎的,因为他们什么都不需要改动。
1086 0
|
Oracle 关系型数据库 测试技术
Oracle 数据库重放(Database Replay)功能演示
https://www.cnblogs.com/jyzhao/p/5072800.html 我们可以捕获生产环境的工作量,在测试环境上重放,从而在不影响生产环境的前提下做一些改动测试。捕获:需要Oracle版本为10.2.0.4或更高.重放:需要Oracle版本为11g Release 1或更新. 本文环境:RHEL6.4 + Oracle 11.2.0.4下面介绍一下执行Database Replay的Workflow。
1251 0
|
关系型数据库 MySQL 数据库
MySQL案例-初步恢复: alter引起的从库无限Crash
-------------------------------------------------------------------------------------------------正文-----------------------------------...
1727 0