前言：
相對於傳統行業的相對服務時間9x9x6或者9x12x5，因為互聯網電子商務以及互聯網游戲的實時性，所以服務要求7*24小時，業務架構不管是應用還是數據庫，都需要容災互備，在mysql的體系中，最好通過在最開始階段的數據庫架構階段來實現容災系統。所以這裡從業務宏觀角度闡述下mysql架構的方方面面。
一，MySQL架構設計—業務分析
(1)讀多寫少
虛線表示跨機房部署，比如電子商務系統，一個Master既有讀也有些寫，對讀數據一致性需要比較重要的，讀要放在Master上面。
M(R)僅僅是一個備庫，只有M(WR)掛了之後，才會切換到M(R)上，這個時候M(R)就變成了讀寫庫。比如游戲系統，有很多Salve會掛載後面一個M(R)上面。
(2)讀多寫少MMS-電商
如果是電子商務類型的，這種讀多寫少的，一般是1個master拖上4到6個slave，所有slave掛載在一個master也足夠了。
切換的時候，把M1的讀寫業務切換到M2上面，然後把所有M1上的slave掛到M2上面去，如下所示：
(3)讀多寫少MMSS-游戲
如果是游戲行業的話，讀非常多蠻明顯的，會出現一般1個Master都會掛上10個以上的Slave的情況，所以這個時候，可以把一部分Slave掛載新的M(R)上面。至少會減少一些壓力，這樣至少服務器掛掉的時候，不會對所有的slave有影響，還有一部分在M(R)上的slave在繼續，不會對所有的slave 受到影響，見圖3，
(4)讀少寫多
意味著讀並不會影響寫的效率，所以讀寫都可以放在一個M1(WR)，而另外一個不提供讀也不提供寫，只提供standby冗余異地容災。
這個異地容災是非常重要的，否則如果是單機的，單邊的業務，萬一idc機房故障了，一般就會影響在線業務的，這種 造成業務2小時無法應用，對於在線電子商務交易來說，影響是蠻大的，所以為了最大限度的保證7*24小時，必須要做到異地容災，MM要跨idc機房。雖然對資源有一些要求，但是對HA來說是不可缺少的，一定要有這個MM機制。
做切換的時候，把所有的讀寫從M1直接切換到M2上就可以了。
(5)讀寫平分秋色
讀和寫差不多，但是讀不能影響寫的能力，把讀寫放在M1(WR)上，然後把一部分讀也放在M2(R)上面，當然M1和M2也是跨機房部署的。
切換的時候，把一部分讀和全部寫從M1切換到M2上就可以了。
