転送から：のhttp：CentOSに//hi.baidu.com/cloudhorizon/item/26bf393b2f142642033edc94インストールリファレンスます：http：//ylw6006.blog.51cto.com/470441/890360。MHA MHAオートメーションが複製の一貫性に影響を与えずに、プライマリ・サーバのフェールオーバー、（通常は10-30s中）のサーバーベースのサーバーからの迅速なプロモーションを紹介し、より新しいサーバーを買うためにお金を費やす必要はありません、パフォーマンス上の損失はありません、任意のストレージエンジンのために、既存のデプロイメント環境を変更することなく、簡単にインストールします。MHAオンラインスイッチングマスターサーバー、別の実行中のステージを変更するには、マスターサーバー、このプロセスのみ0。データを書き込むことができない、この時間は、時間を5-2s。MHAマネージャーMySQLのスレーブサーバは、ssh経由で接続されています。MHAの試みは必ずしも可能ではない、遮断マスタからバイナリログを保存しますが。例えば、ssh経由でアクセスするには、プライマリサーバのハードウェア障害または不能ならば、MHAはバイナリログを保存することはできません、フェイルオーバーを実行するだけで、最新のデータを失いました。準同期レプリケーションは、大幅にデータ損失のリスクを減らすことができます。MHAは準同期レプリケーションと組み合わせることができます。1つのスレーブだけが、最新のバイナリログを受信している場合は、MHA最新のバイナリログはとても互いに矛盾それらを保ち、他のすべてのスレーブサーバに適用することができます。、自動監視および主マスターサーバーアーキテクチャMHAモニタ複製の転送に失敗し、プライマリサーバの検出に失敗した時に、それは自動的に失敗します：MHAは、次のような特徴があります。いくつかは、サーバーのリレーログからの違いや他のアプリケーションにこれらのログの最新の自動識別、サーバーからサーバーからの一貫性のため、すべてのサーバから、MHAから最新のリレーログを受けなかったにもかかわらず。MHAは通常、数秒のフェールオーバ以内に完了する、9-12秒は、プライマリサーバに障害が発生した新しいプライマリサーバに、数秒以内に適用されるスプリットブレイン、7-10秒、リレーログ差を避けるために、プライマリサーバを閉じるに失敗したことを検出するために、 、全体のプロセスは、10-30sで完了することができます。また、スレーブマスターの候補として指定されているの優先度を設定することができます。スレーブ間のMHAは、一貫性を修復するので、それは任意のスレーブにすることができますので、新しいマスタになり、問題の一貫性は発生しません、レプリケーションが失敗する原因。インタラクティブプライマリ・サーバのフェールオーバーは、フェールオーバーMHAを使用して、プライマリサーバが、障害の障害のためのマニュアルコールMHAを失敗した場合、サーバーを監視するために使用することはできません。主な非対話型のフェイルオーバーは、プライマリサーバが、自動フェイルオーバーを監視しません。この機能は、マスターサーバーに昇格され、プライマリサーバに障害が発生し、仮想IPアドレスの引き継ぎを検出するためにこのようなハートビートとして、プライマリサーバの状態を監視するために使用されてきた、MHAは、フェイルオーバーとスレーブサーバーを実装するために使用することができ、他のソフトウェアに適用されます。メインサーバーオンラインスイッチ 多くの場合、あなたは別のサーバー上の既存のマスターサーバーに移行する必要があります。たとえば、プライマリサーバのハードウェア障害が、RAIDコントローラカードを再構築する必要があるので、上の優れたサーバーのパフォーマンス、およびへのプライマリサーバ。少なくともダウンタイムにつながるメインサーバーのパフォーマンス低下のメンテナンスは、書き込むことができません。また、ブロックまたは現在の主な主な問題の間で一貫性のないデータにつながることができます実行中のセッションを殺します。MHAは、高速スイッチングを提供し、エレガントな書き込みをブロックし、切り替え処理のみ0.5-2s時間がかかり、この時間は、データが書き込まれていません。多くの場合、書き込み0.5-2sを遮断することが可能です。したがって、（ああ、あなたが高い暗い嵐の夜にタスクを完了するために夜を介してメインサーバーを切り替える必要はありません）、メインサーバは、計画的なメンテナンスウィンドウを割り当てる必要はありません切り替えます。注：MHA複製構造はMHA SSH公開鍵認証サーバ管理ノードMySQLは、SSHを介した接続を必要とした任意の二つの.MHA条件に適用することができる、最新の送信リレーSCPを介してサーバにログオンMHA他のスレーブ。SSH公開鍵認証パスワードを使用して、これらのプロセスの自動化を行います。MHAのオペレーティングシステムは現在、単一のLinuxシステムは、サーバ間の一貫性から、プライマリサーバた場合や読み取り専用のとき、プライマリサーバオフからマスターサーバーと複数のサーバにMHA修復データを書き込むことができますサポートしています。バイナリログファイルを保存しようとMHAは、プライマリサーバのクラッシュから送信され、サーバからのすべてに適用されていません。唯一つのサーバからの場合は、サーバ間の整合性の問題を気にする必要はありません。唯一のバイナリログイベントがサーバーから送信されていない場合でも、MHAは、メインサーバーへのSSHアクセスによるプライマリサーバ限り、クラッシュから保存されました。準同期レプリケーションは、とき、プライマリサーバがクラッシュし、あなたはまだ送信されていないマスターのバイナリログイベントを保存するためにsshをすることはできません解決することができます。MHA Manager0から。52のバージョンは、マルチマスターレプリケーション構成をサポートしています。唯一のマスターサーバーが書き込むことができ、メインサーバは、他の読み取り専用= 1に設定されなければなりません。デフォルトでは、サーバーは、2層の管理構造のコピーでなければなりません。デフォルトでは、コピーされた3層以上の場合には、MHAは、3つ以上の3つの複製構造をサポートしていません。MASTER1として--- MASTER2 ---- slave3。MHAのフェイルオーバーおよびプライマリサーバから現在のプライマリサーバとして選択された1から直接回復します。slave3が別のプライマリサーバ（MASTER2）からコピーされているのでMASTER1クラッシュ、メインとしてMASTER2は、MHAが監視しslave3を復元していないときMHAは、MASTER1とMASTER2を管理することができます。この作品MHAアーキテクチャを作るために、あなたは以下の設定を行う必要があります。この場合、すべてのホスト上に提供のみMASTER1とMASTER2 multi_tier_slave設定ファイル内のMHA MHAプロファイル= 1を設定し、本体のみMHA管理マスターとサーバーからの二階、フェイルオーバー・プロセスは、サーバーからの3人はまだ正常に動作することができます。MySQLのバージョン5.0以上のサポートMHA以降MySQL5.0の。バイナリログ（バイナリログV4形式）からフォーマットはMySQL5.0のバージョンから変更されたため。V4フォーマットを使用して、目標位置を決定するバイナリMHAリレー・ログ・ログを解析するとき。MySQLバージョン5.0.60は、以上でなければなりません。mysqlbinlogはバージョン3.3またはそれ以降のMHAは、サーバイベントからターゲットアプリケーションバイナリでmysqlbinlogはを使用します。プライマリサーバーベースライン形式のコピーが、イベントラインに基づいてバイナリファイル形式に書き込む場合は、このバイナリログファイル形式は、後で解決やmysqlbinlogはMySQL5.1のことができます。MySQL5.0の。mysqlbinlogは60の以下のバージョンではラインベースのフォーマットをサポートしていません。候補マスターログ・ビンは、現在のログ・ビンがサーバーから開いていない場合、それはプライマリサーバーになることはありませんオンにする必要があります。MHA管理ノードは、構成ログ・ビンがあるかどうかを検出します。サーバー・ログ・ビンからすべての現在の設定を持っていない場合は、MHAはフェイルオーバーしません。バイナリログとリレーログフィルタリングルールはビンログ-DO-DBのすべてのサーバーで同じでなければなりません、そして複製-無視-dbが同じでなければなりません。検出フィルタルールは、異なるフィルタリングルール場合、MHAは監視とフェイルオーバーを起動しないときMHAが開始されます。サーバーから、それがすべてのコマンド変更マスタを実行するために、フェイルオーバー後にするとき、プライマリサーバ候補ユーザが存在している必要がありますコピーします。ご予約は自動的にSQLスレッドの実装後に削除されます、サーバー上のリレーログから、ログインして、デフォルトでは、定期的に清掃リレー。これらの他の中継ログは、サーバーからの回復時間に使用することができる。しかし、自動クリアリレーログと定期的なパージ古いリレーログを無効にする必要があります。定期的に明確なリレーログは問題にレプリケーションの遅延を考慮する必要があります。ext3ファイルシステムでは、ある程度の時間がかかります大きなファイルを削除し、深刻な遅延の複製を引き起こす可能性があります。レプリケーションの遅延を避けるために、一時的にリレーログへのハードリンクを作成します。MHAノードがリレーログのハードリンクを作成することができますpure_relay_logsコマンド・ツールが含まれている、SET GLOBAL relay_log_purge = 1、新しいSQLスレッドリレーログに切り替えるために、数秒待っを実行し、その後、SET GLOBAL relay_log_purge = 0を実行します。ポート番号--port MySQLサーバのアドレス--host --userのMySQLユーザ名--password mysqlのパスワードを--workdirリレーログディレクトリのハードリンクを作成および削除：次のようにpure_relay_logsパラメータです。スクリプトの実行が成功した後、ハードリンクリレーログファイルが削除されます。デフォルトのディレクトリは/ var / tmpです。--disable_relay_log_purge relay_log_purge = 1の場合、何もせずにスクリプトが終了しpurge_relay_logs。--disable_relay_log_purgeパラメータを設定し、スクリプトが後退し、自動的= 0 relay_log_purgeを設定しませんpurge_relay_logs。定期的にスクリプトをpurge_relay_logs：リレーログを削除するPurge_relay_logsスクリプトは、SQLスレッドをブロックすることはありません。だから、定期的にログをクリアする各リレー上のサーバからのスケジュールされたタスクを設定します。00 00 * * *は/ usr / binに/ purge_relay_logs --user =ルート--password = passwdの--disable_relay_log_purge >> /data/masterha/log/purge_relay_logs.logサーバ2から、好ましくはそれぞれ異なる時点>＆1スケジュールされたタスクを実行します。11.は、LOAD DATA INFILEあなたは非トランザクションストレージエンジンを使用している場合、バイナリログの種類、プライマリサーバがクラッシュをベースLOAD DATA INFILEステートメントを実行するには、MHAが違いにはならないかもしれタイプバイナリログの声明に基づいてリレーログイベントを使用しないでください。 。そこはお勧めしませんmysql5.1バージョンではいくつかの既知の問題があり、深刻な遅延がコピー引き起こすタイプのバイナリログに基づいてLOAD DATA INFILEステートメントを使用しますので、それを使用する理由はありません。III。1. MHAプロセス監視とフェイルオーバー検出、プライマリサーバは、マスターサーバからオフ検出器（オプション）新しいプライマリマスターの新しいアクティベーションを復元するときに再び閉鎖するように構成された検出された場合、現在のマスターサーバーマスターサーバーを監視するために設けられたコピーの決意2.サーバー回復プロセスの残りは、（オプション）コピーラインサーバから新しいプライマリグラント書き込ま警告に追いつくためにサーバからコピー全ての現在のプライマリサーバーが待機に書き込まれたブロックに設定し、新しいプライマリ・サーバを決定するために、現在のプライマリ・サーバを決定するスイッチ検出します4バックサーバーからサーバー。MHA MHAのインストールスクリプトは、3つのノード、依存Perlモジュールが含まれています。save_binary_logs：質入れマスタバイナリログapply_diff_relay_logsを保存してコピーします。違いは、イベントをログに記録リレー、および他のサーバーのpurge_relay_logsに適用される軟膏識別：クリアリレーログファイルは、MHAのMySQLサーバは、MHAは、管理サーバーをインストールする必要があるすべてのノードにインストールする必要があります。内部ノード管理モジュールは、MHA MHAノードモジュールを依存しています。MHA管理ノードの接続管理のMySQLサーバおよびSSHでスクリプトMHAノードを実行します。perlのDBDのMHA依存ノード:: mysqlのモジュール。インストールMHAノードは、MakefileのすべてのMySQLサーバ＃libdbd-mysqlの-perlの＃1のwgetをインストールapt-getをhttp://mysql-master-ha.googlecode.com/files/mha4mysql-node-0.52.tar.gz＃perlの上に設置しました.PL＃が＃はMakefileのMHAマネージャ＃libdbd-mysqlの-perlの＃1のwgetをインストールapt-getをhttp://mysql-master-ha.googlecode.com/files/mha4mysql-node-0.52.tar.gz＃perlのインストールmake installを作ります.PL＃が＃はmake installを作り＃apt-getをインストールlibconfig-小さな-perlの＃apt-getをインストールliblog-派遣-perlの＃apt-getをインストールlibparallel-forkmanager-perlの＃apt-getのインストールのlibnet-のtelnet-perlの＃1のwgetのhttp ：//mysql-master-ha.googlecode.com/files/mha4mysql-manager-0.52.tar.gz＃タールzxvf mha4mysqlマネージャ-0.52.tar.gz -C ../software/＃perlのメイクファイル。PL＃が＃は*上の五.MHA配置配置主从结构【ノード2】サーバID = 101ログ・ビン= mysqlのビン-101のmysql>助成金のレプリケーションスレーブをmake installを作る* 'replpasswd' によって識別されるまで。MySQLの> *上のすべての権限を付与*「123456」で識別します。MySQLの> *上のすべての権限を付与*「123456」で識別します。*上の【ノード3】サーバ-ID = 103ログビン= MySQLのビン-103 READ_ONLY = 1 relay_log_purge = 0のMySQL>グラントレプリケーションスレーブ* 'replpasswd' によって同定します。MySQLの> *上のすべての権限を付与*「123456」で識別します。MySQLの> *上のすべての権限を付与*「123456」で識別します。MySQLの>変更マスタへ - > MASTER_HOST = '192.168.1.101'、 - > master_user = 'REPL'、 - > master_password = 'replpasswd'、 - > MASTER_LOG_FILE = 'MySQLのビン-101.000003'、 - > MASTER_LOG_POS = 660。*上の【ノード4】サーバ-ID = 114ログビン= MySQLのビン-114 READ_ONLY = 1 relay_log_purge = 0のMySQL>グラントレプリケーションスレーブ* 'replpasswd' によって同定します。MySQLの> *上のすべての権限を付与*「123456」で識別します。MySQLの> *上のすべての権限を付与*「123456」で識別します。MySQLの>変更マスタへ - > MASTER_HOST = '192.168.1.101'、 - > master_user = 'REPL'、 - > master_password = 'replpasswd'、 - > MASTER_LOG_FILE = 'MySQLのビン-101.000003'、 - > MASTER_LOG_POS = 660。2.配置MHA＃MKDIRの/ etc / masterha＃ます。mkdir -p / masterha / APP1＃CP ./mha4mysql-manager-0.52/samples/conf/*の/ etc / masterha /＃のVimのapp1.cnf [サーバのデフォルト] manager_workdir = / masterha / APP1 manager_log = / masterha / APP1 /マネージャー。ユーザー= rootのパスワード= 123456 ssh_user =ルートrepl_user = REPL repl_password = replpasswd ping_interval = 1 shutdown_script = "" master_ip_failover_script = "は/ usr / local / binに/ master_ip_failover" master_ip_online_change_script = "" report_script = "" [サーバー1]ホスト名= 192.168を記録。 1.101 master_binlog_dir = /データ/ MYDATA candidate_master = 1 [サーバ2]ホスト名= 192.168.1.103 master_binlog_dir = /データ/ MYDATA candidate_master = 1 [server3の】ホスト名= 192.168.1.114 master_binlog_dir = /データ/ MYDATAのMySQL> *上のすべての権限を付与します。* 「123456」によって識別されると、：〜＃1にssh-keygenは-t rsaの：〜＃sshをコピー-ID -i /root/.ssh/id_rsa.pub：〜＃sshをコピー-ID -i /root/.ssh/id_rsa.pub：〜＃ SSH-コピー-ID -i /root/.ssh/id_rsa.pub：〜＃1にssh-keygenは-t rsaの：〜＃sshのコピー-ID -i /root/.ssh/id_rsa.pub：〜＃sshをコピー-id -i /root/.ssh/id_rsa.pub：〜＃1にssh-keygenは-t rsaの：〜＃sshをコピー-ID -i /root/.ssh/id_rsa.pub：〜＃sshをコピー-ID -i /root/.ssh/id_rsa.pub：〜＃1にssh-keygenは-t rsaの：〜＃sshを-copy-ID -i /root/.ssh/id_rsa.pub：〜＃sshをコピー-ID -i /root/.ssh/id_rsa.pub：〜＃masterha_check_ssh --conf =の/ etc / masterha / app1.cnf火10月25日夜08時51分04秒2011 - [情報]読書のデフォルトconfiguratoins /etc/masterha_default.cnfから...火曜10月25日夜08時51分04秒2011 - [情報]リーディングアプリケーションのデフォルト設定は/ etc / masterha / APP1から。 CNF ..火曜10月25日20時51分04秒2011 - /etc/masterha/app1.cnfから[情報]読書サーバの設定... 10月25日（火）20時51分04秒2011 - [情報] SSH接続テストを開始。..火10月25日午後08時51分05秒2011 - [デバッグ]火曜10月25日午前20時51分04秒2011 - [デバッグ]まで）からSSH経由での接続）..火曜10月25日午後08時51分05秒2011 - [デバッグ] [OK]をクリックします。火10月25日20時51分05秒2011 - [デバッグ]まで）からSSH経由での接続）... 10月25日（火）20時51分05秒2011 - [デバッグ] [OK]をクリックします。火10月25日午後08時51分05秒2011 - [デバッグ]火曜10月25日午後08時51分05秒2011 - [デバッグ]まで）からSSH経由での接続）..火曜10月25日午後08時51分05秒2011 - [デバッグ] [OK]をクリックします。火10月25日20時51分05秒2011 - [デバッグ]まで）からSSH経由での接続）... 10月25日（火）20時51分05秒2011 - [デバッグ] [OK]をクリックします。火10月25日20時51分06秒2011 - [デバッグ]火曜10月25日午後8時51分05秒2011 - [デバッグ]まで）からSSH経由での接続）... 10月25日（火）20時51分06秒2011 - [デバッグ] [OK]をクリックします。火10月25日20時51分06秒2011 - [デバッグ]まで）からSSH経由での接続）... 10月25日（火）20時51分06秒2011 - [デバッグ] [OK]をクリックします。火曜10月25日20時51分06秒2011 - [情報]合格すべてのSSH接続をテストします。：〜＃masterha_check_repl --conf =の/ etc / masterha / app1.cnf水曜日10月26日20時47分34秒2011 - [警告]グローバルコンフィギュレーションファイルが見つかりません/etc/masterha_default.cnf。スキップ。水曜日10月26日午後08時47分34秒2011 - /etc/masterha/app1.cnfから[情報]リーディングアプリケーションのデフォルト設定.. 水曜日10月26日20時47分34秒2011 - [情報] /etc/masterha/app1.cnfから読書サーバー構成が..水曜日10月26日20時47分34秒2011 - [情報] MHA :: MasterMonitorバージョン0.52。水曜日10月26日20時47分35秒2011 - [情報]デッドサーバ：水曜日10月26日20時47分35秒2011 - [情報]アライブサーバ：水曜日10月26日20時47分35秒2011 - [情報] 192.168.1.101（192.168 3306）水10月26日20時47分35秒2011 - [情報] 192.168.1.103（192.168.1.103:3306）水10月26日20時47分35秒2011 - [情報] 192.168.1.114（192.168.1.114:3306：.1.101 ）水曜日10月26日午後8時47分35秒2011 - [情報]アライブ奴隷：水曜日10月26日午後8時47分35秒2011 - [情報] 192.168.1.103（192.168.1.103:3306）バージョン= 5.5.14-ログ（最古の主要なスレーブ間のバージョン）ログインビン：水曜日10月26日夜08時47分35秒2011が有効 - [情報] 192.168.1.101（192.168.1.101:3306）水10月26日夜08時47分35秒2011年から複製 - のための[情報]原発候補を新しいマスター（candidate_masterが設定されている）水曜日10月26日20：47：35 2011 - [情報] 192.168.1.114（192.168.1.114:3306）バージョン= 5.5.14-ログ（スレーブ間の最古のメジャーバージョン）がログインビン：水曜日10月26日夜08時47分35秒2011が有効 - [情報]から複製を192.168.1.101（192.168.1.101:3306）水10月26日午前20時47分35秒2011 - [情報]現在アライブマスター：192.168.1.101（192.168.1.101:3306）水10月26日午前20時47分35秒2011 - [詳細]スレーブ構成を確認する。..水曜日10月26日20時47分35秒2011 - [情報]チェックレプリケーションのフィルタリングの設定..水曜日10月26日20時47分35秒2011 - [情報] binlog_do_db =、binlog_ignore_db =水曜日10月26日20時47分35秒2011 - [情報]、[OK]レプリケーションのフィルタリングチェック。水曜日10月26日夜8時47分35秒2011 - [情報] SSH接続テストを開始。..水曜日10月26日午前20時47分37秒2011 - [情報]合格すべてのSSH接続をテストします。水曜日10月26日午後08時47分37秒2011 - [情報] MHAノードのバージョンを確認する。..水曜日10月26日午後08時47分37秒2011 - OK [情報]バージョンチェック。水曜日10月26日午後08時47分：37 2011 - [情報] SSHの公開鍵認証をチェックし、現在のマスターの回復スクリプトの設定を確認する。..水曜日10月26日20時47分38秒2011 - [情報]コマンドを実行：save_binary_logs --command =テスト--start_file = mysqlのビン-101.000003 --start_pos = 4 --binlog_dir = /データ/ mydataという--output_file =の/ var / tmpに/ save_binary_logs_test --manager_version = 0.52水曜日10月26日20時47分38秒2011 - [情報]への接続）..の作成/ VAR / tmpがない場合は、[OK] ...存在しています。出力ディレクトリをチェックすると、アクセス可能かどうか..です[OK]をクリックします。行って[情報]マスターの設定チェック - のbinlogは、MySQL-ビン101.000003水曜日10月26日午後08時47分38秒2011年まで、/データ/ mydataというのが分かりました。水曜日10月26日20時47分38秒2011 - [情報] ..水曜日10月26日20時47分38秒2011 SSHの公開鍵認証をチェックし、すべての生きているスレーブサーバ上で回復スクリプトの設定を確認する - [情報]実行するコマンドを：apply_diff_relay_logs --command =テスト--slave_user =ルート--slave_host = 192.168.1.103 --slave_ip = 192.168.1.103 --slave_port = 3306 --workdir =の/ var / tmpの--target_version = 5.5.14-ログ--manager_version = 0.52 --relay_log_info = /データ/ mydataという/ relay-log.info --slave_pass = xxxは水曜日10月26日午前20時47分38秒2011 - [情報]に接続する）..スレーブリカバリ環境の設定を確認する...オープニング/データ/ MYDATA / relay-log.info ... OK。ログリレー..行わノード3-リレー-bin.000004一時リレーログファイルまで/data/mydata/node3-relay-bin.000004テストmysqlの接続と権限で、/データ/ mydataというのが分かりました。テストmysqlbinlogは出力が..行わ。テストファイル（複数可）をクリーンアップ..行わ。水曜日10月26日午前20時47分38秒2011 - [情報]コマンドを実行：apply_diff_relay_logs --command =テスト--slave_user =ルート--slave_host = 192.168.1.114 --slave_ip = 192.168.1.114 --slave_port = 3306 --workdir =の/ var / tmpの--target_version = 5。5.14ログ--manager_version = 0.52 --relay_log_info = /データ/ mydataという/ relay-log.info --slave_pass = xxxは水曜日10月26日夜08時47分38秒2011 - [情報]に接続する）..スレーブリカバリ環境の設定を確認します... OK ... /data/mydata/relay-log.info開きます。ログリレー..行わノード4-リレー-bin.000002一時リレーログファイルまで/data/mydata/node4-relay-bin.000002テストmysqlの接続と権限で、/データ/ mydataというのが分かりました。テストmysqlbinlogは出力が..行わ。テストファイル（複数可）をクリーンアップ..行わ。水曜日10月26日午後8時47分39秒2011 - [情報]スレーブの設定が行われるチェック。水曜日10月26日20時47分39秒2011 - [情報] 192.168.1.101（現在のマスター）+ - + 192.168.1.103 - 192.168.1.114水10月26日20時47分39秒2011 - [情報] 192.168でのレプリケーションの状態を確認します.1.103 ..水曜日10月26日20時47分39秒2011 - [情報] [OK]をクリックします。水曜日10月26日20時47分39秒2011 - [情報] 192.168.1.114のレプリケーションの状態を確認する。..水曜日10月26日20時47分：39 2011 - [情報] [OK]をクリックします。水曜日10月26日20時47分39秒2011 - [情報] master_ip_failvoer_script状況を確認する：水曜日10月26日20時47分39秒2011 - [情報]を/ usr / local / binに/ master_ip_failover --command =ステータス--ssh_user =ルート - orig_master_host = 192.168.1.101 --orig_master_ip = 192.168.1.101 --orig_master_port = 3306水曜日10月26日午後08時47分39秒2011 - [情報] OK。水曜日10月26日午後8時47分39秒2011 - [警告] shutdown_scriptが定義されていません。水曜日10月26日午後8時47分39秒2011 - [情報]ガットの終了コード0（デッドマスターではありません）。MySQLのレプリケーションの状態はOKです。：〜＃masterha_check_status --conf =の/ etc / masterha / app1.cnf APP1（PID：16179）（0：PING_OK）が実行され、マスタ：192.168.1.101：〜＃のcrontab -l 00 00 * * *は/ usr / local / binに/ purge_relay_logs --user =ルート--password = 123456 --disable_relay_log_purge >> /masterha/purge_relay_logs.log 2>＆1：〜＃crontabの-l 00 01 * * *は/ usr / local / binに/ purge_relay_logs --user =ルート--password = 123456 --disable_relay_log_purge >> /masterha/purge_relay_logs.log 2>＆1启动MHA：〜＃nohupをするmasterha_manager - -conf =の/ etc / masterha / app1.cnf <を/ dev / null> /masterha/app1/manager.log 2>＆1＆六测试：〜＃pkillはmysqlの*：〜＃テール-fれるManager.log将看到整个过程-----フェールオーバレポート----- APP1：MySQLのマスターのフェールオーバー192.168.1.101 192.168.1.103には、マスター192.168.1.101がダウンしている成功しました！UbuntuのでMHA Managerログを確認します。詳細については/masterha/app1/manager.log。自動化された（非対話型）のフェールオーバーを開始しました。192.168.1.101に無効化されたマスターIPアドレス。最新のスレーブ192.168.1.103（192.168.1.103:3306は）回復のためのすべてのリレーログを持っています。新しいマスターとして192.168.1.103を選択しました。192.168.1.103：OK：すべてのログを適用することに成功しました。192のマスターIPアドレスをアクティブに失敗しました。リターンコードと168.1.103 10：0 192.168.1.114：このホストは、最新のリレーログイベントがあります。最新のスレーブから生成リレー差分ファイルは成功しました。192.168.1.114：OK：すべてのログを適用することに成功しました。スレーブが192.168.1.103からの複製開始しました。192.168.1.103：リセットスレーブ情報に成功しました。192.168.1.103（192.168.1.103:3306）にマスターフェイルオーバーが正常に完了しました。ノード3>スレーブホストを示し; + ----------- + ------ + ------ + ----------- + | SERVER_ID | ホスト| ポート| MASTER_ID | + ----------- + ------ + ------ + ----------- + | 114 | | 3306 | 103 | + ----------- + ------ + ------ + ----------- +ノード4> ****スレーブステータスの\ Gを表示*********************** 1行************************ *** Slave_IO_State：イベントMASTER_HOSTを送信するためにマスターを待っている：192.168.1.103成功将主服务器切换到192.168.1.103、同时将从服务器的主切换到192.168.1.103。このホストは、最新のリレーログイベントがあります。最新のスレーブから生成リレー差分ファイルは成功しました。192.168.1.114：OK：すべてのログを適用することに成功しました。スレーブが192.168.1.103からの複製開始しました。192.168.1.103：リセットスレーブ情報に成功しました。192.168.1.103（192.168.1.103:3306）にマスターフェイルオーバーが正常に完了しました。ノード3>スレーブホストを示し; + ----------- + ------ + ------ + ----------- + | SERVER_ID | ホスト| ポート| MASTER_ID | + ----------- + ------ + ------ + ----------- + | 114 | | 3306 | 103 | + ----------- + ------ + ------ + ----------- +ノード4> ****スレーブステータスの\ Gを表示*********************** 1行************************ *** Slave_IO_State：イベントMASTER_HOSTを送信するためにマスターを待っている：192.168.1.103成功将主服务器切换到192.168.1.103、同时将从服务器的主切换到192.168.1.103。このホストは、最新のリレーログイベントがあります。最新のスレーブから生成リレー差分ファイルは成功しました。192.168.1.114：OK：すべてのログを適用することに成功しました。スレーブが192.168.1.103からの複製開始しました。192.168.1.103：リセットスレーブ情報に成功しました。192.168.1.103（192.168.1.103:3306）にマスターフェイルオーバーが正常に完了しました。ノード3>スレーブホストを示し; + ----------- + ------ + ------ + ----------- + | SERVER_ID | ホスト| ポート| MASTER_ID | + ----------- + ------ + ------ + ----------- + | 114 | | 3306 | 103 | + ----------- + ------ + ------ + ----------- +ノード4> ****スレーブステータスの\ Gを表示*********************** 1行************************ *** Slave_IO_State：イベントMASTER_HOSTを送信するためにマスターを待っている：192.168.1.103成功将主服务器切换到192.168.1.103、同时将从服务器的主切换到192.168.1.103。
ます。https：//my.oschina.net/766/blog/211373で再現