MySQL（stock、Percona 等）應該多久升級一次？

April 22, 2021

我的組織在 RHEL 上執行多個由各種 MySQL 風格支持的數據驅動的 Web 應用程序（即，我們就像其他人一樣！）我們的一些 Web 應用程序使用 MySQL 的標準建構，我們yum update會定期使用來更新所有 yum 管理的這些系統上的軟體。其他主機上的其他 webapps 使用我們手動安裝的 Percona 建構。我們yum update也定期在這些系統上使用，但由於我們在這些建構上安裝的 Percona 不是由 yum 管理的，因此它不會通過該過程進行升級。
是否有關於何時升級像 MySQL 之類的組件的經驗法則（例如每月、每季度或每個版本之後）？我們希望在保持最新狀態和在管理上花費過多時間之間找到適當的平衡。影響決定的因素有哪些？在安全方面，我們使用硬體防火牆和 iptables 來限制訪問，因此 MySQL/Percona 不會暴露在最外層的攻擊面。有問題的系統是專用的單租戶主機（即主機上沒有其他使用者）。

就個人而言，當我聽說由於人為錯誤導致升級出錯時，我會感到畏縮。大多數在連續升級 MySQL 時都有成功案例（5.0、5.1、5.5、5.6）有些人通過移動datadir、解除安裝舊 MySQL、安裝新 MySQL、放回 MySQLdatadir並認為一切正常……不！
MySQL 升級
MySQL 創建了mysql_upgrade用於對可能與目前安裝的 MySQL 二進製文件不同的所有內容進行清單檢查。當您負責任地使用時，這就是全面的解決方案。它是唯一適用於非常大的數據庫安裝的。您必須遵守某些規則。儘管非常罕見，即使正確執行 mysql_upgrade，仍然會發生奇怪的事情：請參閱從 MySQL 5.5 到 5.6.11 的就地升級會從使用者表中刪除所有使用者以及我對它的回答。
選擇
對於較小的數據庫安裝，我有一個更簡單的方法：mysqldump（但有一些警告）。MySQL 實例中最容易被忽視的數據庫始終是mysql模式。人們使用mysqldump --all-databases並嘗試將 mysqldump 從舊版本載入到新版本中，認為這就是全部。不是這樣。原因如下：
在 MySQL 的每個主要版本中，表mysql.user都有不同數量的列。
MySQL 5.6 有 43 列
MySQL 5.5 有 42 列
MySQL 5.1 有 39 列
MySQL 5.0 有 37 列
MySQL 4.x 有 31 列
請參閱我文章中的實際列：無法以 root 身份授予權限
請參閱我在 ServerFault 上的最新文章：MySQL upgrade from 5.0 to 5.5
腳本mysql_upgrade嘗試修復這些列以及其他要調整的兼容性問題。我的方法完全消除了對兼容性問題的擔憂。
我的方法
步驟 01：mysqldump 所有數據庫，除了 mysql 模式到文本文件（/root/MySQLData.sql）
MYSQL_CONN="-uroot -ppassword"
SQLSTMT="SELECT GROUP_CONCAT(schema_name SEPARATOR ' ')"
SQLSTMT="${SQLSTMT} FROM information_schema.schemata WHERE schema_name"
SQLSTMT="${SQLSTMT} NOT IN ('information_schema','mysql')"
DBLIST=`mysql ${MYSQL_CONN} -ANe"${SQLSTMT}"`
MYSQLDUMP_OPTIONS="--single-transaction --routines --triggers --databases ${DBLIST}"
mysqldump ${MYSQL_CONN} ${MYSQLDUMP_OPTIONS} &gt; /root/MySQLData.sql
步驟 02：將 MySQL 授權轉儲為 SQL 文件
有兩種技術可以做到這一點
技巧 #1：使用mk-show-grants
這會將所有 MySQL Grants 轉儲為 SQL 語句，完全可移植到任何版本的 MySQL/Percona 5.x
技巧#2：模仿mk-show-grants
cd
MYSQL_CONN="-uroot -ppassword"
SQLSTMT="SELECT CONCAT('SHOW GRANTS FOR ',"
SQLSTMT="${SQLSTMT} QUOTE(user),'@',QUOTE(host),';') "
SQLSTMT="${SQLSTMT} FROM mysql.user WHERE user&lt;&gt;''"
mysql ${MYSQL_CONN} -ANe"${SQLSTMT}" &gt; GetGrants.sql
echo "SET sql_log_bin = 0;" &gt; MySQLUserGrants.sql
mysql ${MYSQL_CONN} -AN &lt; GetGrants.sql | sed 's/$/;/g' &gt;&gt; MySQLUserGrants.sql
rm -f GetGrants.sql
我以前推薦過這些技術
Jul 26, 2011:將舊備份恢復到最新的 MySQL 版本
Mar 24, 2013: MySQL 導出使用者用分號“;” 最後
步驟 03：關閉 mysql
service mysql stop
STEP 04 : 把舊的 datadir 和 my.cnf 移開
mv /var/lib/mysql /var/lib/mysql_old
mv /etc/my.cnf /etc/my.cnf_old
STEP 05 : 解除安裝舊的 MySQL/Percona 伺服器
STEP 06 : 安裝新的 MySQL/Percona 伺服器
步驟 07：登錄 MySQL
STEP 08 : 執行兩個腳本
mysql&gt; source /root/MySQLData.sql
mysql&gt; source /root/MySQLUserGrants.sql
而已！！！
別擔心，我以前做過：MySQL upgrade 5.0.88 to latest
我相信我的替代方法，因為 mysqldump 是數據的邏輯表示，除了儲存引擎細節之外，它可以從一個安裝移動到另一個安裝。如果是這種情況，我會在一個文件中 mysqldump 沒有架構的數據，而只在另一個文件中 mysqldump 架構。然後，我將編輯僅模式文件中的細節。
我將把軟體安裝的血腥細節留給你有能力的人……
試一試！！！
結語
有很多古語
如果它沒有壞，就不要修理它。
命運眷顧大膽的人（來自星際迷航 DS9 的一集）
根據這些說法，使用常識。如果您對 MySQL 迄今為止的性能感到滿意，升級將只是不必要的停機時間。堅持你所擁有的。不要只是升級，因為你可以。我親眼目睹了 MySQL 5.5 的升級，它比原來的 MySQL 5.1 數據庫要慢。這是我過去對這種現象的回答：
Nov 24, 2011:為什麼 mysql 5.5 比 5.1 慢 (linux,using mysqlslap)
Oct 05, 2011:查詢在一些較新的 MySQL 版本中執行時間較長
Jun 19, 2011:如何正確執行 MySQL 烘烤？
如果你想要 MySQL 的新特性，比如
InnoDB 多核參與（MySQL 5.1 的 InnoDB 外掛，MySQL 5.5/5.6）
半同步複製 (MySQL 5.5)
並行從屬執行緒 (MySQL 5.6)
你將不得不大膽地去以前沒有人去過的地方。
在進行升級之前，了解您想要在數據庫中使用的技術。

引用自：https://dba.stackexchange.com/questions/43019

MySQL（stock、Percona 等）應該多久升級一次？

MySQL 升級

選擇

我的方法

結語

相關問答

mysql_upgrade 檢查是否需要執行它

MySQL percona 5.6 到 MySQL 5.5 複製

MySQL 升級到 5.6 後 tmp 磁碟表過多

MySQL/InnoDB 統計表是否會在主要版本升級中保持不變？

InnoDB INSERT 性能的能力

Windows 上的 MySQL 升級