Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit3a3d3f9

Browse files
committed
upgrade docs: highlight pg_upgrade, warn about globals preservation
Also, remove OID preservation mention, mention non-text dump formatsBackpatch through 9.4
1 parent3435693 commit3a3d3f9

File tree

2 files changed

+44
-30
lines changed

2 files changed

+44
-30
lines changed

‎doc/src/sgml/backup.sgml‎

Lines changed: 15 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -28,7 +28,7 @@
2828
<title><acronym>SQL</> Dump</title>
2929

3030
<para>
31-
The idea behind this dump method is to generate atextfile with SQL
31+
The idea behind this dump method is to generate a file with SQL
3232
commands that, when fed back to the server, will recreate the
3333
database in the same state as it was at the time of the dump.
3434
<productname>PostgreSQL</> provides the utility program
@@ -39,6 +39,9 @@ pg_dump <replaceable class="parameter">dbname</replaceable> &gt; <replaceable cl
3939
</synopsis>
4040
As you see, <application>pg_dump</> writes its result to the
4141
standard output. We will see below how this can be useful.
42+
While the above command creates a text file, <application>pg_dump</>
43+
can create files in other formats that allow for parallism and more
44+
fine-grained control of object restoration.
4245
</para>
4346

4447
<para>
@@ -98,20 +101,11 @@ pg_dump <replaceable class="parameter">dbname</replaceable> &gt; <replaceable cl
98101
exclusive lock, such as most forms of <command>ALTER TABLE</command>.)
99102
</para>
100103

101-
<important>
102-
<para>
103-
If your database schema relies on OIDs (for instance, as foreign
104-
keys) you must instruct <application>pg_dump</> to dump the OIDs
105-
as well. To do this, use the <option>-o</option> command-line
106-
option.
107-
</para>
108-
</important>
109-
110104
<sect2 id="backup-dump-restore">
111105
<title>Restoring the Dump</title>
112106

113107
<para>
114-
The text files created by <application>pg_dump</> are intended to
108+
Text files created by <application>pg_dump</> are intended to
115109
be read in by the <application>psql</application> program. The
116110
general command form to restore a dump is
117111
<synopsis>
@@ -127,6 +121,8 @@ psql <replaceable class="parameter">dbname</replaceable> &lt; <replaceable class
127121
supports options similar to <application>pg_dump</> for specifying
128122
the database server to connect to and the user name to use. See
129123
the <xref linkend="app-psql"> reference page for more information.
124+
Non-text file dumps are restored using the <xref
125+
linkend="app-pgrestore"> utility.
130126
</para>
131127

132128
<para>
@@ -225,7 +221,14 @@ psql -f <replaceable class="parameter">infile</replaceable> postgres
225221
roles, tablespaces, and empty databases, then invoking
226222
<application>pg_dump</> for each database. This means that while
227223
each database will be internally consistent, the snapshots of
228-
different databases might not be exactly in-sync.
224+
different databases are not sychronized.
225+
</para>
226+
227+
<para>
228+
Cluster-wide data can be dumped alone using the
229+
<application>pg_dumpall</> <option>--globals-only</> option.
230+
This is necessary to fully backup the cluster if running the
231+
<application>pg_dump</> command on individual databases.
229232
</para>
230233
</sect2>
231234

‎doc/src/sgml/runtime.sgml‎

Lines changed: 29 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -1509,8 +1509,9 @@ $ <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput
15091509
For <emphasis>major</> releases of <productname>PostgreSQL</>, the
15101510
internal data storage format is subject to change, thus complicating
15111511
upgrades. The traditional method for moving data to a new major version
1512-
is to dump and reload the database. Other methods are available,
1513-
as discussed below.
1512+
is to dump and reload the database, though this can be slow. A
1513+
faster method is <xref linkend="pgupgrade">. Replication methods are
1514+
also available, as discussed below.
15141515
</para>
15151516

15161517
<para>
@@ -1585,12 +1586,14 @@ $ <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput
15851586

15861587
</variablelist>
15871588

