MySQL升級-5.6升級到5.7版本&切換GTID模式

時間 2019-12-08

標籤 mysql 升級 5.6升 5.7 版本切換 gtid 模式欄目 MySQL 简体版

原文原文鏈接

目前未在生產環境中升級過數據庫版本，卻是在測試環境跟開發環境升級過。

能夠經過mysqldump sql文件進行升級，也能夠經過mysql_upgrade升級，前者耗時較長，且須要足夠量的磁盤空間，本文暫不討論，升級使用mysql_upgrade方式。

若是轉載，請註明博文來源： www.cnblogs.com/xinysu/ ，版權歸博客園蘇家小蘿蔔全部。望各位支持！

若是是線上環境升級，常規來講分爲如下幾個步驟：

從庫先升級

業務遷移，從庫上如有隻讀業務或者其餘，遷移到其餘DB實例
從庫備份
從庫中止複製
升級
從庫恢復複製（升級後主庫還是5.6版本，從庫是5.7版本，注意是否有異常）
主從恢復正常

主從切換
新從庫升級

新從庫中止複製
新從庫備份
升級
新從庫恢復複製
主從恢復正常
恢復相關業務

本文主要記錄升級的詳細步驟、主庫5.6從庫5.7有哪些問題以及如何從傳統模式轉變爲GTID模式。

1 MySQL5.6升級到5.7版本

升級步驟簡要以下：

安裝新版本mysql，從庫服務器安裝5.7版本mysql
修改安裝目錄配置參數，修改從庫的mysql配置文件，把 mysql 安裝目錄修改成 5.7版本的安裝目錄
關閉從庫mysql服務
新版本mysql啓動實例，使用5.7版本mysql啓動待升級實例
升級字典，使用mysql_upgrade升級字典
檢查，查看mysql log日誌

#1 安裝新版本mysql
## 下載mysql5.7.17，拷貝到server下的/opt文件目錄下
## 解壓，建立軟鏈接，受權
tar zvxf mysql-5.7.17-linux-glibc2.5-x86_64.tar.gz
ln -s /opt/mysql-5.7.17-linux-glibc2.5-x86_64 /usr/local/mysql57
chown -R mysql:mysql /usr/data/mysql57
 
#2 修改配置參數
## 檢查配置文件中那些配置是使用到了 安裝目錄，把使用到底都修改
舊：
basedir = /usr/local/mysql56
plugin-dir = /usr/local/mysql56/lib/plugin/
 
新：
basedir = /usr/local/mysql
plugin-dir = /usr/local/mysql/lib/plugin/
 
#3 關閉mysql
[root@sutest244 mysqlup]# /usr/local/mysql56/bin/mysqladmin --socket=/tmp/mysql3399.sock -uroot -p shutdown
Enter password:
[root@sutest244 mysqlup]# ps axu | grep mysql3399 | grep mysqld
[root@sutest244 mysqlup]#
 
#4 新版本啓動mysql
[root@sutest244 mysqlup]# /usr/local/mysql/bin/mysqld --defaults-file=/data/mysqlup/mysql3399.cnf &
[1] 15477
[root@sutest244 mysqlup]# ps axu | grep mysql3399 | grep mysqld
mysql    15477 37.1 26.7 11931672 1037520 pts/4 Sl  03:34   0:05 /usr/local/mysql/bin/mysqld --defaults-file=/data/mysqlup/mysql3399.cnf
[root@sutest244 mysqlup]#
[root@sutest244 mysqlup]# vim /data/mysqlup/data/error.log
 
#4.1 檢查
檢查啓動後的錯誤日誌，看下是否有配置參數報錯，若是有，修改
錯誤日誌會有大量的字典信息報錯，這個暫不處理，下個步驟修復
 
