mysql 异步复制和半同步复制

在MySQL5.5之前，MySQL 的复制是异步 *** 作，主库和从库的数据之间存在一定的延迟，这样存在一个隐患:当在主库上写入一个事务并提交成功，而从库尚未得到主库推送的Binlog日志时，主库宕机了，例如主库可能因磁盘损坏、内存故障等造成主库上该事务Binlog丢失，此时从库就可能损失这个事务，从而造成主从不一致。

为了解决这个问题, MySQL5.5引人了半同步复制机制。

在MySQL 5.5之前的异步复制时，主库执行完 Commit提交 *** 作后，在主库写入 Binlog日志后即可成功返回客户端，无需等待Binlog日志传送给从库，如图31-7所示。

而半同步复制时，为了保证主库上的每一个 Binlog 事务都能够被可靠的复制到从库上，主库在每次事务成功提交时，并不及时反馈给前端应用用户，而是等待其中一个从库也接收到 Binlog事务并成功写入中继日志后，主库才返回Commit *** 作成功给客户端。 半同步复制保证了事务成功提交后，至少有两份日志记录 ，一份在主库的 Binlog日志上，另一份在至少一个从库的中继日志Relay Log 上，从而更进一步保证了数据的完整性。半同步复制的大致流程如图31-8所示。

半同步复制模式下，假如在图31-8的步骤1、2、3中的任何一个步骤中主库宕机，则事务并未提交成功，从库上也没有收到事务对应的 Binlog日志，所以主从数据是一致的

假如在步骤4传送 Binlog日志到从库时，从库宕机或者网络故障，导致 Binlog并没有及时地传送到从库上，此时主库上的事务会等待一段时间(时间长短由参数rpl_semi_sync_master_timeout设置的毫秒数决定)，如果 Binlog 在这段时间内都无法成功推送到从库上，则 MySQL自动调整复制为异步模式，事务正常返回提交结果给客户端。

半同步复制很大程度上取决于主从库之间的网络情况，往返时延RTT 越小决定了从库的实时性越好。通俗地说，主从库之间网络越快，从库越实时。

半同步模式是作为MySQL5.5的一个插件来实现的，主库和从库使用不同的插件。安装比较简单，在上一小节异步复制的环境上，安装半同步复制插件即可。

1、首先,判断MySQL服务器是否支持动态增加插件:

2、安装插件

3、可以查看到已安装的插件

4、在安装完插件后，半同步复制默认是关闭的，这时需设置参数来开启半同步

主：

从：

以上的启动方式是在命令行 *** 作，也可写在配置文件中。

主：

从：

4、重启从上的IO线程

从：

如果没有重启，则默认还是异步复制，重启后，slave会在master上注册为半同步复制的slave角色。这时候，主的error.log中会打印如下信息：

查看半同步是否在运行

主：

从：

这两个变量常用来监控主从是否运行在半同步复制模式下。至此，MySQL半同步复制搭建完毕~

来做个实验，观察半同步状态参数的变化。

1、在主库上insert一条记录，观察下变化；

Rpl_semi_sync_master_net_waits加1，说明刚才的insert已经发送到从机并且主机还接收到从机的反馈响应；

2、我们将从机mysql停止，再次在主机上进行insert后查看状态

可以看到，主机进行insert阻塞了10秒才返回结果。Rpl_semi_sync_master_status变为OFF，Rpl_semi_sync_master_no_tx加1，说明这条insert没有同步到从机。后面再一次执行了insert立马返回了结果，说明此时已经降级为异步复制；Rpl_semi_sync_master_no_tx也是增加了1；

3、现在恢复启动从机，再次在主机上进行insert后查看状态

Rpl_semi_sync_master_status还是OFF，Rpl_semi_sync_master_no_tx又增加了1。说明从库重启并不会自动恢复为原来的半同步复制，需要手动 *** 作：

主 SET GLOBAL rpl_semi_sync_master_enabled = 1

从 SET GLOBAL rpl_semi_sync_slave_enabled = 1STOP SLAVE IO_THREADSTART SLAVE IO_THREAD

上面是从机重启后的变化，那么主到从之间的网络问题呢，我们可以利用防火墙来模拟。

对于全同步复制，当主库提交事务之后，所有的从库节点必须收到，APPLY并且提交这些事务，然后主库线程才能继续做后续 *** 作。这里面有一个很明显的缺点就是，主库完成一个事务的时间被拉长，性能降低。

大致流程：主库将变更写binlog日志，然后从库连接到主库之后，从库有一个IO线程，将主库的binlog日志拷贝到自己本地，写入一个中继日志 relay日志中。接着从库中有一个SQL线程会从中继日志读取binlog，然后执行binlog日志中的内容，也就是在自己本地再次执行一遍SQL，这样就可以保证自己跟主库的数据是一样的。

如果主库突然宕机，然后恰好数据还没同步到从库，那么有些数据可能在从库上是没有的，这时候从库成为了主库，那么有些数据可能就丢失了。

开启半同步复制 semi-sync ，用来解决主库数据丢失问题；

这个所谓半同步复制， semi-sync复制 ，指的就是主库写入binlog日志之后，就会将强制此时立即将数据同步到从库，从库将日志 写入自己本地的relay log之后 ，接着会 返回一个ack 给主库， 主库接收到至少一个从库的ack之后才会认为写 *** 作完成了。 如果 过程出现失败 ，那么 我们的客户端就可以进行重试了 ；

主从延迟对于读写分离的涉及影响比较大

这里有一个非常重要的一点，就是 从库同步主库数据的过程是串行化的 ，也就是说 主库上并行的 *** 作，在从库上会串行执行 。所以这就是一个非常重要的点了，由于从库从主库拷贝日志以及串行执行SQL的特点，在 高并发场景下，主库大量的写，那么从库的数据一个个的读，那么就会导致从库同步一定会比主库慢一些，是有延时的 。所以经常出现，刚写入主库的数据可能是读不到的，要过几十毫秒，甚至几百毫秒才能读取到。（主库并发写的量级越高，从库积压的同步数据越多，延迟越高）

我们可以用 show status 看看 Seconds_Behind_Master 参数，你可以看到从库复制主库的数据落后了几ms，但是这个也不是完全准确，可以看 Seconds_Behind_Master的

对于解决主从延迟，解决方案可以从以下方面考虑

---