Red Hat Training

A Red Hat training course is available for RHEL 8

7.2. MariaDB の使用

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

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

7.2.1. MariaDB のインストール

RHEL 8 では、MariaDB サーバーは、それぞれ個別のストリームにより提供される以下のバージョンで利用できます。

  • MariaDB 10.3
  • MariaDB 10.5 - RHEL 8.4 以降で利用できます。

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

手順

  1. mariadb モジュールからストリーム (バージョン) を選択し、server プロファイルを指定して MariaDB サーバーパッケージをインストールします。以下に例を示します。

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

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

    # systemctl enable mariadb.service
  4. MariaDB 10.3 に推奨: MariaDB をインストールする際のセキュリティーを向上させるには、次のコマンドを実行します。

    $ mysql_secure_installation

    このコマンドは、完全にインタラクティブなスクリプトを起動して、プロセスの各ステップのプロンプトを表示します。このスクリプトを使用すると、次の方法でセキュリティーを改善できます。

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

      注記

      mysql_secure_installation スクリプトは、MariaDB 10.5 以降では価値がなくなりました。セキュリティーの強化は、MariaDB 10.5 以降のデフォルトの動作の一部です。

重要

RPM パッケージが競合しているため、RHEL 8 では MariaDB および MySQL データベースサーバーを同時にインストールすることはできません。RHEL 7 用の Red Hat Software Collections では、コンポーネントの同時インストールが可能です。RHEL 8 では、コンテナー内で異なるバージョンのデータベースサーバーを使用できます。

7.2.2. MariaDB の設定

MariaDB サーバーをネットワーク用に設定するには、以下の手順に従います。

手順

  1. /etc/my.cnf.d/mariadb-server.cnf ファイルの [mysqld] セクションを編集します。以下の設定ディレクティブを設定できます。

    • bind-address: サーバーがリッスンするアドレスです。設定可能なオプションは以下のとおりです。

      • ホスト名
      • IPv4 アドレス
      • IPv6 アドレス
    • skip-networking: サーバーが TCP/IP 接続をリッスンするかどうかを制御します。以下の値が使用できます。

      • 0 - すべてのクライアントをリッスンする
      • 1 - ローカルクライアントのみをリッスンする
    • port: MariaDB が TCP/IP 接続をリッスンするポート。
  2. mariadb サービスを再起動します。

    # systemctl restart mariadb.service

7.2.3. MariaDB サーバーでの TLS 暗号化の設定

デフォルトでは、MariaDB は暗号化されていない接続を使用します。安全な接続のために、MariaDB サーバーで TLS サポートを有効にし、暗号化された接続を確立するようにクライアントを設定します。

7.2.3.1. MariaDB サーバーに CA 証明書、サーバー証明書、および秘密鍵を配置する

MariaDB サーバーで TLS 暗号化を有効にする前に、認証局 (CA) 証明書、サーバー証明書、および秘密鍵を MariaDB サーバーに保存します。

前提条件

  • Privacy Enhanced Mail(PEM) 形式の以下のファイルがサーバーにコピーされています。

    • サーバーの秘密鍵: server.example.com.key.pem
    • サーバー証明書: server.example.com.crt.pem
    • 認証局 (CA) 証明書: ca.crt.pem

    秘密鍵および証明書署名要求 (CSR) の作成や、CA からの証明書要求に関する詳細は、CA のドキュメントを参照してください。

手順

  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/

7.2.3.2. MariaDB サーバーでの TLS の設定

セキュリティーを向上させるには、MariaDB サーバーで TLS サポートを有効にします。その結果、クライアントは TLS 暗号化を使用してサーバーでデータを送信できます。

前提条件

  • MariaDB サーバーをインストールしている。
  • mariadb サービスが実行している。
  • Privacy Enhanced Mail(PEM) 形式の以下のファイルがサーバー上にあり、mysql ユーザーが読み取りできます。

    • サーバーの秘密鍵: /etc/pki/tls/private/server.example.com.key.pem
    • サーバー証明書: /etc/pki/tls/certs/server.example.com.crt.pem
    • 認証局 (CA) 証明書 /etc/pki/tls/certs/ca.crt.pem
  • サーバー証明書のサブジェクト識別名 (DN) またはサブジェクトの別名 (SAN) フィールドは、サーバーのホスト名と一致します。

