You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Alan Conway (JIRA)" <ji...@apache.org> on 2012/09/19 17:59:08 UTC
[jira] [Created] (QPID-4329) HA disaster recovery.
Alan Conway created QPID-4329:
---------------------------------
Summary: 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. We need an efficient solution based on ReplicatingSubscription rather than the old async. queue replication.
--
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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
[jira] [Updated] (QPID-4329) HA disaster recovery.
Posted by "Alan Conway (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan Conway updated QPID-4329:
------------------------------
Description:
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.
was: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. We need an efficient solution based on ReplicatingSubscription rather than the old async. queue replication.
> 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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org