スマートスタイル TECH BLOG

データベース&クラウド技術情報

Oracle Grid Infrastructure を用いた MySQL Enterprise Edition HA構成 (その2:MySQL構築編)

その1:GI構築編
その2:MySQL構築編
その3:機能確認編

はじめに

前回の記事ではOracle Grid Infrastructure(GI)のインストールと、MySQL用の ACFS の作成まで完了しました。
続けて、MySQL をインストールし、GI のクラスターリソースとして登録するところまでを確認してみます。

  1. MySQL 8.0 EE インストール
  2. XAG Agent インストール
  3. MySQLをクラスターリソースへ登録
  4. MySQL インスタンス起動

1. MySQL 8.0 EE インストール

MySQL と GI との仲介機能である Grid Infrastructure Agent(XAG Aent)の公式リファレンスガイドによれば、XAG Agentは MySQL インストールパターンの RPM(yum)、Tar ball いずれでも対応しています。

ただし、実際構築してみたところ、以下の相違点があることが確認できました。つまりMySQLのインストールの方法によってこれ以降のインストール・設定手順が異なってきますので、詳しく見ていきます。

RPMインストール Tar ball インストール
インストール先 固定される(製品デフォルト) 任意の場所にインストール可能
起動 systemd (systemctl start mysqld) mysqld_safe
停止 systemd (systemctl stop mysqld) mysqladmin shutdown
死活監視 systemd (systemctl status mysqld) mysqladmin status
監視用DBユーザー 不要 必要

RPMインストールの場合

今回は Yum Repositoryを用いた手順としています。
/tmp に MySQL 8.0.17 EE インストールメディアファイル(V983227-01.zip)を配置済みの状態です。
メディア解凍後、アーカイブをACFS上に展開し、クラスターメンバーノードから参照できるローカルレポジトリとするための準備を行います。

yum コマンドでインストールします。


なお、これ以降の手順は、マルチインスタンス構成でインスタンスごとにmy.cnfを分ける場合の例となっています。
もし、シングルインスタンス構成で、my.cnf はデフォルトの /etc/my.cnf を利用するので構わなければ、以下の手順でサービス起動を確認し、2. XAG Agent インストールに進んでください。
1. /etc/my.cnf を編集(datadirにACFSマウントポイントを設定)
2. systemctl start mysqld で起動


まず、デフォルトのsystemd mysqld サービスは今回利用しないので、自動起動を無効化しておきます。

次に、インスタンス1用の my.cnf を作成します。
datadir などの/u02/app/mysql/datastore/${INSTANCE_NAME}と共有ディスク(ACFS)の領域を指定している箇所が重要ですが、あとのパラメーターはお好みで変えても問題有りません。
また、今回の検証では性能検証を行っていないため、その辺りのパラメーターはデフォルトにしています。

パラメーターに合わせて必要なディレクトリを作成します。

systemd のサービス設定を行います。
デフォルトのサービス(mysqld.service)ではなく、マルチインスタンス用のサービス(mysqld@.service)を使うのですが、my.cnfを分けて任意の場所に配置する場合は少し細工が必要になります。

  1. まず、ノード1で実施します。
    • ExecStartPre で実行される /usr/bin/mysqld_pre_systemd スクリプトがデータディレクトリ初期化処理を実行する際、素の状態だと /etc/my.cnf を読み込んでしまうため、
      初回起動時のみ MYSQL_HOME 環境変数を設定することで、初期化の際に利用する my.cnf を明示的に指定します。($MYSQL_HOME/my.cnf を参照するようにします)

    • インスタンス1用のPIDファイルとしてPIDFile--pid-file 、my.cnfを指定するために--defaults-fileを追加します。※オーバーライドで設定します。
      ※PIDファイルの格納先は任意の場所で構いません。

    • 上記2点を設定後、ノード1でサービスを起動します。起動に成功したら、systemd 環境変数 MYSQL_HOME を削除して、サービス再起動します。
      再起動も成功したら、いったんノード1側でサービスを停止させます。

  2. 次にノード2で実施します。
    • 初回起動時にデータディレクトリの初期化は不要とするフラグ NO_INIT=true/etc/sysconfig/mysql に設定しておき、起動できたら /etc/sysconfig/mysql をクリアして再起動します。

なお、mysqld@.service はデフォルトで自動起動は無効になっていますが、念の為確認しておきます。(最終的にクラスターで起動させるため)

Tar ball インストールの場合

Tar ball を ACFS上の /u02/app/mysql/products に格納しておき、インストールベースディレクトリはローカルの /u01/app/mysql にしています。

つぎに、my.cnf ですが、こちらではmysqladminセクションに以下を追加し、監視用DBユーザーを指定します。

データディレクトリの初期化、SSL-RSAセットアップを実行し、mysqld_safe でプロセスを起動させます。
mysql_secure_installationも実行しておきます。

DBに接続後、auth_socket認証方式でログインする監視用DBユーザーを作成します。
このあとクラスターリソースを登録する際のリソースの所有者(mysqlユーザー)が、死活監視(mysqladmin)の実行ユーザーとなります。
ちなみにパスワード認証方式にすることもでき、その場合は、my.cnfの mysqld_safe セクションに password を追記します。(平文で保管されるので本番環境の場合はセキュリティを考慮して格納先やファイルパーミッションを適切に設定しておくべきです)