#5 升級字典
[root@sutest244 bin]# /usr/local/mysql/bin/mysql_upgrade --socket=/tmp/mysql3399.sock -uroot -p
Enter password:
Checking if update is needed.
Checking server version.
Running queries to upgrade MySQL server.
Checking system database.
mysql.columns_priv                                 OK
mysql.db                                           OK
mysql.engine_cost                                  OK
mysql.event                                        OK
mysql.func                                         OK
mysql.general_log                                  OK
mysql.gtid_executed                                OK
mysql.help_category                                OK
mysql.help_keyword                                 OK
mysql.help_relation                                OK
mysql.help_topic                                   OK
mysql.innodb_index_stats                           OK
mysql.innodb_table_stats                           OK
mysql.ndb_binlog_index                             OK
mysql.plugin                                       OK
mysql.proc                                         OK
mysql.procs_priv                                   OK
mysql.proxies_priv                                 OK
mysql.server_cost                                  OK
mysql.servers                                      OK
mysql.slave_master_info                            OK
mysql.slave_relay_log_info                         OK
mysql.slave_worker_info                            OK
mysql.slow_log                                     OK
mysql.tables_priv                                  OK
mysql.time_zone                                    OK
mysql.time_zone_leap_second                        OK
mysql.time_zone_name                               OK
mysql.time_zone_transition                         OK
mysql.time_zone_transition_type                    OK
mysql.user                                         OK
Upgrading the sys schema.
Checking databases.
sys.sys_config                                     OK
省略...
檢查用戶數據庫及表格
省略...
Upgrade process completed successfully.
Checking if update is needed.
 
#6 檢查日誌
查看log日誌正常。

2 主庫5.6從庫5.7存在問題

因爲從庫是5.7版本，mysql、performance、sys等一些系統數據庫對象有發生變化，同時一些SQL也有所變更。

2.1 修改用戶密碼失敗

1). 問題

主庫修改用戶密碼，update mysql.user set password=password('newpasswd') where ...

2018-03-29T01:22:45.058927Z 12 [ERROR] Slave SQL for channel '': Column 1 of table 'mysql.user' cannot be converted from type 'char(16)' to type 'char(32)', Error_code: 1677
2018-03-29T01:22:45.059066Z 12 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'bin_log.000003' position 3208

2). 分析

修改致使從庫複製異常中止，由於 5.6版本mysql.user表格的password字段，在5.7沒有該字段，修改成 authentication_string

3). 處理

方案1：事先處理，執行update password 的前，配置會話不記錄binlog：set session sql_log_bin=off，而後單獨到主從執行該SQL

方案2：過後處理，若是已經出現這個錯誤，則在從庫跳過該sql而後再開啓複製同步，最後從庫修改密碼

set global sql_slave_skip_counter=1;
start slave sql_thread;
show slave status;
set session sql_log_bin=off;
alter user suuser@'%' identified by 'newpassword';
flush privileges;
set session sql_log_bin=on;

2.2 SQL語法問題

1). 問題

SELECT字段超過GROUP BY字段報錯

select id,name,age,count(*) from tbuser group by name;

其餘一些SQL語法問題

2).分析

5.7跟5.6默認的sql_mode配置不同，若是mysql配置文件中沒有說明sql_mode，升級後sql_mode將從NO_ENGINE_SUBSTITUTION修改成ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION，該模式下會致使部分在5.6支持的SQL在5.7報語法錯誤。

3). 處理

方案1：事先處理，在測試環境中，詳細測試程序代碼在新版本數據庫上的兼容性，如有異常，則修復程序代碼中的SQL操做邏輯。

方案2：事先處理，mysql配置文件中，指定sql_mode與5.6版本一致。

方案3：過後處理，若是已經在出現這個錯誤，有須要快速響應處理，能夠把sql_mode修改成跟5.6版本默認的sql_mode一致便可。

3 切換GTID模式

3.1 何爲GTID

Global Transaction ID，全局惟一標識，簡稱GTID，一個GTID 表明在某個實例上發生的一個事務。

GTID = source_id:transaction_id，其中source_id表明執行該事務的實例的server_uuid，transaction_id是自增值，從1開始，故GTID實際表示爲：在 source_id 實例上面發生的第 transaction_id 個事務。

3.2 GTID相關配置參數

ENFORCE_GTID_CONSISTENCY

warn

若是出現GTID不兼容的語句用法，在錯誤日誌會記錄相關信息，那麼須要調整應該程序避免不兼容的寫法，直到徹底沒有產生不兼容的語句，能夠經過應該程序去排查全部的sql，也能夠設置後觀察錯誤日誌一段時間，這一步很是重要。

