7.4. PostgreSQL の使用

PDF

PostgreSQL サーバーは、SQL 言語をベースにした、オープンソースの堅牢かつ拡張性に優れたデータベースサーバーです。PostgreSQL サーバーは、オブジェクトリレーショナルデータベースシステムを提供します。これにより、広範なデータセットと多数の同時ユーザーを管理できます。このような理由から、PostgreSQL サーバーは、大量のデータを管理するためにクラスターで使用できます。

PostgreSQL サーバーには、データの整合性の確保、耐障害性のある環境やアプリケーションの構築を行うための機能が含まれます。PostgreSQL サーバーを使用すると、データベースを再コンパイルすることなく、独自のデータ型、カスタム関数、またはさまざまなプログラミング言語のコードでデータベースを拡張できます。

RHEL システムに PostgreSQL をインストールして設定する方法、PostgreSQL データをバックアップする方法、および PostgreSQL の以前のバージョンから移行する方法について説明します。

7.4.1. PostgreSQL のインストール

RHEL 8 では、PostgreSQL サーバーは複数のバージョンで利用でき、各バージョンは個別のストリームで提供されます。

PostgreSQL 10 - デフォルトのストリーム
PostgreSQL 9.6
PostgreSQL 12 - RHEL 8.1.1 以降で利用できます。
PostgreSQL 13 - RHEL 8.4 以降で利用できます。
PostgreSQL 15 - RHEL 8.8 以降で利用できます。
PostgreSQL 16 - RHEL 9.4 以降で利用可能

注記

設計上、同じモジュールの複数のバージョン (ストリーム) を並行してインストールすることはできません。したがって、postgresql モジュールから利用可能なストリームのいずれかを選択する必要があります。コンテナー内では、別々のバージョンの PostgreSQL データベースサーバーを使用できます。コンテナー内で複数の PostgreSQL バージョンを実行するを参照してください。

PostgreSQL をインストールするには、以下の手順に従います。

手順

postgresql モジュールからストリーム (バージョン) を選択し、サーバープロファイルを指定して PostgreSQL サーバーパッケージをインストールします。以下に例を示します。
```
# yum module install postgresql:16/server
```
postgres のスーパーユーザーが自動的に作成されます。
データベースクラスターを初期化します。
```
# postgresql-setup --initdb
```
Red Hat は、デフォルトの /var/lib/pgsql/data ディレクトリーにデータを保存することを推奨します。
postgresql サービスを開始します。
```
# systemctl start postgresql.service
```
postgresql サービスが、システムの起動時に起動するようにします。
```
# systemctl enable postgresql.service
```

モジュールストリームの使用方法は、ユーザー空間コンポーネントのインストール、管理、および削除を参照してください。

重要

RHEL 9 内の以前の postgresql ストリームからアップグレードする場合は、後続のストリームへの切り替えと RHEL 9 バージョンの PostgreSQL への移行の両方の手順に従ってください。

7.4.1.1. コンテナー内で複数の PostgreSQL バージョンを実行する

同じホスト上で別々のバージョンの PostgreSQL を実行するには、コンテナー内で実行してください。同じモジュールの複数のバージョン (ストリーム) を並行してインストールすることはできないためです。

この手順では、例として PostgreSQL 13 と PostgreSQL 15 を記載していますが、Red Hat Ecosystem Catalog で利用可能な任意の PostgreSQL コンテナーバージョンを使用できます。

前提条件

container-tools モジュールがインストールされている。

手順

Red Hat カスタマーポータルアカウントを使用して、registry.redhat.io レジストリーに認証します。
```
# podman login registry.redhat.io
```
すでにコンテナーレジストリーにログインしている場合は、このステップをスキップしてください。

コンテナー内で PostgreSQL 13 を実行します。

$ podman run -d --name <container_name> -e POSTGRESQL_USER=<user_name> -e POSTGRESQL_PASSWORD=<password> -e POSTGRESQL_DATABASE=<database_name> -p <host_port_1>:5432 rhel8/postgresql-13

このコンテナーイメージを使用する方法の詳細は、Red Hat Ecosystem Catalog を参照してください。

コンテナー内で PostgreSQL 15 を実行します。

$ podman run -d --name <container_name> -e POSTGRESQL_USER=<user_name> -e POSTGRESQL_PASSWORD=<password> -e POSTGRESQL_DATABASE=<database_name> -p <host_port_2>:5432 rhel8/postgresql-15

このコンテナーイメージを使用する方法の詳細は、Red Hat Ecosystem Catalog を参照してください。

コンテナー内で PostgreSQL 16 を実行します。
```
$ podman run -d --name <container_name> -e POSTGRESQL_USER=<user_name> -e POSTGRESQL_PASSWORD=<password> -e POSTGRESQL_DATABASE=<database_name> -p <host_port_3>:5432 rhel8/postgresql-16
```
このコンテナーイメージを使用する方法の詳細は、Red Hat Ecosystem Catalog を参照してください。
注記
2 つのデータベースサーバーのコンテナー名とホストポートが異なっている必要があります。
クライアントがネットワーク上のデータベースサーバーにアクセスできるように、ファイアウォールでホストポートを開きます。
```
# firewall-cmd --permanent --add-port={<host_port_1>/tcp,<host_port_2>/tcp,...}
# firewall-cmd --reload
```

検証

実行中のコンテナーに関する情報を表示します。
```
$ podman ps
```
データベースサーバーに接続し、root としてログインします。
```
# psql -u postgres -p -h localhost -P <host_port> --protocol tcp
```

関連情報

7.4.2. PostgreSQL ユーザーの作成

PostgreSQL ユーザーは以下のタイプのものです。

postgres UNIX システムユーザー: PostgreSQL サーバーおよびクライアントアプリケーション (pg_dump など) を実行する場合にのみ使用してください。データベース作成およびユーザー管理などの、PostgreSQL 管理上の対話的な作業には、postgres システムユーザーを使用しないでください。
データベースのスーパーユーザー: デフォルトの postgres PostgreSQL スーパーユーザーは、postgres システムユーザーとは関係ありません。pg_hba.conf ファイルの postgres のスーパーユーザーのアクセスを制限することができます。制限しない場合には、その他のパーミッションの制限はありません。他のデータベースのスーパーユーザーを作成することもできます。
特定のデータベースアクセスパーミッションを持つロール:
- データベースユーザー: デフォルトでログインするパーミッションがある。
- ユーザーのグループ: グループ全体のパーミッションを管理できるようにします。

ロールはデータベースオブジェクト (テーブルや関数など) を所有することができ、SQL コマンドを使用してオブジェクト権限を他のロールに割り当てることができます。

標準のデータベース管理権限には SELECT、INSERT、UPDATE、DELETE、TRUNCATE、REFERENCES、TRIGGER、CREATE、CONNECT、TEMPORARY、EXECUTE、および USAGE が含まれます。

ロール属性は、LOGIN、SUPERUSER、CREATEDB、および CREATEROLE などの特別な権限です。

重要

Red Hat は、スーパーユーザーではないロールとしてほとんどのタスクを実行することを推奨します。一般的な方法として、CREATEDB および CREATEROLE の権限を持つロールを作成し、このロールをデータベースおよびロールのすべてのルーチン管理に使用します。

前提条件

PostgreSQL サーバーがインストールされている
データベースクラスターが初期化されている

手順

ユーザーを作成するには、ユーザーのパスワードを設定し、ユーザーに CREATEROLE および CREATEDB の権限を割り当てます。
```
postgres=# CREATE USER mydbuser WITH PASSWORD 'mypasswd' CREATEROLE CREATEDB;
```
mydbuser をユーザー名に、mypasswd をユーザーのパスワードに置き換えます。

関連情報

例7.1 PostgreSQL データベースの初期化、作成、接続

この例では、PostgreSQL データベースを初期化方法、日常的なデータベース管理権限を持つデータベースユーザーの作成方法、および管理権限を持つデータベースユーザーを介して任意のシステムアカウントからアクセスできるデータベースの作成方法を示します。

PosgreSQL サーバーをインストールします。
```
# yum module install postgresql:13/server
```

データベースクラスターを初期化します。

# postgresql-setup --initdb
* Initializing database in '/var/lib/pgsql/data'
* Initialized, logs are in /var/lib/pgsql/initdb_postgresql.log

パスワードハッシュアルゴリズムを scram-sha-256 に設定します。
1. /var/lib/pgsql/data/postgresql.conf ファイルで、次の行を変更します。
```
#password_encryption = md5              # md5 or scram-sha-256
```
  更新後は次のようになります。
```
password_encryption = scram-sha-256
```
2. /var/lib/pgsql/data/pg_hba.conf ファイルで、IPv4 ローカル接続用に次の行を変更します。
```
host    all             all             127.0.0.1/32            ident
```
  更新後は次のようになります。
```
host    all             all             127.0.0.1/32            scram-sha-256
```
postgresql サービスを起動します。
```
# systemctl start postgresql.service
```
postgres という名前のシステムユーザーとしてログインします。
```
# su - postgres
```
PostgreSQL インタラクティブターミナルを起動します。
```
$ psql
psql (13.7)
Type "help" for help.

postgres=#
```

オプション: 現在のデータベース接続に関する情報を取得します。

postgres=# \conninfo
You are connected to database "postgres" as user "postgres" via socket in "/var/run/postgresql" at port "5432".

mydbuser という名前のユーザーを作成し、mydbuser のパスワードを設定して、CREATEROLE および CREATEDB の権限を mydbuser に割り当てます。
```
postgres=# CREATE USER mydbuser WITH PASSWORD 'mypasswd' CREATEROLE CREATEDB;
CREATE ROLE
```
これで、mydbuser ユーザーは、日常的なデータベース管理操作 (データベースの作成とユーザーインデックスの管理) を実行できるようになりました。
\q メタコマンドを使用して、インタラクティブターミナルからログアウトします。
```
postgres=# \q
```
postgres ユーザーセッションからログアウトします。
```
$ logout
```
mydbuser として PostgreSQL ターミナルにログインし、ホスト名を指定して、初期化中に作成されたデフォルトの postgres データベースに接続します。
```
# psql -U mydbuser -h 127.0.0.1 -d postgres
Password for user mydbuser:
Type the password.
psql (13.7)
Type "help" for help.

postgres=>
```

mydatabase という名前のデータベースを作成します。

postgres=> CREATE DATABASE mydatabase;
CREATE DATABASE
postgres=>

セッションからログアウトします。
```
postgres=# \q
```

mydbuser として mydatabase に接続します。

# psql -U mydbuser -h 127.0.0.1 -d mydatabase
Password for user mydbuser:
psql (13.7)
Type "help" for help.
mydatabase=>

オプション: 現在のデータベース接続に関する情報を取得します。

mydatabase=> \conninfo
You are connected to database "mydatabase" as user "mydbuser" on host "127.0.0.1" at port "5432".

7.4.3. PostgreSQL の設定

PostgreSQL データベースでは、データおよび設定ファイルはすべて、データベースクラスターと呼ばれる 1 つのディレクトリーに保存されます。Red Hat は、設定ファイルを含むすべてのデータをデフォルトの /var/lib/pgsql/data/ ディレクトリーに保存することを推奨しています。

PostgreSQL 設定は、以下のファイルで設定されます。

postgresql.conf: データベースのクラスターパラメーターの設定に使用されます。
postgresql.auto.conf: postgresql.conf と同様の基本的な PostgreSQL 設定を保持します。ただし、このファイルはサーバーの制御下にあります。これは、ALTER SYSTEM クエリーにより編集され、手動で編集することはできません。
pg_ident.conf: 外部認証メカニズムから PostgreSQL ユーザー ID へのユーザー ID のマッピングに使用されます。
pg_hba.conf: PostgreSQL データベースのクライアント認証の設定に使用されます。

PostgreSQL 設定を変更するには、以下の手順に従います。

手順

各設定ファイル (例: /var/lib/pgsql/data/postgresql.conf) を編集します。
postgresql サービスを再起動して、変更を有効にします。
```
# systemctl restart postgresql.service
```

例7.2 PostgreSQL データベースクラスターパラメーターの設定

以下の例では、/var/lib/pgsql/data/postgresql.conf ファイルのデータベースクラスターパラメーターの基本設定を示しています。

# This is a comment
log_connections = yes
log_destination = 'syslog'
search_path = '"$user", public'
shared_buffers = 128MB
password_encryption = scram-sha-256

例7.3 PostgreSQL でのクライアント認証の設定

以下の例では、/var/lib/pgsql/data/pg_hba.conf ファイルでクライアント認証を設定する方法を説明します。

# TYPE    DATABASE       USER        ADDRESS              METHOD
local     all            all                              trust
host      postgres       all         192.168.93.0/24      ident
host      all            all         .example.com         scram-sha-256

7.4.4. PostgreSQL サーバーにおける TLS 暗号化の設定

デフォルトでは、PostgreSQL は暗号化されていない接続を使用します。よりセキュアな接続のために、PostgreSQL サーバーで Transport Layer Security (TLS) サポートを有効にし、暗号化された接続を確立するようにクライアントを設定できます。

前提条件

PostgreSQL サーバーがインストールされている
データベースクラスターが初期化されている

手順

OpenSSL ライブラリーをインストールします。
```
# yum install openssl
```
TLS 証明書とキーを生成します。
```
# openssl req -new -x509 -days 365 -nodes -text -out server.crt \
  -keyout server.key -subj "/CN=dbhost.yourdomain.com"
```
dbhost.yourdomain.com を データベースのホストとドメイン名に置き換えます。
署名済み証明書と秘密鍵をデータベースサーバー上の必要なロケーションにコピーします。
```
# cp server.{key,crt} /var/lib/pgsql/data/.
```
署名付き証明書と秘密鍵の所有者とグループの所有権を postgres ユーザーに変更します。
```
# chown postgres:postgres /var/lib/pgsql/data/server.{key,crt}
```
所有者だけが読み取れるように、秘密鍵の権限を制限します。
```
# chmod 0400 /var/lib/pgsql/data/server.key
```
/var/lib/pgsql/data/postgresql.conf ファイルの次の行を変更して、パスワードハッシュアルゴリズムを scram-sha-256 に設定します。
```
#password_encryption = md5              # md5 or scram-sha-256
```
更新後は次のようになります。
```
password_encryption = scram-sha-256
```
/var/lib/pgsql/data/postgresql.conf ファイルの次の行を変更して、SSL/TLS を使用するように PostgreSQL を設定します。
```
#ssl = off
```
更新後は次のようになります。
```
ssl=on
```
/var/lib/pgsql/data/pg_hba.conf ファイルの IPv4 ローカル接続で次の行を変更して、TLS を使用するクライアントからの接続のみを受け入れるように、すべてのデータベースへのアクセスを制限します。
```
host		all		all		127.0.0.1/32		ident
```
更新後は次のようになります。
```
hostssl 	all		all		127.0.0.1/32		scram-sha-256
```
または、次の行を新たに追加して、単一のデータベースとユーザーのアクセスを制限できます。
```
hostssl	mydatabase	mydbuser	127.0.0.1/32		scram-sha-256
```
mydatabase をデータベース名に、mydbuser をユーザー名に置き換えます。
postgresql サービスを再起動して、変更を有効にします。
```
# systemctl restart postgresql.service
```

