Oracle的Data Guard技术再11g中有了Active Data Guard，就产生了很多的技术解决方案，比如读写分离，多活的技术支撑等。
12c 中又有了一些改进，那就当属Far Sync。以下是来自官网提供的一张图，看起来很威武霸气。
这个Far Sync到底是个什么东东，主要就是为了解决远距离的数据传输延迟，而在中间节点创建的一个虚实例，这个实例很特别，只有参数文件，密码问价和控制文件，而且需要特别强调的是没有数据文件。
当然这个特性是一个补充，你如果使用原本的Active Data Guard也全然没有问题。而这个特性可以通过中间节点来过渡，达到了官方所宣称的0数据丢失。
这个特性是不是非常牛叉呢，其实如果大家了解Data Guard的一些知识，会发现其实这个Far Sync就是cascade standby的一个改进，所以我没有说是一个技术上很大的一个创新。
如果已经有了Active Data Guard的环境，启用Far Sync那就很简单了。
下面是一个典型的DG配置情况，使用了DG Broker来统一配置管理。主库是testdb,备库是testdb2
DGMGRL> show configuration Configuration - dgb_testdb Protection Mode: MaxPerformance Members: testdb - Primary database testdb2 - Physical standby database Fast-Start Failover: DISABLED Configuration Status: DISABLED
需要特别强调的是，Far Sync的添加一个关键就是控制文件，这个和备库控制文件有所区别。如果你使用的是备库控制文件，那很可能添加的时候得到下面的错误。
DGMGRL> add far_sync testdbf as connect identifier is testdbf; Error: ORA-16831: operation not allowed on this member 查看错误信息，也是一头雾水，日志中也没有什么明显的信息。 [oracle@teststd ~]$ oerr ora 16831 16831, 00000, "operation not allowed on this member" // *Cause: The Oracle Data Guard broker operation was not allowed for the // specified member of the Oracle Data Guard broker configuration. // *Action: Check the documentation for the Oracle Data Guard broker command // and then reissue the command with the correct member.
我刚开始玩的时候大意了，结果因为这个问题给折腾了不少时间。需引以为戒。
正确的姿势是在主库生成Far Sync的控制文件：
SQL> ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE AS '/tmp/controlfs01.ctl1'; Database altered. 然后拷贝到备库还原即可。 备库执行: RMAN> restore controlfile from '/tmp/controlfs01.ctl1'; RMAN> alter database mount;
很重要的一个检查项就是检查v$database,输出全然不同
SQL> select database_role,name,db_unique_name from v$database DATABASE_ROLE NAME DB_UNIQUE_NAME ------------------------------ --------------------------- ----------- FAR SYNC TESTDB testdbf
这样就对了，我们再次在主库添加：
添加Far Sync节点： DGMGRL> add far_sync TESTDBF as connect identifier is TESTDBF; far sync instance "testdbf" added 启用配置 DGMGRL> enable far_sync TESTDBF; Enabled. 查看配置情况: DGMGRL> DGMGRL> show configuration; Configuration - dgb_testdb Protection Mode: MaxPerformance Members: testdb - Primary database testdb2 - Physical standby database testdbf - Far sync instance Fast-Start Failover: DISABLED Configuration Status: SUCCESS (status updated 5 seconds ago)
Far Sync的节点就这样搞定了。其实就是中间走了一层转接，而对于Far Sync而言，使用DG Broker搭建就是两条简单的命令即可。其实在后台日志中是设置归档路径参数：
Sat Oct 29 23:21:23 2016 ALTER SYSTEM SET log_archive_dest_3='service="testdbf"','ASYNC NOAFFIRM delay=0 optional compression=disable max_failure=0 max_connections=1 reopen=300 db_unique_name="testdbf" net_timeout=30','valid_for=(online_logfile,all_roles)' SCOPE=BOTH; Sat Oct 29 23:21:23 2016 ALTER SYSTEM SET log_archive_dest_state_3='ENABLE' SCOPE=BOTH;
所以核心的部分就在于这儿，还有一个地方是Far Sync节点，Fal_server的设置
FAR SYNC节点： SQL> show parameter fal NAME TYPE VALUE ------------------------------------ ---------- ----------- fal_client string fal_server string testdb, testdb2
我们可以简单测试一下Far Sync的影响范围：
直接shutdown abort Far Sync节点，主库会马上收到一条错误信息:
Sat Oct 29 23:29:18 2016 Errors in file /home/U01/app/oracle/diag/rdbms/testdb/testdb/trace/testdb_tt02_8451.trc: ORA-03135: connection lost contact
这个时候测试节点的日志传输还是可以的，当然远距离还是会把影响放大。
而在Far Sync节点恢复之后，主库日志会发生变化：
ERROR: Shared memory area is accessible to instance startup process prior to instance startup operation. Sat Oct 29 23:32:17 2016 ALTER SYSTEM SET log_archive_dest_state_3='ENABLE' SCOPE=MEMORY SID='*';
再次查看DG Broker的配置就没有问题了。
DGMGRL> show configuration; Configuration - dgb_testdb Protection Mode: MaxPerformance Members: testdb - Primary database testdb2 - Physical standby database testdbf - Far sync instance Fast-Start Failover: DISABLED Configuration Status: SUCCESS (status updated 41 seconds ago)
这个测试的过程还是比较流畅的，还有更多的细节，后续继续分享。
