Oracle Grid Infrastructure を用いた MySQL Enterprise Edition HA構成(その3:機能確認編)

この記事は最終更新から4年以上経過しています。内容が古くなっている可能性があります。

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

目次

はじめに

前回の記事でベースの環境構築は済みましたので、いよいよ高可用性の機能を確認していきます。

1. 高可用性の機能確認

接続確認用の準備

HAの切り替わりを確認するために準備をしておきます。

  1. 接続ユーザーの作成

  2. Application VIP ホスト名を hosts ファイルに追記

リソース再配置(relocate)

node1,node2 ともにOSは通常稼働中の状態で、node1 → node2 へ稼働系を切り替えてみます。
切り替え前の状態を確認します。node1で MySQL instance1 が稼働中です。

agctl relocate コマンドでリソースを再配置させます。

instance1 用の Application VIP も共連れで node2 へ移動していることが確認できます。

node1 に切り戻してみます。
併せて実行時間も測ってみたところ、この環境では13秒程度で relocate されました。

mysqld プロセスダウン時

mysqldプロセスが異常終了によりダウンした場合、Oracle Clusterware の機能ではなく、systemd サービス(RPMインストール時)またはmysqld_safe(Tar ballインストール時)によって自動再起動されます。
※例えば、systemd 管理の場合、mysqld@.service の設定で Restart=on-failure となっているので0以外の終了コードで停止した場合、自動で再起動されます。

ちなみに、Clusterware がリソースを再起動したかどうかは以下のコマンドで確認できます。
今回はRESTART_COUNTが0なので Clusterwareによる再起動ではありません。

mysqld プロセスハング時

プロセスが応答不能になった場合の死活監視と保護について挙動を確認してみます。

その前に、Oracle Clusterware はどのようにリソース監視を行っているのかといいますと、、、

まず前提として、Clusterware リソースにはリソース属性というパラメーターが存在します。
基本的なものから詳細なものまで様々なリソース属性がありますが、リソースの死活監視の挙動は以下のパラメーターが関係してきます。
※リソース属性の各説明文章はClusterware管理およびデプロイメント・ガイドより引用

リソース属性 説明 XAG Agent mysql_server のデフォルト値
CHECK_INTERVAL checkアクションの実行を繰り返す時間間隔(秒単位)。間隔を短くするとより頻繁にチェックできますが、スクリプト・エージェントを使用するとリソースの消費も増大します。リソースの消費を低減するには、アプリケーション固有のエージェントを使用します。 30
CHECK_TIMEOUT チェック・アクションを実行できる最大時間(秒単位)。アクションが指定された時間内に完了しなかった場合、Oracle Clusterwareはエラー・メッセージを戻します。この属性が指定されていない場合または0秒が指定されている場合、Oracle ClusterwareはSCRIPT_TIMEOUT属性の値を使用します。 0
SCRIPT_TIMEOUT アクションを実行する最大時間(秒単位)。アクション・スクリプトが指定された時間内に完了しなかった場合、Oracle Clusterwareはエラー・メッセージを戻します。このタイムアウトは、すべてのアクション(start、stop、checkおよびclean)に適用されます。 60
FAILURE_INTERVAL リソースがFAILURE_THRESHOLD属性で指定した障害の回数を超えた場合にOracle Clusterwareがリソースを停止するまでの間隔(秒単位)。 600
FAILURE_THRESHOLD リソースに指定されたFAILURE_INTERVAL内で検出される障害の数で、この値を超えると、Oracle Clusterwareがリソースを使用不可としてマーク付けし、そのリソースの監視を停止します。指定した回数の障害がリソースで発生すると、Oracle Clusterwareはそのリソースを停止します。 5
RESTART_ATTEMPTS Oracle Clusterwareが、リソースの再配置を試行する前に、リソースの現行のサーバー上でリソースの再起動を試行する回数。1の値を指定した場合、Oracle Clusterwareはサーバー上でリソースの再起動を1回のみ試行します。2回失敗すると、Oracle Clusterwareの再配置が試行されます。 5
UPTIME_THRESHOLD UPTIME_THRESHOLDの値は、Oracle Clusterwareがリソースが安定しているとみなすまでに、リソースが稼働中である必要がある時間の長さを表します。UPTIME_THRESHOLD属性の値を設定すると、リソースの安定性を示すことができます。
この属性の値は、数値の後に秒(s)、分(m)、時間(h)、日(d)または週(w)を示す文字を付けて入力します。たとえば、7hという値は、稼働時間のしきい値が7時間であることを示します。
Oracle Clusterwareは、UPTIME_THRESHOLDに指定した時間が経過すると、停止、起動、再配置または障害のようなリソース状態が変更されるイベントが次に発生したときに、RESTART_COUNTの値を0にリセットします。RESTART_COUNTの値がRESTART_ATTEMPTSに設定した値に達すると、Oracle Clusterwareはアラートを生成します。カウンタは、次回リソースの障害発生時や再起動時に、効果的にリセットされます。しきい値は、再起動がカウントされて破棄される時間の長さを示しています。しきい値に達してリソースが失敗すると、再起動されます。
10m

