Re: Lost replication slots after pg_upgrade.

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Victor Sudakov <vas(at)sibptus(dot)ru>
Cc: Nikhil Shetty <nikhil(dot)dba04(at)gmail(dot)com>, 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 08:45:20
Message-ID: 20220208084520.hvp3qnwxtfmzq2lr@jrouhaud
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Tue, Feb 08, 2022 at 08:32:22AM +0000, Victor Sudakov wrote:
> Julien Rouhaud wrote:
> >
> > > 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).
>
> I think Nikhil was going to invoke the rsync black magic as described
> in https://www.postgresql.org/docs/current/pgupgrade.html, not for
> copying the entire PGDATA from the master to standbys. While the rsync
> magic should be hundreds of times faster because only modified files
> will be copied and the majority of files will be just hardlinked, I've
> never felt I have enough skill and luck to undertake this method.

Ah, if that's the case I don't think there's any doubt to have for rsync being
faster. And this method works just fine if you take care of what you're doing.

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Nikhil Shetty 2022-02-08 09:14:20 Re: Lost replication slots after pg_upgrade.
Previous Message Victor Sudakov 2022-02-08 08:34:35 Re: Lost replication slots after pg_upgrade.