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

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

　　首先，我們必須對現(xiàn)有的“同步”設(shè)置做一個全面地檢查

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

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

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

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

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

　　現(xiàn)在，“同步”可以正常工作了，但是數(shù)據(jù)匹配嗎？

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

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

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

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

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

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

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

　　原文標(biāo)題：The story of one MySQL Upgrade

it知識庫：MySQL升級的那些事:外來的和尚會念經(jīng)，轉(zhuǎn)載需保留來源！

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