> On Tue, 2006-09-19 at 12:13 -0400, Tom Lane wrote:
> Also, I'm not sold that the concept is even useful. Apparently the idea
> is to offload the expense of taking periodic base backups from a master
> server, by instead backing up a PITR slave's fileset --- which is fine.
Good. That's the key part of the idea and its a useful one, so I was
looking to document it for 8.2
I thought of this idea separately, then, as usual, realised that this
idea has a long heritage: Change Accumulation has been in production use
with IMS for at least 20 years.
> But why in the world would you want to stop the slave to do it? ISTM
> we would want to arrange things so that you can copy the slave's files
> while it continues replicating, just as with a standard base backup.
You can do that, of course, but my thinking was that people would regard
the technique as "unsupported", so I added a quick flag as a prototype.
On Tue, 2006-09-19 at 12:13 -0400, Tom Lane wrote:
> This patch has obviously been thrown together with no thought and even
> less testing. It breaks the normal case (I think the above if-test is
> backwards), and I don't believe that it works for the advertised purpose
> either (because nothing gets done to force a checkpoint before aborting,
> thus the files on disk are not up to date with the end of WAL).
Yes, it was done very quickly and submitted to ensure it could be
considered yesterday for inclusion. It was described by me as rushed,
which it certainly was because of personal time pressure yesterday: I
thought that made it clear that discussion was needed. Heikki mentions
to me it wasn't clear, so those criticisms are accepted.
On Tue, 2006-09-19 at 16:05 +0100, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > +
> > + if (startupAfterRecovery)
> > + ereport(ERROR,
> > + (errmsg("recovery ends normally with startup_after_recovery=false")));
> > +
>
> I find this part of the patch a bit ugly.
Me too.
Overall, my own thoughts and Tom's and Heikki's comments indicate I
should withdraw the patch rather than fix it. Patch withdrawn.
Enclose a new doc patch to describe the capability, without s/w change.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
Index: doc/src/sgml/backup.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/backup.sgml,v
retrieving revision 2.86
diff -c -r2.86 backup.sgml
*** doc/src/sgml/backup.sgml 16 Sep 2006 00:30:11 -0000 2.86
--- doc/src/sgml/backup.sgml 20 Sep 2006 12:43:55 -0000
***************
*** 1137,1142 ****
--- 1150,1197 ----
</para>
</sect2>
+ <sect2 id="backup-incremental-updated">
+ <title>Incrementally Updated Backups</title>
+
+ <indexterm zone="backup">
+ <primary>incrementally updated backups</primary>
+ </indexterm>
+
+ <indexterm zone="backup">
+ <primary>change accumulation</primary>
+ </indexterm>
+
+ <para>
+ Restartable Recovery can also be utilised to offload the expense of
+ taking periodic base backups from a main server, by instead backing
+ up a Standby server's files. This concept is also generally known as
+ incrementally updated backups, log change accumulation or more simply,
+ change accumulation.
+ </para>
+
+ <para>
+ If we take a backup of the server files whilst a recovery is in progress,
+ we will be able to restart the recovery from the last restartpoint.
+ That backup now has many of the changes from previous WAL archive files,
+ so this version is now an updated version of the original base backup.
+ If we need to recover, it will be faster to recover from the
+ incrementally updated backup than from the base backup.
+ </para>
+
+ <para>
+ To make use of this capability you will need to set up a Standby database
+ on a second system, as described in <xref linkend="warm-standby">. By
+ taking a backup of the Standby server while it is running you will
+ have produced an incrementally updated backup. Once this configuration
+ has been implemented you will no longer need to produce regular base
+ backups of the Primary server: all base backups can be performed on the
+ Standby server. If you wish to do this, it is not a requirement that you
+ also implement the failover features of a Warm Standby configuration,
+ though you may find it desirable to do both.
+ </para>
+
+ </sect2>
+
<sect2 id="continuous-archiving-caveats">
<title>Caveats</title>
***************
*** 1287,1292 ****
--- 1342,1355 ----
really offers a solution for Disaster Recovery, not HA.
</para>
+ <para>
+ When running a Standby Server, backups can be performed on the Standby
+ rather than the Primary, thereby offloading the expense of
+ taking periodic base backups. (See
+ <xref linkend="backup-incremental-updated">)
+ </para>
+
+
<para>
Other mechanisms for High Availability replication are available, both
commercially and as open-source software.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
