MySQL主從復制包括異步模式、半同步模式、GTID模式以及多源復制模式，默認是異步模式 (如之前詳細介紹的mysql主從復制)。所謂異步模式指的是MySQL 主服務器上I/O thread 線程將二進制日誌寫入binlog文件之後就返回客戶端結果，不會考慮二進制日誌是否完整傳輸到從服務器以及是否完整存放到從服務器上的relay日誌中，這種模式一旦主服務(器)宕機，數據就可能會發生丟失。

異步模式是一種基於偏移量的主從復制，實現原理是：主庫開啟binlog功能並授權從庫連接主庫，從庫通過change master得到主庫的相關同步信息然後連接主庫進行驗證，主庫IO線程根據從庫slave線程的請求，從master.info開始記錄的位置點向下開始取信息，同時把取到的位置點和最新的位置與binlog信息一同發給從庫IO線程,從庫將相關的sql語句存放在relay-log裏面，最終從庫的sql線程將relay-log裏的sql語句應用到從庫上，至此整個同步過程完成，之後將是無限重復上述過程。

設置MySQL主從同步一般步驟為: 1) 主數據庫實例設置server-id和開啟bin-log； 2) 主數據庫實例創建用於同步的賬號； 3) 從數據庫實例設置server-id； 4) 從數據庫實例配置同步參數(change master to .....)； 5) 從數據庫實例啟動同步開關。

這裏順便說下之前給過的一道面試題：描述msyql replication 機制的實現原理，如何在不停掉mysql主庫的情況下，恢復數據不一致的slave的數據庫節點？

MySQL的復制（replication）是一個異步的復制，從一個MySQL instace（稱之為Master）復制到另一個MySQL instance（稱之Slave）。實現整個復制操作主要由三個進程完成的，其中兩個進程在Slave（Sql進程和IO進程），另外一個進程在Master（IO進程）上。簡單來說，Mysql復制就是一種基於binlog的單線程異步復制過程！！

MySQL Replication復制的基本過程如下：
1) Slave上面的IO進程連接上Master，並請求從指定日誌文件的指定位置（或者從最開始的日誌）之後的日誌內容

mysql> CHANGE MASTER TO
    -> MASTER_HOST=‘master_host_name‘,
    -> MASTER_USER=‘replication_user_name‘,
    -> MASTER_PASSWORD=‘replication_password‘,
    -> MASTER_LOG_FILE=‘recorded_log_file_name‘,
    -> MASTER_LOG_POS=recorded_log_position;

2) Master接收到來自Slave的IO進程的請求後，通過負責復制的IO進程根據請求信息讀取制定日誌指定位置之後的日誌信息，返回給Slave的IO進程。返回信息中除了日誌所包含的信息之外，還包括本次返回的信息已經到Master端的bin-log文件的名稱以及bin-log的位置；

3) Slave的IO進程接收到信息後，將接收到的日誌內容依次添加到Slave端的relay-log文件的最末端，並將讀取到的Master端的bin-log的文件名和位置記錄到master-info文件中，以便在下一次讀取的時候能夠清楚的高速Maste “我需要從某個bin-log的哪個位置開始往後的日誌內容，請發給我”!

4) Slave的Sql進程檢測到relay-log中新增加了內容後，會馬上解析relay-log的內容成為在Master端真實執行時候的那些可執行的內容，並在自身執行

上面提到的是mysql默認的異步同步模式，接下來重點說下Mysql半同步復制，從MySQL5.5開始，MySQL以插件的形式支持半同步復制。先來區別下mysql幾個同步模式概念：

異步復制（Asynchronous replication）
MySQL默認的復制即是異步的，主庫在執行完客戶端提交的事務後會立即將結果返給給客戶端，並不關心從庫是否已經接收並處理，這樣就會有一個問題，主如果crash掉了，此時主上已經提交的事務可能並沒有傳到從上，如果此時，強行將從提升為主，可能導致新主上的數據不完整。

全同步復制（Fully synchronous replication）
指當主庫執行完一個事務，所有的從庫都執行了該事務才返回給客戶端。因為需要等待所有從庫執行完該事務才能返回，所以全同步復制的性能必然會收到嚴重的影響。

半同步復制（Semisynchronous replication）
介於異步復制和全同步復制之間，主庫在執行完客戶端提交的事務後不是立刻返回給客戶端，而是等待至少一個從庫接收到並寫到relay log中才返回給客戶端。相對於異步復制，半同步復制提高了數據的安全性，同時它也造成了一定程度的延遲，這個延遲最少是一個TCP/IP往返的時間。所以，半同步復制最好在低延時的網絡中使用。

下面來看看半同步復制的原理圖：

