前回は1台構成で動作を確認したため今回は全て別なサーバで構築したと想定し、動作するか確認しました。
検証環境
- 全てKVMのゲスト環境。CentOS6.3 64bit
- MySQL5.6はRC版を使用(全サーバで3306ポートで起動)
- MySQL Workbenchは5.2.44を使用
- MasterのIPアドレスを192.168.1.237
- Slave1のIPアドレスを192.168.1.238(read_onlyをON)
- Slave2のIPアドレスを192.168.1.240(read_onlyをON)
- mysqlfailoverを実行するのが192.168.1.239
- mysqlfailover用のアカウントとしてfailover@192.168.1.%をALL権限で作成(パスワードもfailoverにしています)
- GRANT ALL PRIVILEGES ON *.* TO 'failover'@'192.168.1.%' IDENTIFIED BY PASSWORD '*略'
レプリケーションユーザについて
何度か検証しましたが、おそらく現状のmysqlfailoverコマンドではレプリケーション用ユーザとしてrepl@192.168.1.%のように%を使うとmysqlfailoverのレプリケーションユーザの存在確認処理でマッチしないため、個別にアカウントを作成する必要があるようです。
そのため、レプリケーションユーザとして以下のように3ユーザ作成しています。
- repl@192.168.1.237
- repl@192.168.1.238
- repl@192.168.1.240
%を使うと必ず動作不可なのかはなんとも言えませんが、今の所%を使って正常動作する方法が分かっていません。
replication.pyの修正
前回replication.pyを修正していましたが、今回も修正しています。ただし修正する箇所を変更して以下のようにしています。
# diff -urN mysql-wb/lib/python2.6/site-packages/mysql/utilities/common/replication.py{.20121101,} --- mysql-wb/lib/python2.6/site-packages/mysql/utilities/common/replication.py.20121101 2012-09-27 05:50:38.000000000 +0900 +++ mysql-wb/lib/python2.6/site-packages/mysql/utilities/common/replication.py 2012-11-01 02:54:42.991980521 +0900 @@ -1077,7 +1077,7 @@ # Build dictionary for the information with column information rows = [] for i in range(0, len(res[0][2:])): - rows.append(res[0][i+2]) + rows.append(res[0][i+1]) self._build_dictionary(rows) return True #
SELECT * FROM mysql.slave_master_infoを行い、値を取る処理でズレが発生しているため、取得段階で適切な位置となるよう修正する方が妥当と考えたためです。
なお、今回はserver.pyは変更していません。
mysqlfailoverの実行
準備が出来た所で動作確認を行います。
今回はfailover用ユーザを作成したため以下のように実行した後、MasterのMySQLを停止します。
# /usr/local/mysql-wb/bin/mysqlfailover \ --master=failover:failover@192.168.1.237 \ --slaves=failover:failover@192.168.1.238,failover:failover@192.168.1.240 \ --candidates=failover:failover@192.168.1.238 \ --log=/tmp/failover.log
MasterのMySQL停止後のコンソール出力とかは以下のように。一部欠けたので後日補完します。
Failover starting in 'auto' mode... # Candidate slave 192.168.1.238:3306 will become the new master. # Preparing candidate for failover. # Creating replication user if it does not exist. # Stopping slaves. # Performing STOP on all slaves. # Switching slaves to new master. # Starting slaves. # Performing START on all slaves. /tmp/failover.logへの出力 2012-11-01 03:12:53 AM INFO Master may be down. Waiting for 3 seconds. 2012-11-01 03:12:56 AM INFO Cannot reconnect to master. 2012-11-01 03:12:59 AM CRITICAL Master is confirmed to be down or unreachable. 2012-11-01 03:12:59 AM INFO Failover starting in 'auto' mode... 2012-11-01 03:12:59 AM INFO Candidate slave 192.168.1.238:3306 will become the new master. 2012-11-01 03:12:59 AM INFO Preparing candidate for failover. 2012-11-01 03:13:50 AM INFO Creating replication user if it does not exist. 2012-11-01 03:13:50 AM INFO Stopping slaves. 2012-11-01 03:13:50 AM INFO Performing STOP on all slaves. 2012-11-01 03:13:50 AM INFO Switching slaves to new master. 2012-11-01 03:13:50 AM INFO Starting slaves. 2012-11-01 03:13:50 AM INFO Performing START on all slaves. 2012-11-01 03:14:41 AM INFO Checking slaves for errors. 2012-11-01 03:14:41 AM INFO Failover complete.
切り替え後のmysqlfailoverを実行していたコンソールは以下のように。
MySQL Replication Failover Utility Failover Mode = auto Next Interval = Thu Nov 1 03:16:49 2012 Master Information ------------------ Binary Log File Position Binlog_Do_DB Binlog_Ignore_DB mysql-bin.000002 1396 Replication Health Status +----------------+-------+---------+--------+------------+-----------------------------+ | host | port | role | state | gtid_mode | health | +----------------+-------+---------+--------+------------+-----------------------------+ | 192.168.1.238 | 3306 | MASTER | UP | ON | OK | | 192.168.1.240 | 3306 | SLAVE | UP | ON | SQL thread is not running. | +----------------+-------+---------+--------+------------+-----------------------------+ Q-quit R-refresh H-health G-GTID Lists U-UUIDs L-log entries
Masterへ昇格したMySQLのread_onlyがOFFになることを期待したのですがONのままでした…
failoverユーザはALLなので変更可能だし、まだどこか設定に不備があるのかもしれません。
server.py, topology.pyを見る限りはOFFにしてくれそうな処理があったのでちゃんと動いた場合はOFFにしてくれるのでは無いかと。read_onlyについても上手く修正されるようになったら再度書きたいと思います。