第8章 データベースサーバー

8.1. データベースサーバーの概要

データベースサーバーは、一定量のメインメモリーとデータベース (DB) アプリケーションがインストールされているハードウェアデバイスです。このデータベースアプリケーションは、通常、小さくて高価なメインメモリーから DB ファイル (データベース) にキャッシュされたデータを書き込む手段としてサービスを提供します。サービスは、ネットワーク上の複数のクライアントに提供されます。利用できるデータベースサーバーの数は、マシンのメインメモリーおよびストレージにより異なります。

Red Hat Enterprise Linux 8 は、以下のデータベースアプリケーションを提供します。

  • MariaDB 10.3
  • MySQL 8.0
  • PostgreSQL 10
  • PostgreSQL 9.6
  • PostgreSQL 12 - RHEL 8.1.1 以降で利用できます。

8.2. MariaDB の使用

8.2.1. MariaDB の概要

MariaDB サーバーは、MySQL テクノロジーをベースとしたオープンソースの高速で強力なデータベースサーバーです。

MariaDB は、データを構造化情報に変換して、データにアクセスする SQL インターフェースを提供するリレーショナルデータベースです。これには、複数のストレージエンジンとプラグイン、および地理的な情報システム (GIS) および JSON (JavaScript Object Notation) 機能が含まれます。

本セクションでは、「MariaDB のインストール」で、MariaDB サーバーをインストールする方法を説明します。また、「MariaDB 10.3 への移行」では、Red Hat Enterprise Linux 7 のデフォルトバージョンの MariaDB 5.5 から Red Hat Enterprise Linux 8 のデフォルトバージョンの MariaDB 10.3 に移行する方法と、MariaDB データのバックアップを作成する方法を説明します。データバックアップの実行は、MariaDB 移行の前提条件です。

8.2.2. MariaDB のインストール

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

  1. 特定のストリームを使用して mariadb モジュールをインストールして、そのシステムで MariaDB サーバーに必要なパッケージをすべて利用できる状態にします。

    # yum module install mariadb:10.3/server
  2. mariadb サービスを起動します。

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

    # systemctl enable mariadb.service
注記

RPM パッケージの競合により、データベースサーバー MariaDB および MySQL を Red Hat Enterprise Linux 8.0 で並行してインストールできないことに注意してください。Red Hat Enterprise Linux 6 および Red Hat Enterprise Linux 7 用の Red Hat Software Collections では、コンポーネントの同時インストールが可能です。Red Hat Enterprise Linux 8 では、コンテナーで異なるバージョンのデータベースサーバーを使用できます。

8.2.2.1. MariaDB インストールセキュリティーの改善

MariaDB のインストール時にセキュリティーを強化する場合は、次のコマンドを実行します。

このコマンドは、完全にインタラクティブなスクリプトを起動して、プロセスの各ステップのプロンプトを表示します。

# mysql_secure_installation

このスクリプトを使用すると、次の方法でセキュリティーを改善できます。

  • root アカウントのパスワードの設定
  • 匿名ユーザーの削除
  • リモート (ローカルホスト外) の root ログインの拒否

8.2.3. MariaDB の設定

8.2.3.1. MariaDB サーバーのネットワーク設定

MariaDB サーバーをネットワーク用に設定するには、/etc/my.cnf.d/mariadb-server.cnf ファイルの [mysqld] セクションを使用します。ここには、以下の設定ディレクティブを設定できます。

  • bind-address

    bind-address は、サーバーがリッスンするアドレスです。

    可能なオプションは、ホスト名、IPv4 アドレス、または IPv6 アドレスです。

  • skip-networking

    以下の値が使用できます。

    0 - すべてのクライアントをリッスンする

    1 - ローカルクライアントのみをリッスンする

  • port

    MariaDB が TCP/IP 接続をリッスンするポート

8.2.4. MariaDB データのバックアップ

MariaDB データベースからデータのバックアップを取得するには、以下の 2 つの方法があります。

  • 論理バックアップ
  • 物理バックアップ

