mysql5.7 开启增强半同步复制

前提是主从异步复制环境要提前搭建好,然后再开启mysql增强半同步

环境:mysql5.7.26 主从异步复制早已部署好。

1.加载plugin插件

建议master和slave上全部执行(考虑到MHA的主从自动切换的环境)

在主库安装semisync_master.so和semisync_slave.so插件:

mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME ‘semisync_master.so‘;
mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME ‘semisync_slave.so‘;

linux服务器上的master库执行:

[email protected] [(none)]>INSTALL PLUGIN rpl_semi_sync_master SONAME ‘semisync_master.so‘;
Query OK, 0 rows affected (4.52 sec)
[email protected] [(none)]>INSTALL PLUGIN rpl_semi_sync_slave SONAME ‘semisync_slave.so‘;
Query OK, 0 rows affected (0.07 sec)

linux服务器上的slave库执行:

[email protected] [(none)]>INSTALL PLUGIN rpl_semi_sync_master SONAME ‘semisync_master.so‘;
ERROR 1125 (HY000): Function ‘rpl_semi_sync_master‘ already exists
[email protected] [(none)]>INSTALL PLUGIN rpl_semi_sync_slave SONAME ‘semisync_slave.so‘;
ERROR 1125 (HY000): Function ‘rpl_semi_sync_slave‘ already exists
[email protected] [(none)]>

提示:slave上增强半同步的插件已经存在,所以报错。
原因:master上安装增强半同步的插件后自动同步到了slave库上

2.slave和master开启增强半同步参数

生产环境上建议先在slave库上的开启 增强半同步参数

set global rpl_semi_sync_slave_enabled =1;
stop  slave io_thread;start  slave io_thread;

此刻观察master的错误日志:提示开启了Semi-sync replication 复制

2019-06-16T20:31:28.923731+08:00 718 [Note] While initializing dump thread for slave with UUID <7659cf56-8e81-11e9-bcbd-842b2b5999d9>, found a zombie dump thread with the same UUID. Master is killing the zombie dump thread(717).
2019-06-16T20:31:28.923838+08:00 717 [Note] Stop asynchronous binlog_dump to slave (server_id: 113306)
2019-06-16T20:31:28.923951+08:00 718 [Note] Start binlog_dump to master_thread_id(718) slave_server(113306), pos(, 4)
2019-06-16T20:31:28.923984+08:00 718 [Note] Start semi-sync binlog_dump to slave (server_id: 113306), pos(, 4)
2019-06-16T20:31:29.189007+08:00 718 [Note] Semi-sync replication switched ON at (mysql-bin.000005, 852045921)

然后master上再开启增强半同步参数


set global rpl_semi_sync_master_enabled =1
set global rpl_semi_sync_master_timeout        =1000

3.MySQL官网配置方法

官方要求master和slave的/etc/my.cnf要开启下面的参数:

rpl_semi_sync_master_enabled        =1                             #    0
rpl_semi_sync_slave_enabled         =1                             #    0
rpl_semi_sync_master_timeout        =1000                          #    1000(1 second) 同步复制中由于网络原因导致复制时间超过1s后,增强半同步复制就变成了异步复制了
rpl_semi_sync_master_wait_for_slave_count=N
plugin_load_add                     =semisync_master.so            #
plugin_load_add                     =semisync_slave.so             #

重启master和slave数据库。

4.实际生产环境配置方法

当然实际操作中还是不建议把参数rpl_semi_sync_master_enabled 和rpl_semi_sync_slave_enabled 直接写入配置文件的。
原因:把参数加入my.cnf配置文件时,在slave库挂掉,重新开启slave库或者是slave库重启后,会自动开启增强半同步复制。
如果在slave库断开master库时间较长时,最好是先开启mysql异步复制,让slave库追赶上master库后,然后再开启增强半同步复制。这样不会拖垮master库。要是直接开启增强半同步复制是会拖垮主库的。
rpl_semi_sync_master_timeout =1000 ##1s 这个转化为异步复制的超时参数是可以写入配置文件的。

5.演示增强半同步超时被关闭

演示增强半同步复制超过设定的时间被关闭:

在master上设置超时时间

mysql> set global rpl_semi_sync_master_timeout=20000;  ##为20s

