git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What is the best architecture to set up an activemq cluster to achieve high service and data availability


I'm concerned that the KahaDB became corrupted in the first place and
recommend solving that problem.  After all, if you end up replicating a
corrupt KahaDB, that won't help much.  And even with replication of an
uncorrupt image, recovering when the main store becomes corrupt would lead
to redelivery of the messages that were delivered since the replicated
image was created.

Corruption in the KahaDB is uncommon these days - it is very stable.
Abrupt termination of the broker might yield minor corruption, but for
that, I would expect the broker to easily recover.

Do you still have the corrupt KahaDB store around?  If so, one thing you
can try is to enable recovery options for KahaDB and see if that would
recover the store.

Also, is the store running on an NFSv4 filesystem?  It is possible to end
up with two active brokers with NFSv4 if the lock timeouts are too
aggressive, or the network has significant pauses.

Hope this helps.

Art



On Tue, May 8, 2018 at 11:54 AM, maheedhar1010 <
maheedhar.gunasekharan@xxxxxxxxxxxxxxx> wrote:

> We are currently in the process of setting up a highly available active-mq
> cluster that has 1 master and 2 slave nodes that share the same file
> system.
>
> However we felt this architecture might not be a safe from issues such as
> kahadb corruption. We recently faced an issue where the only way to start
> up
> the broker was to delete all the kahadb data as it never successfully
> recovered.
>
> So our question is whether we can opt for a setup that is both highly
> available service wise but also replicates the data in the background so
> that we can recover the data from a secondary node when there is a
> corruption of data in the primary storage node. Does active-mq support an
> architecture such as that?
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-
> f2368404.html
>