検証

接続が暗号化されていることを手動で確認するには、以下を行います。
1. mydbuser ユーザーとして PostgreSQL データベースに接続し、ホスト名とデータベース名を指定します。
```
$ psql -U mydbuser -h 127.0.0.1 -d mydatabase
Password for user mydbuser:
```
  mydatabase をデータベース名に、mydbuser をユーザー名に置き換えます。
2. 現在のデータベース接続に関する情報を取得します。
```
mydbuser=> \conninfo
You are connected to database "mydatabase" as user "mydbuser" on host "127.0.0.1" at port "5432".
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
```
PostgreSQL への接続が暗号化されているかどうかを検証する簡単なアプリケーションを作成できます。この例は、libpq-devel パッケージで提供される libpq クライアントライブラリーを使用する C で記述されたアプリケーションを示しています。
```
#include <stdio.h>
#include <stdlib.h>
#include <libpq-fe.h>

int main(int argc, char* argv[])
{
//Create connection
PGconn* connection = PQconnectdb("hostaddr=127.0.0.1 password=mypassword port=5432 dbname=mydatabase user=mydbuser");

if (PQstatus(connection) ==CONNECTION_BAD)
    {
    printf("Connection error\n");
    PQfinish(connection);
    return -1; //Execution of the program will stop here
    }
    printf("Connection ok\n");
    //Verify TLS
    if (PQsslInUse(connection)){
     printf("TLS in use\n");
     printf("%s\n", PQsslAttribute(connection,"protocol"));
    }
    //End connection
    PQfinish(connection);
    printf("Disconnected\n");
    return 0;
}
```
mypassword をパスワードに、mydatabase をデータベース名に、myduser をユーザー名に置き換えます。
注記
-lpq オプションを使用して、コンパイルのために pq ライブラリーをロードする必要があります。たとえば、GCC コンパイラーを使用してアプリケーションをコンパイルするには、次のようにします。
```
$ gcc source_file.c -lpq -o myapplication
```
この source_file.c には上記のサンプルコードが含まれており、myapplication はセキュアな PostgreSQL 接続を検証するためのアプリケーションの名前です。

例7.4 TLS 暗号化を使用した PostgreSQL データベースの初期化、作成、接続

この例では、PostgreSQL データベースの初期化方法、データベースユーザーとデータベースの作成方法、セキュアな接続を使用したデータベースへの接続方法を示します。

PosgreSQL サーバーをインストールします。
```
# yum module install postgresql:13/server
```

データベースクラスターを初期化します。

# postgresql-setup --initdb
* Initializing database in '/var/lib/pgsql/data'
* Initialized, logs are in /var/lib/pgsql/initdb_postgresql.log

OpenSSL ライブラリーをインストールします。
```
# yum install openssl
```
TLS 証明書とキーを生成します。
```
# openssl req -new -x509 -days 365 -nodes -text -out server.crt \
  -keyout server.key -subj "/CN=dbhost.yourdomain.com"
```
dbhost.yourdomain.com を データベースのホストとドメイン名に置き換えます。
署名済み証明書と秘密鍵をデータベースサーバー上の必要なロケーションにコピーします。
```
# cp server.{key,crt} /var/lib/pgsql/data/.
```
署名付き証明書と秘密鍵の所有者とグループの所有権を postgres ユーザーに変更します。
```
# chown postgres:postgres /var/lib/pgsql/data/server.{key,crt}
```
所有者だけが読み取れるように、秘密鍵の権限を制限します。
```
# chmod 0400 /var/lib/pgsql/data/server.key
```
パスワードハッシュアルゴリズムを scram-sha-256 に設定します。/var/lib/pgsql/data/postgresql.conf ファイルで、次の行を変更します。
```
#password_encryption = md5              # md5 or scram-sha-256
```
更新後は次のようになります。
```
password_encryption = scram-sha-256
```
SSL/TLS を使用するように PostgreSQL を設定します。/var/lib/pgsql/data/postgresql.conf ファイルで、次の行を変更します。
```
#ssl = off
```
更新後は次のようになります。
```
ssl=on
```
postgresql サービスを開始します。
```
# systemctl start postgresql.service
```
postgres という名前のシステムユーザーとしてログインします。
```
# su - postgres
```
postgres ユーザーとして PostgreSQL インタラクティブターミナルを起動します。
```
$ psql -U postgres
psql (13.7)
Type "help" for help.

postgres=#
```
mydbuser という名前のユーザーを作成し、mydbuser のパスワードを設定します。
```
postgres=# CREATE USER mydbuser WITH PASSWORD 'mypasswd';
CREATE ROLE
postgres=#
```

mydatabase という名前のデータベースを作成します。

postgres=# CREATE DATABASE mydatabase;
CREATE DATABASE
postgres=#

すべての権限を mydbuser ユーザーに付与します。

postgres=# GRANT ALL PRIVILEGES ON DATABASE mydatabase TO mydbuser;
GRANT
postgres=#

インタラクティブターミナルからログアウトします。
```
postgres=# \q
```
postgres ユーザーセッションからログアウトします。
```
$ logout
```
/var/lib/pgsql/data/pg_hba.conf ファイルの IPv4 ローカル接続で次の行を変更して、TLS を使用するクライアントからの接続のみを受け入れるように、すべてのデータベースへのアクセスを制限します。
```
host		all		all		127.0.0.1/32		ident
```
更新後は次のようになります。
```
hostssl 	all		all		127.0.0.1/32		scram-sha-256
```
postgresql サービスを再起動して、変更を有効にします。
```
# systemctl restart postgresql.service
```

mydbuser ユーザーとして PostgreSQL データベースに接続し、ホスト名とデータベース名を指定します。

$ psql -U mydbuser -h 127.0.0.1 -d mydatabase
Password for user mydbuser:
psql (13.7)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.

mydatabase=>

7.4.5. PostgreSQL データのバックアップ

PostgreSQL データをバックアップするには、以下のいずれかの方法を使用します。

SQL ダンプ: Backing up with SQL dump を参照してください。
ファイルシステムレベルのバックアップ: File system level backup を参照してください。
継続的アーカイブ: 継続的アーカイブを参照してください。

7.4.5.1. SQL ダンプを使用した PostgreSQL データのバックアップ

SQL ダンプのメソッドは、SQL コマンドを使用したダンプファイルの生成に基づいています。ダンプがデータベースサーバーにアップロードされると、ダンプ時と同じ状態でデータベースが再作成されます。

SQL ダンプは、以下の PostgreSQL クライアントアプリケーションによって保証されます。

pg_dump は、ロールまたはテーブル空間に関するクラスター全体の情報なしに単一のデータベースをダンプします。
pg_dumpall は、指定のクラスターに各データベースをダンプし、ロールやテーブル空間定義などのクラスター全体のデータを保持します。

