pg_upgrade - クラウドでオンライン

プログラム：

NAME

pg_upgrade - PostgreSQL サーバー インスタンスをアップグレードします

SYNOPSIS

pg_upgrade -b 古いバインダー -B 新しいビンディル -d 古いデータディレクトリ -D 新しいデータディレクトリ [オプション...]

DESCRIPTION

pg_upgrade (以前は pg_migrator と呼ばれていました) を使用すると、PostgreSQL データ ファイルに保存されたデータを
通常、データのダンプ/リロードを行わずに、新しい PostgreSQL メジャー バージョンにアップグレードされます。
メジャー バージョンのアップグレードに必要です (例: 8.4.7 から現在のメジャー リリースへ)。
ポストグレSQL。 マイナー バージョン アップグレード (9.0.1 から 9.0.4 など) の場合は必要ありません。

PostgreSQL のメジャー リリースでは、定期的に新機能が追加され、そのレイアウトが変更されることがよくあります。
システム テーブルですが、内部データ ストレージ形式が変更されることはほとんどありません。 pg_upgradeはこれを使用します
新しいシステム テーブルを作成し、古いシステム テーブルを再利用するだけで、迅速なアップグレードを実行できます。
ユーザーデータファイル。 将来のメジャー リリースでデータ ストレージ形式が変更される場合
古いデータ形式が読み取れなくなるため、pg_upgrade はそのようなデータ形式には使用できません。
アップグレード。 (コミュニティはそのような状況を回避するよう努めます。)

pg_upgrade は、古いクラスターと新しいクラスターがバイナリ互換であることを確認するために最善を尽くします。
32/64 ビット バイナリを含む、互換性のあるコンパイル時設定を確認することによって。 それは
外部モジュールもバイナリ互換であることが重要ですが、バイナリ互換であることはできません。
pg_upgrade によってチェックされます。

pg_upgrade は、8.4.X 以降から現在のメジャー リリースへのアップグレードをサポートします。
PostgreSQL (スナップショット リリースとアルファ リリースを含む)。

OPTIONS

pg_upgrade は次のコマンドライン引数を受け入れます。

-b バインダー
--old-bindir=バインダー
古い PostgreSQL 実行可能ディレクトリ。 環境変数 PGBINOLD

-B バインダー
--new-bindir=バインダー
新しい PostgreSQL 実行可能ディレクトリ。 環境変数 PGBINNEW

-c
- チェック
クラスターのみをチェックし、データは変更しないでください

-d データディレクトリ
--old-datadir=データディレクトリ
古いクラスター データ ディレクトリ。 環境変数 PGD​​ATAOLD

-D データディレクトリ
--new-datadir=データディレクトリ
新しいクラスター データ ディレクトリ。 環境変数 PGD​​ATANEW

-j
-ジョブ
同時に使用するプロセスまたはスレッドの数

-k
- リンク
ファイルを新しいクラスターにコピーする代わりにハード リンクを使用します (クラスター上のジャンクション ポイントを使用します)。
Windows）

-o オプション
--古いオプション オプション
オプションは古いものに直接渡されます ポストグレス 指図; 複数のオプションの呼び出し
追加されます

-O オプション
-- 新しいオプション オプション
オプションは新しいものに直接渡されます ポストグレス 指図; 複数のオプションの呼び出し
追加されます

-p ポート
--old-port=ポート
古いクラスターのポート番号。 環境変数 PGポートルド

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

-r
- 保持
正常に完了した後でも SQL ファイルとログ ファイルを保持する

-U ユーザ名
--username =ユーザ名
クラスターのインストールユーザー名。 環境変数 プユーザー

-v
-詳細
詳細な内部ログを有効にする

-V
- バージョン
バージョン情報を表示して終了します

-?
- 助けて
ヘルプを表示して終了する

USAGE

pg_upgrade を使用してアップグレードを実行する手順は次のとおりです。

