Re: backup manifests - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: backup manifests |
Date | |
Msg-id | CA+TgmoaGoQM74CMJhqg3_M7osWgkT2xSxo9aGVu9E4Nt+8Z4sg@mail.gmail.com Whole thread Raw |
In response to | Re: backup manifests (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: backup manifests
|
List | pgsql-hackers |
On Thu, Apr 2, 2020 at 2:55 PM Robert Haas <robertmhaas@gmail.com> wrote: > On Thu, Apr 2, 2020 at 2:23 PM Andres Freund <andres@anarazel.de> wrote: > > > That might make the window fairly wide on normal systems, but I'm not > > > sure about Raspberry Pi BF members or things running > > > CLOBBER_CACHE_ALWAYS/RECURSIVELY. I guess I could try it. > > > > You can set checkpoint_timeout to be a day. If that's not enough, well, > > then I think we have other problems. > > I'm not sure that's the only issue here, but I'll try it. I ran into a few problems here. In trying to set this up manually, I always began with the following steps: ==== # (1) create cluster initdb # (2) add to configuration file log_checkpoints=on checkpoint_timeout=1d checkpoint_completion_target=0.99 # (3) fire it up postgres createdb ==== If at this point I do "pg_basebackup -D pgslave -R -c spread", it completes within a few seconds anyway, because there's basically nothing dirty, and no matter how slowly you write out no data, it's still pretty quick. If I run "pgbench -i" first, and then "pg_basebackup -D pgslave -R -c spread", it hangs, apparently essentially forever, because now the checkpoint has something to do, and it does it super-slowly, and "psql -c checkpoint" makes it finish immediately. However, this experiment isn't testing quite the right thing, because what I actually need is a slow backup off of a cascading standby, so that I have time to promote the parent standby before the backup completes. I tried continuing like this: ==== # (4) set up standby pg_basebackup -D pgslave -R postgres -D pgslave -c port=5433 # (5) set up cascading standby pg_basebackup -D pgslave2 -d port=5433 -R postgres -c port=5434 -D pgslave2 # (6) dirty some pages on the master pgbench -i # (7) start a backup of the cascading standby pg_basebackup -D pgslave3 -d port=5434 -R -c spread ==== However, the pg_basebackup in the last step completes after only a few seconds. If it were hanging, then I could continue with "pg_ctl promote -D pgslave" and that might give me what I need, but that's not what happens. I suspect I'm not doing quite what you had in mind here... thoughts? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgsql-hackers by date: