MySQL升級的那些事:外來的和尚會念經

BKJIA獨家特稿】我最近把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 DBAData Base Administrator），一般來說，主要版本的升級頻率也不應該超過3到5年一次，在這樣一個團隊中，如果沒有很多應用程式需要升級，也是很難記錄下這些經驗的。在升級的時候，你遇到的問題可能是截然不同的，這主要取決於升級的版本——從MySQL 4.1升級到MySQL 5.0和從MySQL 5.0升級到MySQL 5.1遇到的問題是不同的。

原文標題：The story of one MySQL Upgrade