デフォルトでは、pg_dump コマンドおよび pg_dumpall コマンドは、結果を標準出力に書き込みます。ダンプをファイルに保存するには、出力を SQL ファイルにリダイレクトします。作成される SQL ファイルは、テキスト形式またはその他の形式のいずれかになります。これにより並列処理が可能になり、オブジェクトの復元をより詳細に制御できます。

データベースにアクセスできる任意のリモートホストから、SQL ダンプを実行できます。

7.4.5.1.1. SQL ダンプの長所と短所

SQL ダンプには、他の PostgreSQL バックアップ方法と比較して、以下の長所があります。

SQL ダンプは、サーバーのバージョン固有ではない唯一の PostgreSQL バックアップメソッドです。pg_dump ユーティリティーの出力は、PostgreSQL の後続のバージョンに再読み込みできます。これは、ファイルシステムレベルのバックアップ、または継続的なアーカイブにはできません。
SQL ダンプは、32 ビットサーバーから 64 ビットサーバーへなど、異なるアーキテクチャーにデータベースを転送する際に有効な唯一の方法です。
SQL ダンプは、内部的に一貫性のあるダンプを提供します。ダンプは、pg_dump の実行開始時のデータベースのスナップショットを表します。
pg_dump ユーティリティーは、実行中のデータベースの他の操作をブロックしません。

SQL ダンプの短所は、ファイルシステムレベルのバックアップと比較して時間がかかることです。

7.4.5.1.2. pg_dump を使用した SQL ダンプの実行

クラスター全体の情報なしに単一のデータベースをダンプするには、pg_dump ユーティリティーを使用します。

前提条件

ダンプするすべてのテーブルへの読み取りアクセスが必要です。データベース全体をダンプするには、postgres のスーパーユーザーまたはデータベースの管理者権限を持つユーザーとして、コマンドを実行する必要があります。

手順

クラスター全体の情報なしでデータベースをダンプします。
```
$ pg_dump dbname > dumpfile
```

pg_dump が接続するデータベースサーバーを指定するには、以下のコマンドラインオプションを使用します。

ホストを定義する -h オプション
デフォルトのホストは、ローカルホストか、PGHOST 環境変数で指定されているものです。
ポートを定義する -p オプション
デフォルトのポートは、PGPORT 環境変数またはコンパイル済みデフォルトで示されます。

7.4.5.1.3. pg_dumpall を使用した SQL ダンプの実行

特定のデータベースクラスターで各データベースをダンプし、クラスター全体のデータを保持するには、pg_dumpall ユーティリティーを使用します。

前提条件

postgres スーパーユーザーまたはデータベースの管理者権限を持つユーザーとして、コマンドを実行する必要があります。

手順

データベースクラスターのすべてのデータベースをダンプし、クラスター全体のデータを保存します。
```
$ pg_dumpall > dumpfile
```

pg_dumpall が接続するデータベースサーバーを指定するには、以下のコマンドラインオプションを使用します。

ホストを定義する -h オプション
デフォルトのホストは、ローカルホストか、PGHOST 環境変数で指定されているものです。
ポートを定義する -p オプション
デフォルトのポートは、PGPORT 環境変数またはコンパイル済みデフォルトで示されます。
デフォルトのデータベースを定義する -l オプション
このオプションにより、初期化時に自動的に作成された postgres データベースとは異なるデフォルトのデータベースを選択できます。

7.4.5.1.4. pg_dump を使用したダンプされたデータベースの復元

pg_dump ユーティリティーを使用してダンプした SQL ダンプからデータベースを復元するには、以下の手順に従います。

前提条件

postgres スーパーユーザーまたはデータベースの管理者権限を持つユーザーとして、コマンドを実行する必要があります。

手順

新しいデータベースを作成します。
```
$ createdb dbname
```
ダンプされたデータベースのオブジェクトを所有するか、オブジェクトに対する権限が許可されたユーザーがすべて存在していることを検証してください。このようなユーザーが存在しない場合、復元は元の所有権と権限でオブジェクトの再作成に失敗します。
psql ユーティリティーを実行して、pg_dump ユーティリティーが作成したテキストファイルのダンプを復元します。
```
$ psql dbname < dumpfile
```
ここでの dumpfile は、pg_dump コマンドの出力になります。非テキストファイルのダンプを復元するには、代わりに pg_restore ユーティリティーを使用します。
```
$ pg_restore non-plain-text-file
```

7.4.5.1.5. pg_dumpall を使用したダンプされたデータベースの復元

pg_dumpall ユーティリティーを使用してダンプしたデータベースクラスターからデータを復元するには、以下の手順に従います。

前提条件

postgres スーパーユーザーまたはデータベースの管理者権限を持つユーザーとして、コマンドを実行する必要があります。

手順

ダンプされたデータベースのオブジェクトを所有するか、オブジェクトに対する権限が許可されたユーザーがすべて、すでに存在していることを検証してください。このようなユーザーが存在しない場合、復元は元の所有権と権限でオブジェクトの再作成に失敗します。
psql ユーティリティーを実行して、pg_dumpall ユーティリティーにより作成されたテキストファイルのダンプを復元します。
```
$ psql < dumpfile
```
ここでの dumpfile は、pg_dumpall コマンドの出力になります。

7.4.5.1.6. 別のサーバーでのデータベースの SQL ダンプの実行

pg_dump および psql はパイプに対する読み書きが可能であるため、あるサーバーから別のサーバーにデータベースを直接ダンプできます。

手順

データベースを、サーバーから別のサーバーにダンプするには、以下のコマンドを実行します。
```
$ pg_dump -h host1 dbname | psql -h host2 dbname
```

7.4.5.1.7. 復元中の SQL エラーの処理

デフォルトでは、SQL エラーが発生した場合、psql は実行を継続します。これにより、データベースの復元は一部のみとなります。

デフォルトの動作を変更するには、ダンプを復元する際に以下のいずれかの方法を使用します。

前提条件

postgres スーパーユーザーまたはデータベースの管理者権限を持つユーザーとして、コマンドを実行する必要があります。

手順

ON_ERROR_STOP 変数を設定して SQL エラーが発生した場合は、終了ステータスが 3 で psql を終了します。
```
$ psql --set ON_ERROR_STOP=on dbname < dumpfile
```
ダンプ全体が単一のトランザクションとして復元されるように指定して、復元が完全に完了するかキャンセルされるようにします。
- psql ユーティリティーを使用してテキストファイルのダンプを復元する場合:
```
$ psql -1
```
- pg_restore ユーティリティーを使用してテキストファイル以外のダンプを復元する場合:
```
$ pg_restore -e
```
  この方法を使用する場合は、多少のエラーでも、すでに何時間も実行している復元操作をキャンセルできます。

7.4.5.1.8. 関連情報

PostgreSQL Documentation - SQL dump

7.4.5.2. ファイルシステムレベルのバックアップを使用した PostgreSQL データのバックアップ

ファイルシステムレベルのバックアップを実行するには、PostgreSQL データベースファイルを別の場所に作成します。たとえば、以下のいずれかの方法を使用できます。

tar ユーティリティーを使用してアーカイブファイルを作成します。
rsync ユーティリティーを使用して、ファイルを別の場所にコピーします。
データディレクトリーの一貫したスナップショットを作成します。

