On Wed, Sep 21, 2011 at 2:13 PM, Magnus Hagander <mag...@hagander.net> wrote: > On Wed, Sep 21, 2011 at 04:50, Fujii Masao <masao.fu...@gmail.com> wrote: >> 3. Copy the pg_control file from the cluster directory on the standby to >> the backup as follows: >> >> cp $PGDATA/global/pg_control /mnt/server/backupdir/global > > But this is done as part of step 2 already. I assume what this really > means is that the pg_control file must be the last file backed up?
Yes. When we perform an archive recovery from the backup taken during normal processing, we gets a backup end location from the backup-end WAL record which was written by pg_stop_backup(). But since no WAL writing is allowed during recovery, pg_stop_backup() on the standby cannot write a backup-end WAL record. So, in his patch, instead of a backup-end WAL record, the startup process uses the minimum recovery point recorded in pg_control which has been included in the backup, as a backup end location. BTW, a backup end location is used to check whether recovery has reached a consistency state (i.e., end-of-backup). To use the minimum recovery point in pg_control as a backup end location safely, pg_control must be backed up last. Otherwise, data page which has the newer LSN than the minimum recovery point might be included in the backup. > (Since there are certainly a lot other ways to do the backup than just > cp to a mounted directory..) Yes. The above command I described is just an example. >> 4. Execute pg_stop_backup on the standby. >> >> The backup taken by the above procedure is available for an archive >> recovery or standby server. >> >> If the standby is promoted during a backup, pg_stop_backup() detects >> the change of the server status and fails. The data backed up before the >> promotion is invalid and not available for recovery. >> >> Taking a backup from the standby by using pg_basebackup is still not >> possible. But we can relax that restriction after applying this patch. > > I think that this is going to be very important, particularly given > the requirements on pt 3 above. (But yes, it certainly doesn't have to > be done as part of this patch, but it really should be the plan to > have this included in the same version) Agreed. >> To take a base backup during recovery safely, some sort of parameters >> must be set properly. Hot standby must be enabled on the standby, i.e., >> wal_level and hot_standby must be enabled on the master and the standby, >> respectively. FPW (full page writes) is required for a base backup, >> so full_page_writes must be enabled on the master. > > Presumably pg_start_backup() will check this. And we'll somehow track > this before pg_stop_backup() as well? (for such evil things such as > the user changing FPW from on to off and then back to on again during > a backup, will will make it look correct both during start and stop, > but incorrect in the middle - pg_stop_backup needs to fail in that > case as well) Right. As I suggested upthread, to address that problem, we need to log the change of FPW on the master, and then we need to check whether such a WAL is replayed on the standby during the backup. If it's done, pg_stop_backup() should emit an error. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