手順

  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. 必要に応じて、MariaDB 10.5.2 以降を実行する場合は、暗号化せずに接続を拒否できます。この機能を有効にするには、以下を追加します。

      require_secure_transport = on
    4. 必要に応じて、MariaDB 10.4.6 以降を実行する場合は、サーバーが対応する 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

検証

トラブルシューティングを簡素化するには、ローカルクライアントが TLS 暗号化を使用するように設定する前に、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 |
    +---------------+-----------------+

7.2.3.3. 特定のユーザーアカウントに TLS で暗号化された接続を要求する

機密データにアクセスできるユーザーは、ネットワーク上で暗号化されていないデータ送信を回避するために、常に TLS で暗号化された接続を使用する必要があります。

すべての接続にセキュアなトランスポートが必要なサーバーで設定できない場合は (require_secure_transport = on)、TLS 暗号化を必要とするように個別のユーザーアカウントを設定します。

前提条件

  • MariaDB サーバーで TLS サポートが有効になっている。
  • セキュアなトランスポートを必要とするように設定するユーザーが存在する。
  • クライアントは、サーバーの証明書を発行した CA 証明書を信頼している。

手順

  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)。

7.2.4. MariaDB クライアントでの TLS 暗号化のグローバルな有効化

MariaDB サーバーが TLS 暗号化に対応している場合は、安全な接続のみを確立し、サーバー証明書を検証するようにクライアントを設定します。この手順では、サーバー上のすべてのユーザーで TLS サポートを有効にする方法を説明します。

7.2.4.1. デフォルトで TLS 暗号化を使用するように MariaDB クライアントを設定する

RHEL では、MariaDB クライアントが TLS 暗号化を使用するようにグローバルに設定でき、サーバー証明書の Common Name (CN) が、ユーザーが接続するホスト名と一致することを検証します。これにより、man-in-the-middle 攻撃 (中間者攻撃) を防ぎます。

前提条件

  • MariaDB サーバーで TLS サポートが有効になっている。
  • サーバー証明書を発行した認証局 (CA) が RHEL で信頼されていない場合は、CA 証明書がクライアントにコピーされています。

手順

  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 と比較することを定義します。

検証

  • ホスト名を使用してサーバーに接続し、サーバーの状態を表示します。

    # mysql -u root -p -h server.example.com -e status
    ...
    SSL:        Cipher in use is TLS_AES_256_GCM_SHA384

    SSL エントリーに Cipher in use is…​ が含まれている場合、接続は暗号化されています。

    このコマンドで使用するユーザーには、リモートで認証するパーミッションがあることに注意してください。

    接続するホスト名がサーバーの TLS 証明書のホスト名と一致しない場合、ssl-verify-server-cert パラメーターにより接続が失敗します。たとえば、localhost に接続する場合は、以下のようになります。

    # mysql -u root -p -h localhost -e status
    ERROR 2026 (HY000): SSL connection error: Validation of SSL server certificate failed

関連情報

  • mysql(1) man ページの --ssl* パラメーターの説明。

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

Red Hat EnterpriseLinux 8 で MariaDB データベースからデータをバックアップする主な方法は 2 つあります。

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 選択したデータベースを 1 つまたは複数バックアップ
  • すべてのデータベースをバックアップする。
  • あるデータベースのテーブルのサブセットのバックアップを作成する。

手順

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

    # mysqldump [options] --databases db_name > backup-file.sql
  • 複数のデータベースを一度にダンプするには、次のコマンドを実行します。

    # mysqldump [options] --databases db_name1 [db_name2 …​] > backup-file.sql
  • すべてのデータベースをダンプするには、以下を実行します。

    # mysqldump [options] --all-databases > backup-file.sql
  • 1 つ以上のダンプされたフルデータベースをサーバーにロードし直すには、以下を実行します。

    # mysql < backup-file.sql
  • データベースをリモート MariaDB サーバーにロードするには、以下を実行します。

    # mysql --host=remote_host < backup-file.sql
  • あるデータベースでテーブルのサブセットをダンプするには、mysqldump コマンドの末尾に、選択したテーブルのリストを追加します。

    # mysqldump [options] db_name [tbl_name …​​] > backup-file.sql
  • 1 つのデータベースからダンプされたテーブルのサブセットをロードするには、以下を実行します。

    # mysql db_name < backup-file.sql
    注記

    この時点で、db_name データベースが存在している必要があります。

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

    $ mysqldump --help

関連情報

  • mysqldump を使用した論理バックアップの詳細は、MariaDB Documentation を参照してください。

