手順

1. CA およびサーバー証明書を /etc/pki/tls/certs/ ディレクトリーに保存します。

   # mv <path>/server.example.com.crt.pem /etc/pki/tls/certs/
   # mv <path>/ca.crt.pem /etc/pki/tls/certs/

2. MariaDB サーバーがファイルを読み込めるように、CA およびサーバー証明書にパーミッションを設定します。

   # chmod 644 /etc/pki/tls/certs/server.example.com.crt.pem /etc/pki/tls/certs/ca.crt.pem

   証明書は、セキュアな接続が確立される前は通信の一部であるため、任意のクライアントは認証なしで証明書を取得できます。そのため、CA およびサーバーの証明書ファイルに厳密なパーミッションを設定する必要はありません。

3. サーバーの秘密鍵を /etc/pki/tls/private/ ディレクトリーに保存します。

   # mv <path>/server.example.com.key.pem /etc/pki/tls/private/

4. サーバーの秘密鍵にセキュアなパーミッションを設定します。

   # chmod 640 /etc/pki/tls/private/server.example.com.key.pem
   # chgrp mysql /etc/pki/tls/private/server.example.com.key.pem

   承認されていないユーザーが秘密鍵にアクセスできる場合は、MariaDB サーバーへの接続は安全ではなくなります。

5. SELinux コンテキストを復元します。

   #  restorecon -Rv /etc/pki/tls/

手順

1. /etc/my.cnf.d/mariadb-server-tls.cnf ファイルを作成します。

   1. 以下の内容を追加して、秘密鍵、サーバー、および CA 証明書へのパスを設定します。

      [mariadb]
      ssl_key = /etc/pki/tls/private/server.example.com.key.pem
      ssl_cert = /etc/pki/tls/certs/server.example.com.crt.pem
      ssl_ca = /etc/pki/tls/certs/ca.crt.pem

   2. 証明書失効リスト (CRL) がある場合は、それを使用するように MariaDB サーバーを設定します。

      ssl_crl = /etc/pki/tls/certs/example.crl.pem

   3. オプション:暗号化のない接続試行を拒否します。この機能を有効にするには、以下を追加します。

      require_secure_transport = on

   4. オプション:サーバーがサポートする TLS バージョンを設定します。たとえば、TLS 1.2 および TLS 1.3 をサポートするには、以下を追加します。

      tls_version = TLSv1.2,TLSv1.3

      デフォルトでは、サーバーは TLS 1.1、TLS 1.2、および TLS 1.3 をサポートします。

2. mariadb サービスを再起動します。

   # systemctl restart mariadb

1. MariaDB で TLS 暗号化が有効になっていることを確認します。

   # mysql -u root -p -e "SHOW GLOBAL VARIABLES LIKE 'have_ssl';"
   +---------------+-----------------+
   | Variable_name | Value           |
   +---------------+-----------------+
   | have_ssl      | YES             |
   +---------------+-----------------+

   have_ssl 変数が yes に設定されている場合、TLS 暗号化が有効になります。

2. MariaDB サービスが特定の TLS バージョンのみをサポートするように設定している場合は、tls_version 変数を表示します。

   # mysql -u root -p -e "SHOW GLOBAL VARIABLES LIKE 'tls_version';"
   +---------------+-----------------+
   | Variable_name | Value           |
   +---------------+-----------------+
   | tls_version   | TLSv1.2,TLSv1.3 |
   +---------------+-----------------+

手順

1. 管理ユーザーとしてMariaDB サーバーに接続します。

   # mysql -u root -p -h server.example.com

   管理ユーザーがリモートでサーバーにアクセスする権限を持たない場合は、MariaDB サーバーでコマンドを実行し、localhost に接続します。

2. REQUIRE SSL 句を使用して、ユーザーが TLS 暗号化接続を使用して接続する必要があるよう強制します。

   MariaDB [(none)]> ALTER USER 'example'@'%' REQUIRE SSL;

検証

