MySQL 的主從複制

文章目錄

• 1. MySQL 主從複制
• • • 1.1 複制的主要用途
    • 1.2 主從複制的流程
    • 1.3 從伺服器的并行複制
• 2. 主從複制存在的問題
• • 2.1 資料丢失
  • 2.2 主從延遲
  • • 2.2.1 原因
    • 2.2.2 應對方案
    • • 2.2.2.1 治标
      • 2.2.2.2 治本
• 3. binlog 的三種模式
• • • 3.1 Statement 模式
    • 3.2 Row 模式
    • 3.3 Mixed 模式

1. MySQL 主從複制

MySQL 主從複制是指資料可以從一個 MySQL 主伺服器複制到一個或多個從伺服器，這樣 MySQL 的資料就可以分布到多個伺服器上，提高了整個系統的可用性

1.1 複制的主要用途

1. 資料分布

   MySQL 資料庫的複制功能對網絡帶寬要求不高，是以可以在不同的資料中心直接很友善地實作資料的複制

2. 讀操作的負載均衡

   将讀寫操作分離開，主伺服器負責寫操作，從伺服器負責讀操作。通過部署多個從伺服器，可以将讀操作平均地分布到各個從伺服器上，進而提高了讀操作性能，減小了主伺服器壓力

3. 資料備份

   複制是資料備份的一個補充，它允許從庫資料實時地跟随主庫資料變化，比備份更靈活但不能完全替代備份

4. 高可用性與故障切換

   複制可以幫助 MySQL 避免單點問題，通過複制建立的從伺服器可以用于故障轉移，減少故障時的停機時間和恢複時間

1.2 主從複制的流程

MySQL 主從複制預設采用異步複制方式，其大緻流程如下：

1. 從庫連接配接上主庫，主庫會為每個從庫的 IO 線程啟動一個 dump 線程與其建立連接配接
2. 從庫 IO 線程發送拉取 binlog 的請求，則主庫 dump 線程會讀取本地 binlog ，将其以 events 的方式發給從庫 IO 線程
3. 從庫 IO 線程接收 binlog events，将其存放到本地中繼日志（relay log） 中
4. 從庫 SQL 線程解析重放 relay log 将主庫的資料更新應用到本地，最終達成資料一緻性

1.3 從伺服器的并行複制

并行複制主要是指從服務将 binlog 寫入到本地

relay log

中繼日志之後，啟動多線程并行重放中繼日志完成資料的同步。并行複制主要是為了解決主從延遲的問題，其實作有兩種模式：

1. 基于資料庫

   如果 3 條語句是在3個資料庫執行，操作各自的資料庫，肯定不會産生并發的問題，并且執行的順序也沒有要求。是以如果是操作 3 個資料庫，這 3 個資料庫的從庫資料更新就可以使用多個線程并行重放中繼日志，但是同一個庫資料更改還是串行的。這是 MySQL 5.6 版本裡面支援的多庫并行複制

2. 基于事務組

   資料庫本身是支援多個事務同時操作的，這些事務在主庫上面可以并行執行，是因為他們本身就是互相不幹擾的。比如在主庫上有 3 個事務同時分别操作 3 張表，不存在資源的競争和資料的幹擾，那這 3 個事務在從庫上面也可以并行執行。是以可以把那些在主庫上并行執行的事務分為一個組，并且給它們編号， 在一個組内的事務可以在從庫上使用多線程并行重放。這個編号叫做

   GTID(Global Transaction Identifiers)

   ，這種主從複制的方式叫做基于 GTID 的複制

2. 主從複制存在的問題

2.1 資料丢失

主庫如果當機，binlog 還沒有傳輸到從庫上則可能發生資料丢失，一種解決方法是半同步複制

半同步複制

在 5.5 版本內建，以插件的形式存在，需要單獨安裝。其主要工作原理是確定事務完成前 binlog 至少傳輸到一個從庫，但是不保證從庫重放執行完這個事務

