看完這篇還不懂 MySQL 主從複製，可以回家躺平了～

大家好，我是小羽。

我們在平時工作中，使用最多的資料庫就是 MySQL 了，隨著業務的增加，如果單單靠一台伺服器的話，負載過重，就容易造成宕機。

這樣我們保存在 MySQL 資料庫的數據就會丟失，那麼該怎麼解決呢？

其實在 MySQL 本身就自帶有一個主從複製的功能，可以幫助我們實現負載均衡和讀寫分離。

對於主伺服器（Master）來說，主要負責寫，從伺服器（Slave）主要負責讀，這樣的話，就會大大減輕壓力，從而提高效率。

接下來，跟著小羽一起來看看它都有哪些核心知識點呢：

簡介

隨著業務的增長，一台數據伺服器已經滿足不了需求了，負載過重。這個時候就需要減壓了，實現負載均衡讀寫分離，一主一叢或一主多從。

主伺服器只負責寫，而從伺服器只負責讀，從而提高了效率減輕壓力。

主從複製可以分為：

  • 主從同步：當用戶寫數據主伺服器必須和從伺服器同步了才告訴用戶寫入成功，等待時間比較長。

  • 主從非同步：只要用戶訪問寫數據主伺服器，立即返回給用戶。

  • 主從半同步：當用戶訪問寫數據主伺服器寫入並同步其中一個從伺服器就返回給用戶成功。

形式

一主一從

圖片

一主一從

一主多從

圖片

一主多從

一主一從和一主多從是我們現在見的最多的主從架構，使用起來簡單有效，不僅可以實現 HA，而且還能讀寫分離，進而提升集群的並發能力。

多主一從

圖片

多主一從

多主一從可以將多個 MySQL 資料庫備份到一台存儲性能比較好的伺服器上。

雙主複製

圖片

雙主複製

雙主複製，也就是可以互做主從複製，每個 master 既是 master，又是另外一台伺服器的 salve。這樣任何一方所做的變更，都會通過複製應用到另外一方的資料庫中。

級聯複製

圖片

級聯複製

級聯複製模式下，部分 slave 的數據同步不連接主節點，而是連接從節點。

因為如果主節點有太多的從節點，就會損耗一部分性能用於 replication ，那麼我們可以讓 3~5 個從節點連接主節點，其它從節點作為二級或者三級與從節點連接，這樣不僅可以緩解主節點的壓力，並且對數據一致性沒有負面影響。

原理

MySQL 主從複製是基於主伺服器在二進位日誌跟蹤所有對資料庫的更改。因此，要進行複製，必須在主伺服器上啟用二進位日誌。

每個從伺服器從主伺服器接收已經記錄到日誌的數據。當一個從伺服器連接到主伺服器時，它通知主伺服器從伺服器日誌中讀取最後一個更新成功的位置。

從伺服器接收從那時發生起的任何更新，並在主機上執行相同的更新。然後封鎖等待主伺服器通知的更新。

從伺服器執行備份不會干擾主伺服器，在備份過程中主伺服器可以繼續處理更新。

過程

工作過程

MySQL 的主從複製工作過程大致如下：

  1. 從庫生成兩個執行緒，一個 I/O 執行緒，一個 SQL 執行緒；

  2. I/O 執行緒去請求主庫的 binlog，並將得到的 binlog 日誌寫到 relay log(中繼日誌) 文件中；

  3. 主庫會生成一個 log dump 執行緒，用來給從庫 I/O 執行緒傳 binlog；

  4. SQL 執行緒會讀取 relay log 文件中的日誌，並解析成具體操作，來實現主從的操作一致，而最終數據一致；

圖片

工作過程

請求流程

MySQL 建立請求的主從的詳細流程如下：

  1. 當從伺服器連接主伺服器時，主伺服器會創建一個 log dump 執行緒，用於發送 binlog 的內容。在讀取 binlog 的內容的操作中，會對象主節點上的 binlog 加鎖，當讀取完成並發送給從伺服器後解鎖。

  2. 當從節點上執行 start slave 命令之後，從節點會創建一個 IO 執行緒用來連接主節點，請求主庫中更新 binlog。IO 執行緒接收主節點 binlog dump 進程發來的更新之後，保存到 relay-log 中。

  3. 從節點 SQL 執行緒負責讀取 realy-log 中的內容，解析成具體的操作執行，最終保證主從數據的一致性。

