Skip site navigation (1) Skip section navigation (2)

Re: pg_start_backup - backups

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Ian Lea" <ian(dot)lea(at)gmail(dot)com>, "David Roland" <david(dot)roland(at)soapware(dot)com>
Cc: <pgsql-admin(at)postgresql(dot)org>
Subject: Re: pg_start_backup - backups
Date: 2011-04-11 15:47:12
Message-ID: 4DA2DC30020000250003C644@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-admin
"David Roland" <david(dot)roland(at)soapware(dot)com> wrote:
 
> changes to the data folder continue even after the PG_START_BACKUP
> command has been issued. This implies to me that the contents of
> any copy of the data folder may be unreliable. i.e. the copy may
> not reflect the state of the data folder either before the copy
> started or after the copy has finished. It may reflect the state
> of the data folder in some transient form.
 
Right.
 
> Assuming this is true, is the copy still usable for restoration?
 
Yes.
 
> If so, how does PostgreSQL get the data folder to a stable
> state? Is it by the use of the WAL files that may be created
> during the backup process and the restore.config file?
 
Exactly.  Simplifying somewhat:
 
- The pg_start_backup causes the WAL position to be remembered.  You
  will need to start WAL replay at this point.
 
- Every significant change to a page is WAL-logged.
 
- Changes after you record the restart point may or may not be in
  the base backup.
 
- After the base backup copying is complete, pg_stop_backup records
  the WAL position.  You will need to replay WAL *at least* to this
  point to have a consistent database.
 
- WAL replay will bring every page modified after the "start" to a
  valid state, whether or not any or all direct modifications to
  that page made it into the base backup.
 
- This actually goes beyond page fix-ups to file creation and
  deletion, etc.
 
-Kevin

In response to

Responses

pgsql-admin by date

Next:From: Jerry SieversDate: 2011-04-11 15:49:02
Subject: Re: unsupported header version error
Previous:From: Saurabh AgrawalDate: 2011-04-11 14:12:36
Subject: Postgres 9 slave lag

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group