1. 必要に応じて古いクラスターを移動します: バージョン固有のインストールを使用している場合
ディレクトリ (例: /opt/PostgreSQL/9.1) の場合、古いクラスターを移動する必要はありません。 の
グラフィカル インストーラーはすべて、バージョン固有のインストール ディレクトリを使用します。

インストール ディレクトリがバージョン固有ではない場合 (例: /usr/local/pgsql)、
干渉しないように、現在の PostgreSQL インストール ディレクトリを移動する必要があります。
新しい PostgreSQL インストールを使用します。 現在の PostgreSQL サーバーがシャットダウンされたら、
PostgreSQL インストール ディレクトリの名前を変更しても安全です。 古いディレクトリを想定
/usr/local/pgsql である場合、次のことができます。

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

ディレクトリの名前を変更します。

2. ソース インストールの場合は、新しいバージョンをビルドします。次のコマンドを使用して新しい PostgreSQL ソースをビルドします。
configure 古いクラスターと互換性のあるフラグ。 pg_upgrade がチェックします
pg_controldata アップグレードを開始する前に、すべての設定に互換性があることを確認してください。

3. 新しい PostgreSQL バイナリをインストールします。新しいサーバーのバイナリとサポートをインストールします。
ファイル。 pg_upgrade はデフォルトのインストールに含まれています。

ソース インストールの場合、新しいサーバーをカスタムの場所にインストールする場合は、次を使用します。
プレフィックス変数:

make prefix=/usr/local/pgsql.new install

4. 新しい PostgreSQL クラスターを初期化します。次を使用して新しいクラスターを初期化します。 initdb。 再び、
互換性のあるものを使用する initdb 古いクラスターに一致するフラグ。 多くの事前構築済みインストーラーは、
このステップは自動的に行われます。 新しいクラスターを起動する必要はありません。

5. カスタム共有オブジェクト ファイルのインストール: カスタム共有オブジェクト ファイル (または DLL) をインストールします。
古いクラスターによって新しいクラスターに使用されます (pgcrypto.so など)。
contrib または他のソース。 スキーマ定義をインストールしないでください。例:
pgcrypto.sql。これらは古いクラスターからアップグレードされるためです。 また、どんなカスタムでも
全文検索ファイル (辞書、同義語、シソーラス、ストップワード) も必要です。
新しいクラスターにコピーされます。

6. 認証を調整します。 pg_upgrade いくつかの古いサーバーと新しいサーバーに接続します
そのため、pg_hba.conf で認証をピアに設定するか、
〜/ .pgpass ファイル (ドキュメントのセクション31.15「パスワード ファイル」を参照)。

7. 両方のサーバーを停止します。Unix では、次のようにして、両方のデータベース サーバーが停止していることを確認します。

pg_ctl -D /opt/PostgreSQL/8.4 停止
pg_ctl -D /opt/PostgreSQL/9.0 停止

または Windows では、適切なサービス名を使用します。

ネット ストップ postgresql-8.4
ネット ストップ postgresql-9.0

ストリーミング レプリケーションとログ配布スタンバイ サーバーは、
後のステップ。

8. スタンバイ サーバーを確認します: ストリーミング レプリケーションとログ配布をアップグレードしている場合
スタンバイ サーバー。次のコマンドを実行して、古いスタンバイ サーバーが追い付いていることを確認します。
古いプライマリ クラスタとスタンバイ クラスタに対する pg_controldata。 「最新」であることを確認します。
「チェックポイントの場所」の値はすべてのクラスターで一致します。 (古い場合は不一致が発生します)
スタンバイ サーバーは古いプライマリの前にシャットダウンされました。)

9. pg_upgrade を実行します。古いサーバーではなく、常に新しいサーバーの pg_upgrade バイナリを実行します。
pg_upgrade には、新旧のクラスターのデータと実行可能ファイルの指定が必要です
(bin) ディレクトリ。 ユーザーとポートの値、および必要かどうかを指定することもできます。
データはコピーされるのではなくリンクされます (デフォルト)。

