Previous Topic: Stop a Recovering DSA Sending Out-of-date Information to a Client

Next Topic: Manually Resynchronize a DSA in a Multiwrite System

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.

    The recovery process - Step A

  2. Data DSA 2 goes offline.

    The recovery process - Step B

    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:

    The recovery process - Step C

    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.


Copyright © 2009 CA. All rights reserved. Email CA about this topic