MHA + HAproxyによるMySQLの冗長構成の検証 (フェイルオーバー編) - s_tajima:TechBlog
前回の記事で作成したMHA + HAproxyのMySQLクラスタで、フェイルオーバーの実験をしてみた。 MySQL Cluster of MHA + HAproxy (FAILOVER) from Satoshi Tajima 想定する状況 フェイルオーバー時のレプリケーションの状態は、上のスライドの図1のような状態を想定。 master(mysqlserver-a), slave*2台の構成。 slv1(mysqlserver-b)はt1までをDBに反映済み。t3までのrelay-logを受信済み。 slv2(mysqlserver-c)はt0までをDBに反映済み。t2までのrelay-logを受信済み。 この状況でmasterが(物理障害などで)OSごと停止した状況を想定。 MHAがどのようにリカバリを行うかを調査する。 検証環境構築の準備 MySQLのレプリケーション構成、MHAの
MHA + HAproxyによるMySQLの冗長構成の検証 (環境構築編) - s_tajima:TechBlog
現在運用中の、Heartbeat + DRBDによるMySQLクラスタ環境の改善を試みるために、 MHA + HAproxyによるMySQLクラスタ環境をテスト中。 今回は環境を整えるところまで。 環境構築 AWS上に以下の図と文章で示すような環境を構築。 MySQL Cluster of MHA + HAproxy from Satoshi Tajima webserver, manageserver, mysqlserver * 3台(master, slave, slave) (今回はwebserverとmanageserverを同じインスタンスに同居させた) webserverは同ホスト上で稼働しているHAproxy経由でMySQLサーバーにアクセス 初期状態 127.0.0.1:3310でmysqlserver-aのmysql(master)に接続。WRITE処理を行う想定。 1
#11 MySQL Master HA を AWS で動作させる場合のフェイルオーバー支援ツール MHA::AWS のご紹介 - KAYAC engineers' blog
こんにちは、@fujiwara です。 2013年を振り返ると、春の新卒研修での社内ISUCON、秋のISUCON予選と本選でずっとISUCONをやっていたような気がしていまして、さてそれ以外になにか……そういえばインフラ回りの仕事もしていましたね。 カヤックのサーバインフラ全体としては、Amazon Web Service(AWS) への移行が進んだ1年でした。いままで自社サーバでやっていたソーシャルゲームや、比較的アクセスが多いとある自社サービス(これは後ほど事例公開されるかも知れません) を、AWS上で構築したり移行したり、という仕事が多かったです。 AWSでサービスを構築する場合、MySQL については RDS を利用する EC2 インスタンス上に MySQL サーバを稼働させる というどちらかの手段を取ることになります。 RDSはフェイルオーバーやバックアップを自動でやってくれま
MySQLレプリケーションをMHAとHAProxyでフェイルオーバさせてみた - Tech-Sketch
MySQL には標準でレプリケーション機能が組み込まれており、下図の様なシステム構成とすることで、データの冗長化と参照処理の負荷分散を容易に実現できます。この構成では更新処理はマスタサーバで行うことになりますが、 参照処理は全てのサーバに分散して行えます。 ここでサーバの1台が何らかの障害で停止した場合を考えましょう。スレーブサーバの1台が停止した場合、マスタサーバや他のスレーブサーバで参照処理を継続できるため、停止したサーバへクライアントが参照クエリを送信しないように変更する必要はありますが、システム全体に大きな影響を与えません。 一方、マスタサーバが停止した場合、更新処理が停滞して業務継続に影響します。そのためマスタサーバは手厚く監視する必要があり、もしマスタサーバが停止した場合には業務を継続するため以下の作業が必要です。 最も最新に近い更新内容が反映されているスレーブサーバを選択し、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
