下午的時候接到業(yè)務部門的一個需求，他們有一個業(yè)務對性能要求比較高，在測試環(huán)境已經(jīng)做了一些測試和優(yōu)化，想看看在MySQL新版本中是否有一定的提升，現(xiàn)在使用的數(shù)據(jù)庫版本是MySQL 5.5.19，想問問我能不能做下升級。
確實，很少有業(yè)務部門對數(shù)據(jù)庫版本有一定的要求，對我來說有點兒驚喜。本來要推到下周的事情，我就速戰(zhàn)速決吧。
升級數(shù)據(jù)庫版本，在商業(yè)數(shù)據(jù)庫中是一個大活，有一定的復雜性，記得在Oracle中是有一個特有的版本升級路線圖的，現(xiàn)在都19c了，相比路線圖更是復雜了不少。
回到這個需求，在MySQL中，常用的思路無非是兩種，一種是遷移式升級，一種是字典升級。鑒于這是一個測試環(huán)境，上面的數(shù)據(jù)庫很多，數(shù)據(jù)量也不大，采用遷移式升級是比較推薦的，因為業(yè)務方對時間的要求比較寬松，1個小時以內(nèi)交付就行，所以我想試試字典升級的方式。
整個遷移的過程可以歸納為下面的幾個步驟：
1.多版本軟件部署
2.停庫備份
3.切換版本，啟動數(shù)據(jù)庫
4.升級數(shù)據(jù)字典
5.重啟數(shù)據(jù)庫
我們來逐個說一下。
源環(huán)境是MySQL 5.5.19,升級到Percona 5.7.16版本
- 多版本軟件部署
- 需要在同一臺服務器上部署多版本軟件，在這里就是5.7的軟件，這里使用二進制的部署方式，目錄暫定為/usr/local/mysql_5.7
- 停庫備份
- 這應該是最關鍵的一個步驟了，可以考慮多個層面的備份，比如目前的數(shù)據(jù)量不大，可以直接做目錄的復制，同時為了保險起見，再做一個邏輯備份,記得備份/etc/my.cnf
- 切換版本，啟動數(shù)據(jù)庫
- 這個是風險高發(fā)階段，很可能數(shù)據(jù)庫啟動出現(xiàn)問題。
- 常見的問題是參數(shù)不兼容,比如下面的參數(shù)是5.7版本中不識別的。
- thread_concurrency = 8
- innodb_additional_mem_pool_size = 32M
- innodb_thread_concurrency = 0
- 還有MySQL的啟動方式，是用mysqld_safe --defaults-file總是提示如下的錯誤。
mysqld_safe Adding '/usr/local/Percona-Server-5.7.16-10-linux.x86_64.ssl101/lib/mysql/libjemalloc.so.1' to LD_PRELOAD for mysqld
mysqld_safe ld_preload libraries can only be loaded from system directories (/usr/lib64, /usr/lib, /usr/local/mysql/lib)
[1]+ Exit 1 mysqld_safe --defaults-file=/data/mysql_4306/my.cnf
而使用service的方式啟動就沒有問題了，可以看到方式還是有較大的差異，在/etc/init.d下面的mysql文件里有這些變量的差異性補充，還有Percona和MySQL社區(qū)版的文件路徑差異
root 21395 1 0 15:25 pts/2 00:00:00 /bin/sh /usr/local/Percona-Server-5.7.16-10-Linux.x86_64.ssl101/bin/mysqld_safe --datadir=/data/mysql_4306/data --pid-file=/data/mysql_4306/tmp/mysql.pid
4.升級數(shù)據(jù)字典
數(shù)據(jù)庫啟動之后，算是處于一個臨界狀態(tài)，用的MySQL 5.7的軟件，但是數(shù)據(jù)字典還是5.5版本的。可以使用自帶的mysql_upgrade來進行升級。
mysql_upgrade --socket=/data/mysql_4306/tmp/mysql.sock --port=4306 -uroot -pxxxx
MySQL的字典升級難得之處就是對于字典的兼容性很好，沒有了版本間的復雜依賴，處理起來真是很清爽。
會輸出一些簡單日志，類似下面的形式：
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.host 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.
。。。
liteApp.banner OK
litework.attributes
error : Partitioning upgrade required. Please dump/reload to fix it or do: ALTER TABLE `litework`.`attributes` UPGRADE PARTITIONING
litework.id_sequence OK
。。。
Repairing tables
Upgrading tables
`test`.`monitor_db`
Running : ALTER TABLE `test`.`monitor_db` FORCE
status : OK
Running : ALTER TABLE `litework`.`attributes` UPGRADE PARTITIONING
status : OK
。。。
Upgrade process completed successfully.
整個過程不超過2分鐘即可搞定。
5.重啟數(shù)據(jù)庫
升級之后需要做下基本的檢查，比如查看數(shù)據(jù)庫日志，查看sys庫是否正常等。
當然在生產(chǎn)環(huán)境中的檢查和預案就要豐富一些了，總之一句話，升級是一件風險極高的任務，一定要做好完整的備份，升級不成如何降級，你有了余地才有了進步的機會。
