Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
P
postgres-lambda-diff
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container Registry
Model registry
Operate
Environments
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Jakob Huber
postgres-lambda-diff
Commits
87ba04ee
Commit
87ba04ee
authored
20 years ago
by
Tom Lane
Browse files
Options
Downloads
Patches
Plain Diff
Add note about risks involved in replaying CREATE TABLESPACE commands
from WAL. A couple other grammatical improvements too.
parent
d27061a3
No related branches found
Branches containing commit
No related tags found
Tags containing commit
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
doc/src/sgml/backup.sgml
+24
-7
24 additions, 7 deletions
doc/src/sgml/backup.sgml
with
24 additions
and
7 deletions
doc/src/sgml/backup.sgml
+
24
−
7
View file @
87ba04ee
<!--
<!--
$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.
59
2005/03/
17
1
5
:38:
46 momjian
Exp $
$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.
60
2005/03/
23
1
9
:38:
53 tgl
Exp $
-->
-->
<chapter id="backup">
<chapter id="backup">
<title>Backup and Restore</title>
<title>Backup and Restore</title>
...
@@ -364,11 +364,12 @@ tar -cf backup.tar /usr/local/pgsql/data
...
@@ -364,11 +364,12 @@ tar -cf backup.tar /usr/local/pgsql/data
</para>
</para>
<para>
<para>
If your database is spread across multiple file systems there may not
If your database is spread across multiple file systems
,
there may not
be any way to obtain exactly-simultaneous frozen snapshots of all
be any way to obtain exactly-simultaneous frozen snapshots of all
the volumes. For example, if your data files and WAL log on different
the volumes. For example, if your data files and WAL log are on different
file disks, or if tablespaces are on different file systems, it might
disks, or if tablespaces are on different file systems, it might
not be possible to use snapshots because the snapshots must be simultaneous.
not be possible to use snapshot backup because the snapshots must be
simultaneous.
Read your file system documentation very carefully before trusting
Read your file system documentation very carefully before trusting
to the consistent-snapshot technique in such situations. The safest
to the consistent-snapshot technique in such situations. The safest
approach is to shut down the database server for long enough to
approach is to shut down the database server for long enough to
...
@@ -381,7 +382,8 @@ tar -cf backup.tar /usr/local/pgsql/data
...
@@ -381,7 +382,8 @@ tar -cf backup.tar /usr/local/pgsql/data
while the database server is running, then shutting down the database
while the database server is running, then shutting down the database
server just long enough to do a second <application>rsync</>. The
server just long enough to do a second <application>rsync</>. The
second <application>rsync</> will be much quicker than the first,
second <application>rsync</> will be much quicker than the first,
but will be consistent because the server was down. This method
because it has relatively little data to transfer, and the end result
will be consistent because the server was down. This method
allows a file system backup to be performed with minimal downtime.
allows a file system backup to be performed with minimal downtime.
</para>
</para>
...
@@ -1123,6 +1125,19 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
...
@@ -1123,6 +1125,19 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
such index after completing a recovery operation.
such index after completing a recovery operation.
</para>
</para>
</listitem>
</listitem>
<listitem>
<para>
<command>CREATE TABLESPACE</> commands are WAL-logged with the literal
absolute path, and will therefore be replayed as tablespace creations
with the same absolute path. This might be undesirable if the log is
being replayed on a different machine. It can be dangerous even if
the log is being replayed on the same machine, but into a new data
directory: the replay will still overwrite the contents of the original
tablespace. To avoid potential gotchas of this sort, the best practice
is to take a new base backup after creating or dropping tablespaces.
</para>
</listitem>
</itemizedlist>
</itemizedlist>
</para>
</para>
...
@@ -1133,7 +1148,9 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
...
@@ -1133,7 +1148,9 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
since we may need to fix partially-written disk pages. It is not
since we may need to fix partially-written disk pages. It is not
necessary to store so many page copies for PITR operations, however.
necessary to store so many page copies for PITR operations, however.
An area for future development is to compress archived WAL data by
An area for future development is to compress archived WAL data by
removing unnecessary page copies.
removing unnecessary page copies. In the meantime, administrators
may wish to reduce the number of page snapshots included in WAL by
increasing the checkpoint interval parameters as much as feasible.
</para>
</para>
</sect2>
</sect2>
</sect1>
</sect1>
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment