Disaster Recovery

FastSync or Far Sync? FastSync AND Far Sync!

Introduction

FastSync and Far Sync seem to be very similar terms, especially in the spoken language. In my conversations, I have seen these terms being mixed up and even questions about using one OR the other. Indeed, FastSync and Far Sync are two different things that can be used independently or make perfect sense to be used together in specific configurations.

This blog post briefly explains these terms, their benefits, and how to use them. The credits for the nice architectural diagrams go to my dear colleague Ludovico Caldara.

Protection Modes

Oracle Data Guard provides three different protection modes:

Maximum Performance

When the application commits a transaction, the redo is written to the online redo logs, and the commit acknowledgment is sent back to the application. Redo is then transmitted to the standby database asynchronously (ASYNC). The primary database performance is unaffected by the time required to transmit redo data and receive an acknowledgment from a standby database.

Maximum Protection

When the application commits a transaction, the redo is written to the online redo logs, transmitted to the standby database synchronously, and written to the standby redo logs (disk I/O on standby) (SYNC). Finally, the commit acknowledgment is sent back to the application.

So, after a commit, the application waits until the redo is transferred (latency) and written to disk (I/O) on standby. It provides the maximum data protection but might impact performance depending on the distance (latency) between the primary and standby and the I/O disk performance on the standby. The I/O time usually makes up a bigger portion of that wait time.

This protection mode ensures that your data is ALWAYS replicated to a standby database. If the primary is unable to receive an acknowledgment from the standby database, then it will not continue processing and shut down. This is why Oracle recommends a minimum of two standby databases in maximum protection mode. This prevents a single standby database failure from causing the primary database to shut down.

Maximum Availability

When the application commits a transaction, redo is written to the online redo logs, transmitted to the standby database synchronously, then:

  • Redo is written to the standby redo logs (disk I/O on standby) (SYNC), and then the commit acknowledgment is sent back to the application. Or,
  • Redo is received at the standby database – without waiting for disk I/O to standby redo logs (FastSync), and then the commit acknowledgment is sent back to the application. So, FastSync is fast. At least faster than SYNC, as it does not wait for disk I/O. The redo transport attributes for FastSync are SYNC/NOAFFIRM. If the primary fails and the standby loses power simultaneously, then the redo that is not yet written to disk on standby will be lost.

If the primary cannot receive an acknowledgment from the standby database, it will continue processing as if it were in maximum performance mode. This preserves the availability of the primary database until it is again able to write its redo to a synchronized standby database.

Far Sync

A Far Sync instance is a remote Data Guard destination that accepts redo from the primary database and then ships that redo to other members of the Oracle Data Guard configuration. Far Sync is a lightweight instance that consumes very few disks and processing resources. It requires the Active Data Guard option on the database nodes.

Benefits of Far Sync:

Far Sync instances can benefit Oracle Data Guard configurations in different ways:

  • In maximum availability mode (SYNC or FastSync), the Far Sync instance is close to the primary database to benefit from low latency and low commit response times for synchronous replication. Far Sync forwards the redo asynchronously to the much farther standby(s). If the primary database fails, the standby will fetch the very last redo from the Far Sync instance upon failover ensuring zero data loss.
  • In maximum performance mode (ASYNC), the Far Sync instance can be at any distance from the primary because asynchronous redo transport does not impact the performance at the primary. However, when using many remote standby databases, the overhead of the redo transport might become measurable. This is offloaded to the Far Sync instance. Adding even more standbys will have zero effect on the primary.
  • Additionally, redo transport compression and encrypting can be offloaded to the Far Sync instance freeing more resources on the primary database server.

Similarities to a standby database:

  • Far Sync manages a control file, receives redo into standby redo logs (SRLs), and archives those SRLs to local archived redo logs.

Differences from a standby database:

  • Far Sync has no user data files, cannot be opened for access, and cannot run redo apply.
  • It can never function in the primary role or be converted to any type of standby database.
  • It is supported in either maximum performance or maximum availability mode but not in maximum protection mode.

FastSync and Far Sync

Using synchronous replication to a remote standby database might impact performance. Asynchronous replication does not ensure zero data loss if the primary fails. A Far Sync instance close to the primary that receives redo in SYNC or FastSync mode provides both benefits:

  • High performance as the latency is low to the primary database. FastSync further reduces the round trip time by not waiting for the redo to be written to disk.
  • Zero data loss if the primary fails, as the standby will fetch the latest redo from the Far Sync instance after failover.

So, the combination of FastSync and Far Sync makes perfect sense.

Conclusion

FastSync is a redo transport mode used in maximum availability protection mode. It ensures that redo is transmitted synchronously to the standby site and acknowledgment is sent when it is received without waiting for the disk I/O on the standby. This reduces the round trip time and minimizes the performance impact on the primary.

A Far Sync instance is a remote destination that receives the redo from the primary and forwards it to one or multiple standbys.

A typical configuration to ensure data loss without impacting performance when the standby is too far away from the primary is to send the redo in FastSync mode to a Far Sync instance, which forwards the redo asynchronously to the remote standby.

Further Reading

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