Re: Seeking information about backup/recovery - Mailing list pgsql-admin

From Murthy Kambhampaty
Subject Re: Seeking information about backup/recovery
Date
Msg-id 2D92FEBFD3BE1346A6C397223A8DD3FC0923CD@THOR.goeci.com
Whole thread Raw
In response to Seeking information about backup/recovery  (Mary Edie Meredith <maryedie@osdl.org>)
Responses Re: Seeking information about backup/recovery  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-admin
On Thursday, September 04, 2003 18:12, Bruce Momjian
[mailto:pgman@candle.pha.pa.us]
>Murthy Kambhampaty wrote:
...
>I assume you are contrasting _any_ point-in-time recovery to recover up
>to the crash point, right?
>
Right.

>Anyway, unfortunately, WAL doesn't contain enough information
>to recover
>without having the file system files in some consistent state, even if
>that state is old.  In fact, the files have to be consistent as of the
>last checkpoint.
This, I'm not so sure of. On Linux, an xfs_freeze -f <fs_to_freeze> pauses
the filesystem and flushes all writes to disk; a snapshot of $PGDATA's
filesystem taken while it is frozen gives a consistent copy of $PGDATA as of
that instant (similar functionality is obtained by compiling the VFS locking
patch into the kernel).

The discussion at
http://marc.theaimsgroup.com/?l=postgresql-admin&w=2&r=1&s=LVM+snapshots&q=b
, includes log files from postmaster startup and shutdown on the backup
$PGDATA, and AFAICT, WAL recovery does not roll back to the last checkpoint.
If there is a better way to test this, let me know, and I'm happy to do it.

Thanks,
    Murthy

PS: From the man page for xfs_freeze:

"The -f flag requests the specified XFS filesystem to be frozen from new
modifications.   When this is selected, all ongoing transactions in the
filesystem are allowed to complete, new write system calls are  halted,
other calls which modify the filesystem are halted, and all dirty data,
metadata, and  log  information  are  written  to  disk.   Any  process
attempting to write to the frozen filesystem will block waiting for the
filesystem to be unfrozen."

When $PGDATA/pg_xlog/ is on disks different from $PGDATA's,
the XFS filesystem still allows online BAR with the following sequence:

1. rysnc -avr --delete $PGDATA/ <backup server>::mirror_pgdata/
2. xfs_freeze -f $PGDATA/pg_clog/
3. xfs_freeze -f $PGDATA
4. create snapshots and mount
5. xfs_freeze -f $PGDATA
6. xfs_freeze -f $PGDATA/pg_clog/
7. rysnc -avr --delete --exclude=pg_xlog/ $PGDATA/ <backup
server>::mirror_pgdata/pg_xlog/
8. rysnc -avr --delete $PGDATA/pg_xlog/ $PGDATA/ <backup
server>::mirror_pgdata/pg_xlog/
9. remove snapshots

By freezing both volumes ($PGDATA/pg_clog/ and $PGDATA/) during snapshot
creation,
a "consistent" copy is assured. Freezing the pg_xlog first, and unfreezing
it last, makes sure
that no CHECKPOINT operations are missed, ensuring the consistency of the
copy.

pgsql-admin by date:

Previous
From: Tom Lane
Date:
Subject: Re: max_fsm_pages
Next
From: Bruce Momjian
Date:
Subject: Re: Seeking information about backup/recovery