Re: Lost replication slots after pg_upgrade.

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Nikhil Shetty <nikhil(dot)dba04(at)gmail(dot)com>
Cc: Victor Sudakov <vas(at)sibptus(dot)ru>, Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org>, pgsql-admin <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Lost replication slots after pg_upgrade.
Date: 2022-02-08 07:04:04
Message-ID: 20220208070404.d2dizlt6nvz2g3og@jrouhaud
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Hi,

On Tue, Feb 08, 2022 at 12:24:56PM +0530, Nikhil Shetty wrote:
>
> I am doing a major version upgrade from pg 11 to 13. The point is if I lose
> the replication slot after upgrade then how will I sync standby from
> primary after rsync.
>
> I can create the slot after upgrading but won't there be dataloss?

The replication slots are only there to make sure that the primary server won't
remove needed WALs before the standby can retrieve them. Unless you start
production activity just after the pg_upgrade and before finishing rebuilding
the secondary there shouldn't be enough activity to lead to removing old WALs.
But if you do, you can create the needed replication slot(s) manually just
after the pg_upgrade. But as already mentioned, I also recommend using
pg_basebackup for rebuilding the standby server(s).

> pg_basebackup takes time for large databases (> 5TB). I feel rsync should
> be faster.

Not necessarily. pg_basebackup will do simple sequential read of all the data,
which is probably the fastest thing to do. rsync will do some extra processing
that isn't required in that scenario, so it's likely to be slower (although
probably only marginally slower).

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Julien Rouhaud 2022-02-08 07:08:26 Re: PostgreSQL Full Vacuum Taking 5 to 6 hrs.
Previous Message Ram Pratap Maurya 2022-02-08 06:59:07 RE: PostgreSQL Full Vacuum Taking 5 to 6 hrs.