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 < [email protected]> 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 >