7.4.5.2.1. ファイルシステムのバックアップを作成する利点と制限

ファイルシステムレベルのバックアップは、他の PostgreSQL バックアップ方法と比較して、以下の長所があります。

通常、ファイルシステムレベルのバックアップは、SQL ダンプよりも高速です。

ファイルシステムレベルのバックアップは、他の PostgreSQL バックアップ方法と比較して、以下の制限があります。

このバックアップメソッドは、RHEL 7 から RHEL 8 にアップグレードし、アップグレードしたシステムにデータを移行する場合には適していません。ファイルシステムレベルのバックアップは、アーキテクチャーと RHEL メジャーバージョンに固有のものです。アップグレードに成功しなかった場合は、RHEL 7 システムでデータを復元できますが、RHEL 8 システムではデータを復元できません。
データをバックアップおよび復元する前に、データベースサーバーをシャットダウンする必要があります。
特定のファイルまたはテーブルを個々にバックアップまたは復元することはできません。ファイルシステムのバックアップは、データベースクラスター全体を完全にバックアップおよび復元する場合にのみ機能します。

7.4.5.2.2. ファイルシステムレベルのバックアップの実行

ファイルシステムレベルのバックアップを実行するには、次の手順を使用します。

手順

データベースクラスターの場所を選択し、このクラスターを初期化します。
```
# postgresql-setup --initdb
```
postgresql サービスを停止します。
```
# systemctl stop postgresql.service
```
任意のメソッドを使用してファイルシステムのバックアップを作成します (例: tar アーカイブ)。
```
$ tar -cf backup.tar /var/lib/pgsql/data
```
postgresql サービスを起動します。
```
# systemctl start postgresql.service
```

関連情報

PostgreSQL Documentation - file system level backup

7.4.5.3. 継続的にアーカイブして PostgreSQL データのバックアップを作成

7.4.5.3.1. 継続的なアーカイブの概要

PostgreSQL は、データベースのデータファイルに対するすべての変更を、クラスターのデータディレクトリーの pg_wal/ サブディレクトリーで利用可能なログ先行書き込み (WAL) ファイルに記録します。このログは、主にクラッシュからの復元を目的としています。クラッシュ後、最後のチェックポイント以降に作成されたログエントリーを使用して、データベースの整合性まで復元できます。

オンラインバックアップとも呼ばれる継続的なアーカイブメソッドは、WAL ファイルを、稼働中のサーバーまたはファイルシステムレベルのバックアップで実行されるベースバックアップの形式でデータベースクラスターのコピーと組み合わせます。

データベース復元が必要な場合は、データベースクラスターのコピーからデータベースを復元してから、バックアップを作成した WAL ファイルからログを再生して、システムを現在の状態にすることができます。

継続的なアーカイブメソッドでは、少なくとも最後のベースバックアップの開始時間までさかのぼって、アーカイブされたすべての WAL ファイルの連続したシーケンスを保持する必要があります。そのため、基本バックアップの理想的な頻度は、次の条件により異なります。

アーカイブされた WAL ファイルで利用可能なストレージボリューム。
復元が必要な場合の、データ復元の最大許容期間。最後のバックアップからの期間が長い場合、システムはより多くの WAL セグメントを再生するため、回復に時間がかかります。

注記

pg_dump および pg_dumpall SQL ダンプは、継続的にアーカイブするバックアップソリューションの一部として使用することができません。SQL ダンプは論理バックアップを生成しますが、WAL 再生で使用する上で十分な情報は含まれていません。

継続的なアーカイブメソッドを使用してデータベースのバックアップと復元を実行するには、以下の手順に従います。

WAL ファイルのアーカイブ手順をセットアップおよびテストします。WAL アーカイブを参照してください。
ベースバックアップを実行します。ベースバックアップを参照してください。

データを復元するには、連続アーカイブを使用したデータベースの復元の手順に従います。

7.4.5.3.2. 継続的なアーカイブの長所と短所

継続的なアーカイブは、PostgreSQL のその他のバックアップ方法と比較して、以下の利点があります。

継続的なバックアップメソッドでは、バックアップ内の内部不整合がログ再生により修正されるため、整合性が完全に取れないベースバックアップを使用することができます。したがって、実行中の PostgreSQL サーバーでベースバックアップを実行できます。
ファイルシステムのスナップショットは必要ありません。tar または同様のアーカイブユーティリティーで十分です。
継続的にバックアップを行うには、継続的に WAL ファイルをアーカイブします。これは、ログ再生用の WAL ファイルの順序が無限に長くなる可能性があるためです。これは、特に大規模なデータベースで有用です。
継続的バックアップは、特定の時点への復旧 (ポイントインタイムリカバリー) をサポートします。WAL エントリーを最後まで再生する必要はありません。再生はいつでも停止でき、ベースバックアップを作成してから、データベースをいつでもその状態に復元できます。
一連の WAL ファイルが同じベースのバックアップファイルで読み込まれた別のマシンが継続的に利用可能である場合は、任意の時点で、データベースで現在に一番近いコピーで、他のマシンを復元できます。

継続的なアーカイブには、その他の PostgreSQL バックアップ方法と比較して、以下の短所があります。

継続バックアップ方法は、サブセットではなく、データベースクラスター全体の復元のみをサポートします。
継続的にバックアップするには、大きなアーカイブストレージが必要です。

7.4.5.3.3. WAL アーカイブの設定

稼働中の PostgreSQL サーバーでは、ログ先行書き込み (WAL) レコードのシーケンスを生成します。サーバーは、このシーケンスを WAL セグメントファイルに物理的に分割します。このファイルには、WAL シーケンスの位置を反映する数値名が与えられます。WAL のアーカイブを使用しない場合は、セグメントファイルは再利用され、より大きなセグメント番号に名前が変更されます。

WAL データをアーカイブする場合、各セグメントファイルの内容がキャプチャーされ、新しい場所に保存されてから、セグメントファイルが再利用されます。別のマシン上の NFS マウントディレクトリー、テープドライブ、または CD など、コンテンツの保存場所には複数のオプションがあります。

WAL レコードには、設定ファイルへの変更が含まれていないことに注意してください。

WAL のアーカイブを有効にするには、以下の手順に従います。

手順

/var/lib/pgsql/data/postgresql.conf ファイルで以下を行います。
1. wal_level 設定パラメーターを replica 以降に設定します。
2. archive_mode パラメーターを on に設定します。
3. archive_command 設定パラメーターでシェルコマンドを指定します。cp コマンド、別のコマンド、またはシェルスクリプトを使用できます。
postgresql サービスを再起動して、変更を適用します。
```
# systemctl restart postgresql.service
```
アーカイブコマンドをテストし、既存のファイルが上書きされないこと、失敗した場合にゼロ以外の終了ステータスが返されることを確認します。
データを保護するには、セグメントファイルがグループまたはワールド読み取りアクセスを持たないディレクトリーにアーカイブされていることを確認してください。

注記

archive コマンドは、完了した WAL セグメントでのみ実行されます。WAL トラフィックをほとんど生成しないサーバーでは、トランザクションの完了とアーカイブストレージへの安全な記録の間にかなりの遅延が生じる可能性があります。アーカイブされていないデータの古さを制限するには、以下を行います。

