7.2. MariaDB の使用


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

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

7.2.1. MariaDB のインストール

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

  • MariaDB 10.3
  • MariaDB 10.5 - RHEL 8.4 以降で利用できます。
  • MariaDB 10.11 - RHEL 8.10 以降で利用可能
注記

設計上、同じモジュールの複数のバージョン (ストリーム) を並行してインストールすることはできません。したがって、mariadb モジュールから利用可能なストリームのいずれかを選択する必要があります。コンテナー内では、別々のバージョンの MariaDB データベースサーバーを使用できます。コンテナー内で複数の MariaDB バージョンを実行する を参照してください。

RPM パッケージが競合しているため、RHEL 8 では MariaDB および MySQL データベースサーバーを同時にインストールすることはできません。コンテナー内では、MariaDB および MySQL データベースサーバーを並行して使用できます。コンテナー内で複数の MySQL および MariaDB バージョンを実行する を参照してください。

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

手順

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

    # yum module install mariadb:10.3/server
    Copy to Clipboard Toggle word wrap
  2. mariadb サービスを起動します。

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

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

    $ mysql_secure_installation
    Copy to Clipboard Toggle word wrap

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

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

      注記

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

重要

RHEL 8 内で以前の mariadb ストリームからアップグレードする場合は、新しいストリームへの切り替え および MariaDB 10.3 から MariaDB 10.5 へのアップグレード または MariaDB 10.5 から MariaDB 10.11 へのアップグレード の両方の手順に従ってください。

7.2.2. コンテナー内で複数の MariaDB バージョンを実行する

同じホスト上で別々のバージョンの MariaDB を実行するには、コンテナー内で実行してください。同じモジュールの複数のバージョン (ストリーム) を並行してインストールすることはできないためです。

前提条件

  • container-tools モジュールがインストールされている。

手順

  1. Red Hat カスタマーポータルアカウントを使用して、registry.redhat.io レジストリーに認証します。

    # podman login registry.redhat.io
    Copy to Clipboard Toggle word wrap

    すでにコンテナーレジストリーにログインしている場合は、このステップをスキップしてください。

  2. コンテナー内で MariaDB 10.3 を 実行します。

    $ podman run -d --name <container_name> -e MYSQL_ROOT_PASSWORD=<mariadb_root_password> -p <host_port_1>:3306 rhel8/mariadb-103
    Copy to Clipboard Toggle word wrap

    このコンテナーイメージの使用方法の詳細は、Red Hat Ecosystem Catalog を 参照してください。

  3. コンテナー内で MariaDB 10.5 を実行します。

    $ podman run -d --name <container_name> -e MYSQL_ROOT_PASSWORD=<mariadb_root_password> -p <host_port_2>:3306 rhel8/mariadb-105
    Copy to Clipboard Toggle word wrap

    このコンテナーイメージの使用方法の詳細は、Red Hat Ecosystem Catalog を 参照してください。

  4. コンテナー内で MariaDB 10.11 を実行します。

    $ podman run -d --name <container_name> -e MYSQL_ROOT_PASSWORD=<mariadb_root_password> -p <host_port_3>:3306 rhel8/mariadb-1011
    Copy to Clipboard Toggle word wrap

    このコンテナーイメージの使用方法の詳細は、Red Hat Ecosystem Catalog を 参照してください。

    注記

    2 つのデータベースサーバーのコンテナー名とホストポートが異なっている必要があります。

  5. クライアントがネットワーク上のデータベースサーバーにアクセスできるように、ファイアウォールでホストポートを開きます。

    # firewall-cmd --permanent --add-port={<host_port_1>/tcp,<host_port_2>/tcp,<host_port_3>/tcp...}
    # firewall-cmd --reload
    Copy to Clipboard Toggle word wrap

検証

  1. 実行中のコンテナーに関する情報を表示します。

    $ podman ps
    Copy to Clipboard Toggle word wrap
  2. データベースサーバーに接続し、root としてログインします。

    # mysql -u root -p -h localhost -P <host_port> --protocol tcp
    Copy to Clipboard Toggle word wrap

7.2.3. 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
    Copy to Clipboard Toggle word wrap

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

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

