作為一個關係型資料庫,MySQL內建地提供資料複製機制,這使得在使用時,可以基於其複製機制實現高可用架構等高階特性,從而使得MySQL無需藉助額外的外掛或其他工具就具備適用於生產環境。這是MySQL得到大面積實際應用的條件之一。
基於MySQL的複製機制,不僅可以實現資料庫的高可用,還能實現如:效能擴充套件、異地災備以及冷熱分離等高階特性。
- 高可用:通過配置一定的複製機制,MySQL實現了跨主機的資料複製,從而獲得一定的高可用能力,如果需要獲得更高的可用性,只需要配置多個副本,或者進行級聯複製就可以達到目的。
- 效能擴充套件:由於複製機制提供了多個資料備份,在讀寫一致性要求不高的場景下,可以通過配置一個或多個副本,將讀請求分發至副本節點,從而獲得整體上讀寫效能的提升。
- 異地災備:只需要將副本節點部署到異地機房,就可以輕鬆獲得一定的異地災備能力。實際當中,需要考慮網路延遲等可能影響整體表現的因素。
- 交易分離:通過配置複製機制,並將低頻、大運算量的交易傳送至副本節點執行,就可以避免這些交易與高頻交易競爭運算資源,從而避免整體的效能問題。
為了獲得上述能力,需要了解基本的MySQL複製機制,並結合實際應用場景選擇恰當的配置。
主從複製機制
MySQL基於binlog實現主從複製,從節點跟蹤並獲取主節點binlog中最新更新並在自身進行重放,從而實現複製主節點資料。
下圖是MySQL主從複製過程的示意圖。在整個過程中涉及三個執行緒,他們的職責分別是:
- 主節點binlog dump執行緒:該執行緒在從節點連線上主節點後建立,負責向從節點傳送binlog中新寫入的資料。在讀取binlog時,dump執行緒會首先獲取binlog的鎖,並在讀取完畢後立刻釋放,然後將讀取到的資料傳送至從節點。
- 從節點I/O執行緒:從節點I/O執行緒職責為向主節點傳送資料同步的請求,接收主節點傳送的資料並將其寫入relay-log。
- 從節點SQL執行緒:該執行緒從relay-log中讀取資料更新並進行重放。
非同步複製
預設情況下,MySQL的主從複製是非同步複製,在這種機制下,主節點會在完成本地日誌寫入後立刻響應客戶端的請求,從節點的資料複製過程非同步執行。
很明顯,在這種機制下面,由於複製過程並不會影響主節點對客戶端請求的響應,因此,相比於單節點,並不會造成整體效能上的明顯損失。
但是,在這種機制下面,如果資料在主節點完成提交而未同步至從節點時主節點當機,此時如果發生主從切換並寫入新的資料,可能導致資料丟失或不一致。
半同步複製(semisynchronous replication)
從5.6版本開始,MySQL支援半同步複製,這種機制與非同步複製相比主要有如下區別:
主節點在收到客戶端的請求後,必須在完成本節點日誌寫入的同時,還需要等待至少一個從節點完成資料同步的響應之後(或超時),才會響應請求。
從節點只有在寫入relay-log並完成刷盤之後,才會向主節點響應。
當從節點響應超時時,主節點會將同步機制退化為非同步複製。在至少一個從節點恢復,並完成資料追趕後,主節點會將同步機制恢復為半同步複製。
可以看出,相比於非同步複製,半同步複製在一定程度上提高了資料的可用性,在未退化至非同步複製時,如果主節點當機,此時資料已複製至至少一臺從節點。
同時,由於向客戶端響應時需要從節點完成響應,相比於非同步複製,此時多出了主從節點上網路互動的耗時以及從節點寫檔案並刷盤的耗時,因此整體上叢集對於客戶端的響應效能表現必然有所降低。
主從複製格式
由於MySQL的複製機制是基於binlog的,因此binlog的格式就決定了主從複製的格式。binlog有基於行的和基於語句兩種,從而複製也有兩種對應的格式。
Statement-Based Replication(SBR)
對於基於語句的複製機制,binlog僅記錄所執行的語句。這種方式,有如下優點:
- 自從3.23版本就存在,經過長期驗證的成熟技術
- 寫入日誌檔案的資料更少,這意味著更少的檔案寫入和網路傳輸消耗,從而整體上可以更快的完成主從複製,提升效能表現。
- 日誌檔案記錄了所有資料庫上執行的語句,可以用來進行審計等用途
有如下缺點:
- 使用者自定義函式(UDF)以及執行結果不確定的函式無法進行復制
- 進行資料更新時,需要比基於行的複製更多的行鎖
- 對於如先插入後更新式的複雜語句,從節點需要進行完全的對應重放,而基於行格式的複製只需要執行最終結果即可
Row-Based Replication(RBR)
基於行的複製機制下,對應binlog也是基於行的,這時每次資料更新當寫入binlog時,都被轉化所有受影響行的變化。
這種複製方式,有如下優點:
- 所有資料變化都可以被安全的複製,不會受到UDF以及特殊函式的影響。
- 大部分DBMS都採用這種複製方式,知識遷移成本低。
- 進行資料更新時,所需要的行鎖更少,從而可以獲取更高的效能表現。
有如下缺點:
- 在涉及大資料量的DML時,基於行的日誌將會產生大量的日誌資料,大資料量在日誌檔案寫入、網路傳輸方面都意味著更長的時間,從而可能導致整體效能表現顯著變差,同時也可能導致併發問題。
- 無法通過日誌檢視所執行的語句,同時也無法獲知從節點上執行的語句。
在實際的架構應用中,需要根據系統的業務特點合理利用主從複製機制,並選擇合適主從複製格式。
關注“程式設計師順仔和他的朋友們”,幫你掌握更多架構知識~