Re: How to start slave after pg_basebackup. Why min_wal_size and wal_keep_segments are duplicated

Hi Andrus,

> On 31. May, 2020, at 22:56, Andrus <kobruleht2(at)hot(dot)ee> wrote:
> wal files are not archieved.

IMHO a bad decision. They should be. Now you're in the situation where you see why.

> I have tried to re-initiate replica serveral times in low-use time but this error occurs again.

remove the whole replica's PGDATA/* and do a pg_basebackup again. But before that, make sure wal_keep_segments in big enough on the master and, just as much important, do a vacuumdb -a (takes much space during the process) and use archiving!

> If named replication slot is used commands like
> vacuumdb --all --full
> will cause main server crash due to disk space limit. pg_wal directory will occupy free disk space. After that main server stops.

if you have disk constraints you will run into trouble sooner or later anyway. Make sure, you have enough disk space. There's no way around that anyway.

> I tried using wal_keep_segments =180
> Will setting wal_keep_segments to higher value allw replication start after pg_basebackup ?

it depends. If you start the replica immediately and don't wait for hours or days, you should be good to go. But that depends on different factors, for example, how many WAL files are written during the pg_basebackup and pg_ctl start of the replica. If more than 180 WALs have gone by on the master because it is really busy, then you're probably lost again. Point being, you'll have to launch the replica before WALs are expired!

Again: Make sure you have enough disk space, use archiving and use a replication slot.

Cheers,
Paul