Asynchronous vs. Synchronous Replication
As discussed, disaster recovery requires having the application data available in the
disaster-recovery location. This either requires the data to be stored somewhere that is
available to both locations, such as in the public cloud, or more commonly, it requires
the data to be stored in both locations and replication technologies to be used to keep
the replica copy of the data synchronized with the primary (live) copy of the data.
The mode of the replication can be either asynchronous or synchronous:
Asynchronous Mode This mode allows transactions to be committed on the
primary source before the transaction has been sent to the replicas or has been
acknowledged. The exact mechanism for asynchronous replication differs, but the
key point is that the primary source can continue working independently of the
replica receiving and acknowledging the data. This gives the best performance on
the primary replica (although there is always a slight risk of data loss in a failure
situation because data is committed on the primary before it’s committed or
potentially even sent to the replica).
Synchronous Mode This mode ensures that no transactions are committed on
the primary source until they are acknowledged on the replica. This ensures that
there is no risk of data loss, but this will incur some performance impact because
of the additional delay while waiting for the acknowledgments from the replica.
The higher the latency between the primary and the replica, the greater the
performance impact.
Nearly every type of cross-site replication leverages asynchronous as the
replication type because of the typical high latency between different locations and
the performance impact that synchronous replication across high-latency links
imposes. Synchronous replication is typically reserved within a datacenter for
highly critical data that cannot risk any kind of data loss.SQL Server is a good example of a workload that leverages both asynchronous and
synchronous replication with its Always On technology. Always On provides the
replication of SQL databases between a primary replica and one or more secondary
replicas. Within a datacenter, synchronous Always On replication may be used;
between locations, the asynchronous Always On replication is typically used. SQL
Always On allows switching between replication types, which opens up some
interesting failover solutions such as running in asynchronous normally but switching
to synchronous prior to failover to ensure no data loss.
Many storage solutions, such as SANs, offer replication at a storage level from one
SAN to another, and very high-end SANs can offer a synchronous replication
capability. This is typically expensive and is specific to the type of SAN used. The
benefit of using SAN-level replication where available is that a cluster can then use the
SAN storage in multiple locations as a single logical storage device, enabling clusters