Embed Size (px)
DESCRIPTION
MySQL Casual v2
Citation preview
1
MySQL Master High Availabilitymanager and tools (MySQL MHA)
株式会社 ディー・エヌ・エー
MySQL Geek, Oracle ACE Director
松信 嘉範 (MATSUNOBU Yoshinori)
Twitter: @matsunobu
2
MySQLマスター障害対応の課題
id=99
id=100
id=101
id=102
master
slave1 slave2
id=99
id=100
id=99
id=100
id=101
・MySQLのレプリケーションは非同期または
準同期
・マスター障害時に、一部のスレーブ(あるいは全部のスレーブ)が
最新のバイナリログを受け取っていない可能性がある
・スレーブ間で、バイナリログの転送状況にずれが生じている可能性がある・左図の例では、id=102はどのスレーブにも
転送されていない・id=101はスレーブ2にしか転送されていない・スレーブ3ではid=100, id=101を受け取っていない
正しく復旧するには、・id=102をマスターから転送する
・スレーブ間でのずれを解消する必要がある
これを全自動でやるのがMHA
slave3
id=99
Writer IP
1. Save binlog events that
exist on master only
2. Identify which events are not sent
id=101id=100
id=101
3. Apply lost events
id=102 id=102 id=102
3
MHAのアーキテクチャ
� マスターの稼働監視およびダウン時の自動フェイルオーバーを実現するツール� http://code.google.com/p/mysql-master-ha/� Pure Perl
� MySQL 5.0以降で動作� 管理サーバ(MHA Manager)と、個々のMySQLサーバでバイナリログの
差分修復等を行うツール(MHA Node)から構成される� モジュールの依存関係は少ない
– NodeパッケージはDBD::mysqlのみ– ManagerパッケージはConfig::Tiny, Log::Dispatch, Parallel::ForkManager, DBD::mysql,
MHA::Nodeに依存しているが、だいたい1-2箇所に入れれば十分
master
slave1 slave2 slave3
Manager
MySQL-MasterHA-Manager
- masterha_manager
- masterha_master_switch
MySQL-MasterHA-Node
- save_binary_logs
- apply_diff_relay_logs
- purge_relay_logs
master
slave1 slave2 slave3
4
内部的な動作
Final Relay_Log_File,
Relay_Log_Pos
Master_Log_File
Read_Master_Log_Pos
Latest SlaveDead Master
(i1)
(i2)
(X)
Slave(i)
Wait until SQL thread
executes all events
� SQLスレッドが実行を終えるまで待つ (i1)
� 最新スレーブのリレーログログのヘッダを解析して各スレーブに適用すべき差分位置を特定(i2)
� マスターにアクセス可能なら、マスターから差分を保存(X)
� i1->i2->Xをすべて組み立て1個のバイナリログにする (Format Description Eventは内部的にROLLBACKを生成しうるので先頭のみ)
� mysqlbinlogして実行� 上記をスレーブ間で並列で行なう
5
主要な拡張ポイント
� shutdown_script� 電源強制OFFなど
� フェイルオーバーの直前に呼ばれる
� master_ip_failover_script� マスターIPアドレスの更新(Virtual IPを更新したり、アプリケーション
から見ているマッピングテーブルを更新したり)
� フェイルオーバーの直前と、マスター復旧後に呼ばれる
� report_script: フェイルオーバーの可否と詳細情報をメール通知したり� フェイルオーバーの終了後に呼ばれる
6
ほかの方法との比較
� Pacemaker + DRBDに対する優位性� スタンバイサーバが要らず、全サーバを有効活用できる� フェイルオーバー時間が高速(検知に10秒程度、切り替えに4秒程度)
– アクティブ/スタンバイ型ならクラッシュリカバリに1分単位は見ないといけない
� 既存環境にそのまま入れることができる
� MySQL Cluster / Galeraに対する優位性� 難しくない (当社比)
� 既存環境にそのまま入れることができる
� MySQL-MMMに対する優位性� MySQL-MMMはそもそもHAソリューションではない
– 稼働監視のNW経路が1本しかない
– マスター障害の状況によっては高確率で切り替えが止まる– 差分修復をしていない– 多数のVirtual IPが必須– 切り替えが連続して起こる可能性があり、それを防ぐ手段が無い
� その他の特徴� 任意のスレーブを新マスターにできる (最新でなくても)
� フェイルバックをするのが面倒。障害マスターへの復旧には多くの場合作り直しが必要– Fully durable settings (innodb_flush_log_at_trx_commit=1, innodb_support_xa=1
sync_binlog=1)でなければほかのHAソリューションでも同じ欠点がある
7
FAQ
� どこで使ってるの?� Mobageのサービスで全面的に使っています (150系統以上)
� DeNAに入社すれば動いている様子が見れます
� 日本語のドキュメントは?
� 英語版を作って力尽きました� DeNAに入社すれば日本語版Wikiが見れます
� テストケースが見当たらないんだけど� 100個くらいあるんですが、まだ公開してません� DeNA環境依存のものは公開できないので。
DeNAに入社すれば見れます
� 拡張ポイントのサンプルコードが動かない� サンプルなので。
DeNAに入社すれば本番環境で動いてるものが見れます
* 興味のある方は([email protected] or [email protected])にご連絡ください