7.2.5.2. Mariabackup ユーティリティーを使用した物理的なオンラインバックアップの実行

Mariabackup は、Percona XtraBackup テクノロジーをベースとしたユーティリティーです。これにより、InnoDB、Aria、および MyISAM テーブルの物理的なオンラインバックアップを実行できます。このユーティリティーは、AppStream リポジトリーから mariadb-backup パッケージで提供されます。

Mariabackup は、MariaDB サーバーの完全バックアップ機能に対応します。これには、暗号化されたデータおよび圧縮データが含まれます。

前提条件

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

    # yum install mariadb-backup
  • Mariabackup には、バックアップを実行するユーザーの認証情報を指定する必要があります。認証情報はコマンドラインまたは設定ファイルで指定できます。
  • Mariabackup のユーザーは、RELOADLOCK TABLES、および REPLICATION CLIENT の権限が必要です。

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

手順

  • コマンドラインで認証情報を提供する間にバックアップを作成するには、以下を実行します。

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

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

    ユーザー オプションおよび パスワード オプションにより、ユーザー名とパスワードを設定できます。

  • 設定ファイルに認証情報を設定してバックアップを作成するには、次のコマンドを実行します。

    1. /etc/my.cnf.d/ ディレクトリーに設定ファイルを作成します (例: /etc/my.cnf.d/mariabackup.cnf)。
    2. 以下の行を新規ファイルの [xtrabackup] セクションまたは [mysqld] セクションに追加します。

      [xtrabackup]
      user=myuser
      password=mypassword
    3. バックアップを実行します。

      $ mariabackup --backup --target-dir <backup_directory>
重要

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

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

datadir=/var/mycustomdatadir

7.2.5.3. Mariabackup ユーティリティーを使用したデータの復元

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

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

Mariabackup ユーティリティーを使用してデータを復元するには、以下の手順に従います。

前提条件

  • mariadb サービスが実行されていないことを確認します。

    # systemctl stop mariadb.service
  • データディレクトリーが空であることを確認します。
  • Mariabackup のユーザーは、RELOADLOCK TABLES、および REPLICATION CLIENT の権限が必要です。

手順

  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

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

MariaDB データファイルのファイルシステムバックアップを作成するには、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
  6. バックアップされたデータをバックアップ場所から /var/lib/mysqlディレクトリーに読み込む際は、mysql:mysql/var/lib/mysql 内のすべてのデータの所有者であることを確認してください。

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

7.2.5.5. バックアップソリューションとしてレプリケーションを使用

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

警告

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

7.2.6. MariaDB 10.3 への移行

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

ここでは、MariaDB の RHEL 7 または Red Hat Software Collections バージョンから MariaDB 10.3 への移行を説明します。RHEL 8 内で MariaDB 10.3 から MariaDB 10.5 へ移行する場合は、MariaDB 10.3 から MariaDB 10.5 へのアップグレード を参照してください。

7.2.6.1. RHEL 7 と RHEL 8 のバージョンにおける MariaDB の主な相違点

MariaDB 5.5 および MariaDB 10.3 における最も重要な変更点を以下に示します。

  • 10.1 以降、同期マルチソースクラスターのMariaDB Galera クラスター は、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 に移行するには、MariaDB への移行 の説明に従って複数の設定変更を実行する必要があります。

7.2.6.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 へ直接移行することもできますが、上記の移行ドキュメントに記載されている違いにより必要とされる設定変更をすべて実行する必要があります。

7.2.6.3. mysql_upgrade ユーティリティーを使用したインプレースアップグレード

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

インプレースアップグレードを実行するには、RHEL 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.3

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

注記

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

mysql_upgrade ユーティリティーを使用してアップグレード を実行するには、以下の手順を行います。

前提条件

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

手順

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

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

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

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

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

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

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

7.2.7. MariaDB 10.3 から MariaDB 10.5 へのアップグレード

ここでは、RHEL 8 における MariaDB 10.3 から MariaDB 10.5 への移行について説明します。

7.2.7.1. MariaDB 10.3 と MariaDB 10.5 の主な相違点

