For later readers, the suggestion should have directed to use the Artemis users@ list, not the dev list.
On Wed, 27 May 2026 at 12:45, Jean-Baptiste Onofré <[email protected]> wrote: > Hi > > I suggest you send your message to the [email protected] mailing > list. > > Thanks! > > Regards > JB > > On Wed, May 27, 2026 at 11:46 AM Mikhail Lukyanov <[email protected]> > wrote: > >> Hello everyone. >> >> I would like to ask for advice and recommendations regarding a >> high-availability cluster with mirroring to another data centers. >> >> Currently we have the following setup: in each data center there are 3 >> machines/JVMs, each running 2 Artemis instances — a primary of one group >> and a backup of another — along with ZooKeeper. In total there are 6 >> Artemis instances, forming 3 primary/backup pairs managed by CuratorManager >> within one data center. Each Artemis instance mirrors data to the other >> data center, so that if one data center goes down, we can bring up the full >> cluster and continue processing in the other data center. Mirroring is >> configured per pair failover: if the primary fails, we send data to its >> backup. In this scheme, all broker connections on the standby data center >> are disabled. The primary and backup configuration xml in attachment to the >> letter. >> >> [image: image.png] >> Now there is a requirement to mirror data to a third, additional data >> center. This means each active Artemis instance in the first data center >> must mirror data to 2 standby data centers. However, this introduces >> significant new complications. For example, Artemis1 in standby DC2 has >> broker connections both to Artemis1 in active DC1 and to Artemis1 in >> standby DC3. As a result, events received via mirroring from Artemis1.DC1 >> are then attempted to be re-mirrored from Artemis1.DC2 to Artemis1.DC3, and >> they accumulate in `$ACTIVEMQ_ARTEMIS_MIRROR_Artemis1.DC2_to_Artemis1.DC3` >> — even though Artemis1.DC1 is already forwarding those events directly to >> Artemis1.DC3. Mirroring from Artemis1.DC2 to Artemis1.DC3 is disabled, yet >> messages continue to accumulate in >> `$ACTIVEMQ_ARTEMIS_MIRROR_Artemis1.DC2_to_Artemis1.DC3`. >> >> My understanding is that the solution to this problem is Mesh Mirror, as >> described in https://issues.apache.org/jira/browse/ARTEMIS-5925. >> >> This raises the question: are Cluster HA and Mesh Mirror compatible with >> each other, or are they mutually exclusive mechanisms? >> >> It also follows that ZooKeeper would need to be deployed separately for >> HA and for Mesh Mirror — how can this be configured and managed? >> >> By what mechanisms can I actually achieve the desired behavior? >> >> -- >> *With best regards, Lukyanov Mikhail* >> *Tel: **+7-909-69-71-547* >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> For further information, visit: https://activemq.apache.org/contact >> >