類型

非同步複製

一個主庫，一個或多個從庫，數據非同步同步到從庫。

圖片

非同步複製

這種模式下，主節點不會主動推送數據到從節點，主庫在執行完客戶端提交的事務後會立即將結果返給給客戶端，並不關心從庫是否已經接收並處理。

這樣就會有一個問題，主節點如果崩潰掉了，此時主節點上已經提交的事務可能並沒有傳到從節點上，如果此時，強行將從提升為主，可能導致新主節點上的數據不完整。

同步複製

在 MySQL cluster 中特有的複製方式。

當主庫執行完一個事務，然後所有的從庫都複製了該事務並成功執行完才返回成功資訊給客戶端。

因為需要等待所有從庫執行完該事務才能返回成功資訊，所以全同步複製的性能必然會收到嚴重的影響。

半同步複製

在非同步複製的基礎上，確保任何一個主庫上的事物在提交之前至少有一個從庫已經收到該事物並日誌記錄下來。

圖片

半同步複製

介於非同步複製和全同步複製之間，主庫在執行完客戶端提交的事務後不是立刻返回給客戶端，而是等待至少一個從庫接收到並寫到 relay log 中才返回成功資訊給客戶端(只能保證主庫的 Binlog 至少傳輸到了一個從節點上)，否則需要等待直到超時時間然後切換成非同步模式再提交。

相對於非同步複製，半同步複製提高了數據的安全性，一定程度的保證了數據能成功備份到從庫，同時它也造成了一定程度的延遲，但是比全同步模式延遲要低，這個延遲最少是一個 TCP/IP 往返的時間。所以，半同步複製最好在低延時的網路中使用。

半同步模式不是 MySQL 內置的，從 MySQL 5.5 開始集成，需要 master 和 slave 安裝插件開啟半同步模式。

延遲複製

在非同步複製的基礎上，人為設定主庫和從庫的數據同步延遲時間，即保證數據延遲至少是這個參數。

方式

MySQL 主從複製支援兩種不同的日誌格式，這兩種日誌格式也對應了各自的複製方式。當然也有二者相結合的混合類型複製。

語句複製

基於語句的複製相當於邏輯複製，即二進位日誌中記錄了操作的語句，通過這些語句在從資料庫中重放來實現複製。

這種方式簡單，二進位文件小，傳輸頻寬佔用小。但是基於語句更新依賴於其它因素，比如插入數據時利用了時間戳。

因此在開發當中，我們應該盡量將業務邏輯邏輯放在程式碼層，而不應該放在 MySQL 中，不易拓展。

特點：

  • 傳輸效率高，減少延遲。

  • 在從庫更新不存在的記錄時，語句賦值不會失敗。而行複製會導致失敗，從而更早發現主從之間的不一致。

  • 設表裡有一百萬條數據，一條sql更新了所有表，基於語句的複製僅需要發送一條sql，而基於行的複製需要發送一百萬條更新記錄

行數據複製

基於行的複製相當於物理複製，即二進位日誌中記錄的實際更新數據的每一行。

這樣導致複製的壓力比較大，日誌佔用的空間大，傳輸頻寬佔用大。但是這種方式比基於語句的複製要更加精確。

特點：

  • 不需要執行查詢計劃。

  • 不知道執行的到底是什麼語句。

  • 例如一條更新用戶總積分的語句，需要統計用戶的所有積分再寫入用戶表。如果是基於語句複製的話，從庫需要再一次統計用戶的積分，而基於行複製就直接更新記錄，無需再統計用戶積分。

混合類型的複製

一般情況下，默認採用基於語句的複製，一旦發現基於語句無法精確複製時，就會採用基於行的複製。

配置

配置主要要點如下：

# 如果在雙主複製結構中沒有設置ID的話就會導致循環同步問題
server_id=1

# 即日誌中記錄的是語句還是行更新或者是混合
binlog_format=mixed

# 在進行n次事務提交以後，Mysql將執行一次fsync的磁碟同步指令。將緩衝區數據刷新到磁碟。
# 為0的話由Mysql自己控制頻率。
sync_binlog=n