MariaDB 10.3MariaDB 10.5 の間の重要な変更点には以下が含まれます。

  • MariaDB はデフォルトで unix_socket 認証プラグインを使用するようになりました。このプラグインを使用すると、ローカルの UNIX ソケットファイルを介して MariaDB に接続する際に、オペレーティングシステムの資格情報を使用できます。
  • MariaDB は、mariadb-* という名前のバイナリーと、mariadb-* バイナリーを指す mysql* シンボリックリンクを追加します。たとえば、mysqladminmysqlaccess、および mysqlshow のシンボリックリンクは、mariadb-adminmariadb-access、および mariadb-show のバイナリーをそれぞれポイントします。
  • 各ユーザーロールに合わせて、SUPER 特権が複数の特権に分割されました。その結果、一部のステートメントで必要な特権が変更されました。
  • 並列のレプリケーションでは、slave_parallel_mode はデフォルトで optimistic に設定されるようになりました。
  • InnoDB ストレージエンジンで、変数のデフォルトが変更されました (innodb_adaptive_hash_indexOFF へ、innodb_checksum_algorithmfull_crc32 へ変更)。
  • MariaDB は、以前使用された readline ライブラリーではなく、MariaDB コマンド履歴 (.mysql_history ファイル) を管理する基盤となるソフトウェアの libedit 実装を使用するようになりました。この変更は、.mysql_history ファイルを直接使用しているユーザーに影響します。.mysql_historyMariaDB または MySQL アプリケーションによって管理されるファイルであるため、ユーザーは直接ファイルでは機能しないことに注意してください。人間が判読可能な外観は偶然です。

    注記

    セキュリティーを強化するために、履歴ファイルの維持を考慮することができます。コマンド履歴の記録を無効にするには、以下を実行します。

    1. 存在する場合は、.mysql_history ファイルを削除します。
    2. 以下のいずれかの方法を使用します。

      • MYSQL_HISTFILE 変数を /dev/null に設定し、これをシェルの起動ファイルに追加します。
      • .mysql_history ファイルを /dev/null へのシンボリックリンクに変更します。

        $ ln -s /dev/null $HOME/.mysql_history

MariaDB Galera クラスター がバージョン 4 にアップグレードされ、以下の主な変更点が加えられました。

  • Galera は、サイズ制限なしのトランザクションの複製をサポートする、新しいストリーミングレプリケーション機能を追加します。ストリーミングレプリケーションの実行時に、クラスターは小さなフラグメントでトランザクションを複製します。
  • Galera が Global Transaction ID (GTID) に完全に対応するようになりました。
  • /etc/my.cnf.d/galera.cnf ファイルの wsrep_on オプションのデフォルト値が 1 から 0 に変更され、エンドユーザーが必要な追加オプションを設定せずに wsrep レプリケーションを開始できないようにします。

MariaDB 10.5 の PAM プラグインへの変更には、以下が含まれます。

  • MariaDB 10.5 は、PAM (Pluggable Authentication Modules) プラグインの新バージョンを追加します。PAM プラグインバージョン 2.0 は、個別の setuid root ヘルパーバイナリーを使用して PAM 認証を実行します。これにより、MariaDB が追加の PAM モジュールを使用できるようになります。
  • ヘルパーバイナリーは、mysql グループのユーザーによってのみ実行できます。デフォルトでは、グループには mysql ユーザーのみが含まれます。Red Hat では、このヘルパーユーティリティーを介してスロットルまたはログの記録をせずにパスワード推測攻撃を防ぐために、管理者が mysql グループにユーザーをさらに追加しないことを推奨しています。
  • MariaDB 10.5 では、プラグ可能な認証モジュール (PAM) プラグインとその関連ファイルが新しいパッケージ mariadb-pam に移動しました。したがって、MariaDB に PAM 認証を使用しないシステムに、新しい setuid root バイナリーが導入されることはありません。
  • mariadb-pam パッケージには、両方の PAM プラグインバージョンが含まれています。バージョン 2.0 はデフォルトで、バージョン 1.0 は auth_pam_v1 共有オブジェクトライブラリーとして利用できます。
  • MariaDB サーバーでは、mariadb-pam パッケージはデフォルトでインストールされません。MariaDB 10.5 で PAM 認証プラグインを利用できるようにするには、mariadb-pam パッケージを手動でインストールします。

7.2.7.2. RHEL 8 バージョンの MariaDB 10.3 から MariaDB 10.5 へのアップグレード

この手順では、yum および mariadb-upgrade ユーティリティーを使用して、mariadb:10.3 モジュールストリームから mariadb:10.5 モジュールストリームにアップグレードする方法を説明します。

