pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedA streaming replica catching up
3+ messages / 2 participants
[nested] [flat]
* A streaming replica catching up
@ 2021-04-22 03:16 Victor Sudakov <vas@sibptus.ru>
2021-04-22 07:20 ` Re: A streaming replica catching up Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 1 reply; 3+ messages in thread
From: Victor Sudakov @ 2021-04-22 03:16 UTC (permalink / raw)
To: pgsql-admin@lists.postgresql.org
Dear Colleagues,
After a streaming standby has been down for a time, I know of two
options for it to catch up with the master:
1. The replica can fetch all the necessary WAL records via the
replication protocol from the master (unless max_slot_wal_keep_size is
not the default -1, all the required WAL archives should be available from
the master).
2. The replica can be provided with a restore_command and will fetch
all WAL files from the WAL archive before starting streaming WAL from
the master.
Which is the preferred way?
Of course if max_slot_wal_keep_size is limited, the second options seems
the only safe one.
OTOH, if the master does not write to a WAL archive, only the first
option is left to us.
--
Victor Sudakov VAS4-RIPE
http://vas.tomsk.ru/
2:5005/49@fidonet
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: A streaming replica catching up
2021-04-22 03:16 A streaming replica catching up Victor Sudakov <vas@sibptus.ru>
@ 2021-04-22 07:20 ` Laurenz Albe <laurenz.albe@cybertec.at>
2021-04-22 08:43 ` Re: A streaming replica catching up Victor Sudakov <vas@sibptus.ru>
0 siblings, 1 reply; 3+ messages in thread
From: Laurenz Albe @ 2021-04-22 07:20 UTC (permalink / raw)
To: Victor Sudakov <vas@sibptus.ru>; pgsql-admin@lists.postgresql.org
On Thu, 2021-04-22 at 10:16 +0700, Victor Sudakov wrote:
> After a streaming standby has been down for a time, I know of two
> options for it to catch up with the master:
>
> 1. The replica can fetch all the necessary WAL records via the
> replication protocol from the master (unless max_slot_wal_keep_size is
> not the default -1, all the required WAL archives should be available from
> the master).
>
> 2. The replica can be provided with a restore_command and will fetch
> all WAL files from the WAL archive before starting streaming WAL from
> the master.
>
> Which is the preferred way?
>
> Of course if max_slot_wal_keep_size is limited, the second options seems
> the only safe one.
>
> OTOH, if the master does not write to a WAL archive, only the first
> option is left to us.
Both methods are equally feasible. Which one you choose depends on
your situation, just as you describe in the last two sentences.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: A streaming replica catching up
2021-04-22 03:16 A streaming replica catching up Victor Sudakov <vas@sibptus.ru>
2021-04-22 07:20 ` Re: A streaming replica catching up Laurenz Albe <laurenz.albe@cybertec.at>
@ 2021-04-22 08:43 ` Victor Sudakov <vas@sibptus.ru>
0 siblings, 0 replies; 3+ messages in thread
From: Victor Sudakov @ 2021-04-22 08:43 UTC (permalink / raw)
To: pgsql-admin@lists.postgresql.org; +Cc: Laurenz Albe <laurenz.albe@cybertec.at>
Laurenz Albe wrote:
> On Thu, 2021-04-22 at 10:16 +0700, Victor Sudakov wrote:
> > After a streaming standby has been down for a time, I know of two
> > options for it to catch up with the master:
> >
> > 1. The replica can fetch all the necessary WAL records via the
> > replication protocol from the master (unless max_slot_wal_keep_size is
> > not the default -1, all the required WAL archives should be available from
> > the master).
> >
> > 2. The replica can be provided with a restore_command and will fetch
> > all WAL files from the WAL archive before starting streaming WAL from
> > the master.
> >
> > Which is the preferred way?
> >
> > Of course if max_slot_wal_keep_size is limited, the second options seems
> > the only safe one.
> >
> > OTOH, if the master does not write to a WAL archive, only the first
> > option is left to us.
>
> Both methods are equally feasible. Which one you choose depends on
> your situation, just as you describe in the last two sentences.
I see.
It is also interesting when there is Patroni involved, would it be a good
idea to provide Patroni nodes with a restore_command? I'm afraid it can
interfere with Patroni failover/switchover operations.
--
Victor Sudakov VAS4-RIPE
http://vas.tomsk.ru/
2:5005/49@fidonet
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2021-04-22 08:43 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-04-22 03:16 A streaming replica catching up Victor Sudakov <vas@sibptus.ru>
2021-04-22 07:20 ` Laurenz Albe <laurenz.albe@cybertec.at>
2021-04-22 08:43 ` Victor Sudakov <vas@sibptus.ru>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox