mysql性能優化系列8-mysql集羣

1. 爲什麼要使用集羣

（1）可用性
單個數據庫實例宕機，其他的數據庫實例可提供服務，對業務來說基本無感知。同時數據在多個實例之間的複製，提高數據的安全性和可用性。
（2）提高性能
業務對數據的訪問可以分散到不同的數據庫實例上，比如讀寫分離降低單個數據庫實例的訪問壓力。

2. 集羣方案

（1）MySQL Cluster
Mysql本身提供，優勢：可用性和性能非常好。每份數據至少可在不同主機存一份拷貝，且冗餘數據拷貝實時同步。但它的維護非常複雜，存在部分Bug，不適合比較核心的線上系統。
（2）DRBD
Distributed Replicated Block Device（磁盤網絡鏡像方案）是通過網絡來鏡像整個設備(磁盤)。它允許用戶在遠程機器上建立一個本地塊設備的實時鏡像，與心跳鏈接結合使用。
優勢：軟件功能強大，數據可在底層快設備級別跨物理主機鏡像，且可根據性能和可靠性要求配置不同級別的同步。IO操作保持順序，可滿足數據庫對數據一致性的苛刻要求。但非分佈式文件系統環境無法支持鏡像數據同時可見，性能和可靠性兩者相互矛盾，無法適用於性能和可靠性要求都比較苛刻的環境，維護成本高於MySQL Replication。DRBD也是官方推薦的可用於MySQL高可用方案之一。
（3）MySQL Replication
MySQL Replication是使用最爲廣泛的一種方案。通過Replication功能提升系統的擴展性，硬件設備價格低廉，但性能成數量級地提高。

3. 複製

複製是指將主庫的 操作通過二進制日誌傳到複製從庫,然後從庫根據日誌重新執行操作，使得從庫和主庫的數據保持同步。MysQL支持一臺主庫同時向多臺從庫進行復制,從庫同時也可以作爲其他服務器的主庫，實現鏈狀的複製 。
由於MySQL並不是完全同步,所以主從庫數據之間存在一定的差距，一般對實時性要求不高的數據可以通過從庫查詢，實時性要求高的數據仍然需要從主數據庫獲得。
優勢：

• 如果主庫宕機、從庫可以提供服務
• 讀寫分離，降低從庫壓力
• 某些數據庫維護工作比如備份，可以在從庫上執行，避免影響主庫提供服務

3.1 原理

• 主庫在事務提交時會把數據變更作爲事件Events記錄在二進制日誌文件Binlog中，主庫上的sync_binlog參數控制Binlog日誌刷新到磁盤
• 主庫推送二進制日誌文件Binlog中的事件到從庫的中繼日誌Relay Log，從庫根據Relay Log重做數據變更，從而主庫和從庫達到數據一致
• MySQL通過3個線程來完成主從庫的數據複製，Binlog Dump線程在主庫上，I/0線程和SQL線程跑在從庫上。當在從庫上啓動複製時，首先創建I/0程連接主庫，主庫隨後創建Binlog Dump線程讀取數據庫事件發送給I/0線程，I0線程將事件數據寫到從庫的中繼日誌Relay Log中去，從庫上的 SQL線程讀取中繼日誌RelayLog中重新執行操作。

3.2 文件參數

複製過程涉及了兩個日誌文件：二進制日誌文件Binlog和中繼日誌文件Relay Log。Binlog會記錄Create、Drop、Insert、Update、Delete等操作，但不會記錄Select操作。Binlog支持Statement、Row、Mixed三種方式，通過show variables可以査看。
Relay Log的文件格式、內容和Binlog一樣，區別在於從庫的SQL線程在執行完Relay Log中的事件後，會自動刪除Relay Log中的事件，避免Relay Log佔用過多的磁盤空間。
爲了保證從庫Crash重啓之後，從庫的I/0線程和SQL線程仍然能夠知道從哪裏開始複製，從庫上默認還會創建兩個日誌文件master.info（記錄l/0線程讀取主庫Binlog的進度）和relay_log.info（SQL線程讀取RelayLog的進度）。
可以通過 show slave status命令能夠看到當前從庫複製的狀態。

• Master Host：主庫 IP
• Master Port：主庫 MySQL的端口號
• Master User：主庫上主從複製的用戶賬號
• Master_Log_File：主庫的Binlog文件
• Read_Master Log_Pos：從庫I/0線程當前讀取到的位置
• Relay_Log_File：Relay Log文件名
• Relay_Log_Pos：從庫SQL線程當前讀取並應用Relay Log的位置
• Relay_Master_Log_File：從庫SQL線程正在讀取和應用的Relay Log對應的主庫Binlog的文件名
• Exec_Master_Log_Pos：RelayLog中Relay_Log_Pos位置對應於主庫Binlog的位置

3.3 三種複製技術

Binlog有三種格式：

• Statement：基於SQL語句級別的Binlog，每條修改數據的SQL都會保存到Binlog
• Row：基於行級別，記錄每一行數據的變化，並不記錄原始SQL。在複製的時候，不會因爲存儲過程或觸發器造成主從庫數據不一致，但是日誌量較Statement格式要大得多 。
• Mixed：混合Statement和Row模式，默認情況下采用Statement模式記錄，某些情況下會切換到Row模式

binlog_format設置爲Row時, MySQL實際上在 Binlog中逐行記錄數據的變更, Row格式比 Statement格式更能保證從庫數據的一致性(複製的是記錄,而不是單純操作 SQL)。當然, Row格式下的 Binlog的日誌量很可能會增大非常多,在設置時需要考慮到磁盤空間間題。可以通過參數binlog_format在全局或者在當前session動態設置Binlog的格式，在全局設置會影響所有session。

3.4 複製架構

常見3種複製架構有一主多從複製、多級複製和雙主複製/DrualMaster架構

• 一主多從：在主庫查詢壓力非常大時，可以配置一主多從實現讀寫分離，在主庫宕機時, 可以把一個從庫切換爲主庫繼續提供服務

• 多級複製
  MysQL的複製是主庫推送Binlog日誌到從庫，主庫的 I/0壓力和網絡壓力會隨着從庫增加而增長(每個從庫都會在主庫上有一個獨立的Binlog Dump線程來發送事件)，多級複製架構解決了一主多從場景下，主庫額外的 I/0和網絡壓力

• 雙主複製/Dual Master：主庫Master和Master2互爲主從， client客戶端的寫請求都訪問主庫Master，而讀請求可以選擇訪問主庫 Master或 Master2。
  
  雙主複製還能和主從複製聯合起來使用。

3.5 複製過程

（1）異步複製
主庫執行完Commit後，在主庫寫入Binlog日誌後即可成功返回客戶端，無需等Binlog日誌傳送給從庫。

步驟：

• 主從庫安版本相同
• 在主庫上設置一個複製使用的賬戶，並授予REPLICATION SLAVE權限
• 修改主庫配置文件my.cnf，開啓 BINLOG，並設置server-id的值
• 執行show master status得到主庫上當前的二進制日誌名和偏移量值。這個操作的目的是爲了在從數據庫啓動以後,從這個點開始進行數據的恢復
• 修改從數據庫的配置文件my.cnf，增加 server-id參數。server-id的值必須是唯一的，不能和主數據庫的配置相同
• 在從庫上使用 - -skip-slave- start選項啓動從數據庫，這樣不會立即啓動從數據庫服務上的複製進程，方便我們對從數據庫的服務進行進一步的配置
• 在從庫指定複製使用的用戶,主數據庫服務器的IP、端口以及開始執行復制的日誌文件和位置等

CHANGE MASTER TO MASTER_HOST='192.168.56.103',MASTER_PORT=3306,MASTER_USER='rep1',MASTER_PASSWORD='1234test' ,MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=428

• 在從庫上啓動slave線程

（2）半同步複製
MySQL5.5之前，複製是異步操作，這樣存在一個隱患：當主庫上寫入一個事務並提交成功,而從庫尚未得到主庫推送的 Binlog日誌時,主庫宕機了或者主庫可能因磁盤損壞、內存故障等造成主庫上該事務 Binlog丟失,此時從庫就可能損失這個事務，從而造成主從不一致。而半同步複製，是等待其中一個從庫也接收到Binlog事務併成功寫入Relay Log之後，才返回Commit操作成功給客戶端。這樣保證至少有兩份日誌記錄，一份在主庫Binlog上，另一份在從庫的Relay Log上。半同步複製很大程度取決於主從網絡RTT（往返時延），以插件semisync_master/semisync_slave 形式存在。

3.5 集羣高可用插件

（1）Keepalived
Mysql+Keepalived可以實現雙主高可用。Keepalived在之前文章中說過，不再詳細解釋。簡單回顧下。
Keepalived是基於VRRP協議的一款高可用軟件。Keepailived有一臺主服務器和多臺備份服務器，在主服務器和備份服務器上面部署相同的服務配置，使用一個虛擬IP地址對外提供服務，當主服務器出現故障時，虛擬IP地址會自動漂移到備份服務器。
Keepalived是一個工作在IP/TCP協議棧的IP層，TCP層及應用層實現交換機制的軟件。作用是檢測服務器的狀態，如果有一臺服務器宕機，或工作出現故障，Keepalived將有故障的服務器從系統中剔除，同時使用其他服務器代替該服務器的工作，當服務器工作正常後Keepalived自動將服務器加入到服務器羣中。

• IP層： Keepalived會定期向服務器羣中的服務器發送一個ICMP的數據包（Ping程）,如果發現某臺服務的IP地址沒有激活，Keepalived便將它從服務器羣中剔除
• TCP層:主要以TCP端口的狀態來決定服務器工作正常與否。如果Keepalived檢測到對應端口沒有啓動，則Keepalived將把這臺服務器從服務器羣中剔除
• 應用層：對指定的URL執行HTTP GET。然後使用MD5算法對HTTP GET結果進行求和。如果這個總數與預期值不符，那麼服務器將從服務器池中移除。該模塊對同一服務實施多URL獲取檢查

（2）HAProxy
HAProxy是請求分發，類似於nginx的負載均衡，haproxy監聽一個統一對外提供能力的端口，然後內部進行分發。除支持http7層處理外，還順便爲mysql支持4層轉發。這裏常常需要一個額外的機器來提供服務，但是由於只爲haproxy使用，一個最低配機器即可。haproxy轉發策略可以是輪詢、加權或者隨機等。
爲了保證HAProxy的可靠性，常常用兩臺HAProxy，並用KeepAlived實現HAProxy高可用。