• 缺點

  1. 性能有一定的降低，響應時間會更長

  2. 網絡異常或從庫當機時會卡住主庫，直到逾時或從庫恢複

2.2 主從延遲

主從延遲主要表現為資料已經在主庫中寫入了，但是因為某些原因從庫還沒有同步這些資料到本地，這樣就産生了主庫和從庫資料的不一緻

2.2.1 原因

1. 主庫寫繁忙

   主庫會将所有修改資料的操作（包括插入更新删除及表結構變更）寫進binlog，由于 binlog 是順序寫，是以效率很高。但是從庫首先要通過網絡 IO 擷取到 binglog，之後 SQL 線程将主庫的操作事件在本地重放（也就是寫資料）是随機 IO 的，效率要低很多，這就為延遲的産生埋下了伏筆。當主庫的并發較高時，産生 binlog 的速度一旦超過從庫的 SQL 線程所能處理的極限，延遲就不可避免了

2. 從庫讀繁忙

   從庫一般負責處理讀操作，而大部分服務都是讀多寫少的，資料庫主要壓力恰恰在于讀操作。一旦有大型查詢語句産生了鎖等待，那麼從庫可能就無法及時将中繼日志記錄的資料變動應用到本地，進而産生延遲

2.2.2 應對方案

2.2.2.1 治标

1. 單個庫讀寫分離，主寫從讀，一主多從，這樣分攤一個從庫的壓力，可以降低主從延遲
2. 更改優化資料庫配置，提升從庫資料庫伺服器的硬體配置。使用比主庫硬體配置更好的伺服器作為從庫，有助于減小 MySQL 壓力，延遲自然會變小
3. 更新 MySQL 版本到 5.7 及以上，高版本中已經加入了并行複制功能，可以加快重放中繼日志的效率，提高資料的同步速度
4. 對大表進行表結構變更或者刷資料時，選擇在淩晨 3 點等業務低峰期執行，也可以分批執行，執行完一批就 sleep 一會

2.2.2.2 治本

1. 在服務的業務和 MySQL 之間加入緩存層，降低資料庫的讀壓力
2. 任何伺服器都有吞吐量限制，是以必須估算好伺服器能夠承載的流量上限，達到這個上限時做好限流
3. 主從延遲大部分時候是從庫寫資料不及時引起的，那也可以在有主從延遲的地方改變讀庫方式，從原來的讀從庫改為讀主庫，代價則是增加代碼邏輯複雜性

3. binlog 的三種模式

3.1 Statement 模式

這是基于語句的模式，記錄的内容是造成了資料更改的 SQL 語句。這種模式下，當從庫讀取并重放中繼日志時，實際上是把主庫執行過的 SQL 重新執行一遍

• 優點

  不需要記錄每一行的資料變化，減少了 binlog 的日志量，節省了 IO 以及存儲資源，相對也就提高了性能

• 缺點

  由于記錄的是主庫執行的 SQL 語句，是以為了保證這些語句在從庫也能正确執行，必須額外記錄每條語句執行時的上下文資訊（例如同一條語句在從庫和主庫上的執行時間不太可能相同，這就需要儲存一些時間戳之類的元資訊），以保證 SQL 語句在從庫的執行結果和在主庫相同

3.2 Row 模式

基于資料行的模式，記錄的内容是在主庫上發生了變化的資料行的變更記錄。在這種模式下，從庫隻需要把主庫最新的資料行更新到本地即可完成資料的同步

• 優點

  記錄下每一行資料的變更，可以非常清楚地知道每一行資料的修改細節，正确地複制每一行

• 缺點

  資料行但凡有變動就将生成行的修改記錄，如果修改的資料行比較多那麼日志量也會很龐大，會給主庫生成日志造成額外負擔，同時也會在傳輸時占用更多的 IO 資源

3.3 Mixed 模式

預設采用基于語句的複制，不過一旦發現基于語句無法精确複制時，就會采用基于行的複制。也就是說 MySQL 會動态切換政策，一般有表結構的變更時采用 Statement 模式記錄 binlog，其他插入更新删除的語句則使用 Row 模式