public inbox for [email protected]
help / color / mirror / Atom feedFrom: Aidan Van Dyk <[email protected]>
To: Heikki Linnakangas <[email protected]>
Cc: Simon Riggs <[email protected]>
Cc: Fujii Masao <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Date: Thu, 11 Feb 2010 12:31:54 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <1265884657.7341.1192.camel@ebony>
<[email protected]>
<1265891248.7341.1346.camel@ebony>
<[email protected]>
<1265893599.7341.1454.camel@ebony>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
* Heikki Linnakangas <[email protected]> [100211 12:04]:
> > But it can be a problem - without the last WAL (or at least enough of
> > it) the master switched and archived, you have no guarantee of having
> > being consistent again (I'm thinking specifically of recovering from a
> > fresh backup)
>
> You have to wait for the last WAL file required by the backup to be
> archived before starting recovery. Otherwise there's no guarantee anyway.
Right, but now define "wait for". If you pull only "half" the last WAL
(because you've accepted that you *can* have short WAL files in the
archive), you have the problem with PITR.
Is it "wait for it to be in the archive", or "wait for it to be in the
archive, and be sure that the contents satisfy some criteria".
I've always made my PITR such that "in the archive" (i.e. the first
moment a recovery can see it) implies that it's bit-for-bit identical to
the original (or at least as bit-for-bit I can assume by checking
various hashes I can afford to). I just assumed that was kind of common
practice.
I'm amazed that "partial WAL" files are every available in anyones
archive, for anyone's restore command to actually pull. I find that
scarry, and sure, probably won't regularly be noticed... But man, I'ld
hate the time I need that emergency PITR restore to be the one time when
it needs that WAL, pulls it slightly before the copy has finished (i.e.
the master is pushing the WAL over a WAN to a 2nd site), and have my
restore complete consistently...
a.
--
Aidan Van Dyk Create like a god,
[email protected] command like a king,
http://www.highrise.ca/ work like a slave.
Attachments:
[application/pgp-signature] signature.asc (189B, 2-signature.asc)
download
view thread (77+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox