mysql 中的主备会经常碰到主库和备库日志传输延迟,其中一个role突然宕机,这时候会发生什么?
最近刚好在生产环境中碰到切换物理DG的需求,参照学习,准备研究一下oracle中主备切换时日志未及时应用,oracle怎么处置!
1.redo日志同步传输:
事务会等到redo日志传输到所有可以到达的备库之后再提交。这种一般是在最大保护性和最大可用性模式下使用。(NET_TIMEOUT表明LGWR将被阻塞多久为了等待备库的回应,如果redo日志被成功接收的消息一直没有回传至主库,日志传输将中断,error会被写入日志。)
redo异步传输:
不用等到事务产生的所有日志全部传输至备库,主库事务就可以提交了。这种一般是在最大性能的模式下使用。
2.AFFIRM:这个参数表示 主库传输的日志状态一直等到redo写入standby log file才会的到确认。NOAFFIRM:该参数则表示redo已经被接受的消息不用等到其写入standby log file才会得到确认,会在之前就被确认。
3.LOG_ARCHIVE_DEST_STATE_n 该值为enable的时候,日志传输服务则会将redo日志传输至LOG_ARCHIVE_DEST_n这个路径下。
DEFFR:日志传输服务不会传输redo至该路径下。
ALTERNATE:当和该路径关联的路径不可用时,这个路径会成为enable状态。
4.standby relo logfile是用来储存从其他数据库中接收到的redo日志的。
5.备库接收到的日志直接写入归档日志文件,这个时候可能是因为备库上的重做日志组不可用,或者是为了解决redo gap。
6.redo gap如何解决?
如果是由于日志传输中断导致的gap,当日志传输重新开启的时候,gap会被自动填充。
在某些场景下,gap需要手动填充,比如在逻辑DG的场景中,主库连接不了的时候。
1>SQL> SELECT * FROM V$ARCHIVE_GAP;
可以查看gap的日志情况
2>SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND SEQUENCE# BETWEEN x1 AND x2;
在主库上找出对应的归档日志所在的路径
3>SQL> ALTER DATABASE REGISTER LOGFILE '/physical_standby1/thread1_dest/arcr_1_7.arc';
SQL> ALTER DATABASE REGISTER LOGFILE '/physical_standby1/thread1_dest/arcr_1_8.arc';
SQL> ALTER DATABASE REGISTER LOGFILE '/physical_standby1/thread1_dest/arcr_1_9.arc';
将归档日志传送至备库,并注册。
7.日志应用服务
物理备库中,一般redo日志会在其被归档之后应用,也有实时应用的。
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE
该sql表示的是前台进程应用日志:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
该sql表示的是后台进程应用日志:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
该sql表示开启实时应用redo日志:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;
停止应用日志:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/30018455/viewspace-2124618/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/30018455/viewspace-2124618/