MySQL Replication 梳理詳解

MySQL Replication

1 MySQL5.5之前的複製

異步、SQL線程串行化回放

MySQL內建的複製功能是構建大型，高性能應用程序的基礎。主服務器將更新寫入二進制日誌文件，從服務器從新執行一遍來實現的

1.1 MySQL支持的複製類型　　

1. 基於語句的複製： 

在主服務器上執行的SQL語句，在從服務器上執行一樣的語句。MySQL默認採用基於語句的複製，效率比較高。 

MySQL 5.0及以前的版本僅支持基於語句的複製（也叫作邏輯複製，logical replication），這在數據庫並不常見。master記錄下改變數據的查詢，而後，slave從中繼日誌中讀取事件，並執行它，這些SQL語句與master執行的語句同樣。

這種方式的優勢就是實現簡單。此外，基於語句的複製的二進制日誌能夠很好的進行壓縮，並且日誌的數據量也較小，佔用帶寬少——例如，一個更新GB的數據的查詢僅須要幾十個字節的二進制日誌。而mysqlbinlog對於基於語句的日誌處理十分方便。

可是，基於語句的複製並非像它看起來那麼簡單，由於一些查詢語句依賴於master的特定條件，例如，master與slave可能有不一樣的時間。因此，MySQL的二進制日誌的格式不只僅是查詢語句，還包括一些元數據信息，例如，當前的時間戳。即便如此，仍是有一些語句，好比，CURRENT USER函數，不能正確的進行復制。此外，存儲過程和觸發器也是一個問題。

另一個問題就是基於語句的複製必須是串行化的。這要求大量特殊的代碼，配置，例如InnoDB的next-key鎖等。並非全部的存儲引擎都支持基於語句的複製。

1. 基於行的複製：

把改變的內容複製過去，而不是把命令在從服務器上執行一遍. 從mysql5.0開始支持

MySQL增長基於記錄的複製，在二進制日誌中記錄下實際數據的改變，這與其它一些DBMS的實現方式相似。這種方式有優勢，也有缺點。優勢就是能夠對任何語句都能正確工做，一些語句的效率更高。主要的缺點就是二進制日誌可能會很大，並且不直觀，因此，你不能使用mysqlbinlog來查看二進制日誌。

1. 混合類型的複製:

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

1.2 複製相關的文件

除了二進制日誌和中繼日誌文件外，還有其它一些與複製相關的文件。

1. mysql-bin.index

服務器一旦開啓二進制日誌，會產生一個與二日誌文件同名，可是以.index結尾的文件。它用於跟蹤磁盤上存在哪些二進制日誌文件。MySQL用它來定位二進制日誌文件。

1. mysql-relay-bin.index

該文件的功能與mysql-bin.index相似，可是它是針對中繼日誌，而不是二進制日誌。

1. master.info

保存master的相關信息。不要刪除它，不然，slave重啓後不能鏈接master。I/O線程更新master.info文件

1. relay-log.info

包含slave中當前二進制日誌和中繼日誌的信息。

1.3 複製的原理

1. master將改變記錄到二進制日誌(binary log)中（這些記錄叫作二進制日誌事件，binary log events）；
2. slave將master的binary log events拷貝到它的中繼日誌(relay log)；
3. slave重作中繼日誌中的事件，將更改應用到本身的數據上。

在每一個事務更新數據完成以前，MySQL將事務串行的寫入二進制日誌，即便事務中的語句都是交叉執行的。在事件寫入二進制日誌完成後，master通知存儲引擎提交事務。

slave開始一個工做線程——I/O線程。I/O線程在master上打開一個普通的鏈接，而後開始binlog dump process。Binlog dump process從master的二進制日誌中讀取事件還包括文件的名稱以及bin-log的位置，若是已經跟上master，它會睡眠並等待master產生新的事件。I/O線程將這些事件寫入中繼日誌。

SQL線程從中繼日誌讀取事件，並重放其中的事件而更新slave的數據，使其與master中的數據一致。只要該線程與I/O線程保持一致，中繼日誌一般會位於OS的緩存中，因此中繼日誌的開銷很小。

複製過程有一個很重要的限制——複製在slave上是串行化的（徹底順序的執行日誌中所記錄的各類操做），也就是說master上的並行更新操做不能在slave上並行操做。

