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并且提交这些事务，然后主库线程才能继续做后续 *** 作。这里面有一个很明显的缺点就是，主库完成一个事务的时间被拉长，性能降低。

通常情况下在PHP中MySQL查询是串行的，如果能实现MySQL查询的异步化，就能实现多条SQL语句同时执行，这样就能大大地缩短MySQL查询的耗时，提高数据库查询的效率。目前MySQL的异步查询只在MySQLi扩展提供，查询方法分别是：

1、使用MYSQLI_ASYNC模式执行mysqli::query

2、获取异步查询结果：mysqli::reap_async_query

使用mysql异步查询，需要使用mysqlnd作为PHP的MySQL数据库驱动。

使用MySQL异步查询，因为需要给所有查询都创建一个新的连接，而MySQL服务端会为每个连接创建一个单独的线程进行处理，如果创建的线程过多，则会造成线程切换引起系统负载过高。Swoole中的异步MySQL其原理是通过MYSQLI_ASYNC模式查询，然后获取mysql连接的socket，加入到epoll事件循环中，当数据库返回结果时会回调指定函数，这个过程是完全异步非阻塞的。

MySQL 主从一直是面试常客，里面的知识点虽然基础，但是能回答全的同学不多。

比如楼哥之前面试小米，就被问到过主从复制的原理，以及主从延迟的解决方案，因为回答的非常不错，给面试官留下非常好的印象。你之前面试，有遇到过哪些 MySQL 主从的问题呢？

所谓 MySQL 主从，就是建立两个完全一样的数据库，一个是主库，一个是从库， 主库对外提供读写的 *** 作，从库对外提供读的 *** 作 ，下面是一主一从模式：

对于数据库单机部署，在 4 核 8G 的机器上运行 MySQL 5.7 时，大概可以支撑 500 的 TPS 和 10000 的 QPS， 当遇到一些活动时，查询流量骤然，就需要进行主从分离。

大部分系统的访问模型是读多写少，读写请求量的差距可能达到几个数量级，所以我们可以通过一主多从的方式， 主库只负责写入和部分核心逻辑的查询，多个从库只负责查询，提升查询性能，降低主库压力。

MySQL 主从还能做到服务高可用，当主库宕机时，从库可以切成主库，保证服务的高可用，然后主库也可以做数据的容灾备份。

整体场景总结如下：

MySQL 的主从复制是依赖于 binlog 的，也就是记录 MySQL 上的所有变化并以二进制形式保存在磁盘上二进制日志文件。

主从复制就是将 binlog 中的数据从主库传输到从库上，一般这个过程是异步的，即主库上的 *** 作不会等待 binlog 同步的完成。

详细流程如下：

当主库和从库数据同步时，突然中断怎么办？因为主库与从库之间维持了一个长链接，主库内部有一个线程，专门服务于从库的这个长链接的。

对于下面的情况，假如主库执行如下 SQL，其中 a 和 create_time 都是索引：

我们知道，数据选择了 a 索引和选择 create_time 索引，最后 limit 1 出来的数据一般是不一样的。

所以就会存在这种情况：在 binlog = statement 格式时，主库在执行这条 SQL 时，使用的是索引 a，而从库在执行这条 SQL 时，使用了索引 create_time，最后主从数据不一致了。

那么我们改如何解决呢？

可以把 binlog 格式修改为 row，row 格式的 binlog 日志记录的不是 SQL 原文，而是两个 event:Table_map 和 Delete_rows。

Table_map event 说明要 *** 作的表，Delete_rows event用于定义要删除的行为，记录删除的具体行数。 row 格式的 binlog 记录的就是要删除的主键 ID 信息，因此不会出现主从不一致的问题。

但是如果 SQL 删除 10 万行数据，使用 row 格式就会很占空间的，10 万条数据都在 binlog 里面，写 binlog 的时候也很耗 IO。但是 statement 格式的 binlog 可能会导致数据不一致。

设计 MySQL 的大叔想了一个折中的方案，mixed 格式的 binlog，其实就是 row 和 statement 格式混合使用， 当 MySQL 判断可能数据不一致时，就用 row 格式，否则使用就用 statement 格式。

有时候我们遇到从数据库中获取不到信息的诡异问题时，会纠结于代码中是否有一些逻辑会把之前写入的内容删除，但是你又会发现，过了一段时间再去查询时又可以读到数据了，这基本上就是主从延迟在作怪。

主从延迟，其实就是“从库回放” 完成的时间，与 “主库写 binlog” 完成时间的差值， 会导致从库查询的数据，和主库的不一致 。

谈到 MySQL 数据库主从同步延迟原理，得从 MySQL 的主从复制原理说起：

总结一下主从延迟的主要原因 ：主从延迟主要是出现在 “relay log 回放” 这一步，当主库的 TPS 并发较高，产生的 DDL 数量超过从库一个 SQL 线程所能承受的范围，那么延时就产生了，当然还有就是可能与从库的大型 query 语句产生了锁等待。

我们一般会把从库落后的时间作为一个重点的数据库指标做监控和报警，正常的时间是在毫秒级别，一旦落后的时间达到了秒级别就需要告警了。

解决该问题的方法，除了缩短主从延迟的时间，还有一些其它的方法，基本原理都是尽量不查询从库。

具体解决方案如下：

在实际应用场景中，对于一些非常核心的场景，比如库存，支付订单等，需要直接查询从库，其它非核心场景，就不要去查主库了。

两台机器 A 和 B，A 为主库，负责读写，B 为从库，负责读数据。

如果 A 库发生故障，B 库成为主库负责读写，修复故障后，A 成为从库，主库 B 同步数据到从库 A。

一台主库多台从库，A 为主库，负责读写，B、C、D为从库，负责读数据。

如果 A 库发生故障，B 库成为主库负责读写，C、D负责读，修复故障后，A 也成为从库，主库 B 同步数据到从库 A。

---