archive_timeout パラメーターを設定して、サーバーが特定の頻度で新しい WAL セグメントファイルに切り替えるように強制します。
pg_switch_wal パラメーターを使用して、セグメント切り替えを強制し、トランザクションが終了後すぐにアーカイブされるようにします。

例7.5 WAL セグメントをアーカイブするためのシェルコマンド

この例は、archive_command 設定パラメーターに設定できる簡単なシェルコマンドを示しています。

以下のコマンドは、完了したセグメントファイルを必要な場所にコピーします。

archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'

%p パラメーターは、アーカイブするファイルの相対パスに置き換えられ、%f パラメーターはファイル名に置き換えられます。

このコマンドは、アーカイブ可能な WAL セグメントを /mnt/server/archivedir/ ディレクトリーにコピーします。%p パラメーターおよび %f パラメーターを置き換えると、実行されたコマンドは以下のようになります。

test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_wal/00000001000000A900000065 /mnt/server/archivedir/00000001000000A900000065

アーカイブされる新規ファイルごとに同様のコマンドが生成されます。

関連情報

PostgreSQL 16 ドキュメント

7.4.5.3.4. ベースバックアップの作成

ベースバックアップは、複数の方法で作成できます。ベースバックアップを実行する最も簡単な方法は、実行中の PostgreSQL サーバーで pg_basebackup ユーティリティーを使用することです。

ベースバックアッププロセスは、WAL アーカイブ領域に保存され、ベースバックアップに必要な最初の WAL セグメントファイルにちなんで名付けられたバックアップ履歴ファイルを作成します。

バックアップ履歴ファイルは、開始時間および終了時間、およびバックアップの WAL セグメントが含まれる小さなテキストファイルです。ラベル文字列を使用して関連するダンプファイルを特定した場合は、バックアップ履歴ファイルを使用して復元するダンプファイルを判断できます。

注記

データを確実に復元できるようにするために、複数のバックアップセットを維持することを検討してください。

ベースバックアップを実行するには、以下の手順を行います。

前提条件

postgres スーパーユーザー、データベースの管理者権限のあるユーザー、または少なくとも REPLICATION パーミッションを持つ別のユーザーとして、コマンドを実行する必要があります。
ベースバックアップ中およびベースバックアップ後に生成されたすべての WAL セグメントファイルを保持する必要があります。

手順

pg_basebackup ユーティリティーを使用してベースバックアップを実行します。
- 個々のファイル (プレーン形式) としてベースバックアップを作成するには、以下を実行します。
```
$ pg_basebackup -D backup_directory -Fp
```
  backup_directory は、任意のバックアップの場所に置き換えます。
  テーブル空間を使用し、サーバーと同じホストでベースバックアップを実行する場合は、--tablespace-mapping オプションも使用する必要があります。そうしないと、バックアップを同じ場所に書き込もうとすると、バックアップが失敗します。
- tar アーカイブ (tar および圧縮形式) としてベースバックアップを作成するには、以下を実行します。
```
$ pg_basebackup -D backup_directory -Ft -z
```
  backup_directory は、任意のバックアップの場所に置き換えます。
  このようなデータを復元するには、ファイルを正しい場所に手動で抽出する必要があります。
ベースバックアッププロセスが完了すると、バックアップ履歴ファイルで指定されている、データベースクラスターのコピーとバックアップ中に使用された WAL セグメントファイルを安全にアーカイブします。
ベースバックアップで使用されている WAL セグメントファイルよりも数値が小さい WAL セグメントを削除します。これらはベースバックアップよりも古く、復元には必要ないためです。

pg_basebackup が接続するデータベースサーバーを指定するには、以下のコマンドラインオプションを使用します。

ホストを定義する -h オプション
デフォルトのホストは、ローカルホストまたは PGHOST 環境変数により指定されたホストです。
ポートを定義する -p オプション
デフォルトのポートは、PGPORT 環境変数またはコンパイル済みデフォルトで示されます。

関連情報

7.4.5.3.5. 継続的なアーカイブバックアップを使用したデータベースの復元

継続バックアップを使用してデータベースを復元するには、以下の手順を行います。

手順

サーバーを停止します。
```
# systemctl stop postgresql.service
```
必要なデータを一時的な場所にコピーします。
必要に応じて、クラスターデータのディレクトリー全体と、すべてのテーブル空間をコピーします。既存データベースのコピーを 2 つ保持するには、システムに十分な空き領域が必要になることに注意してください。
十分な容量がない場合は、クラスターの pg_wal ディレクトリーの内容を保存します。これには、システムがダウンする前にアーカイブされなかったログが含まれます。
クラスターデータディレクトリー、および使用しているテーブル空間のルートディレクトリー下の既存ファイルおよびサブディレクトリーをすべて削除します。
ベースバックアップからデータベースファイルを復元します。
以下の点を確認してください。
- ファイルは、正しい所有権 (root ではなくデータベースシステムのユーザー) で復元されます。
- ファイルは、正しい権限で復元されます。
- pg_tblspc/ サブディレクトリーのシンボリックリンクが正しく復元されます。
pg_wal/ サブディレクトリーにあるファイルをすべて削除します。
このファイルは、ベースバックアップから作成されるため、非推奨になりました。pg_wal/ をアーカイブしていない場合は、適切な権限で再作成します。
手順 2 で保存したアーカイブされていない WAL セグメントファイルを pg_wal/ にコピーします。
クラスターデータディレクトリーの recovery.conf リカバリーコマンドファイルを作成し、restore_command 設定パラメーターにシェルコマンドを指定します。cp コマンド、別のコマンド、またはシェルスクリプトを使用できます。以下に例を示します。
```
restore_command = 'cp /mnt/server/archivedir/%f "%p"'
```
サーバーを起動します。
```
# systemctl start postgresql.service
```
サーバーは復元モードに入り、引き続き必要なアーカイブファイル (WAL) を読み込みます。
外部エラーにより復元が終了した場合は、サーバーを再起動して復元を続行します。復元プロセスが完了すると、サーバーは recovery.conf の名前を recovery. done に変更します。これにより、サーバーが通常のデータベース操作を開始した後に、誤ってリカバリーモードに戻るのを防ぐことができます。
データベースのコンテンツを確認して、データベースが必要な状態に復元されたことを検証します。
データベースが必要な状態に復元されていない場合は、手順 1 に戻ります。データベースが必要な状態に復元された場合は、pg_hba.conf ファイルでクライアント認証設定を復元して接続できるようにします。

継続バックアップを使用した復元の詳細は、PostgreSQL ドキュメントを参照してください。

7.4.5.3.6. 関連情報

継続的アーカイブ方法

7.4.6. RHEL 8 バージョンの PostgreSQL への移行

Red Hat Enterprise Linux 7 には、PostgreSQL 9.2 が、PostgreSQL サーバーのデフォルトバージョンとして含まれます。また、RHEL 7 の Software Collections として、複数の PostgreSQL のバージョンが提供されます。

Red Hat Enterprise Linux 8 は、PostgreSQL 10 (デフォルトの postgresql ストリーム)、PostgreSQL 9.6、PostgreSQL 12、PostgreSQL 13、および PostgreSQL 15 を提供します。

Red Hat Enterprise Linux 上の PostgreSQL のユーザーは、データベースファイルの移行パスを使用できます。

高速アップグレードメソッドは、ダンプおよび復元のプロセスよりも速くなります。ただし、場合によっては高速アップグレードが機能せず、ダンプおよび復元プロセスしか使用できない場合があります。そのようなケースには、以下が含まれます。

