activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: HA system design
Date Thu, 08 Jun 2006 14:47:16 GMT
On 6/8/06, Thomas Swindells <tswindells@ndsuk.com> wrote:
>
> >Re: HA system design  James.Strachan 2006-06-08 12:26
> >On 6/7/06, Thomas Swindells <tswindells@...> wrote:
> >>
> >> Hi, I'm new to JMS and ActiveMQ
>
> >Welcome!
> Thank you
> >> and need to develope a high available system.
> ...
> >> From what I have been reading the Master-Slave connection only supports a
> >> single failure occouring and then requires both brokers to be restarted,
> >> is
> >> this correct?
> >Yes
>
> >> If this is the case please could someone suggest to me what then is the
> >> best
> >> configuration in order to create a rebust high availability system?
> >>
> >> Are there any advantages/disadvantages to having embeded brokers within
> >> each
> >> client which then connect to the main broker system or should the client
> >> just connect directly to the main broker system?
>
> >So i'd recommend 2 approaches; it kinda depends on your requirements
> >really which is best. The easiest option to go with is Master/Slave.
> >The issue is if you loose a broker its currently a manual process to
> >bring it back online again since we don't yet have an automatic
> >old-master <-> new-master synchronization protocol.
> Unfortunately this isn't an option, the system needs to be HA meaning a full
> failover/failback solution.
> Is any work being done on creating the necessary synchronization?

Not yet - hopefully in the future someone will build this.


> >The other option; if you're using topics and need really high
> >performance you could consider using   subscription recovery...
> >http://incubator.apache.org/activemq/subscription-recovery-policy.html
> >which basically means if a broker dies, you connect to another broker
> >(in a store/forward network so messages on a topic get replicated to
> >all available consumers). However by default you'd miss some messages
> >during the time between reconnecting & resubscribing, so subscription
> >recovery policy allows you to configure a buffer in each broker (say 1
> >minutes worth) of messages kept around in RAM so that they can be
> >replayed to any new retroactive consumers that reconnect.
>
> >The latter option is crazy fast and does not require any persistence,
> >the former option is the solution you should go with if you need
> >persistence or use queues.
> The later option sounds closer to the solution I need however I do also need
> to use some queues in the system. Are there any other solutions which allow
> full failover/failback support which do also support queues or is it going
> to be a comprimise between one or the other?

For queues the only real option is master/slave as we have to
replicate things to 1-N brokers.

So it sounds like you need a broker-broker reconciliation capability
so you can automatically bring back online any failed masters.

-- 

James
-------
http://radio.weblogs.com/0112098/

Mime
View raw message