MHAについて
MHA（マスターハイアベイラビリティ）は現在、高可用性のMySQLの面では、開発する（現在はFacebookの会社の）従業員youshimaton日本のディー・エヌ・エーで構成されて比較的成熟したソリューションです、次のMySQL高可用性環境として良いです誤動作を切り替えますそしてマスター・スレーブの役割を強化するため、高可用性ソフトウェアを。MySQLのフェイルオーバー・プロセスでは、MHAプライマリ・データベースは、障害からのスイッチング動作に0から30秒後に自動的に行うことができ、およびフェイルオーバーを実行するプロセスは、MHAはに最大限にデータの整合性を保証するために本当の意味での高可用性を実現します。
MHAマネージャー（管理ノード）とノードMHA（ノードデータ）：MHAは、2つの部分から構成します。MHAマネージャが別のマシン上のマスタ・スレーブクラスタの複数を管理する個別に配備することができ、それはスレーブノード上に展開することができます。その後、MHAノードのマスターに障害が発生した場合、各サーバとMySQL Managerサーバ上で実行されている、MHA Managerは、定期的にクラスタ内のマスターノードを検出します、それは自動的に新しいマスターにスレーブの最新のデータを持つことができ、他のすべてのスレーブは、マスタの新しいアップグレードにリダイレクト。全体のフェイルオーバー・プロセスは、アプリケーション・レベルに対して完全に透過的です。
MHA自動フェイルオーバー・プロセスでは、プライマリサーバがダウンしたからMHAは、バイナリログを保存するために、データが失われないという保証の最大の度合いをしようとしますが、この操作は確率的です。たとえば、プライマリサーバのハードウェア障害やssh経由でアクセスすることができない場合は、MHAは、フェールオーバーが最新のデータのみが失われる実行、バイナリログを保存することはできません。半同期レプリケーションを使用してMySQL 5.5は、データ損失のリスクを減らすことができます。MHAは準同期レプリケーションと組み合わせることができます。1つのスレーブだけが、最新のバイナリログを受信している場合は、MHA最新のバイナリログは、他のすべてのスレーブサーバに適用することができますので、あなたは、すべてのノード間でデータの一貫性を確保することができます。
MHAを構築するためのMHAメインサポートインフラストラクチャマスターマルチスレーブは、現在、コピークラスタには、少なくとも3台のデータベース・サーバを持っている必要があります要求し、その1からのライブラリーから、プライマリ2つの行為がマスターとして動作する、一つはバックアップマスター、他の一つとして機能しそれはコストを考慮するための少なくとも3台のサーバ、マシンを必要とするため、淘宝網は、現在の淘宝網TMHAに基づいて変換されて、既にマスタースレーブをサポートしています。また、迅速に参照することができ構築したい人のために：私たち自身の使用を構築すばやくMHAを実際にメイン1から使用することができますが、マスターホストがダウンして切り替え、および完了binlogのにできないことはできません。マスターmysqldプロセスがクラッシュした後、またはあなたが首尾よく切り替えることができ、同様のbinlogの完成。
公式説明します。https：//code.google.com/p/mysql-master-ha/
ワークフロー
（1）ダウンマスターの崩壊からバイナリログイベント（ビンログイベント）を保存しようとします。
（2）スレーブの最新の更新を含むサーバを識別する。
（3）他のスレーブへのアプリケーションログリレーの差（ログリレー）。
（4）マスタから保存アプリケーションバイナリログイベント（バイナリログイベント）。
（5）新しいマスターサーバーとスレーブを持ち上げます。
（6）新しいマスタースレーブマスタスレーブレプリケーションへの他の接続点。
MHAツールが導入します
MHAソフトウェアは2つの部分から構成され、次のようにノードマネージャツールキットキットには、具体的に説明します。
マネージャーのキットは、以下のツールが含まれています。
MHAのSSHの設定状況➢のmasterha_check_ssh審査
➢MySQLのレプリケーションの状態を確認masterha_check_repl
➢MHAを開始masterha_manger
➢masterha_check_statusはMHAの現在の実行状態を検出します
➢masterha_master_monitorマスターがダウンしているかどうかを検出
➢masterha_master_switchフェイルオーバー制御（自動または手動）
➢masterha_conf_hostサーバーの構成情報の追加または削除
：ノードのキットは、（これらのツールは、通常は手動操作することなく、MHAマネージャスクリプトによってトリガされている）は、次のツールが含まれています
➢save_binary_logs保存およびレプリケーションマスタのバイナリログ
➢apply_diff_relay_logsリレーイベントログのイベントや他のスレーブに適用される特定の違いの違い
➢不要なROLLBACKイベントを削除filter_mysqlbinlog（MHAはもはやこのツールを使用）
➢purge_relay_logsクリアリレーログ（SQLスレッドをブロックしません）
注：ために、データの破損の損失によって引き起こされる主なライブラリハードウェアのダウンタイムを可能な限り減らすため、MySQLのMHAのアドバイスは、半同期レプリケーション5.5を設定して構成するには。あなたが所有して約半分の同期レプリケーション原則の見直し。（必須ではありません）
説明MHA環境
すべてのオペレーティングシステムについては、64ビット、単に手順を紹介しますレプリケーション環境から建物の背後にある主な問題ですが、関連するセキュリティの詳細をコピーしないであろう、MySQLのレプリケーションはCentOSの7.xのを必要とすることに留意すべきです。
| 役割 | IPアドレス | ホスト名 | サーバー | データベースタイプ |
| プライマリマスタ | 192.168.200.111 | SERVER01 | 1 | 書きます |
| セカンダリマスタ | 192.168.200.112 | Server02の | 2 | 書きます |
| スレーブ1 | 192.168.200.113 | server03 | 3 | 読みます |
| スレーブ2 | 192.168.200.114 | server04 | 4 | 読みます |
| マネージャー | 192.168.200.115 | server05 | - | モニタリング・レプリケーション・グループ |
プライマリマスターがダウンした後、外部の書き込みサービスを提供するプライマリマスタ、代替セカンダリマスタ（読みサービスを提供するために、実際の奴隷、スレーブ1とスレーブ2も読んでサービスを提供するには、代わりに、新しいセカンダリマスタプライマリマスタにアップグレードされます新しいマスターにスレーブ1とスレーブ2ポイント。