1588-
<sect2 id="upgrade-methods-pgdump">
1589-
<title>Upgrading Data via <application>pg_dump</></title>
1589+
<sect2 id="upgrading-via-pgdumpall">
1590+
<title>Upgrading Data via <application>pg_dumpall</></title>
15901591

15911592
<para>
1592-
To dump data from one major version of <productname>PostgreSQL</> and
1593-
reload it in another, you must use <application>pg_dump</>; file system
1593+
One upgrade method is to dump data from one major version of
1594+
<productname>PostgreSQL</> and reload it in another &mdash; to do
1595+
this, you must use a <emphasis>logical</> backup tool like
1596+
<application>pg_dumpall</>; file system
15941597
level backup methods will not work. (There are checks in place that prevent
15951598
you from using a data directory with an incompatible version of
15961599
<productname>PostgreSQL</productname>, so no great harm can be done by
@@ -1599,7 +1602,8 @@ $ <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput
15991602

16001603
<para>
16011604
It is recommended that you use the <application>pg_dump</> and
1602-
<application>pg_dumpall</> programs from the newer version of
1605+
<application>pg_dumpall</> programs from the <emphasis>newer</>
1606+
version of
16031607
<productname>PostgreSQL</>, to take advantage of enhancements
16041608
that might have been made in these programs. Current releases of the
16051609
dump programs can read data from any server version back to 7.0.
@@ -1634,14 +1638,12 @@ $ <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput
16341638
<screen>
16351639
<userinput>pg_dumpall &gt; <replaceable>outputfile</></userinput>
16361640
</screen>
1637-
If you need to preserve OIDs (such as when using them as
1638-
foreign keys), then use the <option>-o</option> option when running
1639-
<application>pg_dumpall</>.
16401641
</para>
16411642

16421643
<para>
16431644
To make the backup, you can use the <application>pg_dumpall</application>
1644-
command from the version you are currently running. For best
1645+
command from the version you are currently running; see <xref
1646+
linkend="backup-dump-all"> for more details. For best
16451647
results, however, try to use the <application>pg_dumpall</application>
16461648
command from <productname>PostgreSQL</productname> &version;,
16471649
since this version contains bug fixes and improvements over older
@@ -1675,7 +1677,8 @@ $ <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput
16751677
<step>
16761678
<para>
16771679
If restoring from backup, rename or delete the old installation
1678-
directory. It is a good idea to rename the directory, rather than
1680+
directory if it is not version-specific. It is a good idea to
1681+
rename the directory, rather than
16791682
delete it, in case you have trouble and need to revert to it. Keep
16801683
in mind the directory might consume significant disk space. To rename
16811684
the directory, use a command like this:
@@ -1747,16 +1750,24 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433
17471750

17481751
</sect2>
17491752

1750-
<sect2 id="upgrading-methods-other">
1751-
<title>Non-Dump Upgrade Methods</title>
1753+
<sect2 id="upgrading-via-pg-upgrade">
1754+
<title>Upgrading Data via <application>pg_upgrade</></title>
17521755

17531756
<para>
1754-
The <link linkend="pgupgrade">pg_upgrade</link> module allows an
1755-
installation to be migrated in-place from one major
1756-
<productname>PostgreSQL</> version to the next. Upgrades can be
1757-
performed in minutes.
1757+
The <xref linkend="pgupgrade"> module allows an installation to
1758+
be migrated in-place from one major <productname>PostgreSQL</>
1759+
version to another. Upgrades can be performed in minutes,
1760+
particularly with <option>--link</> mode. It requires steps similar to
1761+
<application>pg_dumpall</> above, e.g. starting/stopping the server,
1762+
running <application>initdb</>. The <application>pg_upgrade</> <link
1763+
linkend="pgupgrade">documentation</> outlines the necessary steps.
17581764
</para>
17591765

1766+
</sect2>
1767+
1768+
<sect2 id="upgrading-via-replication">
1769+
<title>Upgrading Data via Replication</title>
1770+
17601771
<para>
17611772
It is also possible to use certain replication methods, such as
17621773
<productname>Slony</>, to create a standby server with the updated version of

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp