MySQL-MHAを設定する
MySQL-MHAをインストールして設定する
MySQL-MHAは、MySQLでレプリケーション構成時にMasterサーバが障害等で停止した場合に、自動的に自動的SlaveサーバーをMasterサーバに昇格してのダウンタイムで短くするツールです。障害時にも自動でフェイルオーバーはできるの大変便利なツールです。また手動でのフェイルオーバーもできます。
まずはMySQLのレプリケーション環境が必要ですので導入方法は以下の記事を参考にしてください
今回設定するサーバーのIPアドレス・用途等の仕様は以下となります。OSはCentOS 6.8でインストールしています
| IPアドレス | ホスト名 | 用途 |
| 192.168.11.100 | mha | MHAマネージャー |
| 192.168.11.101 | db01 | MasterDB |
| 192.168.11.102 | db02 | SlaveDB（Masterサーバ停止時にはMasterに昇格） |
| 192.168.11.103 | db03 | SlaveDB |
MHAマネージャーのインストール及び設定
MHA-Managerをインストールします。この作業はmha（192.168.11.100）で設定します。
インストールに必要なパッケージをインストールします。一部のパッケージではEPELからインストールが必要なためEPELを有効にします
>EPELを有効にする # yum install epel-release # yum --enablerepo=epel install libmcrypt-devel # vi /etc/yum.repos.d/epel.repo enabled=1 ↓変更（普段はEPELを使用しないようにする） enabled=0 # yum install mysql mysql-server # yum install perl-DBD-MySQL perl-Config-Tiny perl-Time-HiRes # yum install --enablerepo=epel install perl-Log-Dispatch perl-Parallel-ForkManager
MHA for MySQLのパッケージ（mha4mysql-node-0.56-0.el6.noarch.rpm、mha4mysql-manager-0.56-0.el6.noarch.rpm）を下記URLよりダウンロードします
https://github.com/yotoobo/linux/tree/master/mha
MHA for MySQLのパッケージは、SCP等で /usr/local/srcに配置しておきます。yum localinstallコマンドでMHA for MySQLのパッケージをインストールします
># cd /usr/local/src # yum localinstall mha4mysql-node-0.56-0.el6.noarch.rpm # yum localinstall mha4mysql-manager-0.56-0.el6.noarch.rpm # rpm -ql mha4mysql-manager
パスワード無しでSSHログインできるように設定する
全サーバが共通の設定で、パスワード無しでSSHログインできるように設定します。パスワード無しでログインできるユーザーは「admin」とします
最初に、mha（192.168.11.100）で鍵を作成し、他のサーバへも展開します
># 鍵を生成します $ su - admin $ ssh-keygen -t rsa # db01に鍵を展開します $ ssh -l admin mha touch ‾/.ssh/authorized_keys2 admin@db01's password: $ ssh -l admin mha chmod 600 ‾/.ssh/authorized_keys2 $ cat ‾/.ssh/id_rsa.pub | ssh -l admin mha 'cat >> '‾/.ssh/authorized_keys2 $ ssh -l admin db01 touch ‾/.ssh/authorized_keys2 $ ssh -l admin db01 chmod 600 ‾/.ssh/authorized_keys2 $ cat ‾/.ssh/id_rsa.pub | ssh -l admin db01 'cat >> '‾/.ssh/authorized_keys2 # db02に鍵を展開します $ ssh -l admin db02 touch ‾/.ssh/authorized_keys2 $ ssh -l admin db02 chmod 600 ‾/.ssh/authorized_keys2 $ cat ‾/.ssh/id_rsa.pub | ssh -l admin db02 'cat >> '‾/.ssh/authorized_keys2 # db03に鍵を展開します $ ssh -l admin db03 touch ‾/.ssh/authorized_keys2 $ ssh -l admin db03 chmod 600 ‾/.ssh/authorized_keys2 $ cat ‾/.ssh/id_rsa.pub | ssh -l admin db03 '>> '‾/.ssh/authorized_keys2
MHA for MySQLのパッケージをインストールします
この作業は、MasteDB（192.168.11.101）、SlaveDB（192.168.11.102,192.168.11.103）で実施します。パッケージはhttps://github.com/yotoobo/linux/tree/master/mha よりダウンロードして「/usr/local/src」に配置しておきます
# cd /usr/local/src # scp admin@mha:/usr/local/src/mha4mysql-node-0.56-0.el6.noarch.rpm . # yum localinstall mha4mysql-node-0.56-0.el6.noarch.rpm
MySQLのMHA用ユーザー作成
全サーバが共通の設定です
MySQL側にmha用のユーザ（mha）を作成します。パスワードは「’apple314」とします。
# mysql -u root -p mysql> GRANT ALL ON *.* TO 'mha'@'192.168.11.%' IDENTIFIED BY 'apple314'; mysql> select user, host from mysql.user where user = 'mha'; +------+--------------+ | user | host | +------+--------------+ | mha | 192.168.11.% | +------+--------------+ 1 row in set (0.00 sec)
MHAで使用するログ・作業ディレクトリを設定
全サーバが共通の設定です
ログディレクトリ・作業ディレクトリを作成します
作業ディレクトリ # mkdir /tmp/mha # chown admin:mysql /tmp/mha # chmod 775 /tmp/mha ログディレクトリ # mkdir /tmp/mha/log # chmod 777 /tmp/mha/log
MHA-Managerの設定ファイルの設定
この作業はmha（192.168.11.100）で設定します。
設定ファイル（mha.cnf）の作成して設定をしていきます
># vim /etc/mha.cnf [server default] # mha用に作成したmysqlユーザ情報 user=mha password=apple314 # mysqlのレプリ用ユーザ（パスワードなしでSSHできるユーザ） repl_user=repl repl_password=mikan321 # ログ・作業ディレクトリパス情報 # mysql-mha-managerのディレクトリパス manager_workdir=/tmp/mha manager_log=/tmp/mha/log/mha.log # mysqldb(master-slave)のディレクトリパス remote_workdir=/tmp/mha # バイナリログのディレクトリパス master_binlog_dir=/var/lib/mysql # ssh接続ユーザ ssh_user=admin [server1] hostname=db01 candidate_master=1 [server2] hostname=db02 candidate_master=1 [server3] hostname=db03 no_master=1 # このホストはマスターにしない ######################## # 監視サーバーの設定（設定内容の説明） ######################## # hostname # ホスト名 # candidate_master # 優先的にmasterに変更するサーバーか(デフォルト:0) # 0:優先的なサーバーとしない # 1:優先的に新しいmaster候補とする。ただし、バイナリーログが有効になっていること。slaveの遅延が発生していないなどの、 # 条件を満たしている限り、新しいmasterに優先される。 # ※複数個のサーバーに1が設定されている場合には、[serever_XXX]セクションのXXXの値が小さい方が優先される。 # ignore_fail # スレーブサーバのいずれかに障害が発生した場合、フェイルオーバーを行うか。 # 0:指定されたslaveサーバーで障害が発生し他場合には、フェイルオーバーを行わない。（デフォルト） # 1:指定されたslaveサーバーで障害が発生しても、フェイルオーバーを行う。 # no_master # マスターの対象にするか # master_binlog_dir # バイナリーログのディレクトリの場所の指定
MySQL-MHAの動作確認
この作業はmha（192.168.11.100）で設定します。
MHAでサーバ間でSSHできるかの確認とサーバー間でレプリケーションの確認をおこないます。コマンドは「masterha_check_ssh –conf=/etc/mha.cnf」と叩きます。
# SSHできるか確認
>$ masterha_check_ssh --conf=/etc/mha.cnf Tue Jun 20 10:39:05 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping. 〜〜 Tue Jun 20 10:39:05 2017 - [error][/usr/share/perl5/vendor_perl/MHA/SSHCheck.pm, ln63] SSH Configuration Check Failed!
SSHの接続確認で下記のような「[warning] Global configuration file 〜」と表示された場合は、/etc/masterha_default.cnfが無いと表示されるので、/etc/masterha_default.cnfを作成すればエラーは解消されます
>[warning] Global configuration file /etc/masterha_default.cnf not found. Skipping. $ sudo touch /etc/masterha_default.cnf
レプリケーションの動作確認をおこないます。コマンドは「masterha_check_repl –conf=/etc/mha.cnf」と叩きます。
>$ masterha_check_repl --conf=/etc/mha.cnf Tue Jun 20 13:33:33 2017 - [info] Reading default configuration from /etc/masterha_default.cnf.. Tue Jun 20 13:33:33 2017 - [info] Reading application default configuration from /etc/mha.cnf.. Tue Jun 20 13:33:33 2017 - [info] Reading server configuration from /etc/mha.cnf.. Tue Jun 20 13:33:33 2017 - [info] MHA::MasterMonitor version 0.56. Tue Jun 20 13:33:33 2017 - [info] GTID failover mode = 0 Tue Jun 20 13:33:33 2017 - [info] Dead Servers: Tue Jun 20 13:33:33 2017 - [info] Alive Servers: Tue Jun 20 13:33:35 2017 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln424] Error happened on checking configurations. SSH Configuration Check Failed! at /usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm line 369 Tue Jun 20 13:33:35 2017 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln523] Error happened on monitoring servers.
MHAプロセスの起動、停止及びプロセス確認
この作業はmha（192.168.11.100）で設定します。
MHAのプロセスの起動、停止、プロセスの確認する方法は以下となります。
MHAプロセスの起動ですが「masterha_manager –conf=/etc/mha.cnf」とすれば起動しますが、バックグランドで起動しないと他のコンソール作業ができないので、バックグランドで起動したほうがいいです
># MHAプロセス起動 $ masterha_manager --conf=/etc/mha.cnf バックグラウンドでプロセス起動する場合 $ nohup masterha_manager --conf=/etc/mha.cnf < /dev/null > /var/log/mha/mha.log 2>&1 & プロセス確認 $ masterha_check_status --conf=/etc/mha.cnf MHAプロセス停止 $ masterha_stop --conf=/etc/mha.cnf
フェイルオーバーの動作確認
MasterDBを停止して、SlaveDBのdb02がMasterとして昇格するかテストしてみます。
この作業はMasterDB（192.168.11.101）で設定します。MasterDBのMySQLを停止します
$ sudo /etc/init.d/mysqld stop mysqld を停止中: [ OK ]
ログを確認してフェイルオーバーしたか確認します。
Master failover to 192.168.11.102(192.168.11.102:3306) complete〜〜となっているので、192.168.11.102にフェイルオーバーしています。
>$ tail /var/tmp/mha/log/mha.log Wed Jun 21 10:30:37 2017 - [info] All relay logs were successfully applied. Wed Jun 21 10:30:37 2017 - [info] Resetting slave 192.168.11.103(192.168.11.103:3306) and starting replication from the new master 192.168.11.102(192.168.11.102:3306).. Wed Jun 21 10:30:37 2017 - [info] Executed CHANGE MASTER. Wed Jun 21 10:30:38 2017 - [info] Slave started. Wed Jun 21 10:30:38 2017 - [info] End of log messages from 192.168.11.103. Wed Jun 21 10:30:38 2017 - [info] -- Slave recovery on host 192.168.11.103(192.168.11.103:3306) succeeded. Wed Jun 21 10:30:38 2017 - [info] All new slave servers recovered successfully. Wed Jun 21 10:30:38 2017 - [info] Wed Jun 21 10:30:38 2017 - [info] * Phase 5: New master cleanup phase.. Wed Jun 21 10:30:38 2017 - [info] Wed Jun 21 10:30:38 2017 - [info] Resetting slave info on the new master.. Wed Jun 21 10:30:38 2017 - [info] 192.168.11.102: Resetting slave info succeeded. Wed Jun 21 10:30:38 2017 - [info] Master failover to 192.168.11.102(192.168.11.102:3306) completed successfully. Wed Jun 21 10:30:38 2017 - [info] ----- Failover Report ----- mha: MySQL Master failover 192.168.11.101(192.168.11.101:3306) to 192.168.11.102(192.168.11.102:3306) succeeded Master 192.168.11.101(192.168.11.101:3306) is down! Check MHA Manager logs at dbtest00:/var/tmp/mha/log/mha.log for details. Started automated(non-interactive) failover. The latest slave 192.168.11.102(192.168.11.102:3306) has all relay logs for recovery. Selected 192.168.11.102(192.168.11.102:3306) as a new master. 192.168.11.102(192.168.11.102:3306): OK: Applying all logs succeeded. 192.168.11.103(192.168.11.103:3306): This host has the latest relay log events. Generating relay diff files from the latest slave succeeded. 192.168.11.103(192.168.11.103:3306): OK: Applying all logs succeeded. Slave started, replicating from 192.168.11.102(192.168.11.102:3306) 192.168.11.102(192.168.11.102:3306): Resetting slave info succeeded. Master failover to 192.168.11.102(192.168.11.102:3306) completed successfully.
この作業はdb02（192.168.11.102）で設定します。db02で「SHOW SLAVE HOSTS」を叩き、接続されているホストを確認します。db02がMasterとなり、db03とレプリケーションできていることが確認できます
[admin@dbtest02 ‾]$ mysql -u root -pmomo1234 mysql> SHOW SLAVE HOSTS; +-----------+------+------+-------------------+-----------+ | Server_id | Host | Port | Rpl_recovery_rank | Master_id | +-----------+------+------+-------------------+-----------+ | 103 | db03 | 3306 | 0 | 102 | +-----------+------+------+-------------------+-----------+ 1 row in set (0.00 sec)
MySQL-MHA フェイルオーバーの戻し作業
元MasterDBをSlaveとして接続する
元MasterDB（db01）をdb02のスレーブとして接続してレプリケーション環境に組み込みます
１． db02をポジションを確認します。後でdb01のスレーブとして設定時にポジション情報は必要なのでメモしておきます
[admin@db02]$ mysql -u root -pmomo1234 mysql> show master status; +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000002 | 106 | | | +------------------+----------+--------------+------------------+ 1 row in set (0.00 sec)
２． db01のスレーブとして設定します。先程のMasterDBのポジション情報反映します
[admin@db01 ]$ mysql -u root -pmomo1234 mysql> stop slave; mysql> CHANGE MASTER TO MASTER_HOST = 'db02', MASTER_USER = 'repl', MASTER_PASSWORD = 'mikan321', MASTER_LOG_FILE = 'mysql-bin.000002', MASTER_LOG_POS = 106; マスター（db02）で接続を確認 [admin@db02 ]$ mysql -u root -pmomo1234 mysql> SHOW SLAVE HOSTS; +-----------+------+------+-------------------+-----------+ | Server_id | Host | Port | Rpl_recovery_rank | Master_id | +-----------+------+------+-------------------+-----------+ | 101 | db01 | 3306 | 0 | 102 | | 103 | db03 | 3306 | 0 | 102 | +-----------+------+------+-------------------+-----------+ 2 rows in set (0.00 sec)
今のMasterを停止して元Masterに切り替える
masterha_master_switchコマンドで、db01のスレーブサーバをマスターに昇格させて、元々のMasterします。手順としては今のMasterのdb02のMySQLを停止させればdb01がMasterとなります。
但し、mha.failover.completeファイルが作成されると、一定時間(デフォルト:8時間)経過後しかフェイルオーバーができません。対処策はmha.failover.completeを削除するか、–ignore_last_failover オプションをつけることで無効化してMHAプロセスの起動します
・mha.failover.completeが存在してもフェイルオーバーする方式での起動方法
$ nohup masterha_manager --conf=/etc/mha.cnf --ignore_last_failover < /dev/null > /var/log/mha/mha.log 2>&1 &
今回の作業では、mha.failover.complete を削除してフェイルオーバーするようにします
[admin@mha]$ rm -f /tmp/mha/mha.failover.complete
MHAプロセス停止を停止してから、masterha_master_switchコマンドで、db01をMasterとするようにします。コマンドを叩くと対話式でdb01とMasterとするか聞いてきます。「Yes」で進んでいけばOKです
>[admin@mha]$ masterha_stop --conf=/etc/mha.cnf MHA Manager is not running on mha(2:NOT_RUNNING). [admin@mha]$ masterha_master_switch --master_state=alive --conf=/etc/mha.cnf --new_master_host=db01 --orig_master_is_new_slave Wed Jun 21 13:33:39 2017 - [info] MHA::MasterRotate version 0.56. Wed Jun 21 13:33:39 2017 - [info] Starting online master switch.. Wed Jun 21 13:33:39 2017 - [info] Wed Jun 21 13:33:39 2017 - [info] * Phase 1: Configuration Check Phase.. 〜〜 It is better to execute FLUSH NO_WRITE_TO_BINLOG TABLES on the master before switching. Is it ok to execute on db02(192.168.11.102:3306)? (YES/no): yes db02(192.168.11.102:3306) (current master) +--db01(192.168.11.101:3306) +--db03(192.168.11.103:3306) To: db01(192.168.11.101:3306) (new master) +--db03(192.168.11.103:3306) +--db02(192.168.11.102:3306) Starting master switch from db02(192.168.11.102:3306) to db01(192.168.11.101:3306)? (yes/NO): yes Starting master switch from db02(192.168.11.102:3306) to db01(192.168.11.101:3306)? (yes/NO): yes Wed Jun 21 13:34:13 2017 - [info] Checking whether db01(192.168.11.101:3306) is ok for the new master.. Wed Jun 21 13:34:13 2017 - [info] ok. Wed Jun 21 13:34:13 2017 - [info] db02(192.168.11.102:3306): SHOW SLAVE STATUS returned empty result. To check replication filtering rules, temporarily executing CHANGE MASTER to a dummy host. Wed Jun 21 13:34:14 2017 - [info] db02(192.168.11.102:3306): Resetting slave pointing to the dummy host. Wed Jun 21 13:34:14 2017 - [info] ** Phase 1: Configuration Check Phase completed. Wed Jun 21 13:34:14 2017 - [info] Wed Jun 21 13:34:14 2017 - [info] * Phase 2: Rejecting updates Phase.. Wed Jun 21 13:34:14 2017 - [info] master_ip_online_change_script is not defined. If you do not disable writes on the current master manually, applications keep writing on the current master. Is it ok to proceed? (yes/NO): yes # db01で接続しているホストを確認します [admin@dbtest01]$ mysql -u root -pmomo1234 mysql> SHOW SLAVE HOSTS; +-----------+------+------+-------------------+-----------+ | Server_id | Host | Port | Rpl_recovery_rank | Master_id | +-----------+------+------+-------------------+-----------+ | 103 | db03 | 3306 | 0 | 101 | | 102 | db02 | 3306 | 0 | 101 | +-----------+------+------+-------------------+-----------+ # db02でMaster_HOSTの情報を確認します [admin@db02 ]$ mysql -uroot -pmomo1234 -e "show slave status¥G" | grep "Master_Host" Master_Host: db01 # db03でMaster_HOSTの情報を確認します [admin@db03 ‾]$ mysql -uroot -pmomo1234 -e "show slave status¥G" | grep "Master_Host" Master_Host: db01
masterha_master_switchのドキュメント
masterha_master_switchコマンドの参考資料です
– conf
設定ファイルの指定
– master_state=dead
必須パラメータ。
masterが生きている状態で行う場合には「alive」を設定する。（オンラインマスタースイッチになる）
死んでる状態で切り替える場合には「dead」を設定する。– dead_master_host =（ホスト名）
master_state=deadを指定した場合には、必須パラメータ。
死んでるとmasterの指定（死んでると仮定するmasterの指定)。– dead_master_ip
gethostbyname（dead_master_host）の結果になる。– dead_master_port
デフォルトは3306。– new_master_host =（ホスト名）
新しいmasterの指定。デフォルトのmha managerの自動フェイルオーバーによるslaveの選択ではなくなる。– interactive=（0 | 1）
0:非対話型フェイルオーバー
1:対話型フェイルオーバー– ssh_reachable =（0 | 1 | 2）
masterにSSH経由で到達可能であるかどうかを指定します。
0:SSHが到達不可の場合
1:SSHが到達可能な場合
2:SSHが到達可能か不明の場合(デフォルト)
デフォルトの2が設定されている場合には、SSH接続が可能かチェックして、0または1にステータスを変更する。
このコマンドは、内部的にマスターはSSHまたはしない経由で到達可能かチェックし、0または1を使って内部のSSHステータスを更新します。
masterがSSH経由で到達可能である場合、master_ip_failover_script、shutdown_scriptが設定されている場合には、
" -command=stopssh"が実行される。
また、masterからバイナリーログがコピーされる。
設定されていない場合には、masterha_master_switchの" -command=stop"が実行される。– skip_change_master
差動リレーのログを適用した後のCHANGE MASTER TOコマンドをスキップする。– skip_disable_read_only
新しいmasterにread_only=0の設定をスキップする。– last_failover_minute =（分）
以前のフェイルオーバーから指定された時間内に再度フェイルオーバーを実行することになった場合に、
フェイルオーバーを行わない。（デフォルトでは480分。８時間）。
ただし、ignore_last_failoverが設定されている場合には、無効になる。– ignore_last_failover
以前フェイルオーバーが失敗した場合に再び同じ現象が起こる可能性があるので、、
last_failover_minuteで指定された時間を経過するまではフェイルオーバーを開始しないため、
それを無効化するためのもの。– wait_on_failover_error =（秒）
フェイルオーバー失敗時に、指定された秒数待機してから終了する。
デーモンスクリプトから自動化されたmasterの監視とフェイルオーバー用に、再び監視させるまでの待機時間ように。– remove_dead_master_conf
フェイルオーバーが正常終了した場合に、死んだmasterの設定ファイルのセクション名を削除する。（デフォルトは削除されない）