7.4. PostgreSQL の使用

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 8.10 以降で利用可能

注記

設計上、同じモジュールの複数のバージョン (ストリーム) を並行してインストールすることはできません。したがって、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 8 内の以前の postgresql ストリームからアップグレードする場合は、新しいストリームへの切り替えおよび RHEL 8 バージョンの PostgreSQL への移行の両方の手順に従ってください。

7.4.2. コンテナー内で複数の 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.3. 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.4. PostgreSQL の設定
リンクのコピー

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

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

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

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

手順

/var/lib/pgsql/data/postgresql.conf ファイルを編集し、データベースクラスターパラメーターの基本設定を行います。次に例を示します。
```
log_connections = yes
log_destination = 'syslog'
search_path = '"$user", public'
shared_buffers = 128MB
password_encryption = scram-sha-256
```

/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

postgresql サービスを再起動して、変更を有効にします。
```
# systemctl restart postgresql.service
```

7.4.5. 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 をデータベース名に、mydbuser をユーザー名に置き換えます。
注記
-lpq オプションを使用して、コンパイルのために pq ライブラリーをロードする必要があります。たとえば、GCC コンパイラーを使用してアプリケーションをコンパイルするには、次のようにします。
$ gcc source_file.c -lpq -o myapplication
この source_file.c には上記のサンプルコードが含まれており、myapplication はセキュアな PostgreSQL 接続を検証するためのアプリケーションの名前です。

例7.2 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.6. PostgreSQL データのバックアップ
リンクのコピー

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

SQL ダンプ
ファイルシステムレベルのバックアップ
継続的アーカイブ

7.4.6.1. SQL ダンプを使用した PostgreSQL データのバックアップ
リンクのコピー

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

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

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

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

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

7.4.6.1.1. SQL ダンプの長所と短所
リンクのコピー

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

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

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

7.4.6.1.2. pg_dump を使用した SQL ダンプの実行
リンクのコピー

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

前提条件

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

手順

クラスター全体の情報なしでデータベースをダンプします。
```
$ pg_dump dbname > dumpfile
```
pg_dump が接続するデータベースサーバーを指定するには、次のコマンドラインオプションを使用します。
- ホストを定義する -h オプション
  デフォルトのホストは、ローカルホストか、PGHOST 環境変数で指定されているものです。
- ポートを定義する -p オプション
  デフォルトのポートは、PGPORT 環境変数またはコンパイル済みデフォルトで示されます。

7.4.6.1.3. pg_dumpall を使用して SQL ダンプを実行する
リンクのコピー

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

前提条件

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

手順

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

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

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

7.4.6.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.6.1.5. pg_dumpall を使用してダンプされたデータベースを復元する
リンクのコピー

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

前提条件

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

手順

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

7.4.6.1.6. 別のサーバーでのデータベースの SQL ダンプの実行
リンクのコピー

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

手順

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

7.4.6.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.6.2. ファイルシステムレベルのバックアップを使用した PostgreSQL データのバックアップ
リンクのコピー

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

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

7.4.6.2.1. ファイルシステムのバックアップを作成する利点と制限
リンクのコピー

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

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

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

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

7.4.6.2.2. ファイルシステムレベルのバックアップの実行
リンクのコピー

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

手順

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

7.4.6.3. 継続的にアーカイブして PostgreSQL データのバックアップを作成
リンクのコピー

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

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

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

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

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

注記

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

7.4.6.3.1. 継続的なアーカイブの長所と短所
リンクのコピー

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

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

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

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

7.4.6.3.2. 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 コマンド、別のコマンド、またはシェルスクリプトを使用できます。
  以下に例を示します。
  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
  アーカイブされる新規ファイルごとに同様のコマンドが生成されます。
  注記
  archive コマンドは、完了した WAL セグメントでのみ実行されます。WAL トラフィックをほとんど生成しないサーバーでは、トランザクションの完了とアーカイブストレージへの安全な記録の間にかなりの遅延が生じる可能性があります。アーカイブされていないデータの古さを制限するには、以下を行います。
  archive_timeout パラメーターを設定して、サーバーが特定の頻度で新しい WAL セグメントファイルに切り替えるように強制します。
  pg_switch_wal パラメーターを使用して、セグメント切り替えを強制し、トランザクションが終了後すぐにアーカイブされるようにします。
