6.3. Red Hat Enterprise Linux 8 で PostgreSQL の使用

6.3.1. Red Hat Enterprise Linux 8 の PostgreSQL の概要

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

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

本セクションは、「PostgreSQL のインストール」で、PostgreSQL をインストールする方法を説明します。さらに「PostgreSQL 10.0 への移行」で、Red Hat Enterprise Linux 7 のデフォルトバージョンの PostgreSQL 9.2 から、Red Hat Enterprise Linux 8 のデフォルトバージョンの PostgreSQL 10.0 へ移行する方法を説明します。移行の前提条件に、データバックアップの実行があります。

6.3.2. PostgreSQL のインストール

RHEL 8 では、PostgreSQL サーバーは、2 つのストリームから提供される 10 と 9.6 の 2 つのバージョンで利用できます。本セクションでは、デフォルトストリームの PostgreSQL 10 を使用することを前提としています。ストリームの変更は、『ユーザー領域コンポーネントのインストール、管理、および削除』を参照してください。

注記

設計上、同じモジュールの複数のバージョン (ストリーム) を並行してインストールすることはできません。たとえば、postgresql モジュールから利用可能なストリーム (10 (デフォルト) または 9.6) から 1 つ選択する必要があります。Red Hat Enterprise Linux 6 および Red Hat Enterprise Linux 7 用の Red Hat Software Collections では、コンポーネントの同時インストールが可能です。Red Hat Enterprise Linux 8 では、コンテナーで異なるバージョンのデータベースサーバーを使用できます。

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

  1. Application Stream リポジトリーで利用可能な postgresql-server パッケージが、必要なサーバーにインストールされていることを確認します。

    # yum install postgresql-server
  2. データディレクトリーを初期化します。

    postgresql-setup --initdb
  3. postgresql サービスを開始します。

    # systemctl start postgresql.service
  4. postgresql サービスが、システムの起動時に起動するようにします。

    # systemctl enable postgresql.service

6.3.3. PostgreSQL の設定

PostgreSQL 設定を変更するには、/var/lib/pgsql/data/postgresql.conf ファイルを使用します。その後、postgresql サービスを再起動して、変更を有効にします。

systemctl restart postgresql.service

/var/lib/pgsql/data/postgresql.conf とは別に、PostgreSQL 設定を変更する他のファイルが存在します。

  • postgresql.auto.conf
  • pg_ident.conf
  • pg_hba.conf

postgresql.auto.conf ファイルは、/var/lib/pgsql/data/postgresql.conf と同様の基本的な PostgreSQL 設定を保持します。ただし、このファイルはサーバーの制御下にあります。これは、ALTER SYSTEM クエリーにより編集され、手動で編集することはできません。

pg_ident.conf ファイルは、外部の認証メカニズムから postgresql ユーザー ID へのユーザー ID のマッピングに使用されます。

pg_hba.conf ファイルは、PostgreSQL データベースに対する詳細なユーザー権限を設定するのに使用されます。

6.3.3.1. データベースクラスターの初期化

PostgreSQL データベースでは、すべてのデータはデータベースクラスターと呼ばれる 1 つのディレクトリーに保存されます。データの保存場所は選択できますが、Red Hat では、デフォルトの /var/lib/pgsql/data ディレクトリーにデータを保存することを推奨します。

このデータディレクトリーを初期化するには、次のコマンドを実行します。

postgresql-setup --initdb

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

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

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

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

6.3.4.1.1. SQL ダンプの実行

SQL ダンプの方法は、SQL コマンドを使用したファイルの生成に基づいています。このファイルがデータベースサーバーにアップロードされると、ダンプ時と同じ状態でデータベースが再作成されます。SQL ダンプは、PostgreSQL クライアントアプリケーションである pg_dump ユーティリティーで保証されます。pg_dump コマンドの基本的な使用方法は、コマンドが結果を標準出力に書き込むことです。

pg_dump dbname > dumpfile

作成される SQL ファイルは、テキスト形式またはその他の異なる形式のいずれかになります。これにより並列処理が可能になり、オブジェクトの復元をより詳細に制御できます。