在slave上停止io_thread 线程

mysql> stop slave io_thread;

然后在master库上删除一个测试库来演示增强半同步关闭:

mysql> drop database test02;  ##删除test02库卡盾超时20s 才执行成功。
Query OK, 0 rows affected (20.00 sec)

在卡盾的20s期间,在master库上执行show proccesslist,发现这期间,master库一直在等待slave的 semi-sync 的ack的响应:

mysql>  show processlist;
+-----+-----------------+-----------+------+---------+--------+--------------------------------------+----------------------+
| Id  | User            | Host      | db   | Command | Time   | State                                | Info                 |
+-----+-----------------+-----------+------+---------+--------+--------------------------------------+----------------------+
|   1 | event_scheduler | localhost | NULL | Daemon  | 185099 | Waiting on empty queue               | NULL                 |
| 700 | root            | localhost | NULL | Query   |      3 | Waiting for semi-sync ACK from slave | drop database test02 |
| 703 | root            | localhost | NULL | Query   |      0 | starting                             | show processlist     |
| 709 | root            | localhost | NULL | Sleep   |    999 |                                      | NULL                 |
+-----+-----------------+-----------+------+---------+--------+--------------------------------------+----------------------+
4 rows in set (0.00 sec)

此时查看master库的错误日志关闭了增强半同步复制:

2019-06-16T18:58:38.249020+08:00 0 [ERROR] ./mysqld: Got an error reading communication packets      ###这个报错是slave库 stop  slave io_thread导致的
2019-06-16T18:59:14.870329+08:00 711 [ERROR] Semi-sync master failed on net_flush() before waiting for slave reply
2019-06-16T18:59:14.870409+08:00 711 [Note] Stop semi-sync binlog_dump to slave (server_id: 113306)
2019-06-16T18:59:14.870469+08:00 711 [Note] Aborted connection 711 to db: ‘unconnected‘ user: ‘rept‘ host: ‘192.168.0.11‘ (Found net error)
2019-06-16T18:59:34.870253+08:00 703 [Warning] Timeout waiting for reply of binlog (file: mysql-bin.000004, pos: 422036), semi-sync up to file mysql-bin.000004, position 421882.
2019-06-16T18:59:34.870298+08:00 703 [Note] Semi-sync replication switched OFF.

当超过master库上设定的20s超时时间后,增强半同步复制被关闭了。Waiting for semi-sync ACK from slave 消失

mysql>  show processlist;
+-----+-----------------+-----------+------+---------+--------+------------------------+------------------+
| Id  | User            | Host      | db   | Command | Time   | State                  | Info             |
+-----+-----------------+-----------+------+---------+--------+------------------------+------------------+
|   1 | event_scheduler | localhost | NULL | Daemon  | 185120 | Waiting on empty queue | NULL             |
| 700 | root            | localhost | NULL | Sleep   |      4 |                        | NULL             |
| 703 | root            | localhost | NULL | Query   |      0 | starting               | show processlist |
| 709 | root            | localhost | NULL | Sleep   |   1020 |                        | NULL             |
+-----+-----------------+-----------+------+---------+--------+------------------------+------------------+
4 rows in set (0.00 sec)

接着在master上删除test01库时不再出现卡盾,说明增强半同步复制已经被关闭了

mysql> drop database test01;
Query OK, 2 rows affected (0.00 sec)
此时在maser查看当前增强半同步复制中有几个slave client,发现已没有client链接

mysql> show global status like "Rpl_semi_sync_master_clients";
+------------------------------+-------+
| Variable_name                | Value |
+------------------------------+-------+
| Rpl_semi_sync_master_clients | 0     |
+------------------------------+-------+
1 row in set (0.01 sec)

在slave上开启 io_thread

mysql> start slave io_thread;
Query OK, 0 rows affected (0.00 sec)

查看master库上的错误日志:

2019-06-16T19:10:46.656964+08:00 713 [Note] Start binlog_dump to master_thread_id(713) slave_server(113306), pos(, 4)
2019-06-16T19:10:46.657003+08:00 713 [Note] Start semi-sync binlog_dump to slave (server_id: 113306), pos(, 4)
2019-06-16T19:10:46.670872+08:00 0 [Note] Semi-sync replication switched ON at (mysql-bin.000004, 422366)

提示增强半同步有开启了。

master 查看半同步链接状态新增了1个:

mysql> show global status like "Rpl_semi_sync_master_clients";
+------------------------------+-------+
| Variable_name                | Value |
+------------------------------+-------+
| Rpl_semi_sync_master_clients | 1     |
+------------------------------+-------+
1 row in set (0.00 sec)

mysql> 

6.观察master库错误日志的变化

6.1 slave库关闭io 线程,再关闭半同步复制,然后再开启 slave 的io_thread线程

mysql> stop slave io_thread;
Query OK, 0 rows affected (0.00 sec)

mysql> set global rpl_semi_sync_slave_enabled=0 ;
Query OK, 0 rows affected (0.00 sec)

mysql> start slave io_thread;
Query OK, 0 rows affected (0.00 sec)
mysql> 

此刻观察master库的错误日志:

2019-06-16T20:35:14.463978+08:00 0 [ERROR] ./mysqld: Got an error reading communication packets
2019-06-16T20:35:44.309080+08:00 719 [Note] While initializing dump thread for slave with UUID <7659cf56-8e81-11e9-bcbd-842b2b5999d9>, found a zombie dump thread with the same UUID. Master is killing the zombie dump thread(718).
2019-06-16T20:35:44.309252+08:00 718 [Note] Stop semi-sync binlog_dump to slave (server_id: 113306)
2019-06-16T20:35:44.309724+08:00 719 [Note] Start binlog_dump to master_thread_id(719) slave_server(113306), pos(, 4)
2019-06-16T20:35:44.309740+08:00 719 [Note] Start asynchronous binlog_dump to slave (server_id: 113306), pos(, 4)

6.2 slave库关闭io 线程,等待20s后然后再关闭半同步复制,然后再开启 slave 的io_thread线程

此刻观察master库的错误日志:

2019-06-16T20:39:18.806715+08:00 0 [ERROR] ./mysqld: Got an error reading communication packets

2019-06-16T20:39:58.854194+08:00 720 [Note] Stop semi-sync binlog_dump to slave (server_id: 113306)
2019-06-16T20:39:58.854305+08:00 720 [Note] Aborted connection 720 to db: ‘unconnected‘ user: ‘rept‘ host: ‘192.168.0.11‘ (failed on flush_net())

2019-06-16T20:41:06.636868+08:00 721 [Note] Start binlog_dump to master_thread_id(721) slave_server(113306), pos(, 4)
2019-06-16T20:41:06.636902+08:00 721 [Note] Start asynchronous binlog_dump to slave (server_id: 113306), pos(, 4)

发现6.1和6.2的错误日志还是有不同的地方的

7.案例

当线上运行的MySQL增强半同步复制架构中,当其中的一台slave库挂掉了应该如何正确重新添加到原先的增强半同步复制架构??

正确的做法如下:

1. 此2个参数rpl_semi_sync_master_enabled  和rpl_semi_sync_slave_enabled  不要直接写入到my.cnf配置文件开启。
2.在slave库上先 stop slave io_thread ;set global  rpl_semi_sync_slave_enabled=0 关闭此参数。然后start slave io_thread 或者start slave 开启异步复制,让slave库追赶上master库。
3.然后在slave库 set global  rpl_semi_sync_slave_enabled=1 ;stop  slave io_thread;start  slave  io_thread;

演示到此处,欢迎留言一起交流学习。

原文地址:https://blog.51cto.com/wujianwei/2409754

时间: 2024-10-14 12:57:54

mysql5.7 开启增强半同步复制的相关文章

MySQL5.7 大大降低了半同步复制-数据丢失的风险

如果你的生产线开启了半同步复制,那么对数据的一致性会要求较高,但在MySQL5.5/5.6里,会存在数据不一致的风险.有这么一个场景,客户端提交了一个事务,master把binlog发送给slave,在发送的期间,网络出现波动,此时Binlog Dump线程发送就会卡住,要等待slave把binlog写到本地的relay-log里,然后给master一个反馈,等待的时间以rpl_semi_sync_master_timeout参数为准,默认为10秒.在这等待的10秒钟里,在其他会话里,查看刚才的