リンク モードを使用すると、アップグレードが大幅に高速化され (ファイルのコピーが不要)、使用量が少なくなります。
ディスク容量は確保されていますが、新しいクラスタを起動すると古いクラスタにアクセスできなくなります。
アップグレード後のクラスター。 リンク モードでは、新旧のクラスター データも必要です
ディレクトリは同じファイル システム内にある必要があります。 (テーブルスペースと pg_xlog は別の場所にある場合もあります
ファイル システム。) オプションの完全なリストについては、pg_upgrade --help を参照してください。

当学校区の -ジョブ オプションにより、ファイルのコピー/リンクに複数の CPU コアを使用できるようになります
データベース スキーマのダンプと再ロードを並行して実行します。 始めるのに良いのは、
CPU コアとテーブルスペースの最大数。 このオプションにより、劇的に効果が得られます
マルチプロセッサ上で実行されているマルチデータベース サーバーをアップグレードする時間を短縮します。
機械。

Windows ユーザーの場合は、管理者アカウントにログインしてから、
postgres ユーザーとしてシェルを実行し、適切なパスを設定します。

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

次に、引用符で囲まれたディレクトリを使用して pg_upgrade を実行します。例:

pg_upgrade.exe
--old-datadir "C:/プログラム ファイル/PostgreSQL/8.4/データ"
--new-datadir "C:/Program Files/PostgreSQL/9.0/data"
--old-bindir "C:/Program Files/PostgreSQL/8.4/bin"
--new-bindir "C:/Program Files/PostgreSQL/9.0/bin"

一度開始すると、 pg_upgrade XNUMX つのクラスターに互換性があることを確認してから、
アップグレードします。 使用できます pg_upgrade - チェック たとえ古いものであっても、チェックのみを実行するには
サーバーはまだ実行中です。 pg_upgrade - チェック 手動調整についても概要を説明します
アップグレード後に作成する必要があります。 リンク モードを使用する場合は、
を使用する必要があります - リンク オプション - チェック リンクモード固有のチェックを有効にします。
pg_upgrade 現在のディレクトリへの書き込み権限が必要です。

当然のことながら、アップグレード中は誰もクラスターにアクセスすべきではありません。 pg_upgrade
意図しないクライアント接続を避けるために、デフォルトではポート 50432 でサーバーを実行します。 あなた
古いポート番号があるため、アップグレードを行うときに両方のクラスターで同じポート番号を使用できます。
新しいクラスターは同時に実行されません。 ただし、古いものを確認すると、
サーバーを実行している場合、古いポート番号と新しいポート番号は異なっている必要があります。

データベース スキーマの復元中にエラーが発生した場合、 pg_upgrade 出ていきます、そしてあなたは
以下のステップ 16 で説明するように、古いクラスターに戻す必要があります。 試してみる pg_upgrade
再度、古いクラスターを変更して、pg_upgrade スキーマを復元する必要があります。
成功する。 問題が contrib モジュールである場合は、contrib をアンインストールする必要がある場合があります。
古いクラスタからモジュールを削除し、アップグレード後に新しいクラスタにインストールします。
モジュールがユーザー データの保存に使用されていないことを前提としています。

