qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Conway (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (QPID-4329) HA disaster recovery.
Date Wed, 19 Sep 2012 16:29:07 GMT

     [ 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


Mime
View raw message