MySQL5.6.17 → 5.6.19にアップデートしたのでその手順のメモ

MySQLをアップデートしたのでその手順のメモです。GTIDを使用したレプリケーション環境だったので、マスターアップデート中にスレーブをマスターに昇格させることで、ダウンタイム無しでアップデートを行うことが出来ました。

環境

マスター(192.168.1.2)
CentOS6.5 MySQL5.6.17
スレーブ(192.168.1.3)
CentOS6.5 MySQL5.6.17

マスター・スレーブ共にMySQLはRPMパッケージからインストールしてます。

また、マスター・スレーブ共にバイナリログを出力するように設定しています。具体的には下記の様にmy.cnfを設定しています。

[mysqld]
server-id=1
log-bin=mysql-bin
log-bin-index=mysql-bin
binlog-do-db=wordpress
binlog_format=MIXED
expire-logs-days=3
log-slave-update
gtid-mode=ON
enforce-gtid-consistency
[mysqld]
server-id=2
log-bin=mysql-bin
log-bin-index=mysql-bin
binlog-do-db=wordpress
binlog_format=MIXED
expire-logs-days=3
log-slave-update
gtid-mode=ON
enforce-gtid-consistency

master-host=192.168.1.2
master-user=repl
master-password=PASSWORD
relay-log=relay-bin
relay-log-index=relay-bin
replicate-do-db=wordpress

DBサーバーの向け変えとレプリケーションの停止

先ずアプリケーション側の設定でデータベースの参照先がマスターになっているものをスレーブに変更します。
スレーブに向け変えたらレプリケーションをストップします。

mysql> STOP SLAVE;
Query OK, 0 rows affected (0.02 sec)

mysql> RESET SLAVE;
Query OK, 0 rows affected (0.06 sec)

向け変え直後は以下の様にマスター・スレーブ共にSHOW MASTER STATUSコマンドのExecuted_Gtid_Setの値は同じになっています。

mysql> SHOW MASTER STATUS\G
*************************** 1. row ***************************
             File: mysql-bin.000001
         Position: 2218281
     Binlog_Do_DB: wordpress
 Binlog_Ignore_DB: 
Executed_Gtid_Set: e8bc325e-f538-11e3-81e9-525405020099:1-2718
1 row in set (0.00 sec)
*************************** 1. row ***************************
             File: mysql-bin.000002
         Position: 2212004
     Binlog_Do_DB: wordpress
 Binlog_Ignore_DB: 
Executed_Gtid_Set: e8bc325e-f538-11e3-81e9-525405020099:1-10:12-2718
1 row in set (0.00 sec)

現在アプリケーションはスレーブに書き込む様になっていますので、アプリケーションから更新処理を行うと以下のようにスレーブのみのExecuted_Gtid_Setが変更されることを確認します。

mysql> SHOW MASTER STATUS\G
*************************** 1. row ***************************
             File: mysql-bin.000001
         Position: 2218281
     Binlog_Do_DB: wordpress
 Binlog_Ignore_DB: 
Executed_Gtid_Set: e8bc325e-f538-11e3-81e9-525405020099:1-2718
1 row in set (0.00 sec)
mysql> SHOW MASTER STATUS\G
*************************** 1. row ***************************
             File: mysql-bin.000002
         Position: 2235999
     Binlog_Do_DB: wordpress
 Binlog_Ignore_DB: 
Executed_Gtid_Set: cabe8ba1-efc3-11e3-9e53-525405003375:1-28,
e8bc325e-f538-11e3-81e9-525405020099:1-10:12-2718
1 row in set (0.00 sec)

マスターサーバーのMySQL停止とバックアップ

アプリケーションのDBの向け先をスレーブに変更し、レプリケーションを停止した状態にすると、マスターサーバーが孤立した状態になります。この状態でマスターサーバーを停止させます。

service mysql stop

mysqlサーバーのデーモンを停止させたら一応データのバックアップをとっておきます。

cp -p /usr/my.cnf{,.`date '+%Y%m%d'`}
cp -rp /var/lib/mysql{,.`date '+%Y%m%d'`}

マスターサーバーのMySQL5.6.17アンインストールとMySQL5.6.19インストール

以下のコマンドでインストールされているMySQLのパッケージを調べます。

rpm -qa | grep -i mysql

今回の結果では以下の様になりましたので、すべて削除します。

MySQL-shared-compat-5.6.17-1.linux_glibc2.5.x86_64
MySQL-server-5.6.17-1.linux_glibc2.5.x86_64
MySQL-shared-5.6.17-1.linux_glibc2.5.x86_64
MySQL-client-5.6.17-1.linux_glibc2.5.x86_64
MySQL-embedded-5.6.17-1.linux_glibc2.5.x86_64
MySQL-devel-5.6.17-1.linux_glibc2.5.x86_64
rpm -e MySQL-embedded
rpm -e MySQL-devel
rpm -e MySQL-client
rpm -e MySQL-shared
rpm -e MySQL-server 
rpm -e MySQL-shared-compat

アンインストールが完了したら、MySQL5.6.19のパッケージをダウンロードして展開します。