実際に確認するコマンドは以下になります。(全パラメーターが出力されるので egrep で表示を絞っています)

リソースの死活監視の仕組みは要約すると以下のような動きになります。

  • CHECK_INTERVAL秒間隔でリソースのチェック・アクションを実行する。
    • systemd サービス管理の場合は、systemctl status mysqld
    • mysqld_safe からの起動の場合は、mysqladmin status
  • リソースチェックに失敗する、または(CHECK_TIMEOUT=0なので)SCRIPT_TIMEOUT秒以内に完了しなかった場合、リソースの再起動を試みる。

  • RESTART_COUNT 数が RESTART_ATTEMPTS を超え、かつ FAILURE_COUNT数 が FAILURE_INTERVAL 期間内で FAILURE_THRESHOLD 数以内の場合、フェイルオーバーを実行する。

  • FAILURE_COUNT数 が FAILURE_INTERVAL 期間内で FAILURE_THRESHOLD 数を超えた場合、リソースは OFFLINEとなる(クラスター内で完全に停止される)

[クリックして拡大]

それでは、実際にリソースチェックの失敗を発生させ、挙動を確認してみます。

リソースチェック失敗による再起動回数が閾値を超過した場合、Clusterware アラートログ($ORACLE_BASE/diag/crs/<ホスト名>/crs/trace/alert.log)に以下のメッセージが出力されます。

リソース属性値の遷移を観察していると、確かに設定値に準じてフェイルオーバーが発生したことが確認できました。

XAG Agentのリソース属性値は、agctl modify コマンドの--attributeパラメーターを使用することで任意の値に変更することができます。もちろん、リソース登録時に指定することもできますので、デフォルトから変更するのであれば、予めプロセス死活監視方針を定めた上で最初に設定しておいて、テストで調整していくのがよいでしょう。

※なお、oraから始まるクラスターリソースのリソース属性値はOracleサポートからの指示がない限りユーザーが変更することはできませんのでご注意ください。(変更した場合サポート対象外となります)

mysqld に対する人的な起動停止オペレーションミス

以下のシチュエーションはどちらかと障害というより運用者が誤操作してしまったような場合の挙動確認になります。

  • node1 で起動中の MySQL クラスターリソースを node2 で起動させようとした場合
    ⇒XAG Agent が起動状態を確認し、二重起動が抑止されました。

  • agctl コマンドで起動した MySQL クラスターリソースのプロセスを、systemctl コマンドで停止した場合
    ⇒今度は Clusterware がOFFLINEを検知し、自動再起動によって復旧されます。
    クラスター管理下での完全な正常停止は、agctl stop コマンドを利用することになります。

正系サーバーダウン時

アクティブ・スタンバイHAの基本機能となりますが、当然ながら副系(node2)へフェイルオーバーすることを確認しました。

再び node1 を起動させた後も、MySQL クラスターリソースは node1 へは戻らずそのまま node2 で稼働しています。node1のダウンや故障となる原因を取り除いた後、リソースを正系へ切り戻す流れとなります。

副系サーバーダウン時

node1 で MySQL が稼働中に node2 をサーバーダウンしても、クラスターリソースの稼働には影響を与えないことが確認できました。