1. TLS 暗号化を使用して、example ユーザーとしてサーバーに接続します。

   # mysql -u example -p -h server.example.com --ssl
   ...
   MariaDB [(none)]>

   エラーが表示されず、インタラクティブな MariaDB コンソールにアクセスできる場合は、TLS との接続は成功します。

2. TLS を無効にして、example ユーザーとして接続を試みます。

   # mysql -u example -p -h server.example.com --skip-ssl
   ERROR 1045 (28000): Access denied for user 'example'@'server.example.com' (using password: YES)

   このユーザーに TLS が必要だが無効になっているため、サーバーはログインの試行を拒否しました (--skip-ssl)。

手順

1. RHEL が、サーバー証明書を発行した CA を信頼しない場合は、以下を行います。

   1. CA 証明書を /etc/pki/ca-trust/source/anchors/ ディレクトリーにコピーします。

      # cp <path>/ca.crt.pem /etc/pki/ca-trust/source/anchors/

   2. すべてのユーザーが CA 証明書ファイルを読み取りできるようにするパーミッションを設定します。

      # chmod 644 /etc/pki/ca-trust/source/anchors/ca.crt.pem

   3. CA 信頼データベースを再構築します。

      # update-ca-trust

2. 以下の内容で /etc/my.cnf.d/mariadb-client-tls.cnf ファイルを作成します。

   [client-mariadb]
   ssl
   ssl-verify-server-cert

   これらの設定は、MariaDB クライアントが TLS 暗号化 (ssl) を使用し、クライアントがホスト名をサーバー証明書 (ssl-verify-server-cert) の CN と比較することを定義します。

手順

1. mariabackup コマンドを実行します。

   • データを復元し、元のバックアップファイルを保持するには、--copy-back オプションを使用します。

     $ mariabackup --copy-back --target-dir=/var/mariadb/backup/

   • データを復元し、元のバックアップファイルを削除するには、--move-back オプションを使用します。

     $ 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

手順

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

6. バックアップされたデータをバックアップ場所から /var/lib/mysqlディレクトリーに読み込む際は、mysql:mysql が /var/lib/mysql 内のすべてのデータの所有者であることを確認してください。

   # chown -R mysql:mysql /var/lib/mysql

手順

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

   # dnf install mariadb-server

2. データのコピー時に、mariadb サービスがソースおよびターゲットのシステムで稼働していないことを確認します。

   # systemctl stop mariadb.service

3. ソースの場所から RHEL 9 ターゲットシステムの /var/lib/mysql/ ディレクトリーにデータをコピーします。

4. ターゲットシステムでコピーされたファイルに適切なパーミッションと SELinux コンテキストを設定します。

   # restorecon -vr /var/lib/mysql

5. mysql:mysql が /var/lib/mysql ディレクトリー内のすべてのデータの所有者であることを確認してください。

   # chown -R mysql:mysql /var/lib/mysql

6. /etc/my.cnf.d/ にあるオプションファイルに MariaDB 10.5 に対して有効なオプションのみが含まれるように、設定を調整します。詳細は、MariaDB 10.4 および MariaDB 10.5 のアップストリームドキュメントを参照してください。

7. ターゲットシステムで、MariaDB サーバーを起動します。

   • スタンドアロンを実行しているデータベースをアップグレードする場合:

     # systemctl start mariadb.service

   • Galera クラスターノードをアップグレードする場合:

     # galera_new_cluster

     mariadb サービスが自動的に起動します。

8. mariadb-upgrade ユーティリティーを実行して、内部テーブルをチェックし、修復します。

   • スタンドアロンを実行しているデータベースをアップグレードする場合:

     $ mariadb-upgrade

   • Galera クラスターノードをアップグレードする場合:

     $ mariadb-upgrade --skip-write-binlog

手順

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

   # galera_new_cluster

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

   注記

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

   # galera_new_cluster mariadb@node1

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

   # systemctl start mariadb

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

手順

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

   # systemctl stop mysqld.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/mysql/* /backup-location/logs

5. mysqld サービスを開始します。

   # systemctl start mysqld.service

