Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
MySQL Master High Availabilitymanager and tools (MySQL MHA)           株式会社 ディー・エヌ・エー         MySQL Geek, Oracle ACE Direct...
MySQLマスター障害対応の課題                                      ・MySQLのレプリケーションは非同期または         Writer IP                    準同期    m...
MHAのアーキテクチャ  Manager                                               masterMySQL-MasterHA-Manager- masterha_manager- masterh...
内部的な動作Dead Master     Latest Slave                         Slave(i)                                                       ...
主要な拡張ポイント shutdown_script    電源強制OFFなど    フェイルオーバーの直前に呼ばれる master_ip_failover_script    マスターIPアドレスの更新(Virtual IPを更新したり、アプリ...
ほかの方法との比較 Pacemaker + DRBDに対する優位性    スタンバイサーバが要らず、全サーバを有効活用できる    フェイルオーバー時間が高速(検知に10秒程度、切り替えに4秒程度)     – アクティブ/スタンバイ型ならクラ...
FAQ   どこで使ってるの?      Mobageのサービスで全面的に使っています (150系統以上)      DeNAに入社すれば動いている様子が見れます   日本語のドキュメントは?      英語版を作って力尽きました      D...
Upcoming SlideShare
Loading in …5
×

Introducing MySQL MHA (JP/LT)

MySQL Casual v2

Introducing MySQL MHA (JP/LT)

  1. 1. MySQL Master High Availabilitymanager and tools (MySQL MHA) 株式会社 ディー・エヌ・エー MySQL Geek, Oracle ACE Director 松信 嘉範 (MATSUNOBU Yoshinori) Twitter: @matsunobu 1
  2. 2. MySQLマスター障害対応の課題 ・MySQLのレプリケーションは非同期または Writer IP 準同期 master ・マスター障害時に、一部のスレーブ (あるいは全部のスレーブ)が id=99 最新のバイナリログを受け取っていない id=100 可能性がある id=101 id=102 ・スレーブ間で、バイナリログの転送状況に 1. Save binlog events that ずれが生じている可能性がある exist on master only ・左図の例では、id=102はどのスレーブにも 転送されていない ・id=101はスレーブ2にしか転送されていない ・スレーブ3ではid=100, id=101を受け取っていないslave1 slave2 slave3 正しく復旧するには、 id=99 id=99 id=99 ・id=102をマスターから転送する id=100 id=100 id=100 id=101 id=101 id=101 ・スレーブ間でのずれを解消する id=102 id=102 id=102 必要がある2. Identify which events are not sent 3. Apply lost events 2 これを全自動でやるのがMHA
  3. 3. MHAのアーキテクチャ Manager masterMySQL-MasterHA-Manager- masterha_manager- masterha_master_switch slave1 slave2 slave3 master MySQL-MasterHA-Node - save_binary_logs - apply_diff_relay_logs - purge_relay_logs slave1 slave2 slave3マスターの稼働監視およびダウン時の自動フェイルオーバーを実現するツール 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箇所に入れれば十分 3
  4. 4. 内部的な動作Dead Master Latest Slave Slave(i) Wait until SQL thread executes all events Final Relay_Log_File, Relay_Log_Pos (i1) Master_Log_File Read_Master_Log_Pos (i2) (X) SQLスレッドが実行を終えるまで待つ (i1) 最新スレーブのリレーログログのヘッダを解析して各スレーブに適用すべき差分位置を 特定(i2) マスターにアクセス可能なら、マスターから差分を保存(X) i1->i2->Xをすべて組み立て1個のバイナリログにする (Format Description Eventは内部 的にROLLBACKを生成しうるので先頭のみ) mysqlbinlogして実行 4 上記をスレーブ間で並列で行なう
  5. 5. 主要な拡張ポイント shutdown_script 電源強制OFFなど フェイルオーバーの直前に呼ばれる master_ip_failover_script マスターIPアドレスの更新(Virtual IPを更新したり、アプリケーション から見ているマッピングテーブルを更新したり) フェイルオーバーの直前と、マスター復旧後に呼ばれる report_script: フェイルオーバーの可否と詳細情報をメール通 知したり フェイルオーバーの終了後に呼ばれる 5
  6. 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ソリューションでも同じ欠点がある 6
  7. 7. FAQ どこで使ってるの? Mobageのサービスで全面的に使っています (150系統以上) DeNAに入社すれば動いている様子が見れます 日本語のドキュメントは? 英語版を作って力尽きました DeNAに入社すれば日本語版Wikiが見れます テストケースが見当たらないんだけど 100個くらいあるんですが、まだ公開してません DeNA環境依存のものは公開できないので。 DeNAに入社すれば見れます 拡張ポイントのサンプルコードが動かない サンプルなので。 DeNAに入社すれば本番環境で動いてるものが見れます * 興味のある方は(Matsunobu.Yoshinori@dena.jp or Yoshinori.Matsunobu@gmail.com)にご連絡ください 7

×