mariadb-upgrade ユーティリティーは、mariadb-server-utils サブパッケージにより提供され、mariadb-server パッケージの依存関係としてインストールされます。

前提条件

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

手順

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

    # systemctl stop mariadb.service
  2. 以下のコマンドを実行して、後続のストリームに切り替えるためのシステムの準備が整っているかどうかを判断します。

    # yum distro-sync

    このコマンドは、Nothing to do.Complete! のメッセージで終了する必要があります。詳細は、後続のストリームへの切り替え を参照してください。

  3. システムで mariadb モジュールをリセットします。

    # yum module reset mariadb
  4. 新しい mariadb:10.5 モジュールストリームを有効にします。

    # yum module enable mariadb:10.5
  5. インストール済みパッケージを同期し、ストリーム間の変更を実行します。

    # yum distro-sync

    これにより、インストールされている MariaDB パッケージがすべて更新されます。

  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
重要

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

7.2.8. Galera で MariaDB を複製する

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

7.2.8.1. MariaDB Galera クラスターの概要

Galera レプリケーションは、複数の MariaDB サーバーで設定される同期マルチソース MariaDB Galera クラスター の作成に基づいています。レプリカが通常読み取り専用である従来のプライマリー/レプリカ設定とは異なり、MariaDB Galera クラスターのノードはすべて書き込み可能にすることができます。

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

MariaDB Galera クラスター の主な機能は以下のとおりです。

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

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

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

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

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

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

MariaDB Galera クラスター を構築するには、システムに以下のパッケージをインストールする必要があります。

  • mariadb-server-galera: MariaDB Galera クラスター のサポートファイルとスクリプトが含まれます。
  • mariadb-server: MariaDB アップストリームがパッチを適用し、書き込みセットレプリケーション API (wsrep API) を組み込みます。この API は、Galera レプリケーションと MariaDB との間のインターフェイスを提供します。
  • galera: MariaDB アップストリームがパッチを適用し、MariaDB の完全サポートを追加します。galera パッケージには、以下の内容が含まれます。

    • Galera Replication Library は、レプリケーション機能全体を提供します。
    • Galera Arbitrator ユーティリティーは、スプリットブレインのシナリオで投票に参加するクラスターメンバーとして使用できます。ただし、Galera Arbitrator は実際のレプリケーションには参加できません。
    • Galera Arbitrator ユーティリティーのデプロイに使用される Galera Systemd service および Galera wrapper script。RHEL 8 の MariaDB 10.3 および MariaDB 10.5 には、Red Hat バージョンの garbd systemd サービスと、/usr/lib/systemd/system/garbd.service ファイルおよび /usr/sbin/garbd-wrapper ファイルにそれぞれある galera パッケージのラッパースクリプトが含まれています。RHEL 8.6 以降、MariaDB 10.3 および MariaDB 10.5 は、/usr/share/doc/galera/garb-systemd および /usr/share/doc/galera/garbd.service にあるこれらのファイルのアップストリームバージョンも提供するようになりました。

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

前提条件

  • mariadb モジュールからストリーム (バージョン) を選択し、galera プロファイルを指定して、MariaDB Galera クラスター パッケージをインストールします。以下に例を示します。

    # yum module install mariadb:10.3/galera

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

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

      mariadb-server-galera パッケージが mariadb-server パッケージおよび galera パッケージを依存関係としてプルします。

      MariaDB Galera Cluster をビルドするためにインストールする必要があるパッケージについては、MariaDB クラスターをビルドするためのコンポーネント を参照してください。

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

    デフォルト設定は、/etc/my.cnf.d/galera.cnf ファイルで配布されます。

    MariaDB Galera クラスター をデプロイする前に、以下の文字列で開始するように、すべてのノードの /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

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

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

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

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

手順

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

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

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

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

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

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

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

クラスターを再起動するには、MariaDB Galera クラスターの設定の説明に従って、最初のノードをブートストラップします。

警告

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

7.2.9. MariaDB クライアントアプリケーションの開発

Red Hat では、MariaDB クライアントライブラリーに対して MariaDB クライアントアプリケーションを開発することを推奨します。

MariaDB クライアントライブラリーに対してアプリケーションを構築するために必要な開発ファイルとプログラムは、mariadb-connector-c-devel パッケージによって提供されます。

直接ライブラリー名を使用する代わりに、mariadb-connector-c-devel パッケージで配布されている mariadb_config プログラムを使用します。このプログラムは、正しいビルドフラグが返されることを保証します。