From: | Adrien Nayrat <adrien(dot)nayrat(at)anayrat(dot)info> |
---|---|
To: | JOULAUD François <Francois(dot)JOULAUD(at)radiofrance(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: "invalid contrecord" error on replica |
Date: | 2021-05-03 13:02:24 |
Message-ID: | 27e30f3e-f3a5-02e5-0b28-f4dbfb99f7e3@anayrat.info |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Oh, I forgot to tell I was able to recover the secondary by replacing the
00000001000000AA000000A0 from the archives into pg_wal. Then the secondary were
able to finish recovery, start streaming replication and fetch subsequent wals.
I wondered why there was a CHECKPOINT_SHUTDOWN record. I dig a little more:
First, the filesystem on primary were full and I got :
PANIC: could not write to file "pg_wal/xlogtemp.305": No space left on device
The instance crashed and restarted in recovery mode.
At the end of the recovery I got:
checkpoint starting: end-of-recovery immediate
checkpoint complete: ...
Then a FATAL message:
FATAL: could not write to file "pg_wal/xlogtemp.9405": No space left on device
Followed by:
aborting startup due to process failure
Maybe it is this checkpoint which were not replicated? The primary had enough
space for this record. But I don't understand how the secondary received records
beginning by AA/A1...
I googled about this and I found other similar issues:
https://www.postgresql.org/message-id/flat/15938-8591df7e95064538%40postgresql.org
https://www.postgresql.org/message-id/CAMp7vw97871F21X7FHHdmU2FXGME4HTgMYxkAubMdCU2xevmxQ%40mail.gmail.com
https://www.postgresql.org/message-id/flat/E73F4CFB-E322-461E-B1EC-82FAA808FEE6%40lifetrenz.com
https://www.postgresql.org/message-id/15398-b4896eebf0bed218%40postgresql.org
https://www.postgresql.org/message-id/flat/15412-f9a89b026e6774d1%40postgresql.org
--
Adrien NAYRAT
https://blog.anayrat.info
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2021-05-03 15:10:44 | Re: pg_upgrade and wraparound |
Previous Message | Hans Buschmann | 2021-05-03 10:26:25 | Huge performance penalty with parallel queries in Windows x64 v. Linux x64 |