postgresql サービスを再起動して、変更を適用します。
```
# systemctl restart postgresql.service
```
アーカイブコマンドをテストし、既存のファイルが上書きされないこと、失敗した場合にゼロ以外の終了ステータスが返されることを確認します。
データを保護するには、セグメントファイルがグループまたはワールド読み取りアクセスを持たないディレクトリーにアーカイブされていることを確認してください。

7.4.6.3.3. ベースバックアップの作成
リンクのコピー

ベースバックアップは、複数の方法で作成できます。ベースバックアップを実行する最も簡単な方法は、実行中の 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 は、任意のバックアップの場所に置き換えます。
  このようなデータを復元するには、ファイルを正しい場所に手動で抽出する必要があります。
pg_basebackup が接続するデータベースサーバーを指定するには、以下のコマンドラインオプションを使用します。
- ホストを定義する -h オプション
  デフォルトのホストは、ローカルホストまたは PGHOST 環境変数により指定されたホストです。
- ポートを定義する -p オプション
  デフォルトのポートは、PGPORT 環境変数またはコンパイル済みデフォルトで示されます。
ベースバックアッププロセスが完了すると、バックアップ履歴ファイルで指定されている、データベースクラスターのコピーとバックアップ中に使用された WAL セグメントファイルを安全にアーカイブします。
ベースバックアップで使用されている WAL セグメントファイルよりも数値が小さい WAL セグメントを削除します。これらはベースバックアップよりも古く、復元には必要ないためです。

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

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

手順

サーバーを停止します。
```
# 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 ファイルでクライアント認証設定を復元して接続できるようにします。

7.4.7. RHEL 8 バージョンの PostgreSQL への移行
リンクのコピー

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

Red Hat Enterprise Linux 8 では、デフォルトの postgresql ストリームとして PostgreSQL 10、PostgreSQL 9.6、PostgreSQL 12、PostgreSQL 13、PostgreSQL 15、PostgreSQL 16 が提供されます。

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.7.1. PostgreSQL 15 と PostgreSQL 16 間の主な違い
リンクのコピー

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

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

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

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

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

7.4.7.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.7.3. pg_upgrade ユーティリティーを使用した高速アップグレード
リンクのコピー

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

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

RHEL 7 システムバージョンの PostgreSQL 9.2 から、RHEL 8 バージョンの PostgreSQL 10 へ
RHEL 8 バージョンの PostgreSQL 10 から RHEL バージョンの PostgreSQL 12 へ
RHEL 8 バージョンの PostgreSQL 12 から RHEL バージョンの PostgreSQL 13 へ
RHEL 版 PostgreSQL 13 から RHEL 版 PostgreSQL 15 へ
RHEL 版 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.7.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.8. RHEL システムロールを使用した PostgreSQL データベースサーバーのインストールおよび設定
リンクのコピー

postgresql RHEL システムロールを使用すると、PostgreSQL データベースサーバーのインストールと管理を自動化できます。デフォルトでは、このロールは、PostgreSQL サービス設定ファイルでパフォーマンス関連の設定を自動的に指定することで、PostgreSQL を最適化します。

7.4.8.1. postgresql RHEL システムロールを使用した、既存の TLS 証明書による PostgreSQL の設定
リンクのコピー

アプリケーションに PostgreSQL データベースサーバーが必要な場合は、TLS 暗号化を使用して PostgreSQL サービスを設定し、アプリケーションとデータベース間のセキュアな通信を有効にできます。postgresql RHEL システムロールを使用すると、このプロセスを自動化し、TLS 暗号化を使用して PostgreSQL をリモートでインストールおよび設定できます。Playbook で、既存の秘密鍵と、認証局 (CA) によって発行された TLS 証明書を使用できます。

注記

postgresql ロールは、firewalld サービスでポートを開くことができません。PostgreSQL サーバーへのリモートアクセスを許可するには、firewall RHEL システムロールを使用するタスクを Playbook に追加します。

前提条件

コントロールノードと管理対象ノードの準備が完了している。
管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
管理対象ノードへの接続に使用するアカウントに、そのノードに対する sudo 権限がある。
管理対象ノードの秘密鍵と証明書が、コントロールノードの次のファイルに保存されている。
- 秘密鍵: ~/<FQDN_of_the_managed_node>.key
- 証明書: ~/<FQDN_of_the_managed_node>.crt

手順

機密性の高い変数を暗号化されたファイルに保存します。
1. vault を作成します。
  $ ansible-vault create ~/vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>
2. ansible-vault create コマンドでエディターが開いたら、機密データを <key>: <value> 形式で入力します。
  pwd: <password>
3. 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。
次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。
```
---
- name: Installing and configuring PostgreSQL
  hosts: managed-node-01.example.com
  vars_files:
    - ~/vault.yml
  tasks:
    - name: Create directory for TLS certificate and key
      ansible.builtin.file:
        path: /etc/postgresql/
        state: directory
        mode: 755

    - name: Copy CA certificate
      ansible.builtin.copy:
        src: "~/{{ inventory_hostname }}.crt"
        dest: "/etc/postgresql/server.crt"

    - name: Copy private key
      ansible.builtin.copy:
        src: "~/{{ inventory_hostname }}.key"
        dest: "/etc/postgresql/server.key"
        mode: 0600

    - name: PostgreSQL with an existing private key and certificate
      ansible.builtin.include_role:
        name: redhat.rhel_system_roles.postgresql
      vars:
        postgresql_version: "16"
        postgresql_password: "{{ pwd }}"
        postgresql_ssl_enable: true
        postgresql_cert_name: "/etc/postgresql/server"
        postgresql_server_conf:
          listen_addresses: "'*'"
          password_encryption: scram-sha-256
        postgresql_pg_hba_conf:
          - type: local
            database: all
            user: all
            auth_method: scram-sha-256
          - type: hostssl
            database: all
            user: all
            address: '127.0.0.1/32'
            auth_method: scram-sha-256
          - type: hostssl
            database: all
            user: all
            address: '::1/128'
            auth_method: scram-sha-256
          - type: hostssl
            database: all
            user: all
            address: '192.0.2.0/24'
            auth_method: scram-sha-256


    - name: Open the PostgresQL port in firewalld
      ansible.builtin.include_role:
        name: redhat.rhel_system_roles.firewall
      vars:
        firewall:
          - service: postgresql
            state: enabled