アーキテクチャー間のアップグレード
plpython または plpython2 拡張を使用するシステム。RHEL 8 AppStream リポジトリーには postgresql-plpython3 パッケージのみが含まれ、postgresql-plpython2 パッケージは含まれません。
高速アップグレードは、PostgreSQLの Red Hat Software Collections バージョンからの移行ではサポートされません。

新しいバージョンの PostgreSQL に移行するための前提条件として、すべての PostgreSQL データベースをバックアップします。

データベースをダンプし、SQL ファイルのバックアップを実行することは、ダンプおよび復元プロセスで必要であり、高速アップグレードメソッドとして推奨されます。

新しいバージョンの PostgreSQL に移行する前に、移行する PostgreSQL バージョンと、移行元と移行先のバージョンの間にあるすべて PostgreSQL バージョンのアップストリームの互換性ノートを参照してください。

7.4.6.1. PostgreSQL 15 と PostgreSQL 16 間の主な違い

PostgreSQL 16 では、次の主な変更点が導入されました。

postmasters バイナリーが利用できなくなりました

PostgreSQL が postmaster バイナリーとともに配布されなくなりました。提供されている systemd ユニットファイル (systemctl start postgres コマンド) を使用して postgresql サーバーを起動するユーザーは、この変更の影響を受けません。以前に postmaster バイナリーを介して postgresql サーバーを直接起動していた場合は、今後は代わりに postgres バイナリーを使用する必要があります。

ドキュメントがパッケージに同梱されなくなりました

PostgreSQL のパッケージで PDF 形式のドキュメントが提供されなくなりました。代わりにオンラインドキュメントを使用してください。

7.4.6.2. PostgreSQL 13 と PostgreSQL 15 間の主な違い

PostgreSQL 15 では、以下の後方互換性のない変更が導入されました。

パブリックスキーマのデフォルトパーミッション

パブリックスキーマのデフォルトパーミッションは、PostgreSQL 15 で変更されています。新規に作成されたユーザーは、GRANT ALL ON SCHEMA public TO myuser; コマンドを使用して、権限を明示的に付与する必要があります。

次の例は PostgreSQL 13 以前で動作します。

postgres=# CREATE USER mydbuser;
postgres=# \c postgres mydbuser
postgres=$ CREATE TABLE mytable (id int);

次の例は PostgreSQL 15 以降で動作します。

postgres=# CREATE USER mydbuser;
postgres=# GRANT ALL ON SCHEMA public TO mydbuser;
postgres=# \c postgres mydbuser
postgres=$ CREATE TABLE mytable (id int);

注記

pg_hba.conf ファイルで mydbuser のアクセス権が適切に設定されていることを確認してください。詳細は、PostgreSQL ユーザーの作成を参照してください。

PQsendQuery() がパイプラインモードでサポートされなくなる

PostgreSQL 15 以降、libpq PQsendQuery() 関数はパイプラインモードでサポートされなくなりました。影響を受けるアプリケーションを変更して、代わりに PQsendQueryParams() 関数を使用します。

7.4.6.3. pg_upgrade ユーティリティーを使用した高速アップグレード

高速アップグレードでは、バイナリーデータファイルを /var/lib/pgsql/data/ ディレクトリーにコピーし、pg_upgrade ユーティリティーを使用する必要があります。

この方法を使用すると、データを移行できます。

RHEL 7 システムバージョンの PostgreSQL 9.2 から、RHEL 8 バージョンの PostgreSQL 10 へ
RHEL 8 バージョンの PostgreSQL 12 から RHEL バージョンの PostgreSQL 13 へ
RHEL 8 バージョンの PostgreSQL 12 から RHEL バージョンの PostgreSQL 13 へ
RHEL 8 または 9 バージョンの PostgreSQL 15 から RHEL バージョンの PostgreSQL 16 へ
RHEL 8 または 9 バージョンの PostgreSQL 15 から RHEL バージョンの PostgreSQL 16 へ

RHEL 8 内の以前の postgresql ストリームからアップグレードする場合は後続のストリームへの切り替えの説明に従い、PostgreSQL データを移行します。

RHEL 内の PostgreSQL バージョンの組み合わせと、Red Hat Software Collections バージョンの PostgreSQL から RHEL への移行には、アップグレードのダンプおよび復元を使用します。

以下の手順では、高速アップグレードメソッドを使用して、RHEL 7 システムバージョンの PostgreSQL 9.2 から、RHEL 8 バージョンの PostgreSQL へ移行する方法を説明します。

前提条件

アップグレードを実行する前に、PostgreSQL データベースに保存されているすべてのデータのバックアップを作成します。デフォルトでは、すべてのデータは、RHEL 7 および RHEL 8 システムの両方の /var/lib/pgsql/data/ ディレクトリーに保存されます。

手順

RHEL 8 システムで、移行するストリーム (バージョン) を有効にします。
```
# yum module enable postgresql:stream
```
stream は、選択した PostgreSQL サーバーのバージョンに置き換えます。
PostgreSQL 10 を提供するデフォルトストリームを使用する場合は、この手順を省略できます。
RHEL 8 システムで、postgresql-server パッケージおよび postgresql-upgrade パッケージをインストールします。
```
# yum install postgresql-server postgresql-upgrade
```
必要に応じて、RHEL 7 で PostgreSQL サーバーモジュールを使用している場合は、その 2 つのバージョンを RHEL 8 システムにインストールし、PostgreSQL 9.2 (postgresql-upgrade パッケージでインストール) および対象バージョンの PostgreSQL (postgresql-server パッケージでインストール) の両方に対してコンパイルします。サードパーティーの PostgreSQL サーバーモジュールをコンパイルする必要がある場合は、postgresql-devel パッケージと postgresql-upgrade-devel パッケージの両方に対してビルドしてください。
以下の項目を確認します。
- 基本設定 - RHEL 8 システムで、サーバーがデフォルトの /var/lib/pgsql/data ディレクトリーを使用し、データベースが正しく初期化され、有効になっているかどうかを確認します。さらに、データファイルは、/usr/lib/systemd/system/postgresql.service ファイルに記載されているパスと同じパスに保存する必要があります。
- PostgreSQL サーバー - システムは複数の PostgreSQL サーバーを実行できます。これらのすべてのサーバーのデータディレクトリーが独立して処理されていることを確認してください。
- PostgreSQL サーバーモジュール - RHEL 7 で使用されていた PostgreSQL サーバーモジュールも、RHEL 8 システムにインストールされていることを確認してください。プラグインは、/usr/lib64/pgsql/ ディレクトリー (32 ビットシステムの /usr/lib/pgsql/ ディレクトリー) にインストールされる点に注意してください。
データのコピー時に、postgresql サービスがソースおよびターゲットのシステムで稼働していないことを確認します。
```
# systemctl stop postgresql.service
```
データベースファイルをソースの場所から RHEL 8 システムの /var/lib/pgsql/data/ ディレクトリーにコピーします。
PostgreSQL ユーザーで以下のコマンドを実行して、アップグレードプロセスを実行します。
```
# postgresql-setup --upgrade
```
これでバックグラウンドで pg_upgrade プロセスが開始します。
障害が発生すると、postgresql-setup は通知のエラーメッセージを提供します。
/var/lib/pgsql/data-old から新規クラスターに、以前の設定をコピーします。
高速アップグレードは、新しいデータスタックで以前の設定を再利用せず、設定がゼロから生成されることに注意してください。古い設定と新しい設定を手動で組み合わせたい場合は、データディレクトリーの *.conf ファイルを使用します。
新しい PostgreSQL サーバーを起動します。
```
# systemctl start postgresql.service
```
新しいデータベースクラスターを分析します。
- PostgreSQL 13 以前の場合:
```
su postgres -c '~/analyze_new_cluster.sh'
```
- PostgreSQL 15 以降の場合:
```
su postgres -c 'vacuumdb --all --analyze-in-stages'
```
  注記
  場合によって、ALTER COLLATION name REFRESH VERSION を使用する必要があります。詳細は、アップストリームのドキュメントを参照してください。