論理バックアップ は、データの復元に必要な SQL ステートメントで構成されます。この種類のバックアップは、情報およびレコードをプレーンテキストファイルにエクスポートします。

物理バックアップに対する論理バックアップの主な利点は、移植性と柔軟性です。データは、物理バックアップではできない他のハードウェア構成である MariaDB バージョンまたはデータベース管理システム (DBMS) で復元できます。

mariadb.service が稼働している場合は、論理バックアップを実行できることに注意してください。論理バックアップには、ログと設定ファイルが含まれません。

物理バックアップ は、コンテンツを格納するファイルおよびディレクトリーのコピーで構成されます。

物理バックアップは、論理バックアップと比較して、以下の利点があります。

  • 出力が少なくなる。
  • バックアップのサイズが小さくなる。
  • バックアップおよび復元が速くなる。
  • バックアップには、ログファイルと設定ファイルが含まれる。

mariadb.service が実行していない場合や、データベースのすべてのテーブルがロックされていて、バックアップ中に変更しないようにする場合は、物理バックアップを実行する必要があります。

以下のいずれかの MariaDB バックアップ方法で、MariaDB データベースのデータのバックアップを使用できます。

  • mysqldump を使用した論理バックアップ
  • Mariabackup ツールを使用した物理的なオンラインバックアップ
  • ファイルシステムのバックアップ
  • バックアップソリューションとしてレプリケーションを使用

8.2.4.1. mysqldump を使用した論理バックアップの実行

mysqldump クライアントはバックアップユーティリティーで、バックアップ目的でデータベースまたはデータベースの集合をダンプしたり、別のデータベースサーバーに転送したりできます。通常、mysqldump の出力は、サーバーテーブル構造を再作成する、それにデータを取り込む、またはその両方の SQL ステートメントで構成されます。また、mysqldump は、CSV などのコンマ区切りテキスト形式、XML など、その他の形式のファイルも生成できます。

mysqldump バックアップを実行するには、以下のいずれかのオプションを使用できます。

  • 選択したデータベースをバックアップする。
  • あるデータベースのテーブルのサブセットのバックアップを作成する。
  • 複数のデータベースをバックアップする。
  • すべてのデータベースをバックアップする。
8.2.4.1.1. mysqldump を使用したデータベース全体のバックアップ

手順

  • データベース全体のバックアップを取得するには、以下を実行します。

    # mysqldump [options] db_name > backup-file.sql
8.2.4.1.2. mysqldump を使用したデータベースから一連のテーブルのバックアップ

手順

  • あるデータベースで、テーブルのサブセットのバックアップを作成するには、mysqldump コマンドの末尾に、選択したテーブルの一覧を追加します。

    # mysqldump [options] db_name [tbl_name …​]
8.2.4.1.3. mysqldump でサーバーへのダンプファイルの読み込み

手順

  • ダンプファイルをサーバーに読み込むには、以下のいずれかを使用します。

    # mysql db_name < backup-file.sql
    # mysql -e "source /path-to-backup/backup-file.sql" db_name
8.2.4.1.4. mysqldump を使用した 2 つのデータベース間のデータのコピー

手順

  • データを MariaDB サーバー間でコピーしてデータベースを入力するには、以下を実行します。

    # mysqldump --opt db_name | mysql --host=remote_host -C db_name
8.2.4.1.5. mysqldump で複数データベースのダンプ

手順

  • 複数のデータベースを一度にダンプするには、次のコマンドを実行します。

    # mysqldump [options] --databases db_name1 [db_name2 …​] > my_databases.sql
8.2.4.1.6. mysqldump で全データベースのダンプ

手順

  • すべてのデータベースをダンプするには、以下を実行します。

    # mysqldump [options] --all-databases > all_databases.sql
8.2.4.1.7. mysqldump オプションの確認

手順

  • mysqldump サポートするオプションの一覧を表示するには、以下を実行します。

    $ mysqldump --help
8.2.4.1.8. 関連情報