半同步復制的潛在問題
客戶端事務在存儲引擎層提交後，在得到從庫確認的過程中，主庫宕機了，此時，可能的情況有兩種
- 事務還沒發送到從庫上
此時，客戶端會收到事務提交失敗的信息，客戶端會重新提交該事務到新的主上，當宕機的主庫重新啟動後，以從庫的身份重新加入到該主從結構中，會發現，該事務在從庫中被提交了兩次，一次是之前作為主的時候，一次是被新主同步過來的。
- 事務已經發送到從庫上
此時，從庫已經收到並應用了該事務，但是客戶端仍然會收到事務提交失敗的信息，重新提交該事務到新的主上。

無數據丟失的半同步復制
針對上述潛在問題，MySQL 5.7引入了一種新的半同步方案：Loss-Less半同步復制。針對上面這個圖，"Waiting Slave dump"被調整到"Storage Commit"之前。當然，之前的半同步方案同樣支持，MySQL 5.7.2引入了一個新的參數進行控制: rpl_semi_sync_master_wait_point, 這個參數有兩種取值：1) AFTER_SYNC , 這個是新的半同步方案，Waiting Slave dump在Storage Commit之前。2) AFTER_COMMIT, 這個是老的半同步方案。

半同步復制的安裝部署條件
要想使用半同步復制，必須滿足以下幾個條件：
1）MySQL 5.5及以上版本！
2）變量have_dynamic_loading為YES （查看命令：show variables like "have_dynamic_loading";）
3） 異步復制已經存在！（即提前部署mysql主從復制環境）

- 首先加載插件
因用戶需執行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後的命令行操作，也可寫在my.cnf配置文件中。
主數據庫的my.cnf配置文件中添加:

plugin-load=rpl_semi_sync_master=semisync_master.so
rpl_semi_sync_master_enabled=1

從數據庫的my.cnf配置文件中添加:

plugin-load=rpl_semi_sync_slave=semisync_slave.so
rpl_semi_sync_slave_enabled=1

在個別高可用架構下，master和slave需同時啟動，以便在切換後能繼續使用半同步復制！即在主從數據庫的my.cnf配置文件中都要添加:

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角色。這時候，主的error.log中會打印如下信息:

2019-01-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).
2019-01-05T10:03:40.111175Z 4 [Note] Stop asynchronous binlog_dump to slave (server_id: 2)
2019-01-05T10:03:40.119037Z 5 [Note] Start binlog_dump to master_thread_id(5) slave_server(2), pos(mysql-bin.000003, 621)
2019-01-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半同步復制環境就部署完成了！

需要註意下，其實Mysql半同步復制並不是嚴格意義上的半同步復制。當半同步復制發生超時時（由rpl_semi_sync_master_timeout參數控制，單位是毫秒，默認為10000，即10s），會暫時關閉半同步復制，轉而使用異步復制。當master dump線程發送完一個事務的所有事件之後，如果在rpl_semi_sync_master_timeout內，收到了從庫的響應，則主從又重新恢復為半同步復制。

mysql> show variables like "rpl_semi_sync_master_timeout";
+------------------------------+-------+
| Variable_name                | Value |
+------------------------------+-------+
| rpl_semi_sync_master_timeout | 10000 |
+------------------------------+-------+
1 row in set (0.01 sec)

接下來可以測試下:

1) 主數據庫 （從數據庫在執行"stop slave"之前）

mysql> create database bobo;
Query OK, 1 row affected (0.05 sec)

mysql> create table bobo.ceshi(id int);
Query OK, 0 row affected (0.28 sec)

mysql> insert into bobo.ceshi values(1);
Query OK, 1 row affected (0.09 sec)

2) 從數據執行"stop slave"

mysql> stop slave;

再觀察主數據庫

mysql> insert into bobo.ceshi values(2);
Query OK, 1 row affected (10.01 sec)

mysql> show status like ‘Rpl_semi_sync_master_status‘;
+-----------------------------+-------+
| Variable_name               | Value |
+-----------------------------+-------+
| Rpl_semi_sync_master_status | OFF   |
+-----------------------------+-------+
1 row in set (0.00 sec)

查看從數據庫

mysql> show status like ‘Rpl_semi_sync_slave_status‘;
+-----------------------------+-------+
| Variable_name               | Value |
+-----------------------------+-------+
| Rpl_semi_sync_slave_status  | OFF   |
+-----------------------------+-------+
1 row in set (0.01 sec)

3) 接著再在從數據庫執行"start slave"

mysql> start slave;

再觀察主數據

mysql> insert into bobo.ceshi values(3);
Query OK, 1 row affected (0.00 sec)

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.00 sec)

