Two-Way Replication

Two-way replication, sometimes called Back Replication, is a term used to describe a replication scenario where there are two instances of AMPS -- termed AMPS-A and AMPS-B for this example.

In a two-way replication configuration, messages that are published to AMPS-A are replicated to AMPS-B. Likewise, messages which are published to AMPS-B are replicated to AMPS-A. This replication scheme is used when both instances of AMPS need to be in sync with each other to handle a failover scenario with no loss of messages between them. This way, if AMPS-A should fail at any point, applications can immediately fail over to the AMPS-B instance, allowing message flow to resume with as little downtime as possible.

To enable two-way replication, each instance of AMPS defines a replication Transport to receive incoming replication messages. Each instance also defines a replication Destination to deliver messages to the other instance.

Notice that servers are intended to function as failover partners. Since a publisher may fail over between these two instances, the Destination on each instance that replicates to the other instance is configured to use sync message acknowledgment. This ensures that a publisher does not consider a message to be persisted until all of the failover partners have received and persisted the message.

When configuring a set of instances for failover, it is important that the instances use sync message acknowledgment among the set of instances that a given client will consider for failover. It should never be possible for a publisher to fail over from one instance to another instance if the replication link between those instances is configured for async acknowledgments.

Starting with the 5.0 release, when AMPS detects back replication between a pair of instances, AMPS will prefer using a single network connection between the servers, replicating messages in both directions (that is, to both destinations) over a single connection. This can be particularly useful for situations where you need to have messages replicated, but only one server can initiate a connection. For example, when one of the servers is in a DMZ, and cannot make a connection to a server within the company. AMPS also allows you to specify a replication destination with no InetAddr provided. In this case, the instance will replicate once the destination establishes a connection, but will not initiate a connection. When both instances specify an InetAddr, AMPS may temporarily create two connections between the instances while replication is being established. In this case, after detecting that there are two connections active, AMPS will close one of the network connections and allow both AMPS instances to use the remaining network connection to publish messages to the other instance. Notice that using a single network connection is simply an optimization to more efficiently use the available sockets. This does not change the way messages are replicated or the replication protocol, nor does it change the requirement that all messages in a journal are replicated to all destinations before a journal can be removed.