mysqldump を使用した論理バックアップの詳細は、MariaDB のドキュメント を参照してください。

8.2.4.2. Mariabackup ツールを使用した物理的なオンラインバックアップ

Mariabackup は、Percona Xtrabackup テクノロジーをベースとしたツールで、InnoDB、Aria、および MyISAM のテーブルの物理的なオンラインバックアップを実行できます。

AppStream リポジトリーの mariadb-backup パッケージが提供する Mariabackup は、MariaDB サーバーの完全バックアップ機能に対応します。これには、暗号化されたデータと圧縮データが含まれます。

前提条件

  • mariadb-backup パッケージがシステムにインストールされている。

    # yum install mariadb-backup
  • Mariabackup には、バックアップを実行するユーザーの認証情報を指定している。この手順に示されるように、コマンドラインで認証情報を指定するか、または手順を適用する前に設定ファイルを指定します。設定ファイルを使用して認証情報を設定するには、最初にファイル (例: /etc/my.cnf.d/mariabackup.cnf) を作成し、新しいファイルの [xtrabackup] セクションまたは [mysqld] セクションに以下の行を追加します。

    [xtrabackup]
    user=myuser
    password=mypassword
    重要

    Mariabackup は、設定ファイルの [mariadb] セクションのオプションは読み込みません。MariaDB サーバーにデフォルト以外のデータディレクトリーが指定されている場合は、Mariabackup がデータディレクトリーを見つけることができるように、設定ファイルの [xtrabackup] セクションまたは [mysqld] セクションでこのディレクトリーを指定する必要があります。

    このようなデータディレクトリーを指定するには、MariaDB 設定ファイルの [xtrabackup] セクションまたは [mysqld] セクションに以下の行を追加します。

    datadir=/var/mycustomdatadir
    注記

    Mariabackup のユーザーがバックアップを操作するには、RELOADLOCK TABLES、および REPLICATION CLIENT の特権が必要です。

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

手順

  • 次のコマンドを実行します。

    $ mariabackup --backup --target-dir <backup_directory> --user <backup_user> --password <backup_passwd>

    target-dir オプションは、バックアップファイルを格納するディレクトリーを定義します。完全バックアップを実行する場合は、ターゲットディレクトリーが空であるか、存在しない必要があります。

    ユーザー オプションおよび パスワード オプションにより、ユーザー名とパスワードを設定できます。「前提条件」の説明に従って設定ファイルでユーザー名とパスワードをすでに設定している場合は、このオプションを使用しないでください。

関連情報

Mariabackup によるバックアップの実行の詳細は、「Full Backup and Restore with Mariabackup」を参照してください。

8.2.4.3. Mariabackup ツールを使用したデータの復元

バックアップが完了したら、mariabackup コマンドに以下のいずれかのオプションを使用して、バックアップからデータを復元できます。

  • --copy-back
  • --move-back

--copy-back オプションを使用すると、元のバックアップファイルを保持できます。--move-back オプションは、バックアップファイルをデータディレクトリーに移動し、元のバックアップファイルを削除します。

前提条件

  • mariadb サービスが稼働していないことを確認します。

    # systemctl stop mariadb.service
  • データディレクトリーが空であることを確認します。
8.2.4.3.1. バックアップファイルを維持しながら Mariabackup でデータの復元

元のバックアップファイルを維持しながらデータを復元するには、以下の手順を行います。

手順

  1. mariabackup コマンドを実行して、--copy-back オプションを指定します。

    $ mariabackup --copy-back --target-dir=/var/mariadb/backup/
  2. ファイルの権限を修正します。

    データベースを復元するとき、Mariabackup は、バックアップのファイルおよびディレクトリーの権限を保持します。ただし、Mariabackup は、ユーザーおよびグループがデータベースを復元する際にファイルをディスクに書き込みます。したがって、バックアップの復元後に、MariaDB サーバーのユーザーおよびグループ (通常は共に mysql) が一致するように、データディレクトリーの所有者の調整が必要になることがあります。

    たとえば、ファイルの所有権を mysql ユーザーおよびグループに再帰的に変更するには、次のコマンドを実行します。

    # chown -R mysql:mysql /var/lib/mysql/
  3. mariadb サービスを起動します。

    # systemctl start mariadb.service
