タグ

MHAに関するmasudaKのブックマーク (5)

  • MHA for MySQL の話

    2. me • Masahiro Nagano • @kazeburo • NHN Japan • Operations Engineer Site Reliability 運用系小姑 Perl Monger 2013年3月8日金曜日 3. MHA for MySQLとは • 元DeNA・現facebookの松信さんによる MySQLのmaster冗長化ツール • Master High Availability の略 • MySQLサーバを監視してのフェイルオーバー とオンラインでのマスター切り替えをサポート • Proxy型ではないのでSPOFにならない • サーバの切り替えは別スクリプトを起動 2013年3月8日金曜日

    MHA for MySQL の話
  • MySQL を MHA + HAProxy で冗長化してみよう

    斎藤です。こんにちは。 今日は、MySQLにてレプリケーション構成において、マスタサーバのフェイルオーバーを司るmysql-master-ha(以下、MHA)を用いる際、マスタサーバ接続先の切り替えにHAProxyを使ってみようというお話です。 ※MHAは0.53.0(公式パッケージ)、MySQLは5.5.25a(Oracle公式パッケージ)、HAProxyは1.4.22(CentOS6標準パッケージ)、OSはCentOS 6.3 x86_64を用いました。 ※MHAによる冗長化およびHAProxyによるMySQLの負荷分散の設定を経験された事がある前提で記述します。 記事では、次の流れで話題を展開します。 フェイルオーバー時の接続先切り替え方法 構成(参考) なぜHAProxyなのか 切り替え方 2台構成の問題点 その他 コツ 設定(参考) 主にMHA+HAProxyによるフェイルオー

    MySQL を MHA + HAProxy で冗長化してみよう
  • My sqlのha構成について

    2.  形あるものは必ず壊れるのでリカバリが必要  止められないサービスなら切り替わる必要がある  復旧にかかる時間を自動化により削減したい  サービス断時間を少なく抑え機会損失を防ぐ  復旧操作の自動化により人によるオペーレーション の不確実性を緩和  復旧時の人的リソースを削減できる  データの保全性を向上 ※HA構成はバックアップの代用にはなりません (オペレーションミスもレプリケーションされるためです) 3.  従来の冗長構成(heartbeat+mon+mysql)  MHA(mysql5.5まで)  mysqlfailover(Mysql5.6以降) (費用的に)需要が少ないが以下構成も可能 • AmazonRDS(現在MySQL5.5まで、排他制御) • Heartbeat-v3+SharedDisk構成(排他制御) ※PostgreSQL,MySQL+V

    My sqlのha構成について
  • MHA 0.54 & 0.55 – continually active development

    I think it’s worth noting that since January 2012 there was no changes to MHA (0.53). Yoshinori Matsunobu made two releases in December (release notes), one in time for my Percona Live London 2012 talk. Thanks Yoshi! Totally download MHA 0.55 which is still be actively developed & used in production at multiple locations.

    MHA 0.54 & 0.55 – continually active development
    masudaK
    masudaK 2013/01/09
  • Automating master failover is possible but needs care

    I was asked from a few people about my opinion of the Github's recent service outage. As a creator of MHA, I have lots of MySQL failover experiences. Here are my points about failover design. Most of them duplicate with Robert's points. - "Too Many Connections" is not a reason to start automated failover - Do not repeat failover I know some unsuccessful failover stories that "1. failover happens b

  • 1