データベースにアクセスできる任意のリモートホストから、SQL ダンプを実行できます。pg_dump ユーティリティーは特殊な権限では機能しませんが、バックアップを作成するすべてのテーブルに対する読み取りアクセスが必要です。データベース全体のバックアップを作成するには、データベースのスーパーユーザーで実行する必要があります。

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

  • ホストを定義する -h オプション。

    デフォルトのホストは、ローカルホストか、PGHOST 環境変数で指定されているものです。

  • ポートを定義する -p オプション。

    デフォルトのポートは、PGPORT 環境変数またはコンパイル済みデフォルトで示されます。

注記

pg_dump は、1 つのデータベースのみをダンプすることに注意してください。その情報はクラスター全体にあるため、ロールやテーブル空間に関する情報はダンプされません。

指定クラスターの各データベースのバックアップを作成し、ロールやテーブル空間の定義など、クラスター全体のデータを保持するには、pg_dumpall コマンドを使用します。

pg_dumpall > dumpfile
6.3.4.1.2. SQL ダンプからのデータベースの復元

SQL ダンプからデータベースを復元するには、次を行います。

  1. 新しいデータベース (dbname) を作成します。

    createdb dbname
  2. ダンプされたデータベースのオブジェクトを所有するか、オブジェクトに対する権限が許可されたユーザーがすべて存在していることを確認してください。

    このようなユーザーが存在しない場合、復元は元の所有権と権限でオブジェクトの再作成に失敗します。

  3. psql ユーティリティーを実行して、pg_dump ユーティリティーが作成したテキストファイルのダンプを復元します。

    psql dbname < dumpfile

ここでの dumpfile は、pg_dump コマンドの出力になります。

非テキストファイルのダンプを復元する場合は、pg_restore ユーティリティーを使用します。

pg_restore non-plain-text-file
6.3.4.1.2.1. 別のサーバーでのデータベースの復元

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

データベースを、サーバーから別のサーバーにダンプするには、以下のコマンドを実行します。

pg_dump -h host1 dbname | psql -h host2 dbname
6.3.4.1.2.2. 復元中の SQL エラーの処理

デフォルトでは、SQL エラーが発生すると、psql の実行が継続します。その結果、データベースは部分的にのみ復元されます。

このデフォルトの動作を変更する場合は、以下のいずれかの方法を使用します。

  • ON_ERROR_STOP 変数を設定して SQL エラーが発生した場合は、終了ステータスが 3 で psql を終了します。

    psql --set ON_ERROR_STOP=on dbname < dumpfile
  • 以下のいずれかのオプションで psql を使用して、復元が完全に完了またはキャンセルされるようにダンプ全体を 1 つのトランザクションとして復元することを指定します。

    psql -1

    または

    psql --single-transaction

    この方法を使用する場合は、多少のエラーでも、すでに何時間も実行している復元操作をキャンセルできます。

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

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

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

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

6.3.4.1.4. 関連情報

SQL ダンプの詳細は、PostgreSQL 10 ドキュメンテーション を参照してください。

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

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

ファイルシステムレベルのバックアップを作成するには、PostgreSQL がデータベースのデータを保存するために使用するファイルを別の場所にコピーする必要があります。

  1. データベースクラスターの場所を選択し、「データベースクラスターの初期化」の説明に従ってこのクラスターを初期化します。
  2. postgresql サービスを停止します。

    # systemctl stop postgresql.service
  3. ファイルシステムをバックアップする場合は、以下のような方法を使用します。

    tar -cf backup.tar /var/lib/pgsql/data
  4. postgresql サービスを起動します。

    # systemctl start postgresql.service
6.3.4.2.2. ファイルシステムレベルのバックアップの長所と短所

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

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

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

  • バックアップはアーキテクチャー固有で、Red Hat Enterprise Linux 7 固有のものです。アップグレードが正常に完了しなかった場合は、Red Hat Enterprise Linux 7 に戻るためのバックアップとしてのみ使用できますが、PostgreSQL 10.0 では使用できません。
  • データバックアップまたはデータ復元を行う前に、データベースサーバーをシャットダウンする必要があります。
  • 特定の個別ファイルまたはテーブルのバックアップと復元はできません。ファイルシステムのバックアップは、データベースクラスター全体の完全バックアップと復元でのみ機能します。
