Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
諸々の事情により MHA を検証・導入しようという流れがあり、イマイチまだ全体像が見えていないのでまとめてみた。 **MHA とは MySQL のマスタを failover させスレーブをマスタに昇格させるという面倒な作業を短時間(10-30 秒と言われている)で行わせることを目的としたソフトウェア。 一般に、MySQL のマスタ・スレーブ構成を 1 対多という構成で取った場合、スレーブ間でどこまでマスタの DB 状況が反映されているかには差が生じ、これが自動 failover の妨げになっていた。MHA ではこの問題 (replication consistency problem) も解決してくれる仕組みを内在しているため、運用上のスレーブ間の DB 整合性の問題からも開放される。 - ref: Google Code Archive - Long-term storage for G
MHA for MySQL の導入を検討していて、まずは社内の技術者向けに、MHA for MySQL の概要を伝えようと、主に オフィシャルなドキュメント からポイントを抜粋して社内向けの Wiki に書いてみた。本当なら、オフィシャルドキュメント全体に目を通してもらうのがいいんだけど、英語なので、はじめの一歩としては敷居が高く感じる人もいるだろう、ということで。 特に外に出してまずい情報があるわけでもないので、このブログでも曝しておきます。 MHA の概要 MySQL エキスパートとして世界的にも著名な松信嘉範氏による、MySQL マスターの HA 化を行うためのツール。Perl 製。 最小限のダウンタイムで、データの不整合を防ぎつつ、マスターのフェイルオーバーを行う、というのが主な機能。 また、既に動作している MySQL に影響を与えることなく導入できる。 機能は大きくわけると以下
先日(6/22/14)、6月なのにどういう分けか早めに開催されたJuly Tech Festa 2014でConsulについて発表してきた。そのユースケースの一つとしてMySQL failoverをちょっとだけ紹介したので、ここに詳しく書いておく。 MHA MySQLレプリケーションの障害時にフェールオーバーしたい場合、MHAを使うの結構ポピュラー(日本では)だと思います。MHAは最新binlogの適用、Slaveの昇格とレプリケーションの張替えまではやってくれますが、実際のフェールオーバーの部分はユーザに委ねられていて、master_ip_failover_scriptのテンプレートをカスタマイズするか独自実装する必要があり、一般的な実現方法としてはカタログデータベースの更新かVirtual IPの切替等があります。 Virtual IPだと居残りセッションの問題や切替の保証難しかったり
myhome.munetika.mydns.jp is not accessible... Sorry. I do not know why this site is not working. If you know Administrator of this site, please contact directly. You may be able to see it in Google cache. For administrator ... MyDNS.JP did not received IP address from you over One week. Please check your notify system. If you restart notification of IP address, MyDNS.JP will apply your IP address
たまにはAndroid以外のエントリーを。 最近巷で噂になっているMySQL-MHAを試してみる事にする コマンド/手順等はこちらのエントリをだいぶ参考にさせて頂きました。 http://myhome.munetika.mydns.jp/ossdbwiki/index.php/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8 環境 OS:CentOS release 5.3 (Final) インストールは結構適当にしてあって yum -y update perlが動く環境です。 サーバはとりあえず2台用意して、サーバA(10.13.13.151)は単独一台でマスターとして、サーバB(10.13.13.152)にはmysqlインスタンスを3つ用意して(ポートを別けてMySQLを起動)スレーブとする感じにします。 MySQLは5.1の
5. 単一障害点を無くしたい Single Point of Failure: その箇所がダウンするとサービスが 止まる いかなる時にも緊急対応が必要になる 早朝だろうと深夜だろうと対応が必要 アプリの数が多ければ確率も上がる メンバーも疲弊する MySQLの世界では スレーブは冗長化によってSPoFでなくすことは簡単 マスターは1個しか無いから難しい 5 6. MySQLマスター障害対応の課題 ・MySQLのレプリケーションは非同期または Writer IP 準同期 master ・マスター障害時に、一部のスレーブ (あるいは全部のスレーブ)が id=99 最新のバイナリログを受け取っていない id=100 id=101 可能性がある id=102 ・スレーブ間で、バイナリログの転送状況に 1. Save binlog events that ずれが生じている可能性がある exist o
MySQL masterDBダウン時のサービス停止時間の短縮をはかるために、MHAについて調査してみました。 通常、運用中の大規模なサービスに、後からHAのアーキテクチャを導入する場合、多くの場合システムの再構築が発生するため、導入のコストは高くなる傾向があります。 予算を確保するため資料をつくって説明にまわり、メンテナンスの為のサービス停止許可を得るためにまた説明にまわり、サーバのセットアップ、データの移行、テスト、リリースと、コストも時間もかかる作業になります。しかしMHAは、既存の環境を入れ替えること無しに導入する事が可能なので、導入コストはとても低いです。 MHAがどういうものか、まだイメージができていない方には、この様に説明することができます。MHAは、masterDBダウン時に、手作業で行っていたslaveの昇格作業をスクリプト化し、監視処理からそのスクリプトを呼ぶことで、ダウ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く