9月11日參加了infoq和百度共同舉辦的技術(shù)沙龍《MySQL性能優(yōu)化及空間數(shù)據(jù)庫(kù)開發(fā)實(shí)踐》，百度的劉斌分享的內(nèi)容相信對(duì)目前正欲使用ssd來提升MySQL性能的朋友非常有幫助，同時(shí)，個(gè)人覺得ssd在其他數(shù)據(jù)存儲(chǔ)上也有很大的空間。顏勛講的空間數(shù)據(jù)庫(kù)方面的，我平時(shí)沒有怎么接觸過，不過看起來應(yīng)該也是非常不錯(cuò),應(yīng)該對(duì)做地理信息的朋友很有幫助。***的open space環(huán)境有兩個(gè)小組討論了一些問題，但是***沒有什么答案，正好我有些類似的經(jīng)驗(yàn)，所以也就分享了下。

MySQL數(shù)據(jù)庫(kù)的無縫遷移問題？

問：在平時(shí)的開始過程中，由于經(jīng)常“需求理解，架構(gòu)設(shè)計(jì)，需求變更”等多種原因，導(dǎo)致系統(tǒng)運(yùn)行一段時(shí)間后，數(shù)據(jù)庫(kù)的表結(jié)構(gòu)需要變更，如何實(shí)現(xiàn)盡量短的停機(jī)，實(shí)現(xiàn)無縫的遷移？

我開玩笑說，***的解決辦法就是不遷移。不遷移肯定***，這要依賴于非常好的設(shè)計(jì)，在前期架構(gòu)設(shè)計(jì)的時(shí)候能夠考慮到需求可能的變更，數(shù)據(jù)庫(kù)設(shè)計(jì)也可以根據(jù)業(yè)務(wù)來進(jìn)行一定程度的抽象。這可能有點(diǎn)太理想，不過遷移數(shù)據(jù)，始終是個(gè)不可避免的問題。下面說下一般的遷移方案。

定點(diǎn)停機(jī)遷移

就像那位朋友說的，在一個(gè)月黑風(fēng)高的夜晚，停掉應(yīng)用，用事先寫好的遷移程序，把MySQL 數(shù)據(jù)庫(kù)數(shù)據(jù)遷移到新結(jié)構(gòu)的MySQL數(shù)據(jù)庫(kù)中。完成后，切換應(yīng)用。***的缺點(diǎn)就是隨著數(shù)據(jù)量的增加停機(jī)時(shí)間會(huì)變得非常長(zhǎng)。

MySQL binlog方案

MySQL 的遷移可以考慮MySQL的主從復(fù)制replication的特性，解析binlog日志出來，然后根據(jù)新的業(yè)務(wù)特點(diǎn)設(shè)計(jì)的數(shù)據(jù)庫(kù)結(jié)構(gòu)，把數(shù)據(jù)寫入到新的數(shù)據(jù)庫(kù)，運(yùn)行遷移過程不需要停機(jī)。在數(shù)據(jù)遷移基本上完成的時(shí)候，停掉前段應(yīng)用，等待遷移全部完成，切換應(yīng)用到新庫(kù)。停機(jī)時(shí)間非常短，只需要幾乎1-2分鐘或者更少。

觸發(fā)器方案

備份老的MySQL數(shù)據(jù)表結(jié)構(gòu)到新的MySQL數(shù)據(jù)庫(kù)，在新庫(kù)創(chuàng)建新的表結(jié)構(gòu)，更改老的數(shù)據(jù)庫(kù)表，創(chuàng)建觸發(fā)器，讓數(shù)據(jù)寫入的時(shí)候同時(shí)寫入到的新的MySQL表。dump老的MySQL的數(shù)據(jù)，導(dǎo)入到新的MySQL，這是新的MySQL表結(jié)構(gòu)的表應(yīng)該已經(jīng)有相應(yīng)的數(shù)據(jù)了。然后開啟主從復(fù)制，讓其達(dá)到跟主庫(kù)數(shù)據(jù)一致。切換應(yīng)用，遷移到的方案。停機(jī)時(shí)間非常短，只需要幾乎1-2分鐘或者更少。

MySQL udf方案

MySQL的udf允許你開發(fā)自己的函數(shù)集成到MySQL中，這樣你可以很方便的在數(shù)據(jù)寫入的時(shí)候同時(shí)寫到的其他地方。缺點(diǎn)是開發(fā)成本大，需要對(duì)MySQL udf有了解。也可以用現(xiàn)成的memcached_functions_MySQL和lib_MySQLudf_json來實(shí)現(xiàn)，你就不需要編寫udf函數(shù)了，只需要實(shí)現(xiàn)一個(gè)memcached的服務(wù)端來接受數(shù)據(jù)，然后解析json到新的數(shù)據(jù)庫(kù)就OK了。memcached協(xié)議非常簡(jiǎn)單，自己實(shí)現(xiàn)起來也很容易。這種方案的遷移時(shí)間也會(huì)非常短。

中間件方案

這種方案必須要你的應(yīng)用連接數(shù)據(jù)使用了類似中間層的方案，你只需要在中間層增加同時(shí)往新庫(kù)寫數(shù)據(jù)就OK了。這種方案的依賴比較大，相信小一點(diǎn)的公司可能都沒有條件。

總結(jié)

要實(shí)現(xiàn)無縫遷移，成本和難度肯定會(huì)增加，這需要結(jié)合你的業(yè)務(wù)需要來具體實(shí)施。遷移方案需要進(jìn)行充分的測(cè)試，以及考慮出錯(cuò)的回滾方案。這是我要為大家講解的關(guān)于MySQL數(shù)據(jù)庫(kù)的無縫遷移的知識(shí)的全部?jī)?nèi)容，希望對(duì)大家能夠有所幫助。

【編輯推薦】

1. 論MySQL數(shù)據(jù)庫(kù)中兩種數(shù)據(jù)引擎的差別
2. MySQL數(shù)據(jù)庫(kù)中char與varchar之爭(zhēng)
3. MySQL數(shù)據(jù)庫(kù)常見問題匯總
4. MySQL數(shù)據(jù)庫(kù)單一表突破4G限制的實(shí)現(xiàn)方法