對(duì)于商業(yè)數(shù)據(jù)庫(kù)而言，數(shù)據(jù)庫(kù)升級(jí)是一個(gè)優(yōu)先級(jí)很高的事情，有版本升級(jí)路線圖，有相應(yīng)的補(bǔ)丁，而且對(duì)于方案還有一系列的演練，陷入是一場(chǎng)硬仗。而在MySQL方向上，升級(jí)這件事情就被淡化了許多，好像只能證明它的存在而已，當(dāng)然正是由于這種不重視，也讓我今天走了不少?gòu)澛贰?/p>

[[336613]]

一般來(lái)說(shuō)，升級(jí)MySQL有兩類(lèi)可行方案，一類(lèi)是直接升級(jí)數(shù)據(jù)字典，在本機(jī)完成，整個(gè)過(guò)程會(huì)有離線操作，會(huì)對(duì)業(yè)務(wù)有中斷，第二種是通過(guò)高可用切換平滑實(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,使得遷移過(guò)程中避免其他業(yè)務(wù)連接的影響，驗(yàn)證無(wú)誤后停庫(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è)過(guò)程看上去還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,使得遷移過(guò)程中避免其他業(yè)務(wù)連接的影響，驗(yàn)證無(wú)誤后停庫(kù)

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

5)替換配置文件為5.7版本，在5.7模式下啟動(dòng)數(shù)據(jù)庫(kù)，這里沒(méi)有注意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ò)誤，但是最后竟然安慰我說(shuō)，升級(jí)成功。問(wèn)題到了這個(gè)階段的時(shí)候，其實(shí)已經(jīng)比較難收?qǐng)隽?，因?yàn)閿?shù)據(jù)字典文件損壞，導(dǎo)致升級(jí)數(shù)據(jù)字典的操作完全不可能，現(xiàn)在數(shù)據(jù)庫(kù)連里面的表都desc不出來(lái)了

7) 檢查復(fù)核，本來(lái)輕輕松松收工的驗(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í)過(guò)程再次受阻，這一次是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í)行類(lèi)似 alter table test.xxxxx force這樣的重構(gòu)操作。

12)因?yàn)榛謴?fù)過(guò)程中未知原因，InnoDB的redo log也受到一些影響，日志開(kāi)始拋錯(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ù)生效

整個(gè)過(guò)程也是一波多折，見(jiàn)招拆招，發(fā)現(xiàn)想走捷徑，最后發(fā)現(xiàn)一個(gè)坑都沒(méi)有拉下，而這也給了我深刻的教訓(xùn)，千萬(wàn)不能掉以輕心，不能帶著試運(yùn)氣的態(tài)度處理問(wèn)題。