公式リファレンスガイド(P.57)には監視用ユーザーの権限は USAGE のみでよいと記載ありますが、実際のところ、停止(agctl stop コマンド)と再配置(agctl relocate コマンド)の際に XAG Agentが内部的に発行する mysqladmin shutdownSHUTDOWN 権限がないとエラーになり正しく動作しませんので、忘れずに権限を追加しておきます。

ノード1でのMySQLインストールは完了したので、MySQLを停止し、次はノード2でも同じ手順でMySQLが起動できることを確認します。

2. XAG Agent インストール

rootユーザーでインストールディレクトリを作成します。任意の場所で構いませんが、今回は /u01/app/xag としました。

/tmpにインストールメディア(xagpack91.zip)を格納しておきます。gridユーザーでXAG Agentをインストールします。
--all_nodesオプションを指定すると全クラスターメンバーノードへ、または --nodes オプションで特定のノードへ配布リリースされます。

ノード2でもインストールされていることを確認します。

なお、公式リファレンスガイドには明記されていませんが、XAG Agentのログディレクトリのオーナーがrootになっていると、MySQLインスタンスのリソース起動時にログを書き込めない問題が発生しますので、rootユーザーでオーナー、権限を再設定しておきます。

3. MySQL をクラスターリソースへ登録

インストールとしては最後のステップになります。
agctl add コマンドでクラスターリソース登録しますが、その際に指定するパラメーターは MySQL のインストール方法(RPM or Tar ball)で異なります。
公式リファレンスガイド(P.58,59)にパラメーターの説明がありますが、実物と異なっている(説明が不足している)ので実際のコマンドヘルプ内容を補足する形で説明を入れておきます。

  • (1)で指定する内容はMySQLのインストール方法によって異なります。
    • RPMインストールの場合、--service_name に systemd で認識されるサービス名を指定します。
    • Tarインストールの場合、--mysql_type(MySQL Severインスタンスの場合、MYSQLを設定),--mysql_home,--datadirの指定は必須となります。
  • (4)は--server_pool,--nodesいずれか、または何も指定しなければ、すべてのクラスターメンバーノードで起動するように登録されます。

  • (5)は、いずれのインストールタイプの場合にも、MySQL インスタンス1用Application VIPを指定する必要があります。
    Application VIP はリソース登録の前作成しておくか、またはリソース登録と同時に作成もできます。
    Application VIP を事前に作成するには root ユーザーでcrsctl add resource app.appvipコマンドを実行する必要があります。その際に付けたVIP名を --vip_nameに指定します。
    事前に作成しておいた場合、agctl addコマンドはgridユーザーで実行できます。
    特別な理由がなければ、rootユーザーでリソース登録と同時に作成する手順が1ステップで実施できるのでオススメです。その場合は、--network,--ip,--user(,--group) を指定します。
    --networkは、クラスター上のネットワークリソース番号を指定します。
    下記の場合、ネットワークリソース ora.net1.network の番号は1です。

  • (6)の--filesystemsパラメーターには、インスタンスが使用するデータディレクトリの ACFS リソース名を指定すると、起動・停止の依存関係を組むことができます。これについては次回検証したいと思います。

RPM インストールの場合

実際のリソース登録コマンドは以下の通りとなります。
Application VIP の IPアドレスを 192.168.100.40 としています。
mysqld@.service を用いるサービスを登録する場合、--service_nameパラメーターで指定するサービスが起動している状態でないと認識しないので注意してください。

agctl config コマンドで登録された情報を確認できます。

リソース登録が成功したら、いったん MySQL をsystemctl で停止しておきます。

Tar ball インストールの場合

--environment_varsMYSQL_HOME=/u02/app/mysql/datastore/instance1を指定しています。
これはRPMインストール時と同じ用法で、インスタンス1用に準備したmy.cnfを起動時に認識させるための工夫となります。

agctl config コマンドで登録された情報を確認すると以下の通りとなっています。

4. MySQL インスタンス起動

agctl addコマンド直後、agctl statusコマンドやcrsctl stat resコマンドで状態確認してみると、クラスター管理上では停止状態になっています。

agctl(内部的にはcrsctl)から起動させることでステータスを正しく把握させます。

無事、クラスターリソースとして正常に起動することができました。
ためしに Application VIP を指定して接続してます。

現在のインスタンス稼働ノードである node1 へ接続できました。

まとめ

  • MySQL のインストールについては、相違点はあるものの、RPM or Tar ball のどちらの構成方法でも問題なく構成できました。

  • 記事中で何点かポイントしてありますが、XAG Agent 公式リファレンスガイドを元に環境構築するには説明が少し不足しているようですので、ご注意ください。

  • 次回は、肝となる高可用性の機能(フェイルオーバー・フェイルバック)拡張性(ACFSボリューム拡張、MySQLインスタンス追加)、その他気付いた点などをレポートします。

MySQL
Return Top