MySQL半同复制

打MySQL5.5方始,MySQL以插件的样式支持半同步复制。如何理解半一块啊?首先我们来探望异步,全同台的概念

 

异步复制(Asynchronous replication)

MySQL默认的复制即凡是异步的,主库在实践完客户端提交的工作后会立刻将结果返回给被客户端,并无关心从库是否都吸收并拍卖,这样即使会见时有发生一个问题,主如果crash掉了,此时主上已经交付的事体可能连从未传来从达到,如果这时,强行以由提升为主,可能导致新主上的多少未完全。

 

统统旅复制(Fully synchronous replication)

指当主库执行了一个作业,所有的从库都尽了该事务才回去给客户端。因为待等所有从库执行完毕该工作才能够回,所以全同步复制的性必然会吸纳严重的影响。

 

一半同步复制(Semisynchronous replication)

介于异步复制与咸同台复制之间,主库在实施完客户端提交的事务后非是就回到给客户端,而是等至少一个从库接收到连写及relay
log中才回来给客户端。相对于异步复制,半协同复制提高了数量的安全性,同时它也造成了自然水准的延,这个延迟最少是一个TCP/IP往返的时光。所以,半联合复制最好当低延时之大网中采用。

 

下来探望半伙复制的法则图:

 MySQL 1

 

 

一半合复制的暧昧问题

客户端事务在存储引擎层提交后,在博从库确认之过程被,主库宕机了,此时,可能的事态时有发生半点种

 

业务还未曾发送到由仓库上

这儿,客户端会收到工作提交失败的音讯,客户端会重新提交该事务及新的主上,当宕机的主库重新开动后,以从仓库的地位重新加入到该主从构造面临,会意识,该业务在由仓库中让交给了区区糟,一糟是事先犯为主的当儿,一赖是给新主同步过来的。

 

事情都发送到起仓库上

此时,从库已经接收并应用了拖欠事务,但是客户端仍会收工作提交失败的信息,重新提交该工作及新的主上。

 

诸多准丢失的一半共复制

对上述潜在问题,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;

 

如上之启动方式是当命令行操作,也可写在配置文件被。

主:

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

从:

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角色。

此刻,主的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内,收到了于仓库底应,则着力又再恢复为半共同复制。

 

下面来测试一下

MySQL 2

 

拖欠证分为三个阶段

 

  1. 每当Slave执行stop slave之前,主的insert操作便捷便能回到。

 

  1. 于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.

 

  1. 在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。

 

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,即异步复制。

说得直白一点,如果自身之架是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,则会马上成为异步复制。

 

状态变量

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.
以同样主多打之架构中,如果只要从头启半同步复制,并无要求有的自都是半并复制。

  1. 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的反馈。

 

参考

  1. MariaDB原理与落实

2. http://dev.mysql.com/doc/refman/5.7/en/replication-semisync.html

3. http://sanwen8.cn/p/105GRDe.html

  1. 知数堂《MySQL 5.7 Replication新特性》分享
网站地图xml地图