Slave繼續做爲其餘節點的master，當設置log_slave_updates時，你可讓slave扮演其它slave的master。此時，slave把SQL線程執行的事件寫進行本身的二進制日誌(binary log)，而後，它的slave能夠獲取這些事件並執行它。

複製過濾，複製過濾可讓你只複製服務器中的一部分數據，有兩種複製過濾：在master上過濾二進制日誌中的事件；在slave上過濾中繼日誌中的事件。

1.4 複製的經常使用拓撲結構

1. 單一master和多slave

由一個master和一個slave組成複製系統是最簡單的狀況。Slave之間並不相互通訊，只能與master進行通訊。

在實際應用場景中，MySQL複製90%以上都是一個Master複製到一個或者多個Slave的架構模式，主要用於讀壓力比較大的應用的數據庫端廉價擴展解決方案。由於只要Master和Slave的壓力不是太大（尤爲是Slave端壓力）的話，異步複製的延時通常都不多不多。尤爲是自從Slave端的複製方式改爲兩個線程處理以後，更是減少了Slave端的延時問題。而帶來的效益是，對於數據實時性要求不是特別Critical的應用，只須要經過廉價的pcserver來擴展Slave的數量，將讀壓力分散到多臺Slave的機器上面，便可經過分散單臺數據庫服務器的讀壓力來解決數據庫端的讀性能瓶頸，畢竟在大多數數據庫應用系統中的讀壓力仍是要比寫壓力大不少。這在很大程度上解決了目前不少中小型網站的數據庫壓力瓶頸問題，甚至有些大型網站也在使用相似方案解決數據庫瓶頸。

若是寫操做較少，而讀操做很時，能夠採起這種結構。你能夠將讀操做分佈到其它的slave，從而減少master的壓力。可是，當slave增長到必定數量時，slave對master的負載以及網絡帶寬都會成爲一個嚴重的問題。

這種結構雖然簡單，可是，它卻很是靈活，足夠知足大多數應用需求。一些建議：

• 不一樣的slave扮演不一樣的做用(例如使用不一樣的索引，或者不一樣的存儲引擎)；
• 用一個slave做爲備用master，只進行復制；
• 用一個遠程的slave，用於災難恢復；

1. 主動模式的Master-Master(Master-Master in Active-Active Mode)

Master-Master複製的兩臺服務器，將對方做爲本身的master，同時將本身做爲對方的slave。這樣，任何一方所作的變動，都會經過複製應用到另一方的數據庫中。

可能有些讀者朋友會有一個擔憂，這樣搭建複製環境以後，難道不會形成兩臺MySQL之間的循環複製麼？實際上MySQL本身早就想到了這一點，因此在MySQL的BinaryLog中記錄了當前MySQL的server-id，並且這個參數也是咱們搭建MySQLReplication的時候必須明確指定，並且Master和Slave的server-id參數值必需要不一致才能使MySQLReplication搭建成功。一旦有了server-id的值以後，MySQL就很容易判斷某個變動是從哪個MySQLServer最初產生的，因此就很容易避免出現循環複製的狀況。並且，若是咱們不打開記錄Slave的BinaryLog的選項（--log-slave-update）的時候，MySQL根本就不會記錄複製過程當中的變動到BinaryLog中，就更不用擔憂可能會出現循環複製的情形了。

主動的Master-Master複製有一些特殊的用處。例如，地理上分佈的兩個部分都須要本身的可寫的數據副本。這種結構最大的問題就是更新衝突。

1. 主動-被動模式的Master-Master(Master-Master in Active-Passive Mode)

這是master-master結構變化而來的，它避免了M-M的缺點，實際上，這是一種具備容錯和高可用性的系統。它的不一樣點在於其中一個服務只能進行只讀操做。

1. 級聯複製架構 Master –Slaves - Slaves

在有些應用場景中，可能讀寫壓力差異比較大，讀壓力特別的大，一個Master可能須要上10臺甚至更多的Slave纔可以支撐注讀的壓力。這時候，Master就會比較吃力了，由於僅僅連上來的SlaveIO線程就比較多了，這樣寫的壓力稍微大一點的時候，Master端由於複製就會消耗較多的資源，很容易形成複製的延時。

