mysql主從複製原理及實踐

Mysql主從複製原理及實踐

mysql主從框架

      MySQL主從架構是MySQL集羣中最基本也是最經常使用的一種架構部署，可以知足不少業務需求，常見的有一主一從或者一主多從。能夠防止單一主機的數據丟失，提升數據的安全性，務上能夠實現讀寫分離，能夠把一些讀操做在從服務器上執行，減少主服務器的負擔。

主從複製原理

      mysql主從複製是指數據能夠從一個mysql服務器節點複製到一臺或者多臺mysql服務器上，多個從服務器採用異步的方式更新主數據庫的變化。MySQL主從同步是基於從庫對主庫binlog文件的增量訂閱來實現,更新的事件類型寫入到主庫的binlog文件中，日誌用於記錄全部更新了數據或者已經潛在更新了數據的全部語句，以「事件」的形式保存，它描述數據更改，它是以二進制的形式保存在磁盤中。以.000001的方式結尾，binlog文件大小和數字會不斷增長，當mysql重啓時，數字會不斷遞增。

                                                                                           主從複製的原理圖：

                                      

---

    對於每個主從鏈接，都須要三個進程來完成，master（binlog dump thread）、slave（I/O thread 、SQL thread）。

• 主節點會爲每個當前鏈接的從節點建一個binary log dump 進程
• 從節點上執行start slave命令以後，從節點會建立一個I/O線程用來鏈接主節點，請求主庫中更新的bin-log。I/O線程接收到主節點binlog dump 進程發來的更新以後，保存在本地relay-log中。
• SQL線程負責讀取relay log中的內容，解析成具體的操做並執行，最終保證主從數據的一致性。整個同步操做是異步執行的。

下面講下在linux系統下實現主從同步的相關操做步驟：

主庫配置

• 開啓master的binglog日誌，
• 建立惟一的server_id，
• 指定要同步的數據庫和和不須要同步的數據庫

一、編輯my.cnf文件

vi /etc/my.cnf

二、添加配置：

log-bin=master-bin
server-id=1
#須要同步的數據庫
binlog-do-db=shoes
#不須要同步的mysql系統數據庫
binlog-ignore-db=mysql

三、授予從庫replication權限

grant replication slave on *.* to 'root'@'192.168.48.133' identified by '123456';

   這裏的ip地址和用戶密碼都是從庫的，若是提示：Your password does not satisfy the current policy requirements 說明你的密碼是不安全的，此時須要設置密碼的校驗級別，可自行百度。
設置完畢後，重啓master的mysql服務。

使用命令: mysql -uroot -p 登陸mysql服務後，執行 show master status；

會出現相似如圖所示的信息：

記錄下File和Position的值，後面從庫配置的時候須要使用。
好了，到這裏主庫配置完畢，接下來是從庫的配置。

一樣修改my.cnf文件，添加以下信息：

server-id=2 
log-bin=mysql-bin 
replicate-do-db=shoes
replicate-ignore-db=mysql

配置鏈接主服務器的信息：

mysql> CHANGE MASTER TO
-> MASTER_HOST='192.168.48.128',
-> MASTER_USER='root',
-> MASTER_PASSWORD='123456',
-> MASTER_LOG_FILE='mysql-bin.000002',
-> MASTER_LOG_POS=7641;
mysql> start slave;

這裏的 MASTER_LOG_POS 是要告訴slave庫從master二進制日誌的哪一個地方開始複製，也就是前文查看主庫狀態的Position的值。

而後查看slave的狀態：

mysql>show slave status\G

會出現如圖所示的信息：

   當出現Slave_IO_Running和Slave_SQL_Running都是yes,而且Slave_IO_State是：Waiting for master to send event的時候，說明配置是成功的。若是是Connecting to.......說明沒連上，這時候要檢查下ip地址、帳號或者防火牆等問題了。

在複製的過程當中，因爲一些其餘不當的操做，可能會遇到如圖所示相似的問題，

   這種狀況好比說我在從庫上把數據刪掉了，而後主庫又進行刪除，此時找不到從庫上對應的記錄就會報錯，當發生這樣的錯誤以後，從庫就沒法更新主庫的數據了。若是主庫都已經刪除了，那麼從庫也就沒有必要保留了，這種狀況的話能夠設置從庫複製的時候跳過當前這個事件，須要暫停slave操做:

stop slave;
set global sql_slave_skip_counter=1;
start slave;

   相似的問題還有好比說重複插入，更新丟失，relay log 損壞等，均可以採起相應的策略來恢復，如從新選擇到同步的binlog和POS點，而後從新作同步等。

binlog日誌文示例
使用命令

mysql> show binlog events in 'mysql-bin.000002;
查看binlog日誌。

binlog的日誌格式

mysql的binlog格式分爲三種：

Statement
      每一條會修改數據的 SQL 都會記錄到 master 的 bin-log 中。slave 在複製的時候 SQL 進程會解析成和原來 master 端執行過的相同的 SQL 再次執行。

優勢：不須要記錄每一行的變化，減小了binlog日誌量，節約了IO，提升性能。

缺點：因爲記錄的只是執行語句，爲了這些語句能在slave上正確運行，所以還必須記錄每條語句在執行的時候的一些相關信息，以保證全部語句能在slave獲得和在master端執行時候相同的結果。另外mysql 的複製,像一些特定函數功能，slave可與master上要保持一致會有不少相關問題

row
   日誌中會記錄成每一行數據被修改的形式，而後在 slave 端再對相同的數據進行修改。

優勢：Binnary Log能夠不記錄執行的Query語句的上下文相關信息，不會出現某些特定狀況下存儲過程或function，以及trigger的調用和觸發器沒法被正確複製的問題。
缺點：若是批量修改數據，記錄的不是批量修改的SQL語句事件，而是每條記錄被更改的SQL語句，好比說update語句，會記錄每一行被修改的sql語句，當alter表的時候，更是會產生大量的日誌。

Mixedlevel
      以上兩種的結合體，MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日誌形式，也就是在Statement和Row之間選擇一種.新版本的MySQL中隊row level模式也被作了優化，並非全部的修改都會以row level來記錄，像遇到表結構變動的時候就會以statement模式來記錄。
所以，企業生產上使用哪一種弄場景能夠根據具體的場景來選擇合適的格式。
查看binlog格式使用命令：

mysql> show global variables like "%binlog_format%";
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+

格式能夠在my.cnf文件中進行配置：

binlog_format="ROW"

或者在運行時動態的修改格式：

mysql> SET SESSION binlog_format = 'STATEMENT';

   經過mysql複製能夠將讀操做分佈在多個服務器上，實現對密集型應用的優化，經過簡單的代碼修改就能夠實現基本的負載均衡，而且可以幫助應用程序避免mysql的單點故障，實現mysql的高可用性。