6.3.4.2.3. ファイルシステムレベルのバックアップの代替アプローチ

ファイルシステムのバックアップの代替方法は、以下のとおりです。

  • データディレクトリーの一貫したスナップショット
  • rsync ユーティリティー
6.3.4.2.4. 関連情報

ファイルシステムレベルのバックアップの詳細は、PostgreSQL 10 ドキュメント を参照してください。

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

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

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

オンラインバックアップ とも呼ばれる継続的なアーカイブ方法は、WAL ファイルとファイルシステムレベルのバックアップを組み合わせたものです。データベース復元が必要な場合は、ファイルシステムのバックアップからデータベースを復元してから、バックアップを作成した WAL ファイルからログを再生して、システムを現在の状態にすることができます。

このバックアップ方法には、少なくともバックアップの開始時刻まで戻る、アーカイブされた WAL ファイルの連続シーケンスが必要です。

継続的なアーカイブバックアップ方式の使用を開始する場合は、最初のベースバックアップを行う前に、WAL ファイルのアーカイブ手順を設定してテストしてください。

注記

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

6.3.4.3.2. 継続的なアーカイブのバックアップの実行

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

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

ベースバックアップを実行するには、pg_basebackup ツールを使用します。このツールは、個別のファイルまたは tar アーカイブの形式でベースバックアップを作成できます。

ベースバックアップを使用するには、ファイルシステムのバックアップ中およびバックアップ後に生成されたすべての WAL セグメントファイルを維持する必要があります。ベースバックアッププロセスでは、WAL アーカイブ領域に保存され、ファイルシステムのバックアップに必要な最初の WAL セグメントファイルの後に名前が付けられるバックアップ履歴ファイルが作成されます。バックアップ中に使用するファイルシステムのバックアップおよび WAL セグメントファイルをバックアップ履歴ファイルで安全にアーカイブすると、ファイルシステムバックアップの復元が必要なくなるため、アーカイブされたすべての WAL セグメントを、数値的に小さい名前で削除できます。ただし、データの復元が可能であることを確実にするため、複数のバックアップセットを維持することを検討してください。

バックアップ履歴ファイルは小さなテキストファイルで、pg_basebackup に付与したラベル文字列、開始時間および終了時間、およびバックアップの WAL セグメントが含まれます。ラベル文字列を使用して関連するダンプファイルを特定した場合に、どのダンプファイルを復元するかを確認するには、アーカイブされた履歴ファイルで十分となります。

継続的にアーカイブする方法では、アーカイブされた WAL ファイルをすべて、最後のベースバックアップに戻す必要があります。したがって、ベースバックアップの理想的な頻度は、以下に依存します。

  • アーカイブされた WAL ファイルで利用可能なストレージボリューム。
  • 復元が必要な場合の、データ復元の最大許容期間。

    最後のバックアップ以降の長い期間では、より多くの WAL セグメントが再生されるため、復元には時間がかかります。

ベースバックアップの作成の詳細は、PostgreSQL 10 ドキュメンテーション を参照してください。

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

継続的にバックアップを作成してデータベースを復元するには、以下を行います。

  1. サーバーを停止します。

    # systemctl stop postgresql.service
  2. 必要なデータを一時的な場所にコピーします。

    必要に応じて、クラスターデータのディレクトリー全体と、すべてのテーブル空間をコピーします。既存データベースのコピーを 2 つ保持するには、システムに十分な空き領域が必要になることに注意してください。

    十分な容量がない場合は、クラスターの pg_wal ディレクトリーの内容を保存します。これには、システムがダウンする前にアーカイブされなかったログが含まれます。

  3. クラスターデータディレクトリー、および使用しているテーブル空間のルートディレクトリー下の既存ファイルおよびサブディレクトリーをすべて削除します。
  4. ファイルシステムのバックアップからデータベースファイルを復元します。

    以下の点を確認してください。

    • ファイルは、正しい所有権 (root ではなくデータベースシステムのユーザー) で復元されます。
    • ファイルは、正しい権限で復元されます。
    • pg_tblspc/ サブディレクトリーのシンボリックリンクが正しく復元されます。
  5. pg_wal/ サブディレクトリーにあるファイルをすべて削除します。

    このファイルは、ファイルシステムのバックアップから作成されるため、非推奨になりました。pg_wal/ をアーカイブしていない場合は、適切な権限で再作成します。

  6. 手順 2 で保存した未アーカイブの WAL セグメントファイルがある場合は、pg_wal/ にコピーします。
  7. クラスターデータディレクトリーに、recovery.conf 復元コマンドファイルを作成します。
  8. サーバーを起動します。

    # systemctl start postgresql.service

    サーバーは復元モードに入り、引き続き必要なアーカイブファイル (WAL) を読み込みます。

    外部エラーにより復元が終了した場合は、サーバーを再起動するだけで復元が続行します。復元プロセスが完了すると、サーバーは recovery.conf の名前を recovery.done に変更し、サーバーが通常のデータベース操作を開始する際に、誤って復元モードに再度入らないようにします。

  9. データベースのコンテンツを確認して、データベースが必要な状態に復元されたことを確認します。

    データベースが必要な状態に復元されていない場合は、手順 1 に戻ります。データベースが必要な状態に復元された場合は、pg_hba.conf ファイルを通常に復元して接続できるようにします。

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

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

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

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

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

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

継続的なアーカイブ方法の詳細は、PostgreSQL 10 ドキュメンテーション を参照してください。

6.3.5. PostgreSQL 10.0 への移行

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

本セクションでは、Red Hat Enterprise Linux 7 システムバージョンの Postgreql 9.2 から、デフォルトのストリームで提供される Red Hat Enterprise Linux 8 バージョンの PostgreSQL 10 に移行することを前提としています。

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

ダンプおよび復元のプロセスよりも高速なアップグレード方法を使用してください。

拡張機能の plpython または plpython2 を使用した ba * Cross-architecture upgrades * システム

+ Red Hat Enterprise Linux 8 のアプリケーションストリームリポジトリーには postgresql-plpython3 パッケージのみが含まれ、postgresql-plpython2 パッケージは含まれません。

  • 高速アップグレードは、PostgreSQLの Red Hat Software Collections バージョンからの移行ではサポートされません。

PostgreSQL 9.2 から PostgreSQL 10.0 への移行の前提条件として、PostgreSQL データベースのバックアップを作成します。

データベースをダンプし、SQL ファイルのバックアップを実行することは、ダンプおよび復元プロセスに必要な部分です。ただし、高速アップグレードも実行する場合は、これを実行することが推奨されます。

6.3.5.1. pg_upgrade ツールを使用した高速アップグレード

高速アップグレードでは、バイナリーデータファイルを /var/lib/pgsql/data/ ディレクトリーにコピーし、pg_upgrade ツールを使用する必要があります。この方法は、Red Hat Enterprise Linux 7 バージョンの PostgreSQL 9.2 からデータを移行するのに使用できます。デフォルトでは、すべてのデータが、Red Hat Enterprise Linux 7 および Red Hat Enterprise Linux 8 の両方の /var/lib/pgsql/data/ ディレクトリーに保存されます。Red Hat Software Collections バージョンの PostgreSQL からの移行には、「ダンプおよび復元のアップグレード」を使用します。

重要

アップグレードを実行する前に、PostgreSQL データベースに保存されているすべてのデータのバックアップを作成します。

