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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　在我看來(lái)，在MySQL升級(jí)過(guò)程中，聘請(qǐng)一個(gè)外部的顧問(wèn)十分有必要。

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

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

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

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