バージョンごとのドキュメント一覧

pg_upgrade

pg_upgrade <refpurpose>upgrade a <productname>PostgreSQL</productname> server instance</refpurpose> PostgreSQLサーバインスタンスをアップグレードする

概要

pg_upgrade -b oldbindir [-B newbindir] -d oldconfigdir -D newconfigdir [option...]

説明

<title>Description</title>

<application>pg_upgrade</application> (formerly called <application>pg_migrator</application>) allows data stored in <productname>PostgreSQL</productname> data files to be upgraded to a later <productname>PostgreSQL</productname> major version without the data dump/restore typically required for major version upgrades, e.g., from 9.5.8 to 9.6.4 or from 10.7 to 11.2. It is not required for minor version upgrades, e.g., from 9.6.2 to 9.6.3 or from 10.1 to 10.2. pg_upgrade(これまではpg_migratorと呼ばれていました)を使用することで、メジャーバージョンのアップグレード、例えば、9.5.8から9.6.4へ、10.7から11.2へのアップグレードで通常必要とされるデータのダンプ/リストアを行うことなく、PostgreSQLデータファイル内に格納されたデータをより最新のPostgreSQLメジャーバージョンに移行できます。 これは、例えば9.6.2から9.6.3、10.1から10.2などマイナーバージョンのアップグレードでは必要ありません。

Major PostgreSQL releases regularly add new features that often change the layout of the system tables, but the internal data storage format rarely changes. <application>pg_upgrade</application> uses this fact to perform rapid upgrades by creating new system tables and simply reusing the old user data files. If a future major release ever changes the data storage format in a way that makes the old data format unreadable, <application>pg_upgrade</application> will not be usable for such upgrades. (The community will attempt to avoid such situations.) PostgreSQLのメジャーリリースでは通常、システムテーブルのレイアウトをよく変更する、多くの機能が追加されます。 しかし内部データの格納書式はまれにしか変更されません。 pg_upgradeはこの事実を使用して、システムテーブルを新しく作成し、古いユーザデータファイルを単に再利用することで、高速なアップグレードを実施します。 将来のメジャーリリースでついに古いデータ書式を読み取ることができなくなるようにデータ格納書式を変更した場合、pg_upgradeではこうしたアップグレードを扱うことができません。 (コミュニティはこうした状況を防ごうと考えています。)

<application>pg_upgrade</application> does its best to make sure the old and new clusters are binary-compatible, e.g., by checking for compatible compile-time settings, including 32/64-bit binaries. It is important that any external modules are also binary compatible, though this cannot be checked by <application>pg_upgrade</application>. pg_upgradeは古いクラスタと新しいクラスタとの間で、例えばコンパイル時の設定に互換性があるかどうか、32ビットバイナリか64ビットバイナリかなど、バイナリ互換性があることを確実にするために最善を尽くします。 任意の外部モジュールがバイナリ互換であることも重要ですが、これはpg_upgradeでは検査することができません。

pg_upgrade supports upgrades from 9.2.X and later to the current major release of <productname>PostgreSQL</productname>, including snapshot and beta releases. pg_upgradeは9.2.X以降から現時点のPostgreSQLのメジャーリリース(スナップショット版やβリリースを含む)へのアップグレードをサポートします。

オプション

<title>Options</title>

<application>pg_upgrade</application> accepts the following command-line arguments: pg_upgradeは以下のコマンドライン引数を受け付けます。

-b bindir
--old-bindir=bindir

古いPostgreSQLの実行ファイル格納ディレクトリ。PGBINOLD環境変数

-B bindir
--new-bindir=bindir

新しいPostgreSQLの実行ファイル格納ディレクトリ。デフォルトはpg_upgradeのあるディレクトリ。PGBINNEW環境変数

-c
--check

クラスタの検査のみを行い、データの変更を行いません。

-d configdir
--old-datadir=configdir

古いクラスタの設定データディレクトリ。PGDATAOLD環境変数

-D configdir
--new-datadir=configdir

新しいクラスタの設定データディレクトリ。PGDATANEW環境変数

-j njobs
--jobs=njobs

使用する同時実行プロセスまたはスレッド数。

-k
--link

新しいクラスタにファイルをコピーするのではなく、ハードリンクを使用します。

-N
--no-sync

By default, <command>pg_upgrade</command> will wait for all files of the upgraded cluster to be written safely to disk. This option causes <command>pg_upgrade</command> to return without waiting, which is faster, but means that a subsequent operating system crash can leave the data directory corrupt. Generally, this option is useful for testing but should not be used on a production installation. デフォルトでは、pg_upgradeはアップグレードされたクラスタのすべてのファイルが安全にディスクに書き込まれるのを待ちます。 このオプションでpg_upgradeは待たずに戻るようになります。これはより高速ですが、その後のオペレーティングシステムのクラッシュによってデータディレクトリが壊れたままになる可能性があることを意味します。 一般的に、このオプションは試験するには有用ですが、実稼働環境では使用すべきではありません。

-o options
--old-options options

古いpostgresコマンドに直接渡すオプションです。複数の起動オプションが追加されます。