6. バックアップされたデータをバックアップ場所から /var/lib/mysqlディレクトリーに読み込む際は、mysql:mysql が /var/lib/mysql 内のすべてのデータの所有者であることを確認してください。

   # chown -R mysql:mysql /var/lib/mysql

手順

1. [mysqld] セクションの /etc/my.cnf.d/mysql-server.cnf ファイルに以下のオプションを含めます。

   • bind-address=source_ip_adress

     このオプションは、レプリカからソースへの接続に必要です。

   • server-id=id

     id は一意である必要があります。

   • log_bin=path_to_source_server_log

     このオプションは、MySQL ソースサーバーのバイナリーログファイルへのパスを定義します。例: log_bin=/var/log/mysql/mysql-bin.log

   • gtid_mode=ON

     このオプションは、サーバー上でグローバルトランザクション識別子 (GTID) を有効にします。

   • enforce-gtid-consistency=ON

     サーバーは、GTID を使用して安全にログに記録できるステートメントのみの実行を許可することにより、GTID の整合性を強化します。

   • オプション: binlog_do_db=db_name

     選択したデータベースのみを複製する場合は、このオプションを使用します。選択した複数のデータベースを複製するには、各データベースを個別に指定します。

     binlog_do_db=db_name1
     binlog_do_db=db_name2
     binlog_do_db=db_name3

   • オプション: binlog_ignore_db=db_name

     このオプションを使用して、特定のデータベースをレプリケーションから除外します。

2. mysqld サービスを再起動します。

   # systemctl restart mysqld.service

手順

1. [mysqld] セクションの /etc/my.cnf.d/mysql-server.cnf ファイルに以下のオプションを含めます。

   • server-id=id

     id は一意である必要があります。

   • relay-log=path_to_replica_server_log

     リレーログは、レプリケーション中に MySQL レプリカサーバーによって作成されたログファイルのセットです。

   • log_bin=path_to_replica_sever_log

     このオプションは、MySQL レプリカサーバーのバイナリーログファイルへのパスを定義します。例: log_bin=/var/log/mysql/mysql-bin.log

     このオプションはレプリカでは必須ではありませんが、強く推奨します。

   • gtid_mode=ON

     このオプションは、サーバー上でグローバルトランザクション識別子 (GTID) を有効にします。

   • enforce-gtid-consistency=ON

     サーバーは、GTID を使用して安全にログに記録できるステートメントのみの実行を許可することにより、GTID の整合性を強化します。

   • log-replica-updates=ON

     このオプションにより、ソースサーバーから受信した更新がレプリカのバイナリーログに記録されます。

   • skip-replica-start=ON

     このオプションは、レプリカサーバーの起動時に、レプリカサーバーがレプリケーションスレッドを開始しないようにします。

   • オプション: binlog_do_db=db_name

     特定のデータベースのみを複製する場合は、このオプションを使用します。複数のデータベースを複製するには、各データベースを個別に指定します。

     binlog_do_db=db_name1
     binlog_do_db=db_name2
     binlog_do_db=db_name3

   • オプション: binlog_ignore_db=db_name

     このオプションを使用して、特定のデータベースをレプリケーションから除外します。

2. mysqld サービスを再起動します。

   # systemctl restart mysqld.service

手順

1. レプリケーションユーザーを作成します。

   mysql> CREATE USER 'replication_user'@'replica_server_ip' IDENTIFIED WITH mysql_native_password BY 'password';

2. ユーザーにレプリケーション権限を付与します。

   mysql> GRANT REPLICATION SLAVE ON *.* TO 'replication_user'@'replica_server_ip';

3. MySQL データベースの付与テーブルを再読み込みします。

   mysql> FLUSH PRIVILEGES;

4. ソースサーバーを読み取り専用状態に設定します。

   mysql> SET @@GLOBAL.read_only = ON;

手順

1. レプリカサーバーを読み取り専用状態に設定します。

   mysql> SET @@GLOBAL.read_only = ON;

