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
I didn't recal that it was not possible to create a hot standby with a
fresh new install and pg_dumpall .
only pg_basebackup or an exact copy of the data folder can do it right?
is the reason technical or else?
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)
