MySQL半同步複製詳解

MySQL半同步複製詳解

從MySQL5.5開始，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

rpl_semi_sync_master_wait_point有兩種取值

AFTER_SYNC

這個即新的半同步方案，Waiting Slave dump在Storage Commit之前。

AFTER_COMMIT

老的半同步方案，。

半同步複製的安裝部署

要想使用半同步複製，必須滿足以下幾個條件：

1. MySQL 5.5及以上版本

2. 變數have_dynamic_loading為YES

3. 非同步複製已經存在

首先載入外掛程式

因使用者需執行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;

重啟從上的IO線程

mysql> STOP SLAVE IO_THREAD;

mysql> START SLAVE IO_THREAD;

如果沒有重啟，則預設還是非同步複製，重啟後，slave會在master上註冊為半同步複製的slave角色。

這時候，主的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半同步複製搭建完畢~

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

當半同步複製發生逾時時（由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)

其它變數

環境變數

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。

狀態變數

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 test.test values(2)這個事務。

Rpl_semi_sync_master_yes_tx

The number of commits that were acknowledged successfully by a slave.

具體到上面的測試中，指的是以下四個事務

create database test;

create table test.test(id int);

insert into test.test values(1);

insert into test.test 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的反饋。

本文永久更新連結地址：