LifeKeeperのすべて第1回

フェイルオーバーの動作確認

フェイルオーバーの動作確認は若干トリッキーな手法を用いる必要がある。これは「MySQLは監視上ダウンしていて、再起動しても復旧できない」という状態を擬似的に発生させる必要があるためである。

手法はいくつか考えられるが、ここでは最もシンプルにmysqld_safeの実行権限を奪うことで再起動による復旧が行えない状態を再現してみる。まずは、現在のアクティブ側（ylk1）とスタンバイ側（ylk2）のMySQLの起動状態を確認する。

`[root@ylk1 root]# netstat -anp \| grep 3306`
`tcp`	`0`	`0`	`0.0.0.0:3306`	`0.0.0.0:*`	`LISTEN`	`17623/mysqld`

`[root@ylk1 root]# ps auxwww \| grep mysql`
`root`	`17559`	`0.0`	`0.4`	`5264`	`1224`	`?`	`S`	`05:10`	`0:00`
`/bin/sh /usr/local/bin/mysqld_safe`
`（出力略）`
`mysql`	`7497`	`0.0`	`4.7`	`105464`	`12096`	`tty1`	`S`	`Dec11`	`0:02`
`/usr/local/libexec/mysqld`
`（以下出力略）`

[root@ylk1 root]# ssh ylk2 netstat -anp | grep 3306 root@ylk2's password: [root@ylk1 root]#
確認例では混乱を避けるため意図的にylk1側から両系の状態確認を行っている。これにより、現在ylk1側でMySQLが起動しており、ylk2側では起動していないことが確認できたので、以下のコマンドでylk1側に擬似障害を発生させる。

[root@ylk1 root]# kill -9 17623 17559 && chmod -x /usr/local/bin/mysqld_safe [root@ylk1 root]# neststat -anp | grep 3306 [root@ylk1 root]#
今度は、デフォルトの監視間隔である2分以上が経過してもylk1側でmysqlが起動した形跡はない。かわりに、ylk2側の状態を再度確認する。

`[root@ylk1 root]# ssh ylk2 netstat -anp \| grep 3306`
`root@ylk2's password:`
`tcp`	`0 0 0.0.0.0:3306`	`0.0.0.0:*`	`LISTEN`	`25641/mysqld`

上記の出力例のようにMySQLがylk2側で無事起動していることを確認できれば、障害時にLifeKeeperの切り替え機能が正常に動作していることが確認できる。

今回はOSのコマンドレベルでの確認を紹介したが、LifeKeeperのコマンドからの確認やGUI上からの遷移を確認することで切り替えの進行状況も確認することが可能であるのであわせて使用して欲しい。LifeKeeperのユーティリティコマンドについては本連載の別の機会で使用頻度の高いものや有用なものを紹介するのであわせて参考にしていただきたい。

終わりに

   今回、DBのHAクラスタ化の基本的な手順や留意事項を紹介した。連載上では取り上げられなかったが、運用に向けての留意事項や性能テストなど熟知すべき部分は多岐にわたる。本連載とSteelEye社のサイト上のドキュメントをあわせて参照してほしい。

   またLifeKeeperの真価はカタログの性能一覧ではなく、実際の構築を行ってこそ実感することができるものだと考えている。

   LifeKeeperの各ARKも評価版を使用して最大90日間試用することが可能となっているので、本連載を参考に一度HAクラスタ化を試行してほしい。意外なほどシンプルにDBのHAクラスタ化という命題を叶えられることを「体感」できるはずである。

（監修：サイオステクノロジー株式会社小野寺章）