- FSFO(fast start failover 快速启动故障)
DG_broker已经配置完了,可是还是需要我们进行手动切换,如果我们想让数据库自动切换,那么还需要配置FSFO了。
- 启用闪回
FSFO 将闪回数据库用作将故障主数据库恢复为备用数据库流程的一部分,所以我们需要启用数据库的闪回功能:
开启闪回的步骤可参考:
Flashback Database 闪回数据库功能测试 - 雨花石的专栏 - 博客频道 - CSDN.NET http://blog.csdn.net/shiyu1157758655/article/details/55095760
主库和备库操作一样
设置闪回区的大小,这个大小要足够大,不然闪回区满了会导致数据库宕机
如果之前没有开启的话就,开启一下
一、将主从数据库都开启数据库闪回功能
1.1 从数据库在启用数据库闪回之前,需要关闭日志应用功能
|
DGMGRL> edit database 11gdg2 set state=APPLY-OFF; Succeeded. |
1.2 将从库启用数据库闪回
|
SQL> alter database flashback on; Database altered. |
1.3 开启从库日志应用功能
|
DGMGRL> edit database 11gdg2 set state=APPLY-ON; Succeeded. |
1.4 将主库开启数据库闪回功能
|
SQL> alter database flashback on; Database altered. |
来自 <http://lqding.blog.51cto.com/9123978/1682317>
启用了主备库的闪回功能后,我们就可以启动FSFO了,登录dgmgrl主机连接主库:
$ dgmgrl sys/oracle@ogg2
设置故障切换目标
Ogg2的故障转移目标为ruanjian,反过来也需要设置,可以反复的故障转移。
DGMGRL> edit database ogg2 set PROPERTY FastStartFailoverTarget='ruanjian';
Property "faststartfailovertarget" updated
DGMGRL> edit database ruanjian set PROPERTY FastStartFailoverTarget='ogg2';
Property "faststartfailovertarget" updated
DGMGRL> enable FAST_START FAILOVER
Enabled.
DGMGRL> show configuration;
Configuration - test
Protection Mode: MaxPerformance
Databases:
ogg2 - Primary database
Warning: ORA-16819: fast-start failover observer not started
ruanjian - (*) Physical standby database
Warning: ORA-16819: fast-start failover observer not started
Fast-Start Failover: ENABLED
Configuration Status:
WARNING
可是我们发现DGMGRL告警了,那是因为我们没有启动观察器(observer)的原因,那我们接下来就启动观察器吧!(由于observer的启动会一直占用session 窗口的,所以建议写成脚本挂后台)
登录dgmgrl主机执行以下命令:
编写脚本,内容如下
Vi observer.sh
nohup dgmgrl sys/oracle@ogg2 "start observer file=FSFO.dat" >>fsfo.log 2>&1 &
Chmod u+x observer.sh
./observer.sh
启动observer后,我们再看一下配置状态
DGMGRL> show configuration;
Configuration - test
Protection Mode: MaxPerformance
Databases:
ogg2 - Primary database
ruanjian - (*) Physical standby database
Fast-Start Failover: ENABLED
Configuration Status:
SUCCESS
注意:
DGMGRL> edit database ogg2 set property DelayMins=0;
DGMGRL> edit database ruanjian set property DelayMins=0;
这两个的值要为0,不能为1,否者导致主备不能实时同步,、
fast-start failover,observer都会出现wenti
使用show database verbose ogg2|ruanjian,查看配置中的参数DelayMins
这样我们的FSFO就配置完成了,下面我们模拟主库宕机后,FSFO的切换:
- 直接把主库ogg2的主机断电;
SQL> shutdown abort;
ORACLE instance shut down.
- 查看我们observer的日志:
13:09:42.83 Thursday, February 16, 2017
Initiating Fast-Start Failover to database "ruanjian"...
Performing failover NOW, please wait...
Failover succeeded, new primary is "ruanjian"
13:09:48.55 Thursday, February 16, 2017
将原主库启动
1 2 3 4 5 6 7 8 9 10 11 |
SQL> startup ORACLE instance started. Total System Global Area 839282688 bytes Fixed Size 2233000 bytes Variable Size 499125592 bytes Database Buffers 335544320 bytes Redo Buffers 2379776 bytes Database mounted. ORA-16649: possible failover to another database prevents this database from being opened
|
由Observer保护着,该库是不允许直接打开的。(后面的open将会有observer来后台进行)
我们看看Observer端的打印信息
13:11:39.93 Thursday, February 16, 2017 Initiating reinstatement for database "ogg2"... Reinstating database "ogg2", please wait... Operation requires shutdown of instance "ogg2" on database "ogg2" Shutting down instance "ogg2"... ORA-01109: database not open
Database dismounted. ORACLE instance shut down. Operation requires startup of instance "ogg2" on database "ogg2" Starting instance "ogg2"... ORACLE instance started. Database mounted. Continuing to reinstate database "ogg2" ... Reinstatement of database "ogg2" succeeded 13:12:31.72 Thursday, February 16, 2017
看到observer中的信息得知ogg2已经reinstatement,再次查看ogg2的状态 SQL> select open_mode,database_role,switchover_status from v$database;
OPEN_MODE DATABASE_ROLE SWITCHOVER_STATUS -------------------- ---------------- -------------------- READ ONLY WITH APPLY PHYSICAL STANDBY SWITCHOVER PENDING
|
|
解释一下FSFO故障自动切换的原理
主库修改的原理是什么呢? 我们查看一下主库的scn以及备库切换成主库时的scn
SQL> select to_char(standby_became_primary_scn) from v$database;
SQL>startup mount
SQL> flashback database to scn 9978113; //这个值为在新主库上查询到的SCN值
SQL> alter database convert to physical standby;
SQL> shutdown immediate
SQL> startup
SQL> alter database recover managed standby database using current logfile disconnect from session;