Windows 下怎么关闭mysql的异步io？

linux上，innodb使用异步IO子系统(native AIO)来对数据文件页进行预读和写请求。行为受到参数innodb_use_native_aio控制。

默认是开启的，且只是适用于linux平台，需要libaio库。在其他的类unix平台上，innodb使用的是同步I/O。

由于历史的原因，在windows平台上innodb只使用异步I/O。

在同步I/O情况下，查询线程将I/O请求放入队列，innodb后台线程会便利请求队列，每次处理一个请求。并行处理的请求个数受到后台线程的数量控制(参数innodb_read_io_threads)。

native AIO情况下，查询线程直接将I/O请求分发给 *** 作系统，从而避免的后台线程数量对并发数的控制。innodb后台线程只需要等待 *** 作系统对IO请求的处理反馈信息。

native AIO优点是可以扩展，对于I/O高的系统，通过show engine innodb status可以看到很多挂起的读写线程。磁盘控制器影响I/O性能。

native AIO的另一个优点就是可以进行I/O merge *** 作。

native AIO潜在的不足是，对于高I/O系统缺少对I/O写请求分发的控制。有些场景下，太多的I/O写请求分发给 *** 作系统，可能会导致I/O读饥荒，这取决于系统可以同时处理I/O活动的能力。

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

---