Ensure Zero Data Loss at any Distance by using Oracle Data Guard Far Sync

Introduction

Oracle Data Guard enables you to transport the redo to the standby database synchronously to ensure zero data loss. However, when the standby database is geographically too far, the latency becomes higher, impacting the commit response time and the transaction throughput at the primary database. Oracle Active Data Guard Far Sync can ensure zero data loss at any distance without impacting the primary database performance. The Far Sync instance (a lightweight Oracle instance) provides the ability to perform a zero data loss failover to a remote standby database without creating and managing a second standby database.

Data Guard Environment

In the following example, the Data Guard configuration consists of a primary database running in the OCI Ashburn region (Ashburn_ad1) and a standby database running in the OCI London region (London_ad1). Maximum Performance Mode with asynchronous replication is being used to not impact the application performance by the high network latency between Ashburn and London.

The Data Guard broker’s RedoRoutes property looks like follows for this configuration:

[oracle@hostiad ~]$ dgmgrl SYS as sysdba

DGMGRL> EDIT DATABASE 'Ashburn_ad1' SET PROPERTY RedoRoutes = '( LOCAL : London_ad1 ASYNC)';
Property "redoroutes" updated

DGMGRL> EDIT DATABASE 'London_ad1' SET PROPERTY RedoRoutes = '( LOCAL : Ashburn_ad1 ASYNC )';
Property "redoroutes" updated

Check the configuration:

[oracle@hostiad ~]$ dgmgrl SYS as sysdba
DGMGRL> show configuration

Configuration - Ashburn_ad1_London_ad1

  Protection Mode: MaxPerformance
  Members:
  Ashburn_ad1    - Primary database
    London_ad1     - Physical standby database

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 57 seconds ago)

Adding a Far Sync Instance

To use synchronous replication in Maximum Availability mode and ensure zero data loss without impacting application performance, a Far Sync instance (FS1) is added to the configuration. The primary database sends redo to the geographically close Far Sync instance with low network latency, while the Far Sync instance forwards the redo asynchronously to the standby.

The Data Guard broker’s RedoRoutes property looks like follows for this configuration:

[oracle@hostiad ~]$ dgmgrl SYS as sysdba

DGMGRL> EDIT DATABASE 'Ashburn_ad1' SET PROPERTY RedoRoutes = '( LOCAL : ( FS1 FASTSYNC PRIORITY=1, London_ad1 ASYNC PRIORITY=2 ))';
Property "redoroutes" updated

DGMGRL> EDIT FAR_SYNC 'FS1' SET PROPERTY RedoRoutes = '( Ashburn_ad1 : London_ad1 ASYNC )';
Property "redoroutes" updated

DGMGRL> EDIT DATABASE 'London_ad1' SET PROPERTY RedoRoutes = '( LOCAL : Ashburn_ad1 ASYNC )';
Property "redoroutes" updated

Check the configuration:

DGMGRL> show configuration

Configuration - Ashburn_ad1_London_ad1

  Protection Mode: MaxAvailability
  Members:
  Ashburn_ad1    - Primary database
    fs1            - Far sync instance
      London_ad1     - Physical standby database

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 57 seconds ago)

Far Sync Instance in the Remote Region

After a role switch with the previous configuration, the new primary in London will send redo to Ashburn asynchronously:

To ensure zero data loss after a role switch, you need to add a Far Sync instance (FS2) in the London region too. The new primary in London sends redo synchronously to the geographically close Far Sync instance, which forwards the redo asynchronously to Ashburn:

This is achieved by modifying the RedoRoutes as follows:

DGMGRL> EDIT DATABASE 'London_ad1' SET PROPERTY RedoRoutes = '( LOCAL : ( FS2 FASTSYNC PRIORITY=1, Ashburn_ad1 ASYNC PRIORITY=2 ))';
Property "redoroutes" updated

DGMGRL> EDIT FAR_SYNC 'FS2' SET PROPERTY RedoRoutes = '( London_ad1 : Ashburn_ad1 ASYNC )';
Property "redoroutes" updated

Far Sync Instance Location

The Far Sync instance should be separated from the primary database to ensure they can’t be affected by the same failure or disaster, but still close enough to the primary to ensure low latency and high application performance.

The primary, standby, and Far Sync instances can be deployed anywhere: on-premises, Oracle Cloud, Non-Oracle Clouds, Hybrid Cloud, or Multicloud environments.

In a Cloud scenario in regions with multiple data centers (Availability Domains/Zones) for example, the Far Sync instance could be deployed in a different data center than the primary.

Considerations

  • Far Sync is a very lightweight instance. However, disk performance is critical as the Far Sync instance writes the received redo to disk before acknowledging back to the primary, which impacts the application performance.
  • Create two Far Sync instances per region for Far Sync instance High Availability.
  • The Far Sync feature requires the Active Data Guard option license.

Conclusion

Far Sync receives redo from the primary database synchronously and forwards it to the standby database asynchronously, ensuring zero data loss even if the standby database is at a far distance from the primary without affecting application performance. Create an additional Far Sync instance in the remote region to ensure a symmetric configuration after a role switch.

Further Reading

Would you like to get notified when the next post is published?