概要

先日MySQLのMaster-Slaveレプリケーションが何かの拍子に機能しなくなっていることがわかりました。
このような状況に陥ったときの修正手順についてまとめてみます。

環境:

  • Debian lenny
  • MySQL 5.0.51
  • 1台のマスタから1台のスレーブに対してレプリケーションしている構成

修正前のSlave状態

まず、現在のSlaveの状態を確認します。

mysql> show slave status\G
*************************** 1. row ***************************
             Slave_IO_State:
                Master_Host: xxx.xxx.xxx
                Master_User: repl
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysqld-bin.000005
        Read_Master_Log_Pos: 13341150
             Relay_Log_File: mysqld-relay-bin.000232
              Relay_Log_Pos: 98
      Relay_Master_Log_File: mysqld-bin.000005
           Slave_IO_Running: No
          Slave_SQL_Running: Yes
            Replicate_Do_DB: 
        Replicate_Ignore_DB:
         Replicate_Do_Table:
     Replicate_Ignore_Table:
    Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
                 Last_Errno: 0
                 Last_Error:
               Skip_Counter: 0
        Exec_Master_Log_Pos: 13341150
            Relay_Log_Space: 98
            Until_Condition: None
             Until_Log_File:
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File:
         Master_SSL_CA_Path:
            Master_SSL_Cert:
          Master_SSL_Cipher:
             Master_SSL_Key:
      Seconds_Behind_Master: NULL
1 row in set (0.01 sec)

⇒「Slave_IO_Running: No 」になっています。
ちなみにマスタの状態は、、

mysql> show master status\G
*************************** 1. row ***************************
            File: mysqld-bin.000009
        Position: 42782848
    Binlog_Do_DB:
Binlog_Ignore_DB:
1 row in set (0.00 sec)

となっています。明らかにずれています。

復旧手順

MasterのバックアップとPositionの確認

Masterのバックアップを取ると同時にLog Positionを確認しておきます。

(Master側で)
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;
※ここで表示される FileとPositionの値を記録しておく。

バックアップはmysqldumpコマンドで行ないます。

$ mysqldump -u root -p --lock-all-tables --databases db1 db2 ...  > mysql.dmp

バックアップが終わったらロックを解除します。

(Master側で)
mysql> UNLOCK TABLES;

※ここまでの間、DBへの書き込みがブロックされることになります。

Slave側にバックアップを適用

Masterで取得したバックアップファイルをSlaveに適用します。

(Slave側で)
mysql> drop database db1 db2 ....;
$ mysql -u root -p < mysql.dmp

Slave側でMasterのpositionをセットしてレプリケーション開始

Masterバックアップ時に記録したFile名とPotisionをSlaveにセットしてレプリケーションを開始します。

(Slave側で)
mysql> CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001',  MASTER_LOG_POS=4320981;
mysql> START SLAVE;

これで完了。Master側で SHOW MASTER STATUS, Slave側で SHOW SLAVE STATUSを実行してレプリケーションが機能していることを確認します。

Nagiosでのレプリケーション監視

WEB+DB PRESS vol.54に書いてあるとおりなのですがNagiosでレプリケーションの監視ができることを知りました。
標準プラグインで提供されている「check_mysql」を使用するのですがDebianの場合は
/etc/nagios-plugins/config/mysql.cfg に以下のように追記してコマンドを用意しました。

# 'check_mysql_slave' command definition
define command{
        command_name    check_mysql_slave
        command_line    /usr/lib/nagios/plugins/check_mysql -H '$HOSTADDRESS$' -u '$ARG1$' '$ARG2$'
}

そしてサーバの定義ファイルに

define service{
        use                             generic-service
        host_name                  localhost
        service_description       mysql
        check_command         check_mysql_slave!nagios!-S
}

のように設定します。

※監視用につかう nagiosユーザには REPLICATION CLIENTに加えて SUPERの権限が必要でした。

mysql> GRANT SUPER,REPLICATION CLIENT ON *.* TO nagios@localhost;

※今回は既に一度レプリケーション構成を構築していた環境で再設定することについてまとめましたが、一からレプリケーション構成を構築する場合にはこれに加えていくつかの作業が必要となります。下記のリンクなどが参考になります。

参考

コメントは受け付けていません。