7.2.4.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/
    Copy to Clipboard Toggle word wrap
  2. MariaDB サーバーがファイルを読み込めるように、CA およびサーバー証明書にパーミッションを設定します。

    # chmod 644 /etc/pki/tls/certs/server.example.com.crt.pem /etc/pki/tls/certs/ca.crt.pem
    Copy to Clipboard Toggle word wrap

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

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

    # mv <path>/server.example.com.key.pem /etc/pki/tls/private/
    Copy to Clipboard Toggle word wrap
  4. サーバーの秘密鍵にセキュアなパーミッションを設定します。

    # chmod 640 /etc/pki/tls/private/server.example.com.key.pem
    # chgrp mysql /etc/pki/tls/private/server.example.com.key.pem
    Copy to Clipboard Toggle word wrap

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

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

    #  restorecon -Rv /etc/pki/tls/
    Copy to Clipboard Toggle word wrap

7.2.4.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
      Copy to Clipboard Toggle word wrap
    2. 証明書失効リスト (CRL) がある場合は、それを使用するように MariaDB サーバーを設定します。

      ssl_crl = /etc/pki/tls/certs/example.crl.pem
      Copy to Clipboard Toggle word wrap
    3. 必要に応じて、MariaDB 10.5.2 以降を実行する場合は、暗号化せずに接続を拒否できます。この機能を有効にするには、以下を追加します。

      require_secure_transport = on
      Copy to Clipboard Toggle word wrap
    4. 必要に応じて、MariaDB 10.4.6 以降を実行する場合は、サーバーが対応する TLS バージョンを設定できます。たとえば、TLS 1.2 および TLS 1.3 をサポートするには、以下を追加します。

      tls_version = TLSv1.2,TLSv1.3
      Copy to Clipboard Toggle word wrap

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

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

    # systemctl restart mariadb.service
    Copy to Clipboard Toggle word wrap

検証

トラブルシューティングを簡素化するには、ローカルクライアントが TLS 暗号化を使用するように設定する前に、MariaDB サーバーで以下の手順を実行します。

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

    # mysql -u root -p -e "SHOW GLOBAL VARIABLES LIKE 'have_ssl';"
    +---------------+-----------------+
    | Variable_name | Value           |
    +---------------+-----------------+
    | have_ssl      | YES             |
    +---------------+-----------------+
    Copy to Clipboard Toggle word wrap

    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 |
    +---------------+-----------------+
    Copy to Clipboard Toggle word wrap

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

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

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

前提条件

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

手順

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

    # mysql -u root -p -h server.example.com
    Copy to Clipboard Toggle word wrap

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

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

    MariaDB [(none)]> ALTER USER 'example'@'%' REQUIRE SSL;
    Copy to Clipboard Toggle word wrap

検証

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

    # mysql -u example -p -h server.example.com --ssl
    ...
    MariaDB [(none)]>
    Copy to Clipboard Toggle word wrap

    エラーが表示されず、インタラクティブな 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)
    Copy to Clipboard Toggle word wrap

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

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

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

7.2.5.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/
      Copy to Clipboard Toggle word wrap
    2. すべてのユーザーが CA 証明書ファイルを読み取りできるようにするパーミッションを設定します。

      # chmod 644 /etc/pki/ca-trust/source/anchors/ca.crt.pem
      Copy to Clipboard Toggle word wrap
    3. CA 信頼データベースを再構築します。

      # update-ca-trust
      Copy to Clipboard Toggle word wrap
  2. 以下の内容で /etc/my.cnf.d/mariadb-client-tls.cnf ファイルを作成します。

    [client-mariadb]
    ssl
    ssl-verify-server-cert
    Copy to Clipboard Toggle word wrap

    これらの設定は、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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

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

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

論理バックアップ

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

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

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

物理バックアップ

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

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

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

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

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

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

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

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

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

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

手順

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

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

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

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

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

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

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

    # mysql db_name < backup-file.sql
    Copy to Clipboard Toggle word wrap
    注記

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

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

    $ mysqldump --help
    Copy to Clipboard Toggle word wrap

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

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

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

前提条件

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

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

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

手順

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

    $ mariabackup --backup --target-dir <backup_directory> --user <backup_user> --password <backup_passwd>
    Copy to Clipboard Toggle word wrap

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

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

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

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

      [xtrabackup]
      user=myuser
      password=mypassword
      Copy to Clipboard Toggle word wrap
    3. バックアップを実行します。

      $ mariabackup --backup --target-dir <backup_directory>
      Copy to Clipboard Toggle word wrap

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

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

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

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

