I’m not on the DBA team so I don’t know specifics but it is asynchronous replication to a secondary server in the same datacenter and a similar primary/secondary server to the standby datacenter.
Theoretically the mirroring in Artemis should offer the same resiliency (synced to the disk, possibly not replicated in the event of a hard failure); But in practice mirroring is Artemis is relatively new and SQL replication has existed for decades with plenty of DBAs who are well versed in mitigating common problems. Some of the issues we have with mirroring that I can remember: * The two sides get out of sync quickly as in: https://issues.apache.org/jira/projects/ARTEMIS/issues/ARTEMIS-3766 (not just the expiry queue – looking at one of our production sets right now on two of 6 queues I see message counts of 172 and 96 on the cold side, and 0 on the hot side. Because this is Artemis 2.20 I cannot browse them or see if they are really there but I hope to learn more when we complete our 2.22 update.) * The stats are not tracked correctly so it’s hard to tell how out of sync we are: https://issues.apache.org/jira/projects/ARTEMIS/issues/ARTEMIS-3743 * We use to end up with extremely large journals on the cold side that would prevent start up. Mitigated with aggressive TTL and purging on the cold side. * We’ve ended up with delivery of ancient messages when failing over. Mitigated somewhat with aggressive TTL. * More often than not when performing a graceful failover we need to restart Artemis on the new live. Consumers connect but they don’t receive any messages. * In some instances the mirror queues have not shown up in the Artemis console but have functioned. No known steps to reproduce, in all cases eventually resolved themselves. * Messages in the logs that indicate problems we don’t know the effect of like: 2022-05-30 00:30:12,964 WARN [org.apache.activemq.artemis.protocol.amqp.connect.mirror.AMQPMirrorControllerTarget] Queue activemq.management.665d289a-520e-40a6-9233-96265817ca6c not found on mirror target, ignoring ack for queue=activemq.management.665d289a-520e-40a6-9233-96265817ca6c, messageID=68514641673, nodeID=dea32b83-efd5-11eb-b5b1-0050568fe3b2 I hope as we grow we’ll be able to devote a resource to working on Artemis. It’s a critical and highly performant part of our infrastructure. I have personally been advocating for it to replace our aging JbossMQ 4 (pre-hornet) infrastructure. The JDBC replication is part of that plan, to replace a similarly JDBC replicated JbossMQ 4 cluster that is for the first time, outside of products that I’m directly responsible for. A bit more than I intended to write, but I hope this helps understand our where we are and our motivations. From: Justin Bertram <[email protected]> Date: Wednesday, June 1, 2022 at 12:34 AM To: [email protected] <[email protected]> Subject: Re: Artemis MQ with JDBC persistence not starting since 2.22 update I sent a commit to update the docs in the repo, and I also updated the website. Out of curiosity, how is your MySQL replication configured? Are you using the default asynchronous, semisynchronous, or fully synchronous NDB cluster? Justin On Tue, May 31, 2022 at 4:09 PM Stephen Baker < [email protected]> wrote: > Understood thank you. We (the company I work for) are definitely getting > more value out of the product than we are contributing, so that point is > taken. The JDBC replication route was recommended by a consultant from > Savoir as more established/reliable than mirroring when delivery guarantees > are important, which is why we are pursuing it. > > [EXTERNAL]: This email originated from outside of Rave Mobile Safety. Do not click links or open attachments unless you recognize the sender and know the content is safe.
