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

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 12.14 to 13.10 or from 14.9 to 15.5. It is not required for minor version upgrades, e.g., from 12.7 to 12.8 or from 14.1 to 14.5. pg_upgrade(これまではpg_migratorと呼ばれていました)を使用することで、メジャーバージョンのアップグレード、例えば、12.14から13.10へ、14.9から15.5へのアップグレードで通常必要とされるデータのダンプ/リストアを行うことなく、PostgreSQLデータファイル内に格納されたデータをより最新のPostgreSQLメジャーバージョンに移行できます。 これは、例えば12.7から12.8、14.1から14.5などマイナーバージョンのアップグレードでは必要ありません。

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では検査することができません。

<application>pg_upgrade</application> supports upgrades from 9.2.X and later to the current major release of <productname>PostgreSQL</productname>, including snapshot and beta releases. 《マッチ度[83.783784]》pg_upgradeは9.2.X以降から現時点のPostgreSQLのメジャーリリース(スナップショット版やβリリースを含む)へのアップグレードをサポートします。 《機械翻訳》pg_upgradeは、9.2.X以降から現在メジャーリリースのPostgreSQL、snapshotおよびベータのリリースを含むへのアップグレードをサポートします。

警告

Upgrading a cluster causes the destination to execute arbitrary code of the source superusers' choice. Ensure that the source superusers are trusted before upgrading. クラスタをアップグレードすると、アップグレード元のスーパーユーザが選択した任意のコードをアップグレード先で実行することになります。 アップグレードする前に、アップグレード元のスーパーユーザが信頼できることを確認してください。

オプション

<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>, <option>&#45;-clone</option>, <option>&#45;-copy-file-range</option>, and <option>&#45;-swap</option>.) 《マッチ度[55.617978]》新しいクラスタにファイルをコピーします。 これがデフォルトです。 (--linkおよび--cloneも参照してください。) 《機械翻訳》コピーが新しいクラスタにファイルします。 これがデフォルトです。 --link--clone--copy-file-range、および--swap。 も参照してください。

--copy-file-range

Use the <function>copy_file_range</function> system call for efficient copying. On some file systems this gives results similar to <option>&#45;-clone</option>, sharing physical disk blocks, while on others it may still copy blocks, but do so via an optimized path. At present, it is supported on Linux and FreeBSD. 効率的なコピーを行うには、システムコールcopy_file_rangeを使用します。 ファイルシステムによっては、物理ディスクブロックを共有する--cloneと同様の結果を得られるものもあれば、ブロックをコピーするものの、最適化されたパスを介してコピーするものもあります。 現在、LinuxとFreeBSDでサポートされています。

--no-statistics

Do not restore statistics from the old cluster into the new cluster. 《機械翻訳》古いクラスタから新しいクラスタに統計処理をリストアしないでください。

--set-char-signedness=option

Manually set the default char signedness of new clusters. Possible values are <literal>signed</literal> and <literal>unsigned</literal>. 《機械翻訳》新しいクラスタのデフォルト文字の符号を手動で設定します。 有効な値はsignedunsignedです。

In the C language, the default signedness of the <type>char</type> type (when not explicitly specified) varies across platforms. For example, <type>char</type> defaults to <type>signed char</type> on x86 CPUs but to <type>unsigned char</type> on ARM CPUs. 《機械翻訳》C言語では、charデフォルトのタイプ符号はプラットフォームによって異なります。 例の場合、charのデフォルトはx86 CPUではsigned charですが、ARM CPUではunsigned charです。

Starting from <productname>PostgreSQL</productname> 18, database clusters maintain their own default char signedness setting, which can be used to ensure consistent behavior across platforms with different default char signedness. By default, <application>pg_upgrade</application> preserves the char signedness setting when upgrading from an existing cluster. However, when upgrading from <productname>PostgreSQL</productname> 17 or earlier, <application>pg_upgrade</application> adopts the char signedness of the platform on which it was built. 《機械翻訳》PostgreSQL18以降、データベースクラスタは独自のデフォルトchar signedness設定を維持しており、これを使用して、異なる保証char signednessを持つプラットフォーム間で一貫した動作をデフォルトすることができる。 デフォルトでは、既存のクラスタからアップグレード処理する場合、pg_upgrade char signedness設定を保持する。 ただし、PostgreSQL17以前のアップグレード処理では、pg_upgradeそれが構築されたプラットフォームのchar signednessを採用する。