遇到這種狀況如何解決呢？這時候咱們就能夠利用MySQL能夠在Slave端記錄複製所產生變動的BinaryLog信息的功能，也就是打開—log-slave-update選項。而後，經過二級（或者是更多級別）複製來減小Master端由於複製所帶來的壓力。也就是說，咱們首先經過少數幾臺MySQL從Master來進行復制，這幾臺機器咱們姑且稱之爲第一級Slave集羣，而後其餘的Slave再從第一級Slave集羣來進行復制。從第一級Slave進行復制的Slave，我稱之爲第二級Slave集羣。若是有須要，咱們能夠繼續往下增長更多層次的複製。這樣，咱們很容易就控制了每一臺MySQL上面所附屬Slave的數量。這種架構我稱之爲Master-Slaves-Slaves架構

這種多層級聯複製的架構，很容易就解決了Master端由於附屬Slave太多而成爲瓶頸的風險。

固然，若是條件容許，我更傾向於建議你們經過拆分紅多個Replication集羣來解決

上述瓶頸問題。畢竟Slave並無減小寫的量，全部Slave實際上仍然仍是應用了全部的數據變動操做，沒有減小任何寫IO。相反，Slave越多，整個集羣的寫IO總量也就會越多，咱們沒有很是明顯的感受，僅僅只是由於分散到了多臺機器上面，因此不是很容易表現出來。

此外，增長複製的級聯層次，同一個變動傳到最底層的Slave所須要通過的MySQL也會更多，一樣可能形成延時較長的風險。

而若是咱們經過分拆集羣的方式來解決的話，可能就會要好不少了，固然，分拆集羣也須要更復雜的技術和更復雜的應用系統架構。

1. 帶從服務器的Master-Master結構(Master-Master with Slaves)

這種結構的優勢就是提供了冗餘。在地理上分佈的複製結構，它不存在單一節點故障問題，並且還能夠將讀密集型的請求放到slave上。

級聯複製在必定程度上面確實解決了Master由於所附屬的Slave過多而成爲瓶頸的問題，可是他並不能解決人工維護和出現異常須要切換後可能存在從新搭建Replication的問題。這樣就很天然的引伸出了DualMaster與級聯複製結合的Replication架構，我稱之爲Master-Master-Slaves架構

和Master-Slaves-Slaves架構相比，區別僅僅只是將第一級Slave集羣換成了一臺單獨的Master，做爲備用Master，而後再從這個備用的Master進行復制到一個Slave集羣。

 

 

 

 

這種DualMaster與級聯複製結合的架構，最大的好處就是既能夠避免主Master的寫入操做不會受到Slave集羣的複製所帶來的影響，同時主Master須要切換的時候也基本上不會出現重搭Replication的狀況。可是，這個架構也有一個弊端，那就是備用的Master有可能成爲瓶頸，由於若是後面的Slave集羣比較大的話，備用Master可能會由於過多的SlaveIO線程請求而成爲瓶頸。固然，該備用Master不提供任何的讀服務的時候，瓶頸出現的可能性並非特別高，若是出現瓶頸，也能夠在備用Master後面再次進行級聯複製，架設多層Slave集羣。固然，級聯複製的級別越多，Slave集羣可能出現的數據延時也會更爲明顯，因此考慮使用多層級聯複製以前，也須要評估數據延時對應用系統的影響。

1.5 參考資料：

http://blog.sina.com.cn/s/blog_aed82f6f01019nzj.html

http://www.linuxidc.com/Linux/2015-02/112647.htm

http://www.cnblogs.com/kristain/articles/4142970.html

2 MySQL5.6的複製

2.1 半同步複製

因爲Mysql的複製都是基於異步進行的，在特殊狀況下不能保證數據的成功複製，所以在mysql5.5以後使用了來自google補丁，能夠將Mysql的複製實現半同步模式。MySQL5.6的官方版本已經收錄了半同步複製功能，須要爲主服務器加載對應的插件。在Mysql的安裝目錄下的lib/plugin/目錄中具備對應的插件semisync_master.so，semisync_slave.so，其中semisync_master.so是主服務器上的插件，而semisync_slave.so則是從服務器上的插件。

    隨着MySQL 5.6中引入了全局事務ID（GTIDs）

