8000 Remove docs for "Incrementally Updated Backups" because it was of · postgrespro/postgres_cluster@13e6d6c · GitHub
[go: up one dir, main page]
Skip to content

Commit 13e6d6c

Browse files
bmomjianbmomjian
committed
Remove docs for "Incrementally Updated Backups" because it was of
questionable reliability; information moved to a wiki: http://wiki.postgresql.org/wiki/Incrementally_Updated_Backups Backpatch to 9.0.
1 parent 9389ac8 commit 13e6d6c

File tree

1 file changed

+1
-92
lines changed

1 file changed

+1
-92
lines changed

‎doc/src/sgml/high-availability.sgml

Lines changed: 1 addition & 92 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.80 2010/08/24 15:22:12 momjian Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.81 2010/08/25 23:55:54 momjian Exp $ -->
22

33
<chapter id="high-availability">
44
<title>High Availability, Load Balancing, and Replication</title>
@@ -1890,95 +1890,4 @@ LOG: database system is ready to accept read only connections
18901890

18911891
</sect1>
18921892

1893-
<sect1 id="backup-incremental-updated">
1894-
<title>Incrementally Updated Backups</title>
1895-
1896-
<indexterm zone="high-availability">
1897-
<primary>incrementally updated backups</primary>
1898-
</indexterm>
1899-
1900-
<indexterm zone="high-availability">
1901-
<primary>change accumulation</primary>
1902-
</indexterm>
1903-
1904-
<para>
1905-
In a standby configuration, it is possible to offload the expense of
1906-
taking periodic base backups from the primary server; instead base backups
1907-
can be made by backing
1908-
up a standby server's files. This concept is generally known as
1909-
incrementally updated backups, log change accumulation, or more simply,
1910-
change accumulation.
1911-
</para>
1912-
1913-
<para>
1914-
If we take a file system backup of the standby server's data
1915-
directory while it is processing
1916-
logs shipped from the primary, we will be able to reload that backup and
1917-
restart the standby's recovery process from the last restart point.
1918-
We no longer need to keep WAL files from before the standby's restart point.
1919-
If recovery is needed, it will be faster to recover from the incrementally
1920-
updated backup than from the original base backup.
1921-
</para>
1922-
1923-
<para>
1924-
The procedure for taking a file system backup of the standby server's
1925-
data directory while it's processing logs shipped from the primary is:
1926-
<orderedlist>
1927-
<listitem>
1928-
<para>
1929-
Perform the backup, without using <function>pg_start_backup</> and
1930-
<function>pg_stop_backup</>. Note that the <filename>pg_control</>
1931-
file must be backed up <emphasis>first</>, as in:
1932-
<programlisting>
1933-
cp /var/lib/pgsql/data/global/pg_control /tmp
1934-
cp -r /var/lib/pgsql/data /path/to/backup
1935-
mv /tmp/pg_control /path/to/backup/data/global
1936-
</programlisting>
1937-
<filename>pg_control</> contains the location where WAL replay will
1938-
begin after restoring from the backup; backing it up first ensures
1939-
that it points to the last restartpoint when the backup started, not
1940-
some later restartpoint that happened while files were copied to the
1941-
backup.
1942-
</para>
1943-
</listitem>
1944-
<listitem>
1945-
<para>
1946-
Make note of the backup ending WAL location by calling the <function>
1947-
pg_last_xlog_replay_location</> function at the end of the backup,
1948-
and keep it with the backup.
1949-
<programlisting>
1950-
psql -c "select pg_last_xlog_replay_location();" > /path/to/backup/end_location
1951-
</programlisting>
1952-
When recovering from the incrementally updated backup, the server
1953-
can begin accepting connections and complete the recovery successfully
1954-
before the database has become consistent. To avoid that, you must
1955-
ensure the database is consistent before users try to connect to the
1956-
server and when the recovery ends. You can do that by comparing the
1957-
progress of the recovery with the stored backup ending WAL location:
1958-
the server is not consistent until recovery has reached the backup end
1959-
location. The progress of the recovery can also be observed with the
1960-
<function>pg_last_xlog_replay_location</> function, though that requires
1961-
connecting to the server while it might not be consistent yet, so
1962-
care should be taken with that method.
1963-
</para>
1964-
<para>
1965-
</para>
1966-
</listitem>
1967-
</orderedlist>
1968-
</para>
1969-
1970-
<para>
1971-
Since the standby server is not <quote>live</>, it is not possible to
1972-
use <function>pg_start_backup()</> and <function>pg_stop_backup()</>
1973-
to manage the backup process; it will be up to you to determine how
1974-
far back you need to keep WAL segment files to have a recoverable
1975-
backup. That is determined by the last restartpoint when the backup
1976-
was taken, any WAL older than that can be deleted from the archive
1977-
once the backup is complete. You can determine the last restartpoint
1978-
by running <application>pg_controldata</> on the standby server before
1979-
taking the backup, or by using the <varname>log_checkpoints</> option
1980-
to print values to the standby's server log.
1981-
</para>
1982-
</sect1>
1983-
19841893
</chapter>

0 commit comments

Comments
 (0)
0