```
サンプル Playbook で指定されている設定は次のとおりです。
postgresql_version: <version>
インストールする PostgreSQL のバージョンを設定します。設定できるバージョンは、管理対象ノードで実行されている Red Hat Enterprise Linux で使用可能な PostgreSQL バージョンによって異なります。
postgresql_version 変数を変更して Playbook を再度実行しても、PostgreSQL をアップグレードまたはダウングレードすることはできません。
postgresql_password: <password>
postgres データベーススーパーユーザーのパスワードを設定します。
postgresql_password 変数を変更して Playbook を再度実行しても、パスワードを変更することはできません。
postgresql_cert_name: <private_key_and_certificate_file>
管理対象ノード上の証明書と秘密鍵の両方のパスとベース名を、.crt および key 接尾辞なしで定義します。PostgreSQL の設定中に、ロールが /var/lib/pgsql/data/ ディレクトリーにこれらのファイルを参照するシンボリックリンクを作成します。
証明書と秘密鍵は管理対象ノード上にローカルに存在している必要があります。Playbook に示されているように、ansible.builtin.copy モジュールのタスクを使用して、コントロールノードから管理対象ノードにファイルを転送できます。
postgresql_server_conf: <list_of_settings>
ロールが設定する必要がある postgresql.conf 設定を定義します。ロールはこれらの設定を /etc/postgresql/system-roles.conf ファイルに追加し、このファイルを /var/lib/pgsql/data/postgresql.conf の最後に含めます。その結果、postgresql_server_conf 変数の設定により、/var/lib/pgsql/data/postgresql.conf 内の設定がオーバーライドされます。
postgresql_server_conf で異なる設定を使用して Playbook を再実行すると、/etc/postgresql/system-roles.conf ファイルが新しい設定で上書きされます。
postgresql_pg_hba_conf: <list_of_authentication_entries>
/var/lib/pgsql/data/pg_hba.conf ファイル内のクライアント認証エントリーを設定します。詳細は、PostgreSQL のドキュメントを参照してください。
この例では、PostgreSQL への次の接続を許可します。
ローカル UNIX ドメインソケットを使用した暗号化されていない接続。
IPv4 および IPv6 ローカルホストアドレスへの TLS 暗号化接続。
192.0.2.0/24 サブネットからの TLS 暗号化接続。リモートアドレスからのアクセスは、postgresql_server_conf 変数の listen_addresses 設定も適切に設定した場合にのみ可能であることに注意してください。
postgresql_pg_hba_conf で異なる設定を使用して Playbook を再実行すると、/var/lib/pgsql/data/pg_hba.conf ファイルが新しい設定で上書きされます。
Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.postgresql/README.md ファイルを参照してください。
Playbook の構文を検証します。
```
$ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml
```
このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

Playbook を実行します。

$ ansible-playbook --ask-vault-pass ~/playbook.yml

検証

postgres スーパーユーザーを使用して PostgreSQL サーバーに接続し、\conninfo メタコマンドを実行します。
```
# psql "postgresql://postgres@managed-node-01.example.com:5432" -c '\conninfo'
Password for user postgres:
You are connected to database "postgres" as user "postgres" on host "192.0.2.1" at port "5432".
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
```
出力に TLS プロトコルのバージョンと暗号の詳細が表示される場合、接続は機能し、TLS 暗号化が有効になっています。

7.4.8.2. postgresql RHEL システムロールを使用した、IdM から発行された TLS 証明書による PostgreSQL の設定
リンクのコピー

アプリケーションに PostgreSQL データベースサーバーが必要な場合は、TLS 暗号化を使用して PostgreSQL サービスを設定し、アプリケーションとデータベース間のセキュアな通信を有効にできます。PostgreSQL ホストが Red Hat Enterprise Linux Identity Management (IdM) ドメインのメンバーである場合、certmonger サービスによって証明書要求と将来の更新を管理できます。

postgresql RHEL システムロールを使用すると、このプロセスを自動化できます。TLS 暗号化を使用して PostgreSQL をリモートでインストールおよび設定できます。postgresql ロールは、certificate RHEL システムロールを使用して certmonger を設定し、IdM から証明書を要求します。

注記

前提条件

コントロールノードと管理対象ノードの準備が完了している。
管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
管理対象ノードへの接続に使用するアカウントに、そのノードに対する sudo 権限がある。
管理対象ノードを IdM ドメインに登録した。

手順

機密性の高い変数を暗号化されたファイルに保存します。
1. vault を作成します。
  $ ansible-vault create ~/vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>
2. ansible-vault create コマンドでエディターが開いたら、機密データを <key>: <value> 形式で入力します。
  pwd: <password>
3. 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。
次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。
```
---
- name: Installing and configuring PostgreSQL
  hosts: managed-node-01.example.com
  vars_files:
    - ~/vault.yml
  tasks:
    - name: PostgreSQL with certificates issued by IdM
      ansible.builtin.include_role:
        name: redhat.rhel_system_roles.postgresql
      vars:
        postgresql_version: "16"
        postgresql_password: "{{ pwd }}"
        postgresql_ssl_enable: true
        postgresql_certificates:
          - name: postgresql_cert
            dns: "{{ inventory_hostname }}"
            ca: ipa
            principal: "postgresql/{{ inventory_hostname }}@EXAMPLE.COM"
        postgresql_server_conf:
          listen_addresses: "'*'"
          password_encryption: scram-sha-256
        postgresql_pg_hba_conf:
          - type: local
            database: all
            user: all
            auth_method: scram-sha-256
          - type: hostssl
            database: all
            user: all
            address: '127.0.0.1/32'
            auth_method: scram-sha-256
          - type: hostssl
            database: all
            user: all
            address: '::1/128'
            auth_method: scram-sha-256
          - type: hostssl
            database: all
            user: all
            address: '192.0.2.0/24'
            auth_method: scram-sha-256


    - name: Open the PostgresQL port in firewalld
      ansible.builtin.include_role:
        name: redhat.rhel_system_roles.firewall
      vars:
        firewall:
          - service: postgresql
            state: enabled