8.2.4.3.2. バックアップファイルの削除中に Mariabackup でデータの復元

データを復元し、元のバックアップファイルを保存しないようにするには、以下の手順を行います。

手順

  1. --move-back オプションを指定して mariabackup コマンドを実行します。

    $ mariabackup --move-back --target-dir=/var/mariadb/backup/
  2. ファイルの権限を修正します。

    データベースを復元するとき、Mariabackup は、バックアップのファイルおよびディレクトリーの権限を保持します。ただし、Mariabackup は、ユーザーおよびグループがデータベースを復元する際にファイルをディスクに書き込みます。したがって、バックアップの復元後に、MariaDB サーバーのユーザーおよびグループ (通常は共に mysql) が一致するように、データディレクトリーの所有者の調整が必要になることがあります。

    たとえば、ファイルの所有権を mysql ユーザーおよびグループに再帰的に変更するには、次のコマンドを実行します。

    # chown -R mysql:mysql /var/lib/mysql/
  3. mariadb サービスを起動します。

    # systemctl start mariadb.service
8.2.4.3.3. 関連情報

詳細は「Full Backup and Restore with Mariabackup」を参照してください。

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

MariaDB データファイルのファイルシステムのバックアップを作成するには、root ユーザーに切り替えて、MariaDB データディレクトリーの内容をバックアップの場所にコピーします。

現在の設定またはログファイルのバックアップも作成するには、以下の手順の中から任意の手順を選択します。

手順

  1. mariadb サービスを停止します。

    # systemctl stop mariadb.service
  2. データファイルを必要な場所にコピーします。

    # cp -r /var/lib/mysql /backup-location
  3. 必要に応じて、設定ファイルを必要な場所にコピーします。

    # cp -r /etc/my.cnf /etc/my.cnf.d /backup-location/configuration
  4. 必要に応じて、ログファイルを必要な場所にコピーします。

    # cp /var/log/mariadb/* /backup-location/logs
  5. mariadb サービスを起動します。

    # systemctl start mariadb.service

8.2.4.5. レプリケーションをバックアップソリューションとして紹介します。

レプリケーションは、マスターサーバー用の代替バックアップソリューションです。マスターサーバーの複製となるスレーブサーバーを作成すると、マスターに影響を与えずに、スレーブでバックアップを実行できます。マスターは、スレーブをシャットダウンしている間にも実行でき、データをバックアップできます。

警告

レプリケーション自体は、バックアップソリューションとしては十分ではありません。レプリケーションは、ハードウェア障害からマスターサーバーを保護しますが、データ損失に対する保護は保証しないためです。この方法とともに、レプリケーションスレーブでその他のバックアップソリューションを使用することが推奨されます。

関連情報

レプリケーションをバックアップソリューションとして使用する場合は、MariaDB ドキュメンテーション を参照してください。

8.2.5. MariaDB 10.3 への移行

Red Hat Enterprise Linux 7 には、MySQL データベースファミリーからのサーバーのデフォルトの実装として、MariaDB 5.5 が同梱されています。新しいバージョンの MariaDB データベースサーバーは、Red Hat Enterprise Linux 6 および Red Hat Enterprise Linux 7 の Software Collections として利用できます。Red Hat Enterprise Linux 8 は、MariaDB 10.3 および MySQL 8.0 を提供します。

8.2.5.1. RHEL 7 と RHEL 8 のバージョンの MariaDB の違い

