1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>23.4.Migration Between Releases</title>
<link rel="stylesheet" href="stylesheet.css" type="text/css">
<link rev="made" href="pgsql-docs@postgresql.org">
<meta name="generator" content="DocBook XSL Stylesheets V1.70.0">
<link rel="start" href="index.html" title="PostgreSQL 8.1.4 Documentation">
<link rel="up" href="backup.html" title="Chapter23.Backup and Restore">
<link rel="prev" href="backup-online.html" title="23.3.On-line backup and point-in-time recovery (PITR)">
<link rel="next" href="monitoring.html" title="Chapter24.Monitoring Database Activity">
<link rel="copyright" href="ln-legalnotice.html" title="Legal Notice">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="migration"></a>23.4.Migration Between Releases</h2></div></div></div>
<a name="id671268"></a><a name="id671277"></a><p> This section discusses how to migrate your database data from one
<span class="productname">PostgreSQL</span> release to a newer one.
The software installation procedure <span class="foreignphrase"><em class="foreignphrase">per se</em></span> is not the
subject of this section; those details are in <a href="installation.html" title="Chapter14. Installation Instructions">Chapter14, <i> Installation Instructions</i></a>.
</p>
<p> As a general rule, the internal data storage format is subject to
change between major releases of <span class="productname">PostgreSQL</span> (where
the number after the first dot changes). This does not apply to
different minor releases under the same major release (where the
number after the second dot changes); these always have compatible
storage formats. For example, releases 7.0.1, 7.1.2, and 7.2 are
not compatible, whereas 7.1.1 and 7.1.2 are. When you update
between compatible versions, you can simply replace the executables
and reuse the data directory on disk. Otherwise you need to back
up your data and restore it on the new server. This has to be done
using <span class="application">pg_dump</span>; file system level backup methods
obviously won't work. There are checks in place that prevent you
from using a data directory with an incompatible version of
<span class="productname">PostgreSQL</span>, so no great harm can be done by
trying to start the wrong server version on a data directory.
</p>
<p> It is recommended that you use the <span class="application">pg_dump</span> and
<span class="application">pg_dumpall</span> programs from the newer version of
<span class="productname">PostgreSQL</span>, to take advantage of any enhancements
that may have been made in these programs. Current releases of the
dump programs can read data from any server version back to 7.0.
</p>
<p> The least downtime can be achieved by installing the new server in
a different directory and running both the old and the new servers
in parallel, on different ports. Then you can use something like
</p>
<pre class="programlisting">pg_dumpall -p 5432 | psql -d postgres -p 6543</pre>
<p>
to transfer your data. Or use an intermediate file if you want.
Then you can shut down the old server and start the new server at
the port the old one was running at. You should make sure that the
old database is not updated after you run <span class="application">pg_dumpall</span>,
otherwise you will obviously lose that data. See <a href="client-authentication.html" title="Chapter20.Client Authentication">Chapter20, <i>Client Authentication</i></a> for information on how to prohibit
access.
</p>
<p> In practice you probably want to test your client
applications on the new setup before switching over completely.
This is another reason for setting up concurrent installations
of old and new versions.
</p>
<p> If you cannot or do not want to run two servers in parallel you can
do the backup step before installing the new version, bring down
the server, move the old version out of the way, install the new
version, start the new server, restore the data. For example:
</p>
<pre class="programlisting">pg_dumpall > backup
pg_ctl stop
mv /usr/local/pgsql /usr/local/pgsql.old
cd ~/postgresql-8.1.4
gmake install
initdb -D /usr/local/pgsql/data
postmaster -D /usr/local/pgsql/data
psql -f backup postgres</pre>
<p>
See <a href="runtime.html" title="Chapter16.Operating System Environment">Chapter16, <i>Operating System Environment</i></a> about ways to start and stop the
server and other details. The installation instructions will advise
you of strategic places to perform these steps.
</p>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
<p> When you “<span class="quote">move the old installation out of the way</span>”
it may no longer be perfectly usable. Some of the executable programs
contain absolute paths to various installed programs and data files.
This is usually not a big problem but if you plan on using two
installations in parallel for a while you should assign them
different installation directories at build time. (This problem
is rectified in <span class="productname">PostgreSQL</span> 8.0 and later, but you
need to be wary of moving older installations.)
</p>
</div>
</div></body>
</html>
|
