On 6/12/06, Thomas Swindells <[EMAIL PROTECTED]> wrote:
James.Strachan wrote:
>
> Yes. Ultimately we'd like a quorum based system where you could have a
> cluster of N nodes, say N=3 so that so long as 2 broker nodes are
> communicating, you are fine and the 1 broker node that can't see
> anyone else would shut down - then you can handle network splits OK.
>
> Until we get there I'd recommend running clients on different machines
> to the master/slave broker unless you are prepared to handle network
> splits manually when they occur.
>
Has there been any design work on doing this,
We've had a few design sessions in bars on the back of envelopes ;)
But so far thats about it.
or (more importantly) on
automatic replication of state between brokers such that a master can become
a slave to the (old) slave when it comes back up (so that it would actually
be possible to use it in a HA system). Has there been any
designs/brainstorms on how this synchronization should occour/the
appropraite data gathered?
No - am afraid not.
Its probably easiest to just suspend a broker, checkpoint to disk,
then rsync the file system across to the other broker.
Another option could be to suspend the broker, force a checkpoint in
the journal to JDBC; then do a JDBC <-> JDBC synchronisation; though
this approach will only work with JDBC based persistence and not kaha
(the file system based persistence model)
--
James
-------
http://radio.weblogs.com/0112098/