```
サンプル Playbook で指定されている設定は次のとおりです。
postgresql_version: <version>
インストールする PostgreSQL のバージョンを設定します。設定できるバージョンは、管理対象ノードで実行されている Red Hat Enterprise Linux で使用可能な PostgreSQL バージョンによって異なります。
postgresql_version 変数を変更して Playbook を再度実行しても、PostgreSQL をアップグレードまたはダウングレードすることはできません。
postgresql_password: <password>
postgres データベーススーパーユーザーのパスワードを設定します。
postgresql_password 変数を変更して Playbook を再度実行しても、パスワードを変更することはできません。
postgresql_certificates: <certificate_role_settings>
certificate ロールの設定を含む YAML ディクショナリーのリスト。
postgresql_server_conf: <list_of_settings>
ロールが設定する必要がある postgresql.conf 設定を定義します。ロールはこれらの設定を /etc/postgresql/system-roles.conf ファイルに追加し、このファイルを /var/lib/pgsql/data/postgresql.conf の最後に含めます。その結果、postgresql_server_conf 変数の設定により、/var/lib/pgsql/data/postgresql.conf 内の設定がオーバーライドされます。
postgresql_server_conf で異なる設定を使用して Playbook を再実行すると、/etc/postgresql/system-roles.conf ファイルが新しい設定で上書きされます。
postgresql_pg_hba_conf: <list_of_authentication_entries>
/var/lib/pgsql/data/pg_hba.conf ファイル内のクライアント認証エントリーを設定します。詳細は、PostgreSQL のドキュメントを参照してください。
この例では、PostgreSQL への次の接続を許可します。
ローカル UNIX ドメインソケットを使用した暗号化されていない接続。
IPv4 および IPv6 ローカルホストアドレスへの TLS 暗号化接続。
192.0.2.0/24 サブネットからの TLS 暗号化接続。リモートアドレスからのアクセスは、postgresql_server_conf 変数の listen_addresses 設定も適切に設定した場合にのみ可能であることに注意してください。
postgresql_pg_hba_conf で異なる設定を使用して Playbook を再実行すると、/var/lib/pgsql/data/pg_hba.conf ファイルが新しい設定で上書きされます。
Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.postgresql/README.md ファイルを参照してください。
Playbook の構文を検証します。
```
$ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml
```
このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

Playbook を実行します。

$ ansible-playbook --ask-vault-pass ~/playbook.yml

検証

postgres スーパーユーザーを使用して PostgreSQL サーバーに接続し、\conninfo メタコマンドを実行します。
```
# psql "postgresql://postgres@managed-node-01.example.com:5432" -c '\conninfo'
Password for user postgres:
You are connected to database "postgres" as user "postgres" on host "192.0.2.1" at port "5432".
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
```
出力に TLS プロトコルのバージョンと暗号の詳細が表示される場合、接続は機能し、TLS 暗号化が有効になっています。

7.4. PostgreSQL の使用

7.4.1. PostgreSQL のインストール
リンクのコピー

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

7.4.3. PostgreSQL ユーザーの作成
リンクのコピー

7.4.4. PostgreSQL の設定
リンクのコピー

7.4.5. PostgreSQL サーバーにおける TLS 暗号化の設定
リンクのコピー

7.4.6. PostgreSQL データのバックアップ
リンクのコピー

7.4.6.1. SQL ダンプを使用した PostgreSQL データのバックアップ
リンクのコピー

7.4.6.1.1. SQL ダンプの長所と短所
リンクのコピー

7.4.6.1.2. pg_dump を使用した SQL ダンプの実行
リンクのコピー

7.4.6.1.3. pg_dumpall を使用して SQL ダンプを実行する
リンクのコピー

7.4.6.1.4. pg_dump を使用してダンプされたデータベースを復元する
リンクのコピー

7.4.6.1.5. pg_dumpall を使用してダンプされたデータベースを復元する
リンクのコピー

7.4.6.1.6. 別のサーバーでのデータベースの SQL ダンプの実行
リンクのコピー

7.4.6.1.7. 復元中の SQL エラーの処理
リンクのコピー

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

7.4.6.2.1. ファイルシステムのバックアップを作成する利点と制限
リンクのコピー

7.4.6.2.2. ファイルシステムレベルのバックアップの実行
リンクのコピー

7.4.6.3. 継続的にアーカイブして PostgreSQL データのバックアップを作成
リンクのコピー

7.4.6.3.1. 継続的なアーカイブの長所と短所
リンクのコピー

7.4.6.3.2. WAL アーカイブの設定
リンクのコピー

7.4.6.3.3. ベースバックアップの作成
リンクのコピー

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

7.4.7. RHEL 8 バージョンの PostgreSQL への移行
リンクのコピー

7.4.7.1. PostgreSQL 15 と PostgreSQL 16 間の主な違い
リンクのコピー

7.4.7.2. PostgreSQL 13 と PostgreSQL 15 間の主な違い
リンクのコピー

7.4.7.3. pg_upgrade ユーティリティーを使用した高速アップグレード
リンクのコピー

7.4.7.4. ダンプおよび復元のアップグレード
リンクのコピー

7.4.8. RHEL システムロールを使用した PostgreSQL データベースサーバーのインストールおよび設定
リンクのコピー

7.4.8.1. postgresql RHEL システムロールを使用した、既存の TLS 証明書による PostgreSQL の設定
リンクのコピー

7.4.8.2. postgresql RHEL システムロールを使用した、IdM から発行された TLS 証明書による PostgreSQL の設定
リンクのコピー

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

7.4. PostgreSQL の使用

7.4.1. PostgreSQL のインストールリンクのコピーリンクがクリップボードにコピーされました!

7.4.2. コンテナー内で複数の PostgreSQL バージョンを実行するリンクのコピーリンクがクリップボードにコピーされました!

7.4.3. PostgreSQL ユーザーの作成リンクのコピーリンクがクリップボードにコピーされました!

7.4.4. PostgreSQL の設定リンクのコピーリンクがクリップボードにコピーされました!

7.4.5. PostgreSQL サーバーにおける TLS 暗号化の設定リンクのコピーリンクがクリップボードにコピーされました!

7.4.6. PostgreSQL データのバックアップリンクのコピーリンクがクリップボードにコピーされました!

7.4.6.1. SQL ダンプを使用した PostgreSQL データのバックアップリンクのコピーリンクがクリップボードにコピーされました!

7.4.6.1.1. SQL ダンプの長所と短所リンクのコピーリンクがクリップボードにコピーされました!

7.4.6.1.2. pg_dump を使用した SQL ダンプの実行リンクのコピーリンクがクリップボードにコピーされました!

7.4.6.1.3. pg_dumpall を 使用して SQL ダンプを実行するリンクのコピーリンクがクリップボードにコピーされました!

7.4.6.1.4. pg_dump を 使用してダンプされたデータベースを復元するリンクのコピーリンクがクリップボードにコピーされました!

7.4.6.1.5. pg_dumpall を 使用してダンプされたデータベースを復元するリンクのコピーリンクがクリップボードにコピーされました!

7.4.6.1.6. 別のサーバーでのデータベースの SQL ダンプの実行リンクのコピーリンクがクリップボードにコピーされました!

7.4.6.1.7. 復元中の SQL エラーの処理リンクのコピーリンクがクリップボードにコピーされました!

7.4.6.2. ファイルシステムレベルのバックアップを使用した PostgreSQL データのバックアップリンクのコピーリンクがクリップボードにコピーされました!

7.4.6.2.1. ファイルシステムのバックアップを作成する利点と制限リンクのコピーリンクがクリップボードにコピーされました!

7.4.6.2.2. ファイルシステムレベルのバックアップの実行リンクのコピーリンクがクリップボードにコピーされました!

7.4.6.3. 継続的にアーカイブして PostgreSQL データのバックアップを作成リンクのコピーリンクがクリップボードにコピーされました!

7.4.6.3.1. 継続的なアーカイブの長所と短所リンクのコピーリンクがクリップボードにコピーされました!

7.4.6.3.2. WAL アーカイブの設定リンクのコピーリンクがクリップボードにコピーされました!

7.4.6.3.3. ベースバックアップの作成リンクのコピーリンクがクリップボードにコピーされました!

7.4.6.3.4. 継続的なアーカイブバックアップを使用したデータベースの復元リンクのコピーリンクがクリップボードにコピーされました!

7.4.7. RHEL 8 バージョンの PostgreSQL への移行リンクのコピーリンクがクリップボードにコピーされました!

7.4.7.1. PostgreSQL 15 と PostgreSQL 16 間の主な違いリンクのコピーリンクがクリップボードにコピーされました!

7.4.7.2. PostgreSQL 13 と PostgreSQL 15 間の主な違いリンクのコピーリンクがクリップボードにコピーされました!

7.4.7.3. pg_upgrade ユーティリティーを使用した高速アップグレードリンクのコピーリンクがクリップボードにコピーされました!

7.4.7.4. ダンプおよび復元のアップグレードリンクのコピーリンクがクリップボードにコピーされました!

7.4.8. RHEL システムロールを使用した PostgreSQL データベースサーバーのインストールおよび設定リンクのコピーリンクがクリップボードにコピーされました!

7.4.8.1. postgresql RHEL システムロールを使用した、既存の TLS 証明書による PostgreSQL の設定リンクのコピーリンクがクリップボードにコピーされました!

7.4.8.2. postgresql RHEL システムロールを使用した、IdM から発行された TLS 証明書による PostgreSQL の設定リンクのコピーリンクがクリップボードにコピーされました!

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

7.4.1. PostgreSQL のインストール
リンクのコピー

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

7.4.3. PostgreSQL ユーザーの作成
リンクのコピー

7.4.4. PostgreSQL の設定
リンクのコピー

7.4.5. PostgreSQL サーバーにおける TLS 暗号化の設定
リンクのコピー

7.4.6. PostgreSQL データのバックアップ
リンクのコピー

7.4.6.1. SQL ダンプを使用した PostgreSQL データのバックアップ
リンクのコピー

7.4.6.1.1. SQL ダンプの長所と短所
リンクのコピー

7.4.6.1.2. pg_dump を使用した SQL ダンプの実行
リンクのコピー

7.4.6.1.3. pg_dumpall を使用して SQL ダンプを実行する
リンクのコピー

7.4.6.1.4. pg_dump を使用してダンプされたデータベースを復元する
リンクのコピー

7.4.6.1.5. pg_dumpall を使用してダンプされたデータベースを復元する
リンクのコピー

7.4.6.1.6. 別のサーバーでのデータベースの SQL ダンプの実行
リンクのコピー

7.4.6.1.7. 復元中の SQL エラーの処理
リンクのコピー

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

7.4.6.2.1. ファイルシステムのバックアップを作成する利点と制限
リンクのコピー

7.4.6.2.2. ファイルシステムレベルのバックアップの実行
リンクのコピー

7.4.6.3. 継続的にアーカイブして PostgreSQL データのバックアップを作成
リンクのコピー

7.4.6.3.1. 継続的なアーカイブの長所と短所
リンクのコピー

7.4.6.3.2. WAL アーカイブの設定
リンクのコピー

7.4.6.3.3. ベースバックアップの作成
リンクのコピー

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

7.4.7. RHEL 8 バージョンの PostgreSQL への移行
リンクのコピー

7.4.7.1. PostgreSQL 15 と PostgreSQL 16 間の主な違い
リンクのコピー

7.4.7.2. PostgreSQL 13 と PostgreSQL 15 間の主な違い
リンクのコピー

7.4.7.3. pg_upgrade ユーティリティーを使用した高速アップグレード
リンクのコピー

7.4.7.4. ダンプおよび復元のアップグレード
リンクのコピー

7.4.8. RHEL システムロールを使用した PostgreSQL データベースサーバーのインストールおよび設定
リンクのコピー

7.4.8.1. postgresql RHEL システムロールを使用した、既存の TLS 証明書による PostgreSQL の設定
リンクのコピー

7.4.8.2. postgresql RHEL システムロールを使用した、IdM から発行された TLS 証明書による PostgreSQL の設定
リンクのコピー