Configuring Replication
Replication provides a data center redundancy and disaster recovery solution for PubSub+ software event brokers and appliances.
Replication uses corresponding Message VPNs with active and standby replication states at separate replication sites to ensure that Guaranteed Messaging clients can continue to have service through a specified Message VPN should one data center become unavailable. When replication is enabled, Guaranteed messages received by durable endpoints in a Message VPN with an active replication state at one replication site are automatically propagated to corresponding durable endpoints in a duplicate Message VPN with a standby replication state at the other replication site. In addition, local and XA transactions that publish or consume replicated Guaranteed messages are automatically propagated to the standby replication site. If a service failover to one replication site occurs, clients can reconnect to the same Message VPN at a different replication site to continue to receive service, and any messages that were received, but not consumed, before the service interruption can be delivered to them.
The following sections describe how to set up replication:
- Steps for Configuring Replication
- Configuring System-Level Replication Settings
- Configuring VPN-Level Replication Settings
Depending on other configuration settings on your event brokers, you may need to do additional tasks, such as:
If you are using replication with PubSub+ Cloud, see Using Replication for Disaster Recovery of Event Broker Services.
When configuring a bi-directional Message VPN bridge in a Message VPN where replication is also enabled, avoid subscribing both ends of that bridge to the same topics if those topics are also configured for replication. This restriction also applies to overlapping wildcard subscriptions. In other words, it applies to any subscription which would match a message received over the bridge. If such topics exist, then following a replication failover, they can cause messages originally received over the bridge to be sent back over that bridge to the originating event broker. This results in message duplication in the originating broker.