【51CTO獨家特稿】如果單MySQL的優(yōu)化始終還是頂不住壓力時，這個時候我們就必須考慮MySQL的高可用架構(gòu)(很多同學(xué)也愛說成是MySQL集群)了，目前可行的方案有：
一、MySQL Cluster
優(yōu)勢：可用性非常高，性能非常好。每份數(shù)據(jù)至少可在不同主機存一份拷貝，且冗余數(shù)據(jù)拷貝實時同步。但它的維護非常復(fù)雜，存在部分Bug，目前還不適合比較核心的線上系統(tǒng)，所以這個我不推薦。
二、DRBD磁盤網(wǎng)絡(luò)鏡像方案
優(yōu)勢：軟件功能強大，數(shù)據(jù)可在底層快設(shè)備級別跨物理主機鏡像，且可根據(jù)性能和可靠性要求配置不同級別的同步。IO操作保持順序，可滿足數(shù)據(jù)庫對數(shù)據(jù)一致性的苛刻要求。但非分布式文件系統(tǒng)環(huán)境無法支持鏡像數(shù)據(jù)同時可見，性能和可靠性兩者相互矛盾，無法適用于性能和可靠性要求都比較苛刻的環(huán)境，維護成本高于MySQL Replication。另外，DRBD也是官方推薦的可用于MySQL高可用方案之一，所以這個大家可根據(jù)實際環(huán)境來考慮是否部署。
三、MySQL Replication
在實際應(yīng)用場景中，MySQL Replication是使用最為廣泛的一種提高系統(tǒng)擴展性的設(shè)計手段。眾多的MySQL使用者通過Replication功能提升系統(tǒng)的擴展性后，通過簡單的增加價格低廉的硬件設(shè)備成倍 甚至成數(shù)量級地提高了原有系統(tǒng)的性能，是廣大MySQL中低端使用者非常喜歡的功能之一，也是許多MySQL使用者選擇MySQL最為重要的原因。

比較常規(guī)的MySQL Replication架構(gòu)也有好幾種，這里分別簡單說明下
MySQL Replication架構(gòu)一：常規(guī)復(fù)制架構(gòu)--Master-slaves，是由一個Master復(fù)制到一個或多個Salve的架構(gòu)模式，主要用于讀壓力大的應(yīng)用數(shù)據(jù)庫端廉價擴展解決方案，讀寫分離，Master主要負責寫方面的壓力。
MySQL Replication架構(gòu)二：級聯(lián)復(fù)制架構(gòu)，即Master-Slaves-Slaves,這個也是為了防止Slaves的讀壓力過大，而配置一層二級 Slaves，很容易解決Master端因為附屬slave太多而成為瓶勁的風險。
MySQL Replication架構(gòu)三：Dual Master與級聯(lián)復(fù)制結(jié)合架構(gòu)，即Master-Master-Slaves，最大的好處是既可以避免主Master的寫操作受到Slave集群的復(fù)制帶來的影響，而且保證了主Master的單點故障。
以上就是比較常見的MySQL replication架構(gòu)方案，大家可根據(jù)自己公司的具體環(huán)境來設(shè)計 ，Mysql 負載均衡可考慮用LVS或Haproxy來做，高可用HA軟件我推薦Heartbeat。
MySQL Replication的不足：如果Master主機硬件故障無法恢復(fù)，則可能造成部分未傳送到slave端的數(shù)據(jù)丟失。所以大家應(yīng)該根據(jù)自己目前的網(wǎng)絡(luò)規(guī)劃，選擇自己合理的Mysql架構(gòu)方案，跟自己的MySQL DBA和程序員多溝涌，多備份(備份我至少會做到本地和異地雙備份)，多測試，數(shù)據(jù)的事是最大的事，出不得半點差錯，切記切記。
因本人自身能力有限，以上認識可能存在錯誤和疏漏，大家有什么想法和意見都可以通過我的博客與我交流，我會在第一時間更正此文章。

本文轉(zhuǎn)自 撫琴煮酒 51CTO博客，原文鏈接：http://blog.51cto.com/yuhongchun/510652，如需轉(zhuǎn)載請自行聯(lián)系原作者

總結(jié)

以上是生活随笔為你收集整理的MySQL数据库的优化(下)MySQL数据库的高可用架构方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。