続・MySQL5.6-rcでmysqlfailoverを試してみた

前回は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についても上手く修正されるようになったら再度書きたいと思います。