MySQL Fabric検証シリーズ第4弾。
今回は死活監視。
死活監視はさほど難しくない。
今回の記事は障害模擬やおまけがあって長くなっているが、
設定自体はコマンド1つでできる。
復習になるが、MySQL Fabricでの死活監視は、
高可用性グループ内で行われる。
高可用性グループ内に複数のサーバがある場合、
1台のPrimaryサーバと、それ以外のSecondaryサーバに分類される。
(厳密にはSpareなどのステータスも存在するが、
実用的・意図的に使用することはあまりないと思われるため割愛)
Primaryサーバがダウンした際、これをMySQL Fabric管理サーバが検知し、
残りのSecondaryサーバにfailoverする、という流れになる。
ちなみに今回、MySQL Fabricでの表記に合わせてPrimary/Secondaryという表現をしているが、
これは従来のMySQL Replicationで言うMaster/Slaveとほぼ同義。
以下のPrimary/Secondaryという表現が馴染まない方は、Master/Slaveと読み替えてもらって構わない。
なお、以下の作業は既にMySQL Fabricの基本設定が済んでいる前提で実施している。
詳細はUCO-Tech(MySQL Fabric基本設定編)を参照のこと。
現在、下記のような構成となっている。
MySQL Fabric管理サーバ
192.168.2.213
my_first_fabric
192.168.2.214
192.168.2.215
my_second_fabric
192.168.2.216
192.168.2.217
my_global_fabric
192.168.2.218
192.168.2.219
3つの高可用性グループに2つずつサーバが属しており、
これをMySQL Fabric管理サーバが統括している、という構成である。
my_global_fabricというグループ名はいかにも特殊な役割を持っていそうに見えるが
(そして実際将来的には持たせるのだが)、今のところは他と全く違いはない。
では、死活監視の手順に入っていく。
○ 死活監視有効化
mysqlfabric group activate 高可用性グループ名
の構文でMySQL Fabricの死活監視をスタートできる。
[root@mysql-fabric-kensyo1 ~]# mysqlfabric group activate my_first_fabric Fabric UUID: 5ca1ab1e-a007-feed-f00d-cab3fe13249e Time-To-Live: 1 uuid finished success result ------------------------------------ -------- ------- ------ e85b448e-06e4-4440-8fa8-702c8f31278b 1 1 1 state success when description ----- ------- ------------- ------------------------------------------------------------- 3 2 1.43484e+09 Triggered by. 4 2 1.43484e+09 Executing action (_activate_group). 5 2 1.43484e+09 Executed action (_activate_group).
これで死活監視は有効化されている。
○ 障害模擬
では早速failoverさせてみる。
ログはfabric.cfgの[logging]に書いたファイル(デフォルトでは/var/log/fabric.log)に記載されるので、
これをtail -fで観察する(もちろん別コンソールを立ち上げての話)。
Primaryのmysqldとmysqld_safeをkill -9で落とす。
[root@mysql-fabric-kensyo2 ~]# kill -9 1999 2176
すると、数秒後、/var/lib/fabric.logにこんな記載が現れた。
[WARNING] 1434844143.698885 - FailureDetector(my_first_fabric) - Server (b5420e49-1775-11e5-a680-000c29337b1b) in group (my_first_fabric) is unreachable. [WARNING] 1434844145.706382 - FailureDetector(my_first_fabric) - Server (b5420e49-1775-11e5-a680-000c29337b1b) in group (my_first_fabric) is unreachable. [WARNING] 1434844147.715908 - FailureDetector(my_first_fabric) - Server (b5420e49-1775-11e5-a680-000c29337b1b) in group (my_first_fabric) is unreachable. [WARNING] 1434844147.731936 - Executor-1 - Reported issue (FAULTY) for server (b5420e49-1775-11e5-a680-000c29337b1b). [INFO] 1434844147.734008 - Executor-1 - Master (b5420e49-1775-11e5-a680-000c29337b1b) in group (my_first_fabric) has been lost. [INFO] 1434844147.875261 - Executor-1 - Master has changed from b5420e49-1775-11e5-a680-000c29337b1b to b61e91a7-1775-11e5-a680-000c29c92c22.
「Master has changed from b5420e49-1775-11e5-a680-000c29337b1b to b61e91a7-1775-11e5-a680-000c29c92c22.」
とあるところをみると、どうやら無事failoverしてくれたようだ。
ここでmysqlfabricユーティリティでステータスを見てみると・・・
[root@mysql-fabric-kensyo1 ~]# mysqlfabric group lookup_servers my_first_fabric Fabric UUID: 5ca1ab1e-a007-feed-f00d-cab3fe13249e Time-To-Live: 1 server_uuid address status mode weight ------------------------------------ ------------- ------- ---------- ------ b5420e49-1775-11e5-a680-000c29337b1b 192.168.2.216 FAULTY READ_WRITE 1.0 b61e91a7-1775-11e5-a680-000c29c92c22 192.168.2.217 PRIMARY READ_WRITE 1.0
たしかにb542~のサーバのstatusがFAULTYになり、
代わりにb61e~のサーバがPRIMARYになっている。
これでfailoverができたと判断できる。
○ 復旧
まず、落としたMySQLを起動させる(service mysql startでOK)。
その後、
mysqlfabric server set_status MySQLのUUID 変更したいステータス
の構文を利用して、ステータスを変更する。
ステータス変更については、一旦「spare」にしてから「secondary」、「primary」と
順に実行していく必要がある。
注:MySQLのUUIDというのは、MySQLサーバを一意に決定するための独自のIDで、
今回の障害を起こしたMySQLでいえばb5420e49-1775-11e5-a680-000c29337b1bである。
これを知るには、上の例のように
mysqlfabric group lookup_servers グループ名
の構文を利用してもよいし、
データディレクトリ直下のauto.cnfを参照しても良い。
それはさておき、ステータス変更実行例。
[root@mysql-fabric-kensyo1 ~]# mysqlfabric server set_status b5420e49-1775-11e5-a680-000c29337b1b spare Password for admin: Fabric UUID: 5ca1ab1e-a007-feed-f00d-cab3fe13249e Time-To-Live: 1 uuid finished success result ------------------------------------ -------- ------- ------ c9d984b7-6bd1-4b99-90b3-7d2cf7c60f65 1 1 1 state success when description ----- ------- ------------- ------------------------------------------------------------- 3 2 1.43485e+09 Triggered by. 4 2 1.43485e+09 Executing action (_set_server_status). 5 2 1.43485e+09 Executed action (_set_server_status).
これはspareにした例だが、
次も同様に
# mysqlfabric server set_status b5420e49-1775-11e5-a680-000c29337b1b secondary
とした後、
# mysqlfabric group promote my_first_fabric
で元通りPrimaryに戻すことができる。
死活監視編は以上。
次はいよいよMySQL Fabric最大の特徴とも言えるデータシャーディング編!
○ おまけ(死活監視の仕組み)
死活監視をどのように行っているか、
その中身を少しだけのぞいてみた。
各サーバで一般クエリログをONにして、
監視をactivateした時にどんなクエリが実行されているかを見てみよう、
という企画。
管理対象MySQLサーバでは下記のようなクエリが実行されていた。
150722 5:27:15 58 Connect fabric@192.168.2.213 on 58 Query SET NAMES 'utf8' COLLATE 'utf8_general_ci' 58 Query SET @@session.autocommit = ON 150722 5:27:17 59 Connect fabric@192.168.2.213 on 59 Query SET NAMES 'utf8' COLLATE 'utf8_general_ci' 59 Query SET @@session.autocommit = ON 150722 5:27:19 60 Connect fabric@192.168.2.213 on 60 Query SET NAMES 'utf8' COLLATE 'utf8_general_ci' 60 Query SET @@session.autocommit = ON 150722 5:27:21 61 Connect fabric@192.168.2.213 on 61 Query SET NAMES 'utf8' COLLATE 'utf8_general_ci' 61 Query SET @@session.autocommit = ON (略)
クエリの内容は意味のあるものではなさそうで、
このクエリの結果が返ってくるかどうかで死活監視をしている、
と推測される。
なお、興味深いことに、上記クエリはPrimaryだけでなく、Secondaryでも実行されていた。
MySQL Fabricと同じくMySQLの死活監視を行うソフトウェアであるMHA(Master HA for MySQL)では、
Masterに対してのみ定期的にselect 1というクエリを実行することで死活監視しており、
Slaveに対しては全くの監視対象外であったが、MySQL Fabricでは違うようだ。
MySQL FabricではダウンしたサーバのステータスをFAULTYとして管理する。
Primaryに障害が発生した場合にFAULTYと判定できるのは上の障害模擬で確認したが、
Secondaryに障害が起きたときにもFAULTYと判定できる可能性が大である。
できる、というと聞こえは良く、実際できたほうがいい局面もあるとは思うが、
これはマイナスの側面もあるといえる。
一般に、MySQLのバックアップ取得では、Master/Slave構成のうち、
Slaveを一時的に停止してデータディレクトリの物理コピーを行う、
という手法が用いられることがある(もちろんmysqldumpやMySQL Enterprise Backupも忘れてはならない)。
この際、MySQL Fabricでバックアップのために停止したSecondaryサーバをFaultyとして判定してしまうと、
バックアップ終了後にSecondaryサーバが起動してきても高可用性グループ内で生きたサーバとして認識されない、
という可能性がある。
このような事態にならないよう、MySQL Fabric側で判断している可能性もあるが、
要検証、というのは間違いない。
一方、MySQL Fabric管理サーバでは、
150722 5:30:02 13 Query SELECT group_id, description, master_uuid, master_defined, status FROM groups WHERE group_id = 'my_first_fabric' 13 Query SELECT server_uuid, server_address, mode, status, weight, group_id FROM servers WHERE group_id = 'my_first_fabric' 150722 5:30:04 13 Query SELECT group_id, description, master_uuid, master_defined, status FROM groups WHERE group_id = 'my_first_fabric' 13 Query SELECT server_uuid, server_address, mode, status, weight, group_id FROM servers WHERE group_id = 'my_first_fabric' 150722 5:30:06 13 Query SELECT group_id, description, master_uuid, master_defined, status FROM groups WHERE group_id = 'my_first_fabric' 13 Query SELECT server_uuid, server_address, mode, status, weight, group_id FROM servers WHERE group_id = 'my_first_fabric' 150722 5:30:08 13 Query SELECT group_id, description, master_uuid, master_defined, status FROM groups WHERE group_id = 'my_first_fabric' 13 Query SELECT server_uuid, server_address, mode, status, weight, group_id FROM servers WHERE group_id = 'my_first_fabric'
となっていた。
こちらはシンプルに、監視対象のサーバの情報を定期的に取得している、ということだろう。
おもしろくもなんともない(笑)。
おしまい。
=====MySQL Fabric検証シリーズ=====
第1弾:UCO-Tech(MySQL Fabricアーキテクチャ編)
第2弾:UCO-Tech(MySQL Fabricインストール&検証準備編)
第3弾:UCO-Tech(MySQL Fabric基本設定編)
第4弾:UCO-Tech(MySQL Fabric死活監視編)
第5弾:UCO-Tech(MySQL Fabricデータシャーディング編)
==================================