以上驗證分為三個階段:
1) 在Slave執行stop slave之前，主的insert操作很快就能返回。
2) 在Slave執行stop slave後，主的insert操作需要10.01s才返回，而這與rpl_semi_sync_master_timeout參數的時間相吻合。這時，查看兩個狀態的值，均為“OFF”了。同時，主的error.log中打印如下信息:

2019-01-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.
2019-01-05T11:51:49.855742Z 6 [Note] Semi-sync replication switched OFF.

3) 在Slave執行start slave後，主的insert操作很快就能返回，此時，兩個狀態的值也變為“ON”了。同時，主的error.log中會打印如下信息:

2019-01-05T11:52:40.477098Z 7 [Note] Start binlog_dump to master_thread_id(7) slave_server(2), pos(mysql-bin.000003, 1196)
2019-01-05T11:52:40.477168Z 7 [Note] Start semi-sync binlog_dump to slave (server_id: 2), pos(mysql-bin.000003, 1196)
2019-01-05T11:52:40.523475Z 0 [Note] Semi-sync replication switched ON at (mysql-bin.000003, 1447)

其他變量說明

環境變量（show variables like ‘%Rpl%‘;）

mysql> show variables like ‘%Rpl%‘;
+-------------------------------------------+------------+
| Variable_name                             | Value      |
+-------------------------------------------+------------+
| rpl_semi_sync_master_enabled              | ON         |
| rpl_semi_sync_master_timeout              | 10000      |
| rpl_semi_sync_master_trace_level          | 32         |
| rpl_semi_sync_master_wait_for_slave_count | 1          |
| rpl_semi_sync_master_wait_no_slave        | ON         |
| rpl_semi_sync_master_wait_point           | AFTER_SYNC |
| rpl_stop_slave_timeout                    | 31536000   |
+-------------------------------------------+------------+
7 rows in set (0.30 sec)

rpl_semi_sync_master_wait_for_slave_count
MySQL 5.7.3引入的，該變量設置主需要等待多少個slave應答，才能返回給客戶端，默認為1。

rpl_semi_sync_master_wait_no_slave
ON
默認值，當狀態變量Rpl_semi_sync_master_clients中的值小於rpl_semi_sync_master_wait_for_slave_count時，Rpl_semi_sync_master_status依舊顯示為ON。

OFF
當狀態變量Rpl_semi_sync_master_clients中的值於rpl_semi_sync_master_wait_for_slave_count時，Rpl_semi_sync_master_status立即顯示為OFF，即異步復制。

簡單來說，如果mysql架構是1主2從，2個從都采用了半同步復制，且設置的是rpl_semi_sync_master_wait_for_slave_count=2，如果其中一個掛掉了，對於rpl_semi_sync_master_wait_no_slave設置為ON的情況，此時顯示的仍然是半同步復制，如果rpl_semi_sync_master_wait_no_slave設置為OFF，則會立刻變成異步復制。

狀態變量（show status like ‘%Rpl_semi%‘;）

mysql> show status like ‘%Rpl_semi%‘;
+--------------------------------------------+-------+
| Variable_name                              | Value |
+--------------------------------------------+-------+
| Rpl_semi_sync_master_clients               | 1     |
| Rpl_semi_sync_master_net_avg_wait_time     | 0     |
| Rpl_semi_sync_master_net_wait_time         | 0     |
| Rpl_semi_sync_master_net_waits             | 6     |
| Rpl_semi_sync_master_no_times              | 1     |
| Rpl_semi_sync_master_no_tx                 | 1     |
| Rpl_semi_sync_master_status                | ON    |
| Rpl_semi_sync_master_timefunc_failures     | 0     |
| Rpl_semi_sync_master_tx_avg_wait_time      | 1120  |
| Rpl_semi_sync_master_tx_wait_time          | 4483  |
| Rpl_semi_sync_master_tx_waits              | 4     |
| Rpl_semi_sync_master_wait_pos_backtraverse | 0     |
| Rpl_semi_sync_master_wait_sessions         | 0     |
| Rpl_semi_sync_master_yes_tx                | 4     |
+--------------------------------------------+-------+
14 rows in set (0.00 sec)

Rpl_semi_sync_master_clients
當前半同步復制從的個數，如果是一主多從的架構，並不包含異步復制從的個數。

Rpl_semi_sync_master_no_tx
The number of commits that were not acknowledged successfully by a slave.
具體到上面的測試中，指的是insert into bobo.ceshi values(2)這個事務。

Rpl_semi_sync_master_yes_tx
The number of commits that were acknowledged successfully by a slave.
具體到上面的測試中，指的是以下四個事務:
mysql> create database bobo;
mysql> create table bobo.ceshi(id int);
mysql> insert into bobo.ceshi values(1);
mysql> insert into bobo.ceshi values(3);

簡單總結：
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的反饋。

Mysql半同步復制模式說明 - 運維小結