一、前言

升級需求：將5.7.35升級到8.0.27, 升級方式 in-place升級【關閉現有版本MySQL，將二進制或包替換成新版本并在現有數據目錄上啟動MySQL并執(zhí)行升級任務的方式，稱為in-place升級】

原版本 5.7.35 CentOS Linux release 7.9.2009

新版本 8.0.27 CentOS Linux release 7.9.2009

二、Mysql 生命周期

以下Mysql 生命周期-內容來自于互聯網

關于數據庫版本升級，一直都是熱議話題，對于升級的緣由各家也有所不同，有業(yè)務驅動的，有DBA自發(fā)驅動的，有規(guī)劃導向也有方向指引的……拋開各種原因，當升級這個決定落下來的時候，對于DBA手頭的幾百幾千套數據庫來說，就好比是一場動物大遷徙，滿滿的畫面感。

從Oracle發(fā)布的版本生命周期規(guī)劃可以看到，Mysql5.7已經走到了生命周期的終點，意味著后續(xù)將不再為Mysql5.7提供官方更新、錯誤修復或安全補丁。

阿里云和AWS都在官方公布了版本支持計劃,Mysql5.7版本已經開始了倒計時。

三、MySQL8.0的新特性

默認字符集由latin1變?yōu)閡tf8mb4。

MyISAM系統表全部換成InnoDB表。

JSON特性增強。

支持不可見索引，支持直方圖。

sql_mode參數默認值變化。

默認密碼策略變更。

新增角色管理。

支持窗口函數，支持Hash join。

四、升級建議

支持從MySQL5.7升級到MySQL8.0，注意僅支持GA版本之間的升級。

不支持跨大版本的升級，如從5.6升級到8.0是不支持的。

建議升級大版本前先升級到當前版本的最近小版本，如5.7先升級到5.7.35后再升級到8.0。

做好充足的備份！數據無價?。?

五、升級前準備

5.1 Mysql-shell 檢查工具兼容性

在執(zhí)行升級操作前需要做一些檢查工作，確認準備工作是否就緒，避免升級過程中出現異常?？梢允褂肕ySQL Shell使用util.checkForServerUpgrade進行檢查，返回內容包括不符合遷移要求的問題，error的問題需要遷移前修改。

Mysql-shell 下載地址：https://dev.mysql.com/downloads/shell/

這里我們選擇8027版本

然后上傳文件至5.7.35的機器/root目錄下

[root@localhost ~]# tar -xf mysql-shell-8.0.27-linux-glibc2.12-x86-64bit.tar.gz
[root@localhost ~]# cd mysql-shell-8.0.27-linux-glibc2.12-x86-64bit/bin/
[root@localhost bin]# ./mysqlsh -uroot -p -S /tmp/mysql.sock -e "util.checkForServerUpgrade()" > util.checkForServerUpgrade.log

從輸出報告可以看出，升級檢查器在23個方面進行了檢查，最終得出4個警告信息和1個提示。

消除警告：

Usage of utf8mb3 charset 在MySQL 8.0版本之前，默認字符集為latin1 ，utf8字符集指向的是utf8mb3 。從MySQL8.0開始，數據庫的默認編碼將改為utf8mb4 ；為了避免新舊對象字符集不一致的情況，可以在配置文件將字符集和校驗規(guī)則設置為舊版本的字符集和比較規(guī)則。

New default authentication plugin considerations，密碼認證插件變更。為了避免連接問題，可以仍采用5.7的mysql_native_password認證插件。

消除提示：

Usage of obsolete sql_mode flags：Mysq8.0 版本sql_mode不支持NO_AUTO_CREATE_USER，要避免配置的sql_mode中帶有NO_AUTO_CREATE_USER。

通過以上的例子，可以發(fā)現，MySQL Shell提供的升級檢查工具能夠幫助我們檢測版本兼容性，減輕升級工作負擔。

5.2 邏輯備份Mysql數據

[root@localhost opt]#which mysqldump
[root@localhost opt]#/usr/local/mysql/bin/mysqldump
# --routines 備份存儲過程和函數；--set-gtid-purged=OFF: 禁用GTID（全局事務標識）;xxx1,XXX2 表示庫名，備份多個庫 用空格做為間隔
[root@localhost opt]#/usr/local/mysql/bin/mysqldump -uroot -p --routines --set-gtid-purged=OFF -A > /root/all-database-20231115.sql

5.3 優(yōu)雅的停止數據庫

select version();
show variables like 'innodb_fast_shutdown';

