關於MySQL集群的一些看法

02-05

市面上的招聘往往要求DBA精通MySQL集群，實際上，應該指得是MySQL複製。由於MySQL cluster應用場景很少且很複雜，所以國內擅長MySQL cluster的DBA其實是很少的。許多人/公司還停留在試用階段。

由於數據量的不斷增加，讀寫吞吐的不斷增加，業務對於資料庫的高可用/高吞吐要求越來越高，單個節點往往承載不了工作負荷，如果我們擁有一個多節點的集群，可以把數據分布在多個節點，多個節點同時對外提供部分或者全部服務，那麼將可以大大改善我們系統的可用性和擴展性。

在現實領域，由於MySQL集群產品的複雜性和維護成本，DBA往往並不傾向於採用這種方案，特別是DBA本身成為工作瓶頸的情況下，當然DBA希望方案越簡單越好，而MySQL主從就是最簡單的方案。

資料庫的擴展一般可分為讀的擴展、寫的擴展以及數據量的擴展。對於讀的擴展，通過複製架構，增加更多的從庫，是可以大大緩解讀的，而在合適的時機使用緩存架構，是普遍認為更良好的一種解決方案。緩存的方案也可以比MySQL自身的從庫更高效的處理工作負荷。

複製架構擴展讀，需要考慮的一個問題是讀的一致性，由於一些數據對於複製延時是敏感的，你可能不能簡單的從從庫讀取，而是仍然從主庫讀取，以獲得強一致性，所以，對於你的數據，你一定要清楚，明確知道各種數據對於時間的敏感度，分別加以處理，這種處理工作在應用層處理成本會更少，更好處理。

MySQL複製為了獲得各種級別的一致性，有非同步、半同步、強同步之分，對同步要求越高，對性能影響最大。一般生產環境，我建議仍然是採用非同步複製的方式，這也是默認的，如果真的需要很高的一致性，我覺得從應用的訪問策略解決更好，直接從主庫或者緩存中讀取是更優雅的處理方式。

對於MySQL複製集群，實例數比較少，DBA往往可以手動處理，如果你擁有大量實例，那麼需要更自動化的方案，網上有一些開源的方案，大家可以參考，比如MHA，Proxy的方案也是可行，可以更透明的處理節點異常，在5.6 gtid實現後，MySQL的節點複製的異常處理，已經變得比以前簡單多了，相對低版本來說，自動化程度也可以更為提高，自動化方案也會更穩健。

傳統的技術仍然有一定的用武之地，比如基於存儲層的同步，MySQL提供了一個軟raid的方案DRBD, 據說也有許多人採用這個方案，但是我認為，這種方案是不可取的，現在的PC伺服器已經很強勁，基於主機之間做故障切換是主流，我們設計方案也應該從這點出發，主庫如果不可用，就把流量切換到從庫。如果使用DRBD這樣的方案，意味著有一邊節點是不能用的，而且切換的時間也很可能達不到你的需求。在一個，DRBD可能自身成為整個系統的評價，因為現在的SSD硬碟已經很快了，網路raid反而成為瓶頸，限制了性能/吞吐。

對於寫的擴展，複製架構其實無助於解決問題，如果不能從應用層減少數據的寫入，我們只能進行垂直或者水平的拆分，把數據的寫入平均分布到多個節點，sharding的技術方案這個時候會用到，對於sharding的策略，不要求很自動化或者擴展很多倍，但預先進行sharding策略是需要的，如果你的業務真的可能有大量的數據增長。常見的一個問題是，軟體設計人員不清楚硬體，往往預留了太多的擴展空間，這點可以通過和硬體運維團隊、DBA加以溝通盡量避免。

資料庫的寫的優化，和其他應用程序的寫入優化差不多，減少寫的次數、減少寫的頻率、批量寫、合併寫、壓縮、利用時間/空間的局部性，你需要選擇的是，在應用層做呢，還是在資料庫的層次做。對於很大的的欄位，如果實際是可以獲得很高壓縮比的話，比如是文本，MySQL 5.6的壓縮表，是值得考慮嘗試的。

我傾向於資料庫控制在1個T以下，並不是說MySQL就處理不來超過1T的數據，而在於這種有的方式更可控，基於經驗認為這樣的數據量單個實例，是比較成本平衡的，MySQL對於大數據量的備份，仍然存在一些帶解決的問題。所以如果集群有多個節點，能在多個節點分別備份，那麼基於每個節點的備份/恢復也會快的多的。

有一個觀點認為，集群有更多的節點，那麼可以容錯性更高，因為單個節點可能只負責部分訪問，那麼單個節點的失效，整個系統仍然大部分可用，這取決於你的系統的設計，如果你的集群系統是鬆散耦合的，單個節點不怎麼影響整個系統，那麼這種想法是有道理的，如果單個節點可能導致整個系統不可用，那麼多個節點，可能導致更多的問題出現，顯而易見的情況是，數據分布到多台機器，出故障的概率肯定是要多了，如果沒有一套自動化的發現和處理問題的手段，那麼必然意味著管理維護成本的攀升。

有人使用官方的MySQL cluster，也有人使用percona公司出品的Percona XtraDB Cluster，但由於使用的人少，務必做好充分的測試驗證工作，你可能碰到許多問題需要小心加以避免。這些產品在解決問題的同時，往往帶來一些新的問題。

基於目前的官方文檔，MySQL cluster是緊耦合設計的，對於節點之間的網路要求很高，而Percona XtraDB Cluster相對來說是松耦合設計，容錯性更高，這方面我沒有足夠的經驗。有想使用cluster的同學，建議從試用Percona XtraDB Cluster開始。