10. ストリーミング レプリケーションとログ配布スタンバイをアップグレードする
サーバー: ストリーミング レプリケーションがある場合 (「ストリーミング レプリケーション」を参照)
ドキュメントの「レプリケーション」) またはログ配布 (セクション25.2「ログ配布」を参照)
スタンバイ サーバー」（ドキュメント内）スタンバイ サーバーは、次の手順に従ってアップグレードします。
彼ら。 スタンバイサーバーでは pg_upgrade を実行するのではなく、rsync を実行します。 する
まだサーバーを起動していません。 新しい PostgreSQL バイナリをスタンバイ サーバーにインストールします。
新しいバイナリとサポート ファイルがすべてのスタンバイ サーバーにインストールされていることを確認してください。
新しいスタンバイ データ ディレクトリが適切であることを確認してください。
存在する: 新しいスタンバイ データ ディレクトリが存在することを確認します。 存在するか空です。 もしも
initdb が実行された場合は、スタンバイ サーバーのデータ ディレクトリを削除します。 カスタム共有をインストールする
オブジェクト ファイル: 新しいスタンバイに同じカスタム共有オブジェクト ファイルをインストールします。
新しいマスタークラスターにインストールされます。 スタンバイ サーバーの停止: スタンバイ サーバーが
まだ実行中の場合は、上記の手順を使用して今すぐ停止してください。 設定ファイルを保存します。
保存する必要がある構成ファイルをスタンバイから保存します。
postgresql.conf、recovery.conf、これらは次回上書きまたは削除されます。
ステップ。 新しいマスター クラスターの開始と停止: 新しいマスター クラスターで、
wal_level postgresql.conf ファイルの hot_standby に設定してから、
集まる。 rsync を実行します: 新旧のデータベース クラスターの上にあるディレクトリから
ディレクトリで、各スレーブに対してこれを実行します。

rsync --archive --delete --hard-links --size-only old_pgdata new_pgdata remote_dir

コラボレー old_pgdata 　 新しい_pgdata 現在のディレクトリを基準とした相対値であり、 リモートディレクトリ
is 上記の. スタンバイ サーバー上の古いクラスタ ディレクトリと新しいクラスタ ディレクトリ。 古いものと新しいもの
相対クラスタ パスはマスター サーバーとスタンバイ サーバーで一致する必要があります。 rsync に問い合わせてください
リモート ディレクトリの指定の詳細については、マニュアル ページを参照してください。
スタンバイホスト:/opt/PostgreSQL/。 pg_upgrade の場合、rsync は高速になります - リンク モードは
転送ではなくリモートサーバー上にハードリンクを作成するために使用されます。
ユーザーデータ。

テーブルスペースがある場合は、テーブルスペースごとに同様の rsync コマンドを実行する必要があります。
テーブルスペースディレクトリ。 pg_xlog をデータ ディレクトリの外に移動した場合は、
rsync はそれらのディレクトリでも実行する必要があります。 ストリーミングレプリケーションを構成し、
ログ配布スタンバイ
サーバー: ログ配布用にサーバーを構成します。 (実行する必要はありません
pg_start_backup() 　 pg_stop_backup() または、スレーブとしてファイル システムのバックアップを作成します。
まだマスターと同期しています。)

11. pg_hba.conf の復元: pg_hba.conf を変更した場合は、元の設定を復元します。 それ
新しいクラスター内の他の構成ファイルを調整する必要がある場合もあります。
古いクラスター (postgresql.conf など) と一致します。

12. 新しいサーバーを起動します。これで、新しいサーバーを安全に起動できるようになり、rsync を実行できるようになります。
スタンバイサーバー。

13. アップグレード後の処理: アップグレード後の処理が必要な場合、pg_upgrade は
完了時に警告を発行します。 また、実行する必要があるスクリプト ファイルも生成されます。
管理者。 スクリプト ファイルは、必要な各データベースに接続します。
アップグレード後の処理。 各スクリプトは以下を使用して実行する必要があります。

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

スクリプトは任意の順序で実行でき、実行後に削除できます。

あぶない
一般に、再構築スクリプトで参照されるテーブルにアクセスするのは安全ではありません。
再構築スクリプトは完了まで実行されました。 そうすると、間違った結果が生じる可能性があります。
業績不振。 再構築スクリプトで参照されていないテーブルにアクセス可能
すぐに。

14. 統計: オプティマイザ統計は、 pg_upgrade、 あなたはするであろう
の最後にその情報を再生成するコマンドを実行するように指示されます。
アップグレードします。 新しいクラスターに一致するように接続パラメーターを設定する必要がある場合があります。

