From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
Cc: | Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_basebackup --wal-method=fetch |
Date: | 2024-02-08 22:21:29 |
Message-ID: | ZcVT6e9AU9XgP/37@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Greetings,
* Ron Johnson (ronljohnsonjr(at)gmail(dot)com) wrote:
> On Thu, Feb 8, 2024 at 4:41 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > * Ron Johnson (ronljohnsonjr(at)gmail(dot)com) wrote:
> > > On Thu, Feb 8, 2024 at 12:48 PM Magnus Hagander <magnus(at)hagander(dot)net>
> > wrote:
> > > > On Thu, Feb 8, 2024, 17:05 Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
> > wrote:
> > > >> (PG 14, if it matters.)
> > > >>
> > > >> What's the purpose of fetch mode, as opposed to streaming mode? Is
> > it a
> > > >> legacy of bygone days that just hasn't been deprecated, or is there
> > > >> something I don't understand from reading
> > > >> https://www.postgresql.org/docs/14/app-pgbasebackup.html?
> > > >
> > > > Your backup can go to a single file with it, which it can't do in
> > > > streaming. Which means it can also be sent through a pipe.
> > >
> > > But isn't the whole purpose of pg_basebackup (running it on Node B, when
> > > the database instance is Node A)?
> >
> > Something seems missing from this question?
>
> 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?
> 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.
I use pgbackrest too. ;) That said, one of the longest poles in the
tent when it comes to dealing with backups is compression- and there are
tools like pigz that allow you to multi-thread a single stream across
many cores, so it isn't necessarily the case that using fetch mode or
pg_basebackup generally makes everything have to be completely
single-process. Of course, pgbackrest has a lot of other features that
make it a great tool to use.
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.
> > > It also needs one connection instead of two to the server, if that's
> > > > limited.
> > >
> > > It's 2024, not 2011. Who can't spare an extra connection?
> >
> > Changing max_wal_senders requires a database-wide restart, so..
>
> To not have some wiggle room is poor planning
Doesn't change reality though.
> > If so, why? If that's not the angle,
> > then what is? Would you suggest some better documentation of the
> > option? I'm sure a proposal to improve the docs would be welcome, if
> > there's something confusing about them and this option.
>
> A hint as to the use-case for the non-default "streaming" option would be
> enlightening.
I mentioned a couple of them above and there is an example of streaming
in the documentation today:
######
To create a backup of a single-tablespace local database and compress
this with bzip2:
$ pg_basebackup -D - -Ft -X fetch | bzip2 > backup.tar.bz2
######
Would it make things more clear if this was an example that sent data to
a tape device instead of through bzip2..?
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-02-08 22:32:04 | Re: DDL - TYPES |
Previous Message | Laurenz Albe | 2024-02-08 22:21:19 | Re: DDL - TYPES |