天天看點

OLTP應用之MySQL架構選型

在我們下定決心将企業核心應用從企業級資料庫遷移到開源資料庫産品、使用本地磁盤代替共享存儲之前。我覺得我們必須要面對并回答以下幾個問題之後才能真正的将開源進行到底,将想法付諸于實踐。下面我們來看一下我們在将OLTP應用遷移到MySQL資料庫之上之前,我們必須要回答的幾個問題:

(1)  允許在極端情況下備庫接管服務後,資料存在暫時的不一緻嗎(主從架構下在主庫crash後可能存在部分寫操作沒有及時同步的備庫的問題)?

(2)  MySQL資料庫在資料庫故障時應用服務也将中斷3-30s,這樣的場景是否能夠接受?

(3)  我們對資料庫的可擴充性、吞吐能力、響應時間及使用者體驗是否有較高的要求?

隻有回答了如上三個問題,以下3類OLTP類型的MySQL架構設計方案,才能真正的具備可參考性與實際意義。下面我們來扒一扒筆者目前考慮到适合OLTP應用開源解決方案。

方案一、多主同步複制方案PXC

PXC,即Percona Xtradb Cluster,它采用Galera引擎,可以實作多個節點間的資料同步複制以及讀寫并且可保障資料庫的服務高可用及資料一緻性。其架構如下所示:

OLTP應用之MySQL架構選型

一、 PXC的優點

(1) 資料同步複制

(2) 多個可同時讀寫節點,但需要事先進行分庫分表,讓各個節點分别寫不同的表或者庫

(3) 可以保證資料嚴格一緻性

(4) 适合讀多寫少的業務系統

二、 PXC的缺點

(1) 不支援XA事務

(2) 叢集吞吐量/性能取決于響應最慢的節點,事務效率與主從架構相比低了不止一個數量級

(3) 需要調整

(4) 隻支援InnoDB引擎

(5) 所有表都要有主鍵

(6) 不允許大事務産生

(7) 不支援LOCK TABLE等顯式鎖操作

(8) 存在寫沖突,鎖沖突、死鎖問題較多,不能解決熱點更新問題,可擴充性差

(9) 如果并發事務量很大的話,官方建議采用InfiniBand網絡,降低因網絡延遲帶來的瓶頸

(10) 需要引入多個第三方插件,內建複雜度高

方案二、主從複制方案MHA

MHA即Master High Availability Manager and Tools for MySQL是一個MySQL高可用管理工具,目的在于維持Master主庫的高可用性及資料的一緻性。其最大特點是可以修複多個Slave之間的差異日志,最終使所有Slave保持資料一緻,然後從中選擇一個Slave資料庫作為新的Master,并将其它Slave指向它。

   其架構如下,請參考:

OLTP應用之MySQL架構選型

一、 MHA的優點

1. 自動監控Master故障轉移、故障後節點之間的資料同步

2. 不會有性能損耗,适用于任何存儲引擎

3. 具備自動資料補償能力,在主庫異常崩潰時能夠最大程度的保證資料的一緻性

4. 可實作同城應用級别雙活

二、 MHA的缺點

1. 如果主伺服器硬體故障或無法通過ssh通路,進行故障轉移可能導緻丢失目前資料

2. 切換時間較長,整個切換時間大約需要9-12s

方案三、主主複制方案MM

利用MySQL原生支援主從單向複制、主主雙向複制,該架構解決了主庫單點及寫瓶頸等問題。 其架構如下,請參考:

OLTP應用之MySQL架構選型

一、 MM架構優點

1. 支援快速切換,一般3s之内即可切換到備機

2. 配置管理簡單、不需要第三方插件

二、 MM架構缺點

1. 如果資料庫伺服器硬體故障可能導緻丢失目前操作資料

關于以上方案的總結

(一)對于PXC架構,其優點很多但缺點同時也非常的明顯,其核心優勢就是保證了各節點資料的一緻性,劣勢就是其在可擴充性、鎖沖突、寫擴大方面存在問題,PXC為了保證資料的一緻性其要求每個節點都要将資料寫入到磁盤才算完成,這樣就存在一個效率問題。也就是說每個事務的響應時間依賴于整個叢集最慢的節點,且其對網絡品質要求非常高。另一個問題就是我們需要考慮清楚,我們的開源的方向在哪裡?是跟着一個小衆分支開源社群Percona,還是跟着主流MySQL官方開源社群發展的問題。

(二)對于MHA架構其優點就是通過MHA插件解決主庫的單點問題及因主庫挂掉後盡量保證接管的從庫與當機後的主庫的資料一緻性且資料的同步功能是原生的,其缺點就是在主庫故障切換後不能保證資料零丢失,其實這裡更準确的說法不應該是資料丢失應該主庫與從庫資料不一緻。

在以下情況MHA可以保證接管後的節點與主庫資料時一緻性的:

(1) 在不發生硬體故障的情況下是可以從修複後的主庫找回資料并由DBA手動補回備庫,最終實作資料的一緻性;

(2) 若隻是資料庫故障,MHA具備将所有已落實的資料自動同步到備庫進而實作資料的零丢失;

(3) 直接使用MySQL的半同步機制,兩階段送出來保證資料的一緻性,這個方法與PXC的實作方式相似

(三)對于MM雙主架構其優缺點與MHA相似,都是采用MySQL原生的資料同步機制。不同之處就是MM架構在主故障時切換時間更短,缺點就是産生資料不一緻的可能性更多一下。另外在MM架構中我們也可以嘗試引入MHA資料補償工具來盡量降低在主備切換時導緻的資料不一緻性問題或者直接使用MySQL的半同步機制來保證資料一緻性。

上一篇: linux-grep
下一篇: expect寫腳本