MariaDB 5.5MariaDB 10.3 において最も重要な変更点を以下に示します。

  • 10.1 以降、同期マルチクラスターでもある MariaDB Galera Cluster が、MariaDB の標準に含まれるようになりました。
  • ARCHIVE ストレージエンジンはデフォルトで有効ではなくなるため、プラグインを明示的に有効にする必要があります。
  • BLACKHOLE ストレージエンジンはデフォルトで有効ではなくなるため、プラグインを明示的に有効にする必要があります。
  • InnoDB は、MariaDB 10.1 以前のバージョンで使用されていた XtraDB ではなく、デフォルトのストレージエンジンとして使用されます。

    詳細は、「Why does MariaDB 10.2 use InnoDB instead of XtraDB?」を参照してください。

  • 新しい mariadb-connector-c パッケージは、MySQL と MariaDB に共通のクライアントライブラリーを提供します。このライブラリーは、データベースサーバー MySQL および MariaDB のすべてのバージョンで使用できます。その結果、Red Hat Enterprise Linux 8 に同梱される MySQL サーバーまたは MariaDB サーバーのいずれかに構築されるアプリケーションの 1 つに接続できます。

MariaDB 5.5 から MariaDB 10.3 へ移行するには、「設定変更」の記載どおりに複数の設定を実行する必要があります。

8.2.5.2. 設定変更

MariaDB 5.5 から MariaDB 10.3 への推奨される移行パスは、最初に MariaDB 10.0 にアップグレードしてから、1 バージョンずつ順次アップグレードすることです。

バージョンを 1 つずつアップグレードする主な利点は、変更に対するデータと構成の両方を含む、データベースの適合に優れています。アップグレードは、RHEL 8 (MariaDB 10.3) で利用可能なものと同じメジャーバージョンで終了します。これにより、設定変更やその他の問題が大幅に低下します。

MariaDB 5.5 から MariaDB 10.0 への移行時の設定の変更の詳細は、『Red Hat Software Collections』の「MariaDB 10.0 への移行」を参照してください。

以下の後続バージョンの MariaDB への以降と、必要な設定変更は、以下のドキュメントで説明します。

注記

MariaDB 5.5 から MariaDB 10.3 へ直接移行することもできますが、上記の移行ドキュメントに記載されている違いにより必要とされる設定変更をすべて実行する必要があります。

8.2.5.3. mysql_upgrade ツールを使用したインプレースアップグレード

データベースファイルを Red Hat Enterprise Linux 8 に移行するには、Red Hat Enterprise Linux 7 の MariaDB ユーザーが、mysql_upgrade ツールを使用してインプレースアップグレードを実行する必要があります。mysql_upgrade ツールは、mariadb-server-utils サブパッケージにより提供され、mariadb-server パッケージの依存関係としてインストールされます。

インプレースアップグレードを実行するには、Red Hat Enterprise Linux 8 システムの /var/lib/mysql/ データディレクトリーにバイナリーデータファイルをコピーして、mysql_upgrade ツールを使用する必要があります。

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

  • Red Hat Enterprise Linux 7 バージョンの MariaDB 5.5
  • Red Hat Software Collections のバージョンは、以下の通りです。

    • MariaDB 5.5 (サポート対象外になりました)
    • MariaDB 10.0 (サポート対象外になりました)
    • MariaDB 10.1 (サポート対象外になりました)
    • MariaDB 10.2

MariaDB 10.2 へのアップグレードは、バージョンごとに行うことが推奨されます。移行は、Red Hat Software Collections Release Notes で該当する章を参照してください。

注記

Red Hat Enterprise Linux 7 バージョンの MariaDB からアップグレードする場合、ソースデータは /var/lib/mysql/ ディレクトリーに保存されます。Red Hat Software Collections バージョンの MariaDB の場合、ソースデータディレクトリーは /var/opt/rh/<collection_name>/lib/mysql/ です (/opt/rh/mariadb55/root/var/lib/mysql/ データディレクトリーを使用する mariadb55 を除く)。

重要

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