前提条件

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

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

手順

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

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

      $ mariabackup --copy-back --target-dir=/var/mariadb/backup/
      Copy to Clipboard Toggle word wrap
    • データを復元し、元のバックアップファイルを削除するには、--move-back オプションを使用します。

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

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

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

    # chown -R mysql:mysql /var/lib/mysql/
    Copy to Clipboard Toggle word wrap
  3. mariadb サービスを起動します。

    # systemctl start mariadb.service
    Copy to Clipboard Toggle word wrap

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

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

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

手順

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

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

    # cp -r /var/lib/mysql /backup-location
    Copy to Clipboard Toggle word wrap
  3. オプション: 設定ファイルを必要な場所にコピーします。

    # cp -r /etc/my.cnf /etc/my.cnf.d /backup-location/configuration
    Copy to Clipboard Toggle word wrap
  4. オプション: ログファイルを必要な場所にコピーします。

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

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

    # chown -R mysql:mysql /var/lib/mysql
    Copy to Clipboard Toggle word wrap

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

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

警告

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

7.2.7. MariaDB 10.3 への移行

RHEL 7 には、MySQL データベースファミリーからのサーバーのデフォルトの実装として、MariaDB 5.5 が同梱されています。新しいバージョンの MariaDB データベースサーバーは、RHEL 7 の Software Collections として利用できます。RHEL 8 では、MariaDB 10.3MariaDB 10.5MariaDB 10.11、および 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 へのアップグレードを 参照してください。

RHEL 8 内で MariaDB 10.5 から MariaDB 10.11 に移行する場合は、MariaDB 10.5 から MariaDB 10.11 へのアップグレードを 参照してください。

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

MariaDB 5.5MariaDB 10.3 の間の最も重要な変更点は次のとおりです。

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

    詳細は、XtraDB ではなく InnoDB を 参照してください。

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

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

7.2.7.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.7.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
    Copy to Clipboard Toggle word wrap
  2. データのコピー時に、mariadb サービスがソースおよびターゲットのシステムで稼働していないことを確認します。

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

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

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

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

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

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

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

