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@xxxxxxxxxxx
<mailto:adrian.klaver@xxxxxxxxxxx>> 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@xxxxxxxxxxx <mailto:adrian.klaver@xxxxxxxxxxx>
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
