db/pgbackrest
1
0
Fork 0
mirror of https://github.com/pgbackrest/pgbackrest.git synced 2024-12-04 09:43:08 +02:00
Code Issues Releases Activity

Fix typo in user guide.

Browse Source
This commit is contained in:
Aleksey Tsalolikhin 2024-07-30 00:48:32 -05:00 committed by GitHub
parent 8d6bceb541
commit c42d484c9d
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -2414,7 +2414,7 @@
<p>Note that the <br-option>repo</br-option> option is not required when only <br-option>repo1</br-option> is configured in order to maintain backward compatibility. However, the <br-option>repo</br-option> option <i>is</i> required when a single repo is configured as, e.g. <br-option>repo2</br-option>. This is to prevent command breakage if a new repository is added later.</p>
<p>The <cmd>archive-push</cmd> command will always push WAL to the archive in all configured repositories. When a repository cannot be reached, WAL will still be pushed to other repositories. However, for this to work effectively, <br-setting>archive-aync=y</br-setting> must be enabled; otherwise, the other repositories can only get one WAL segment ahead of the unreachable repository. Also, note that if WAL cannot be pushed to any repository, then <postgres/> will not remove it from the <path>pg_wal</path> directory, which may cause the volume to run out of space.</p>
<p>The <cmd>archive-push</cmd> command will always push WAL to the archive in all configured repositories. When a repository cannot be reached, WAL will still be pushed to other repositories. However, for this to work effectively, <br-setting>archive-async=y</br-setting> must be enabled; otherwise, the other repositories can only get one WAL segment ahead of the unreachable repository. Also, note that if WAL cannot be pushed to any repository, then <postgres/> will not remove it from the <path>pg_wal</path> directory, which may cause the volume to run out of space.</p>
<p>Backups need to be scheduled individually for each repository. In many cases this is desirable since backup types and retention will vary by repository. Likewise, restores must specify a repository. It is generally better to specify a repository for restores that has low latency/cost even if that means more recovery time. Only restore testing can determine which repository will be most efficient.</p>
</section>