This option allows you to explicitly set the default char signedness for the new cluster, overriding any inherited values. There are two specific scenarios where this option is relevant: 《機械翻訳》このオプションを使用すると、新しいデフォルトのクラスタ文字の符号を明示的に設定し、継承された値を上書きできます。 このオプションが関連する具体的なシナリオは次の2つです。

  • If you are planning to migrate to a different platform after the upgrade, you should not use this option. The default behavior is right in this case. Instead, perform the upgrade on the original platform without this flag, and then migrate the cluster afterward. This is the recommended and safest approach. 《機械翻訳》アップグレードの後に別のプラットフォームに移行する場合は、このオプションを使用しないでください。 デフォルトの動作はこのケースにあります。 かわりに、このフラグのないオリジナルプラットフォームでアップグレードを実行し、その後クラスタを移行します。 これは推奨される最も安全なアプローチです。

  • If you have already migrated the cluster to a platform with different char signedness (for example, from an x86-based system to an ARM-based system), you should use this option to specify the signedness matching the original platform's default char signedness. Additionally, it's essential not to modify any data files between migrating data files and running <command>pg_upgrade</command>. <command>pg_upgrade</command> should be the first operation that starts the cluster on the new platform. 《機械翻訳》既に異なるchar signednessを持つプラットフォームにクラスタを移行している場合(例えば、x86ベースのシステムからARMベースのシステムへ)、このオプションを使用して、元のプラットフォームのデフォルトchar signednessと一致する符号を指定する必要があります。 さらに、データファイルを移行してからpg_upgradeを実行するまでの間に、データファイルを変更しないことが不可欠です。 pg_upgradeは、新しいプラットフォームでクラスタを起動する最初の操作である必要があります。

--swap

Move the data directories from the old cluster to the new cluster. Then, replace the catalog files with those generated for the new cluster. This mode can outperform <option>&#45;-link</option>, <option>&#45;-clone</option>, <option>&#45;-copy</option>, and <option>&#45;-copy-file-range</option>, especially on clusters with many relations. 《機械翻訳》データディレクトリを古いクラスタから新しいクラスタに移動します。 次に、カタログファイルを新しいクラスタ用に生成されたものに置き換えます。 このモードは、--link--clone--copy、および--copy-file-range、特に多くのリレーションを持つクラスタではよりも優れています。

However, this mode creates many garbage files in the old cluster, which can prolong the file synchronization step if <option>&#45;-sync-method=syncfs</option> is used. Therefore, it is recommended to use <option>&#45;-sync-method=fsync</option> with <option>&#45;-swap</option>. 《機械翻訳》ただし、このモードでは古いクラスタに多くの不要なファイルが作成されるため、--sync-method=syncfsが使用されている場合、ファイルの同期のステップが長くなる可能性があります。 したがって、--sync-method=fsync--swapを併用することをお勧めします。

Additionally, once the file transfer step begins, the old cluster will be destructively modified and therefore will no longer be safe to start. See <xref linkend="pgupgrade-step-revert"/> for details. 《機械翻訳》さらに、ファイル転送ステップが開始されると、古いクラスタは破壊的に変更されるため、セーフからスタートではなくなります。 詳細については、ステップ 17を参照してください。

--sync-method=method

When set to <literal>fsync</literal>, which is the default, <command>pg_upgrade</command> will recursively open and synchronize all files in the upgraded cluster's data directory. The search for files will follow symbolic links for the WAL directory and each configured tablespace. デフォルトのfsyncに設定すると、pg_upgradeはアップグレードされたクラスタのデータディレクトリ内のすべてのファイルを再帰的に開いて同期します。 ファイルの検索はWALディレクトリと設定された各テーブル空間のシンボリックリンクをたどります。

On Linux, <literal>syncfs</literal> may be used instead to ask the operating system to synchronize the whole file systems that contain the upgraded cluster's data directory, its WAL files, and each tablespace. See <xref linkend="guc-recovery-init-sync-method"/> for information about the caveats to be aware of when using <literal>syncfs</literal>. Linuxでは、syncfsを代わりに使用して、アップグレードされたクラスタのデータディレクトリ、WALファイル、および各テーブル空間を含むファイルシステム全体を同期するようにオペレーティングシステムに要求できます。 syncfsを使用する際に注意すべき点については、recovery_init_sync_methodを参照してください。

This option has no effect when <option>&#45;-no-sync</option> is used. このオプションは--no-syncが使われている場合は効果がありません。

-?
--help

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

使用方法

<title>Usage</title>

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

注記