15. 古いクラスターの削除: アップグレードに満足したら、古いクラスターを削除できます。
クラスタのデータ ディレクトリを、前述のスクリプトを実行して実行します。 pg_upgrade 完了します。
(内部にユーザー定義の表領域がある場合、自動削除はできません。
古いデータ ディレクトリ。) 古いインストール ディレクトリ (例: bin、
共有）。

16. 古いクラスターに戻す: 実行後の場合 pg_upgrade、古い状態に戻したいと考えています。
クラスターの場合、いくつかのオプションがあります。

· 走った場合 pg_upgrade 　 - チェック、古いクラスターには変更が加えられませんでした。
そしていつでも再利用できます。

· 走った場合 pg_upgrade 　 - リンク、データ ファイルは古いものとの間で共有されます。
新しいクラスター。 新しいクラスターを開始した場合、新しいサーバーはそれらのクラスターに書き込みを行っています。
ファイルが共有されているため、古いクラスターを使用するのは安全ではありません。

· 走った場合 pg_upgrade 無し - リンク または、新しいサーバー、古いサーバーを起動しませんでした。
クラスターは、リンクが開始された場合に .old サフィックスが付けられることを除いて変更されませんでした。
$PGDATA/global/pg_control に追加されます。 古いクラスターを再利用するには、おそらく削除します
$PGDATA/global/pg_control の .old サフィックス。 その後、古いものを再起動できます
クラスタ。

注意事項

pg_upgrade は、これらの reg* OID 参照を含むデータベースのアップグレードをサポートしていません。
システム データ タイプ: regproc、regprocedure、regoper、regoperator、regconfig、および
統治者。 (regtype はアップグレードできます。)

すべての失敗、再構築、および再インデックスのケースが影響を与える場合、pg_upgrade によって報告されます。
インストール; テーブルとインデックスを再構築するためのアップグレード後のスクリプトが生成されます
自動的。 多くのクラスターのアップグレードを自動化しようとしている場合は、以下を見つける必要があります。
同一のデータベース スキーマを持つクラスターでは、すべてのクラスターで同じアップグレード後の手順が必要であること
クラスターのアップグレード。 これは、アップグレード後の手順がデータベースに基づいているためです。
ユーザーデータではなくスキーマ。

デプロイメントテストの場合、古いクラスターのスキーマのみのコピーを作成し、ダミーデータを挿入します。
そしてそれをアップグレードします。

構成ファイルのみを使用する PostgreSQL 9.2 より前のクラスターをアップグレードする場合
ディレクトリを指定するには、実際のデータ ディレクトリの場所を pg_upgrade に渡し、
サーバーへの構成ディレクトリの場所、例: -d /real-data-directory -o '-D
/構成ディレクトリ」。

デフォルト以外の Unix ドメイン ソケット ディレクトリを使用している 9.1 より前の古いサーバーを使用している場合、または
新しいクラスターのデフォルトとは異なるデフォルト、設定 ゴースト 古いものを指す
サーバーのソケットの場所。 (これは Windows には関係ありません。)

リンク モードを使用する必要があり、古いクラスターが変更されたくない場合は、
新しいクラスターが開始されたら、古いクラスターのコピーを作成し、それをリンク モードでアップグレードします。 に
古いクラスターの有効なコピーを作成し、使用します。 rsync 古いクラスターのダーティ コピーを作成するには
サーバーの実行中に古いサーバーをシャットダウンして実行します。 rsync -チェックサム 再び
変更を加えてコピーを更新し、整合性を保ちます。 (-チェックサム 必要です
なぜなら rsync ファイル変更時間の粒度は XNUMX 秒のみです。)
「postmaster.pid」などの一部のファイルを除外するには、セクション24.3.3「
ドキュメントの「低レベル API を使用したベース バックアップ」を参照してください。 ファイル システムがサポートしている場合
ファイル システムのスナップショットまたはコピーオンライト ファイル コピーを使用して、以下のバックアップを作成できます。
古いクラスターとテーブルスペース (ただし、スナップショットとコピーを作成する必要があります)
同時に、またはデータベースサーバーがダウンしている間に。

onworks.net サービスを使用してオンラインで pg_upgrade を使用する