Chapter 2
Configuration Considerations
11
Choosing Between Synchronous and
Asynchronous Replication
In synchronous mode, a write operation is not confirmed as complete until the
remote volume has been updated. Generally, synchronous mirroring is limited to
relatively short distances (that is, tens of kilometers) because of the detrimental
effect of round-trip propagation delay on I/O response times. However, there are
applications such as web server replication that can tolerate relatively slow remote
updates and operate in a synchronous mode over long stretches.
With synchronous mirroring, the remote copy always matches the local host’s view
of committed writes. Should the local primary site be rendered inoperative, the
remote secondary copy can be used to continue operations after the user community
and the applications are switched to the alternate site.
What if the link goes down while running in synchronous mode? Should the local
I/O remain incomplete until the link comes back up? Some applications require that
the primary and secondary sites be exactly in sync and therefore would desire that
the I/O not complete. However, many mission-critical customers decide not to block
local access to the data upon encountering intersite transmission errors. Instead,
software keeps track of these writes at the primary site and then updates the
recovery site when the remote service is reliably restored. If configured this way,
disaster recovery procedures must take into account loss of in-flight and logged data.
That is, data might have been committed to the local application but never had a
chance to arrive at the backup site.
Asynchronous mirroring affirms primary I/O completion to the originating host
before updating the remote image. This type of mirroring is often used when the
distance and relatively low bandwidth telecommunications lines of 45 Mbps or less
between primary and secondary sites would introduce prohibitive latencies if
performed synchronously. Here, the long-distance pipe becomes the bottleneck,
forcing local writes to be queued for later transmission. Consequently, there is a
higher possibility of losing buffered and in-flight data if the primary system fails.