mysql5.623 GTID主从复制+半同步复制安装与配置

一.GTID简介 什么是GTID GTID(Global Transaction ID)是对于一个已提交事务的编号,并且是一个全局唯一的编号.GTID实际上是由UUID+TID组成的.其中UUID是一个MySQL实例的唯一标识.TID代表了该实例上已经提交的事务数量,并且随着事务提交单调递增.下面是一个GTID的具体形式 3E11FA47-71CA-11E1-9E33-C80AA9429562:23 更详细的介绍可以参见:官方文档 GTID的作用 那么GTID功能的目的是什么呢?具体归纳主要有以

mysql5.6 semi replication 半同步复制配置

--###半同步配置--1.插件位置mysql> show variables like 'plugin_dir' -> ;+---------------+------------------------------+| Variable_name | Value |+---------------+------------------------------+| plugin_dir | /usr/local/mysql/lib/plugin/ |+---------------+----

MySQL 5.7 新特性之增强半同步复制

1. 背景介绍 半同步复制 普通的replication,即mysql的异步复制,依靠mysql二进制日志也即binary log进行数据复制.比如两台机器,一台主机(master),另外一台是从机(slave). 正常的复制为:事务一(t1)写入binlog buffer:dumper 线程通知slave有新的事务t1:binlog buffer 进行checkpoint:slave的io线程接收到t1并写入到自己的的relay log:slave的sql线程写入到本地数据库. 这时,mast

mysql5.7.19的半同步复制问题分享

=== 异步复制(Asynchronous replication) MySQL默认的复制即是异步的,主库在执行完客户端提交的事务后会立即将结果返给给客户端,并不关心从库是否已经接收并处理,这样就会有一个问题,主如果crash掉了,此时主上已经提交的事务可能并没有传到从上,如果此时,强行将从提升为主,可能导致新主上的数据不完整. 全同步复制(Fully synchronous replication) 指当主库执行完一个事务,所有的从库都执行了该事务才返回给客户端.因为需要等待所有从库执行完该事

mysql-5.6.x半同步复制配置

本文环境   主库:CentOS6.5 x64 192.168.0.65 mysql-5.6.29    备库:CentOS6.5 x64 192.168.0.66 mysql-5.6.29 接上文: mysql-5.6主从同步配置示例http://koumm.blog.51cto.com/703525/1764093 半同步复制的概念:    mysql5.5.x以上版本支持半同步复制,当Slave主机连接到Master时,能够查看其是否处于半同步复制的机制.当Master上开启半同步复制的功

MySQL 5.7的复制架构,在有异步复制、半同步、增强半同步、MGR等的生产中,该如何选择?

一.生产环境中: 几种复制场景都有存在的价值.下面分别描述一下: 从成熟度上来选择,推荐:异步复制(GTID+ROW) 从数据安全及更高性能上选择:增强半同步 (在这个结构下也可以把innodb_flush_log_trx_commit调整到非1, 从而获得更好的性能) 对于主从切换控制觉的不好管理,又对数据一致性要求特别高的场景,可以使用MGR 二.理由: 异步复制,相对来讲非常成熟,对于环境运维也比较容易上手 增强半同步复制,可以安全的保证数据传输到从库上,对于单节点的配置上不用要求太严格,

mysql 半同步复制

半同步复制 (1).半同步复制原理. 在半同步复制架构中,主机会确保当前的事务至少已经发送到一个备机中(不等待事务重做完成), 才会返回消息到客户端.如果在设置的时间内,事务日志还没传送到备机,那么半同步会变成异步复制. (2).半同步复制的和异步复制的区别: 异步复制:主机不会去检测事务日志是否已经传动到备机,就返回消息到客户端.在高负载的系统中丢失数据的风险比较大. 半同步复制;主机会检测事务日志是否已经至少传送到一个备机中,如果在设置的时间内一直没有传送到一个备机中, 主机不会返回消息到客

mysql5.5 读写分离 半同步

读写分离 一般我们从服务器端是只负责客户的读请求的,主服务端负责写请求的.那么配置下吧!    首先查看下从服务器端的只读方式是否打开.    mysql> show global variables like 'read%';    +----------------------+---------+    | Variable_name        | Value   |    +----------------------+---------+    | read_buffer_size