Re: Lost replication slots after pg_upgrade.

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: Lost replication slots after pg_upgrade.
Дата
Msg-id 20220208070404.d2dizlt6nvz2g3og@jrouhaud
обсуждение исходный текст
Ответ на Re: Lost replication slots after pg_upgrade.  (Nikhil Shetty <nikhil.dba04@gmail.com>)
Ответы Re: Lost replication slots after pg_upgrade.  (Nikhil Shetty <nikhil.dba04@gmail.com>)
Re: Lost replication slots after pg_upgrade.  (Victor Sudakov <vas@sibptus.ru>)
Список 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).



В списке pgsql-admin по дате отправления:

Предыдущее
От: Ram Pratap Maurya
Дата:
Сообщение: RE: PostgreSQL Full Vacuum Taking 5 to 6 hrs.
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: PostgreSQL Full Vacuum Taking 5 to 6 hrs.