# 確保數據都刷到硬盤上，更改成0InnoDB關閉模式。如果值為0，InnoDB會在關閉前進行緩慢關閉、完全清除和更改緩沖區(qū)合并。如果值為1（默認值），InnoDB會在關閉時跳過這些操作，這個過程稱為快速關閉。如果值為2，InnoDB刷新其日志并冷關機，就好像MySQL崩潰了；沒有提交的事務丟失，但崩潰恢復操作使下一次啟動需要更長的時間。在仍然緩沖大量數據的極端情況下，緩慢關閉可能需要幾分鐘甚至幾小時。

set global innodb_fast_shutdown=0;
shut down;
exit
[root@localhost opt]# ps -ef|grep mysql

5.4 備份Mysql 數據目錄,安裝目錄 和配置文件

--確認數據庫狀態(tài)為關閉狀態(tài)
[root@localhost opt]# service mysql status
--數據目錄備份
[root@localhost opt]# cp -r /data/mysql /data/mysql_bak_`date +%F`
--安裝目錄備份
[root@localhost opt]# cp -r /usr/local/mysql/ /usr/local/mysql_bak_`date +%F`
--配置文件備份
[root@localhost local]# cp /etc/my.cnf /etc/my.cnf_`date +%F`

5.5 下載并解壓MySQL8

安裝包上傳至原安裝包目錄下 我的是/usr/local/mysql

[root@localhost local]# tar -xf mysql-8.0.27-linux-glibc2.12-x86_64.tar.xz
# 文件夾重命名為mysql8
[root@localhost local]# mv mysql-8.0.27-linux-glibc2.12-x86_64 mysql8
# 更改文件夾所屬
[root@localhost local]# chown -Rf mysql:mysql /usr/local/mysql8
# 刪除安裝包
[root@localhost local]# rm -rf mysql-8.0.27-linux-glibc2.12-x86_64.tar.xz

六、升級

6.1 修改my.cnf 配置文件

因5.7版本與8.0版本參數有所不同，為了能順利升級，我們需要更改部分配置參數。主要注意sql_mode、basedir、密碼認證插件及字符集設置，其他參數最好還是按照原5.7的來，不需要做調整。下面展示5.7和8.0的配置文件,注意備份原來配置文件。

6.1.1 Mysql5.7_my.cnf 配置文件

相比5.7，8多了以下配置

sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
basedir=/home/application/mysql/mysql8
datadir=/home/application/mysql/data
character_set_server=utf8
collation-server=utf8_general_ci
# 默認使用"mysql_native_password"插件認證
default_authentication_plugin=mysql_native_password
# 創(chuàng)建新表時將使用的默認存儲引擎
default-storage-engine=INNODB

6.2 執(zhí)行升級程序

在mysql5.7升級的時候，MySQL啟動后還需執(zhí)行mysql_upgrade后重啟MySQL。MySQL8.0.16開始，MySQL 不推薦使用mysql_upgrade；直接使用 mysqld_safe 直接啟動。關于--upgrade=的一些參數。

--upgrade=AUTO MySQL升級所有過時的內容

• --upgrade=NONE MySQL跳過升級步驟，可能會導致報錯
• --upgrade=MINIMAL MySQL在必要時升級數據字典表，information_schema和information_schema。這可能會導致部分功能不能正常使用，例如MGR
• --upgrade=FORCE MySQL會升級所有的內容，這會檢查所有schema的所有對象，導致MySQL需要更長的時間啟動。此模式下MySQL會重新創(chuàng)建系統表if they are missing。

[root@localhost local]# /usr/local/mysql8/bin/mysqld_safe --defaults-file=/etc/my.cnf --user=mysql --upgrade=FORCE

新開一個窗口，可觀察下錯誤日志看是否報錯

tailf /data/mysql/mysql-error.log 然后登錄數據庫測試

重新登錄
[root@localhost bin]# mysql -uroot -proot
mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.27    |
+-----------+
1 row in set (0.00 sec)

6.3 修改Mysql環(huán)境變量

由于basedir 從/usr/local/mysql 變成了 /usr/local/mysql8，需要修改下環(huán)境變量信息：

[root@localhost bin]# vi /etc/profile
export PATH=$PATH:/usr/local/mysql8/bin:/usr/local/mysql8/lib
[root@localhost bin]# source /etc/profile
[root@localhost ~]# which mysql
/usr/local/mysql8/bin/mysql
[root@localhost ~]# mysql -V
mysql  Ver 8.0.27 for Linux on x86_64 (MySQL Community Server - GPL)

6.4驗證恢復過來的數據是否正常

七、問題及經驗總結

7.1 問題一

在升級Mysql8.0后，關于JDBC中SSL連接的一些報錯信息，如下圖：

