Más contenido relacionado La actualidad más candente (20) Similar a MHAを検証して導入した話 (20) MHAを検証して導入した話2. MHA とは
MHA とは MySQL のマスタ障害時に最新のス
レーブをマスタとして他のスレーブの差分を
補完しマスタの向き先を変えてくれるプロダ
クト。 replication の復旧を自動的にしてくれ
るもの。
VIP を移動するのは自己責任。
MHA for MySQL は Master High Availability
Manager and tools for MySQL の略らしいです。
作者の日本語スライド
http://www.slideshare.net/matsunobu/mha-for-mysqlden
3. 検証のきっかけ
じつは MHA はきっと使いたいと要望が出
るに違いないと思って、産休直前に松信
さんの英語の .ppt を英語講習の先生とマ
ンツーの時間に一緒に訳してた。
そして育休から復帰するのを待ってたか
のようにお客様要望が複数きてるので検
証せよとご依頼が。
だってサービスレベルあがるもんね、そ
うよね。
4. DB の負荷分散と冗長化の構成
Before
LVS で分散して HertbeatV1+mon+mysql で冗長
化
LVS1LVS
DB
Master
Hertbeat1
+mon
DB
Slave2
DB
Slave1
Hertbeat1
VIP
webwebwebwebwebweb
write
read
repl
read
repl
6. DB の負荷分散と冗長化の構成
After
LVS で分散して MHA+mysql で冗長化
※manager は Admin サーバと相乗り
LVS1
DB
Master
MHAnode
Admin
MHA
manager
DB
Slave
MHAnode
DB
Slave
MHAnode
VIP
webwebwebwebwebweb
write
read
repl
repl
read
LVS
chk
7. DB の負荷分散と冗長化の構成
After
Failover すると、 replicaiton も再構成され
る
LVS1
DB
Master
MHAnode
Admin
MHA
manager
DB
newMaster
MHAnode
DB
Slave
MHAnode
VIP
webwebwebwebwebweb
write
read
repl
read
LVS
※ 切り替えた後に
、
manager も落ちま
す
8. そのたの構成(余談)
HertbeatV3+DRBD+mysql
→ 1 台無駄 ( 共有ディスクで排他制御 ) でスケールしないのがヤ
ダって言われることがおおい
RDS
→値段が高いっていわれることがおおい、 DC 越しに chk してる
せいか無駄に切り替わることが多い ( 規模にもよる )
多段 replication
→昔社内の某案件で大障害がおきたきっかけが多段 replication で
あって、その復旧のために色々な人が寝る間もなかったことは
忘れ難い。
(GTID が有効な場合に中間ノード障害の復旧が難しいかはよ
くわかりません!知ってたらおしえてほしいです)
9. 何が問題だったか、何が嬉しいのか
問題だったのは
フェイルオーバすると、 VIP の移動だけで replication の整合性
までは保障できず、マスタのみのシングル構成になってしまい
負荷に耐えられないのと、
slave の復旧の際は再度マスタを止めて dump をとる必要があ
り、
復旧のための計画停止が必要になってしまっていたこと。
サービス停止時間はデータ量に依存し dump 時間が異なる。
嬉しいことは、
MHA をつかうとフェイルオーバーしても 3 台以上 (slave 2台
以上 ) あれば replication まで再構成されてシングルになること
を防げて負荷耐性が向上したこと。
また3台以上あれば slave 復旧のために dump でサービス停止
する必要がない
10. MHA 導入時の制限事項
mysql5.0 以上、 SBR( ステートメントベー
スレプリケーション ) の場合 LOAD DATA
INFILE を使えない。
MySQL-5.6 の GTID と違って MyISAM つか
えないとか Create..Select できないとかはな
い。
GTID が有効な場合に動作するかは確かめ
ていない。
11. 注意したほうがいいところ ( 監視
等) 物理は大丈夫だけど仮想でコア数が少ない CPU パワーが
貧弱なサーバだと挙動がおかしかった
mysqld をチェックする頻度の調整は可能だが、同じよう
に mysqld を chk する lvs 等と同じサーバに相乗りをする
と host が db から拒否されるので要注意。
デーモンではないためバックグラウンドで起動したのと
同じターミナルでログを tail でみると固まることがあっ
た
仮想 IP に対する監視と manager に対するプロセス監視
は別途必要
slave が死んでも反応しないので、別途検知できる必要
がある
通常切り戻しはしない運用になると思われる ( マスタ切
替るなら念のためメンテ入れることになると思う ) ので
どちらがマスタかややわかりづらいのでつど確認するの
と、リレーログパージの cron の有効無効化を忘れないよ
うに注意必要。
12. どういう動きをするのか動作フェーズ
1 ログをみるとかいてあるよ ( 作者のスライドの P.8 に図があります )
# grep Phase manager.log |head -20|grep -v completed
* Phase 1: Configuration Check Phase..
* Phase 2: Dead Master Shutdown Phase..
* Phase 3: Master Recovery Phase..
* Phase 3.1: Getting Latest Slaves Phase..
* Phase 3.2: Saving Dead Master's Binlog Phase..
* Phase 3.3: Determining New Master Phase..
* Phase 3.3: New Master Diff Log Generation Phase..
* Phase 3.4: Master Log Apply Phase..
* Phase 4: Slaves Recovery Phase..
* Phase 4.1: Starting Parallel Slave Diff Log Generation Phase..
* Phase 4.2: Starting Parallel Slave Log Apply Phase..
* Phase 5: New master cleanup phease..
13. どういう動きをするのか動作フェーズ
2 フェイルオーバ時の動作は以下のとおり。(ログから追った動き)
※ SQL 処理のスレッド実行が終わった後
①config(/etc/app1.cnf) から各ノード情報を読み込む
②newMaster の VIP を停止する
③newMaste の mysqld を停止
④ 各 Slave リレーログを解析して次マスターの選出と差分位置を特定
⑤oldMaster にアクセス可能であればバイナリーログをローカルに
(/var/log/masterha/app1) コピーする
⑥⑤ で引き上げた最新のバイナリーログを newMaster(/var/log/masterha/app1) にコ
ピー
⑦oldMaster との差分を newMaster で更新
⑧neMaster に VIP を付与する
⑨newMaster の read-only を解除
⑩⑤ で引き上げた最新のバイナリーログを newSlave(/var/log/masterha/app1) にコピー
⑪oldMaster サーバとの差分を newSlave で更新
⑫newSlave で最新のバイナリーログと relay ログとの差分を確認して適用
⑬newSlave の Master を oldMaster サーバから newMaster サーバに変更し replication 再
開
⑭manager にて app1.failover.complete を /var/log/masterha/app1 に出力して
masterha_manager を停止する
15. manager の設定ファイル
# vi /etc/app1.cnf
---------------------------------
[server default]
# mysql user and password
user=root
password=
ssh_user=root
# working directory on the manager
manager_workdir=/var/log/masterha/app1
manager_log=/var/log/masterha/app1/manager.log
# working directory on MySQL servers
remote_workdir=/var/log/masterha/app1
# master binlog dir
master_binlog_dir=/usr/local/mysql/var
master_ip_failover_script=/usr/local/bin/master_ip_failover
ping_interval=3
[server1]
hostname=192.168.100.1
port=3306
[server2]
hostname=192.168.100.2
port=3306
candidate_master=1
[server3]
hostname=192.168.100.3
port=3306
no_master=1
----------------------------------
メイン設定パラメータ詳細は以下参照のこと
http://code.google.com/p/mysql-master-ha/wiki/Parameters
※ 他にあったほうがいいかもしれないパラメータ
secondary_check_script
2 つ目のインターフェースからも
チェックしてくれるスクリプトとホストを指定
ignore_fail
2 つ目のスレーブが落ちてもマスタが落ちたら
切り替えたい場合に無視していいスレーブに指定
16. master_ip_failover スクリプトが
要修正
めんどくさいから VIP は Heartbeat でいい
じゃないと思ったらお客さんに拒否され
てしまった
拾ってきたやつを修正しました
( https://gist.github.com/2310502 )(ダサ
くてすみま ry
やりたいことは、更新用の VIP を旧マス
タから新マスタに移すのと LVS の参照分
散の重みを変えること、旧マスタを落と
すこと
17. 参照分散との連携の拡張
system コマンドで perl(master_ip_failover
スクリプト ) からシェルを呼び出すように
しました。(ダサくてすみま ry
system("/usr/local/bin/mod_lvs_weight.sh");
参照 VIP がついてるほうを確かめてついて
るほうの重みを変える処理をします。
(force reload で強制的に設定変更します )
18. リレーログを定期的にパージする必
要がある (cron 登録 )
slave ごとに時差があったほうが復旧できるデータが残って
る確立が上がります。
mysql> set global relay_log_purge=0;
# crontab -e
----------slave1----------
30 2,4,6,10,14,16 * * * /usr/bin/perl /usr/bin/purge_relay_logs
--user=root --password=`cat /root/.mysql_pwd`
--disable_relay_log_purge >>
/var/log/masterha/purge_relay_logs.log 2>&1
----------slave2----------
30 3,5,9,11,15,17 * * * /usr/bin/perl /usr/bin/purge_relay_logs
--user=root --password=`cat /root/.mysql_pwd`
--disable_relay_log_purge >>
/var/log/masterha/purge_relay_logs.log 2>&1
--------------------------
※ ioDrive とか SSD とかマウントしてるならハードリンク先
のディレクトリ指定する必要があります。
19. マスタを手動切替したい場合
MHA マネージャが落ちていてマスタ ( と更新用 VIP) を
手動切替したい場合
# masterha_master_switch --master_state=alive
--conf=/etc/app1.cnf
※ ほんとにやっていいか聞かれるので承諾する。 MHA
マネージャが起動してると落とせと怒られる。
( VIP※ は処理を追加しないと切り替わらない )
http://code.google.com/p/mysql-master-
ha/wiki/masterha_master_switch
もし VIP も切替えたい場合は master_ip_failover スクリ
プトと同じように修正する必要がある