# 為0的話，log buffer將每秒一次地寫入log file中並且刷新到磁碟。
# mysqld進程崩潰會丟失一秒內的所有事務。
# 為1的話，每次事務log buffer會寫入log file並刷新到磁碟。（較為安全）
# 在崩潰的時候,僅會丟失一個事務。
# 為2的話，每次事務log buffer會寫入log file，但一秒一次刷新到磁碟
innodb_flush_logs_at_trx_commit=0

# 阻止從庫崩潰後自動啟動複製，給一些時間來修復可能的問題，
# 崩潰後再自動複製可能會導致更多的問題。並且本身就是不一致的
skip_slave_start=1 

# 是否將從庫同步的事件也記錄到從庫自身的bin-log中
# 允許備庫將重放的事件也記錄到自身的二進位日誌中去，可以將備庫當做另外一台主庫的從庫
log_slave_update 

# 日誌過期刪除時間，延遲嚴重的話會導致日誌文件佔用磁碟
expire_logs_days=7

問題

延遲

當主庫的 TPS 並發較高的時候，由於主庫上面是多執行緒寫入的，而從庫的SQL執行緒是單執行緒的，導致從庫SQL可能會跟不上主庫的處理速度。

解決方法：

  • 網路方面：盡量保證主庫和從庫之間的網路穩定，延遲較小；

  • 硬體方面：從庫配置更好的硬體，提升隨機寫的性能；

  • 配置方面：盡量使 MySQL 的操作在記憶體中完成，減少磁碟操作。或升級 MySQL5.7 版本使用並行複製；

  • 建構方面：在事務中盡量對主庫讀寫，其它非事務的讀在從庫。消除一部分延遲帶來的資料庫不一致。增加快取降低一些從庫的負載。

數據丟失

當主庫宕機後，數據可能丟失。

解決方法：

使用半同步複製，可以解決數據丟失的問題。

注意事項

MySQL 需要注意以下事項：

  • MySQL 主從複製是 MySQL 高可用性，高性能（負載均衡）的基礎；

  • 簡單，靈活，部署方式多樣，可以根據不同業務場景部署不同複製結構；

  • 複製過程中應該時刻監控複製狀態，複製出錯或延時可能給系統造成影響；

  • MySQL 主從複製目前也存在一些問題，可以根據需要部署複製增強功能。

作用

主從複製帶來了很多好處，當我們的主伺服器出現問題，可以切換到從伺服器；可以進行資料庫層面的讀寫分離；可以在從資料庫上進行日常備份。還可以保證：

  1. 數據更安全：做了數據冗餘，不會因為單台伺服器的宕機而丟失數據；

  2. 性能大大提升：一主多從，不同用戶從不同資料庫讀取，性能提升；

  3. 擴展性更優：流量增大時，可以方便的增加從伺服器，不影響系統使用；

  4. 負載均衡：一主多從相當於分擔了主機任務，做了負載均衡。

應用場景

MySQL 主從複製集群功能使得 MySQL 資料庫支援大規模高並發讀寫成為可能，同時有效地保護了物理伺服器宕機場景的數據備份。

橫向擴展

將工作負載分發到各 Slave 節點上，從而提高系統性能。

在這個場景下，所有的寫(write)和更新(update)操作都在 Master 節點上完成；所有的讀( read)操作都在 Slave 節點上完成。通過增加更多的 Slave 節點，便能提高系統的讀取速度。

數據安全

數據從 Master 節點複製到 Slave 節點上，在 Slave 節點上可以暫停複製進程。可以在 Slave 節點上備份與 Master 節點對應的數據，而不用影響 Master 節點的運行。

數據分析

實時數據可以在 Master 節點上創建，而分析這些數據可以在 Slave 節點上進行，並且不會對 Master 節點的性能產生影響。

遠距離數據分布

可以利用複製在遠程主機上創建一份本地數據的副本，而不用持久的與Master節點連接。

拆分訪問

可以把幾個不同的從伺服器，根據公司的業務進行拆分。通過拆分可以幫助減輕主伺服器的壓力，還可以使資料庫對外部用戶瀏覽、內部用戶業務處理及 DBA 人員的備份等互不影響。

Tags:

VirMach 便宜 VPS

QNews

QNews