Thanks for checking on that.

I will take a look today.

On Thu, Jun 30, 2022 at 4:39 AM Iliya Grushevskiy <iliya...@gmail.com>
wrote:

> Hi, Clebert
>
> I think there is another related issue:
> https://issues.apache.org/jira/projects/ARTEMIS/issues/ARTEMIS-3815 <
> https://issues.apache.org/jira/projects/ARTEMIS/issues/ARTEMIS-3815>
> I have sent a PR https://github.com/apache/activemq-artemis/pull/4066.
> It’s outdated now, but it contains test that I think is still relevant.
>
>
> Regards
> Iliya Grushevskiy
>
>
>
>
> > 29 июня 2022 г., в 18:34, Clebert Suconic <clebert.suco...@gmail.com>
> написал(а):
> >
> > I have sent a PR for the mirror issues:
> >
> > https://github.com/apache/activemq-artemis/pull/4127
> >
> > On Wed, Jun 1, 2022 at 10:06 AM Stephen Baker
> > <stephen.ba...@rmssoftwareinc.com> wrote:
> >>
> >> 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 <jbert...@apache.org>
> >> Date: Wednesday, June 1, 2022 at 12:34 AM
> >> To: users@activemq.apache.org <users@activemq.apache.org>
> >> 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 <
> >> stephen.ba...@rmssoftwareinc.com> 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.
> >
> >
> >
> > --
> > Clebert Suconic
>
> --
Clebert Suconic

Reply via email to