1. 在主服務器的mysql服務器上執行以下命令

mysql> install pluginrpl_semi_sync_master soname 'semisync_master.so';  安裝模塊

mysql> set global rpl_semi_sync_master_enabled = 1;  啓用半同步複製主節點

mysql> set global rpl_semi_sync_master_timeout = 1000;  超時時間

mysql> show variables like '%semi%';   查看設置是否成功

1. 在從服務器的mysql服務器上執行以下命令

mysql> install pluginrpl_semi_sync_slave soname 'semisync_slave.so';  安裝模塊

mysql> set global rpl_semi_sync_slave_enabled = 1;   啓用半同步複製從節點

mysql> stop slave;

mysql> start slave;

mysql> show variables like '%semi%'; 查看設置是否成功

1. 驗證半同步複製是否生效在主服務器上執行以下命令

mysql> show global status like 'rpl_semi%';

2.2 並行複製

MySQL 5.6版本也支持所謂的並行複製，可是其並行只是基於schema的，也就是基於庫的。若是用戶的MySQL數據庫實例中存在多個schema，對於從機複製的速度的確能夠有比較大的幫助。

在下圖的紅色框框部分就是實現並行複製的關鍵所在。在MySQL 5.6版本以前，Slave服務器上有兩個線程I/O線程和SQL線程。I/O線程負責接收二進制日誌（更準確的說是二進制日誌的event），SQL線程進行回放二進制日誌。若是在MySQL 5.6版本開啓並行複製功能，那麼SQL線程就變爲了coordinator線程，coordinator線程主要負責之前兩部分的內容：

• 若判斷能夠並行執行，那麼選擇worker線程執行事務的二進制日誌
• 若判斷不能夠並行執行，如該操做是DDL，亦或者是事務跨schema操做，則等待全部的worker線程執行完成以後，再執行當前的日誌

這意味着coordinator線程並非僅將日誌發送給worker線程，本身也能夠回放日誌，可是全部能夠並行的操做交付由worker線程完成。coordinator線程與worker是典型的生產者與消費者模型。

上述機制實現了基於schema的並行複製存在兩個問題，首先是crash safe功能很差作，由於可能以後執行的事務因爲並行複製的關係先完成執行，那麼當發生crash的時候，這部分的處理邏輯是比較複雜的。從代碼上看，5.6這裏引入了Low-Water-Mark標記來解決該問題，從設計上看（WL#5569），其是但願藉助於日誌的冪等性來解決該問題，不過5.6的二進制日誌回放還不能實現冪等性。另外一個最爲關鍵的問題是這樣設計的並行複製效果並不高，若是用戶實例僅有一個庫，那麼就沒法實現並行回放，甚至性能會比原來的單線程更差。而單庫多表是比多庫多表更爲常見的一種情形。

2.3 參考資料

http://jilili.blog.51cto.com/6617089/1203805

http://mp.weixin.qq.com/s?__biz=MjM5MjIxNDA4NA==&mid=205236417&idx=1&sn=15281c834348911cea106478aa819175&3rd=MzA3MDU4NTYzMw==&scene=6#rd

http://blog.itpub.net/24945919/viewspace-764369/

3 MySQL5.7的複製

3.1 真正的並行複製

MySQL 5.7纔可稱爲真正的並行複製，這其中最爲主要的緣由就是slave服務器的回放與主機是一致的即master服務器上是怎麼並行執行的slave上就怎樣進行並行回放。再也不有庫的並行複製限制，對於二進制日誌格式也無特殊的要求（基於庫的並行複製也沒有要求）。

MTS: Prepared transactions slave parallel applier，可見：WL#6314。該並行複製的思想最先是由MariaDB的Kristain提出，並已在MariaDB 10中出現，相信不少選擇MariaDB的小夥伴最爲看重的功能之一就是並行複製。

MySQL 5.7並行複製的思想簡單易懂，一言以蔽之：一個組提交的事務都是能夠並行回放，由於這些事務都已進入到事務的prepare階段，則說明事務之間沒有任何衝突（不然就不可能提交）。

