加強半同步複製

1、理解半同步

一、概念

MySQL默認的複製都是異步的，在服務器崩潰時丟失事務是使用異步複製不可避免的結果。而5.5以後推出的一項新功能：半同步複製，能夠限制事務丟失的數量。

1>異步複製

Asynchronous replication

MySQL默認的複製便是異步的，主庫在執行完客戶端提交的事務後會當即將結果返給給客戶端，並不關心從庫是否已經接收並處理，這樣就會有一個問題，主若是crash掉了，此時主上已經提交的事務可能並無傳到從上，若是此時，強行將從提高爲主，可能致使新主上的數據不完整。

2>全同步複製

Fully synchronous replication

指當主庫執行完一個事務，全部的從庫都執行了該事務才返回給客戶端。由於須要等待全部從庫執行完該事務才能返回，因此全同步複製的性能必然會收到嚴重的影響。

3>半同步複製

Semisynchronous replication

介於異步複製和全同步複製之間，主庫在執行完客戶端提交的事務後不是馬上返回給客戶端，而是等待至少一個從庫接收到並寫到relay log中才返回給客戶端。相對於異步複製，半同步複製提升了數據的安全性，同時它也形成了必定程度的延遲，這個延遲最少是一個TCP/IP往返的時間。因此，半同步複製最好在低延時的網絡中使用。

二、MySQL5.7在5.6/5.5的基礎上加強了幾點功能

1>無數據丟失

MySQL5.7在Master事務提交的時間方面作了改進（rpl_semi_sync_master_wait_point：AFTER_COMMIT\AFTER_SYNC），事務是在提交以前發送給Slave（默認：after_sync），當Slave沒有接收成功，而且Master宕機了，不會致使主從不一致，由於此時主尚未提交，因此主從都沒有數據。

MySQL5.7也支持和MySQL5.5\5.6同樣的機制：事務提交以後再發給Slave（after_commit）****。

總之，MySQL5.7半同步的好處就是在確認事務複製到Slave以前，併發的其餘線程看不到當前事務的數據。當Master故障時，要麼提交的事務已經複製到Slave，要麼所有都沒提交，這樣就保證了數據的一致性。

2>更快的半同步複製

MySQL5.5/5.6的半同步複製是一個單工通信方式，master把事務發送完畢後，要接收和處理slave的應答，處理完應答以後才能繼續發送下一個事務。

MySQL5.7的半同步複製建立了單獨的應答接收線程，變成了雙工模式，發送和接收互不影響。由於有了相應的線程處理，發送效率獲得大幅提高，相比MySQL5.5/5.6延遲會小不少，性能獲得大幅提高。

5.7 semi_sync具體設計思路以下：

1. 事務提交的時候，主庫把 binlog 發給從庫；
2. 從庫收到 binlog 之後，發回給主庫一個 ack，表示收到了；
3. 主庫收到這個 ack 之後，才能給客戶端返回「事務完成」的確認。

也就是說，若是啓用了 semi-sync，就表示全部給客戶端發送過確認的事務，都確保了備庫已經收到了這個日誌。

注意：

MySQL5.7單獨的應答接收線程在開啓半同步複製的時候默認就建立了，不須要額外的設置。

3>等待多個slave應答

在半同步複製中，Master發送事務默認至少有一個Slave獲得響應才能繼續下一個事務。MySQL5.7以後用戶能夠設置應答的Slave數量，而且能夠經過參數(rpl_semi_sync_master_wait_for_slave_count)。該變量控制slave應答的數量，默認是1，表示master接收到幾個slave應答後才commit。在多從的環境下，設置大於1能夠提升數據的可靠性。

2、參數說明

一、主庫

rpl_semi_sync_master_enabled

表示主上是否開啓半同步複製功能，能夠動態修改。可選值：ON\OFF

rpl_semi_sync_master_timeout