-O options
--new-options options

新しいpostgresコマンドに直接渡すオプションです。複数の起動オプションが追加されます。

-p port
--old-port=port

古いクラスタのポート番号。PGPORTOLD環境変数

-P port
--new-port=port

新しいクラスタのポート番号。PGPORTNEW環境変数

-r
--retain

正常に完了した場合であってもSQLファイルとログファイルを保持します。

-s dir
--socketdir=dir

アップグレード中にpostmasterソケット用に利用するディレクトリ。デフォルトは現在の作業ディレクトリです。環境変数PGSOCKETDIR

-U username
--username=username

クラスタのインストールユーザの名称。PGUSER環境変数

-v
--verbose

冗長な内部ログを有効にします。

-V
--version

バージョン情報を表示し、終了します。

--clone

Use efficient file cloning (also known as <quote>reflinks</quote> on some systems) instead of copying files to the new cluster. This can result in near-instantaneous copying of the data files, giving the speed advantages of <option>-k</option>/<option>&#45;-link</option> while leaving the old cluster untouched. 新しいクラスタにファイルをコピーする代わりに、効率的なファイルの複製(システムのいくつかではreflinkとしても知られています)を使います。 これは、データファイルをほぼ瞬間的にコピーし、古いクラスタに手をつけずに-k/--linkの速度の利点を与えることになるでしょう、

File cloning is only supported on some operating systems and file systems. If it is selected but not supported, the <application>pg_upgrade</application> run will error. At present, it is supported on Linux (kernel 4.5 or later) with Btrfs and XFS (on file systems created with reflink support), and on macOS with APFS. ファイルの複製はいくつかのオペレーティングシステムとファイルシステムでのみサポートされています。 選択されたもののサポートされていなければ、pg_upgradeの実行はエラーになります。 現在のところ、BtrfsとXFS(のreflinkサポート付きで作られたファイルシステム)のLinux(カーネル4.5以降)と、APFSのmacOSでサポートされています。

--copy