NIC障害時

  1. Public Network 通信不可
    node1 で Application VIP が稼働している Public Network の NIC をダウンさせてみます。

    Application VIP と共に MySQL クラスターリソースがnode2へフェイルオーバーしました。

  2. Private Network 通信不可
    次は、Clusterware の稼働上重要な通信を行っている Private Network の NIC をダウンさせてみます。(node1)

    169.254.11.46/19(eth2:1)という仮想IPアドレスについては後述します。

    NICダウン後、程無くしてNode1の Clusterwareの主要スタックが Oracle High Availability Services 以外異常な状態になります。

    スプリットブレイン防止のため、クラスターから node1 が切り離され、生存する他のクラスターメンバーノードへリソースがフェイルオーバーされました。

    このように、Private Networkの通信ができなくなることは、Clusterwareにとって甚大な影響となります
    今回の環境では Private Network は単一の NIC で構成していますが、本番環境では必然的に冗長化することになります。
    冗長化は一般的なボンディング以外に、GI では冗長インターコネクトという構成方法があります。
    これは、Private Network用に2~4つのそれぞれ別のネットワークセグメントに属するNICを用いて、GIが内部的に付与する高可用性IP(HAIP)が、障害時に自動的に着け替えわれる仕組みとなっています。
    詳細についてはマニュアルや少しバージョンは古いですがこのあたりの資料(P.87-99)をご一読いただけると理解が深まるかと思います。前出の169.254.11.46/19(eth2:1)という仮想IPアドレスはこの冗長インターコネクトで利用するHAIPになります。
    ※残念ながら、単一NICではHAIPはインストール時に付与されるだけで、実際には機能しません。

ACFS リソース停止

その2:MySQL構築編にて、agctl add mysql_server コマンドでクラスターリソースに登録する際に、--filesystems という任意のパラメーターがあり起動停止の依存関係を設定できる、と補足していました。

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

実は、このパラメーターは本構成ではこの依存関係の設定を入れておかないとOS再起動時に問題になってしまうのです。
理由としては以下の通りで、

  • GI のデーモンプロセス(スタック)には起動順序があり、定められた依存関係に準じて起動していきます。
  • ASMとそれに紐づくADVM,ACFS の起動時間は他の GI リソースよりも長く、ほとんどの場合起動完了するのが最後になります。
  • OSをクリーンな状態から起動させた場合、MySQL のクラスターリソースは、ACFS の起動完了を待たずに mysqld プロセスを起動させようとします。
    ところが、ACFSが起動していないため、共有ディスク上の my.cnf や datadir にアクセスできず起動失敗となります。

「MySQL が起動する前に ACFS が起動していること」は必須であるため、適切に依存関係を設定しておく必要があります。

ということで、agctl modify コマンドでACFSとの起動停止依存関係を設定します。

agctl config コマンドで設定が反映されていることを確認します。

正しく設定できたので、ACFSリソース停止時の挙動を確認してみます。

ACFリソース ora.data.acfsvol02.acfs は node1,node2 で起動していますので、
試しに、node1のACFSリソースを単独で停止しようとすると、依存関係により抑制されます。

-forceオプションを付与することで、MySQL インスタンスのリソースはnode2へrelocateされました。

※すべてのクラスターメンバーノードのACFSを停止すると、MySQLリソースも停止します。

2. 拡張性の機能確認

MySQLインスタンス追加

その1:GI構築編の手順を元に、インスタンス(instance2)を追加してみます。(ここでは注意点のみ記載し、詳細なコマンドは割愛します)

  1. ACFS ボリューム、ファイルシステム作成
  2. マウントポイント作成
  3. ACFS クラスターリソース登録、起動
  4. ACFS 上に 追加インスタンス用ディレクトリ作成
  5. my.cnf作成
    インスタンス名とポート番号を変えます。

  6. MySQL起動、初期設定(node1)
    systemd 利用の場合、同じUnit定義ファイルを利用するので instance1 の時に実施したsystemctl edit mysqld@の手順は今回は不要ですが、instance2用のmy.cnfを一時的にsystemd環境変数に設定する手順は必要です。

  7. MySQL起動(node2)
    instance1 の時と同様に、初回起動時はデータ初期化不要のフラグを忘れず設定しておきます。

  8. 追加インスタンスをクラスターリソースへ登録
    Application VIPとAFCSリソースは追加インスタンス用の設定をセットするようにします。
    systemd 利用版のリソース登録コマンド例)

  9. 追加インスタンス(クラスターリソース)起動

無事追加できました。

instance2 のみ副系へ relocate してみます。

ACFS ボリューム拡張

ACFS は、ADVM(ASM動的ボリューム・マネージャ)によって LVM のようにオンラインでボリュームサイズの変更(拡張、縮小)が可能です。
簡単な例ですが、instance1 用の ボリュームを5G増やしてみます。
ファイルシステムがマウント済みのボリュームサイズに対する変更は、acfsutil size コマンドを用います。(類似コマンドとして、asmcmd volresizeがありますが、このコマンドはマウント済みファイルシステムがある場合利用できません)
gridユーザーで実行します。

3. その他

XAG Agent ログファイル

/u01/app/xag/log/<ホスト名>ディレクトリに以下のログが出力されます。

ログファイル名 内容
agctl_<実行ユーザー名>.trc agctl コマンド実行ログ
agctl_mysql_server_<実行ユーザー名>.trc agctl コマンド実行ログ(対象:mysql_server)
<インスタンス名>_agent_mysql_server.trc <インスタンス名>実行ログ
xagsetup_YY-MM-DD_hh-mi-ss.log xagsetup.shによるinstall/deinstall実行時のログ

<インスタンス名>_agent_mysql_server.trcは、デフォルトではCHECK_INTERVAL 30秒ごとに mysqladmin status でモニタリングするため、このトレースファイルに実行結果がロギングされ続け、ファイルサイズが増大していきます。
ただし、XAG Agent でログファイルサイズを監視しており、10MB 以上になると<インスタンス名>_agent_mysql_server_01.trcのように自動でログローテーションされ、10世代保管される仕様になっていますので、運用上も安心です。

XAG Agent 診断ログ収集スクリプト

公式リファレンスガイドに、XAG Agent の障害調査用として診断ログを収集する perl スクリプト xagdiagcollection.pl が紹介されていました。

スクリプトは $XAG_HOME 直下に置かれており、ラッパーシェルスクリプト xagdiagcollection.sh も併せて存在していました。(ラッパーシェルスクリプトについてはリファレンスガイドに記載なし)

試しに実行してみたところ、perlスクリプトにコードバグがありそのままでは動きませんでした、、、
(残念ながら本稿でコードは公開できませんのでご了承ください)

コードを読んでみたところと、このスクリプトの処理自体は、上述の/u01/app/xag/log/<ホスト名>ディレクトリ内のログを tar.gz で固めているものでしたので、現状は敢えて利用する必要性もあまりなさそうです。

このほか、GIのログ収集としては Oracleトレース・ファイル・アナライザ・コレクタ(TFA コレクター)を使うのがサポート調査用に有益です。

まとめ

  • 全3回にわたって環境構築から機能確認までを行いました。
    本記事では性能面での検証は行っておりませんが、アクティブ・スタンバイDBシステムとしての高可用性の要求には十二分に応じられる機能を有していることが確認できました。
  • XAG Agentが仲介することにより、複雑な管理コマンド(crsctl,srvctl)を駆使せずとも、agctl によってMySQLインスタンスをシンプルに操作できることが利点となります。
  • GI未経験のユーザーにはどうしてもハードルになってしまうのは致し方ないところではあります。
    一方で、既にOracle RACを運用されているユーザーとってはスキル習熟コストも少なくて済むかもしれません。
  • DBとClusterwareの製品サポートを一本化するというメリットもあります。
  • 概要レベルになりましたが、構成検討の際の一助となれば幸いです。
MySQL

スマートスタイルTECHブログについて

スマートスタイルTECHブログでは、日頃MySQLのサポート業務に従事している有資格者で構成された技術サポートチームがMySQLに関する技術情報を発信しています。データベースのお困りごとはお気軽にご相談下さい。

よかったらシェアしてね!
  • URLをコピーしました!
目次