爲了防止半同步複製中主在沒有收到S發出的確認發生堵塞，用來設置超時，超過這個時間值沒有收到信息，則切換到異步複製，執行操做。默認爲10000毫秒，等於10秒，這個參數動態可調，表示主庫在某次事務中，若是等待時間超過10秒，那麼則降級爲異步複製模式，再也不等待SLAVE從庫。若是主庫再次探測到，SLAVE從庫恢復了，則會自動再次回到半同步複製模式。能夠設置成1000，即1秒。

rpl_semi_sync_master_wait_for_slave_count

控制slave應答的數量，默認是1，表示master接收到幾個slave應答後才commit。

rpl_semi_sync_master_wait_no_slave

當一個事務被提交，可是Master沒有Slave鏈接，這時M不可能收到任何確認信息，但M會在時間限制範圍內繼續等待。若是沒有Slave連接，會切換到異步複製。是否容許master每一個事務提交後都要等待slave的接收確認信號。默認爲on，每個事務都會等待。若是爲off，則slave追遇上後，也不會開啓半同步複製模式，須要手工開啓。

rpl_semi_sync_master_wait_point

該參數表示半同步複製的主在哪一個點等待從的響應，默認AFTER_SYNC，在獲得slave的應答後再commit，可選值AFTER_COMMIT。

二、從庫

rpl_semi_sync_slave_enabled

表示從上是否開啓半同步複製功能，能夠動態修改。可選值：ON\OFF

Rpl_semi_sync_slave_status

Slave上的半同步複製狀態，ON表示已經被啓用，OFF表示非活動狀態。

rlp_semi_sync_slave_trace_level=32

表示開啓半同步複製模式時的調試級別，默認是32。

3、安裝部署

本次部署演示環境爲

• 操做系統：CentOS7.2
• 數據庫：   MySQL5.7.24
• 複製模式：GTID + ROW 

一、環境準備

要想使用半同步複製，必須知足如下幾個條件

1. MySQL 5.5及以上版本
2. 變量have_dynamic_loading爲YES
3. 異步複製已經存在

mysql> show variables like '%have_dynamic_loading%';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| have_dynamic_loading | YES   |
+----------------------+-------+
1 row in set (0.00 sec)

 

二、加載插件

因用戶需執行INSTALL PLUGIN, SET GLOBAL, STOP SLAVE和START SLAVE操做，因此用戶需有SUPER權限。

主：

mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';

從：

mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

查看插件是否加載成功

方法1

mysql> show plugins;

rpl_semi_sync_master       | ACTIVE   | REPLICATION        | semisync_master.so | GPL

方法2

mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE '%semi%';

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

| PLUGIN_NAME          | PLUGIN_STATUS |

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

| rpl_semi_sync_master | ACTIVE        |

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

1 row in set (0.00 sec)

四、啓動半同步複製

在安裝完插件後，半同步複製默認是關閉的，這時需設置參數來開啓半同步

主：

mysql> SET GLOBAL rpl_semi_sync_master_enabled = 1;

從：

mysql> SET GLOBAL rpl_semi_sync_slave_enabled = 1;

注意：初次加載插件後，MySQL會將該插件記錄到系統表mysql.plugin中，下次啓動時系統會自動加載該插件。

在my.cnf配置文件里加入如下配置

主：

#semi_sync

plugin-load=rpl_semi_sync_master=semisync_master.so

rpl_semi_sync_master_enabled=1

從：

#semi_sync

plugin-load=rpl_semi_sync_slave=semisync_slave.so

rpl_semi_sync_slave_enabled=1

在有的高可用架構下，master和slave需同時啓動，以便在切換後能繼續使用半同步複製

plugin-load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"
rpl-semi-sync-master-enabled = 1
rpl-semi-sync-slave-enabled = 1

 

五、重啓從庫IO線程

mysql> STOP SLAVE IO_THREAD;
mysql> START SLAVE IO_THREAD;

 

若是沒有重啓，則默認仍是異步複製，重啓後，slave會在master上註冊爲半同步複製的slave角色。

此時從庫半同步模式正式開啓

mysql> show status like '%semi_sync%';

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

| Variable_name              | Value |

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