2. レプリケーションソースを設定します。

   mysql> CHANGE REPLICATION SOURCE TO
       -> SOURCE_HOST='source_ip_address',
       -> SOURCE_USER='replication_user',
       -> SOURCE_PASSWORD='password',
       -> SOURCE_AUTO_POSITION=1;

3. MySQL レプリカサーバーでレプリカスレッドを開始します。

   mysql> START REPLICA;

4. ソースサーバーとレプリカサーバーの両方で、読み取り専用状態の設定を解除します。

   mysql> SET @@GLOBAL.read_only = OFF;

5. オプション:デバッグの目的で、レプリカサーバーのステータスを検査します。

   mysql> SHOW REPLICA STATUS\G;

   注記

   レプリカサーバーの起動または接続に失敗した場合は、SHOW MASTER STATUS コマンドの出力に表示されるバイナリーログファイルの位置に続く特定の数のイベントをスキップできます。たとえば、定義された位置から最初のイベントをスキップします。

   mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;

   レプリカサーバーを再起動してみてください。

6. オプション:レプリカサーバーでレプリカスレッドを停止します。

   mysql> STOP REPLICA;

1. ソースサーバーにサンプルデータベースを作成します。

   mysql> CREATE DATABASE test_db_name;

2. test_db_name データベースが、レプリカサーバーで複製されていることを確認します。

3. ソースサーバーまたはレプリカサーバーのいずれかで以下のコマンドを実行して、MySQL サーバーのバイナリーログファイルに関するステータス情報を表示します。

   mysql> SHOW MASTER STATUS;

   ソースで実行されたトランザクションの GTID のセットを示す Executed_Gtid_Set 列は、空であってはなりません。

   注記

   レプリカサーバーで SHOW SLAVE STATUS を使用すると、同じ GTID のセットが Executed_Gtid_Set 行に表示されます。

手順

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

   # dnf install postgresql-server postgresql-upgrade

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

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

   • 基本設定:RHEL 9 システムで、サーバーがデフォルトの /var/lib/pgsql/data ディレクトリーを使用し、データベースが正しく初期化され、有効になっているかどうかを確認します。さらに、データファイルは、/usr/lib/systemd/system/postgresql.service ファイルに記載されているパスと同じパスに保存する必要があります。
   • PostgreSQL サーバー:システムは複数の PostgreSQL サーバーを実行できます。これらのすべてのサーバーのデータディレクトリーが独立して処理されていることを確認してください。
   • PostgreSQL サーバーモジュール:RHEL 8 で使用されていた PostgreSQL サーバーモジュールも、RHEL 9 システムにインストールされていることを確認してください。プラグインは /usr/lib64/pgsql/ ディレクトリーにインストールされていることに注意してください。

3. データのコピー時に、postgresql サービスがソースおよびターゲットのシステムで稼働していないことを確認します。

   # systemctl stop postgresql.service

4. データベースファイルをソースの場所から RHEL 9 システムの /var/lib/pgsql/data/ ディレクトリーにコピーします。

5. PostgreSQL ユーザーで以下のコマンドを実行して、アップグレードプロセスを実行します。

   # postgresql-setup --upgrade

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

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

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

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

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

   # systemctl start postgresql.service

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

   su postgres -c '~/analyze_new_cluster.sh'

9. システムの起動時に、新しい PostgreSQL サーバーを自動的に起動させる場合は、次のコマンドを実行します。

   # systemctl enable postgresql.service

手順

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

   # systemctl start postgresql.service

2. RHEL 8 システムで、すべてのデータベースのコンテンツを 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 9 システムで、postgresql-server パッケージをインストールします。

   # dnf install postgresql-server

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

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

   # postgresql-setup --initdb

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

   su - postgres -c 'test -e "$HOME/pgdump_file.sql" && echo exists'

7. RHEL 8 システムから設定ファイルをコピーします。

   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 9 システムで、新しい PostgreSQL サーバーを起動します。

   # systemctl start postgresql.service

9. RHEL 9 システムで、ダンプされた sql ファイルからデータをインポートします。

   su - postgres -c 'psql -f ~/pgdump_file.sql postgres'