Active Data Guard + Far Sync 系列文章:
- https://www.modb.pro/db/1988949045378359296
- https://www.modb.pro/db/1995863531225948160
- https://www.modb.pro/db/1997649025219256320
同步异步模式
01.使用LGWR 进程的SYNC 方式
1）Primary Database 产生的Redo 日志要同时写到日志文件和网络。也就是说LGWR进程把日志写到本地日志文件的同时还要发送给本地的LNSn进程（Network Server Process），再由LNSn（LGWR Network Server process）进程把日志通过网络发送给远程的目的地，每个远程目的地对应一个LNS进程，多个LNS进程能够并行工作。
2）LGWR 必须等待写入本地日志文件操作和通过LNSn进程的网络传送都成功，Primary Database 上的事务才能提交，这也是SYNC的含义所在。
3）Standby Database的RFS进程把接收到的日志写入到Standby Redo Log日志中。
4）Primary Database的日志切换也会触发Standby Database 上的日志切换，即Standby Database 对Standby Redo Log的归档，然后触发Standby Database 的MRP或者LSP 进程恢复归档日志。
因为Primary Database 的Redo 是实时传递的，于是Standby Database 端可以使用两种恢复方法：
- 实时恢复（Real-Time Apply）： 只要RFS把日志写入Standby Redo Log 就会立即进行恢复；
- 归档恢复： 在完成对Standby Redo Log 归档才触发恢复。
Primary Database默认使用ARCH进程，如果使用LGWR进程必须明确指定。使用LGWR SYNC方式时，可以同时使用NET_TIMEOUT参数，这个参数单位是秒，代表如果多长时间内网络发送没有响应，LGWR 进程会抛出错误。 示例如下：
alter system set log_archive_dest_2 = 'SERVICE=ST LGWR SYNC NET_TIMEOUT=30' scope=both;
02.使用LGWR进程的ASYNC 方式
使用LGWR SYNC方法的可能问题在于，如果日志发送给Standby Database过程失败，LGWR进程就会报错。也就是说Primary Database的LGWR 进程依赖于网络状况，有时这种要求可能过于苛刻，这时就可以使用LGWR ASYNC方式。 它的工作机制如下：
1） Primary Database 一端产生Redo 日志后，LGWR 把日志同时提交给日志文件和本地LNS 进程，但是LGWR进程只需成功写入日志文件就可以，不必等待LNSn进程的网络传送成功。
2） LNSn进程异步地把日志内容发送到Standby Database。多个LNSn进程可以并发发送。
3） Primary Database的Online Redo Log 写满后发生Log Switch，触发归档操作，也触发Standby Database对Standby Database对Standby Redo Log 的归档；然后触发MRP或者LSP 进程恢复归档日志。
因为LGWR进程不会等待LNSn进程的响应结果，所以配置LGWR ASYNC方式时不需要NET_TIMEOUT参数。示例如下：
alter system set log_archive_dest_2 = 'SERVICE=ST LGWR ASYNC ' scope=both;
理解DG三大保护模式
| Maximum Availability | Maximum Performance | Maximum Protection |
|---|---|---|
| AFFIRM | NOAFFIRM | AFFIRM |
| SYNC | ASYNC | SYNC |
-
最大可用性模式（Maximum Availability）
1）该模式提供了仅次于“最大保护模式”的数据保护能力；
2）要求至少一个物理备库收到重做日志后，主库的事务才能够提交；
3）主库找不到合适的备库写入时，主库不会关闭，而是临时降低到“最大性能模式”模式，直到问题得到处理；
4）优点：该模式可以在没有问题出现的情况下，保证备库没有数据丢失，是一种折中的方法；
5）缺点：在正常运行的过程中缺点是主库的性能受到诸多因素的影响。 -
最大性能模式（Maximum Performance）
1）该模式是默认模式，可以保证主数据库的最高可用性；
2）保证主库运行过程中不受备库的影响，主库事务正常提交，不因备库的任何问题影响到主库的运行；
3）优点：避免了备库对主数据库的性能和可用性影响；
4）缺点：如果与主库提交的事务相关的恢复数据没有发送到备库，这些事务数据将被丢失，不能保证数据无损失。 -
最大保护模式（Maximum Protection）
1）这种模式提供了最高级别的数据保护能力；
2）要求至少一个物理备库收到重做日志后，主库的事务才能够提交；
3）主库找不到合适的备库写入时，主库会自动关闭，防止未受保护的数据出现；
4）优点：该模式可以保证备库没有数据丢失；
5）缺点：主库的自动关闭会影响到主库的可用性，同时需要备库恢复后才能提交，对网络等客观条件要求非常的高，主库的性能会因此受到非常大的冲击。
Active Data Guard Far Sync 概述
Data Guard是oracle数据库容灾非常合适的解决方案，并且随着oracle产品的迭代不断进化完善。Active Data Guard Far Sync是Oracle 12c引入的新功能（也称为Far Sync Standby）。
传统的ADG主要由主备库组成，redo数据直接传输到备库，待备库成功写入standbylog file才能保证数据的最大保护。如果主备库之间的网络带宽不足、备库性能较差等因素，不可避免会导致主备库之间的同步延迟，此时一旦出现主库宕机的情况，极易出现数据丢失。12c开始可以在主备库之间添加一个Far Sync实例,redo数据先由主库传输到Far Sync实例，再由于Far Sync实例转发给备库。Far Sync实例只有密码文件、init参数文件和控制文件，而没有数据文件，只负责接收归档和redo而不需要应用，所以主库到Far Sync实例的同步非常迅速，基本没有延迟。
一般Far Sync实例与主库就近部署，主库可以配置同步(synchronous)传输redo到Far Sync实例，保证零数据丢失（zero data loss）。然后Far Sync实例再将redo异步(asynchronous)发送到终端备库(Standby Database)。
Far Sync配置对于Data Guard 角色转换(role transitions)是透明的，即switchover/failover命令方式与12c之前相同。
考虑到可能发生Data Guard 角色转换，即switchover/failover，可以在距离备库较近的地方也配置Far Sync实例，这个Far Sync实例只有在当前的备库切换为主库后才启用。
考虑到Far Sync实例的单点故障，可以在距离主库交近的地点配置2个Far Sync实例，起到备用的作用。
以上是借用网上的一张Active Data Guard Far Sync架构图，图中没有画出备库端的Far Sync实例。
Far Sync的相关参数和用例
GROUP和PRIORITY
- 为日志传输路径分配group
GROUP (12cR2引入)可以使的备用远程传输路径的目标数量增加。GROUP之间相互独立，互不干扰。GROUP可用于从far sync实例或级联将redo分发到多个目标的多个归档目标，GROUP的数量可以设置1到8。每个GROUP可最多配置30个目标。
如果要为日志传输路径分配group，则需要组内的至少一个目的地为可用并为活动状态。组中最多可以存储30个日志存档目标，而且只能为远程日志传输路径（SERVICE = …）分配组，不能为本地日志传输路径（LOCATION = …）分配组。同时当一个组中存在多个日志传输路径时，必须把其他备用的日志传输路径状态LOG_ARCHIVE_DEST_STATE_n改为 ALTERNATE。
如下例子中，LOG_ARCHIVE_DEST_2和LOG_ARCHIVE_DEST_3组成一个group.当LOG_ARCHIVE_DEST_2失效时候，系统会自动切换到LOG_ARCHIVE_DEST_3进行日志远程归档，ALTERNATE即为备用的意思。
当LOG_ARCHIVE_DEST_2再次变为可用时，不会立即切换到LOG_ARCHIVE_DEST_2（因为没有指定PRIORITY), 除非后面LOG_ARCHIVE_DEST_3出现不可用。
2）在相同组内，为多个归档目标分配优先级PRIORITY
PRIORITY这个属性可以对相同GROUP中的目标进行优先级排序，以便同个GROUP里只能有一个目标位置处于活动状态。如果活动目的地不可用，其他目的地可用于后续激活并接替不可用的日志传输路径。优先级也是设置1-8 （1优先级最高）。
如下例子，LOG_ARCHIVE_DEST_2将为当前首选的日志归档目标，如果2不可用，将会切换到4（因为4的优先级高过3）。如果2再次可用，2只会作为4的备用目标而不会立马切换回2（因为2和4的优先级相同）。如果2与4都不可用，将会切换到3，后面2或者4任一可用了，会自动切换回其中一个。
一般同个group中redo只传输到ENABLE的LOG_ARCHIVE_DEST_STATE_n中。如果当前首选的日志归档目标不可用，我们可以通过配置相同的PRIORITY=8来实现多个日志归档目标，通用用于同步到多个目标备库。
常用的场景配置
1）单个Far Sync 实例 → 单个standby
首先主数据库把redo传输到Far Sync 实例，SYNC与AFFIRM模式保证数据的完整性。在LOG_ARCHIVE_DEST_2不可用情况下，主数据库直接把redo传输到standby备库，同时改成异步方式。当Far Sync 实例恢复后，再自动切换回LOG_ARCHIVE_DEST_2继续使用Far Sync 实例。
2）单个Far Sync 实例 → 多个standby
首先主数据库把redo传输到Far Sync 实例。在LOG_ARCHIVE_DEST_2不可用情况下，主数据库直接把redo同时传输到standby和standby1。
当Far Sync 实例恢复后，再自动切换回LOG_ARCHIVE_DEST_2继续使用Far Sync 实例。
3）多个 Far Sync 实例 → 单个standby
这个又叫做Far Sync 实例的高可用，在靠近primary的环节中部署多个Far Sync 实例，在其中一个Far Sync 实例不可用的时候不会马上切换到standby进行传输日志，更是切换到第二个Far Sync 实例。
首先主数据库把redo传输到primaryfs 这个Far Sync 实例，当primaryfs 这个Far Sync 实例不可用的时候，自动切换到primaryfs1 这个Far Sync 实例，当两个Far Sync 实例都不可用情况下，才直接把redo传输到standby。
4）多个Far Sync 实例 → 多个standby
首先主数据库把redo传输到primaryfs 这个Far Sync 实例，当primaryfs 这个Far Sync 实例不可用的时候，自动切换到primaryfs1 这个Far Sync 实例，当两个Far Sync 实例都不可用情况下，直接把redo同时传输到standby和standby1。
当任何一个Far Sync 实例恢复后，再自动切换继续使用Far Sync 实例。
Far Sync是oracle Dataguard的再次进化和完善，很好地解决了普通ADG最大保护影响发生，其他保护模式无法做到零丢失的问题。同时利用新增group和PRIORITY，可以更加灵活地配置和管理日志归档目标，定制各类故障场景下的日志传输目标和传输机制。
https://www.cnblogs.com/missyou-shiyh/p/18040722
https://www.cnblogs.com/kingle-study/p/10675650.html
