對于商業數據庫而言，數據庫升級是一個優先級很高的事情，有版本升級路線圖，有相應的補丁，而且對于方案還有一系列的演練，陷入是一場硬仗。而在MySQL方向上，升級這件事情就被淡化了許多，好像只能證明它的存在而已，當然正是由于這種不重視，也讓我今天走了不少彎路。

一般來說，升級MySQL有兩類可行方案，一類是直接升級數據字典，在本機完成，整個過程會有離線操作，會對業務有中斷，第二種是通過高可用切換平滑實現，原理是搭建低版本到高版本的數據復制關系，這種方案優勢比較明顯，對于業務的侵入性比較低，而且還可以提前驗證，更甚還可以做到平滑回退，當然第二種方案要做很多前期的準備工作。

今天處理的一套環境基于存儲和時長等因素使用的是第一種方法，整個流程如下：

1） mysqldump備份數據庫，備份文件大約為120G

2） 停止MySQL 5.5數據庫

3） 修改數據庫端口重新啟動數據庫，比如從4308調整正為4318，使得遷移過程中避免其他業務連接的影響，驗證無誤后停庫

4）修改mysql_base路徑為5.7版本，修改/usr/bin/mysql等環境變量配置

5）替換配置文件為5.7版本，在5.7模式下啟動數據庫

6）使用upgrade模式升級數據字典，命令如下：

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

7） 檢查復核

整個過程看上去還OK，實際操作的時候漏洞百出。

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

2） 停止MySQL 5.5數據庫

3） 修改數據庫端口重新啟動數據庫，比如從4308調整正為4318，使得遷移過程中避免其他業務連接的影響，驗證無誤后停庫

4）修改mysql_base路徑為5.7版本，修改/usr/bin/mysql等環境變量配置

5）替換配置文件為5.7版本，在5.7模式下啟動數據庫，這里沒有注意ibdata的配置，運氣不好，碰上了一個奇葩配置，如下：

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

而原本的規范配置都是一個ibdata文件，如下：

innodb_data_file_path = ibdata1:1G:autoextend，

導致數據庫啟動時報錯，提示ibdata文件已經被損壞了。

6）使用upgrade模式升級數據字典，命令如下：

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

upgrade這個命令的實現提示不夠友好，拋出了一大堆的錯誤，但是最后竟然安慰我說，升級成功。問題到了這個階段的時候，其實已經比較難收場了，因為數據字典文件損壞，導致升級數據字典的操作完全不可能，現在數據庫連里面的表都desc不出來了

7） 檢查復核，本來輕輕松松收工的驗證工作現在變成了緊急修復工作。

后續的第一波補救措施如下：

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

9）使用物理備份模式備份當前數據庫

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

11）升級過程再次受阻，這一次是sql_mode，系統數據字典升級成功，但是數據庫的表檢測中，主要因為sql_mode的數據格式校驗，導致很多數據表的格式校驗失敗，需要執行類似 alter table test.xxxxx force這樣的重構操作。

12）因為恢復過程中未知原因，InnoDB的redo log也受到一些影響，日志開始拋錯，所以當前恢復的數據庫就算升級字典成功，本身也有一些硬傷。

后續的第二波補救措施如下：

13）使用mysqldump備份當前數據庫，僅僅備份指定的數據庫，不使用all-databases選項，權限單獨導出。

14）部署MySQL 5.7的實例，不同的端口，如4390端口

15）sql_mode和5.5版本通配，修改其他參數等

16）導入mysqldump數據至4390的5.7實例

17）建立主從復制關系

18）切換數據庫端口，使5.7的新版本服務生效

整個過程也是一波多折，見招拆招，發現想走捷徑，最后發現一個坑都沒有拉下，而這也給了我深刻的教訓，千萬不能掉以輕心，不能帶著試運氣的態度處理問題。