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;