天天看點

MySQL 主從複制原理引言 MySQL 主從複制介紹 MySQL Replication 複制過程

引言

MySQL 主從複制原理是相當基礎的知識,很久沒有接觸過 MySQL 主從複制了,因為我這邊負責的業務暫時沒用使用 MySQL 主從複制。

既然有些忘記了,現在我重新複習記錄下。

MySQL 主從複制介紹

 MySQL 的主從複制是一個異步的複制過程(但一般情況下感覺是實時同步的),

資料庫資料從一個 MySQL 資料庫(我們稱之為 Master)複制到另一個 MySQL 資料庫(我們稱之為 Slave)。

在 Master 與 Slave 之間實作整個主從複制的過程是由三個線程參與完成的。

其中有兩個線程(SQL 線程和 IO 線程)在 Slave 端,另外一個線程(IO 線程)在 Master 端。(來自 MySQL 幫助文檔)

MySQL 主從複制原理引言 MySQL 主從複制介紹 MySQL Replication 複制過程

MySQL Replication 複制過程

  1. Slave 伺服器上執行

    start slave

    ,開啟主從複制開關。
  2. 此時,Slave 伺服器上的 IO 線程會通過 Master 伺服器上授權的有複制權限的使用者請求連接配接 Master 伺服器,

    并請求從指定 binlog 日志檔案的指定位置之後發送 binlog 日志内容。

    (日志檔案名和位置就是在配置主從複制任務時執行

    change master

    指令時指定的)
  3. Master 伺服器接收到來自 Slave 伺服器的 IO 線程的請求後,

    Master 伺服器上的 IO 線程根據 Slave 伺服器的 IO 線程請求的資訊,

    讀取指定 binlog 日志檔案指定位置之後的 binlog 日志資訊,然後傳回給 Slave 端的 IO 線程。

    傳回的資訊中除了 binlog 日志内容外,

    還有本次傳回日志内容後在 Master 伺服器端的新的 binlog 檔案名以及在 binlog 中的下一個指定更新位置。

  4. 當 Slave 伺服器的 IO 線程擷取來自 Master 伺服器上 IO 線程發送的日志内容及日志檔案和位置點後,

    将 binlog 日志内容依次寫入到 Slave 端自身的 relay log(即中繼日志)檔案(mysql-relay-bin.xxxxxx)的最末端,

    并将新的 binlog 檔案名和位置記錄到 

    master-info

     檔案中,

    以便下一次讀取 Master 端新 binlog 日志時,

    能告訴 Master 伺服器需要從新 binlog 日志的哪個檔案哪個位置開始請求新的 binlog 日志内容。

  5. Slave 伺服器端的 SQL 線程會實時檢測本地 relay log 中新增加的日志内容,

    然後及時的把 relay log 檔案中的内容解析成在 Master 端曾經執行的 SQL 語句的内容,

    并在自身 Slave 伺服器上按語句的順序執行應用這些 SQL 語句,應用完畢後清理應用過的日志。

  6. 經過了上面的過程,就可以確定在 Master 端和 Slave 端執行了同樣的 SQL 語句。

    當複制狀态正常的情況下,Master 端和 Slave 端的資料是完全一樣的。

MySQL 主從複制原理引言 MySQL 主從複制介紹 MySQL Replication 複制過程

用途及條件

mysql主從複制用途

  • 實時災備,用于故障切換
  • 讀寫分離,提供查詢服務
  • 備份,避免影響業務

主從部署必要條件:

  • 主庫開啟binlog日志(設定log-bin參數)
  • 主從server-id不同
  • 從庫伺服器能連通主庫

總結

主從形式

  • 一主一從
  • 一主多從--擴充系統讀取性能
  • 多主一從--5.7開始支援
  • 主主複制
  • 聯級複制
  • 用途:實時災備的故障切換,讀寫分離,備份
  • 原理
    • 主:log dump線程傳binlog;
      • i/o線程接受讀取binlog,并寫入relay log檔案
      • sql線程從relay log 檔案中讀取binlog并持久化
  • 問題及解決
    • 主庫當機後,資料丢失
      • 半同步複制
    • 主庫寫壓力大,因從庫隻有一個sql 線程來持久化,複制可能延遲
      • 并行複制
  • 半同步複制:
    • 原理
      • 事務在主庫寫完binlog後需要從庫傳回一個已接受,才放回給用戶端;
    • 5.5內建到mysql,以插件的形式存在,需要單獨安裝
    • 確定事務送出後binlog至少傳輸到一個從庫
    • 不保證從庫應用完成這個事務的binlog
    • 性能有一定的降低
    • 網絡異常或從庫當機,卡主庫,直到逾時或從庫恢複
  • 并行複制
    • 原理:從庫多線程apply binlog
    • 在社群5.6中新增
    • 庫級别并行應用binlog,同一個庫資料更改還是串行的
    • 5.7版本并行複制基于事務組
  • 部分資料複制
  • 聯級複制(常用)
    • A->B->C
    • B中添加參數log_slave_updates
    • B将把A的binlog記錄到自己的binlog日志中
  • 複制的監控
    • show slave status
  • 複制出錯處理
    • 常見:1062(主鍵沖突),1032(記錄不存在)
    • 解決:
      • 手動處理
      • 跳過複制錯誤:set global sql_slave_skip_counter=1
  • mysql主從複制是mysql高可用性,高性能(負載均衡)的基礎
  • 簡單,靈活,部署方式多樣,可以根據不同業務場景部署不同複制結構
  • 複制過程中應該時刻監控複制狀态,複制出錯或延時可能給系統造成影響
  • mysql主從複制目前也存在一些問題,可以根據需要部署複制增強功能

繼續閱讀