7.2. MariaDB の使用

前提条件

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

前提条件

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

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

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

前提条件

• 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) フィールドは、サーバーのホスト名と一致します。

前提条件

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

前提条件

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

検証

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

  # 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

• 選択したデータベースを 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

前提条件

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

  # yum install mariadb-backup

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

手順

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

  $ 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>

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

前提条件

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

  # systemctl stop mariadb.service

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

• 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 つに接続できます。

• 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

• 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 で該当する章を参照してください。

前提条件

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

• 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 アプリケーションによって管理されるファイルであるため、ユーザーは直接ファイルでは機能しないことに注意してください。人間が判読可能な外観は偶然です。

  注記

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

  1. 存在する場合は、.mysql_history ファイルを削除します。

  2. 以下のいずれかの方法を使用します。

     • MYSQL_HISTFILE 変数を /dev/null に設定し、これをシェルの起動ファイルに追加します。

     • .mysql_history ファイルを /dev/null へのシンボリックリンクに変更します。

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

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

• 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 パッケージを手動でインストールします。

前提条件

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

• 新しい 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 ソケットを介して接続した場合、指定したポートが無視されていました。

前提条件

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

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

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

• 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 にあるこれらのファイルのアップストリームバージョンも提供します。

前提条件

• 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 設定ファイルの [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) のいずれかを要求し、他のノードとの一貫性を確保します。