システムの起動時に、新しい PostgreSQL サーバーを自動的に起動させる場合は、次のコマンドを実行します。
```
# systemctl enable postgresql.service
```

7.4.6.4. ダンプおよび復元のアップグレード

ダンプおよび復元のアップグレードを使用する場合は、すべてのデータベースのコンテンツを SQL ファイルのダンプファイルにダンプする必要があります。

ダンプおよび復元のアップグレードは高速アップグレード方法よりも低速であり、生成された SQL ファイルで手動修正が必要になる場合があります。

この方法を使用すると、以下からデータを移行できます。

Red Hat Enterprise Linux 7 システムバージョンの PostgreSQL 9.2
以前の Red Hat Enterprise Linux 8 バージョンの PostgreSQL
Red Hat Software Collections の PostgreSQL の以前のバージョンまたは同等バージョン:
- PostgreSQL 9.2 (サポート対象外になりました)
- PostgreSQL 9.4 (サポート対象外になりました)
- PostgreSQL 9.6 (サポート対象外になりました)
- PostgreSQL 10
- PostgreSQL 12
- PostgreSQL 13

RHEL 7 および RHEL 8 システムでは、PostgreSQL データは、デフォルトで /var/lib/pgsql/data/ ディレクトリーに保存されます。Red Hat Software Collections バージョンの PostgreSQLの場合、デフォルトのデータディレクトリーは /var/opt/rh/collection_name/lib/pgsql/data/ です (/opt/rh/postgresql92/root/var/lib/pgsql/data/ ディレクトリーを使用する postgresql92 を除く)。

ダンプおよび復元のアップグレードを実行するには、ユーザーを root に変更します。

以下の手順では、RHEL 7 システムバージョンの PostgreSQL 9.2 から、RHEL 8 バージョンの PostgreSQL への移行方法を説明します。

手順

RHEL 7 システムで PostgreSQL 9.2 サーバーを起動します。
```
# systemctl start postgresql.service
```
RHEL 7 システムで、すべてのデータベースのコンテンツを pgdump_file.sql ファイルにダンプします。
```
su - postgres -c "pg_dumpall > ~/pgdump_file.sql"
```
データベースが正しくダンプされたことを確認します。
```
su - postgres -c 'less "$HOME/pgdump_file.sql"'
```
これにより、ダンプされた sql ファイルのパスが /var/lib/pgsql/pgdump_file.sql に表示されます。
RHEL 8 システムで、移行するストリーム (バージョン) を有効にします。
```
# yum module enable postgresql:stream
```
stream は、選択した PostgreSQL サーバーのバージョンに置き換えます。
PostgreSQL 10 を提供するデフォルトストリームを使用する場合は、この手順を省略できます。
RHEL 8 システムで、postgresql-server パッケージをインストールします。
```
# yum install postgresql-server
```
必要に応じて、RHEL 7 で PostgreSQL サーバーモジュールを使用している場合は、RHEL 8 システムにもインストールしてください。サードパーティーの PostgreSQL サーバーモジュールをコンパイルする必要がある場合は、postgresql-devel パッケージに対してビルドします。
RHEL 8 システムで、新しい PostgreSQL サーバーのデータディレクトリーを初期化します。
```
# postgresql-setup --initdb
```
RHEL 8 システムで、pgdump_file.sql を PostgreSQL ホームディレクトリーにコピーし、ファイルが正しくコピーされたことを確認します。
```
su - postgres -c 'test -e "$HOME/pgdump_file.sql" && echo exists'
```
RHEL 7 システムから設定ファイルをコピーします。
```
su - postgres -c 'ls -1 $PGDATA/*.conf'
```
コピーされる設定ファイルは、以下のとおりです。
- /var/lib/pgsql/data/pg_hba.conf
- /var/lib/pgsql/data/pg_ident.conf
- /var/lib/pgsql/data/postgresql.conf
RHEL 8 システムで、新しい PostgreSQL サーバーを起動します。
```
# systemctl start postgresql.service
```
RHEL 8 システムで、ダンプされた sql ファイルからデータをインポートします。
```
su - postgres -c 'psql -f ~/pgdump_file.sql postgres'
```

注記

Red Hat Software Collections バージョンの PostgreSQL からアップグレードする場合は、scl enable collection_name が含まれるようにコマンドを調整します。たとえば、rh-postgresql96 Software Collection からデータをダンプする場合は、以下のコマンドを使用します。

su - postgres -c 'scl enable rh-postgresql96 "pg_dumpall > ~/pgdump_file.sql"'

7.4. PostgreSQL の使用

7.4.1. PostgreSQL のインストール

7.4.1.1. コンテナー内で複数の PostgreSQL バージョンを実行する

7.4.2. PostgreSQL ユーザーの作成

7.4.3. PostgreSQL の設定

7.4.4. PostgreSQL サーバーにおける TLS 暗号化の設定

7.4.5. PostgreSQL データのバックアップ

7.4.5.1. SQL ダンプを使用した PostgreSQL データのバックアップ

7.4.5.1.1. SQL ダンプの長所と短所

7.4.5.1.2. pg_dump を使用した SQL ダンプの実行

7.4.5.1.3. pg_dumpall を使用した SQL ダンプの実行

7.4.5.1.4. pg_dump を使用したダンプされたデータベースの復元

7.4.5.1.5. pg_dumpall を使用したダンプされたデータベースの復元

7.4.5.1.6. 別のサーバーでのデータベースの SQL ダンプの実行

7.4.5.1.7. 復元中の SQL エラーの処理

7.4.5.1.8. 関連情報

7.4.5.2. ファイルシステムレベルのバックアップを使用した PostgreSQL データのバックアップ

7.4.5.2.1. ファイルシステムのバックアップを作成する利点と制限

7.4.5.2.2. ファイルシステムレベルのバックアップの実行

7.4.5.3. 継続的にアーカイブして PostgreSQL データのバックアップを作成

7.4.5.3.1. 継続的なアーカイブの概要

7.4.5.3.2. 継続的なアーカイブの長所と短所

7.4.5.3.3. WAL アーカイブの設定

7.4.5.3.4. ベースバックアップの作成

7.4.5.3.5. 継続的なアーカイブバックアップを使用したデータベースの復元

7.4.5.3.6. 関連情報

7.4.6. RHEL 8 バージョンの PostgreSQL への移行

7.4.6.1. PostgreSQL 15 と PostgreSQL 16 間の主な違い

7.4.6.2. PostgreSQL 13 と PostgreSQL 15 間の主な違い

7.4.6.3. pg_upgrade ユーティリティーを使用した高速アップグレード

7.4.6.4. ダンプおよび復元のアップグレード

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links