爲了兼容MySQL 5.6基於庫的並行複製，5.7引入了新的變量slave-parallel-type，其能夠配置的值有：

• DATABASE：默認值，基於庫的並行複製方式
• LOGICAL_CLOCK：基於組提交的並行複製方式

3.2 並行複製配置與調優

1. master_info_repository

開啓MTS功能後，務必將參數master_info_repostitory設置爲TABLE，這樣性能能夠有50%~80%的提高。這是由於並行複製開啓後對於元master.info這個文件的更新將會大幅提高，資源的競爭也會變大。在以前InnoSQL的版本中，添加了參數來控制刷新master.info這個文件的頻率，甚至能夠不刷新這個文件。由於刷新這個文件是沒有必要的，即根據master-info.log這個文件恢復自己就是不可靠的。在MySQL 5.7中，Inside君推薦將master_info_repository設置爲TABLE，來減少這部分的開銷。

1. slave_parallel_workers

若將slave_parallel_workers設置爲0，則MySQL 5.7退化爲原單線程複製，但將slave_parallel_workers設置爲1，則SQL線程功能轉化爲coordinator線程，可是隻有1個worker線程進行回放，也是單線程複製。然而，這兩種性能卻又有一些的區別，由於多了一次coordinator線程的轉發，所以slave_parallel_workers=1的性能反而比0還要差，在Inside君的測試下還有20%左右的性能降低。

3.3 Enhanced Multi-Threaded Slave配置

說了這麼多，要開啓enhanced multi-threaded slave其實很簡單，只需根據以下設置：

# slave

slave-parallel-type=LOGICAL_CLOCK

slave-parallel-workers=16

master_info_repository=TABLE

relay_log_info_repository=TABLE

relay_log_recovery=ON

並行複製監控

複製的監控依舊能夠經過SHOW SLAVE STATUS\G，可是MySQL 5.7在performance_schema架構下多瞭如下這些元數據表，用戶能夠更細力度的進行監控：

mysql> show tables like 'replication%';

+---------------------------------------------+

| Tables_in_performance_schema (replication%) |

+---------------------------------------------+

| replication_applier_configuration           |

| replication_applier_status                  |

| replication_applier_status_by_coordinator   |

| replication_applier_status_by_worker        |

| replication_connection_configuration        |

| replication_connection_status               |

| replication_group_member_stats              |

| replication_group_members                   |

+---------------------------------------------+

8 rows in set (0.00 sec)

3.4 參考資料

http://mp.weixin.qq.com/s?__biz=MjM5MjIxNDA4NA==&mid=205236417&idx=1&sn=15281c834348911cea106478aa819175&3rd=MzA3MDU4NTYzMw==&scene=6#rd

4 複製延遲檢測

4.1 經過Slave狀態監控

在MySQL複製環境中，咱們一般只根據 Seconds_Behind_Master 的值來判斷SLAVE的延遲。這麼作大部分狀況下尚可接受，但並不夠準確，而應該考慮更多因素。

• 首先看 Relay_Master_Log_File 和 Master_Log_File 是否有差別；
• 若是Relay_Master_Log_File 和 Master_Log_File 是同樣的話，再來看Exec_Master_Log_Pos 和 Read_Master_Log_Pos 的差別，對比SQL線程比IO線程慢了多少個binlog事件；
• 若是Relay_Master_Log_File 和 Master_Log_File 不同，那說明延遲可能較大，須要從MASTER上取得binlog status，判斷當前的binlog和MASTER上的差距；

4.2 經過pt工具實時監控延遲

percona-toolkit源自Maatkit 和Aspersa工具，這兩個工具是管理mysql的最有名的工具，如今Maatkit工具已經不維護了，請你們仍是使用percona-toolkit吧！這些工具主要包括開發、性能、配置、監控、複製、系統、實用六大類，做爲一個優秀的DBA，裏面有的工具很是有用，若是能掌握並加以靈活應用，將能極大的提升工做效率。

4.3 參考資料

http://blog.chinaunix.net/uid/20639775/list/1.html?sid=159653

http://www.jb51.net/article/75070.htm

http://www.cnblogs.com/zping/p/5678652.html

http://www.cnblogs.com/kevingrace/p/5685511.html