pg_start_backup and pg_stop_backup Re: [HACKERS] Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
in [PgSql]
|
Prev: pg_start_backup and pg_stop_backup Re: [HACKERS] Re:[COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
Next: [HACKERS] bug in build_startup_packet()
From: Heikki Linnakangas on 28 Apr 2010 07:28 Robert Haas wrote: > On Wed, Apr 28, 2010 at 6:52 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: >> On Wed, 2010-04-28 at 19:40 +0900, Fujii Masao wrote: >>> On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas >>> <heikki.linnakangas(a)enterprisedb.com> wrote: >>>> This doesn't contain any changes to pg_start_backup() yet, that's a >>>> separate issue and still under discussion. >>> I'm thinking of changing pg_start_backup and pg_stop_backup so that >>> they just check that wal_level >= 'archive', and changing pg_stop_backup >>> so that it doesn't wait for archiving when archive_mode is OFF. >>> >>> This change is very simple and enables us to take a base backup for SR >>> even if archive_mode is OFF. Thought? >> Makes sense. >> >> I'm wondering whether this could cause problems with people taking hot >> backups that aren't aimed at SR. Perhaps we could have 2 new functions >> whose names are more closely linked to the exact purpose: >> pg_start_replication_copy() etc.. >> which then act exactly as you suggest. > > Hmm. That seems a bit complicated. Why can't we just let people use > the existing functions the way they always have? 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. The straightforward way to enable that would be to allow pg_start_backup() when wal_level >= 'archive', regardless of archive_mode. However, I'm worried that someone might take an online backup without archiving (and replication), not realizing that it's not safe. That risk is there already, though, if you restore from an online backup and forget to create recovery.conf. It will start up in inconsistent state. The proposed change would make it easier to make that mistake. I'm not sure what to do about it, maybe throw a warning if you start up a database and there's a backup_label file in the data directory. Something like: WARNING: database system was interrupted while backup was in progress HINT: If you are restoring from an online backup, you must use a WAL archive for the restore, or the database can be in inconsistent state That would also occur if the primary database crashes while a backup is being taken, in which case the warning can be ignored. Or maybe we should check in pg_start_backup() that either archive_mode or streaming replication (max_wal_senders > 0) is enabled. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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: Heikki Linnakangas on 28 Apr 2010 11:25 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). Which is unfortunate, really. I wish we had a mode where the server simply refrained from removing/recycling WAL segments while the backup is running. You could then just: 1. pg_start_backup() 2. tar the data directory, except for pg_xlog 3. tar pg_xlog 4. pg_stop_backup(). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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: Heikki Linnakangas on 28 Apr 2010 13:44 Robert Haas wrote: > but > what do you mean by "except with filesystem-level snapshot > capabilities"? If you have a filesystem that supports atomic snapshots, you can take a snapshot of the filesystem the data directory resides on, and then copy the data directory from the snapshot at your leisure, without pg_start/stop_backup(). It is entirely invisible to PostgreSQL and works just like copying the data directory after an immediate shutdown. The server will perform crash recovery after restore. Virtualization software, logical volume managers and SANs tend to have such features, in addition to filesystems. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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: Michael Tharp on 30 Apr 2010 13:58 On 04/30/2010 01:53 PM, Robert Haas wrote: > > Well, one of us is. Why would you want to retain all of your WAL logs > in pg_xlog forever? > > ...Robert > To create or re-synchronize SR slaves, one could change wal_keep_segments to -1, run a backup, wait for the slaves to catch up, and change it back to the default. This way no segments would be deleted until the system has reached a stable state. -- m. tharp -- 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: Heikki Linnakangas on 30 Apr 2010 14:36
Robert Haas wrote: > On Fri, Apr 30, 2010 at 1:44 PM, Simon Riggs <simon(a)2ndquadrant.com> wrote: >> On Fri, 2010-04-30 at 12:22 -0400, Bruce Momjian wrote: >>>> (wal_keep_segments can be changed without restarting, right?) >>> Should we allow -1 to mean "keep all segments"? >> Why is that not called "max_wal_segments"? wal_keep_segments sounds like >> its been through Google translate. > > Because it's not a maximum? Yeah, min_wal_segments or something would make sense. It sounds about as good or bad as wal_keep_segments to me. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |