2013年7月14日に開催された「July Tech Festa」発表した時の資料です

1. Mysql冗長構成の歴史とトラブル事例
2013/7/14 株式会社ISAO

2. 1.はじめに
◎会社紹介
株式会社ISAO HP http://www.isao.co.jp/
1999年設立。サービスプロバイダとして創業し、エンターテイメント
業界を中心に「MSP」「サポート」「決済」といったサービスを提供中。
（事例紹介）
◎自己紹介
2000年入社。典型的な文系育ち。ゲーム機を修理をしている時に覚醒。
好きなオープンソース：qmail（苦楽を共にしました）

3. • サービスが機能しなくなる！
• 整合性チェックとか時間との戦いが多い！
• 復旧作業は消耗が激しい！（特に深夜、特に一人）
2.Databaseの障害は心に染みる
 代理サーバがサービス継続し機会損失を防ぐ
 自動切替にしておけばオペレーションミスが無くなる
 データの保全性が向上する
DBが停止すると‥
システムも人も健康を維持する為に…

4. LVS1LVS
DB
Master
Heartbeat1
+mon
DB
Slave2
DB
Slave1
Heartbeat1
VIP
webwebAP READ
REPLICATION
LVS1LVS
DB
Master
Heartbeat1
+mon
DB
Slave
DB
newMaster
Heartbeat1
VIP
webwebAP
F/O
3.HA構成1 (Heartbeat1+mon+mysql)（2010年～）
READ
＜正常時＞
VIP
× ×
＜障害時＞
WRITE
・サービスは継続されますが、DBはシングル構成となってしまうので2次障害までは防げない。
・構成を復旧する為には、シングル構成の新MasterDBの更新を停止してdumpを取得する必要がある。
READ
READ
WRITE
REPLICATION
・DB書込はVIPに対して実施。DB参照はLVS経由で3台に分散しています。
・monがmysqlプロセスを監視し、ダウンを検知したらMasterのheartbeatを終了してSlave1が
Masterに昇格します。同時にレプリケーションが崩れるのでSlave2のmysqlも停止します。
・MasterとSlave2のmysqlが停止後、LVSがmysql停止を検知して参照対象から自動で外します。

5. DB
Master
Heartbeat3
DB
Slave
Heartbeat3
VIP
webAP
READ/WRITE
DRBD 排他制御
F/O
DB
Master
Heratbeat3
DB
NewMaster
Heartbeat3
VIP
webAP
Shared
Disk
4.HA構成2 (Heartbeat3+DRBD+mysql)（2009年～）
DRBD Shared
Disk
VIP
＜正常時＞
F/O
＜障害時＞
READ/WRITE
・参照と書込はVIPが割り当てられているMasterに対して実施します。
・heartbeatに登録されているリソースを監視し、異常を検知したらリソース切替えが発生して
Slaveが新たにMasterへ昇格します。
・参照と更新を1台で処理するので高スペックのサーバを用意しなければならない場合があります。
・バックアップや処理の重いリクエストが実行されるとサービスに影響してしまう。
参照の分散や運用目的でSlaveを別途用意する事でサービスが安定します。（HAには出来ない）

6. AWS Cloud
AZ（データセンタ）A AZ（データセンタ）B
Replication
AWS Cloud
AZ（データセンタ）A AZ（データセンタ）B
5.HA構成3 (AmazonRDS+mysql)（2012年～）
×
＜正常時＞
AZ AZ
WRITEREAD
READWRITE
READ
F/O
×
＜障害時＞
AZ AZ WRITE
WRITE
READ
READ
READ
READ
READ
・Multi-AZを有効にすればHA構成となります。切替はVIPでは無くローカルDNSが書き変わります。
・VPC環境に構築すれば、 ELB経由で参照を分散する事が可能になります。
（クラシック環境ではHaproxyなど分散用のインスタンスを構築する必要があります）
・RDSインスタンスとmysqlはamazon側で対応してくれるので作業工数が激減出来ます。
・Multi-AZ構成で切替りが発生すると、Readレプリカのレプリケーションが停止する事があります。
対処としては、再作成（削除→ Readレプリカ作成）が必要となります。
・更新はMaster1台で実施されるので、高負荷時はスケールアップかDB分割で対応します。
・ユーザ権限や設定変更出来ないパラメータがあったりと自由度は若干下がります。

7. LVS1
DB
Master
MHAnode
Admin
MHA
manager
DB
Slave
MHAnode
DB
Slave
MHAnode
VIP
webwebAP
LVS
LVS1
DB
Master
MHAnode
Admin
MHA
manager
DB
newMaster
MHAnode
DB
Slave
MHAnode
VIP
webwebAP
LVS
※切り替えた後に
Managerは停止
chck
6.HA構成4 (MHA)（2012年末～）
VIP
F/O
＜正常時＞ ＜障害時＞
REPLICATION
READ
READ
WRITE
REPLICATION
READ
READ
WRITE
・ManagerがMasterDBの状態をチェックし、異常を検知するとSlaveの中から次のMasterに昇格する
Slaveを選定する。（標準でポジションが最も進んでいるSlave。予め指定する事も可能）
・ Masterのバイナリログを昇格するSlaveにを転送して、差分解消後にMasterへ昇格する。
・新Masterと他Slaveも差分解消後、新たにレプリケーション構成となり稼働し続けます。
・SlaveはMasterのサーバスペックに合わせておかないと切替り後に負荷に耐えられなくなります。
・思い通りの動作を実現する為には拡張スクリプトを使用する事が前提となります。

8. 7.MHAに期待されている事と落とし穴
▽メリット
3台以上(slave２台以上)で構成すれば、Masterが停止してフェイルオー
バーが発生しても2台以上のMaster・Slave環境が維持出来ます。
負荷耐性やデータ保全性が格段に向上したので、障害が発生しても品質
が低下しなくなりました。
３台以上の構成にしておけば、障害後構成を復旧する為に、サービスを
停止してdumpをとらなくても良くなりました。
▽デメリット
Managerと他の用途を相載せにする場合は、DBへの接続頻度を事前に
設計しておく必要があります。「max_connect_errors」 の閾値超過で
mysqlに拒否されてしまう事がある。
切替りの度にホスト命名規則と役割が変わります。たくさんの人がDB操
作するサービスでは、誤って旧Masterに更新がされないように最新の
Master情報を共有しておく必要があります。
2013年に入ってMHA構成を希望されるお客様がとても増えてきています。

9.  開発者、松信嘉範氏のブログ
http://yoshinorimatsunobu.blogspot.jp/2011/07/announcing-mysql-mha-mysql-master-
high.html
• 公式サイトのチュートリアルを参考に導入しましょう。
https://code.google.com/p/mysql-master-ha/wiki/Tutorial
※最近は解説ページがインターネット上にたくさんありますので探してみて下さい。
＜導入までの流れ＞
※構築済の環境にあとから導入する事も可能です
１．普通にmysqlをMaster-Slave構成を構築する。
２．Nodeサーバに「MySQL-MasterHA-Node」を導入し、managerサーバに
「 MySQL-MasterHA-Node 」と「MySQL-MasterHA-Manager」を導入する。
３． managerサーバに設定ファイル設置し、拡張スクリプトがあれば
スクリプトを用意する。
４．managerからnodeに対して、Rootでsshの公開鍵認証とmysql接続が
できるようにする。
５．付属コマンドでssh接続とレプリケーションのチェックを行う。
６． managerサーバでサービスを起動し、ステータスを確認する
７．必要であれば切替の試験を行う。
8.導入方法について
＜参考サイト＞

10. ▽Managerは専用サーバを用意する必要があるのか
・HA（heartbeat）のSlaveサーバでも負荷が低いので動作可能です。
▽Managerサーバはシングル構成でも安全と言えるのか
・MHAの管理プロセスは、停止しても直接サービスに影響はありません。
プロセス監視で停止したら手動で起動する対応で充分だと思います。
気になる方はheartbeatを使って冗長化するのも可能です。
▽リレーログの自動パージは無効の方が安全です。
mysql> set global relay_log_purge=0;
パージする仕組みを別にcronとかに登録しておく
▽手動でDB切替を実行したい場合
・マネージャーを停止すれば切替コマンドが発行可能になります。
# masterha_master_switch --master_state=alive --conf=/etc/app1.cnf
9.実際に運用していると気になる事

11. 構成名 メリット デメリット・制約
Heartbeat1+mon+mysql 管理ノード不要
NW周りの監視F/Oの作りこみ不要
参照の多いサービス向け
実績数は最多、様々な構成を構築。
F/O後の構成はシングルとなる
構成復旧の為に計画停止が必要
F/O時のデータロスト有（非同期）
VIPが使えないクラウドでは利用不可
Heartbeat3+DRBD+mysql 管理ノード不要
NW周りの監視F/Oの作りこみ不要
F/O時のデータロストを防げる
商用ソフトとストレージで高機能な
構成とする事が可能
F/O後の構成はシングルとなる
構成復旧の為に計画停止が必要
共有DISKは排他制御の為稼働効率が低い。
データが破損した場合復旧出来ない
クラウドだけで組んでもメリットがない
AmazonRDS 管理ノード不要
F/O時のデータロストを防げる
簡単にHAやSlaveを構築できる
PITRが標準機能で搭載されている
DISKがSpikeした際にF/Oが生じやすい
F/O後Readレプリカの再作成が必要
定期的にメンテナンスが発生する
Amazonの仕様で変更不可の設定がある
MHA F/O後にreplicationが再構成される
F/O後も冗長構成が維持される
構成復旧の計画停止が不要
大規模環境での運用実績が増えている
管理ノード必要
Mysql5.5までが対象(2013/4現在)
拡張スクリプトのカスタムが必要
運用実績が現在増加中
Mysqlfailover（参考） F/O後にreplication自動復旧
F/O後構成がシングルにならない
（3台以上の場合）
構成復旧の計画停止不要
管理ノード必要
MySQL5.6以降でGTID有効必須
エンジンとSQLに制約あり(MyISAM他)
VIP管理は自作スクリプトで対応
公開情報は少ない
10.Mysql HA構成のポイント比較

12. 11.最後に
御静聴ありがとうございました。
一緒に働くモノノフを募集中です。