The steps to upgrade <glossterm linkend="glossary-logical-replication-cluster">logical replication clusters</glossterm> are not covered here; refer to <xref linkend="logical-replication-upgrade"/> for details. 《機械翻訳》アップグレードへのステップ論理レプリケーションクラスタはここでは取り上げません。 詳細については29.13を参照してください。

  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/18)を使用しているのであれば、古いクラスタを移動する必要はありません。 グラフィカルインストーラはすべて、バージョンに関連したインストレーションディレクトリを使用します。

    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ファイル(32.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/12 stop
    pg_ctl -D /opt/PostgreSQL/18 stop
    

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

    NET STOP postgresql-12
    NET STOP postgresql-18
    

    Streaming replication and log-shipping standby servers must be running during this shutdown so they receive all changes. すべての変更を受信するよう、ストリーミングレプリケーションおよびログシッピングのスタンバイサーバは、このシャットダウン中は実行していなければなりません。

  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. 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, cloned, or swapped instead of the default copy behavior. 《マッチ度[91.603053]》古いサーバのものではなく、常に新しいサーバの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. Swap mode may be the fastest if there are many relations, but you will not be able to access your old cluster once the file transfer step begins. Swap mode also requires that the old and new cluster data directories be in the same file system. 《マッチ度[66.881720]》リンクモードを使用する場合、アップグレードは非常に高速になり(ファイルのコピーがありません)、ディスク容量が少なくなりますが、アップグレード後に新しいクラスタを一度でも実行してしまうと、古いクラスタにアクセスすることができなくなります。 リンクモードはまた、古いクラスタと新しいクラスタのデータディレクトリが同じファイルシステムにあることが必要です。 (テーブル空間およびpg_walは異なるファイルシステムに置くことができます。) 複製モードは同じ速度とディスク容量の利点を提供しますが、新しいクラスタを一度実行しても、古いクラスタが使えなくなる訳ではありません。 複製モードはまた、新旧のデータディレクトリが同じファイルシステム内にあることを要求します。 このモードは特定のオペレーティングシステムのファイルシステム上でのみ利用可能です。 《機械翻訳》リンクモードを使用すると、アップグレードがはるかに速くなり(ファイルのコピーが不要)、ディスクスペースの使用量も少なくなりますが、アップグレードの後に新しいクラスタをスタートすると、古いクラスタをアクセスすることはできません。 また、リンクモードでは、新旧のクラスタデータディレクトリが同じファイルシステム内にある必要があります。 (表領域とpg_wal異なるファイルシステム上にある場合もありますクローンモードは同じ速度とディスクスペースの利点を提供しますが、新しいクラスタが開始された後に古いクラスタが使用できなくなることはありません。 クローンモードでも、新旧のデータディレクトリが同じファイルシステム内にある必要があります。 このモードは、特定のオペレーティングシステムとファイルシステムでのみ使用できます。 の数が多い場合は、が最も高速になる可能性がありますが、ファイル転送が開始されると、古いディレクトリをできなくなります。 また、では、新旧ののディレクトリが同じ内にある必要があります。 リレーションクラスタモードクラスタファイルシステムスワップモードアクセスステップスワップデータ

    Setting <option>&#45;-jobs</option> to 2 or higher allows pg_upgrade to process multiple databases and tablespaces in parallel. A good starting point is the number of CPU cores on the machine. This option can substantially reduce the upgrade time for multi-database and multi-tablespace servers. 《機械翻訳》--jobsを2以上に設定すると、pg_upgradeからプロセスマルチプルのデータベースおよび表領域をパラレルで使用できます。 まずはマシンのCPUコア数から始めるとよいでしょう。 このオプションを使用すると、マルチデータベースおよびマルチテーブルスペースサーバのアップグレード時間を大幅に削減できます。

    For Windows users, you must be logged into an administrative account, and then run <application>pg_upgrade</application> with quoted directories, e.g.: Windowsユーザの場合、管理アカウントでログインし、引用符でくくったディレクトリを付けてpg_upgradeを実行してください。

    pg_upgrade.exe
            --old-datadir "C:/Program Files/PostgreSQL/12/data"
            --new-datadir "C:/Program Files/PostgreSQL/18/data"
            --old-bindir "C:/Program Files/PostgreSQL/12/bin"
            --new-bindir "C:/Program Files/PostgreSQL/18/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, clone, copy-file-range, or swap mode, you should use the option <option>&#45;-link</option>, <option>&#45;-clone</option>, <option>&#45;-copy-file-range</option>, or <option>&#45;-swap</option> with <option>&#45;-check</option> to enable mode-specific checks. <command>pg_upgrade</command> requires write permission in the current directory. 《マッチ度[81.355932]》起動後、pg_upgradeは2つのクラスタに互換性があるかどうか検証し、その後、アップグレードを行います。 検査のみを行うpg_upgrade --checkを使用することができます。 この場合は古いサーバは稼働中であっても構いません。 またpg_upgrade --checkは、アップグレード後に手作業で行わなければならない調整作業があればその概要を示します。 リンクまたは複製モードを使用する予定であれば、モード固有の検査を有効にするために--checkを付けて--linkまたは--cloneオプションを使用すべきです。 pg_upgradeは現在のディレクトリに対する書き込み権限を必要とします。 《機械翻訳》起動後、pg_upgradeは2つのクラスタに互換性があることを確認し、アップグレードを実行します。 pg_upgrade--チェックを使用すると、古いサーバがまだ実行中であっても、チェックのみを実行できます。 pg_upgrade--チェックでは、アップグレードの後にmakeで必要となるマニュアル調整の概要も示されます。 リンク、クローン、コピー-ファイル-レンジ、またはスワップモードを使用する場合は、オプション--link,--clone,--copy-file-range,または--swap--checkを使用してモード固有のチェックを有効にします。 pg_upgradeはカレントディレクトリにwriteパーミッションが必要です。

    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. リンクモードを使用した場合で、ストリーミングレプリケーション(26.2.5参照)またはログシッピング(26.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/12 \
            /opt/PostgreSQL/18 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_12_201909212 \
            /vol1/pg_tblsp/PG_18_202307071 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.) If the old primary is prior to version 17.0, then no slots on the primary are copied to the new standby, so all the slots on the old standby must be recreated manually. If the old primary is version 17.0 or later, then only logical slots on the primary are copied to the new standby, but other slots on the old standby are not copied, so must be recreated manually. ログシッピングのためにサーバを設定します。 (スタンバイはまだプライマリと同期されているので、pg_backup_start()pg_backup_stop()を実行したり、ファイルシステムのバックアップを取得したりする必要はありません。) 古いプライマリがバージョン 17.0 より前の場合、プライマリのスロットは新しいスタンバイにコピーされないため、古いスタンバイのすべてのスロットを手動で再作成する必要があります。 古いプライマリがバージョン 17.0 以降の場合、プライマリの論理スロットだけが新しいスタンバイにコピーされますが、古いスタンバイの他のスロットはコピーされないため、手動で再作成する必要があります。

  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>

    統計情報

    Unless the <option>&#45;-no-statistics</option> option is specified, <command>pg_upgrade</command> will transfer most optimizer statistics from the old cluster to the new cluster. However, some statistics may not be transferred, such as those created explicitly with <xref linkend="sql-createstatistics"/> or custom statistics added by an extension. 《機械翻訳》--no-statisticsオプションが指定されていない場合、pg_upgradeはほとんどのオプティマイザ統計処理を古いクラスタから新しいクラスタに移行します。 ただし、CREATE STATISTICSを使用して明示的に作成された統計処理や、extensionによって追加されたカスタム統計処理など、一部のは移行できません。

    Because not all statistics are transferred by <command>pg_upgrade</command>, you will be instructed to run commands to regenerate that information at the end of the upgrade. You might need to set connection parameters to match your new cluster. 《マッチ度[85.245902]》オプティマイザの統計情報はpg_upgradeにより転送されませんので、アップグレード後に統計情報を再生成するコマンドを実行するように指示されます。 新しいクラスタに合わせるために接続パラメータを設定する必要があるかもしれません。 《機械翻訳》すべての統計処理がpg_upgradeによって転送されるわけではないため、アップグレードの最後にその情報を再生成するコマンドを実行するように指示されます。 新しいコネクションをマッチするようにクラスタパラメータを設定する必要がある場合があります。

    First, use <command>vacuumdb &#45;-all &#45;-analyze-in-stages &#45;-missing-stats-only</command> to quickly generate minimal optimizer statistics for relations without any. Then, use <command>vacuumdb &#45;-all &#45;-analyze-only</command> to ensure all relations have updated cumulative statistics for triggering vacuum and analyze. For both commands, the use of <option>&#45;-jobs</option> can speed it up. If <varname>vacuum_cost_delay</varname> is set to a non-zero value, this can be overridden to speed up statistics generation using <envar>PGOPTIONS</envar>, e.g., <literal>PGOPTIONS='-c vacuum_cost_delay=0' vacuumdb ...</literal>. 《マッチ度[55.194805]》vacuumdb --all --analyze-onlyを使用すると、このような統計情報を効率的に生成できます。 --jobsを使用すると、統計情報を迅速に生成できます。 --analyze-in-stagesオプションを使用すると、最小限の統計情報を迅速に生成できます。 vacuum_cost_delayが0以外の値に設定されている場合、PGOPTIONSを使用して、例えばPGOPTIONS='-c vacuum_cost_delay=0' vacuumdb ...のように、これを上書きして統計情報の生成を高速化できます。 《機械翻訳》まず、vacuumdb--all--ANALYZE-in-stages--missing-stats-onlyを使用して、オプティマイザ用の最小限のリレーション統計処理を生成します。 次に、vacuumdb--all--ANALYZE-onlyを使用して、すべてのリレーションがバキュームとANALYZEをトリガするために累積統計処理を更新したことを保証します。 どちらのコマンドでも、--jobsを使用すると速度を上げることができます。 バキューム_コスト_遅延がゼロ以外の値に設定されている場合、PGOPTIONSを使用して統計処理の生成速度を上げるためにこれを上書きすることができます。 例えばPGOPTIONS='-c vacuum_cost_delay=0' vacuumdb ....

  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 neither <option>&#45;-link</option> nor <option>&#45;-swap</option> was used, the old cluster was unmodified; it can be restarted. 《マッチ度[64.000000]》--checkオプションが使われた場合、古いクラスタは変更されません。再起動できます。 《機械翻訳》も--swapも使用されなかった場合、古いクラスタは変更されていないので、再起動することができる。 --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. 新しいクラスタを開始した場合、共有ファイルに書き込んでいますので古いクラスタを使うことは安全ではありません。 この場合、古いクラスタをバックアップからリストアすることが必要でしょう。

    • If the <option>&#45;-swap</option> option was used, the old cluster might be destructively modified: 《機械翻訳》--swapオプションが使用された場合、古いクラスタは破壊的に変更される可能性があります。

      • If <command>pg_upgrade</command> aborts before reporting that the old cluster is no longer safe to start, the old cluster was unmodified; it can be restarted. 《マッチ度[63.291139]》リンク処理が始まる前にpg_upgradeが中断すれば、古いクラスタは変更されません。古いクラスタを再起動できます。 《機械翻訳》古い前がスタートへのクラスタではなくなったことを報告するセーフがpg_upgrade中止された場合、古いクラスタは変更されていないため、再起動できます。

      • If <command>pg_upgrade</command> has reported that the old cluster is no longer safe to start, the old cluster was destructively modified. The old cluster will need to be restored from backup in this case. 《機械翻訳》pg_upgradeが、セーフからスタートまでの古いクラスタがなくなったと報告した場合、古いクラスタは破壊的に修正されました。 このケースのバックアップから古いクラスタを復元する必要があります。

環境

<title>Environment</title>

Some environment variables can be used to provide defaults for command-line options: 環境変数の中には、コマンドラインオプションのデフォルト値を提供するものがあります。

PGBINOLD

The old PostgreSQL executable directory; option <option>-b</option>/<option>&#45;-old-bindir</option>. 古いPostgreSQLの実行ファイル格納ディレクトリ。 オプション-b/--old-bindir

PGBINNEW

The new PostgreSQL executable directory; option <option>-B</option>/<option>&#45;-new-bindir</option>. 新しいPostgreSQLの実行ファイル格納ディレクトリ。 オプション-B/--new-bindir

PGDATAOLD

The old database cluster configuration directory; option <option>-d</option>/<option>&#45;-old-datadir</option>. 古いデータベースクラスタの設定ディレクトリ。 オプション-d/--old-datadir

PGDATANEW

The new database cluster configuration directory; option <option>-D</option>/<option>&#45;-new-datadir</option>. 新しいデータベースクラスタの設定ディレクトリ。 オプション-D/--new-datadir

PGPORTOLD

The old cluster port number; option <option>-p</option>/<option>&#45;-old-port</option>. 古いクラスタのポート番号。 オプション-p/--old-port

PGPORTNEW

The new cluster port number; option <option>-P</option>/<option>&#45;-new-port</option>. 新しいクラスタのポート番号。 オプション-P/--new-port

PGSOCKETDIR

Directory to use for postmaster sockets during upgrade; option <option>-s</option>/<option>&#45;-socketdir</option>. アップグレード中にpostmasterソケット用に利用するディレクトリ。 オプション-s/--socketdir

PGUSER

Cluster's install user name; option <option>-U</option>/<option>&#45;-username</option>. クラスタのインストールユーザ名。 オプション-U/--username

注釈

<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が必要です。) 例えば25.3.4で説明したpostmaster.pidなど、一部のファイルを除外したいと考えるかもしれません。 スナップショットやコピーは同時、もしくはデータベースサーバが停止しているときに作らなければなりませんが、ファイルシステムがファイルシステムのスナップショットやコピーオンライトファイルコピーをサポートしているのなら、それを古いクラスタとテーブル空間のバックアップをするのに使うことができます。

関連項目

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