On 5/13/2020 1:24 PM, Laurenz Albe wrote:
> On Wed, 2020-05-13 at 06:18 -0700, Support wrote:
>> On 5/8/2020 1:51 PM, Support wrote:
>>> I normalized my replislots with the name of my nodes.
>>> I have 2 options in my recovery script that tries first pg_basebackup
>>> to recover and sync the hot standby, but unfortunately big DB fails
>>> sometimes due
>>> to very slow or unstable network. So my second option is to completely
>>> make a new inidb and import an sql file from pg_dumpall master as it
>>> takes less bytes once compressed. But I'm facing an issue with the
>>> slot complaining (obviously) about the ho standby node that does not
>>> match the slot identifier. So my question is simple, is there a way to
>>> reinitialize the slot to not renew the identifier with the new hot
>>> standby initdb?
>> No one has an answer to my question?
> That may be because your question is hard to understand.
>
> You cannot create a standby server using "pg_dumpall", so it is
> unclear what exactly you are doing here.
>
> Also, it is not clear what error message you get.
>
> Yours,
> Laurenz Albe
> it is not clear what error message you get.
Each has apparently an internal identifier based on the hot standby
initdb when it connected to the master the first time(?) or when a
pg_basebackup occured previously
this identifier (unique bigint) obviously does not match if I connect
the hot standby with a new initdb and a restore from pg_dumpall copy of
the master.
Sad because everything seems to be running but the master just does not
like the identifier doesn't match up. (sorry I cannot show you the
original error since I run the db in prod now)
