MySQL數(shù)據(jù)庫(kù)升級(jí)的坑有哪些

這篇文章主要介紹“MySQL數(shù)據(jù)庫(kù)升級(jí)的坑有哪些”，在日常操作中，相信很多人在MySQL數(shù)據(jù)庫(kù)升級(jí)的坑有哪些問題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”MySQL數(shù)據(jù)庫(kù)升級(jí)的坑有哪些”的疑惑有所幫助！接下來，請(qǐng)跟著小編一起來學(xué)習(xí)吧！

一般來說，升級(jí)MySQL有兩類可行方案，一類是直接升級(jí)數(shù)據(jù)字典，在本機(jī)完成，整個(gè)過程會(huì)有離線操作，會(huì)對(duì)業(yè)務(wù)有中斷，第二種是通過高可用切換平滑實(shí)現(xiàn)，原理是搭建低版本到高版本的數(shù)據(jù)復(fù)制關(guān)系，這種方案優(yōu)勢(shì)比較明顯，對(duì)于業(yè)務(wù)的侵入性比較低，而且還可以提前驗(yàn)證，更甚還可以做到平滑回退，當(dāng)然第二種方案要做很多前期的準(zhǔn)備工作。

今天處理的一套環(huán)境基于存儲(chǔ)和時(shí)長(zhǎng)等因素使用的是第一種方法，整個(gè)流程如下：

1) mysqldump備份數(shù)據(jù)庫(kù)，備份文件大約為120G

2) 停止MySQL 5.5數(shù)據(jù)庫(kù)

3) 修改數(shù)據(jù)庫(kù)端口重新啟動(dòng)數(shù)據(jù)庫(kù)，比如從4308調(diào)整正為4318,使得遷移過程中避免其他業(yè)務(wù)連接的影響，驗(yàn)證無誤后停庫(kù)

4)修改mysql_base路徑為5.7版本，修改/usr/bin/mysql等環(huán)境變量配置

5)替換配置文件為5.7版本，在5.7模式下啟動(dòng)數(shù)據(jù)庫(kù)

6)使用upgrade模式升級(jí)數(shù)據(jù)字典,命令如下：

mysql_upgrade --socket=/data/mysql_4306/tmp/mysql.sock --port=4308 -uroot  -pxxxx

7) 檢查復(fù)核

整個(gè)過程看上去還OK，實(shí)際操作的時(shí)候漏洞百出。

1)  mysqldump備份數(shù)據(jù)庫(kù)，備份文件大約為120G，為了快速在線備份采用mysqldump，但是異常情況下的恢復(fù)效率是硬傷，所以此處不建議使用mysqldump備份，而是建議使用物理備份，甚至如果條件允許，直接使用冷備模式

2) 停止MySQL 5.5數(shù)據(jù)庫(kù)

3) 修改數(shù)據(jù)庫(kù)端口重新啟動(dòng)數(shù)據(jù)庫(kù)，比如從4308調(diào)整正為4318,使得遷移過程中避免其他業(yè)務(wù)連接的影響，驗(yàn)證無誤后停庫(kù)

4)修改mysql_base路徑為5.7版本，修改/usr/bin/mysql等環(huán)境變量配置

5)替換配置文件為5.7版本，在5.7模式下啟動(dòng)數(shù)據(jù)庫(kù)，這里沒有注意ibdata的配置，運(yùn)氣不好，碰上了一個(gè)奇葩配置，如下：

innodb_data_file_path = ibdata1:1000M;ibdata2:100M:autoextend

而原本的規(guī)范配置都是一個(gè)ibdata文件，如下：

innodb_data_file_path = ibdata1:1G:autoextend，

導(dǎo)致數(shù)據(jù)庫(kù)啟動(dòng)時(shí)報(bào)錯(cuò)，提示ibdata文件已經(jīng)被損壞了。

6)使用upgrade模式升級(jí)數(shù)據(jù)字典,命令如下：

mysql_upgrade --socket=/data/mysql_4306/tmp/mysql.sock --port=4308 -uroot -pxxxx

upgrade這個(gè)命令的實(shí)現(xiàn)提示不夠友好，拋出了一大堆的錯(cuò)誤，但是最后竟然安慰我說，升級(jí)成功。問題到了這個(gè)階段的時(shí)候，其實(shí)已經(jīng)比較難收?qǐng)隽?，因?yàn)閿?shù)據(jù)字典文件損壞，導(dǎo)致升級(jí)數(shù)據(jù)字典的操作完全不可能，現(xiàn)在數(shù)據(jù)庫(kù)連里面的表都desc不出來了

7) 檢查復(fù)核，本來輕輕松松收工的驗(yàn)證工作現(xiàn)在變成了緊急修復(fù)工作。

后續(xù)的第一波補(bǔ)救措施如下：

8)使用已有的凌晨固定的物理備份恢復(fù)數(shù)據(jù)，大約為1個(gè)小時(shí)，mysqldump恢復(fù)果斷放棄，印象中至少得6個(gè)小時(shí)以上。

9)使用物理備份模式備份當(dāng)前數(shù)據(jù)庫(kù)

10)重新升級(jí)數(shù)據(jù)庫(kù)，尤其注意ibdata的配置，如果升級(jí)失敗則使用物理備份快速回退

11)升級(jí)過程再次受阻，這一次是sql_mode,系統(tǒng)數(shù)據(jù)字典升級(jí)成功，但是數(shù)據(jù)庫(kù)的表檢測(cè)中，主要因?yàn)閟ql_mode的數(shù)據(jù)格式校驗(yàn)，導(dǎo)致很多數(shù)據(jù)表的格式校驗(yàn)失敗，需要執(zhí)行類似  alter table test.xxxxx force這樣的重構(gòu)操作。

12)因?yàn)榛謴?fù)過程中未知原因，InnoDB的redo log也受到一些影響，日志開始拋錯(cuò)，所以當(dāng)前恢復(fù)的數(shù)據(jù)庫(kù)就算升級(jí)字典成功，本身也有一些硬傷。

后續(xù)的第二波補(bǔ)救措施如下：

13)使用mysqldump備份當(dāng)前數(shù)據(jù)庫(kù)，僅僅備份指定的數(shù)據(jù)庫(kù)，不使用all-databases選項(xiàng)，權(quán)限單獨(dú)導(dǎo)出。

14)部署MySQL 5.7的實(shí)例，不同的端口，如4390端口

15)sql_mode和5.5版本通配，修改其他參數(shù)等

16)導(dǎo)入mysqldump數(shù)據(jù)至4390的5.7實(shí)例

17)建立主從復(fù)制關(guān)系

18)切換數(shù)據(jù)庫(kù)端口，使5.7的新版本服務(wù)生效

到此，關(guān)于“MySQL數(shù)據(jù)庫(kù)升級(jí)的坑有哪些”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！