wget http://dev.mysql.com/get/Downloads/MySQL-5.6/MySQL-5.6.19-1.linux_glibc2.5.x86_64.rpm-bundle.tar
tar xvf MySQL-5.6.19-1.linux_glibc2.5.x86_64.rpm-bundle.tar 

展開したものをインストールします。

rpm -ivh MySQL-shared-compat-5.6.19-1.linux_glibc2.5.x86_64.rpm
rpm -ivh MySQL-shared-5.6.19-1.linux_glibc2.5.x86_64.rpm
rpm -ivh MySQL-devel-5.6.19-1.linux_glibc2.5.x86_64.rpm
rpm -ivh MySQL-client-5.6.19-1.linux_glibc2.5.x86_64.rpm 
rpm -ivh MySQL-server-5.6.19-1.linux_glibc2.5.x86_64.rpm
rpm -ivh MySQL-embedded-5.6.19-1.linux_glibc2.5.x86_64.rpm 

インストールが完了したら、MySQLサーバーを起動します。

service mysql start

正常に完了すればバージョンが上がっているのが確認できます。

mysql --version
mysql  Ver 14.14 Distrib 5.6.19, for Linux (x86_64) using  EditLine wrapper

差分データ取得

マスターサーバーのアップデートが完了したら、この間にスレーブサーバーに更新されたデータがあるかもしれませんので、このデータを取得するようにします。差分データを取得するには、一旦マスターサーバーをスレーブとしてレプリケーションを開始します。

mysql> CHANGE MASTER TO
    -> master_host='192.168.1.3',
    -> master_port=3306,
    -> master_user='root',
    -> master_password='PASSWORD',
    -> master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (1.58 sec)

mysql> START SLAVE;
Query OK, 0 rows affected (0.03 sec)

スレーブ(192.168.1.3)側にはレプリケーション用のユーザーが存在しなかったので、rootで開始しています。

レプリケーションを開始したら、マスター・スレーブのExecuted_Gtid_Setの値を確認して、差分が反映されているか確認します。

mysql> SHOW MASTER STATUS\G
*************************** 1. row ***************************
             File: mysql-bin.000002
         Position: 63048
     Binlog_Do_DB: wordpress
 Binlog_Ignore_DB: 
Executed_Gtid_Set: cabe8ba1-efc3-11e3-9e53-525405003375:1-47,
e8bc325e-f538-11e3-81e9-525405020099:1-2718
1 row in set (0.00 sec)
mysql> SHOW MASTER STATUS\G
*************************** 1. row ***************************
             File: mysql-bin.000002
         Position: 2254924
     Binlog_Do_DB: wordpress
 Binlog_Ignore_DB: 
Executed_Gtid_Set: cabe8ba1-efc3-11e3-9e53-525405003375:1-47,
e8bc325e-f538-11e3-81e9-525405020099:1-10:12-2718
1 row in set (0.00 sec)

スレーブ上のみにあったGTIDがマスター側にも反映されましたので、これで差分データは取り込めたはずです。これが確認できたら、アプリケーションのDBの向け先をマスター(192.168.1.2)に変更します。

そしてレプリケーションを停止します。

mysql> STOP SLAVE;
Query OK, 0 rows affected (0.02 sec)

mysql> RESET SLAVE;
Query OK, 0 rows affected (0.47 sec)

スレーブサーバーのアップデート

スレーブサーバーもマスターサーバーと同様にアップデートを行います。

  1. MySQLデーモン停止
  2. my.cnf、データディレクトリバックアップ
  3. MySQL5.6.17アンインストール
  4. MySQL5.6.20インストール
  5. MySQLデーモン起動

アップデートが完了したらレプリケーションを開始します。

mysql> CHANGE MASTER TO
    -> master_host='192.168.1.2',
    -> master_port=3306,
    -> master_user='repl',
    -> master_password='PASSWORD',
    -> master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.17 sec)

mysql> START SLAVE;
Query OK, 0 rows affected (0.02 sec)

SHOW SLAVE STATUSコマンドでスレーブの状態を確認します。

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.1.2
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000002
          Read_Master_Log_Pos: 63048
               Relay_Log_File: relay-bin.000003
                Relay_Log_Pos: 20441
        Relay_Master_Log_File: mysql-bin.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: wordpress
          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: 63048
              Relay_Log_Space: 21152
              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: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 1
                  Master_UUID: e8bc325e-f538-11e3-81e9-525405020099
             Master_Info_File: /var/lib/mysql/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: e8bc325e-f538-11e3-81e9-525405020099:11:2719-2746
            Executed_Gtid_Set: cabe8ba1-efc3-11e3-9e53-525405003375:1-47,
e8bc325e-f538-11e3-81e9-525405020099:1-2746
                Auto_Position: 1
1 row in set (0.00 sec)

問題がなければ以上で完了です。

まとめ

  • GTIDはサーバーのUUID+連番で発行される。UUIDは「データディレクトリ/auto.cnf」に書いてある。
  • MySQLをアンインストールしてもデータディレクトリは消えない。データディレクトリが消えない限りはGTIDも消えないっぽい。
  • RESET SLAVEではExecuted_Gtid_Setは消えない。RESET MASTERで消える

コメントを残す