經排查發(fā)現，Mysql8.0 數據庫默認開啟了SSL認證，且之前Mysql5.7.39 也是默認開啟了SSL認證，代碼和JDBC驅動版本都沒有變化，那很有可能就是Mysql8.0 中對于SSL的一個變化，咨詢了DBA 朋友，專業(yè)的解釋是，在5.7.31的時候SSL在源碼中貌似沒有真正的起作用，后面版本完善了這塊的內容。倘若，不使用SSL去連接，就 需要按照如下的方法去處理：

方法一：從數據庫成面，直接在my.cnf 中 添加skip_ssl 參數，從源頭上關閉SSL 認證的方式

方法二：從代碼層面，在JDBC 連接中，使用 &useSSL=false 參數，表示不使用SSL 認證

7.2 問題二

Mysql 報錯unblock with ‘mysqladmin flush-hosts’，報錯如下：

JDBC連接報錯，報錯內容 ERROR 1129 (HY000): Host ‘192.168.59.202’ is blocked because of many connection errors; unblock with ‘mysqladmin flush-hosts’

原因：同一個ip在短時間內產生太多，中斷的數據庫連接而導致的阻塞；而中斷的因為有些業(yè)務使用SSL去連接數據庫，導致登錄失敗，登錄被鎖；

臨時解決方法，使用mysqladmin flush-hosts 命令清理一下hosts文件，mysqladmin -u xxx -p flush-hosts,根本上去解決，就需要排查什么異常的連接導致阻塞，登錄被鎖，比如上面提到的SSL認證的問題。

7.1 問題三

MySQL--使用innodb_force_recovery修復數據庫異常

當MySQL服務異常重啟失敗后，可以通過配置參數innodb_force_recovery來對MySQL服務進行修復啟動。

參數innodb_force_recovery選項：

1 (SRV_FORCE_IGNORE_CORRUPT): 忽略檢查到的 corrupt 頁。盡管檢測到了損壞的 page 仍強制服務運行。一般設置為該值即可，然后 dump 出庫表進行重建。

2 (SRV_FORCE_NO_BACKGROUND): 阻止主線程的運行，如主線程需要執(zhí)行 full purge 操作，會導致 crash。阻止 master thread 和任何 purge thread 運行。若 crash 發(fā)生在 purge 環(huán)節(jié)則使用該值。

3 (SRV_FORCE_NO_TRX_UNDO): 不執(zhí)行事務回滾操作。

4 (SRV_FORCE_NO_IBUF_MERGE): 不執(zhí)行插入緩沖的合并操作。如果可能導致崩潰則不要做這些操作。不要進行統計操作。該值可能永久損壞數據文件。若使用了該值，則將來要刪除和重建輔助索引。

5 (SRV_FORCE_NO_UNDO_LOG_SCAN): 不查看重做日志，InnoDB 存儲引擎會將未提交的事務視為已提交。此時 InnoDB 甚至把未完成的事務按照提交處理。該值可能永久性的損壞數據文件。

6 (SRV_FORCE_NO_LOG_REDO): 不執(zhí)行前滾的操作?；謴蜁r不做 redo log roll-forward。使數據庫頁處于廢止狀態(tài)，繼而可能引起 B 樹或者其他數據庫結構更多的損壞。

參數innodb_force_recovery設置：

在配置文件中的mysqld模塊添加參數innodb_force_recovery。

[mysqld]
innodb_force_recovery    =    N

相同參數innodb_force_recovery在不同MySQL版本允許的操作可能不同，所有版本中innodb_force_recovery>0時都允許對表進行SELECT操作。

使用參數innodb_force_recovery建議：

1、如果MySQL服務故障重啟后，因為事務回滾導致異常，可以將參數innodb_force_recovery設置為3跳過回滾階段

2、如果因為MySQL數據頁損壞導致異常，可以使用SELECT+WHERE查找出未損壞數據并將其通過mysqldump導出。

3、將innodb_force_recovery參數設置大于0啟動服務后，應通過修改端口或域名(VIP)指向來屏蔽應用訪問。

4、將innodb_force_recovery參數設置大于0啟動服務后，可以通過mysqlcheck命令來對表進行檢查/分析/優(yōu)化/修復。

5、使用force_recovery重啟服務前，建議對數據庫所有文件進行備份，避免修復過程中對數據進行二次損害。

在日常運維中，應將使用innodb_force_recovery參數進行數據恢復作為最后手段，做好完善的備份恢復機制，避免對數據庫做高危操作。

總結

到此這篇關于從MySQL5.7平滑升級到MySQL8.0數據庫的文章就介紹到這了,更多相關MySQL5.7平滑升級到MySQL8.0內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論