[ 
https://issues.apache.org/jira/browse/QPID-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13642920#comment-13642920
 ] 

Alan Conway commented on QPID-4329:
-----------------------------------

In the cases I have seen so far, both main and DR sites were clusters. If the 
main site fails you want to have HA at the backup site.

If you can't tolerate message loss then you do need to delay acks for the 
remote site. Delaying acks is not really "synchronous" - you have an async 
streams of messages going one way and acks going the other. However you may 
slow senders down if they reach their capacity.

We could certainly have an option to opt out of delayed ack, but I'm not yet 
sure how we would want to configure & what messaging guarantees we make in that 
case.
                
> 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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to