On 12/24/20 12:24 PM, Lars Vonk wrote:
> Well thanks for taking the time anyway. Indeed next time reduce the
> parts is a good idea.
>
> I would still expect though that if a logical replica misses a WAL it
> would stop replicating (and / or report an inconsistent state). I know
> this is the case with binary replication (it stops replication).
> As a last question, do you know if this is also the case with logical
> replication as well, or is what happened here an "expected outcome" when
> a logical replica misses a WAL?
It is still not clear to me what of the process was complaining about
the WAL. Without knowing that any answer as to what effect it had would
just be pulled out of thin air.
As to logical replication and WAL read this thread(I thought I
remembered a previous discussion on this, took me a bit to pull it up):
https://www.postgresql.org/message-id/CAGvVEFvq_VM9LhYPeu%2BUw__gEVvrBffGL%3DFO-88cZEp-35%2BarA%40mail.gmail.com
>
> Lars
>
> On Thu, Dec 24, 2020 at 5:52 PM Adrian Klaver <adrian.klaver@aklaver.com
> <mailto:adrian.klaver@aklaver.com>> wrote:
>
> On 12/23/20 1:40 AM, Lars Vonk wrote:
> > The full setup is:
> >
> > **Before:
> > 11 primary -> 11 hotstandby binary
> >
> > **During migration
> > 11 primary -> 11 hotstandby binary
> > | -> 12 new instance via logical
> > |-> 12 new replica via binary
> >
> > **After migration
> > 12 primary
> > |-> 12 replica via binary
> >
> >
>
> There are several moving parts here. I have to believe the problem is
> related. Just not sure how to figure it out after the fact. The best I
> can come up with is retry the process and monitor closely in real or
> near real time to see if you can catch the issue. Another option is to
> reduce the parts count by not running the binary 12 --> 12 replication
> at the same time you are doing the 11 --> 12 logical replication.
>
>
> --
> Adrian Klaver
> adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
>
--
Adrian Klaver
adrian.klaver@aklaver.com