インプレースアップグレードを実行する場合は、root で以下を行います。

  1. Red Hat Enterprise Linux 8 システムに mariadb-server パッケージがインストールされていることを確認します。

    # yum install mariadb-server
  2. データのコピー時に、mariadb デーモンがソースおよびターゲットのシステムで実行していないことを確認します。

    # systemctl stop mariadb.service
  3. ソースの場所から、Red Hat Enterprise Linux 8 ターゲットシステムの /var/lib/mysql/ ディレクトリーにデータをコピーします。
  4. ターゲットシステムでコピーされたファイルに適切なパーミッションと SELinux コンテキストを設定します。

    # restorecon -vr /var/lib/mysql
  5. ターゲットシステムで、MariaDB サーバーを起動します。

    # systemctl start mariadb.service
  6. mysql_upgrade コマンドを実行して、内部テーブルをチェックし、修復します。

    # systemctl mysql_upgrade
  7. アップグレードが完了したら、/etc/my.cnf.d/ ディレクトリーのすべての設定ファイルに MariaDB 10.3 の有効なオプションのみが含まれていることを確認してください。
重要

インプレースアップグレードに関連する特定のリスクと既知の問題があります。たとえば、一部のクエリーが動作しなかったり、アップグレード前とは異なる順序で実行される場合があります。これらのリスクと問題、およびインプレースアップグレードに関する全般的な情報は、『MariaDB 10.3 Release Notes』を参照してください。

8.2.6. Galera で MariaDB の複製

本セクションでは、Galera ソリューションを使用して MariaDB データベースを複製する方法を説明します。

8.2.6.1. MariaDB Galera Cluster の概要

Galera レプリケーションは、複数の MariaDB サーバーで構成される同期マルチマスター MariaDB Galera Cluster の作成に基づいています。

Galera レプリケーションと MariaDB データベースとの間のインターフェースは、書き込みセットレプリケーション API (wsrep API) で定義されます。

MariaDB Galera Cluster の主な機能は以下のとおりです。

  • 同期のレプリケーション
  • アクティブ/アクティブのマルチマスタートポロジー
  • クラスターノードへの読み取りおよび書き込み
  • 自動メンバーシップ制御、失敗したノードのクラスターからの削除
  • 自動ノードの参加
  • 行レベルの並列レプリケーション
  • ダイレクトクライアント接続 (ユーザーはクラスターノードにログオンし、レプリケーションの実行中にノードを直接操作できます)

同期レプリケーションとは、サーバーがトランザクションに関連付けられた書き込みセットをクラスター内のすべてのノードにブロードキャストすることで、コミット時にトランザクションをレプリケートすることを意味します。クライアント (ユーザーアプリケーション) は、データベース管理システム (DBMS) に直接接続し、ネイティブの MariaDB と同様の動作が発生します。

同期レプリケーションは、クラスター内の 1 つのノードで発生した変更が、クラスター内の他のノードで同時に発生することを保証します。

そのため、同期レプリケーションには、非同期のレプリケーションと比べて次のような利点があります。

  • 特定のクラスターノード間の変更の伝播に遅延がない
  • すべてのクラスターノードには常に一貫性がある
  • いずれかのクラスターノードがクラッシュしても、最新の変更は失われない
  • すべてのクラスターノードのトランザクションが並列に実行する
  • クラスター全体にわたる因果関係

関連情報

詳細は、アップストリームのドキュメントを参照してください。

8.2.6.2. MariaDB Galera クラスターを構築するためのコンポーネント

MariaDB Galera Cluster を構築できるようにするには、以下のパッケージをシステムにインストールしておく必要があります。

  • mariadb-server-galera
  • mariadb-server
  • galera

mariadb-server-galera パッケージには、MariaDB Galera Cluster のサポートファイルとスクリプトが含まれます。

MariaDB アップストリームは、mariadb-server パッケージにパッチを適用して、書き込みセットレプリケーション API (wsrep API) を組み込みます。この API は、Galera レプリケーションと MariaDB との間のインターフェースを提供します。

また、MariaDB のアップストリームでは galera にパッチを適用して、MariaDB の完全サポートを追加します。galera パッケージには、Galera Replication Library および Galera Arbitrator ツールが含まれます。Galera Replication Library は、レプリケーション機能全体を提供します。Galera Arbitrator は、スプリットブレインのシナリオで投票に参加するクラスターメンバーとして使用できます。ただし、Galera Arbitrator は実際のレプリケーションには参加できません。

