MySQL主從復制

MySQL主從復制
主從復制類型：
異步方式：一般的MySQL復制，主server只負責發送二進制日志，不check從是否完成
半同步方式：在一堆從中，主只保證其中一個返回同步完成即可，如果超時，自動降級為異步
級聯方式：主復制給其中一個從，這個從再復制給后面的一堆從，用于減輕主的負擔
架構：
普通一主多從：

帶負載均衡的讀寫分離：

帶級聯復制和負載均衡的讀寫分離：

主從步驟：

1. 主上面為每個slave開啟一個dump thread
2. 從上的IO thread和主上的dump thread連接，并發送二進制日志，在從上保存為realy log
3. 從上的SQL thread從relay log中逐條讀取并在本地執行
   主從配置：
   主上配置：
4. 開啟binlog
5. 設置server id
6. 創建同步用戶，并授予REPLICATION SLAVE和REPLICATION CLIENT權限
   從上配置：
7. 開啟relay log
8. 設置與主不同的server id
9. CHANGE MASTER TO MASTER_HOST='',MASTER_PORT=,MASTER_USER='',MASTER_PASSWORD='',MASTER_LOG_FILE='',MASTER_LOG_POS=;
10. start slave io_thread;start slave sql_thread;
11. 配置skip-slave-start=1
    半同步配置：
12. 安裝master/slave remi插件：INSTALL PLUGIN
13. 啟用master/slave remi插件
14. 設置超時時間即可，超出此時長后自動降級為異步方式
    同步過濾配置：
    主上可選配置（不推薦，因為會導致二進制事件丟失）：
15. binlog-do-db: 二進制日志記錄此庫操作
16. binlog-ingire-db: 二進制日志忽略此庫操作
    從上可選（推薦，但會導致不必要的性能消耗）：
17. replicate-do-db：同步此db
18. replicate-ingire-db：忽略此db
19. replicate-do-table：同步此表
20. replicate-ingire-table：忽略此表
21. replicate-wild-do-table=tb%：支持正則，同步tb開頭的表
22. replicate-wild-ingire-table=tb_：主持正則，忽略以tb開頭后跟一個字符的表

基于GTID及多線程復制：
1、基于GTID是一種安全復制方式，MySQL5.6版本后支持全局事務ID，在復制是根據全局事務ID進行復制，在復制時從會反饋自己的復制狀態以及記錄復制了哪些語句，其他從也知道另外從的復制位置等，在主從切換時更安全。
2、多線程復制是基于多個庫的，每個庫一個單線程，多個庫可以使用多個線程。

一、 什么是GTID （ Global transaction identifiers ）：
MySQL-5.6.2開始支持，MySQL-5.6.10后完善，GTID 分成兩部分，一部分是服務的UUid,UUID保存在mysql數據目錄的auto.cnf文件中,
這是一個非常重要的文件，不能刪除，這一部分是不會變的。另外一部分就是事務ID了，隨著事務的增加，值一次遞增,如下圖
+---------------+----------+--------------+------------------+--------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+--------------------------------------------+
| binlog.000029 | 23556 | | | 724afcc2-29d6-11e4-9902-000c290c0121:1-362 |
+---------------+----------+--------------+------------------+--------------------------------------------+
GTID:724afcc2-29d6-11e4-9902-000c290c0121:1-362
UUID:724afcc2-29d6-11e4-9902-000c290c0121
transactionId:1-362
在整個復制架構中GTID 是不變化的,即使在多個連環主從中也不會變。
例如：ServerA --->ServerB ---->ServerC
GTID從在ServerA ,ServerB,ServerC 中都是一樣的。

二、 GTID的工作原理：
1、master更新數據時，會在事務前產生GTID，一同記錄到binlog日志中。
2、slave端的i/o 線程將變更的binlog，寫入到本地的relay log中。
3、sql線程從relay log中獲取GTID，然后對比slave端的binlog是否有記錄。
4、如果有記錄，說明該GTID的事務已經執行，slave會忽略。
5、如果沒有記錄，slave就會從relay log中執行該GTID的事務，并記錄到binlog。
6、在解析過程中會判斷是否有主鍵，如果沒有就用二級索引，如果沒有就用全部掃描。

三、 GTID的優點：
1.一個事務對應一個唯一ID，一個GTID在一個服務器上只會執行一次
2.GTID是用來代替傳統復制的方法，GTID復制與普通復制模式的最大不同就是不需要指定二進制文件名和位置
3.減少手工干預和降低服務故障時間，當主機掛了之后通過軟件從眾多的備機中提升一臺備機為主機

那么GTID復制是怎么實現自動同步，自動對應位置的呢？
例如：ServerC <-----ServerA ----> ServerB
主機ServerA
備機:ServerB,ServerC
當主機ServerA 掛了之后 ，此時ServerB執行完了所有從ServerA 傳過來的事務，
ServerC 延時一點。這個時候需要把 ServerB 提升為主機 ，Server C 繼續為備機。
當ServerC 鏈接ServerC 之后,首先在自己的二進制文件中找到從ServerA 傳過來的最新的GTID，
然后將這個GTID 發送到ServerB ,ServerB 獲得這個GTID之后,就開始從這個GTID的下一個GTID
開始發送事務給ServerC。這種自我尋找復制位置的模式減少事務丟失的可能性以及故障恢復的時間。

四、 GTID的限制：
1.不支持非事務引擎
2.不支持create table ... select 語句復制(主庫直接報錯)
原理：（ 會生成兩個sql，一個是DDL創建表SQL，一個是insert into 插入數據的sql。
由于DDL會導致自動提交，所以這個sql至少需要兩個GTID，但是GTID模式下，只能給這個sql生成一個GTID ）
3.不允許一個SQL同時更新一個事務引擎表和非事務引擎表
4.在一個復制組中，必須要求統一開啟GTID或者是關閉GTID
5.開啟GTID需要重啟（5.7除外）
6.開啟GTID后，就不再使用原來的傳統復制方式
7.對于create temporary table 和 drop temporary table語句不支持
8.不支持sql_slave_skip_counter