7.2.8.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
        Copy to Clipboard Toggle word wrap

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 で、Pluggable Authentication Modules (PAM) プラグインの新しいバージョンが追加されました。PAM プラグインバージョン 2.0 は、個別の setuid root ヘルパーバイナリーを使用して PAM 認証を実行します。これにより、MariaDB が追加の PAM モジュールを使用できるようになります。
  • ヘルパーバイナリーは、mysql グループのユーザーによってのみ実行できます。デフォルトでは、グループには mysql ユーザーのみが含まれます。Red Hat では、このヘルパーユーティリティーを介してスロットルまたはログの記録をせずにパスワード推測攻撃を防ぐために、管理者が mysql グループにユーザーをさらに追加しないことを推奨しています。
  • MariaDB 10.5 で、Pluggable Authentication Modules (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.8.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
    Copy to Clipboard Toggle word wrap
  2. 以下のコマンドを実行して、後続のストリームに切り替えるためのシステムの準備が整っているかどうかを判断します。

    # yum distro-sync
    Copy to Clipboard Toggle word wrap

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

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

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

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

    # yum distro-sync
    Copy to Clipboard Toggle word wrap

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

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

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

      # systemctl start mariadb.service
      Copy to Clipboard Toggle word wrap
    • Galera クラスターノードをアップグレードする場合:

      # galera_new_cluster
      Copy to Clipboard Toggle word wrap

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

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

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

      # mariadb-upgrade
      Copy to Clipboard Toggle word wrap
    • Galera クラスターノードをアップグレードする場合:

      # mariadb-upgrade --skip-write-binlog
      Copy to Clipboard Toggle word wrap
重要

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

7.2.9. MariaDB 10.5 から MariaDB 10.11 へのアップグレード

この部分では、RHEL 8 内での MariaDB 10.5 から MariaDB 10.11 への移行について説明します。

7.2.9.1. MariaDB 10.5 と MariaDB 10.11 の主な相違点

MariaDB 10.5MariaDB 10.11 の間の重要な変更点は次のとおりです。

  • 新しい sys_schema 機能。これは、データベースの使用状況に関する情報を提供するビュー、関数、およびプロシージャーのコレクションです。
  • CREATE TABLEALTER TABLERENAME TABLEDROP TABLEDROP DATABASE、および関連するデータ定義言語 (DDL) ステートメントがアトミックになりました。ステートメントは完全に完結している必要があります。そうでない場合、変更が元に戻されます。DROP TABLE を使用して複数のテーブルを削除する場合、テーブルの全リストではなく、個々のドロップのみがアトミックであることに注意してください。
  • 新しい GRANT … TO PUBLIC 権限が利用可能になりました。
  • SUPER 権限と READ ONLY ADMIN 権限が分離されました。
  • 新しい UUID データベースデータ型に、ユニバーサル一意識別子を格納できるようになりました。
  • MariaDB が Secure Socket Layer (SSL) プロトコルバージョン 3 をサポートするようになりました。
  • MariaDB サーバーの起動に正しく設定された SSL が必要になりました。以前は、SSL の設定が誤っている場合、MariaDB は SSL を暗黙的に無効にし、セキュアでない接続を使用していました。
  • MariaDBnatural_sort_key() 関数により自然なソート順序をサポートするようになりました。
  • 新しい SFORMAT 関数を任意のテキスト書式設定に使用できるようになりました。
  • utf8 文字セット (および関連する照合順序) が、デフォルトで utf8mb3 のエイリアスになりました。
  • MariaDB は、Unicode Collation Algorithm (UCA) 14 の照合順序をサポートしています。
  • MariaDBsystemd ソケットのアクティベーションファイルが /usr/share/ ディレクトリーで利用できるようになりました。アップストリームとは異なり、これらのファイルは RHEL のデフォルト設定の一部ではないことに注意してください。
  • エラーメッセージに、MySQL ではなく MariaDB 文字列が含まれるようになりました。
  • エラーメッセージが中国語で利用できるようになりました。
  • デフォルトの logrotate ファイルが大幅に変更されました。MariaDB 10.11 に移行する前に設定を確認してください。
  • MariaDB および MySQL クライアントの場合、コマンドラインで指定した接続プロパティー (例: --port=3306) によって、クライアントとサーバー間の通信のプロトコルタイプ (tcpsocketpipememory など) が強制されるようになりました。たとえば、以前は MariaDB クライアントが UNIX ソケットを介して接続した場合、指定したポートが無視されていました。

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

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

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

前提条件

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

手順

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

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

    # yum distro-sync
    Copy to Clipboard Toggle word wrap

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

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

    # yum module reset mariadb
    Copy to Clipboard Toggle word wrap
  4. 新しい mariadb:10.11 モジュールストリームを有効にします。

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

    # yum distro-sync
    Copy to Clipboard Toggle word wrap

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

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

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

      # systemctl start mariadb.service
      Copy to Clipboard Toggle word wrap
    • Galera クラスターノードをアップグレードする場合:

      # galera_new_cluster
      Copy to Clipboard Toggle word wrap

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

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

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

      # mariadb-upgrade
      Copy to Clipboard Toggle word wrap
    • Galera クラスターノードをアップグレードする場合:

      # mariadb-upgrade --skip-write-binlog
      Copy to Clipboard Toggle word wrap
重要

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

7.2.10. Galera で MariaDB を複製する

Red Hat Enterprise Linux 8 の Galera ソリューションを使用して MariaDB データベースを複製できます。

7.2.10.1. MariaDB Galera Cluster の概要

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

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

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

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

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

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

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

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

7.2.10.2. MariaDB Galera Cluster を構築するためのコンポーネント

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

  • 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.3MariaDB 10.5、および MariaDB 10.11 には、それぞれ /usr/lib/systemd/system/garbd.service ファイルと /usr/sbin/garbd-wrapper ファイルに、Red Hat バージョンの garbd systemd サービスと galera パッケージのラッパースクリプトが含まれています。RHEL 8.6 以降、RHEL とともに配布される MariaDB、/usr/share/doc/galera/garb-systemd および /usr/share/doc/galera/garbd.service にあるこれらのファイルのアップストリームバージョンも提供します。

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

MariaDB Galera Cluster パッケージをデプロイし、設定を更新できます。新しいクラスターを形成するには、クラスターの最初のノードをブートストラップする必要があります。

前提条件

  • クラスター内のすべてのノードに TLS が設定 されている。
  • すべてのノード上のすべての証明書の Extended Key Usage フィールドが次のように設定されている。

    TLS Web Server Authentication, TLS Web Client Authentication
    Copy to Clipboard Toggle word wrap

手順

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

    # yum module install mariadb:10.3/galera
    Copy to Clipboard Toggle word wrap

    その結果、次のパッケージが依存関係とともにインストールされます。

  2. システムを初めてクラスターに追加する前に、MariaDB サーバーのレプリケーション設定を更新します。デフォルト設定は、/etc/my.cnf.d/galera.cnf ファイルで配布されます。MariaDB Galera クラスター をデプロイする前に、以下の文字列で開始するように、すべてのノードの /etc/my.cnf.d/galera.cnf ファイルに wsrep_cluster_address オプションを設定します。

    gcomm://
    Copy to Clipboard Toggle word wrap
    • 初期ノードでは、wsrep_cluster_address を空のリストとして設定できます。

      wsrep_cluster_address="gcomm://"
      Copy to Clipboard Toggle word wrap
    • その他のすべてのノードに wsrep_cluster_address を設定して、実行中のクラスターに属するノードへのアドレスを追加します。以下に例を示します。

      wsrep_cluster_address="gcomm://10.0.0.10"
      Copy to Clipboard Toggle word wrap

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

  3. /etc/my.cnf.d/galera.cnf 設定ファイルで wsrep_on=1 オプションを設定して、すべてのノードで wsrep API を有効にします。
  4. TLS 鍵と証明書を含む Galera 設定ファイルに wsrep_provider_options 変数を追加します。以下に例を示します。

    wsrep_provider_options="socket.ssl_cert=/etc/pki/tls/certs/source.crt;socket.ssl_key=/etc/pki/tls/private/source.key;socket.ssl_ca=/etc/pki/tls/certs/ca.crt”
    Copy to Clipboard Toggle word wrap
  5. ノードで以下のラッパーを実行して、新規クラスターの最初のノードをブートストラップします。

    # galera_new_cluster
    Copy to Clipboard Toggle word wrap

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

    注記

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

    # galera_new_cluster mariadb@node1
    Copy to Clipboard Toggle word wrap
  6. 各ノードで次のコマンドを実行して、その他のノードをクラスターに接続します。

    # systemctl start mariadb.service
    Copy to Clipboard Toggle word wrap

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

7.2.10.4. MariaDB Galera クラスターのステータスを確認する

MariaDB Galera クラスターの健全性、パフォーマンス、同期を監視し、確保することが重要です。そのためには、各ノードのステータス変数をクエリーして、ノードとクラスターを監視できます。

MariaDB Galera クラスターのステータスを確認するには、次のクエリーを使用します。

  • クラスター内のノードの数を表示します。

    # mysql -u root -p -e 'show status like "wsrep_cluster_size";'
    +--------------------+-------+
    | Variable_name      | Value |
    +--------------------+-------+
    | wsrep_cluster_size | 4     |
    +--------------------+-------+
    Copy to Clipboard Toggle word wrap
  • ノードのクラスターコンポーネントのステータスを表示します。

    # mysql -u root -p -e 'show status like "wsrep_cluster_status";'
    +----------------------+---------+
    | Variable_name        | Value   |
    +----------------------+---------+
    | wsrep_cluster_status | Primary |
    +----------------------+---------+
    Copy to Clipboard Toggle word wrap

    wsrep_cluster_status 変数の値は、現在のノードが属するクラスターコンポーネントのステータスを示します。以下の値が使用できます。

    • Primary: クラスターは正常に機能しています。定足数が満たされています。正常なクラスターでは、すべてのノードが Primary を報告します。
    • Non-primary: ノードはクラスターのプライマリーコンポーネントへの接続を失い、アクティブクラスターの一部ではなくなりました。ただし、ノードは引き続き読み取りクエリーを処理できますが、書き込み操作を処理することはできません。
    • Disconnected: ノードはどのクラスターコンポーネントにも接続されていません。その結果、クエリーを受け入れることができず、データはレプリケートされません。
  • ノードのステータスを表示します。

    # mysql -u root -p -e 'show status like "wsrep_local_state_comment";'
    +---------------------------+--------+
    | Variable_name             | Value  |
    +---------------------------+--------+
    | wsrep_local_state_comment | Synced |
    +---------------------------+--------+
    Copy to Clipboard Toggle word wrap

    wsrep_local_state_comment 変数の頻繁に使用される値は次のとおりです。

    • Synced: ノードはクラスター内で完全に同期されており、レプリケーションにアクティブに参加しています。
    • Desynced: ノードは引き続きクラスターの一部ですが、状態の遷移で主にビジー状態です。
    • Joining: ノードはクラスターへの参加処理中です。
    • Joined: ノードはクラスターに正常に参加しました。クラスターから書き込みセットを受信して適用できます。
    • Donor: ノードは現在、State Snapshot Transfer (SST) を提供しています。新しいノードが参加して完全な状態の遷移が必要な場合、クラスターは既存のノードを選択して必要なデータを送信します。
  • ノードがクラスターからの書き込みセットを受け入れるかどうかを確認します。

    # mysql -u root -p -e 'show status like "wsrep_ready";'
    +---------------+-------+
    | Variable_name | Value |
    +---------------+-------+
    | wsrep_ready   | ON    |
    +---------------+-------+
    Copy to Clipboard Toggle word wrap

    wsrep_ready 変数が ON の場合、ノードはコンポーネントを正常に初期化し、クラスターに接続されています。さらに、ノードは同期されているか、クエリーを処理できる状態に達しています。

  • ノードが他のホストとネットワーク接続されているか確認します。

    # mysql -u root -p -e 'show status like "wsrep_connected";'
    +-----------------+-------+
    | Variable_name   | Value |
    +-----------------+-------+
    | wsrep_connected | ON    |
    +-----------------+-------+
    Copy to Clipboard Toggle word wrap

    ON 値は、ノードがクラスター内の少なくとも 1 つのメンバーに接続されていることを意味します。

  • 最後の FLUSH STATUS コマンド以降、またはサーバーの起動以降の書き込みセットのローカル受信キューの平均サイズを表示します。

    # mysql -u root -p -e 'show status like "wsrep_local_recv_queue_avg";'
    +----------------------------+-------+
    | Variable_name              | Value |
    +----------------------------+-------+
    | wsrep_local_recv_queue_avg | 0.012 |
    +----------------------------+-------+
    Copy to Clipboard Toggle word wrap

    0 に近い値は理想的な状態であり、ノードが書き込みセットを受信するとそれを適用し続けることを示します。値が継続的に高い、または増加している場合は、ディスク I/O が遅いなどのパフォーマンスのボトルネックが発生している可能性があります。

  • フロー制御ステータスを表示します。

    # mysql -u root -p -e 'show status like "wsrep_flow_control_paused";'
    +---------------------------+-------+
    | Variable_name             | Value |
    +---------------------------+-------+
    | wsrep_flow_control_paused | 0     |
    +---------------------------+-------+
    Copy to Clipboard Toggle word wrap

    この変数は、ローカル受信キューがいっぱいでフロー制御がトリガーされたために、ノードが一時停止され、新しい着信トランザクションを処理できない時間の割合を表します。値が 0 に近い場合、ノードはレプリケーションワークロードを効率的に継続していることを示します。値が 1.0 に近づくと、ノードが書き込みセットの適用で頻繁または継続的に問題に遭遇し、クラスターのボトルネックになる可能性があることを意味します。

    ノードが頻繁に一時停止する場合は、/etc/my.cnf.d/galera.cnf ファイルの wsrep_slave_threads パラメーターを調整できます。

  • ノードが並列に適用できる最小シーケンス番号と最大シーケンス番号間の平均距離を表示します。

    # mysql -u root -p -e 'show status like "wsrep_cert_deps_distance";'
    +--------------------------+-------+
    | Variable_name            | Value |
    +--------------------------+-------+
    | wsrep_cert_deps_distance | 1     |
    +--------------------------+-------+
    Copy to Clipboard Toggle word wrap

    値が大きいほど、並列度が高くなります。これは、/etc/my.cnf.d/galera.cnf ファイルの wsrep_slave_threads パラメーターで使用できる最適な値です。

7.2.10.5. 新規ノードの MariaDB Galera Cluster への追加

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

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

手順

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

    [mariadb]
    wsrep_cluster_address="gcomm://192.168.0.1"
    Copy to Clipboard Toggle word wrap

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

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

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

7.2.10.6. MariaDB Galera Cluster の再起動

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

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

警告

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

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

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

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

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

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat