Re: pg_basebackup --wal-method=fetch - Mailing list pgsql-admin

From Ron Johnson
Subject Re: pg_basebackup --wal-method=fetch
Date
Msg-id CANzqJaA3yDYekWgC4VdWet3FDKo2qdU+MvcS9yMvMGHS72mkYg@mail.gmail.com
Whole thread Raw
In response to Re: pg_basebackup --wal-method=fetch  (Stephen Frost <sfrost@snowman.net>)
Responses Re: pg_basebackup --wal-method=fetch
List pgsql-admin
On Thu, Feb 8, 2024 at 5:21 PM Stephen Frost <sfrost@snowman.net> wrote:
Greetings,

* Ron Johnson (ronljohnsonjr@gmail.com) wrote:

> The word "streaming".
> Should be "But isn't streaming the whole purpose of pg_basebackup"?

I'm a bit confused on this point still as if the whole purpose of
pg_basebackup is to be streaming ... then we should be defaulting to
fetch mode still?

No.  Since I thought streaming is the whole purpose of pg_basebackup, I questioned the utility of every other method except --wal-method=streaming.
 
> I use PgBackRest, though, and can't imagine single-threading any
> reasonably-sized database.  In fact, one of the tasks on my mental TODO
> list is to research how to use PgBackRest to initialize a replica instance
> prior to starting Streaming Replication.

[snip] 
In terms of using pgbackrest to initialize a replica ... that's
basically running 'pgbackrest restore --type=standby'?  There's really
not much more to it than that.  pgbackrest will set up the restored
system to replay from the WAL in the archive, you'd just need to
configure primary_conninfo so that the replica will attempt to connect
to the primary once it's caught up with all of the WAL in the archive.

I haven't examined it closely enough.  What little looking that I did made me wonder whether PgBackRest handled all the replication itself, or whether it just initialized everything and then let physical replication using replication slots take over.

pgsql-admin by date:

Previous
From: Tom Lane
Date:
Subject: Re: DDL - TYPES
Next
From: Magnus Hagander
Date:
Subject: Re: pg_basebackup --wal-method=fetch