| From: | Jun Ishiduka <ishizuka(dot)jun(at)po(dot)ntts(dot)co(dot)jp> | 
|---|---|
| To: | masao(dot)fujii(at)gmail(dot)com | 
| Cc: | magnus(at)hagander(dot)net, heikki(dot)linnakangas(at)enterprisedb(dot)com, ssinger_pg(at)sympatico(dot)ca, pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: Online base backup from the hot-standby | 
| Date: | 2011-08-18 05:47:25 | 
| Message-ID: | 201108180548.p7I5m0Xx013962@ccmds32.silk.ntts.co.jp | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
> > * Procedure
> >
> > 1. Call pg_start_backup('x') on the standby.
> > 2. Take a backup of the data dir.
> > 3. Call pg_stop_backup() on the standby.
> > 4. Copy the control file on the standby to the backup.
> > 5. Check whether the control file is status during hot standby with pg_controldata.
> > ? -> If the standby promote between 3. and 4., the backup can not recovery.
> > ? ? ?-> pg_control is that "Minimum recovery ending location" is equals 0/0.
> > ? ? ?-> backup-end record is not written.
> 
> What if we do #4 before #3? The backup gets corrupted? My guess is
> that the backup is still valid even if we copy pg_control before executing
> pg_stop_backup(). Which would not require #5 because if the standby
> promotion happens before pg_stop_backup(), pg_stop_backup() can
> detect that status change and cancel the backup.
> 
> #5 looks fragile. If we can get rid of it, the procedure becomes more
> robust, I think.
Sure, you're right.
--------------------------------------------
Jun Ishizuka
NTT Software Corporation
TEL:045-317-7018
E-Mail: ishizuka(dot)jun(at)po(dot)ntts(dot)co(dot)jp
--------------------------------------------
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2011-08-18 06:39:39 | Re: Displaying accumulated autovacuum cost | 
| Previous Message | Jeevan Chalke | 2011-08-18 04:47:41 | Re: Allowing same cursor name in nested levels |