What is Far Sync Instance or FAR Sync Standby in Oracle ?
The FAR Sync Instance or Far Sync Standby is a new feature of Oracle 12c. It is a remote standby instance which receives redo from Primary database and ships to other standby destinations. It is just like any other Data Guard archive destination configured for SYNC transport. A FAR sync instance does not have data files, it cannot be opened for access, cannot apply logs, and can never function in the primary role or be converted to any type of standby database i.e. active dataguard or snapshot standby. Only Log Transport Services are active on a Far Sync Standby Database. It has only FAR sync control file, pfile/spfile, password file, SRLs(Standby Redo Log Files), and archived log files.
A FAR sync instance receives redo into standby redo logs (SRLs), and archives those SRLs to local archived redo logs on FAR Sync Server. The FAR Sync instance is created because of the geographical latency issues when performing synchronous redo transport. Most of the customers use ASYNC mode to ship redo from a primary database to standby database, but this causes some data loss at failover time.
For example, your primary server is located in one location and your standby destination is located on any other remote destination which is in hundreds or thousands of miles or in any geographical area. If anything goes wrong at Primary site, then there can be data loss due to network latency issues between primary and standby databases. Using SYNC redo transport mode to achieve zero data loss may not be a feasible option due to network latency between primary and standby databases because of the impact on the commit response times at the primary site. Here, the FAR Sync instance concept comes where FAR Sync instance can be created at Primary Site in SYNC mode where Primary is located (Refer above diagram) so that logs will get shipped immediately to FAR sync and then that destination can be further cascaded to actual standby database from FAR Sync server. i.e. Primary---> FAR Sync ---> Standby
How the above configuration will work if Primary gets terminated or not available?
Let's say If the primary database has failed and assume that the far sync instance was synchronized at the time of the primary failure, then the FAR sync instance and the actual standby instance will coordinate a final redo shipment from the FAR sync instance to the standby to ship any redo not yet available to the standby and then perform a zero-data-loss failover. This enables zero data loss failover for all cases, except for a disaster outage of both the primary and the Far Sync instance at the same time.
What are the Advantages of FAR Sync instance?
- Creating a far sync instance close to the primary has the benefit of minimizing impact on commit response time due to the smaller network latency between primary and FAR sync instance which allows higher data protection.
- A far sync instance consumes very little disk space and server resources since it doesn't have any data files.
- It provides the ability to failover to a standby destination with zero data loss.
What is the workaround if in case both Primary and FAR Sync instances get terminated or not available at the same time?
We must configure alternate redo transport destinations to the standby databases using the GROUP and PRIORITY attributes of the LOG_ARCHIVE_DEST_n parameter. As of Oracle Database 12c Release 2 (12.2.0.1), the GROUP and PRIORITY attributes have replaced the ALTERNATE attribute for remote redo destinations.
A log archive destination group specifies multiple archive destinations that can be used to distribute redo to multiple destinations, either from a far sync instance or through cascading. The destinations in the group can then be prioritized so that only one destination is active at a time on the primary database and other destinations are available to become active if the active destination becomes unavailable. There can be up to 30 log archive destinations in a group. Log archive destination groups are referenced by their group number, which is assigned when the group is created. Groups are numbered from 1 through 8.
Prerequisites to check before creating FAR Sync Instance:
- The network between the primary database and far sync instance must have round trip latency low enough( i.e. < 5 ms).
- Provide enough bandwidth between the primary database and FAR sync instance. We can use Redo transport compression to reduce network bandwidth.
- Use redundant network links to avoid network component failures.
- Set TCP send and receive buffer sizes equal to three times the bandwidth delay product.
- A FAR Sync instance’s standby redo logs (SRLs) should be placed on storage with sufficient IOPS i.e. "writes per second" capacity to exceed the I/O of the LGWR process on the primary database.
- The Far Sync instance’s standby redo logs (SRLs) should have the same number of redo log groups as on the primary +1 for each thread.
- Configure FAR Sync instances for both the primary and standby databases to allow for zero data loss protection to be maintained before/after role transitions.
- Set Primary Database in Maximum Availability Mode where the Physical or Logical Standby Database can be on a FAR remote Site.
You can refer below link to create FAR Sync Instance step by step.
Thanks for reading this post ! Please comment if you like this post ! Click on FOLLOW to get next blog updates !
Thank you for your comment !