Example: Pair of Instances for Failover

One of the most common scenarios is for two AMPS instances to replicate to each other. This replication is synchronous, so that both instances persist a message before AMPS acknowledges the message to the publisher. This makes a hot-hot pair. In the figure below, any messages published to important_topic are replicated across instances, so both instances have the messages for important_topic.

HA Pair Overview

Two connections are shown in the diagram to demonstrate the required configuration. However, because these instances replicate to each other, AMPS can optimize this replication topology to use a single network connection (although AMPS treats this as two one-way connections that happen to share a single network connection.)

Since AMPS replication is always peer-to-peer, clients can connect to either instance of AMPS when both are running. With this configuration, clients are configured with Instance 1 and Instance 2 as equivalent server addresses. If a client cannot connect to one instance, it tries the other. Given that both instances contain the same messages for important_topic, there is no functional difference in which instance a client connects to from the point of view of a publisher or subscriber. Each instance will contain the same messages for replicated topics. Messages can be published to either instance of AMPS at any time, and those messages will be replicated to the other instance.

Since these instances are intended to be equivalent message sources (that is -- a client may fail over from one instance to another instance), these instances are configured to use sync acknowledgment to publishers. What that means is that, when a message is published to one of these instances, that instance does not acknowledge the message to the publisher as persisted until both instances have written the message to disk (although the message can be delivered to subscribers once it is persisted locally). This means that a publisher using a publish store can fail over to either of these servers without risk of message loss.

When a subscriber uses a bookmark store to manage bookmark replay, that subscriber can fail over safely between instances along any set of replication links that use sync replication without risk of message loss. However, a subscriber that uses bookmark replay should not fail over along a path that includes a replication link that uses async acknowledgment, since an instance of AMPS will not consider that link when determining if a message is persisted.