分享MYSQL中的各類高可用技術（源自姜承堯大牛）

圖片和資料來源於MYSQL大牛姜承堯老師（MYSQL技術內幕做者）

姜承堯： 網易杭州研究院 技術經理 主導INNOSQL的開發

mysql高可用各個技術的比較

數據庫的可靠指的是數據可靠 

數據庫可用指的是數據庫服務可用

可靠的是數據：例如工商銀行，數據不能丟失

可用的是服務：服務器不能宕機

 

 

 

靈活運用MYSQL的各類高可用技術來達到下面各類級別的高可用要求

要達到99.9%：使用MYSQL複製技術

要達到99.99%：使用MYSQL NDB 集羣和虛擬化技術

要達到99.999%：使用shared-nothing架構的GEO-REPLICATION和NDB集羣技術

Gluster Geo-replication是什麼？

Gluster Geo-replication(簡稱geo-replication)是一種異地災備技術，

它主要應用於把集羣中的一個存儲，近乎即時地(near real-time)透過公網（wan）備份到遠端的機房

 

各類高可用級別容許的宕機時間

DRBD：網絡磁盤的RAID1

---

方案一：MYSQL主從複製（單活）

投票選舉機制，較複雜

MySQL自己沒有提供replication failover的解決方案，自動切換須要依賴MHA腳本

能夠有多臺從庫，從庫能夠作報表和備份

 

---

方案二：雙主（單活），failover比單主簡單

一樣，自動切換須要MMM腳本

缺點是某個主掛掉了，他下面的slave一樣掛掉

---

方案三：雙主配SAN存儲（單活）

 

這個架構跟方案二是同樣的，只不過兩個master之間不須要同步數據，由於他們用的是共享磁盤

這個方案是有錢人方案，不管哪一個主掛掉都不會引發其餘的slave掛掉，可是SAN存儲死貴。。

像通訊行業中國聯通這些公司有用到

某個主掛掉了，下面的slave不會掛掉

注意：failover以後不會預熱，數據沒有預先加載到內存中，切換以後一段時間內存儲會有必定的性能影響

 

---

方案四：DRBD 雙主配DRBD （單活）

結構跟方案三同樣，惟一不一樣的是沒有使用SAN網絡存儲 ，而是使用local disk

因爲是實時複製磁盤數據，性能會有影響

人們把DRBD稱爲「屌絲的SAN」

POOR MAN'S SAN：窮人的SAN

 

 

 

---

方案五：NDB CLUSTER

 

國內用NDB集羣的公司很是少，貌似有些銀行有用

NDB集羣不須要依賴第三方組件，所有都使用官方組件，能保證數據的一致性

某個數據節點掛掉，其餘數據節點依然能夠提供服務

管理節點須要作冗餘以防掛掉

缺點是：管理和配置都很複雜，並且某些SQL語句例如join語句須要避免

 

---

方案六：第三方的Tungsten軟件

使用java編寫，不是MYSQL內置的

一樣是MYSQL數據庫複製，不過他不是用MYSQL內置的組件來作的

不但支持MYSQL數據庫複製也支持異構數據庫的複製，並且對異構數據庫複製支持較好，例如MYSQL複製到ORACLE

---

方案七：網易的INNOSQL

相似於SQLSERVER的鏡像高安全模式

High Safety 模式 （也就是同步模式）沒有 witness服務器

數據庫在Principle的事務，須要立刻獲得mirror的確認，才能完成。這種狀況下，Mirror和Principle的數據是同步的。

可是由於全部的事務須要mirror的確認，因此性能可能會有所影響。

區別：innosql的slave能夠讀，鏡像的slave（從庫）不可讀

保證數據不會丟失，數據的高可靠性

 

mysql5.7開始支持這種模式

 

 

---

總結

每種方案都有不一樣的特色，配置和應用場景也各有不一樣

有些偏向於成本低的，有些偏向於成本高的，有些偏向於數據的可靠性，有些則偏向於數據庫的可用性

反正各個方案都各有優缺點，DBA要結合本身公司的業務狀況進行選擇合適本身業務狀況的高可用方案

 

更多參考資料：

讀寫分離：Amoeba

Ubuntu10下MySQL搭建Amoeba系列（文章索引）

集羣技術：數據庫集羣技術漫談

Gluster Geo-replication工做原理

 

若有不對的地方，歡迎你們拍磚o(∩_∩)o