| Rpl_semi_sync_slave_status | ON    |

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

1 row in set (0.00 sec)

這時候，主的error.log中會打印以下信息：

2016-08-05T10:03:40.104327Z 5 [Note] While initializing dump thread for slave with UUID <ce9aaf22-5af6-11e6-850b-000c2988bad2>, found a zombie dump thread with the same UUID. Master is killing the zombie dump thread(4).

2016-08-05T10:03:40.111175Z 4 [Note] Stop asynchronous binlog_dump to slave (server_id: 2)

2016-08-05T10:03:40.119037Z 5 [Note] Start binlog_dump to master_thread_id(5) slave_server(2), pos(mysql-bin.000003, 621)

2016-08-05T10:03:40.119099Z 5 [Note] Start semi-sync binlog_dump to slave (server_id: 2), pos(mysql-bin.000003, 621)

六、查看半同步是否在運行

主庫

mysql> show status like 'Rpl_semi_sync_master_status';

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

| Variable_name | Value |

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

| Rpl_semi_sync_master_status | ON    |

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

1 row in set (0.00 sec)

從庫

mysql> show status like 'Rpl_semi_sync_slave_status';

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

| Variable_name | Value |

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

| Rpl_semi_sync_slave_status | ON    |

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

1 row in set (0.20 sec)

這兩個變量經常使用來監控主從是否運行在半同步複製模式下。

至此，MySQL半同步複製搭建完畢~~~

4、總結

事實上，半同步複製並非嚴格意義上的半同步複製

當半同步複製發生超時時（由rpl_semi_sync_master_timeout參數控制，單位是毫秒，默認爲10000，即10s），會暫時關閉半同步複製，轉而使用異步複製。當master dump線程發送完一個事務的全部事件以後，若是在rpl_semi_sync_master_timeout內，收到了從庫的響應，則主從又從新恢復爲半同步複製。

該驗證分爲三個階段

1. 在Slave執行stop slave以前，主的insert操做很快就能返回。
2. 在Slave執行stop slave後，主的insert操做須要10.01s才返回，而這與rpl_semi_sync_master_timeout參數的時間相吻合。

這時，查看兩個狀態的值，均爲「OFF」了。

同時，主的error.log中打印以下信息：

2016-08-05T11:51:49.855452Z 6 [Warning] Timeout waiting for reply of binlog (file: mysql-bin.000003, pos: 1447), semi-sync up to file mysql-bin.000003, position 1196.

2016-08-05T11:51:49.855742Z 6 [Note] Semi-sync replication switched OFF.

3. 在Slave執行start slave後，主的insert操做很快就能返回，此時，兩個狀態的值也變爲「ON」了。

同時，主的error.log中會打印以下信息：

2016-08-05T11:52:40.477098Z 7 [Note] Start binlog_dump to master_thread_id(7) slave_server(2), pos(mysql-bin.000003, 1196)

2016-08-05T11:52:40.477168Z 7 [Note] Start semi-sync binlog_dump to slave (server_id: 2), pos(mysql-bin.000003, 1196)

2016-08-05T11:52:40.523475Z 0 [Note] Semi-sync replication switched ON at (mysql-bin.000003, 1447)

小結

1. 在一主多從的架構中，若是要開啓半同步複製，並不要求全部的從都是半同步複製。

2. MySQL 5.7極大的提高了半同步複製的性能。

5.6版本的半同步複製，dump thread 承擔了兩份不一樣且又十分頻繁的任務：傳送binlog 給slave ，還須要等待slave反饋信息，並且這兩個任務是串行的，dump thread 必須等待 slave 返回以後纔會傳送下一個 events 事務。dump thread 已然成爲整個半同步提升性能的瓶頸。在高併發業務場景下，這樣的機制會影響數據庫總體的TPS 。

5.7版本的半同步複製中，獨立出一個 ack collector thread ，專門用於接收slave 的反饋信息。這樣master 上有兩個線程獨立工做，能夠同時發送binlog 到slave ，和接收slave的反饋。