數據庫高可用架構 轉載

數據庫高可用架構對於咱們這些應用端開發的人來講是一個比較陌生的領域，是在具體的數據庫產品之上搭建的環境，須要像DBA這樣對數據庫產品有足夠的瞭解纔能有所涉及，雖然不能深刻其中，但能夠經過一些經典的高可用架構學習其中的思想。就我所瞭解到的有如下幾種：

• MySQL Replication
• MySQL Cluster
• Oracle RAC
• IBM HACMP
• Oracle ASM

MySQL Replication

MySQL Replication就是經過異步複製多個copy以達到提升可用性的目的，常規的複製架構有如下幾種：

• Master-Slaves
• Master-Master
• Master-Master-Salves

1）Master-Slaves

Master-Slaves是最經常使用的提升可用的方法，特別是在互聯網應用中，讀遠遠大於寫，所以提升讀的可用性是首當其中的，Master-Slaves就是讓寫的操做集中在一臺數據庫Master上，而後這個Master會把更新的操做複製到其餘數據庫Slaves上，讀的操做都發生在Slaves上，架構圖以下所示：

如上圖在SlaveC不可用時，讀和寫都不會中斷，等SlaveC恢復後會自動同步丟失的數據，又能從新投入運轉，可維護性很是好。但若是Master有問題就麻煩了，所以它只解決了讀的高可用性，但不保證寫的高可用性。關於Master-Slaves的實戰可參考之前的一篇博文構建高性能web之路------mysql讀寫分離實戰

2）Master-Master

爲解決上面談的寫的高可用性，MySQL提供了Master-Master的複製架構，以下所示：

通常說來都向MasterA寫，MasterA同步數據到MasterB，當MasterA有問題時，會自動切換到MasterB，等MasterA恢復時，MasterB同步數據到MasterA

3）Master-Master-Salves

Master-Master-Salves是結合上面兩種方案，是一種同時提供讀和寫高可用的複製架構，以下圖所示：

MySQL Cluster

MySQL Cluster主要由三個部分組成：

• SQL服務器節點
• NDB數據存儲節點
• 監控和管理節點

三個部門的組成結構以下圖所示：

這樣的分層也是由MySQL自己把SQL處理和存儲分開的架構相關係的，關於MySQL的架構可見之前的博文設計與開發應用服務器（一）------常見模式

這樣一來MySQL Cluster就能夠分別在SQL處理和存儲兩個層次上作高可用的複製策略。在SQL處理層次上，比較容易作集羣，由於這些SQL處理是無狀態性的，徹底能夠經過增長機器的方式加強可用性。在存儲層次上，經過對每一個節點進行備份的形式增長存儲的可用性，這相似與MySQL Replication，結構圖以下所示：

Oracle RAC

Oracle RAC和MySQL Cluster有些類似，但主要集中在SQL處理層的高可用性，而在存儲上體現很少，結構圖以下所示：

它的主要優勢就是對應用透明，而且經過Heartbeat檢測可用性很是高，主要缺點就是存儲是共享的，存儲上可擴展能力不足。

IBM HACMP

IBM HACMP與Oracle RAC也是相似，主要用於雙機互備，運行流程以下所示：

1）做爲雙機系統的兩臺服務器（主機A和B）同時運行在Hacmp環境中；
2）服務器除正常運行自機的應用外，同時又做爲對方的備份主機；
3）兩臺主機系統（A和B）在整個運行過程當中，經過 「心跳線」相互監測對方的運行狀況（包括系統的軟硬件運行、網絡通信和應用運行狀況等）；
4）一旦發現對方主機的運行不正常（出故障）時，故障機上的應用就會當即中止運行，本機（故障機的備份機）就會當即在本身的機器上啓動故障機上的應用，把故障機的應用及其資源（包括用到的IP地址和磁盤空間等）接管過來，使故障機上的應用在本機繼續運行；
5）應用和資源的接管過程由Ha軟件自動完成，無需人工干預；
6）當兩臺主機正常工做時，也能夠根據須要將其中一臺機上的應用人爲切換到另外一臺機(備份機)上運行。
Oracle ASM

Oracle ASM主要提供存儲的可擴展性，經過自動化的存儲管理加上後端可擴展性的存儲陣列達到高可用性，結構圖以下所示：

所以，能夠嘗試把Oracle RAC和ASM組合起來使用，同時提供SQL處理和存儲的高可用性，這也是MySQL Cluster想達到的效果