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

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

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

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

定點停機遷移

就像那位朋友說的，在一個月黑風高的夜晚，停掉應用，用事先寫好的遷移程序，把MySQL 數(shù)據(jù)庫數(shù)據(jù)遷移到新結構的MySQL數(shù)據(jù)庫中。完成后，切換應用。***的缺點就是隨著數(shù)據(jù)量的增加停機時間會變得非常長。

MySQL binlog方案

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

觸發(fā)器方案

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

MySQL udf方案

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

中間件方案

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

總結

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

【編輯推薦】

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