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 9.4 以降で利用可能
設計上、同じモジュールの複数のバージョン (ストリーム) を並行してインストールすることはできません。したがって、mariadb
モジュールから利用可能なストリームのいずれかを選択する必要があります。コンテナー内では、別々のバージョンの MariaDB データベースサーバーを使用できます。コンテナー内で複数の MariaDB バージョンを実行する を参照してください。
RPM パッケージが競合しているため、RHEL 8 では MariaDB および MySQL データベースサーバーを同時にインストールすることはできません。コンテナー内では、MariaDB および MySQL データベースサーバーを並行して使用できます。コンテナー内で複数の MySQL および MariaDB バージョンを実行する を参照してください。
MariaDB をインストールするには、以下の手順を行います。
手順
mariadb
モジュールからストリーム (バージョン) を選択し、server
プロファイルを指定して MariaDB サーバーパッケージをインストールします。以下に例を示します。# yum module install mariadb:10.3/server
mariadb
サービスを起動します。# systemctl start mariadb.service
mariadb
サービスが、システムの起動時に起動するようにします。# systemctl enable mariadb.service
MariaDB 10.3 に推奨: MariaDB をインストールする際のセキュリティーを向上させるには、次のコマンドを実行します。
$ mysql_secure_installation
このコマンドは、完全にインタラクティブなスクリプトを起動して、プロセスの各ステップのプロンプトを表示します。このスクリプトを使用すると、次の方法でセキュリティーを改善できます。
- 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
モジュールがインストールされている。
手順
Red Hat カスタマーポータルアカウントを使用して、
registry.redhat.io
レジストリーに認証します。# podman login registry.redhat.io
すでにコンテナーレジストリーにログインしている場合は、このステップをスキップしてください。
コンテナー内で MariaDB 10.11 を実行します。
$ podman run -d --name <container_name> -e MYSQL_ROOT_PASSWORD=<mariadb_root_password> -p <host_port_1>:3306 rhel8/mariadb-103
このコンテナーイメージを使用する方法の詳細は、Red Hat Ecosystem Catalog を参照してください。
コンテナー内で MariaDB 10.5 を実行します。
$ podman run -d --name <container_name> -e MYSQL_ROOT_PASSWORD=<mariadb_root_password> -p <host_port_2>:3306 rhel8/mariadb-105
このコンテナーイメージを使用する方法の詳細は、Red Hat Ecosystem Catalog を参照してください。
コンテナー内で MariaDB 10.11 を実行します。
$ podman run -d --name <container_name> -e MYSQL_ROOT_PASSWORD=<mariadb_root_password> -p <host_port_3>:3306 rhel8/mariadb-1011
このコンテナーイメージを使用する方法の詳細は、Red Hat Ecosystem Catalog を参照してください。
注記2 つのデータベースサーバーのコンテナー名とホストポートが異なっている必要があります。
クライアントがネットワーク上のデータベースサーバーにアクセスできるように、ファイアウォールでホストポートを開きます。
# firewall-cmd --permanent --add-port={<host_port_1>/tcp,<host_port_2>/tcp,<host_port_3>/tcp...} # firewall-cmd --reload
検証
実行中のコンテナーに関する情報を表示します。
$ podman ps
データベースサーバーに接続し、root としてログインします。
# mysql -u root -p -h localhost -P <host_port> --protocol tcp
7.2.3. MariaDB の設定
MariaDB サーバーをネットワーク用に設定するには、以下の手順に従います。
手順
/etc/my.cnf.d/mariadb-server.cnf
ファイルの[mysqld]
セクションを編集します。以下の設定ディレクティブを設定できます。bind-address
: サーバーがリッスンするアドレスです。設定可能なオプションは以下のとおりです。- ホスト名
- IPv4 アドレス
- IPv6 アドレス
skip-networking
: サーバーが TCP/IP 接続をリッスンするかどうかを制御します。以下の値が使用できます。- 0 - すべてのクライアントをリッスンする
- 1 - ローカルクライアントのみをリッスンする
-
port
: MariaDB が TCP/IP 接続をリッスンするポート。
mariadb
サービスを再起動します。# systemctl restart mariadb.service
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 のドキュメントを参照してください。
-
サーバーの秘密鍵:
手順
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/
MariaDB サーバーがファイルを読み込めるように、CA およびサーバー証明書にパーミッションを設定します。
# chmod 644 /etc/pki/tls/certs/server.example.com.crt.pem /etc/pki/tls/certs/ca.crt.pem
証明書は、セキュアな接続が確立される前は通信の一部であるため、任意のクライアントは認証なしで証明書を取得できます。そのため、CA およびサーバーの証明書ファイルに厳密なパーミッションを設定する必要はありません。
サーバーの秘密鍵を
/etc/pki/tls/private/
ディレクトリーに保存します。# mv <path>/server.example.com.key.pem /etc/pki/tls/private/
サーバーの秘密鍵にセキュアなパーミッションを設定します。
# chmod 640 /etc/pki/tls/private/server.example.com.key.pem # chgrp mysql /etc/pki/tls/private/server.example.com.key.pem
承認されていないユーザーが秘密鍵にアクセスできる場合は、MariaDB サーバーへの接続は安全ではなくなります。
SELinux コンテキストを復元します。
# restorecon -Rv /etc/pki/tls/
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) フィールドは、サーバーのホスト名と一致します。
手順
/etc/my.cnf.d/mariadb-server-tls.cnf
ファイルを作成します。以下の内容を追加して、秘密鍵、サーバー、および 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
証明書失効リスト (CRL) がある場合は、それを使用するように MariaDB サーバーを設定します。
ssl_crl = /etc/pki/tls/certs/example.crl.pem
必要に応じて、MariaDB 10.5.2 以降を実行する場合は、暗号化せずに接続を拒否できます。この機能を有効にするには、以下を追加します。
require_secure_transport = on
必要に応じて、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 をサポートします。
mariadb
サービスを再起動します。# systemctl restart mariadb
検証
トラブルシューティングを簡素化するには、ローカルクライアントが TLS 暗号化を使用するように設定する前に、MariaDB サーバーで以下の手順を実行します。
MariaDB で TLS 暗号化が有効になっていることを確認します。
# mysql -u root -p -e "SHOW GLOBAL VARIABLES LIKE 'have_ssl';" +---------------+-----------------+ | Variable_name | Value | +---------------+-----------------+ | have_ssl | YES | +---------------+-----------------+
have_ssl
変数がyes
に設定されている場合、TLS 暗号化が有効になります。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.4.3. 特定のユーザーアカウントに TLS で暗号化された接続を要求する
機密データにアクセスできるユーザーは、ネットワーク上で暗号化されていないデータ送信を回避するために、常に TLS で暗号化された接続を使用する必要があります。
すべての接続にセキュアなトランスポートが必要なサーバーで設定できない場合は (require_secure_transport = on
)、TLS 暗号化を必要とするように個別のユーザーアカウントを設定します。
前提条件
- MariaDB サーバーで TLS サポートが有効になっている。
- セキュアなトランスポートを必要とするように設定するユーザーが存在する。
- クライアントは、サーバーの証明書を発行した CA 証明書を信頼している。
手順
管理ユーザーとしてMariaDB サーバーに接続します。
# mysql -u root -p -h server.example.com
管理ユーザーがリモートでサーバーにアクセスする権限を持たない場合は、MariaDB サーバーでコマンドを実行し、
localhost
に接続します。REQUIRE SSL
句を使用して、ユーザーが TLS 暗号化接続を使用して接続する必要があるよう強制します。MariaDB [(none)]> ALTER USER 'example'@'%' REQUIRE SSL;
検証
TLS 暗号化を使用して、
example
ユーザーとしてサーバーに接続します。# mysql -u example -p -h server.example.com --ssl ... MariaDB [(none)]>
エラーが表示されず、インタラクティブな MariaDB コンソールにアクセスできる場合は、TLS との接続は成功します。
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.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 証明書がクライアントにコピーされています。
手順
RHEL が、サーバー証明書を発行した CA を信頼しない場合は、以下を行います。
CA 証明書を
/etc/pki/ca-trust/source/anchors/
ディレクトリーにコピーします。# cp <path>/ca.crt.pem /etc/pki/ca-trust/source/anchors/
すべてのユーザーが CA 証明書ファイルを読み取りできるようにするパーミッションを設定します。
# chmod 644 /etc/pki/ca-trust/source/anchors/ca.crt.pem
CA 信頼データベースを再構築します。
# update-ca-trust
以下の内容で
/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.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
複数のデータベースを一度にダンプするには、次のコマンドを実行します。
# 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.6.2. Mariabackup ユーティリティーを使用した物理的なオンラインバックアップの実行
Mariabackup は、Percona XtraBackup テクノロジーをベースとしたユーティリティーです。これにより、InnoDB、Aria、および MyISAM テーブルの物理的なオンラインバックアップを実行できます。このユーティリティーは、AppStream リポジトリーから mariadb-backup
パッケージで提供されます。
Mariabackup は、MariaDB サーバーの完全バックアップ機能に対応します。これには、暗号化されたデータおよび圧縮データが含まれます。
前提条件
mariadb-backup
パッケージがシステムにインストールされている。# yum install mariadb-backup
- Mariabackup には、バックアップを実行するユーザーの認証情報を指定する必要があります。認証情報はコマンドラインまたは設定ファイルで指定できます。
-
Mariabackup のユーザーは、
RELOAD
、LOCK TABLES
、およびREPLICATION CLIENT
の権限が必要です。
Mariabackup を使用してデータベースのバックアップを作成するには、以下の手順を行います。
手順
コマンドラインで認証情報を提供する間にバックアップを作成するには、以下を実行します。
$ mariabackup --backup --target-dir <backup_directory> --user <backup_user> --password <backup_passwd>
target-dir
オプションは、バックアップファイルを格納するディレクトリーを定義します。完全バックアップを実行する場合は、ターゲットディレクトリーが空であるか、存在しない必要があります。ユーザー
オプションおよびパスワード
オプションにより、ユーザー名とパスワードを設定できます。設定ファイルに認証情報を設定してバックアップを作成するには、次のコマンドを実行します。
-
/etc/my.cnf.d/
ディレクトリーに設定ファイルを作成します (例:/etc/my.cnf.d/mariabackup.cnf
)。 以下の行を新規ファイルの
[xtrabackup]
セクションまたは[mysqld]
セクションに追加します。[xtrabackup] user=myuser password=mypassword
バックアップを実行します。
$ mariabackup --backup --target-dir <backup_directory>
-
7.2.6.3. Mariabackup ユーティリティーを使用したデータの復元
バックアップが完了したら、mariabackup
コマンドに以下のいずれかのオプションを使用して、バックアップからデータを復元できます。
-
--copy-back
を使用すると、元のバックアップファイルを保持できます。 -
--move-back
は、バックアップファイルをデータディレクトリーに移動し、元のバックアップファイルを削除します。
Mariabackup ユーティリティーを使用してデータを復元するには、以下の手順に従います。
前提条件
mariadb
サービスが実行されていないことを確認します。# systemctl stop mariadb.service
- データディレクトリーが空であることを確認します。
-
Mariabackup のユーザーは、
RELOAD
、LOCK TABLES
、およびREPLICATION CLIENT
の権限が必要です。
手順
mariabackup
コマンドを実行します。データを復元し、元のバックアップファイルを保持するには、
--copy-back
オプションを使用します。$ mariabackup --copy-back --target-dir=/var/mariadb/backup/
データを復元し、元のバックアップファイルを削除するには、
--move-back
オプションを使用します。$ mariabackup --move-back --target-dir=/var/mariadb/backup/
ファイルの権限を修正します。
データベースを復元するとき、Mariabackup は、バックアップのファイルおよびディレクトリーの権限を保持します。ただし、Mariabackup は、ユーザーおよびグループがデータベースを復元する際にファイルをディスクに書き込みます。バックアップの復元後、MariaDB サーバーのユーザーおよびグループ (通常は共に
mysql
) が一致するように、データディレクトリーの所有者の調整が必要になる場合があります。たとえば、ファイルの所有権を
mysql
ユーザーおよびグループに再帰的に変更するには、次のコマンドを実行します。# chown -R mysql:mysql /var/lib/mysql/
mariadb
サービスを起動します。# systemctl start mariadb.service
7.2.6.4. ファイルシステムのバックアップの実行
MariaDB データファイルのファイルシステムバックアップを作成するには、MariaDB データディレクトリーの内容をバックアップ場所にコピーします。
現在の設定またはログファイルのバックアップも作成するには、以下の手順の中から任意の手順を選択します。
手順
mariadb
サービスを停止します。# systemctl stop mariadb.service
データファイルを必要な場所にコピーします。
# cp -r /var/lib/mysql /backup-location
オプション: 設定ファイルを必要な場所にコピーします。
# cp -r /etc/my.cnf /etc/my.cnf.d /backup-location/configuration
オプション: ログファイルを必要な場所にコピーします。
# cp /var/log/mariadb/* /backup-location/logs
mariadb
サービスを起動します。# systemctl start mariadb.service
バックアップされたデータをバックアップ場所から
/var/lib/mysql
ディレクトリーに読み込む際は、mysql:mysql
が/var/lib/mysql
内のすべてのデータの所有者であることを確認してください。# chown -R mysql:mysql /var/lib/mysql
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.3、MariaDB 10.5、MariaDB 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.3 から MariaDB 10.5 へ移行する場合は、MariaDB 10.3 から MariaDB 10.5 へのアップグレード を参照してください。
7.2.7.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 に移行するには、複数の 設定変更を 実行する必要があります。
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 への以降と、必要な設定変更は、以下のドキュメントで説明します。
- Red Hat Software Collections ドキュメントの Migrating to MariaDB 10.1
- Red Hat Software Collections ドキュメントの Migrating to MariaDB 10.2
- Red Hat Software Collections ドキュメントの Migrating to MariaDB 10.3
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.2 (サポート対象外になりました)
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 データベースに保存されている全データのバックアップを作成します。
手順
RHEL 8 システムに
mariadb-server
パッケージがインストールされていることを確認します。# yum install mariadb-server
データのコピー時に、
mariadb
サービスがソースおよびターゲットのシステムで稼働していないことを確認します。# systemctl stop mariadb.service
-
ソースの場所から RHEL 8 ターゲットシステムの
/var/lib/mysql/
ディレクトリーにデータをコピーします。 ターゲットシステムでコピーされたファイルに適切なパーミッションと SELinux コンテキストを設定します。
# restorecon -vr /var/lib/mysql
ターゲットシステムで、MariaDB サーバーを起動します。
# systemctl start mariadb.service
mysql_upgrade
コマンドを実行して、内部テーブルをチェックし、修復します。$ mysql_upgrade
-
アップグレードが完了したら、
/etc/my.cnf.d/
ディレクトリー内のすべての設定ファイルに MariaDB 10.3 に対して有効なオプションのみが含まれていることを確認します。
インプレースアップグレードには、特定のリスクと既知の問題があります。たとえば、一部のクエリーが動作しなかったり、アップグレード前とは異なる順序で実行される場合があります。これらのリスクと問題、およびインプレースアップグレードに関する全般的な情報は、MariaDB 10.3 Release Notes を参照してください。
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.3 と MariaDB 10.5 の間の重要な変更点には以下が含まれます。
-
MariaDB がデフォルトで
unix_socket
認証プラグインを使用するようになりました。このプラグインにより、ユーザーがローカルの UNIX ソケットファイルを介して MariaDB に接続するときにオペレーティングシステムの認証情報を使用できるようになります。 -
MariaDB
に、mariadb-*
という名前のバイナリーと、mariadb-*
バイナリーを参照するmysql*
シンボリックリンクが追加されました。たとえば、mysqladmin
、mysqlaccess
、およびmysqlshow
のシンボリックリンクは、mariadb-admin
、mariadb-access
、およびmariadb-show
のバイナリーをそれぞれポイントします。 -
各ユーザーロールに合わせて、
SUPER
特権が複数の特権に分割されました。その結果、一部のステートメントで必要な特権が変更されました。 -
並列のレプリケーションでは、
slave_parallel_mode
はデフォルトでoptimistic
に設定されるようになりました。 -
InnoDB ストレージエンジンで、変数のデフォルトが変更されました (
innodb_adaptive_hash_index
はOFF
へ、innodb_checksum_algorithm
はfull_crc32
へ変更)。 MariaDB は、以前使用された
readline
ライブラリーではなく、MariaDB コマンド履歴 (.mysql_history
ファイル) を管理する基盤となるソフトウェアのlibedit
実装を使用するようになりました。この変更は、.mysql_history
ファイルを直接使用しているユーザーに影響します。.mysql_history
は MariaDB または MySQL アプリケーションによって管理されるファイルであるため、ユーザーは直接ファイルでは機能しないことに注意してください。人間が判読可能な外観は偶然です。注記セキュリティーを強化するために、履歴ファイルの維持を考慮することができます。コマンド履歴の記録を無効にするには、以下を実行します。
-
存在する場合は、
.mysql_history
ファイルを削除します。 以下のいずれかの方法を使用します。
-
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 で、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 データベースに保存されている全データのバックアップを作成します。
手順
MariaDB サーバーを停止します。
# systemctl stop mariadb.service
以下のコマンドを実行して、後続のストリームに切り替えるためのシステムの準備が整っているかどうかを判断します。
# yum distro-sync
このコマンドは、Nothing to do.Complete! のメッセージで終了する必要があります。詳細は、後続のストリームへの切り替え を参照してください。
システムで
mariadb
モジュールをリセットします。# yum module reset mariadb
新しい
mariadb:10.5
モジュールストリームを有効にします。# yum module enable mariadb:10.5
インストール済みパッケージを同期し、ストリーム間の変更を実行します。
# yum distro-sync
これにより、インストールされている MariaDB パッケージがすべて更新されます。
-
/etc/my.cnf.d/
にあるオプションファイルに MariaDB 10.5 に対して有効なオプションのみが含まれるように、設定を調整します。詳細は、MariaDB 10.4 および MariaDB 10.5 のアップストリームドキュメントを参照してください。 MariaDB サーバーを起動します。
スタンドアロンを実行しているデータベースをアップグレードする場合:
# systemctl start mariadb.service
Galera クラスターノードをアップグレードする場合:
# galera_new_cluster
mariadb
サービスが自動的に起動します。
mariadb-upgrade ユーティリティーを実行して、内部テーブルをチェックし、修復します。
スタンドアロンを実行しているデータベースをアップグレードする場合:
# mariadb-upgrade
Galera クラスターノードをアップグレードする場合:
# mariadb-upgrade --skip-write-binlog
インプレースアップグレードには、特定のリスクと既知の問題があります。たとえば、一部のクエリーが動作しなかったり、アップグレード前とは異なる順序で実行される場合があります。これらのリスクと問題、およびインプレースアップグレードに関する全般的な情報は、MariaDB 10.5 Release Notes を参照してください。
7.2.9. MariaDB 10.5 から MariaDB 10.11 へのアップグレード
ここでは、RHEL 9 における MariaDB 10.5 から MariaDB 10.11 への移行を説明します。
7.2.9.1. MariaDB 10.5 と MariaDB 10.11 の主な相違点
MariaDB 10.5 と MariaDB 10.11 の間の重要な変更点は次のとおりです。
-
新しい
sys_schema
機能。これは、データベースの使用状況に関する情報を提供するビュー、関数、およびプロシージャーのコレクションです。 -
CREATE TABLE
、ALTER TABLE
、RENAME TABLE
、DROP TABLE
、DROP DATABASE
、および関連するデータ定義言語 (DDL) ステートメントがアトミックになりました。ステートメントは完全に完結している必要があります。そうでない場合、変更が元に戻されます。DROP TABLE
を使用して複数のテーブルを削除する場合、テーブルの全リストではなく、個々のドロップのみがアトミックであることに注意してください。 -
新しい
GRANT … TO PUBLIC
権限が利用可能になりました。 -
SUPER
権限とREAD ONLY ADMIN
権限が分離されました。 -
新しい
UUID
データベースデータ型に、ユニバーサル一意識別子を格納できるようになりました。 - MariaDB が Secure Socket Layer (SSL) プロトコルバージョン 3 をサポートするようになりました。
- MariaDB サーバーの起動に正しく設定された SSL が必要になりました。以前は、SSL の設定が誤っている場合、MariaDB は SSL を暗黙的に無効にし、セキュアでない接続を使用していました。
-
MariaDB が
natural_sort_key()
関数により自然なソート順序をサポートするようになりました。 -
新しい
SFORMAT
関数を任意のテキスト書式設定に使用できるようになりました。 -
utf8
文字セット (および関連する照合順序) が、デフォルトでutf8mb3
のエイリアスになりました。 - MariaDB は、Unicode Collation Algorithm (UCA) 14 の照合順序をサポートしています。
-
MariaDB の
systemd
ソケットのアクティベーションファイルが/usr/share/
ディレクトリーで利用できるようになりました。アップストリームとは異なり、これらのファイルは RHEL のデフォルト設定の一部ではないことに注意してください。 -
エラーメッセージに、
MySQL
ではなくMariaDB
文字列が含まれるようになりました。 - エラーメッセージが中国語で利用できるようになりました。
- デフォルトの logrotate ファイルが大幅に変更されました。MariaDB 10.11 に移行する前に設定を確認してください。
-
MariaDB および MySQL クライアントの場合、コマンドラインで指定した接続プロパティー (例:
--port=3306
) によって、クライアントとサーバー間の通信のプロトコルタイプ (tcp
、socket
、pipe
、memory
など) が強制されるようになりました。たとえば、以前は MariaDB クライアントが UNIX ソケットを介して接続した場合、指定したポートが無視されていました。
7.2.9.2. RHEL 9 バージョンの MariaDB 10.5 から MariaDB 10.11 へのアップグレード
この手順では、yum
および mariadb-upgrade
ユーティリティーを使用して、mariadb:10.3
モジュールストリームから mariadb:10.5
モジュールストリームにアップグレードする方法を説明します。
mariadb-upgrade
ユーティリティーは、mariadb-server-utils
サブパッケージにより提供され、mariadb-server
パッケージの依存関係としてインストールされます。
前提条件
- アップグレードを実行する前に、MariaDB データベースに保存されている全データのバックアップを作成します。
手順
MariaDB サーバーを停止します。
# systemctl stop mariadb.service
以下のコマンドを実行して、後続のストリームに切り替えるためのシステムの準備が整っているかどうかを判断します。
# yum distro-sync
このコマンドは、Nothing to do.Complete! のメッセージで終了する必要があります。詳細は、後続のストリームへの切り替え を参照してください。
システムで
mariadb
モジュールをリセットします。# yum module reset mariadb
新しい
mariadb:10.5
モジュールストリームを有効にします。# yum module enable mariadb:10.11
インストール済みパッケージを同期し、ストリーム間の変更を実行します。
# yum distro-sync
これにより、インストールされている MariaDB パッケージがすべて更新されます。
-
/etc/my.cnf.d/
にあるオプションファイルに MariaDB 10.11 に対して有効なオプションのみが含まれるように、設定を調整します。詳細は、MariaDB 10.6 および MariaDB 10.11 のアップストリームドキュメントを参照してください。 MariaDB サーバーを起動します。
スタンドアロンを実行しているデータベースをアップグレードする場合:
# systemctl start mariadb.service
Galera クラスターノードをアップグレードする場合:
# galera_new_cluster
mariadb
サービスが自動的に起動します。
mariadb-upgrade ユーティリティーを実行して、内部テーブルをチェックし、修復します。
スタンドアロンを実行しているデータベースをアップグレードする場合:
# mariadb-upgrade
Galera クラスターノードをアップグレードする場合:
# mariadb-upgrade --skip-write-binlog
インプレースアップグレードには、特定のリスクと既知の問題があります。たとえば、一部のクエリーが動作しなかったり、アップグレード前とは異なる順序で実行される場合があります。これらのリスクと問題、およびインプレースアップグレードに関する全般的な情報は、MariaDB 10.11 Release Notes を参照してください。
7.2.10. Galera で MariaDB を複製する
本セクションでは、Red Hat Enterprise Linux 8 の Galera ソリューションを使用して、MariaDB データベースを複製する方法を説明します。
7.2.10.1. MariaDB Galera クラスターの概要
Galera レプリケーションは、複数の MariaDB サーバーで構成される同期マルチソース MariaDB Galera クラスター の作成に基づいています。レプリカが通常読み取り専用である従来のプライマリー/レプリカ設定とは異なり、MariaDB Galera クラスターのノードはすべて書き込み可能にすることができます。
Galera レプリケーションと MariaDB データベースとの間のインターフェイスは、書き込みセットレプリケーション API (wsrep API) で定義されます。
MariaDB Galera クラスター の主な機能は以下のとおりです。
- 同期のレプリケーション
- アクティブ/アクティブのマルチソーストポロジー
- クラスターノードへの読み取りおよび書き込み
- 自動メンバーシップ制御、失敗したノードのクラスターからの削除
- 自動ノードの参加
- 行レベルの並列レプリケーション
- ダイレクトクライアント接続: ユーザーはクラスターノードにログインし、レプリケーションの実行中にノードを直接操作できます。
同期レプリケーションとは、サーバーがトランザクションに関連付けられた書き込みセットをクラスター内のすべてのノードにブロードキャストすることで、コミット時にトランザクションをレプリケートすることを意味します。クライアント (ユーザーアプリケーション) はデータベース管理システム (DBMS) に直接接続し、ネイティブの MariaDB と同様の動作が発生します。
同期レプリケーションは、クラスター内の 1 つのノードで発生した変更が、クラスター内の他のノードで同時に発生することを保証します。
そのため、同期レプリケーションには、非同期のレプリケーションと比べて次のような利点があります。
- 特定のクラスターノード間の変更の伝播に遅延がない
- すべてのクラスターノードには常に一貫性がある
- いずれかのクラスターノードがクラッシュしても、最新の変更は失われない
- すべてのクラスターノードのトランザクションが並列に実行する
- クラスター全体にわたる因果関係
7.2.10.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 以降、RHEL とともに配布される MariaDB は、/usr/share/doc/galera/garb-systemd
および/usr/share/doc/galera/garbd.service
にあるこれらのファイルのアップストリームバージョンも提供します。
7.2.10.3. MariaDB Galera クラスターのデプロイメント
前提条件
- クラスター内のすべてのノードに TLS が設定 されている。
全ノード上の全証明書の
Extended Key Usage
フィールドが次のように設定されている。TLS Web Server Authentication, TLS Web Client Authentication
手順
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 を参照してください。
-
/etc/my.cnf.d/galera.cnf
設定ファイルでwsrep_on=1
オプションを設定して、すべてのノードでwsrep
API を有効にします。 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”
ノードで以下のラッパーを実行して、新規クラスターの最初のノードをブートストラップします。
# galera_new_cluster
このラッパーにより、MariaDB サーバーデーモン (
mysqld
) に--wsrep-new-cluster
オプションが指定されて実行されるようになります。このオプションは、接続する既存クラスターがないという情報を提供します。したがって、ノードは新規 UUID を作成し、新しいクラスターを特定します。注記mariadb
サービスは、複数の MariaDB サーバープロセスと対話する systemd メソッドをサポートします。したがって、複数の MariaDB サーバーを実行している場合は、インスタンス名を接尾辞として指定して、特定のインスタンスをブートストラップできます。# galera_new_cluster mariadb@node1
各ノードで次のコマンドを実行して、その他のノードをクラスターに接続します。
# systemctl start mariadb
その結果、ノードはクラスターに接続し、それ自体をクラスターの状態と同期します。
7.2.10.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.10.5. MariaDB Galera クラスターの再起動
すべてのノードを同時にシャットダウンすると、クラスターが終了し、実行中のクラスターは存在しなくなります。ただし、クラスターのデータは引き続き存在します。
クラスターを再起動するには、MariaDB Galera クラスターの設定の説明に従って、最初のノードをブートストラップします。
クラスターがブートストラップされておらず、最初のノードの mariadb
が systemctl start mariadb
コマンドのみで起動された場合、ノードは /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
プログラムを使用します。このプログラムにより、正しいビルドフラグが確実に返されるようになります。