関連情報

詳細は、アップストリームのドキュメントを参照してください。

8.2.6.3. MariaDB Galera クラスターのデプロイメント

前提条件

  • MariaDB Galera Cluster を構築するのに必要なソフトウェアがすべてシステムにインストールされている。これを確認するには、mariadb:10.3 モジュールの galera プロファイルをインストールします。

    # yum module install mariadb:10.3/galera

    これにより、以下のパッケージがインストールされます。

  • MariaDB サーバーのレプリケーション設定は、システムを初めてクラスターに追加する前に更新する必要があります。

    デフォルト設定は、/etc/my.cnf.d/galera.cnf ファイルに同梱されています。

    MariaDB Galera Cluster をデプロイする前に、以下の文字列で開始するように、すべてのノードの /etc/my.cnf.d/galera.cnf ファイルに wsrep_cluster_address オプションを設定します。

    gcomm://

    初期ノードでは、wsrep_cluster_address を空のリストとして設定できます。

    wsrep_cluster_address="gcomm://"

    その他のすべてのノードに wsrep_cluster_address を設定して、実行中のクラスターに属するノードへのアドレスを追加します。以下に例を示します。

    wsrep_cluster_address="gcomm://10.0.0.10"

    Galera Cluster アドレスの設定方法は、「Galera Cluster Address」を参照してください。

手順

  1. ノードで以下のラッパーを実行して、新規クラスターの最初のノードをブートストラップします。

    $ galera_new_cluster

    このラッパーにより、MariaDB サーバーデーモン (mysqld) に --wsrep-new-cluster オプションが指定されて実行されるようになります。このオプションは、接続する既存クラスターがないという情報を提供します。したがって、ノードは新規 UUID を作成し、新しいクラスターを特定します。

    注記

    mariadb サービスは、複数の MariaDB サーバープロセスと対話する systemd メソッドをサポートします。したがって、複数の MariaDB サーバーを実行している場合は、インスタンス名を接尾辞として指定して、特定のインスタンスをブートストラップできます。

    $ galera_new_cluster mariadb@node1
  2. 各ノードで次のコマンドを実行して、その他のノードをクラスターに接続します。

    # systemctl start mariadb

    その結果、ノードはクラスターに接続し、それ自体をクラスターの状態と同期します。

関連情報

詳細は「Getting started with MariaDB Galera Cluster」を参照してください。

8.2.6.4. 新規ノードの MariaDB Galera クラスターへの追加

新規ノードを MariaDB Galera Cluster に追加するには、以下の手順に従います。

この手順に従って、既存のノードを再接続することもできます。

手順

  • 特定のノードで、/etc/my.cnf.d/galera.cnf 設定ファイルの [mariadb] セクション内にある wsrep_cluster_address オプションで、1 つ以上の既存クラスターメンバーにアドレスを指定します。

    [mariadb]
    wsrep_cluster_address="gcomm://192.168.0.1"

    新規ノードを既存クラスターノードのいずれかに接続すると、クラスター内のすべてのノードを表示できるようになります。

    ただし、wsrep_cluster_address のクラスターの全ノードを表示することが推奨されます。

    したがって、1 つ以上のクラスターノードがダウンしても、その他のクラスターノードに接続することでノードがクラスターに参加できます。すべてのメンバーがメンバーシップに同意すると、クラスターの状態が変更します。新規ノードの状態がそのクラスターとは異なる場合は、他のノードとの整合性を保つために、IST (Incremental State Transfer) または SST (State Snapshot Transfer) のいずれかが要求されます。

関連情報

8.2.6.5. MariaDB Galera クラスターの再起動

すべてのノードを同時にシャットダウンすると、クラスターが終了し、実行中のクラスターは存在しなくなります。ただし、クラスターのデータは引き続き存在します。

クラスターを再起動するには、「MariaDB Galera クラスターのデプロイメント」の説明に従って最初のノードをブートストラップします。

警告

クラスターがブートストラップされず、最初のノードの mysqldsystemctl start mariadb コマンドで起動した場合、ノードは /etc/my.cnf.d/galera.cnf ファイルの wsrep_cluster_address オプションに記載されている中から少なくとも 1 つのノードに接続しようとします。ノードが現在実行していない場合は、再起動に失敗します。

関連情報

詳細は「Getting started with MariaDB Galera Cluster」を参照してください。

8.3. PostgreSQL の使用

8.3.1. PostgreSQL の概要

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

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

本セクションでは、「PostgreSQL のインストール」PostgreSQL をインストールする方法や、「RHEL 8 バージョンの PostgreSQL への移行」 で、別のバージョンの PostgreSQL に移行する方法を説明します。移行の前提条件に、データバックアップの実行があります。

8.3.2. PostgreSQL のインストール

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

  • PostgreSQL 10 - デフォルトのストリーム
  • PostgreSQL 9.6
  • PostgreSQL 12 - RHEL 8.1.1 以降利用できます。
注記

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

PostgreSQL をインストールするには、以下を実行します。

  1. インストールするストリーム (バージョン) を有効にします。

    # yum module enable postgresql:stream

    stream を、選択した PostgreSQL サーバーのバージョンに置き換えます。

    PostgreSQL 10 を提供するデフォルトストリームを使用する場合は、この手順を省略できます。

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

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

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

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

    # systemctl enable postgresql.service

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

重要

RHEL 8 内の以前の postgresql ストリームからアップグレードする場合は、「後続のストリームへの切り替え」「RHEL 8 バージョンの PostgreSQL への移行」に記載されている両手順を実行します。

8.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 データベースに対する詳細なユーザー権限を設定するのに使用されます。

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

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

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

postgresql-setup --initdb

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

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

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

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

8.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
8.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
8.3.4.1.2.1. 別のサーバーでのデータベースの復元

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

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

pg_dump -h host1 dbname | psql -h host2 dbname
8.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

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

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

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

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

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

8.3.4.1.4. 関連情報

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

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

8.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
8.3.4.2.2. ファイルシステムレベルのバックアップの長所と短所

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

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

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

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

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

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

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

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

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

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

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

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

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

注記

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

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

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

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

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

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

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

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

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

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

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

8.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 ドキュメンテーション を参照してください。

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

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

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

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

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

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

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

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

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

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 バージョンの アップストリームの互換性ノート を参照してください。

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

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

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

  • RHEL 7 システムバージョンの PostgreSQL 9.2 から、RHEL 8 バージョンの PostgreSQL 10
  • RHEL 8 バージョンの PostgreSQL 10 から、RHEL 8 バージョンの PostgreSQL 12

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

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

重要

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

デフォルトでは、すべてのデータは、RHEL 7 および RHEL 8 システムの両方の /var/lib/pgsql/data/ ディレクトリーに保存されます。

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

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

  1. RHEL 8 システムで、移行するストリーム (バージョン)を有効にします。

    # yum module enable postgresql:stream

    stream を、選択した PostgreSQL サーバーのバージョンに置き換えます。

    PostgreSQL 10 を提供するデフォルトストリームを使用する場合は、この手順を省略できます。

  2. 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 パッケージの両方に対してビルドしてください。

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

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

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

    $ /bin/postgresql-setup --upgrade

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

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

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

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

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

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

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

    # systemctl enable postgresql.service

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

ダンプおよび復元のアップグレードを使用する場合は、すべてのデータベースのコンテンツを 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

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 を除く)。

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

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

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

  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 システムで、移行するストリーム (バージョン)を有効にします。

    # yum module enable postgresql:stream

    stream を、選択した PostgreSQL サーバーのバージョンに置き換えます。

    PostgreSQL 10 を提供するデフォルトストリームを使用する場合は、この手順を省略できます。

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

    # yum install postgresql-server

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

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

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

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

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

このページには機械翻訳が使用されている場合があります (詳細はこちら)。