From: | Shaun Thomas <sthomas(at)optionshouse(dot)com> |
---|---|
To: | 'Albe Laurenz' <laurenz(dot)albe(at)wien(dot)gv(dot)at>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Backup Question |
Date: | 2013-10-22 15:33:41 |
Message-ID: | 0683F5F5A5C7FE419A752A034B4A0B979744196B@sswchi5pmbx2.peak6.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> Wrong. The database cannot check all data for consistency
> upon backup. For one, that would take way too long.
Well, what I meant, was that it would stop the database if it couldn't
apply one of the transaction logs for whatever reason. It wasn't
"inconsistent enough" for that. :)
> If you backup the standby, then you won't have a backup_label file.
> You cannot restore a backup without that.
Well, the backup_label gets copied to the archive log path when
pg_stop_backup gets called. So, I do have it. But beyond that, I have
the start/stop WAL locations, so I can get all the required files to apply,
which are all that is really necessary.
> Moreover, recovery needs a checkpoint/restartpoint to start.
> Restartpoints on the standby won't be the same as checkpoints
> on the primary, so I believe that even with the backup_label
> file you would not be able to restore the data.
I suppose I could build in a function to pause the backup until the
restartpoint replays on the replica. Then at least, the backup "starts"
on both systems with the same assumptions.
--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd | Suite 500 | Chicago IL, 60604
312-676-8870
sthomas(at)optionshouse(dot)com
______________________________________________
See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2013-10-22 16:21:43 | Re: Count of records in a row |
Previous Message | Rémi Cura | 2013-10-22 15:32:27 | Re: Count of records in a row |