mysql主從複製系列（2）——主從複製原理概述

前言

先來談談Mysql集羣的可行方案

MySQL Cluster 

由Mysql自己提供，優點：可用性很是高，性能很是好。每份數據至少可在不一樣主機 存一份拷貝，且冗餘數據拷貝實時同步。但它的維護很是複雜，存在部分Bug，目前還不 適合比較核心的線上系統，因此不推薦。

DRBD磁盤網絡鏡像方案 

Distributed Replicated Block Device，其實現方式是經過網絡來鏡像整個設備(磁盤). 它容許用戶在遠程機器上創建一個本地塊設備的實時鏡像,與心跳連接結合使用, 也可看作一種網絡RAID。 

優點：軟件功能強大，數據可在底層快設備級別跨物理主機鏡像，且可根據性能和可 靠性要求配置不一樣級別的同步。IO操做保持順序，可知足數據庫對數據一致性的苛刻要求 。但非分佈式文件系統環境沒法支持鏡像數據同時可見，性能和可靠性二者相互矛盾，無 法適用於性能和可靠性要求都比較苛刻的環境，維護成本高於MySQL Replication。另外，DRBD也是官方推薦的可用於MySQL 高可用方案之一，因此這個你們可根據實際環境來考慮是否部署。 

MySQL Replication 

今天的主題，在實際應用場景中，MySQL Replication是使用最爲普遍的一種提升系統擴展性的設計手段。衆多的MySQL使用者經過 Replication功能提高系統的擴展性後，經過簡單的增長價格低廉的硬件設備成倍 甚至成數量級地提升了原有系統的性能。

主從複製原理概述 

( 1 )首先, MySQL主庫在事務提交時會把數據變動做爲事件 Events 記錄在二進制日誌文件Binlog中; MySQL主庫上的 sync_binlog參數控制 Binlog日誌刷新到磁盤。

 ( 2 )主庫推送二進制日誌文件 Binlog中的事件到從庫的中繼日誌 Relay Log, 以後從庫根據中繼日誌 Relay Log重作數據變動操做, 經過邏輯複製以此來達到主庫和從庫的數據一致。

3個線程 

MySQL經過3個線程來完成主從庫間的數據複製:

Binlog Dump線程跑在主庫上 

I/0線程和 SQL線程跑在從庫上

當在從庫上啓動複製時,首先建立I/0程鏈接主庫, 主庫隨後建立 Binlog Dump線程讀取數據庫事件併發送給 I/0線程, I0線程獲取到事件數據後更新到從庫的中繼日誌 Relay Log中去,以後從庫上的 SQL線程讀取中繼日誌RelayLog中更新的數據庫事件並應用。 

SHOW PROCESSLIST命令

經過 SHOW PROCESSLIST命令在主庫上查看BinlogDump線程

從 BinlogDump 線程的狀態能夠看到, Mysql的複製是主庫主動推送日誌到從庫去的,是屬於「推」日誌的方式來作同步。

經過 SHOW PROCESSLIST能夠在從庫上查看l/O線程和 SQL線程

l/O線程(Id=5)等待主庫上的 Binlog Dump線程發送事件並更新到中繼日誌 RelayLog

SQL線程(Id=6)讀取中繼日誌並應用變動到數據庫

二進制日誌文件 Binlog三種格式(複製方式)

Statement:基於 SQL語句級別的 Binlog,每條修改數據的 SQL都會保存到 Binlog裏。 

Row:基於行級別,記錄每一行數據的變化,也就是將每行數據的變化都記錄到 Binlog 裏面, 記錄得很是詳細, 可是並不記錄原始 SQL; 在複製的時候, 並不會由於存儲過程或觸發器形成主從庫數據不一致的問通, 可是記錄的日誌量較 Statement格式要大得多 。 

Mixed:混合Statement和Row模式,默認狀況下采用 Statement模式記錄, 某些狀況下會切換到 Row模式 同時也對應了 MysQL複製的3種技術。

查看當前複製方式  

show variables like '%binlog%format%'; 複製代碼

更改複製方式 

set global binlog_format = 'ROW'; 
set global binlog_format = 'STATEMENT'; 複製代碼