• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Introducing MySQL MHA (JP/LT)
 

Introducing MySQL MHA (JP/LT)

on

  • 15,208 views

MySQL Casual v2

MySQL Casual v2

Statistics

Views

Total Views
15,208
Views on SlideShare
7,819
Embed Views
7,389

Actions

Likes
10
Downloads
62
Comments
0

15 Embeds 7,389

http://mysql-casual.org 4882
http://d.hatena.ne.jp 1209
http://snipsnaptmae.wordpress.com 678
http://snip-snap.posterous.com 540
http://webcache.googleusercontent.com 40
http://twitter.com 16
http://ist-dev.private.i-studio.co.jp 12
http://www.linkedin.com 2
https://twitter.com 2
http://www.slideshare.net 2
https://www.linkedin.com 2
http://a0.twimg.com 1
http://s.deeeki.com 1
http://mysql-casual.sakura.ne.jp 1
https://www.google.co.jp 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

Introducing MySQL MHA (JP/LT) Introducing MySQL MHA (JP/LT) Presentation Transcript

  • MySQL Master High Availabilitymanager and tools (MySQL MHA) 株式会社 ディー・エヌ・エー MySQL Geek, Oracle ACE Director 松信 嘉範 (MATSUNOBU Yoshinori) Twitter: @matsunobu 1
  • 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
  • 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
  • 内部的な動作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 上記をスレーブ間で並列で行なう
  • 主要な拡張ポイント shutdown_script 電源強制OFFなど フェイルオーバーの直前に呼ばれる master_ip_failover_script マスターIPアドレスの更新(Virtual IPを更新したり、アプリケーション から見ているマッピングテーブルを更新したり) フェイルオーバーの直前と、マスター復旧後に呼ばれる report_script: フェイルオーバーの可否と詳細情報をメール通 知したり フェイルオーバーの終了後に呼ばれる 5
  • ほかの方法との比較 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
  • FAQ どこで使ってるの? Mobageのサービスで全面的に使っています (150系統以上) DeNAに入社すれば動いている様子が見れます 日本語のドキュメントは? 英語版を作って力尽きました DeNAに入社すれば日本語版Wikiが見れます テストケースが見当たらないんだけど 100個くらいあるんですが、まだ公開してません DeNA環境依存のものは公開できないので。 DeNAに入社すれば見れます 拡張ポイントのサンプルコードが動かない サンプルなので。 DeNAに入社すれば本番環境で動いてるものが見れます * 興味のある方は(Matsunobu.Yoshinori@dena.jp or Yoshinori.Matsunobu@gmail.com)にご連絡ください 7