MySQL主从配置半同步复制

注意：

• 主从MySQL版本最好一样，防止有些数据同步失败

• 数据同步前确定主从数据库的数据一样

• 主从的库名一定要一样，不要主库叫A，从库叫B，会导致同步不了不会报错

MySQL 5.7+版本（建议使用5.7+版本，后面说明）

1.安装半自动复制插件，方法是登陆MySQL执行一下脚本：

主库：

install plugin rpl_semi_sync_master soname 'semisync_master.so';1

从库：

INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';1

2.修该数据库配置

主数据库：

[mysqld]
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout=1000   #此单位是毫秒
log-bin=mysql-bin #打开日志(主机需要打开)
server-id=1 #服务器id,注意不能跟其他库一样
#给从机同步的库，可以多个
binlog-do-db=db1
binlog-do-db=db2
binlog-do-db=test123456789

从数据库

[mysqld]
rpl_semi_sync_slave_enabled=1
server-id=2 #服务器id,注意不能跟其他库一样
relay-log = slave-relay-bin #自命名日志文件。防止从服务器更改其主机名时，复制中断
#要从主机同步的库
replicate-do-db=db1
replicate-do-db=db2
replicate-do-db=test12345678

注意：需要数据同步的数据库名一定要一样，要一样！！！ 血一样的教训

3.重启主从数据库的服务

4.创建主数据库授权同步账户

GRANT REPLICATION SLAVE ON *.* TO 'aaa'@'192.168.x.xxx' IDENTIFIED BY 'XXXXXX';
FLUSH PRIVILEGES; #刷新权限，新增修该权限后要刷新12

格式：

GRANT
	[权限]
on [库.表]
to [用户名]@[IP]
IDENTIFIED BY [密码]
# WITH GRANT OPTION;123456

GRANT 命令说明：

1. ALL PRIVILEGES 表示所有权限，你也可以使用SELECT、UPDATE等权限。

2. ON 用来指定权限针对哪些库和表。

3. *.* 前面的 *用来指定数据库名，后面 * 用来指定表名，*表示全部。

4. TO 表示将权限赋予某个用户。

5. @ 前面表示用户，后面接限制的主机，可以是IP、IP段、域名以及%，%表示任何地方。

6. IDENTIFIED BY 指定用户的登陆密码。

7. WITH GRANT OPTION 这个选项表示该用户可以将自己的权限授权给别人。

注意：经常有人在创建操作用户的时候不指定 WITH GRANT OPTION 选项导致后来该用户不能使用 GRANT 命令创建用户或者给其他用户授权。

备注：可以使用 GRANT 重复给用户添加权限，权限叠加。比如你先给用户添加一个 SELECT 权限，然后又给用户添加一个 INSERT 权限，那么该用户就同时有 SELECT 和 INSERT 权限。

5.查看主服务状态

SHOW MASTER STATUS;1

需要记住圈中的两个，配置从库需要用到

6.配置从库

CHANGE MASTER TO MASTER_HOST='xx.xxx.xxx.xx',MASTER_USER='aaa', MASTER_PASSWORD='XXXXXX',MASTER_LOG_FILE='mysql-bin.000007',MASTER_LOG_POS=601;1

1. MASTER_HOST 主库IP

2. MASTER_USER 用户名，第四步创建的用户名

3. MASTER_PASSWORD 密码，第四步创建的用户密码

4. MASTER_LOG_FILE 日志文件，第五步获取的File

5. MASTER_LOG_POS 日志位置，第五步获取的Position

7.开启SLAVE同步

start slave;1

8.查看下slave状态

show slave status \G;1

当Slave_IO_Running和Slave_SQL_Running都为Yes，说明主从复制配置成功

数据还是不同步问题

1.当Slave_IO_Running或Slave_SQL_Running不是yes

• 确定以上步骤是执行正确的

• 查看是否是防火墙禁止了同步服务

2.当Slave_IO_Running或Slave_SQL_Running都为yes

• 查看库名是否一样

• 根据第5步和第8步，查看 FILE 和 POS 是否一样
  
  

如果不一样，先停止同步

stop slave;1

再根据新的 FILE 和 POS 执行 第六步和第七步

---

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

老的半同步方案，如图所示。

---

事实上，半同步复制并不是严格意义上的半同步复制

当半同步复制发生超时时（由rpl_semi_sync_master_timeout参数控制，单位是毫秒，默认为10000，即10s），会暂时关闭半同步复制，转而使用异步复制。当master dump线程发送完一个事务的所有事件之后，如果在rpl_semi_sync_master_timeout内，收到了从库的响应，则主从又重新恢复为半同步复制。

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. windows 搭建swoole搭建环境
2. Navicat Premium 15安装