| From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> | 
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | "Dan Gorman" <dgorman(at)hi5(dot)com>, "Toru SHIMOGAKI" <shimogaki(dot)toru(at)oss(dot)ntt(dot)co(dot)jp>, <pgsql-performance(at)postgresql(dot)org> | 
| Subject: | Re: PITR Backups | 
| Date: | 2007-06-22 17:45:57 | 
| Message-ID: | 1182534358.9276.326.camel@silverbirch.site | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-performance | 
On Fri, 2007-06-22 at 13:12 -0400, Tom Lane wrote:
> Dan Gorman <dgorman(at)hi5(dot)com> writes:
> > This snapshot is done at the LUN (filer) level, postgres is un-aware  
> > we're creating a backup, so I'm not sure how pg_start_backup() plays  
> > into this ...
> 
> That method works too, as long as you snapshot both the data files and
> WAL files --- when you start PG from the backup, it will think it
> crashed and recover by replaying WAL.  So, assuming that the snapshot
> technology really works, it should be exactly as reliable as crash
> recovery is.  
> If you saw a problem I'd be inclined to question whether
> there is some upstream component (OS or disk controller) that's
> reordering writes.
Given thats exactly what they do, constantly, I don't think its safe to
say that it works since we cannot verify whether that has happened or
not.
At the very least, you should issue a CHECKPOINT prior to taking the
snapshot, to ensure that the write barriers have gone through.
But that being said, I'm not quite sure why following the Continuous
Archiving procedures is a problem, since they don't add any significant
overhead, over and above the checkpoint command.
-- 
  Simon Riggs             
  EnterpriseDB   http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-06-22 18:02:44 | Re: PITR Backups | 
| Previous Message | Tom Lane | 2007-06-22 17:12:02 | Re: PITR Backups |