啓動強制GTID一致性

GTID_MODE

說明

新事務是非GTID, Slave只接受不帶GTID的事務，傳送來GTID的事務會報錯

OFF_PERMISSIVE

新事務是非GTID, Slave只接受不帶GTID的事務也接受帶GTID的事務

ON_PERMISSIVE

新事務是GTID, Slave只接受不帶GTID的事務也接受帶GTID的事務

新事務是GTID, Slave只接受帶GTID的事務

切換順序

須要嚴格按照如下順序，不可跳躍
OFF <= => OFF_PERMISSIVE <= => ON_PERMISSIVE <= => ON

3.3 傳統複製切換GTID複製

#step 1 
#修改 ENFORCE_GTID_CONSISTENCY 爲 warn ，運行一段時間，檢查錯誤日誌裏邊是否存在於GTID不兼容的語句用法，並儘快修復
#主從都執行，前後順序不要求
set @@global.enforce_gtid_consistency=warn;
 
#step 2
#修改 ENFORCE_GTID_CONSISTENCY 爲 on ，肯定沒有不兼容語法後，能夠修改成ON
#主從都執行，前後順序不要求
set @@global.enforce_gtid_consistency=on;
 
#step 3
#設置GTID_MODE爲off_permissiv
#主從都執行，前後順序不要求
SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;
 
#step 4
#設置GTID_MODE爲off_permissiv=on_permissiv
#主從都執行，前後順序不要求
SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;
 
#step 5
# 檢查所有實例 正在進行的匿名交易數目，也就是非GTID事務有沒有都傳送到從庫上了，須要等到這個變量爲 0 纔是能夠進行下面操做
#主從都執行，前後順序不要求
SHOW STATUS LIKE 'ONGOING_ANONYMOUS_TRANSACTION_COUNT';
 
#step 6
#檢查全部實例上面的slave的非GTID是否都執行完了
show master status;#取file跟pos到從庫去執行查看
SELECT MASTER_POS_WAIT('bin_log.000003', 88748605); #返回結果大於等於0則說明事務已經徹底複製完成
 
 
#step 7
#清理binlog，切換到新的binlog上面
#主從都執行，前後順序不要求
flush logs;
 
#step8
#啓動GTID
#主從都執行，前後順序不要求
SET @@GLOBAL.GTID_MODE = ON;
 
#step 9
#修改cnf文件
#主從都執行，前後順序不要求
gtid_mode=on
enforce-gtid-consistency=on
binlog_gtid_simple_recovery=1

3.4 GTID複製切換傳統複製

#step 1
#中止從庫
#全部從庫都執行，前後順序不要求
stop slave;
 
#step 2
#重置chanage master to語句，關閉 master_auto_position
#全部從庫都執行，前後順序不要求
show slave status \G; #取sql_thread的file跟position位置，Relay_Master_Log_File  Exec_Master_Log_Pos
change master to master_log_file='mysql-bin.000003',master_log_pos=4563,master_auto_position=0;
 
#step 3
#測試同步是否正常
#主庫對數據進行操做，看從庫的position有沒有變化，同時看數據是否變動
 
#step 4
#修改GTID_MODE 爲 ON_PERMISSIVE
#主從都執行
SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;
 
#step 5
#修改GTID_MODE 爲 OFF_PERMISSIVE
#主從都執行
SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;
 
#step 6
#修改GTID_MODE 爲 OFF
#主從都執行
SET @@GLOBAL.GTID_MODE = OFF;
 
#step 7
#清理binlog，切換到新的binlog上面
#主從都執行，前後順序不要求
flush logs;
 
#step8
#禁用GTID，其中enforce-gtid-consistency能夠不關閉，仍是進行 GTID的一致性檢查
#主從都執行，前後順序不要求
SET @@GLOBAL.GTID_MODE = OFF;
 
#step9
#檢驗同步狀況
 
#10
#修改cnf文件，註釋GTID的參數
#主從都執行，前後順序不要求
#gtid_mode=on
#enforce-gtid-consistency=on
#binlog_gtid_simple_recovery=1