Message-ID: <8ec1143e5f1e45714b415076b3ad7533346e2734.camel@cybertec.at>
Subject: Re: A streaming replica catching up
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Victor Sudakov <vas@sibptus.ru>, pgsql-admin@lists.postgresql.org
Date: Thu, 22 Apr 2021 09:20:43 +0200
In-Reply-To: <YIDqmtsUEpTK8Krp@admin.sibptus.ru>
References: <YIDqmtsUEpTK8Krp@admin.sibptus.ru>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/8ec1143e5f1e45714b415076b3ad7533346e2734.camel%40cybertec.at>
Precedence: bulk

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