MySQLの冗長化モデルです。 Master及びSlaveそれぞれを冗長化する手法を説明しています。

1. MYSQL 冗長化モデル

2. １章
基本設計

3. 1-1 DB（MySQL）の冗長化とは何
か
 MySQLはMaster・Slaveの構成を行いますが、これは『更新』と『参照』と
役割が異なっているだけであり、冗長化とは意味が異なります
 プログラム上で『更新』『参照』についてそれぞれの宛先（IP）を役割毎
にハードコートしており、どちらか片方に障害が起こるとサービスに影響
が出ます
⇒『更新（Master）』『参照（Slave）』を、それぞれ
冗長化する必要があります

4. 1-2 冗長化に向けた設計方針
 サーバーHW障害に対し、サービスが継続できること
 障害時のダウンタイムが限りなくゼロであること
⇒24h/365dサービスを目指すため、ボトルネックを可能な限り減らす
 障害発生時には自動的にサービス復帰する
⇒運用の自動化により、運用の安定化及び省力化を目指す
 プログラムは障害対応を意識せずにコーディングできること
⇒障害に備えたプログラムコーディングは、コードの肥大化とともにコーディング漏れ等の人的
災害も起こりえる
 スケールアウトできること
⇒サーバー1台の処理能力がサービススペックの頭打ちにならないように
⇒拡張性を考慮することで、DBがボトルネックにならないように
 待機サーバーの数を可能な限り減らし、資産を有効活用する
⇒『備え』の工数を増やしても、稼働のサービスレベルは上がらない

5. 1-3 冗長化を支える技術
ミドルウェ
ア
役割
MySQL データベースサーバー
LVS MySQLサービス自体の死活監視を行い、MySQLを仮想化する
Iptables 『MySQLサーバーは生きているが、サービスに問題が有る』場
合に、仮想サービス自体から切り離す

6. ２章
詳細設計

7. 2-1 全体構成図
LVS#1 LVS#2
Master
稼働
Master
待機
Slave#
1
Slave#
2
仮想IP#1 仮想IP#2

8. 2-2 MySQL仮想化
LVS#1 LVS#2
Master
稼働
Master
待機
Slave#
1
Slave#
2
仮想IP#1 仮想IP#2
クライアントはMySQLにアクセ
スする際、『LVSが作成した仮想
IP』にアクセスします。
LVSはクライアントからの信号を
MySQLに転送します。
LVSはMySQLサーバーの生死判
定を定期的に行っております。
この処理によって、仮想IPへアク
セスされた信号は、現在生きてい
るサーバーへと転送されます。
この機能を利用し、『更新』『参
照』それぞれのMySQLを仮想化
しております。

9. 2-3 MySQL同期処理
LVS#1 LVS#2
Master
稼働
Master
待機
Slave#
1
Slave#
2
仮想IP#1 仮想IP#2
MySQLはレプリケーション処理によって、２つのMySQLサーバーが同一になる機能
があります。詳細としては、参照先のMySQLの更新命令を参照元に適用すること
で、双方が同一になるというものです。
現在は下記矢印の向きで更新命令を参照している状態です。上記機能を利用し、
Master（稼働・待機）に更新が入ると、4台のMySQLに適用されますので同一の状
態になります。

10. ３章
障害対策

11. 3-1 MySQL障害対策/前提
LVS#1 LVS#2
Master
稼働
Master
待機
Slave#
1
Slave#
2
仮想IP#1 仮想IP#2
MySQLの仮想化の最大のポイントとなるのは、
『参照先サーバーに障害があった場合は、自分自身
の情報は信頼出来ないものとする』事です。つまり
『参照元から更新情報が得られない』＝『自分自身
の情報は最新でない』という考えです。
これを実現するために、『自分自身のレプリケー
ションになんらかの障害が発生していた』場合、
『親からの死活監視に無応答を返す事で、自発的に
仮想化から切り離す』処理を行なっております。
これはLinuxのファイアーウォール機能である
iptablesによって実現しております。

12. 3-1 MySQL障害対策/Slave障害
LVS#1 LVS#2
Master
稼働
Master
待機
Slave#
1
Slave#
2
仮想IP#1 仮想IP#2
Slaveに障害が起こった場合は、『仮想IP=2台』と
いう割り当てから『仮想IP=1台』という形に縮退動
作を行います。
また、すべてのSlaveに障害が発生した場合は『仮
想IP=Master待機』へと割り当てが行われます。

13. 3-2 MySQL障害対策/Master待機障
害
LVS#1 LVS#2
Master
稼働
Master
待機
Slave#
1
Slave#
2
仮想IP#1 仮想IP#2
Master待機に障害が発生した場合は、2ステッ
プの縮退動作が行われます。
1. LVSの監視により、『仮想IP#1』から
『Master待機』が切り離される
2. Slave#1自身がMaster待機の障害を検知し
た時点で、LVSの死活監視に応答を返さな
い処理を行う。これにより、『仮想IP#2』
から『Slave#1』が切り離される

14. 3-3 MySQL障害対策/Master稼働障
害
LVS#1 LVS#2
Master
稼働
Master
待機
Slave#
1
Slave#
2
仮想IP#1 仮想IP#2
Master稼働に障害が発生した場合は、3ステッ
プの縮退動作が行われます。
1. LVSの監視により、『仮想IP#1』から
『Master待機』が切り離される
2. Slave#1自身がMaster待機の障害を検知し
た時点で、LVSの死活監視に応答を返さな
い処理を行う。
3. LVSがMaster障害を検知した段階で、
『Master待機』を『Master稼働』に昇格さ
せる

15. 3-4 仮想IP冗長化
LVS#1 LVS#2
Master
稼働
Master
待機
Slave#
1
Slave#
2
仮想IP#1 仮想IP#2
LVSはハートビート
（VRRP）信号でお互いの生
死判定を行います。
『稼動系LVS』が死んだ場合
は、『待機側LVS』が仮想IP
を自分自身に割り当てます。
これにより仮想IPは、LVS
サーバー2台に障害が発生し
ない限りサービスを継続する
ことができます。

16. 3-5 MySQLスケールアウト
LVS#1 LVS#2
Master
稼働
Master
待機
Slave#
1
Slave#
2
仮想IP#1 仮想IP#2
将来的にサイトへのアクセスが集中し
MySQLがボトルネックとなった場合は、
参照用仮想IPアドレスにSlave用MySQL
を追加することになります。
応答するサーバーが増加する為、負荷軽
減となります。（スケールアウト）
Slave#
3

17. 4章
まとめ

18. まとめ
DBサーバーは情報が一元集約されるポイントの
ため、単一障害点かつ高負荷になりやすいで
す。
そのため既存のソリューションでは、あらゆる
高負荷に耐えられる筐体を用意する方向に進ん
でおりました。（スケールアップ）
本設計はこの問題点を解消し、かつスケールア
ウトを確保出来るものとなっております。

19. 以上