Copy files to the new cluster. This is the default. (See also <option>&#45;-link</option> and <option>&#45;-clone</option>.) 新しいクラスタにファイルをコピーします。 これがデフォルトです。 (--linkおよび--cloneも参照してください。)

-?
--help

使用方法を表示し、終了します。

使用方法

<title>Usage</title>

These are the steps to perform an upgrade with <application>pg_upgrade</application>: pg_upgradeを用いたアップグレードを行う手順を示します。

  1. <title>Optionally move the old cluster</title>

    古いクラスタの移動(省略可能)

    If you are using a version-specific installation directory, e.g., <filename>/opt/PostgreSQL/&majorversion;</filename>, you do not need to move the old cluster. The graphical installers all use version-specific installation directories. バージョンに関連したインストレーションディレクトリ(例えば/opt/PostgreSQL/16)を使用しているのであれば、古いクラスタを移動する必要はありません。 グラフィカルインストーラはすべて、バージョンに関連したインストレーションディレクトリを使用します。

    If your installation directory is not version-specific, e.g., <filename>/usr/local/pgsql</filename>, it is necessary to move the current PostgreSQL install directory so it does not interfere with the new <productname>PostgreSQL</productname> installation. Once the current <productname>PostgreSQL</productname> server is shut down, it is safe to rename the PostgreSQL installation directory; assuming the old directory is <filename>/usr/local/pgsql</filename>, you can do: インストレーションディレクトリがバージョンに関連していない(例えば/usr/local/pgsql)のであれば、新しいPostgreSQLのインストレーションに干渉しないように、現在のPostgreSQLインストレーションディレクトリを移動しなければなりません。 一度現在のPostgreSQLサーバを停止させていれば、PostgreSQLのインストレーションの名前を変更しても安全です。 古いディレクトリが/usr/local/pgsqlであれば、以下のようにディレクトリ名を変更します。

    mv /usr/local/pgsql /usr/local/pgsql.old
    

    to rename the directory.

  2. <title>For source installs, build the new version</title>

    ソースからのインストールの場合の新しいバージョンの構築

    Build the new PostgreSQL source with <command>configure</command> flags that are compatible with the old cluster. <application>pg_upgrade</application> will check <command>pg_controldata</command> to make sure all settings are compatible before starting the upgrade. 古いクラスタと互換性を持つようなconfigureオプションを付けて新しいPostgreSQLソースを構築してください。 pg_upgradeはアップグレードを始める前にすべての設定が互換性を持っていることを確認するためにpg_controldataを検査します。

  3. <title>Install the new PostgreSQL binaries</title>

    新しいPostgreSQLのバイナリのインストール

    Install the new server's binaries and support files. <application>pg_upgrade</application> is included in a default installation. 新しいサーバのバイナリとサポートファイルをインストールしてください。 pg_upgradeはデフォルトのインストレーションに含まれています。

    For source installs, if you wish to install the new server in a custom location, use the <literal>prefix</literal> variable: ソースからインストールする場合、独自の場所に新しいサーバをインストールしたければ、以下のようにprefixを使用してください。

    make prefix=/usr/local/pgsql.new install
    
  4. <title>Initialize the new PostgreSQL cluster</title>

    新しいPostgreSQLクラスタを初期化

    Initialize the new cluster using <command>initdb</command>. Again, use compatible <command>initdb</command> flags that match the old cluster. Many prebuilt installers do this step automatically. There is no need to start the new cluster. initdbを使用して新しいクラスタを初期化してください。 ここでも、古いクラスタに合うように互換性があるinitdbのオプションを使用してください。 あらかじめ組み込まれたインストーラの多くは、この手順を自動的に実施します。 新しいクラスタを起動する必要はありません。

  5. <title>Install extension shared object files</title>

    拡張共有オブジェクトファイルをインストール

    Many extensions and custom modules, whether from <filename>contrib</filename> or another source, use shared object files (or DLLs), e.g., <filename>pgcrypto.so</filename>. If the old cluster used these, shared object files matching the new server binary must be installed in the new cluster, usually via operating system commands. Do not load the schema definitions, e.g., <command>CREATE EXTENSION pgcrypto</command>, because these will be duplicated from the old cluster. If extension updates are available, <application>pg_upgrade</application> will report this and create a script that can be run later to update them. contribからのものであろうとその他のソースからのものであろうと、多くの拡張や独自のモジュールは、例えばpgcrypto.soなどの独自の共有オブジェクトファイル(またはDLL)を使います。 古いクラスタがこれらを使用していたのであれば、新しいサーバのバイナリに合った共有オブジェクトファイルを、たいていはオペレーティングシステムのコマンドで、新しいクラスタにインストールしなければなりません。 例えばCREATE EXTENSION pgcryptoなどのスキーマ定義はロードしないでください。これらは古いクラスタから複製されるためです。 拡張アップデートが利用可能であれば、pg_upgradeはこれを報告し、アップデートのために後で実行できるスクリプトを作成します。

  6. <title>Copy custom full-text search files</title>

    独自の全文検索ファイルをコピー

    Copy any custom full text search files (dictionary, synonym, thesaurus, stop words) from the old to the new cluster. 独自の全文検索ファイル(辞書、同義語、類語辞書、ストップワード)を古いクラスタから新しいクラスタにコピーしてください。

  7. <title>Adjust authentication</title>

    認証の調整

    <command>pg_upgrade</command> will connect to the old and new servers several times, so you might want to set authentication to <literal>peer</literal> in <filename>pg_hba.conf</filename> or use a <filename>~/.pgpass</filename> file (see <xref linkend="libpq-pgpass"/>). pg_upgradeは古いサーバと新しいサーバに複数回接続します。 このため、pg_hba.conf内でpeer認証に設定、あるいは、~/.pgpassファイル(34.16参照)を使用するようにした方が良いかもしれません。

  8. <title>Stop both servers</title>

    両サーバの停止

    Make sure both database servers are stopped using, on Unix, e.g.: 両サーバが停止していることを確実にしてください。 例えばUnixでは以下を使用します。

    pg_ctl -D /opt/PostgreSQL/9.6 stop
    pg_ctl -D /opt/PostgreSQL/16 stop
    

    or on Windows, using the proper service names: Windowsでは以下

    NET STOP postgresql-9.6
    NET STOP postgresql-16
    

    Streaming replication and log-shipping standby servers can remain running until a later step. ストリーミングレプリケーションおよびログシッピングのスタンバイサーバは、後のステップまで実行中のまま残すことができます。

  9. <title>Prepare for standby server upgrades</title>

    スタンバイサーバのアップグレードの準備

    If you are upgrading standby servers using methods outlined in section <xref linkend="pgupgrade-step-replicas"/>, verify that the old standby servers are caught up by running <application>pg_controldata</application> against the old primary and standby clusters. Verify that the <quote>Latest checkpoint location</quote> values match in all clusters. (There will be a mismatch if old standby servers were shut down before the old primary or if the old standby servers are still running.) Also, make sure <varname>wal_level</varname> is not set to <literal>minimal</literal> in the <filename>postgresql.conf</filename> file on the new primary cluster. スタンバイサーバをステップ 11の節で示した手順でアップグレードする場合は、pg_controldataを実行して、古いスタンバイサーバが、古いプライマリ及びスタンバイのクラスタに同期していることを確認してください。 すべてのクラスタでLatest checkpoint location(最終チェックポイント位置)の値が一致することを確認してください。 (古いスタンバイサーバが、古いプライマリより先にシャットダウンされた場合、もしくは古いスタンバイサーバがまだ稼働中の場合は一致しないでしょう。) また、新しいプライマリのクラスタのpostgresql.confファイルでwal_levelminimalに絶対に設定しないようにしてください。

  10. <title>Run <application>pg_upgrade</application></title>

    pg_upgradeの実行

    Always run the <application>pg_upgrade</application> binary of the new server, not the old one. <application>pg_upgrade</application> requires the specification of the old and new cluster's data and executable (<filename>bin</filename>) directories. You can also specify user and port values, and whether you want the data files linked or cloned instead of the default copy behavior. 古いサーバのものではなく、常に新しいサーバのpg_upgradeバイナリを実行してください。 pg_upgradeは古いクラスタおよび新しいクラスタのデータと実行形式ファイルの格納ディレクトリ(bin)の指定を要求します。 また、ユーザやポート番号の指定や、デフォルト動作のコピーではなくデータファイルのリンクや複製を使用するかどうかを指定することができます。

    If you use link mode, the upgrade will be much faster (no file copying) and use less disk space, but you will not be able to access your old cluster once you start the new cluster after the upgrade. Link mode also requires that the old and new cluster data directories be in the same file system. (Tablespaces and <filename>pg_wal</filename> can be on different file systems.) Clone mode provides the same speed and disk space advantages but does not cause the old cluster to be unusable once the new cluster is started. Clone mode also requires that the old and new data directories be in the same file system. This mode is only available on certain operating systems and file systems. リンクモードを使用する場合、アップグレードは非常に高速になり(ファイルのコピーがありません)、ディスク容量が少なくなりますが、アップグレード後に新しいクラスタを一度でも実行してしまうと、古いクラスタにアクセスすることができなくなります。 リンクモードはまた、古いクラスタと新しいクラスタのデータディレクトリが同じファイルシステムにあることが必要です。 (テーブル空間およびpg_walは異なるファイルシステムに置くことができます。) 複製モードは同じ速度とディスク容量の利点を提供しますが、新しいクラスタを一度実行しても、古いクラスタが使えなくなる訳ではありません。 複製モードはまた、新旧のデータディレクトリが同じファイルシステム内にあることを要求します。 このモードは特定のオペレーティングシステムのファイルシステム上でのみ利用可能です。

    The <option>&#45;-jobs</option> option allows multiple CPU cores to be used for copying/linking of files and to dump and restore database schemas in parallel; a good place to start is the maximum of the number of CPU cores and tablespaces. This option can dramatically reduce the time to upgrade a multi-database server running on a multiprocessor machine. --jobsオプションにより複数のCPUコアを使用して、並行してファイルのコピー・リンク、データベーススキーマのダンプとリストアを行うことができます。 この値の最大値として検討を始める際には、CPUコア数またはテーブル空間数を勧めます。 このオプションはマルチプロセッサを持つマシンで実行している複数のデータベースサーバをアップグレードする時間を大きく減らします。

    For Windows users, you must be logged into an administrative account, and then start a shell as the <literal>postgres</literal> user and set the proper path: Windowsユーザの場合、管理者アカウントでログオンしなければなりません。 また、postgresユーザとしてシェルを起動し、適切なパスを設定してください。

    RUNAS /USER:postgres "CMD.EXE"
    SET PATH=%PATH%;C:\Program Files\PostgreSQL\16\bin;
    

    and then run <application>pg_upgrade</application> with quoted directories, e.g.: そして、以下の例のように、引用符でくくったディレクトリを付けてpg_upgradeを実行してください。

    pg_upgrade.exe
            --old-datadir "C:/Program Files/PostgreSQL/9.6/data"
            --new-datadir "C:/Program Files/PostgreSQL/16/data"
            --old-bindir "C:/Program Files/PostgreSQL/9.6/bin"
            --new-bindir "C:/Program Files/PostgreSQL/16/bin"
    

    Once started, <command>pg_upgrade</command> will verify the two clusters are compatible and then do the upgrade. You can use <command>pg_upgrade &#45;-check</command> to perform only the checks, even if the old server is still running. <command>pg_upgrade &#45;-check</command> will also outline any manual adjustments you will need to make after the upgrade. If you are going to be using link or clone mode, you should use the option <option>&#45;-link</option> or <option>&#45;-clone</option> with <option>&#45;-check</option> to enable mode-specific checks. <command>pg_upgrade</command> requires write permission in the current directory. 起動後、pg_upgradeは2つのクラスタに互換性があるかどうか検証し、その後、アップグレードを行います。 検査のみを行うpg_upgrade --checkを使用することができます。 この場合は古いサーバは稼働中であっても構いません。 またpg_upgrade --checkは、アップグレード後に手作業で行わなければならない調整作業があればその概要を示します。 リンクまたは複製モードを使用する予定であれば、モード固有の検査を有効にするために--checkを付けて--linkまたは--cloneオプションを使用すべきです。 pg_upgradeは現在のディレクトリに対する書き込み権限を必要とします。

    Obviously, no one should be accessing the clusters during the upgrade. <application>pg_upgrade</application> defaults to running servers on port 50432 to avoid unintended client connections. You can use the same port number for both clusters when doing an upgrade because the old and new clusters will not be running at the same time. However, when checking an old running server, the old and new port numbers must be different. 言うまでもありませんが、アップグレード中はクラスタにアクセスしてはいけません。 意図しないクライアント接続を防ぐために、デフォルトではpg_upgradeは50432ポートでサーバを稼働します。 古いクラスタと新しいクラスタが同時に稼働することはありませんので、両クラスタで同じポート番号を使用することができます。 しかし実行中の古いクラスタを検査する時には、新旧で異なるポート番号でなければなりません。

    If an error occurs while restoring the database schema, <command>pg_upgrade</command> will exit and you will have to revert to the old cluster as outlined in <xref linkend="pgupgrade-step-revert"/> below. To try <command>pg_upgrade</command> again, you will need to modify the old cluster so the pg_upgrade schema restore succeeds. If the problem is a <filename>contrib</filename> module, you might need to uninstall the <filename>contrib</filename> module from the old cluster and install it in the new cluster after the upgrade, assuming the module is not being used to store user data. データベーススキーマのリストア中にエラーが発生した場合、pg_upgradeは終了しますので、後述のステップ 17で示すように古いクラスタに戻さなければなりません。 再びpg_upgradeを試すためには、pg_upgradeによるスキーマのリストアが成功するように古いクラスタを変更しなければなりません。 問題がcontribモジュールであれば、そのモジュールがユーザデータを格納するために使用されていないことが前提ですが、古いクラスタからそのcontribモジュールをアンインストールし、アップグレードした後に新しいクラスタにそれをインストールする必要があるかもしれません。

  11. <title>Upgrade streaming replication and log-shipping standby servers</title>

    ストリーミングレプリケーションおよびログシッピングのスタンバイサーバのアップグレード

    If you used link mode and have Streaming Replication (see <xref linkend="streaming-replication"/>) or Log-Shipping (see <xref linkend="warm-standby"/>) standby servers, you can follow these steps to quickly upgrade them. You will not be running <application>pg_upgrade</application> on the standby servers, but rather <application>rsync</application> on the primary. Do not start any servers yet. リンクモードを使用した場合で、ストリーミングレプリケーション(27.2.5参照)またはログシッピング(27.2参照)のスタンバイサーバがある場合、以下の手順に従って、素早くアップグレードすることができます。 スタンバイサーバでpg_upgradeは実行せず、代わりにプライマリでrsyncを実行することになります。 どのサーバもまだ起動しないでください。

    If you did <emphasis>not</emphasis> use link mode, do not have or do not want to use <application>rsync</application>, or want an easier solution, skip the instructions in this section and simply recreate the standby servers once <application>pg_upgrade</application> completes and the new primary is running. リンクモードを使用しなかった場合、rsyncの機能が使えない場合や使いたくない場合、あるいはもっと容易な方法を望む場合は、この節の手順を読み飛ばし、pg_upgradeが完了して新しいプライマリが起動したら、単純にスタンバイサーバを再作成してください。

    1. <title>Install the new PostgreSQL binaries on standby servers</title>

      PostgreSQLの新しいバイナリをスタンバイサーバにインストール

      Make sure the new binaries and support files are installed on all standby servers. すべてのスタンバイサーバで新しいバイナリとサポートファイルがインストールされていることを確実にしてください。

    2. <title>Make sure the new standby data directories do <emphasis>not</emphasis> exist</title>

      新しいスタンバイのデータディレクトリが存在しないことの確認

      Make sure the new standby data directories do <emphasis>not</emphasis> exist or are empty. If <application>initdb</application> was run, delete the standby servers' new data directories. 新しいスタンバイのデータディレクトリが存在しないか空であることを確実にしてください。 initdbが実行されている場合は、スタンバイサーバの新しいデータディレクトリを削除してください。

    3. <title>Install extension shared object files</title>

      拡張共有オブジェクトファイルのインストール

      Install the same extension shared object files on the new standbys that you installed in the new primary cluster. 新しいプライマリのクラスタにインストールしたのと同じ拡張共有オブジェクトファイルを新しいスタンバイにインストールしてください。

    4. <title>Stop standby servers</title>

      スタンバイサーバの停止

      If the standby servers are still running, stop them now using the above instructions. スタンバイサーバがまだ実行中なら、上記の手順に従って停止してください。

    5. <title>Save configuration files</title>

      設定ファイルの保存

      Save any configuration files from the old standbys' configuration directories you need to keep, e.g., <filename>postgresql.conf</filename> (and any files included by it), <filename>postgresql.auto.conf</filename>, <literal>pg_hba.conf</literal>, because these will be overwritten or removed in the next step. スタンバイの設定ディレクトリの設定ファイルで保持する必要のあるもの、例えばpostgresql.conf(とそれがインクルードしているファイル)やpostgresql.auto.confpg_hba.confを保存してください。 これらは次のステップで上書きあるいは削除されるからです。

    6. <title>Run <application>rsync</application></title>

      rsyncの実行

      When using link mode, standby servers can be quickly upgraded using <application>rsync</application>. To accomplish this, from a directory on the primary server that is above the old and new database cluster directories, run this on the <emphasis>primary</emphasis> for each standby server: リンクモードを使用する場合、rsyncを使用してスタンバイサーバを素早くアップグレードすることができます。 これを実行するには、古いデータベースクラスタのディレクトリおよび新しいデータベースクラスタのディレクトリより上位にあるプライマリサーバ上のディレクトリで、プライマリ上で各スタンバイサーバに対して以下を実行します。

      rsync --archive --delete --hard-links --size-only --no-inc-recursive old_cluster new_cluster remote_dir
      

      where <option>old_cluster</option> and <option>new_cluster</option> are relative to the current directory on the primary, and <option>remote_dir</option> is <emphasis>above</emphasis> the old and new cluster directories on the standby. The directory structure under the specified directories on the primary and standbys must match. Consult the <application>rsync</application> manual page for details on specifying the remote directory, e.g., ここでold_clusterおよびnew_clusterはプライマリのカレントディレクトリからの相対パス、remote_dirはスタンバイサーバ上の古いクラスタと新しいクラスタのディレクトリの上位のディレクトリです。 プライマリとスタンバイの指定したディレクトリより下のディレクトリ構造は一致しなければなりません。 リモートディレクトリの指定の詳細についてはrsyncのマニュアルを参照してください。 例を示します。

      rsync --archive --delete --hard-links --size-only --no-inc-recursive /opt/PostgreSQL/9.5 \
            /opt/PostgreSQL/9.6 standby.example.com:/opt/PostgreSQL
      

      You can verify what the command will do using <application>rsync</application>'s <option>&#45;-dry-run</option> option. While <application>rsync</application> must be run on the primary for at least one standby, it is possible to run <application>rsync</application> on an upgraded standby to upgrade other standbys, as long as the upgraded standby has not been started. rsync--dry-runオプションを使うことで、そのコマンドが何をするか確認することができます。 rsyncは少なくとも1つのスタンバイに対して、プライマリ上で実行しなければなりませんが、アップグレード済みのスタンバイがまだ起動していなければ、そのスタンバイ上でrsyncを実行して、他のスタンバイをアップグレードすることができます。

      What this does is to record the links created by <application>pg_upgrade</application>'s link mode that connect files in the old and new clusters on the primary server. It then finds matching files in the standby's old cluster and creates links for them in the standby's new cluster. Files that were not linked on the primary are copied from the primary to the standby. (They are usually small.) This provides rapid standby upgrades. Unfortunately, <application>rsync</application> needlessly copies files associated with temporary and unlogged tables because these files don't normally exist on standby servers. これが実行するのはpg_upgradeのリンクモードが作成したプライマリサーバ上の古いクラスタのファイルと新しいクラスタのファイルを接続するリンクについて記録することです。 次にスタンバイの古いクラスタ内の一致するファイルを探し、スタンバイの新しいクラスタ内に対応するリンクを作成します。 プライマリ上でリンクされなかったファイルは、プライマリからスタンバイにコピーされます。 (それらは通常は小さいです。) これにより高速なアップグレードが可能になります。 残念ながらrsyncは一時テーブルやログを取らないテーブルに関連したファイルを不要であるにも関わらずコピーします。 これらのファイルが通常はスタンバイサーバに存在しないからです。

      If you have tablespaces, you will need to run a similar <application>rsync</application> command for each tablespace directory, e.g.: テーブル空間を使用している場合は、各テーブル空間のディレクトリについて、同様のrsyncコマンドを実行する必要があります。 例を示します。

      rsync --archive --delete --hard-links --size-only --no-inc-recursive /vol1/pg_tblsp/PG_9.5_201510051 \
            /vol1/pg_tblsp/PG_9.6_201608131 standby.example.com:/vol1/pg_tblsp
      

      If you have relocated <filename>pg_wal</filename> outside the data directories, <application>rsync</application> must be run on those directories too. pg_walをデータディレクトリの外側に移動している場合は、そのディレクトリについてもrsyncを実行しなければなりません。

    7. <title>Configure streaming replication and log-shipping standby servers</title>

      ストリーミングレプリケーションおよびログシッピングのスタンバイサーバの設定

      Configure the servers for log shipping. (You do not need to run <function>pg_backup_start()</function> and <function>pg_backup_stop()</function> or take a file system backup as the standbys are still synchronized with the primary.) Replication slots are not copied and must be recreated. ログシッピングのためにサーバを設定します。 (スタンバイはまだプライマリと同期されているので、pg_backup_start()pg_backup_stop()を実行したり、ファイルシステムのバックアップを取得したりする必要はありません。) レプリケーションスロットはコピーされないため、再作成する必要があります。

  12. <title>Restore <filename>pg_hba.conf</filename></title>

    pg_hba.confの復旧

    If you modified <filename>pg_hba.conf</filename>, restore its original settings. It might also be necessary to adjust other configuration files in the new cluster to match the old cluster, e.g., <filename>postgresql.conf</filename> (and any files included by it), <filename>postgresql.auto.conf</filename>. pg_hba.confを変更している場合は、元の認証設定に戻してください。 また新しいクラスタにおけるこの他の設定ファイル、例えばpostgresql.conf(とそれがインクルードしているファイル)、postgresql.auto.confも古いクラスタに合わせるように調整する必要があります。

  13. <title>Start the new server</title>

    新しいサーバの起動

    The new server can now be safely started, and then any <application>rsync</application>'ed standby servers. ここで新しいサーバが安全に起動できます。 それからrsyncしたすべてのスタンバイサーバを起動できます。

  14. <title>Post-upgrade processing</title>

    移行後の処理

    If any post-upgrade processing is required, pg_upgrade will issue warnings as it completes. It will also generate script files that must be run by the administrator. The script files will connect to each database that needs post-upgrade processing. Each script should be run using: アップグレード後の処理が必要な場合、pg_upgradeはその終了時に警告を発します。 また、管理者として実行しなければならないスクリプトファイルを生成します。 このスクリプトファイルは、アップグレード後の処理を必要とするデータベースそれぞれに接続します。 各スクリプトは以下を使用して実行しなければなりません。

    psql --username=postgres --file=script.sql postgres
    

    The scripts can be run in any order and can be deleted once they have been run. スクリプトは任意の順番で実行することができ、また、実行が終わったら削除することができます。

    注意

    In general it is unsafe to access tables referenced in rebuild scripts until the rebuild scripts have run to completion; doing so could yield incorrect results or poor performance. Tables not referenced in rebuild scripts can be accessed immediately. 一般的には、再構築用のスクリプトの実行が完了するより前に、再構築用のスクリプトで参照されるテーブルにアクセスすることは安全ではありません。 これを行うと間違った結果が生じたり、性能が劣化することがあり得ます。 再構築用のスクリプトで参照されないテーブルにはすぐにアクセスすることができます。

  15. <title>Statistics</title>

    統計情報

    Because optimizer statistics are not transferred by <command>pg_upgrade</command>, you will be instructed to run a command to regenerate that information at the end of the upgrade. You might need to set connection parameters to match your new cluster. オプティマイザの統計情報はpg_upgradeにより転送されませんので、アップグレード後に統計情報を再生成するコマンドを実行するように指示されます。 新しいクラスタに合わせるために接続パラメータを設定する必要があるかもしれません。

  16. <title>Delete old cluster</title>

    古いクラスタの削除

    Once you are satisfied with the upgrade, you can delete the old cluster's data directories by running the script mentioned when <command>pg_upgrade</command> completes. (Automatic deletion is not possible if you have user-defined tablespaces inside the old data directory.) You can also delete the old installation directories (e.g., <filename>bin</filename>, <filename>share</filename>). アップグレード処理が満足いくものであれば、pg_upgradeの終了時に示されたスクリプトを使用して、古いクラスタのデータディレクトリを削除することができます。 (古いデータディレクトリ内にユーザ定義のテーブル空間がある場合には、自動削除は不可能です。) (binshareなど)古いインストレーションディレクトリも削除できます。

  17. <title>Reverting to old cluster</title>

    古いクラスタへの戻し

    If, after running <command>pg_upgrade</command>, you wish to revert to the old cluster, there are several options: pg_upgradeを実行した後に古いクラスタに戻したい場合、いくつかの選択肢があります。

    • If the <option>&#45;-check</option> option was used, the old cluster was unmodified; it can be restarted. --checkオプションが使われた場合、古いクラスタは変更されません。再起動できます。

    • If the <option>&#45;-link</option> option was <emphasis>not</emphasis> used, the old cluster was unmodified; it can be restarted. --linkオプションが使われなかった場合、古いクラスタは変更されません。再起動できます。

    • If the <option>&#45;-link</option> option was used, the data files might be shared between the old and new cluster: --linkオプションが使われた場合、データファイルは古いクラスタと新しいクラスタは共有されるかもしれません。

      • If <command>pg_upgrade</command> aborted before linking started, the old cluster was unmodified; it can be restarted. リンク処理が始まる前にpg_upgradeが中断すれば、古いクラスタは変更されません。古いクラスタを再起動できます。

      • If you did <emphasis>not</emphasis> start the new cluster, the old cluster was unmodified except that, when linking started, a <literal>.old</literal> suffix was appended to <filename>$PGDATA/global/pg_control</filename>. To reuse the old cluster, remove the <filename>.old</filename> suffix from <filename>$PGDATA/global/pg_control</filename>; you can then restart the old cluster. 新しいクラスタを開始しなかった場合、リンク処理が始まる時に$PGDATA/global/pg_control.old接尾辞が追加される点を除き、古いクラスタは変更されません。 古いクラスタを再度使用するためには、$PGDATA/global/pg_controlから.old接尾辞を取り除きます。その後で古いクラスタを再起動できます。

      • If you did start the new cluster, it has written to shared files and it is unsafe to use the old cluster. The old cluster will need to be restored from backup in this case. 新しいクラスタを開始した場合、共有ファイルに書き込んでいますので古いクラスタを使うことは安全ではありません。 この場合、古いクラスタをバックアップからリストアすることが必要でしょう。

注釈

<title>Notes</title>

<application>pg_upgrade</application> creates various working files, such as schema dumps, stored within <filename>pg_upgrade_output.d</filename> in the directory of the new cluster. Each run creates a new subdirectory named with a timestamp formatted as per ISO 8601 (<literal>%Y%m%dT%H%M%S</literal>), where all its generated files are stored. <filename>pg_upgrade_output.d</filename> and its contained files will be removed automatically if <application>pg_upgrade</application> completes successfully; but in the event of trouble, the files there may provide useful debugging information. pg_upgradeはスキーマのダンプなど様々な作業ファイルを作成し、新しいクラスタのディレクトリのpg_upgrade_output.d内に保存します。 実行するたびに、ISO 8601に従ってフォーマットされたタイムスタンプ(%Y%m%dT%H%M%S)の付いた名前の新しいサブディレクトリが作成されます。このサブディレクトリには、生成されたファイルがすべて保存されます。 pg_upgradeが正常に完了した場合、pg_upgrade_output.dとそれに含まれるファイルは自動的に削除されます。 しかし、問題が発生した場合、そこにあるファイルは有用なデバッグ情報を提供する可能性があります。

<application>pg_upgrade</application> launches short-lived postmasters in the old and new data directories. Temporary Unix socket files for communication with these postmasters are, by default, made in the current working directory. In some situations the path name for the current directory might be too long to be a valid socket name. In that case you can use the <option>-s</option> option to put the socket files in some directory with a shorter path name. For security, be sure that that directory is not readable or writable by any other users. (This is not supported on Windows.) pg_upgradeは新旧のデータディレクトリで短命なpostmasterを起動します。 このpostmasterの通信用の一時的なUnixのソケットファイルが、デフォルトでは現在の作業ディレクトリに作られます。 状況に依っては、カレントディレクトリのパス名が有効なソケット名には長過ぎる場合もあるでしょう。 その場合、-sオプションを使ってソケットファイルをより短いパス名のディレクトリに置くことができます。 セキュリティのため、他のユーザがそのディレクトリを読んだり書いたりできないことを確実にしてください。 (これはWindowsではサポートされていません。)

All failure, rebuild, and reindex cases will be reported by <application>pg_upgrade</application> if they affect your installation; post-upgrade scripts to rebuild tables and indexes will be generated automatically. If you are trying to automate the upgrade of many clusters, you should find that clusters with identical database schemas require the same post-upgrade steps for all cluster upgrades; this is because the post-upgrade steps are based on the database schemas, and not user data. インストレーションに影響する場合、失敗、再構築、インデックス再作成はすべてpg_upgradeにより報告されます。 テーブルおよびインデックスを再構築するアップグレード後処理スクリプトは自動的に生成されます。 多くのクラスタのアップグレードを自動化することを考えているのであれば、 すべてのクラスタのアップグレードにおいて同一のデータベーススキーマを持つクラスタが同じアップグレード後処理を必要とすることが分かるはずです。 これはアップグレード後処理がデータ自体ではなくデータベーススキーマに基づいているためです。

For deployment testing, create a schema-only copy of the old cluster, insert dummy data, and upgrade that. 展開試験を行うのであれば、古いクラスタのスキーマのみをコピーしたものを作成し、ダミーデータを挿入してから、アップグレードを行ってください。

<application>pg_upgrade</application> does not support upgrading of databases containing table columns using these <type>reg*</type> OID-referencing system data types: pg_upgradeは次のOIDを参照するreg*システムデータ型を使うテーブル列を含むデータベースのアップグレードをサポートしません。

regcollation
regconfig
regdictionary
regnamespace
regoper
regoperator
regproc
regprocedure

(<type>regclass</type>, <type>regrole</type>, and <type>regtype</type> can be upgraded.) (regclassregroleregtypeはアップグレード可能です。)

If you want to use link mode and you do not want your old cluster to be modified when the new cluster is started, consider using the clone mode. If that is not available, make a copy of the old cluster and upgrade that in link mode. To make a valid copy of the old cluster, use <command>rsync</command> to create a dirty copy of the old cluster while the server is running, then shut down the old server and run <command>rsync &#45;-checksum</command> again to update the copy with any changes to make it consistent. (<option>&#45;-checksum</option> is necessary because <command>rsync</command> only has file modification-time granularity of one second.) You might want to exclude some files, e.g., <filename>postmaster.pid</filename>, as documented in <xref linkend="backup-lowlevel-base-backup"/>. If your file system supports file system snapshots or copy-on-write file copies, you can use that to make a backup of the old cluster and tablespaces, though the snapshot and copies must be created simultaneously or while the database server is down. リンクモードを使用したいが、新しいクラスタを起動した時に古いクラスタを変更させたくない場合は、複製モードの使用を検討してください。 もしそれが利用可能でないなら、古いクラスタのコピーを取得してからリンクモードでアップグレードを行ってください。 有効な古いクラスタのコピーを取得するためには、サーバ稼働中にrsyncを使用して古いクラスタの変動があるかもしれないコピーを作成し、古いサーバを停止させた後に、rsync --checksumを再度実行して一貫性を保つために何らかの変更をコピーに反映させます。 (rsyncはファイル更新時刻の粒度が1秒しかないので--checksumが必要です。) 例えば26.3.3で説明したpostmaster.pidなど、一部のファイルを除外したいと考えるかもしれません。 スナップショットやコピーは同時、もしくはデータベースサーバが停止しているときに作らなければなりませんが、ファイルシステムがファイルシステムのスナップショットやコピーオンライトファイルコピーをサポートしているのなら、それを古いクラスタとテーブル空間のバックアップをするのに使うことができます。

関連項目

<title>See Also</title> initdb, pg_ctl, pg_dump, postgres