db/pgbackrest
1
0
Fork 0
mirror of https://github.com/pgbackrest/pgbackrest.git synced 2025-03-03 14:52:21 +02:00
Code Issues Releases Activity

Updated async archiving documentation.

Browse Source 
More accurately describe how the new method works and how it differs from the old method.

Suggested by Jens Wilke.
This commit is contained in:
David Steele 2017-02-08 08:41:43 -05:00
parent 41eba95155
commit b813bfaff6
2 changed files with 18 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
doc/xml/release.xml
View File

@ -148,6 +148,20 @@
</contributor-list>
<release-list>
<release date="XXXX-XX-XX" version="1.14dev" title="UNDER DEVELOPMENT">
<release-doc-list>
<release-feature-list>
<release-item>
<release-item-contributor-list>
<release-item-ideator id="wilke.jens"/>
</release-item-contributor-list>
<p>Updated async archiving documentation to more accurately describe how the new method works and how it differs from the old method.</p>
</release-item>
</release-feature-list>
</release-doc-list>
</release>
<release date="2017-02-05" version="1.13" title="Parallel Archiving, Stanza Create, Improved Info and Check">
<release-core-list>
<p><b>IMPORTANT NOTE</b>: The new implementation of asynchronous archiving no longer copies WAL to a separate queue. If there is any WAL left over in the old queue after upgrading to <id>1.13</id>, it will be abandoned and <b>not</b> pushed to the repository.

6
doc/xml/user-guide.xml
View File

@ -1473,9 +1473,11 @@
<section id="async-archiving" depend="install-config">
<title>Asynchronous Archiving</title>
<p>The <br-option>archive-async</br-option> option offloads WAL archiving to a separate process to improve throughput. WAL segments are temporarily stored in a local queue on the database server, specified by the <br-option>spool-path</br-option> option, before being transferred to the repository on the backup server.</p>
<p>The <br-option>archive-async</br-option> option offloads WAL archiving to a separate process (or processes) to improve throughput. It works by <quote>looking ahead</quote> to see which WAL segments are ready to be archived beyond the request that <postgres/> is currently making via the <code>archive_command</code>. WAL segments are transferred to the archive directly from the <path>pg_xlog</path> directory and success is only returned by the <code>archive_command</code> when the WAL segment has been safely stored in the archive.</p>
<p>The spool directory is created to hold the WAL segments while they are waiting to be (optionally) compressed and transferred.</p>
<p>The spool directory is created to hold the current status of WAL archiving. All the information in this directory can be recreated so it is not necessary to preserve the spool directory if the cluster is moved to new hardware.</p>
<p><b>NOTE:</b> In the original implementation of asynchronous archiving, WAL segments were copied to the spool directory before compression and transfer. The new implementation copies WAL directly from the <path>pg_xlog</path> directory. If asynchronous archiving was utilized in <id>v1.12</id> or prior, read the <id>v1.13</id> release notes carefully before upgrading.</p>
<execute-list host="{[host-db-master]}">
<title>Create the spool directory</title>