[xmlblaster] RE: [xmlblaster] RE: [xmlblaster] Mirrored Masters?

["Craig McIlwee" <craig.mcilwee at openroadsconsulting.com>]

We have considered this approach also, but not as master/slave because the slaves don't persist topics/messages, only masters do this.  In this case we would have 2 masters for a domain but they won't be configured with any knowledge of each other, i.e. no cluster setup.  In the primary master we would have a plugin that does have hostname, port, etc information about secondary master.  The plugin will subscribe to the primary master and publish to the secondary master.  I haven't fleshed out all of the details of this approach yet, but it seems like it would work.

The Linux HA suggested by Marcel is unfortunately out of the question in our scenario.  We have an existing Windows environment that we won't be able to rebuild on linux, we also have no experience with Linux HA.  If we do go the DB replication route I imagine we will try to take advantage of PostgresSQL's Slony-I features.

Craig

-----Original Message-----
From: Sanjeev Dhiman [mailto:sanjeevd at brickred.com]
Sent: Tuesday, December 08, 2009 11:17 AM
To: xmlblaster at server.xmlBlaster.org
Cc: craig.mcilwee at openroadsconsulting.com
Subject: RE: [xmlblaster] RE: [xmlblaster] Mirrored Masters?

Hi Craig,

If that is the case, does it make sense for you to implement a master
slave configuration since you just need the secondary to be in sync with
the primary? If yes, you could just make a subscriber that subscribes to
the primary node and continues to publish to the secondary.

Thanks,
Sanjeev

-----Original Message-----
From: owner-xmlblaster at server.xmlBlaster.org
[mailto:owner-xmlblaster at server.xmlBlaster.org] On Behalf Of Marcel Ruff
Sent: Tuesday, December 08, 2009 9:39 PM
To: xmlblaster at server.xmlBlaster.org
Cc: craig.mcilwee at openroadsconsulting.com
Subject: Re: [xmlblaster] RE: [xmlblaster] Mirrored Masters?

Craig McIlwee schrieb:
> Thanks Marcel.  What we are looking for is nowhere near as elegant of
a solution as you've outlined below.  Quoting the same page as David, we
are most interested in
>
> "Messages which are published are sent to all masters."
>
> Because we really just want a second master node that stays in sync
with the primary master.   In our scenario we don't need any type of
smart failover or load balancing, we want to make sure that 2 nodes are
receiving and persisting the same information.  In normal usage, the
primary node will always receive messages.  In a catastrophic situation
where the primary node fails (hardware error, etc) we need to be able to
switch to the secondary node that should be in sync with the primary,
and manual reconfiguration is acceptable.
>
> So from your mail below, I take it that persisting at 2 nodes is not
implemented yet?
No this is not implemented.
>   If not, it sounds like you recommend mirroring at the database
level?
>
Yes. And I would recommend to go from the beginning the Linux HA 
(bonding,DRDB,Heartbeat etc, HP-ServiceGuard ...) way,
as all the failover problems will arise over time anyhow, so I suggest
doing it right from beginning.

regards
Marcel
> Thanks,
> Craig
>
> -----Original Message-----
> From: owner-xmlblaster at server.xmlBlaster.org
[mailto:owner-xmlblaster at server.xmlBlaster.org] On Behalf Of Marcel Ruff
> Sent: Tuesday, December 08, 2009 4:41 AM
> To: xmlblaster at server.xmlBlaster.org
> Subject: Re: [xmlblaster] Mirrored Masters?
>
> Hi David,
>
> multi master is not implemented.
>
> The I_LoadBalancer#getClusterNode() returns one node (NodeMasterInfo)
which
> is used to forward messages to the next node, but only to one.
>
> If you need mirroring you could, depending if you need "failover" or
> "load balancing",
> consider following:
>
> 1) Change the xmlBlaster cluster code to handle multiple masters
> You need to decide in this case if the multiple masters are informed
> in a transaction (sync) or not (async). Clients need to be coded
> to choose a master depending on current load or failure.
> -> failover and load balancing
>
> 2) You could create an extended I_Queue and I_Map plugin which
> duplicates the data to two DBs
> -> failover
>
> 3) You could do low-level DB mirroring (DRDB, Linux HA et al)
> xmlBlaster gets on startup all information to re-establish its state.
> In this case the mirrored xmlBlaster is started on failure of the
first,
> clients automatically find the mirrored as the IP is change (standard
HA
> behaviour)
> -> failover
>
> 4) Master/Slave operation (exists already, one master with many
salves)
> -> load balancing
>
> 5) Combination of 3) and 4) should work out of the box
> -> failover and load balancing
>
>
> It depends on what you want to achieve,
>
> best regards
> Michele
> Marcel
>
>
> David R Robison schrieb:
>
>> In the discussion on clustering in the reference manual it talks
about
>> mirrored masters:
>>
>>     /An xmlBlaster cluster allows to have more than one master server
>>     for a specific message domain. The master nodes are //mirrored
>>     instances for those messages. Published messages reach all master
>>     nodes. Subscribed messages are retrieved using a load balance
>>     algorithm.
>>     /
>>
>>
>> However, the discussion says that it has not been implemented. Has
any
>> work been done on this? Any suggestions on how to achieve this?
>> Thanks, David

--
Marcel Ruff
http://www.xmlBlaster.org
http://gpsvision.biz