pg_start_backup and pg_stop_backup Re: [HACKERS] Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
in [PgSql]
|
Prev: providing tokenized version of parsed SQL script
Next: pg_start_backup and pg_stop_backup Re: [HACKERS] Re:[COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
From: Robert Haas on 28 Apr 2010 12:44 On Wed, Apr 28, 2010 at 11:25 AM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > Robert Haas wrote: >> At least as I understand it, even when not using >> archive_mode, streaming replication, or hot standby, it's still >> perfectly legal to use pg_start_backup() to take a hot backup. > > Nope. The correct procedure to take a hot backup is described in > http://www.postgresql.org/docs/8.4/interactive/continuous-archiving.html#BACKUP-TIPS. > It involves setting archive_mode=on, and archive_command to a shell > command that normally just returns true, except when backup is in > progress. You can't take a hot backup without archiving (or streaming) > at least temporarily. (except with filesystem-level snapshot capabilities). Oh. Well, in that case the proposed change seems reasonable... but what do you mean by "except with filesystem-level snapshot capabilities"? ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 28 Apr 2010 13:53 Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: > Well, it would be nice to allow using pg_start_backup() on the primary > when streaming replication is enabled, even if archiving isn't. > Otherwise the only way to get the base backup for the standby is to shut > down primary first, or use filesystem snapshot etc. I think I must be missing something: exactly how would you fire up a new standby from such a base backup, if you weren't running archiving? If you aren't archiving then there's no guarantee that you'll still have a continuous WAL series starting from the start of the backup. IOW I think that the requirement in pg_start_backup shouldn't be relaxed without some more thought/work. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 28 Apr 2010 14:21 Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: > Tom Lane wrote: >> If you aren't archiving then there's no guarantee that you'll still have >> a continuous WAL series starting from the start of the backup. > I wasn't really thinking of this use case, but you could set > wal_keep_segments "high enough". Ah. Okay, that seems like a workable approach, at least for people with reasonably predictable WAL loads. We could certainly improve on it later to make it more bulletproof, but it's usable now --- if we relax the error checks. (wal_keep_segments can be changed without restarting, right?) > Not a configuration I would recommend > for high availability, but should be fine for setting up a streaming > replication standby for testing etc. If we don't allow > pg_start/stop_backup() with archive_mode=off and max_wal_senders>0, > there's no way to bootstrap a streaming replication standby without > archiving. Right. +1 for weakening the tests, then. Is there any use in looking at wal_keep_segments as part of this test? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 28 Apr 2010 15:06 Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: > Hmm, you could start streaming the WAL before you start the backup, so > the fact that you've already removed some segments that are needed to > restore from the backup by the time pg_stop_backup() is called doesn't > necessarily mean that the backup is useless. > You'd need a stand-alone tool to do the streaming in that case, and no > such tool exists yet, but I would be surprised if one doesn't appear on > pgfoundry sooner or later :-). Yeah. ISTM the real bottom line here is that we have only a weak grasp on how these features will end up being used; or for that matter what the common error scenarios will be. I think that for the time being we should err on the side of being permissive. We can tighten things up and add more nanny-ism in the warnings later on, when we have more field experience. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 28 Apr 2010 15:50
Aidan Van Dyk <aidan(a)highrise.ca> wrote: > I'm hoping to be able to build a tool that: > > 1) Connects to PG walsender (a la walreceiver) > 2) Streams WAL from pg master > 3) Saves WAL into "files" (a la archive)... > > i.e. I'm looking to keep a more-up-to-date PITR archive than > waiting for traditional WAL file archiving... I'm interested in that, too. > I don't personally care about streaming replication replaying WAL > as it comes, or running queries in recovery... I'm with you that far, but I wouldn't want the sender to wait for remote persistence. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |