This section discusses how to upgrade your database data from one <productname>PostgreSQL</productname> release to a newer one. 本節ではPostgreSQLリリースからより新しいリリースにデータベースデータをアップグレードする方法を説明します。
Current <productname>PostgreSQL</productname> version numbers consist of a major and a minor version number. For example, in the version number 10.1, the 10 is the major version number and the 1 is the minor version number, meaning this would be the first minor release of the major release 10. For releases before <productname>PostgreSQL</productname> version 10.0, version numbers consist of three numbers, for example, 9.5.3. In those cases, the major version consists of the first two digit groups of the version number, e.g., 9.5, and the minor version is the third number, e.g., 3, meaning this would be the third minor release of the major release 9.5. 現在のPostgreSQLのバージョン番号はメジャーバージョンとマイナーバージョンのバージョン番号で構成されます。 例えばバージョン番号10.1は、10がメジャーバージョンで、1がマイナーバージョンです。メジャーリリース10の最初のマイナーリリースを意味します。 PostgreSQLの10.0より前のバージョンは, ３つの番号で構成されています。例えば9.5.3です。 この場合は、メジャーバージョンが最初の２つのグループのバージョン番号、例えば9.5で構成されています。 そしてマイナーバージョンは３つ目の番号で例えば3です。これはメジャーリリース9.5の３番めのマイナーリリースを意味します。
Minor releases never change the internal storage format and are always compatible with earlier and later minor releases of the same major version number. For example, version 10.1 is compatible with version 10.0 and version 10.6. Similarly, for example, 9.5.3 is compatible with 9.5.0, 9.5.1, and 9.5.6. To update between compatible versions, you simply replace the executables while the server is down and restart the server. The data directory remains unchanged — minor upgrades are that simple. マイナーリリースでは内部格納書式が変わることは決してありませんので、同じメジャーバージョンにおける前後のマイナーリリースとの間で常に互換性があります。 例えばバージョン10.1はバージョン10.0やバージョン10.6と互換性があります。 同様に、例えば9.5.3は9.5.0、9.5.1、9.5.6と互換性があります。 互換性があるバージョンとの間で更新するためには、サーバを停止させ、実行ファイルを置き換え、サーバを再起動させるだけです。 データディレクトリはまったく変更されません。 マイナーリリースのアップグレードは簡単です。
For <emphasis>major</emphasis> releases of <productname>PostgreSQL</productname>, the internal data storage format is subject to change, thus complicating upgrades. The traditional method for moving data to a new major version is to dump and restore the database, though this can be slow. A faster method is <xref linkend="pgupgrade"/>. Replication methods are also available, as discussed below. (If you are using a pre-packaged version of <productname>PostgreSQL</productname>, it may provide scripts to assist with major version upgrades. Consult the package-level documentation for details.) PostgreSQLのメジャーリリースでは、内部データ格納書式は変更されがちです。 したがって、アップグレードは複雑になります。 新しいメジャーバージョンにデータを移行する伝統的な方法は、遅くなることがありますが、データベースをダンプしてリストアすることです。 より速い方法については、pg_upgradeを参照してください。以下で説明するようにレプリケーションを使用する方法もあります。 （パッケージ化された版のPostgreSQLを使用している場合は、主要バージョンのアップグレードを支援するスクリプトが提供される場合があります。 詳細についてはパッケージレベルのドキュメントを参照してください。）
New major versions also typically introduce some user-visible incompatibilities, so application programming changes might be required. All user-visible changes are listed in the release notes (<xref linkend="release"/>); pay particular attention to the section labeled "Migration". Though you can upgrade from one major version to another without upgrading to intervening versions, you should read the major release notes of all intervening versions. 新しいメジャーバージョンは通常、ユーザにも影響する非互換性がいくつか導入されます。 このためアプリケーションのプログラム変更が必要になる可能性があります。 ユーザに影響する変更はすべてリリースノート（付録E）に列挙されています。 「移行」という名前の節に特に注意してください。 あるメジャーバージョンから他のメジャーバージョンへと途中のバージョンを経由しないでアップグレードできますが、途中のバージョンすべてのリリースノートを確認してください。
Cautious users will want to test their client applications on the new version before switching over fully; therefore, it's often a good idea to set up concurrent installations of old and new versions. When testing a <productname>PostgreSQL</productname> major upgrade, consider the following categories of possible changes: 用心深いユーザは、完全に切り替える前に新しいバージョンにおける自身のクライアントアプリケーションを試験したいと考えるでしょう。 このため古いバージョンと新しいバージョンを並行してインストールさせるというのは、よく良い考えとなります。 PostgreSQLメジャーアップグレードを試験する時、以下に示す変更があり得る分野を検討してください。
The capabilities available for administrators to monitor and control the server often change and improve in each major release. 各メジャーリリースにおいて、管理者が利用できるサーバの監視、制御機能はよく変更、向上されます。
Typically this includes new SQL command capabilities and not changes in behavior, unless specifically mentioned in the release notes. 通常、これには新しいSQLコマンド機能が含まれます。 リリースノートに特に記載がない限りその動作には変更はありません。
Typically libraries like <application>libpq</application> only add new functionality, again unless mentioned in the release notes. 繰り返しになりますが、リリースノートに記載がない場合のみですが、通常libpqのようなライブラリには新しい機能が追加されるだけです。
System catalog changes usually only affect database management tools. システムカタログの変更は通常データベース管理用ツールにのみ影響します。
This involves changes in the backend function API, which is written in the C programming language. Such changes affect code that references backend functions deep inside the server. ここには、Cプログラム言語で作成されたバックエンド関数APIにおける変更が含まれます。 こうした変更は、サーバ内部深くにあるバックエンド関数を参照するコードに影響します。
One upgrade method is to dump data from one major version of <productname>PostgreSQL</productname> and restore it in another — to do this, you must use a <emphasis>logical</emphasis> backup tool like <application>pg_dumpall</application>; file system level backup methods will not work. (There are checks in place that prevent you from using a data directory with an incompatible version of <productname>PostgreSQL</productname>, so no great harm can be done by trying to start the wrong server version on a data directory.) PostgreSQLのアップグレードの一つの方法は、PostgreSQLの１メジャーバージョンからデータをダンプし、別のバージョンにリストアすることです - これを行うには、pg_dumpallのような論理バックアップツールを使用しなければなりません。 ファイルシステムレベルのバックアップ方法は動作しません。 （あるデータディレクトリで間違ったバージョンのサーバを起動しようとして、大きな損害が起こることがないように、適所に互換性がないバージョンのPostgreSQLのデータディレクトリが使用されないようにするための検査があります。）
It is recommended that you use the <application>pg_dump</application> and <application>pg_dumpall</application> programs from the <emphasis>newer</emphasis> version of <productname>PostgreSQL</productname>, to take advantage of enhancements that might have been made in these programs. Current releases of the dump programs can read data from any server version back to 9.2. 新しいバージョンのPostgreSQLのpg_dumpとpg_dumpallを使用することを勧めます。 これらのプログラムで拡張された機能を利用する可能性があるためです。 現在のリリースのダンププログラムは9.2以降のバージョンのサーバからデータを読み取ることができます。
These instructions assume that your existing installation is under the
<filename>/usr/local/pgsql</filename> directory, and that the data area is in
<filename>/usr/local/pgsql/data</filename>. Substitute your paths
appropriately.
以下の手順では、既存のインストレーションが/usr/local/pgsql以下にあり、そのデータ領域が/usr/local/pgsql/dataにあることを前提としています。
使用しているパスに適切に置き換えてください。
If making a backup, make sure that your database is not being updated.
This does not affect the integrity of the backup, but the changed
data would of course not be included. If necessary, edit the
permissions in the file <filename>/usr/local/pgsql/data/pg_hba.conf</filename>
(or equivalent) to disallow access from everyone except you.
See <xref linkend="client-authentication"/> for additional information on
access control.
バックアップを作成する場合、使用しているデータベースが確実に更新されないようにしてください。
これはバックアップの整合性には影響しませんが、当然ながら変更されたデータがバックアップに含まれません。
必要に応じて、/usr/local/pgsql/data/pg_hba.conf（またはこれと等価なファイル）における権限を変更して、バックアップを行うユーザ以外からのアクセスを禁止してください。
アクセス制御に関する情報は第20章を参照してください。
To back up your database installation, type: データベースインストレーションをバックアップするためには以下を入力してください。
pg_dumpall > outputfile
To make the backup, you can use the <application>pg_dumpall</application> command from the version you are currently running; see <xref linkend="backup-dump-all"/> for more details. For best results, however, try to use the <application>pg_dumpall</application> command from <productname>PostgreSQL</productname> &version;, since this version contains bug fixes and improvements over older versions. While this advice might seem idiosyncratic since you haven't installed the new version yet, it is advisable to follow it if you plan to install the new version in parallel with the old version. In that case you can complete the installation normally and transfer the data later. This will also decrease the downtime. バックアップを作成するために、現在起動中のバージョンのpg_dumpallコマンドを使用することができます。詳細は25.1.2 を参照してください。 しかし最善の結果を得るためには、PostgreSQL 17.0のpg_dumpallコマンドを試してください。 このバージョンでは、過去のバージョンに対して、不具合の修正や改良が含まれているからです。 新しいバージョンをまだインストールしていませんので、この勧告は奇異に思えるかもしれませんが、古いバージョンと並行して新しいバージョンをインストールすることを計画しているのであれば、これに従うことを推奨します。 この場合、インストールを普通に完了させてからデータを移行することができます。 これは同時に停止時間を短縮します。
Shut down the old server: 古いサーバを停止します。
pg_ctl stop
On systems that have <productname>PostgreSQL</productname> started at boot time, there is probably a start-up file that will accomplish the same thing. For example, on a <systemitem class="osname">Red Hat Linux</systemitem> system one might find that this works: 起動時にPostgreSQLを実行させるようにしているシステムではおそらく、同じことを達成する起動ファイルがあります。 例えばRed Hat Linuxシステムでは、以下が動作することが分かります。
/etc/rc.d/init.d/postgresql stop
See <xref linkend="runtime"/> for details about starting and stopping the server. サーバの起動と停止については第18章を参照してください。
If restoring from backup, rename or delete the old installation directory if it is not version-specific. It is a good idea to rename the directory, rather than delete it, in case you have trouble and need to revert to it. Keep in mind the directory might consume significant disk space. To rename the directory, use a command like this: バックアップからリストアする場合、名前を変更、またはバージョン固有でない場合は古いインストレーションディレクトリを削除してください。 問題があった場合に戻さなければならない場合に備え、削除するよりディレクトリの名前を変更する方を勧めます。 このディレクトリが多くのディスク容量を占めている可能性があることに注意してください。 ディレクトリの名前を変更するためには、以下のようなコマンドを使用してください。
mv /usr/local/pgsql /usr/local/pgsql.old
(Be sure to move the directory as a single unit so relative paths remain unchanged.) （相対パスが維持されるように確実にディレクトリ単位で移動してください。）
Install the new version of <productname>PostgreSQL</productname> as outlined in <xref linkend="installation"/>. 概要を第17章で示すように、新しいバージョンのPostgreSQLをインストールしてください。
Create a new database cluster if needed. Remember that you must execute these commands while logged in to the special database user account (which you already have if you are upgrading). 必要に応じて新しいデータベースクラスタを作成してください。 （アップグレードの場合はすでに存在している）特別なデータベースユーザアカウントでログインして、このコマンドを実行しなければならないことに注意してください。
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
Restore your previous <filename>pg_hba.conf</filename> and any
<filename>postgresql.conf</filename> modifications.
以前のpg_hba.confとpostgresql.confに加えた何らかの変更を戻してください。
Start the database server, again using the special database user account: 繰り返しになりますが、特別なデータベースユーザアカウントを使用して、データベースサーバを起動してください。
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
Finally, restore your data from backup with: 最後に、バックアップからデータをリストアしてください。
/usr/local/pgsql/bin/psql -d postgres -f outputfile
using the <emphasis>new</emphasis> <application>psql</application>. 新しいpsqlを使用します。
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: 新しいサーバを異なるディレクトリにインストールし、古いサーバと新しいサーバを別のポートで並行して実行させることで、停止時間を最小にすることができます。 この場合、データを移行するために以下のようなコマンドを使用することができます。
pg_dumpall -p 5432 | psql -d postgres -p 5433
to transfer your data.
The <xref linkend="pgupgrade"/> module allows an installation to
be migrated in-place from one major <productname>PostgreSQL</productname>
version to another. Upgrades can be performed in minutes,
particularly with <option>--link</option> mode. It requires steps similar to
<application>pg_dumpall</application> above, e.g., starting/stopping the server,
running <application>initdb</application>. The <application>pg_upgrade</application> <link
linkend="pgupgrade">documentation</link> outlines the necessary steps.
pg_upgradeモジュールにより、PostgreSQLのあるバージョンから次のバージョンにインストレーションをその場で移行することができます。
特に--linkオプションを使用することで、アップグレードは数分で行うことができます。
これは、pg_dumpallと同様の工程を必要とします。
例えば、initdbを実行し、サーバの起動／停止をおこないます。
pg_upgrade ドキュメントで必要な手順を説明します。
It is also possible to use logical replication methods to create a standby server with the updated version of <productname>PostgreSQL</productname>. This is possible because logical replication supports replication between different major versions of <productname>PostgreSQL</productname>. The standby can be on the same computer or a different computer. Once it has synced up with the primary server (running the older version of <productname>PostgreSQL</productname>), you can switch primaries and make the standby the primary and shut down the older database instance. Such a switch-over results in only several seconds of downtime for an upgrade. 論理レプリケーションを使って更新対象のバージョンのPostgreSQLをスタンバイサーバとして作成することもできます。 論理レプリケーションが異なるメジャーバージョンのPostgreSQLの間でレプリケーションすることができるため、これが実現できます。 スタンバイは同じコンピュータで作成することも異なるコンピュータで作成することもできます。 （古いバージョンのPostgreSQLで実行している）プライマリサーバと同期した後、プライマリを切り替え、スタンバイをプライマリにし、古いデータベースインスタンスを停止することができます。 このようなスイッチオーバーの結果、数秒の停止時間でアップグレードされます。
This method of upgrading can be performed using the built-in logical replication facilities as well as using external logical replication systems such as <productname>pglogical</productname>, <productname>Slony</productname>, <productname>Londiste</productname>, and <productname>Bucardo</productname>. この方法によるアップグレードは、組み込みの論理レプリケーション機能か、あるいはpglogical、Slony、Londiste、Bucardoなどの外部の論理レプリケーションシステムを使うことで実施できます。