高速アップグレードを実行するには、以下の手順を使用します。

  1. RHEL 8 システムで、postgresql-server パッケージおよび postgresql-upgrade パッケージをインストールします。

    # yum install postgresql-server postgresql-upgrade

    必要に応じて、RHEL 7 で PostgreSQL サーバーモジュールを使用している場合は、その 2 つのバージョンを RHEL 8 システムにインストールし、PostgreSQL 9.2 (postgresql-upgrade パッケージでインストール) および PostgreSQL 10 (postgresql-server パッケージでインストール) の両方に対してコンパイルします。サードパーティーの PostgreSQL サーバーモジュールをコンパイルする必要がある場合は、postgresql-devel パッケージと postgresql-upgrade-devel パッケージの両方に対してビルドしてください。

  2. 以下の項目を確認します。

    • 基本設定 - 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/ ディレクトリー) にインストールされます。
  3. データのコピー時に、postgresql サービスがソースおよびターゲットのシステムで稼働していないことを確認します。

    # systemctl stop postgresql.service
  4. データベースファイルをソースの場所から RHEL 8 システムの /var/lib/pgsql/data/ ディレクトリーにコピーします。
  5. PostgreSQL ユーザーで以下のコマンドを実行して、アップグレードプロセスを実行します。

    $ /bin/postgresql-setup --upgrade

    これでバックグラウンドで pg_upgrade プロセスが開始します。

    障害が発生すると、postgresql-setup は通知のエラーメッセージを提供します。

  6. /var/lib/pgsql/data-old から新規クラスターに、以前の設定をコピーします。

    高速アップグレードは、新しいデータスタックで以前の設定を再利用せず、設定がゼロから生成されることに注意してください。古い設定と新しい設定を手動で組み合わせたい場合は、データディレクトリーの *.conf ファイルを使用します。

  7. 新しい PostgreSQL 10 サーバーを起動します。

    # systemctl start postgresql.service
  8. PostgreSQL ホームディレクトリーにある analyze_new_cluster.sh スクリプトを実行します。

    su postgres -c '~/analyze_new_cluster.sh'
  9. システムの起動時に PostgreSQL 10 サーバーを自動的に起動させる場合は、以下を実行します。

    # systemctl enable postgresql.service

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

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

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

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

  • Red Hat Enterprise Linux7 バージョンの PostgreSQL 9.2
  • Red Hat Software Collections のバージョンは、以下の通りです。

    • PostgreSQL 9.2 (サポート対象外になりました)
    • PostgreSQL 9.4 (サポート対象外になりました)
    • PostgreSQL 9.6
    • PostgreSQL 10

Red Hat Enterprise Linux 7 および Red Hat Enterprise Linux 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に変更し、以下の手順に従って、Red Hat Enterprise Linux 7 のベースシステムの PostgreSQL 9.2 バージョンから、Red Hat Enterprise Linux 8 のデフォルトバージョンの PostgreSQL 10 への移行を行います。

  1. RHEL 7 システムで PostgreSQL 9.2 サーバーを起動します。

    # systemctl start postgresql.service
  2. RHEL 7 システムで、すべてのデータベースのコンテンツを pgdump_file.sql ファイルにダンプします。

    su - postgres -c "pg_dumpall > ~/pgdump_file.sql"
  3. データベースが正しくダンプされたことを確認します。

    su - postgres -c 'less "$HOME/pgdump_file.sql"'

    これにより、ダンプされた sql ファイルのパスが /var/lib/pgsql/pgdump_file.sql に表示されます。

  4. RHEL 8 システムで、postgresql-server パッケージをインストールします。

    # yum install postgresql-server

    必要に応じて、RHEL 7 で PostgreSQL サーバーモジュールを使用している場合は、RHEL 8 システムにもインストールしてください。サードパーティーの PostgreSQL サーバーモジュールをコンパイルする必要がある場合は、postgresql-devel パッケージに対してビルドします。

  5. RHEL 8 システムで、PostgreSQL 10.0 サーバーのデータディレクトリーを初期化します。

    # postgresql-setup --initdb
  6. RHEL 8 システムで、pgdump_file.sqlPostgreSQL ホームディレクトリーにコピーし、ファイルが正しくコピーされたことを確認します。

    su - postgres -c 'test -e "$HOME/pgdump_file.sql" && echo exists'
  7. 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
  8. RHEL 8 システムで、新規の PostgreSQL 10 サーバーを起動します。

    # systemctl start postgresql.service
  9. 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"'