> I think this is due to the fact that HA replication is asynchronous and replica server may not catch up with primary.
To be clear, message replication between a primary and a backup is *synchronous*. Justin On Thu, May 26, 2022 at 3:11 AM Iliya Grushevskiy <[email protected]> wrote: > Hi, Aaron > > We are currently testing similar deployment and have encountered several > issues: > > - message lose on send on network failure between data centers > I think this is due to the fact that HA replication is asynchronous and > replica server may not catch up with primary. > > - message lose or duplicate (depending on error handling strategy) on > consumer on network failure between data centers > I think this was caused by two factors: duplicate id cache is consistent > only in HA pair and message redistribution was on. > Switching off redistribution (or as an option increasing delay) should > fix this issue. > > - message duplicate on mirrored server > This is addressed in pull request: > https://github.com/apache/activemq-artemis/pull/4066 > > Regards > Iliya Grushevskiy > > > > 26 мая 2022 г., в 07:46, Justin Bertram <[email protected]> > написал(а): > > > > I'm not aware of such a production deployment and I would be surprised if > > there was one given that clustering was designed for local area networks > > with low latency which typically isn't what is found between data > centers. > > > > I recommend you pursue your mirroring approach as that is what mirroring > > was designed for (i.e. cross data-center disaster-recovery use-cases). > > > > > > Justin > > > > On Wed, May 25, 2022 at 10:36 PM Steigerwald, Aaron > > <[email protected]> wrote: > > > >> Hello, > >> > >> Is anyone aware of a production deployment of an Artemis "cross data > >> center" HA cluster? For example, a cluster spread across 3 data centers. > >> Each data center contains a master/slave pair. > >> > >> I would like to know what kind of issues anyone has overcome with such a > >> configuration. I understand there are many configuration and operational > >> variables. Any info would be helpful. > >> > >> Note that we are considering asynchronously mirroring each master/slave > >> pair's queues to a dedicated asynchronous target node. The asynchronous > >> target node would exist in a different data center and would not service > >> any other connections. A custom plugin would automatically scale down > the > >> messages into a live cluster node if the connections to the master/slave > >> mirror sources were disconnected for a period of time. > >> > >> Thank you, > >> Aaron Steigerwald > >> > >
