您好,登錄后才能下訂單哦!
這篇文章主要介紹了升級MySQL數(shù)據(jù)庫需要注意什么,具有一定借鑒價值,需要的朋友可以參考下。希望大家閱讀完這篇文章后大有收獲。下面讓小編帶著大家一起了解一下。
對于商業(yè)數(shù)據(jù)庫而言,數(shù)據(jù)庫升級是一個優(yōu)先級很高的事情,有版本升級路線圖,有相應的補丁,而且對于方案還有一系列的演練,顯然是一場硬仗。而在MySQL方向上,升級這件事情就被淡化了許多,好像只能證明它的存在而已,當然正是由于這種不重視,也讓我今天走了不少彎路。
一般來說,升級MySQL有兩類可行方案,一類是直接升級數(shù)據(jù)字典,在本機完成,整個過程會有離線操作,會對業(yè)務有中斷,第二種是通過高可用切換平滑實現(xiàn),原理是搭建低版本到高版本的數(shù)據(jù)復制關系,這種方案優(yōu)勢比較明顯,對于業(yè)務的侵入性最低,而且還可以提前驗證,更甚還可以做到平滑回退,當然第二種方案要做很多前期的準備工作。
今天處理的一套環(huán)境基于存儲和時長等因素使用的是第一種方法,整個流程如下:
1) mysqldump備份數(shù)據(jù)庫,備份文件大約為120G
2) 停止MySQL 5.5數(shù)據(jù)庫
3) 修改數(shù)據(jù)庫端口重新啟動數(shù)據(jù)庫,比如從4308調(diào)整正為4318,使得遷移過程中避免其他業(yè)務連接的影響,驗證無誤后停庫
4)修改mysql_base路徑為5.7版本,修改/usr/bin/mysql等環(huán)境變量配置
5)替換配置文件為5.7版本,在5.7模式下啟動數(shù)據(jù)庫
6)使用upgrade模式升級數(shù)據(jù)字典,命令如下:
mysql_upgrade --socket=/data/mysql_4306/tmp/mysql.sock --port=4308 -uroot -pxxxx
7) 檢查復核
整個過程看上去還OK,實際操作的時候漏洞百出。
1) mysqldump備份數(shù)據(jù)庫,備份文件大約為120G,為了快速在線備份采用mysqldump,但是異常情況下的恢復效率是硬傷,所以此處不建議使用mysqldump備份,而是建議使用物理備份,甚至如果條件允許,直接使用冷備模式
2) 停止MySQL 5.5數(shù)據(jù)庫
3) 修改數(shù)據(jù)庫端口重新啟動數(shù)據(jù)庫,比如從4308調(diào)整正為4318,使得遷移過程中避免其他業(yè)務連接的影響,驗證無誤后停庫
4)修改mysql_base路徑為5.7版本,修改/usr/bin/mysql等環(huán)境變量配置
5)替換配置文件為5.7版本,在5.7模式下啟動數(shù)據(jù)庫,這里沒有注意ibdata的配置,運氣不好,碰上了一個奇葩配置,如下:
innodb_data_file_path = ibdata1:1000M;ibdata2:100M:autoextend
而原本的規(guī)范配置都是一個ibdata文件,如下:
innodb_data_file_path = ibdata1:1G:autoextend,
導致數(shù)據(jù)庫啟動時報錯,提示ibdata文件已經(jīng)被損壞了。
6)使用upgrade模式升級數(shù)據(jù)字典,命令如下:
mysql_upgrade --socket=/data/mysql_4306/tmp/mysql.sock --port=4308 -uroot -pxxxx
upgrade這個命令的實現(xiàn)提示不夠友好,拋出了一大堆的錯誤,但是最后竟然安慰我說,升級成功。問題到了這個階段的時候,其實已經(jīng)比較難收場了,因為數(shù)據(jù)字典文件損壞,導致升級數(shù)據(jù)字典的操作完全不可能,現(xiàn)在數(shù)據(jù)庫連里面的表都desc不出來了
7) 檢查復核,本來輕輕松松收工的驗證工作現(xiàn)在變成了緊急修復工作。
后續(xù)的第一波補救措施如下:
8)使用已有的凌晨固定的物理備份恢復數(shù)據(jù),大約為1個小時,mysqldump恢復果斷放棄,印象中至少得6個小時以上。
9)使用物理備份模式備份當前數(shù)據(jù)庫
10)重新升級數(shù)據(jù)庫,尤其注意ibdata的配置,如果升級失敗則使用物理備份快速回退
11)升級過程再次受阻,這一次是sql_mode,系統(tǒng)數(shù)據(jù)字典升級成功,但是數(shù)據(jù)庫的表檢測中,主要因為sql_mode的數(shù)據(jù)格式校驗,導致很多數(shù)據(jù)表的格式校驗失敗,需要執(zhí)行類似 alter table test.xxxxx force這樣的重構操作。
12)因為恢復過程中未知原因,InnoDB的redo log也受到一些影響,日志開始拋錯,所以當前恢復的數(shù)據(jù)庫就算升級字典成功,本身也有一些硬傷。
后續(xù)的第二波補救措施如下:
13)使用mysqldump備份當前數(shù)據(jù)庫,僅僅備份指定的數(shù)據(jù)庫,不使用all-databases選項,權限單獨導出。
14)部署MySQL 5.7的實例,不同的端口,如4390端口
15)sql_mode和5.5版本通配,修改其他參數(shù)等
16)導入mysqldump數(shù)據(jù)至4390的5.7實例
17)建立主從復制關系
18)切換數(shù)據(jù)庫端口,使5.7的新版本服務生效
整個過程也是一波多折,見招拆招,發(fā)現(xiàn)想走捷徑,最后發(fā)現(xiàn)一個坑都沒有拉下,而這也給了我深刻的教訓,千萬不能掉以輕心,不能帶著試運氣的態(tài)度處理問題。
感謝你能夠認真閱讀完這篇文章,希望小編分享升級MySQL數(shù)據(jù)庫需要注意什么內(nèi)容對大家有幫助,同時也希望大家多多支持億速云,關注億速云行業(yè)資訊頻道,遇到問題就找億速云,詳細的解決方法等著你來學習!
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權內(nèi)容。