[
https://issues.apache.org/jira/browse/QPID-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13642803#comment-13642803
]
Ted Ross commented on QPID-4329:
--------------------------------
A simpler approach might be to not use multiple "clusters" but to allow the
primary cluster to have a backup broker that is remote and not part of the
failover group behind the virtual IP.
It is also desirable to operate the replication to the remote backup in an
"asynchronous" way (i.e. don't delay ack's to the producer on the primary while
waiting for acks from the remote backup). In other words, have an option on
the replication subscription that causes that subscription to *not* participate
in the delayed-ack.
> HA disaster recovery.
> ---------------------
>
> Key: QPID-4329
> URL: https://issues.apache.org/jira/browse/QPID-4329
> Project: Qpid
> Issue Type: New Feature
> Components: C++ Clustering
> Affects Versions: 0.18
> Reporter: Alan Conway
> Assignee: Cliff Jansen
>
> A common deployment is to have a main cluster at one site and a "disaster
> recovery" cluster at a remote site to take over if the main cluster fails.
> A possible solution is to have a broker at the DR site act as a "relay" by
> acting in two capacities:
> - as a backup of the main primary: replicate state from the main cluster
> - as a primary at the DR site: allowing DR backups to replicate
> This gives only a single stream of traffic between the and gurarantees that a
> message is not completed to the client till it is completed by all the
> brokers, main and DR.
> Possibly we want some configuration options to be less strict about waiting
> for completions in this configuration, e.g. only wait for the relay to
> complete rather than waiting for all the relays backups, or even don't wait
> for the relay at all. Needs thought.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
