我最近把MySQL從一個早期的版本（MySQL 5.0）升級到了Percona Server 5.1。這是一個經典的升級場景，在升級過程中，可能會發生一些意外。主服務器和幾個從服務器都需要升級。MySQL是一個共享的數據庫，在這5年多的時間里，人們使用這個共享的數據編寫了很多的應用程序。

　　它沒有提供一個通用的測試套件（我們可以使用這個測試套件來驗證MySQL代碼）。就像你猜測的那樣，在這種情況下，那些原作者們還在繼續努力，并且，沒有人可以確切地知道哪個應用程序應該使用這個數據庫，哪個應用程序不應該使用這個數據庫。在正規的公司中，數據庫對生產起著決定性的作用，所以我們不應該草率地進行升級。

　　首先，我們必須對現有的“同步”設置做一個全面地檢查

　　當我們檢查“同步”的一致性的時候，我們要確保“同步”是同步開始的，這樣可以避免誤報。“mk-table-checksum”是一個專用的工具。事實證明，同步觸發器確實存在一個問題。這個問題可以通過升級來修復，所以，我們只需要把它放到賬戶里就可以了。（關于“mk-table-checksum”，具體可以參考：http://www.maatkit.org/doc/mk-table-checksum.html

　　然后，我們把數據庫遷移到MySQL 5.1。因為這個數據庫的體積比較小，所以，我們使用“mysqldump”命令來載入數據是最安全的方法，想想我們提到的這4年版本更新的價值。我們也可以運行“mysql_fix_privilege_tables”，這樣可以確保新的“privilege”會被添加，我經常看到這件事情被徹底遺忘掉了。

　　下一個步驟是配置MySQL 5.0 到 5.1的“同步”，看看它是否可以正常工作

　　事實證明它無法正常工作，這是過去的一個bug（關于這個bug的具體信息，可以參考：http://bugs.mysql.com/bug.php?id=24432），在很多其他的環境中，我也看到過這個Bug會引起一些和升級有關的問題。在MySQL 5.0中，“INSERT ON DUPLICATE KEY UPDATE”存在一個未公開的同步問題。有很多種方法可以解決這個問題，但是，首先，我們決定要看一看它的影響到底有多大。

　　我們讓從服務器通過“skip-slave-errors=1105”來同步，看看我們是否會遇到其他問題，與此同時，我們檢查了上個月的二進制日志，想看一看這個功能的使用頻率。令人愉快的是幾乎沒有幾個“INSERT ON DUPLICATE KEY UPDATE”查詢實例，在這些查詢中，只有一個涉及到了帶有“AUTO_INCREMENT”列的表（會被這個bug影響）。修改那個應用程序，讓它在那個實例中不使用“INSERT ON DUPLICATE KEY UPDATE”，是很容易做到的。所以，我們修改了那個應用程序。

　　現在，“同步”可以正常工作了，但是數據匹配嗎？

　　（如果存在載入不當的數據，使用mysqldump命令會覆蓋掉那些載入不當的數據。）我們讓5.0和5.1的從服務器停在了同一位置，然后使用“mk-table-checksum”來確保數據是同步的。“mk-table-checksum”可以使用“同步”來檢查一致性，但是直接比較兩個服務器會更快一些，正好我們有備用的容量，我們可以使用這些容量。首先，我們使用默認的“CHECKSUM TABLE”算法來進行檢查。當運行“SELECT INTO OUTFILE”的時候，我們發現有很多表報告校驗錯誤，然后我們diff那些報告文件，并沒有發現有什么不同。

　　事實證明，這幾年，“CHECKSUM TABLE”發生了一些微妙的變化，在某些情況下，它可以報告不同的校驗值。使用“BIT_XOR”算法重新進行檢查，可以排除那些誤報。對于剩下的另外一張表，我們可以使用“mk-table-sync –print”（關于mk-table-sync ，具體可以參考：http://www.maatkit.org/doc/mk-table-sync.html），作為一個MySQL的diff工具，它可以看出表之間有什么區別。事實證明，當數據載入到Percona Server 5.1中的時候，在MySQL 5.0中存儲“-0″的float列會顯示成“0″。對于應用程序來說，這并不是一個問題，實際上，完全可以忽略掉這個問題。

　　現在，我們可以確定，寫數據流可以正確地同步到新版本中。是檢查讀數據流行為的時候了。我們把所有從服務器都停在了同一個位置上，然后使用“tcpdump” 和 “mk-query-digest”（關于“mk-query-digest”，具體可以參考：http://www.maatkit.org/doc/mk-query-digest.html）從主服務器和從服務器獲取樣例性的讀數據流。如果想讓每種查詢類型只檢查特定數目的樣本，可以使用“–sample=50”選項（或類似的選項）——否則，會浪費很多時間。

　　使用“mk-upgrade”（關于“mk-upgrade”，具體可以參考：http://www.maatkit.org/doc/mk-upgrade.html）執行那些查詢可以得到一些不同的結果，事實證明，這些結果也是誤報——這是由于“mk-upgrade”在默認情況下使用“TABLE CHECKSUM”來檢查結果集。“–compare-results-method rows”可以幫助你移除它們，并且，我們可以只比較查詢時間方面的區別。在大多數情況下，查詢時間方面的區別并不是很明顯，或許Percona Server 5.1可以做的更好一些，但是，在兩個查詢中，優化器會改變那個明顯落后的查詢，然后，它們會被標記為“被修復”。

　　現在，我們有足夠的信心可以確定，從服務器完全可以處理這個流量，我們可以把它們放在生產環境中了。但是，在升級主服務器以前，我們必須要考慮一下回滾計劃，因為如果在升級過程中遇到一些問題，我們需要把主服務器回滾到MySQL 5.0。為了完成這個任務，我們從Percona Server 5.1回到MySQL 5.0重新配置“同步”，然后再次執行上面提到的那些檢查——很高興“同步”可以正常發揮作用，不存在“偏差”。這可以讓我們簡單地掛載到MySQL 5.0上，所有從服務器都會脫離這個新的主服務器，并且，這種情況會持續一段時間，同時，回滾到過去的設置也很簡單。對于涉及到新的操作系統和硬件（它們都可能造成回滾）的MySQL版本升級來說，這是最好的選擇。

　　在我看來，在MySQL升級過程中，聘請一個外部的顧問十分有必要。

　　即使在一個團隊中有一個優秀的MySQL DBA（Data Base Administrator），一般來說，主版本的升級頻率也不應該超過3到5年一次，在這樣一個團隊中，如果沒有很多應用程序需要升級，也是很難記錄下這些經驗的。在升級的時候，你遇到的問題可能是截然不同的，這主要取決于升級的版本——從MySQL 4.1升級到MySQL 5.0和從MySQL 5.0升級到MySQL 5.1遇到的問題是不同的。

　　原文標題：The story of one MySQL Upgrade

it知識庫：MySQL升級的那些事:外來的和尚會念經，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。