MySQL主从复制
MySQL主从复制
主从复制的前提
1）两台或两台以上的数据库实例
2）主库要开启二进制日志
3）主库要有复制用户
4）主库的server_id和从库不同 (从库可以相同)
5）从库需要在开启复制功能前，要获取到主库之前的数据（主库备份，并且记录binlog当时位置）
6）从库在第一次开启主从复制时，时必须获知主库：ip，port，user，password，logfile，pos
7）从库要开启相关线程：IO、SQL
8）从库需要记录复制相关用户信息，还应该记录到上次已经从主库请求到哪个二进制日志
9）从库请求过来的binlog，首先要存下来，并且执行binlog，执行过的信息保存下来
主从复制涉及到的文件和线程
主库：
1）主库binlog：记录主库发生过的修改事件
2）dump thread：给从库传送（TP）二进制日志线程
从库：
1）relay-log（中继日志）：存储所有主库TP过来的binlog事件
2）master.info：存储复制用户信息，上次请求到的主库binlog位置点
3）IO thread：接收主库发来的binlog日志，也是从库请求主库的线程
4）SQL thread：执行主库TP过来的日志
原理
1）通过change master to语句告诉从库主库的ip，port，user，password，file，pos
2）从库通过start slave命令开启复制必要的IO线程和SQL线程
3）从库通过IO线程拿着change master to用户密码相关信息，连接主库，验证合法性
4）从库连接成功后，会根据binlog的pos问主库，有没有比这个更新的
5）主库接收到从库请求后，比较一下binlog信息，如果有就将最新数据通过dump线程给从库IO线程
6）从库通过IO线程接收到主库发来的binlog事件，存储到TCP/IP缓存中，并返回ACK更新master.info
7）将TCP/IP缓存中的内容存到relay-log中
8）SQL线程读取relay-log.info，读取到上次已经执行过的relay-log位置点，继续执行后续的relay-log日志，执行完成后，更新relay-log.info
演示主从复制
服务器ip 172.16.1.51
vim /etc/my.cnf
[mysqld]
server_id=1
log_bin=mysql-bin
binlog_format=row
重启mysql
查看主库binlog信息 记录文件名和位置点
mysql> show binary logs;| show master logs; | show master status;
#主库创建主从复制用户
mysql> create user replmysql@'172.16.1.%' identified by 'echo';
mysql> grant replication slave on *.* to replmysql@'172.16.1.%';
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
#查看是否开启binlog
mysql> show variables like 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin | ON |
+---------------+-------+
#锁表进行备份保证主库从库数据一致(锁表备份)
mysql> flush table with read lock;
[root@db02 ~]\# mysqldump -uroot -p -A -R --triggers --master-data=1 > /root/full.sql
#解除主库锁表(如果主库备份时锁表了需要解锁)
mysql> unlock tables;
#不锁表备份
[root@db02 ~]\# mysqldump -uroot -p -A -R --triggers --single-transaction --master-data=1 > /root/full.sql #因为加了master-data参数 从库配置master_log 和pos 时直接使用此位置点
#或者使用xtrabackup做全备然后从库中恢复(主库执行)
innobackupex --user=root --socket=/data/mysql.sock --password=echo --no-timestamp /backup/full
#(导入到从库服务器中执行)
innobackupex --apply-logs /backup/full && innobackupex --copy-back /backup/full
从库配置
vim /etc/my.cnf
[mysqld]后加入
server_id=2 #必须开启,且唯一
log_bin=mysql-bin #可不开启,如果级联复制本节点为中间节点时,必须打开
log_slave_updates #单主从无需开启,当级联复制时,如果级联复制本节点为中间节点时,必须打开(MySQL8.0默认开启)
binlog_format=row
read_only=on #设置从库普通用户只读,super user无效
relay_log=relay-log #可选 设置relay_log路径,默认为hostname-relay-log
relay_log_index=relay-log.index #可选 设置relay_log索引文件,默认为hostname-relay-log.index
重启mysql
登录从库进行配置
#方式一:
#导入主库数据
mysql> source /root/full.sql
#执行change master to
mysql> change master to
-> master_host='172.16.1.51',
-> master_user='replmysql',
-> master_password='echo',
-> master_port=3306,
-> master_log_file='mysql-bin.000001',
-> master_log_pos=411;
reset slave 用于删除SLAVE数据库的relaylog日志文件，并重新启用新的relaylog文件；
如果change master 配置错误可以用reset slave 重新配置
#开启从库服务
mysql> start slave
#查看是否开启成功
mysql> show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
#方式二
当主库备份时使用了--master-data=1时,备份的sql文件中会有change master to 语句,在此基础上添加上 master_host,master_user,master_passsword,master_port保存退出
#导入主库数据
mysql> source /root/full.sql
#开启从库服务
mysql> start slave
#查看是否开启成功
mysql> show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
如果开启主从失败报错
error connecting to master 'replmysql@172.16.1.12:3306' - retry-time: 60 retries: 6 message:
Authentication plugin 'caching_sha2_password' reported error:
Authentication requires secure connection.
解决方案
方案一：修改master库的密码加密方式
alter user 'replmysql'@'172.16.1.%' identified with mysql_native_password by 'echo';
方案二：不修改升级加密,设置从库的change master 时加get_master_public_key=1参数
之前准备配置前，查询资料，看到过有人特意设置过get_master_public_key这个参数，加上这个参数再次配置：
1.从库执行 stop slave;
2.清除从库配置：reset slave all;
3.重新配置主库信息
change master to master_host='172.16.1.12', master_user='replmysql', master_password='echo', master_log_file='mysql-bin.000002', master_log_pos=157, get_master_public_key=1;
4.开始复制主库 start slave;
5.查询从库状态：show slave status;
延时从库配置方法
普通的主从复制可能存在不足
1）逻辑损坏怎么办？
2）不能保证主库的操作，从库一定能做
3）高可用？自动failover？
4）过滤复制
企业中一般会延时3-6小时
延时从库配置方法
(在已做好主从复制的前提下)
mysql>stop slave; #停止主从
mysql>CHANGE MASTER TO MASTER_DELAY = 180; #设置延时为180秒
mysql>start slave; #开启主从
mysql> show slave status \G #查看状态
SQL_Delay: 60
3.延时从库停止方法
mysql> stop slave; #停止主从
mysql> CHANGE MASTER TO MASTER_DELAY = 0; #设置延时为0
mysql> start slave; #开启主从
没有做好主从复制的情况下只需在change master 上加入master_delay = 180;
解除从主机方法
stop slave;
reset slave all;
思考问题：
总数据量级500G，正常备份去恢复需要1.5-2小时
1）配置延时3600秒
mysql>CHANGE MASTER TO MASTER_DELAY = 3600;
2）主库
drop database db;
3）怎么利用延时从库，恢复数据？
处理思路
1、从库relaylog存放在datadir目录下
2、mysqlbinlog 可以截取relaylog内容
3、show relay log events in 'db01-relay-bin.000001';
处理的思路：
1）停止SQL线程
mysql> stop slave sql_thread;
2）截取relaylog到误删除之前点
- relay-log.info 获取到上次运行到的位置点，作为恢复起点
- 分析relay-log的文件内容，获取到误删除之前position
模拟故障：
1）关闭延时
mysql -S /data/3308/mysql.sock
mysql> stop slave;
mysql> CHANGE MASTER TO MASTER_DELAY = 0;
mysql> start slave;
2）模拟数据
mysql -S /data/3307/mysql.sock
source /root/world.sql
use world;
create table c1 select * from city;
create table c2 select * from city;
3）开启从库延时5分钟
mysql -S /data/3308/mysql.sock
show slave status \G
mysql>stop slave;
mysql>CHANGE MASTER TO MASTER_DELAY = 300;
mysql>start slave;
mysql -S /data/3307/mysql.sock
use world;
create table c3 select * from city;
create table c4 select * from city;
4）破坏，模拟删库故障。(以下步骤在5分钟内操作完成。)
mysql -S /data/3307/mysql.sock
drop database world;
5）从库，关闭SQL线程
mysql -S /data/3308/mysql.sock
stop slave sql_thread;
6）截取relay-log
#起点：
cd /data/3308/data/
cat relay-log.info
./db01-relay-bin.000002
283
#终点：
mysql> mysql -S /data/3308/mysql.sock
mysql> show relaylog events in 'db01-relay-bin.000002'
db01-relay-bin.000002 | 268047
[mysql_]# mysqlbinlog --start-position=283 --stop-position=268047 /data/3308/data/db01-relay-bin.000002 >/tmp/relay.sql
恢复relay.sql
1）取消从库身份
mysql> stop slave;
mysql> reset slave all;
2）恢复数据
mysql> set sql_log_bin=0;
mysql> source /tmp/relay.sql
mysql> use world
mysql> show tables;
过滤复制
方式1:
主库：
白名单:只记录白名单中列出的库的二进制日志
- binlog-do-db
黑名单：不记录黑名单列出的库的二进制日志
- binlog-ignore-db
方式2:
从库：
白名单：只执行白名单中列出的库或者表的中继日志
replicate-do-db=test 只同步一个库
replicate-do-table=test.t1 只同步一张表
replicate-wild-do-table=test.t2 支持通配符如：test.t*
黑名单：不执行黑名单中列出的库或者表的中继日志
replicate-ignore-db
replicate-ignore-table
replicate-wild-ignore-table 支持通配符如：test.t*
复制过滤配置：
[root@db01 data]# vim /data/3307/my.cnf
[mysqld]
replicate-do-db=world #只同步一个库
mysqladmin -S /data/3307/mysql.sock shutdown #关闭MySQL
mysqld_safe --defaults-file=/data/3307/my.cnf & #启动MySQL
基于GTID的主从复制
gtid是由uuid+tid组成的
GTID（全局事务标识符）在主从复制模式中的优点和缺点如下：
优点：
- 安全性高：GTID 提供了复制安全性，使得主从复制更加可靠。
- 数据一致性：通过 GTID，主库的连续性得到了保证，从而保证了数据的一致性。
- 故障切换时间短：由于 GTID 的引入，故障切换时间更短，服务故障时间降低。
- 简单的搭建主从复制：使用 GTID，可以更简单地进行主从复制的搭建，确保每个事务只会被执行一次。
- 秩序性：GTID 给每一个事务在集群事务的海洋中赋予了秩序，使得 DBA 在运维中做集群变迁时更加方便。
- 快速确定最初提交的事务：根据 GTID，可以快速地确定事务最初是在哪个实例上提交的。
缺点：
- 主从表存储引擎必须一致：在 GTID 模式下，主从表的存储引擎必须一致，否则会导致主备数据不一致。
- 不支持传统复制模式：GTID 不支持传统的复制模式，如跳过错误的语句（sql_slave_skip_counter）。
- 需要主库和从库同时开启和关闭 GTID：在主从模式下，需要主库和从库同时开启和关闭 GTID。
- 不支持某些 SQL 语句：GTID 不支持一些特定的 SQL 语句，如 create table .... as select 语句以及 create/drop temporary table 语句。
- 需要特殊配置：GTID 需要进行一些特殊的配置，如设置 gtid_mode、enforce_gtid_consistency 等参数。
传统主从复制
- binglog: 主库开启binlog 从库不需要开启binlog
- server_id: 主库和从库不同,从库可以相同
- 主库要有主从复制用户,从库不需要
GTID主从先决条件
- binlog: 主库和从库都要开启binlog
- server_id: 主库和从库server-id不同,从库也不能相同
- 要有主从复制用户,从库也必须要有主从复制用户
注：在以往如果是基于binlog日志的主从复制，则必须要记住主库的master状态信息。
mysql> show master status;
+------------------+----------+
| File | Position |
+------------------+----------+
| mysql-bin.000002 | 120 |
+------------------+----------+
开启GTID(主库从库都需要)
#没开启之前先看一下GTID的状态
mysql> show global variables like '%gtid%';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| enforce_gtid_consistency | OFF |
| gtid_executed | |
| gtid_mode | OFF |
| gtid_owned | |
| gtid_purged | |
+--------------------------+-------+
#创建主从复制用户(主从服务器都要创建)
mysql> create user replmysql@"172.16.1.%" identified by 'echo';
mysql> grant replication slave privileges on *.* to replmysql%'172.16.1.%';
mysql> flush privileges;
#编辑mysql配置文件（主库从库都需要修改）
[root@mysql-db01 ~]\# vim /etc/my.cnf
#在[mysqld]标签下添加
[mysqld]
server_id=1 #serverid不可重复
log_bin=mysql-bin
binlog_format=row
read_only=1 #从库视情况开启只读
gtid_mode=ON #开启GTID
log_slave_updates #从库更新binlog (MySQL5.6之前需要开启,之后默认开启)
enforce_gtid_consistency #设置 GTID 校验 强制一致性
#重启数据库
[root@mysql-db01 ~]\# systemctl restart mysqld
#检查GTID状态
mysql> show global variables like '%gtid%';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| enforce_gtid_consistency | ON | #执行GTID一致
| gtid_executed | |
| gtid_mode | ON | #开启GTID模块
| gtid_owned | |
| gtid_purged | |
+--------------------------+-------+
注：主库从库都需要开启GTID否则在做主从复制的时候就会报错：
[root@mysql-db02 ~]\# mysql -uroot -pecho
mysql> change master to
-> master_host='172.16.1.51',
-> master_user='replmysql',
-> master_password='echo',
-> master_auto_position=1;
ERROR 1777 (HY000): CHANGE MASTER TO MASTER_AUTO_POSITION = 1 can only be executed when @@GLOBAL.GTID_MODE = ON.
配置主从复制
#登录数据库
[root@mysql-db02 ~]\#mysql -uroot -pecho
#配置复制主机信息
mysql> change master to
#主库IP
-> master_host='172.16.1.51',#主库复制用户
-> master_user='replmysql',#主库复制用户
-> master_password='echo',#主库复制用户密码
-> master_auto_position=1; #GTID位置点
mysql> start slave; #开启slave
#查看slave状态
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 172.16.1.51
Master_User: replmysql
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000003
Read_Master_Log_Pos: 403
Relay_Log_File: mysql-db02-relay-bin.000002
Relay_Log_Pos: 613
Relay_Master_Log_File: mysql-bin.000003
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
半同步复制
从MYSQL5.5开始，支持半自动复制。之前版本的MySQL Replication都是异步（asynchronous）的，主库在执行完一些事务后，是不会管备库的进度的。如果备库不幸落后，而更不幸的是主库此时又出现Crash（例如宕机），这时备库中的数据就是不完整的。简而言之，在主库发生故障的时候，我们无法使用备库来继续提供数据一致的服务了。
半同步复制（Semi synchronous Replication）则一定程度上保证提交的事务已经传给了至少一个备库。
出发点是保证主从数据一致性问题，安全的考虑。
当主机提交了事务后，只需要等一台从机执行完成以后就返回给客户端。相对于异步复制，半同步复制牺牲了一定的性能，提高了数据的安全性。
半同步复制的原理
客户端给主机发送事务操作，主机提交了事务后，主机发送binlog日志给从机，从机写入到中继日志relay log里面， 然后告诉主机已经接收完毕，这时主机才返回给客户端执行完毕。
半同步复制有两种方式，
- AFTER_SYNC：在接收到备库确认信息后将事务提交。默认方式这种方式下，主库把日志写入binlog，并且复制给从库，然后开始等待从库的响应。从库返回成功后，主库再提交事务，接着给客户端返回一个成功响应。
- AFTER_COMMIT：在接收到备库确认信息前将事务提交。这种方式，在主库写入binlog后，等待binlog复制到从库，主库就提交自己的本地事务，再等待从库返回给自己一个成功响应，然后主库再给客户端返回响应
这里有一个问题：假如从机一直宕机，那么主机不是就卡着了吗？ 并不会，当主机发现从机响应超时，主机会自动切换恒异步复制模式，直到下一次同步没有超时再转换成半同步复制。
5.5 出现概念，但是不建议使用，性能太差（需要从库sql线程执行完成后，再给从库io线程返回ack 然后io现在再去主库取数据，期间主库会被阻塞）
5.6出现group commit 组提交功能，来提升开启半同步复制的性能
5.7更加完善了，在group commit基础上出现了MGR
5.7的增强半同步复制的新特性：after commit； after sync；
官网传送门
https://dev.mysql.com/doc/refman/8.0/en/replication-semisync.html
半同步复制开启方法
1）安装（主库）
#登录数据库
[root@db01 ~]# mysql -uroot -p
#查看是否有动态支持
mysql> show global variables like 'have_dynamic_loading'; | SELECT @@have_dynamic_loading;
#安装自带插件
#语法格式:
INSTALL PLUGIN plugin_name SONAME 'shared_library_name'
mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
#查看插件是否安装启用
mysql> select plugin_name,plugin_status from information_schema.plugins where plugin_name like "%semi%";
#启动插件
mysql> SET GLOBAL rpl_semi_sync_master_enabled = 1;
#查看插件
mysql> show plugins;
#设置超时
mysql> SET GLOBAL rpl_semi_sync_master_timeout = 1000;
#修改配置文件
[root@db01 ~]# vim /etc/my.cnf
#在[mysqld]标签下添加如下内容
[mysqld]
server_id=2 #必须开启,且唯一
log_bin=mysql-bin
binlog_format=row
relay_log=relay-log #可选 设置relay_log路径,默认为hostname-relay-log
relay_log_index=relay-log.index #可选 设置relay_log索引文件,默认为hostname-relay-log.index
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout=1000 #半同步时间阈值(毫秒),超出阈值后也会返回成功信息给客户端
#重启MySQL
mysql> systemctl restart mysqld
#检查安装：
mysql> show variables like'rpl%';
mysql> show global status like 'rpl_semi%';
#查看binary日志
mysql> show master logs;
#创建复制用户
mysql> create user replmysql@'172.16.1.%' identified by 'echo';
mysql> grant replication slave on *.* to replmysql@'172.16.1.%';
mysql> flush privileges;
rpl_semi_sync_master_timeout=milliseconds #设置此参数值（ms）,为了防止半同步复制在没有收到确认的情况下发生堵塞，如果Master在超时之前没有收到任何确认，将恢复到正常的异步复制，并继续执行没有半同步的复制操作。
rpl_semi_sync_master_wait_no_slave={ON|OFF} #如果一个事务被提交,但Master没有任何Slave的连接，这时不可能将事务发送到其它地方保护起来。默认情况下，Master会在时间限制范围内继续等待Slave的连接，并确认该事务已经被正确的写到磁盘上。
可以使用此参数选项关闭这种行为，在这种情况下，如果没有Slave连接，Master就会恢复到异步复制。
2）安装（从库）
#登录数据库
[root@mysql-db02 ~]\#mysql -uroot -p
#安装slave半同步插件
mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
#查看插件是否安装启用
[mysql]> select plugin_name,plugin_status from information_schema.plugins where plugin_name like "%semi%";
或者
show plugins;
#编辑配置文件
[root@mysql-db02 ~]\#vim /etc/my.cnf
#在[mysqld]标签下添加如下内容
[mysqld]
server_id=3 #必须开启,且唯一
log_bin=mysql-bin #可不开启,如果级联复制本节点为中间节点时,必须打开
binlog_format=row
relay_log=relay-log #可选 设置relay_log路径,默认为hostname-relay-log
relay_log_index=relay-log.index #可选 设置relay_log索引文件,默认为hostname-relay-log.index
rpl_semi_sync_slave_enabled=1 #启用从库半同步复制
#重启mysql
mysql> systemctl restart mysqld
#执行change master to
mysql> change master to
-> master_host='172.16.1.51',
-> master_user='replmysql',
-> master_password='echo',
-> master_port=3306,
-> master_log_file='mysql-bin.000001',
-> master_log_pos=411;
# 启动slave
mysql> start slave;
测试半同步
#创建两个数据库，test1和test2
mysql> create database test1;
Query OK, 1 row affected (0.04 sec)
mysql> create database test2;
Query OK, 1 row affected (0.00 sec)
mysql> show global status like 'rpl_semi%'; #查看复制状态
+--------------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------------+-------+
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_net_avg_wait_time | 768 |
| Rpl_semi_sync_master_net_wait_time | 1497 |
| Rpl_semi_sync_master_net_waits | 2 |
| Rpl_semi_sync_master_no_times | 0 |
| Rpl_semi_sync_master_no_tx | 0 |
| Rpl_semi_sync_master_status | ON |
| Rpl_semi_sync_master_timefunc_failures | 0 |
| Rpl_semi_sync_master_tx_avg_wait_time | 884 |
| Rpl_semi_sync_master_tx_wait_time | 1769 |
| Rpl_semi_sync_master_tx_waits | 2 |
| Rpl_semi_sync_master_wait_pos_backtraverse | 0 |
| Rpl_semi_sync_master_wait_sessions | 0 |
| Rpl_semi_sync_master_yes_tx | 2 |
+--------------------------------------------+-------+
14 rows in set (0.06 sec)
mysql> show databases; #从库查看
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| test |
| test1 |
| test2 |
+--------------------+
mysql> SET GLOBAL rpl_semi_sync_master_enabled = 0; #关闭半同步（1:开启 0:关闭）
mysql> show global status like 'rpl_semi%'; #查看半同步状态
+--------------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------------+-------+
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_net_avg_wait_time | 768 |
| Rpl_semi_sync_master_net_wait_time | 1497 |
| Rpl_semi_sync_master_net_waits | 2 |
| Rpl_semi_sync_master_no_times | 0 |
| Rpl_semi_sync_master_no_tx | 0 |
| Rpl_semi_sync_master_status | OFF | #状态为关闭
| Rpl_semi_sync_master_timefunc_failures | 0 |
| Rpl_semi_sync_master_tx_avg_wait_time | 884 |
| Rpl_semi_sync_master_tx_wait_time | 1769 |
| Rpl_semi_sync_master_tx_waits | 2 |
| Rpl_semi_sync_master_wait_pos_backtraverse | 0 |
| Rpl_semi_sync_master_wait_sessions | 0 |
| Rpl_semi_sync_master_yes_tx | 2 |
+--------------------------------------------+-------+
14 rows in set (0.00 sec)
#再一次创建两个库
mysql> create database test3;
Query OK, 1 row affected (0.00 sec)
mysql> create database test4;
Query OK, 1 row affected (0.00 sec)
mysql> show global status like 'rpl_semi%'; #再一次查看半同步状态
+--------------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------------+-------+
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_net_avg_wait_time | 768 |
| Rpl_semi_sync_master_net_wait_time | 1497 |
| Rpl_semi_sync_master_net_waits | 2 |
| Rpl_semi_sync_master_no_times | 0 |
| Rpl_semi_sync_master_no_tx | 0 |
| Rpl_semi_sync_master_status | OFF |
| Rpl_semi_sync_master_timefunc_failures | 0 |
| Rpl_semi_sync_master_tx_avg_wait_time | 884 |
| Rpl_semi_sync_master_tx_wait_time | 1769 |
| Rpl_semi_sync_master_tx_waits | 2 |
| Rpl_semi_sync_master_wait_pos_backtraverse | 0 |
| Rpl_semi_sync_master_wait_sessions | 0 |
| Rpl_semi_sync_master_yes_tx | 2 |
+--------------------------------------------+-------+
14 rows in set (0.00 sec)
注:不难发现，在查询半同步状态是，开启半同步，查询会有延迟时间，关闭之后则没有
注：相关参数说明
Rpl_semi_sync_master_clients ： #表示半同步复制从机的个数 这个参数很重要
Rpl_semi_sync_master_net_avg_wait_time #平均等待时间（默认毫秒）
Rpl_semi_sync_master_net_wait_time #总共等待时间
Rpl_semi_sync_master_net_waits #等待次数
Rpl_semi_sync_master_no_times #关闭半同步复制的次数
Rpl_semi_sync_master_no_tx #表示没有成功接收slave提交的次数
Rpl_semi_sync_master_status #表示当前是异步模式还是半同步模式，on为半同步
Rpl_semi_sync_master_timefunc_failures #调用时间函数失败的次数
Rpl_semi_sync_master_tx_avg_wait_time #事物的平均传输时间
Rpl_semi_sync_master_tx_wait_time #事物的总共传输时间
Rpl_semi_sync_master_tx_waits #事物等待次数
Rpl_semi_sync_master_wait_pos_backtraverse # 网上有人理解为"后来的先到了，而先来的还没有到的次数"
Rpl_semi_sync_master_wait_sessions #当前有多少个session因为slave的回复而造成等待
Rpl_semi_sync_master_yes_tx #成功接受到slave事物回复的次数
