一 具体流程
1 Primary Database的LGWR或者ARCH进程负责将日志源源不断的传送到DG上
2 Standby Database端的RFS进程把接收的日志写入到归档(ARCH)/在线重做日志(LGWR)
3 Standby Database端的MRP(Managed Recovery Process)进程（Redo Apply）或者LSP 进程（SQL Apply）在Standby Database上应用这些日志，进而同步数据
二 日志传输模式
ARCH 只有在主库在线日志发生切换归档后 生成归档日志,才会进行传输给从库 传输的目标是归档日志 这样做的风险是有可能丢失在线重做日志
LGWR 传输的目标是在线重做日志 分为 rsync(同步) 和 async(异步) 由LGWR负责日志传输到DG上 可以尽量减少数据的丢失风险
1 sync 同步 LGWR 确保 本地日志文件和通过LNSn进程的网络传送都成功,Primary Database上的事务才能提交，Standby Database的RFS进程把接收到的日志写入到 Standby Redo Log日志中
我们一定程度上可以理解称为5.7mysql的半同步复制,确保redo写入从库才会在主库进行事务提交
2 rsync 同步
1） Primary Database 一段产生Redo 日志后，LGWR 把日志同时提交给日志文件和本地LNS 进程，但是LGWR进程只需成功写入日志文件就可以，不必等待LNSn进程的网络传送成功。
2） LNSn进程异步地把日志内容发送到Standby Database。多个LNSn进程可以并发发送。
3） Primary Database的Online Redo Log 写满后发生Log Switch触发归档操作，也触发Standby Database对Standby Redo Log 的归档；然后触发MRP或者LSP 进程恢复归档日志
我们可以理解成为5.6版本的半同步复制,只触发redo的网络传输动作 然后就会进行事务提交
三 总结
1 推荐使用 LGWR+ASYNC 方式 DG开启实时应用恢复
2 我们通常使用的都是物理DG , 逻辑DG已经用OGG代替,作为实时同步转换的工具
四 恢复
实时应用（Real-Time Apply）， 这种方式必须Standby Redo Log，每当日志被写入Standby Redo Log时，就会触发恢复，使用这种方式的好处在与可以减少数据库切换（Switchover 或者Failover）的时间，因为切换时间主要用在剩余日志的恢复上。
归档时应用，这种方式在Primary Database发生日志切换，触发Standby Database 归档操作，归档完成后触发恢复。 这也是默认的恢复方式。