今日は、MySQLにてレプリケーション構成において、マスタサーバのフェイルオーバーを司るmysql-master-ha(以下、MHA)を用いる際、マスタサーバ接続先の切り替えにHAProxyを使ってみようというお話です。x86_64を用いました。※MHAによる冗長化およびHAProxyによるMySQLの負荷分散の設定を経験された事がある前提で記述します。本記事では、次の流れで話題を展開します。コツ設定(参考)主にMHA+HAProxyによるフェイルオーバーの仕組みと設定について解説します。途中でDBが2台の場合のちょっとしたコツについても言及します。次の4つの方法が考えられます。アプリケーション側で対処(1)は、MHAのWikiでも言及されている方法です。Masterの候補となるサーバが2台に絞れるなら設定しやすい方法ではないでしょうか。MHAの情報+misc_checkなどで現在稼働中のマスタサーバを決定できるようにしておけば、実装しやすい方法です。keepalivedはAWSのEC2上ではそのままでは利用できず、unicastパッチを当てる必要があります。AWS上など(2)の手段が取れない場合に有効です。マスタサーバ切り替えのためのミドルウェアが不要な構成です。ITインフラの構成はこの4つの中では最もシンプルになります。アプリケーション側で更新系のクエリを投げるマスタサーバをオンラインで随時切り替えられるようにしておく事が必要です。今回は、(3)を適用して構成する事にしました。構成(参考)図1の通りになりました。説明のため、実環境から整理して記述しています。(図1:論理構成図)ポイントは、HAProxy用のサーバを別途立てず、各Web(DBクライアント)にHAProxyを導入したことです。HAProxyなのか先の選択肢から(3)を選択し、かつ図1の通り各クライアントにHAProxyを導入した理由として、次の事柄がありました。このシステムではネットワークが完全に冗長化されていました。そのため、(1)(2)を採用しようとした場合、ネットワークのフェイルオーバーも含めて検証をする必要がありました。稼働しているシステムの検証は難しく、かつリスクがあります。そのため、(1)と(2)は候補から外れました(※1)。Pacemakerを用いることになります。(A)で説明したように、この場合でもフェイルオーバー時にARPの問題が解決できるか検証する必要があります。これでは(3)を選択するメリットがなくなります。そこで、(3)を採用するにしても、ARPの問題が起きず、かつHAProxyがSPOFにならないよう、各クライアントへの導入を選択しました。(B)より各DBクライアントにHAProxyを導入すると、MySQLの死活監視負荷が台数分増えるという問題がありました。こちらは、検証の結果、今回導入するシステムの台数程度であればDBに対する負荷は問題ない水準である事が確認できました。DBサーバの性能によりアクセス可能な台数が変わりますので、注意が必要です(※2)。以上の3点、特にARPについての問題を最小限にするために、各WebサーバにHAProxyを導入することにしました。概要を図2に示します。肝心な所のみ解説します。(図2:フェイルオーバーの流れ)3では、MHAがフェイルオーバー処理を開始します。Logを最新の状態になるよう処理を行います。処理中、master_ip_failover_scriptで設定したスクリプトを実行しますが、これが4の処理になります。DBのIPアドレスとポート番号を基に、新しいHAProxyの設定を作成します。その後、各Webサーバに設定を頒布しつつ、HAProxyに設定を再読み込みさせます。このとき、参照系の通信は途切れません。DBのread_onlyを解除します。ここで「あれ、MHAが解除しないの?」と思われた方は、後述する「2台構成の問題点」をご覧ください。DBが障害前に3台以上あれば、本処理はMHAが行いますのでmaster_ip_failover_scriptのスクリプトにて実行する必要はありません。本処理ですが、手元の検証環境では15秒で切替りました。Logの処理を鑑みるとこれ以上の時間がかかります。2台構成の問題点MHAは、本来DBサーバを3台以上で稼働させるものです。DBがMaster-Slaveの2台のみである事も珍しくないかと思います。その際にMHAを使いますと、フェイルオーバーを終えようとするときにMHAが「スレーブサーバがいない!」とエラーを出し、停止してしまいます。このとき、master_ip_failover_scriptは走るのですが、新Masterのread_onlyを外す処理が走らず、更新系のDB接続が更新を実行するとエラーとなってしまいます。そのため、回避策としてmaster_ip_failover_scriptの処理の最後で、新Masterのread_onlyを外す処理を入れています。3台以上で運用している場合は問題ありません。先の2台構成時の問題がありますので、respawnのリトライ回数は減らしておくとよいでしょう。3台以上であればこの問題は起きません。Manager側に次の設定ファイルを作成します。3HAProxy設定対象のサーバは、次のファイルに設定を記述します。/opt/masterha/conf/hostlist.txtまた、MySQLに、HAProxyの死活監視用ユーザを作成します。パスワード無しである必要があるため、接続元の制限を行う事をお勧めします。Slave各DBのIPアドレスを保存した後、update_all_proxy.shを実行します。旧MasterをSlaveとして復帰させるときにupdate_all_proxy.shを実行すると、SELECT用のDBが切り替わるため瞬断が発生します。./update_all_proxy.shおわりにここまで、MHAとHAProxyを組み合わせて、MySQLの更新系DBの冗長化を行う事例を紹介しました。Requestの問題がある点を述べています。2台構成の場合は、ちょっとした細工が必要な点もお話ししました。様々な選択肢が存在する中で、自分が携わるITインフラにとってどの手段が適切かを調査・判断し構築・運用する事は、骨は折れますが、なかなか面白いものです。それでは、ごきげんよう。初期構築時に採用する場合は、検証しやすい状況でしょうから(B)を用いたかもしれません。sysがtop上で5%程度になっていました。ここまで上がるのは、TCPのOpen/Closeのオーバーヘッドのせいかと思います。Logの巻き上げを待ちますので、こんなに短くする必要はありません。株式会社ハートビーツの技術情報やイベント情報などをお届けする公式ブログです。こちら「みんな仲良く」「プライドを持って」「変化を楽しむ」という企業理念に共感していただけるエンジニアを募集しています。