Administration Guide › Set Up Replication › Multiwrite Replication › How Multiwrite Replication Works › Recovery in Multiwrite › Multiwrite Replication with Multiwrite Recovery

Multiwrite Replication with Multiwrite Recovery

Multiwrite is based on the idea that the multiwrite DSAs are usually functioning and connected. If one of the DSAs in the region shuts down or becomes disconnected, any updates are queued in another DSA's memory until the offline DSA becomes available once more.

After the DSA puts the update request in a queue, it sends a confirmation to the client. In effect, multiwrite reverts to a write-behind scheme until the offline DSA becomes available.

Important! A queued update is stored in memory only, and is lost if the DSA holding the queue is restarted.

The following diagrams show how a DSA in simple multiwrite system recovers.

1. The system is functioning correctly.

   A single router DSA passes client requests to two data DSAs, which replicate all changes to each other.

   

2. Data DSA 2 goes offline.

   

   While DSA 2 is down, the following happens when the client application makes an update request:

   1. The router DSA passes the update request to DSA 1.
   2. DSA 1 makes the update to itself and queues the update for DSA 2.

      DSA 2 is now out-of-date.

3. DSA 2 comes online again, as follows:
   1. DSA 2 starts up in recovery mode, which means that it can receive binds only from its peer, DSA 1.
   2. DSA 1 sends updates from its queue, in the order that it queued them, to DSA 2, as follows:

   

   1. When the queue is empty, DSA 1 sends a notification to DSA 2 that the data is synchronized. This switches DSA 2 out of recovery mode, returning it to service.