MySQL升級(jí)的那些事:外來(lái)的和尚會(huì)念經(jīng)
原創(chuàng)【51CTO獨(dú)家特稿】我最近把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ù)編寫了很多的應(yīng)用程序。它沒有提供一個(gè)通用的測(cè)試套件(我們可以使用這個(gè)測(cè)試套件來(lái)驗(yàn)證MySQL代碼)。就像你猜測(cè)的那樣,在這種情況下,那些原作者們還在繼續(xù)努力,并且,沒有人可以確切地知道哪個(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í)候,我們要確保“同步”是同步開始的,這樣可以避免誤報(bào)。“mk-table-checksum”是一個(gè)專用的工具。事實(shí)證明,同步觸發(fā)器確實(shí)存在一個(gè)問(wèn)題。這個(gè)問(wèn)題可以通過(guò)升級(jí)來(lái)修復(fù),所以,我們只需要把它放到賬戶里就可以了。(關(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è)未公開的同步問(wèn)題。有很多種方法可以解決這個(gè)問(wèn)題,但是,首先,我們決定要看一看它的影響到底有多大。我們讓從服務(wù)器通過(guò)“skip-slave-errors=1105”來(lái)同步,看看我們是否會(huì)遇到其他問(wèn)題,與此同時(shí),我們檢查了上個(gè)月的二進(jìn)制日志,想看一看這個(gè)功能的使用頻率。令人愉快的是幾乎沒有幾個(gè)“INSERT ON DUPLICATE KEY UPDATE”查詢實(shí)例,在這些查詢中,只有一個(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)告文件,并沒有發(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)在,我們可以確定,寫數(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ù)流。如果想讓每種查詢類型只檢查特定數(shù)目的樣本,可以使用“–sample=50”選項(xiàng)(或類似的選項(xiàng))——否則,會(huì)浪費(fèi)很多時(shí)間。使用“mk-upgrade”(關(guān)于“mk-upgrade”,具體可以參考:http://www.maatkit.org/doc/mk-upgrade.html)執(zhí)行那些查詢可以得到一些不同的結(jié)果,事實(shí)證明,這些結(jié)果也是誤報(bào)——這是由于“mk-upgrade”在默認(rèn)情況下使用“TABLE CHECKSUM”來(lái)檢查結(jié)果集。“–compare-results-method rows”可以幫助你移除它們,并且,我們可以只比較查詢時(shí)間方面的區(qū)別。在大多數(shù)情況下,查詢時(shí)間方面的區(qū)別并不是很明顯,或許Percona Server 5.1可以做的更好一些,但是,在兩個(gè)查詢中,優(yōu)化器會(huì)改變那個(gè)明顯落后的查詢,然后,它們會(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ì)中,如果沒有很多應(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
【編輯推薦】