调用mysql的时候,是同步的还是异步的

调用mysql的时候,是同步的还是异步的,第1张

研发的同事反馈,mysql的半同步怎么变异步了?开始觉得不足为奇,超时之后,自然变成异步了。但同步binlog的速度变得正常之后,就会自动变成同步了。但抱着严谨负责的态度,马上去检查了一

下数据库的日志跟半同步的状态。

看了一下从库的错误日志,被图片中所示的sem-sync slave net_flush() reply failed 刷屏。。。。。。,汗了,这又是哪一出?  主库却没有任何日志。

虽然此时的主从同步的延迟时间是正常的,维持在0s的延迟,但此时同步状态却是异步的。

好奇怪呢?

查看一下代码,该Semi-sync slave net_flush() reply failed 信息来自函数

ReplSemiSyncSlave::slaveReply,函数如下

 该错误发生的条件就是执行net_flush(net)函数,没有收到正常的返回,报错了,所以有上面的错误发生,该函数的作用是将从库收到的binlog file 跟binlog pos的信息发送给主库。

网络有问题? 即使网路抖动性的问题,网路恢复之后应该正常才是。

为什么这个错误持续刷屏? 而主从同步目前是正常的,只是由半同步变成了异步。

 当我将slave重启之后,错误信息也很快就出现。

因为该函数是向主库发送同步binlog的确认信息的,也就是ack信息,难道是主库的ack的接收线程出了问题? 而主库没有任何的报错信息 。

关键时刻,自己搞不定的时候,尝试找帮手。我将错误信息,发给oracle公司的mysql开发者宋老师,宋老师是负责replication模块的开发者,对replication相当熟悉,说我可能遇上一个mysql的Bug,让我查看一下Bug 79865 .   在此,非常感谢宋老师的热情的无偿援助。

  bug 详情链接: http://bugs.mysql.com/bug.php?id=79865

我们来看看采用了select()多路复用io模型的ack_reciver 线程的代码:

bug的关键点是因为 ret= select(max_fd+1, &fds, NULL, NULL, &tv)  select()函数的入参max_fd+1有1024的限制,且这个限制无法通过修改nproc来突破?

(ulimit -n 命令可以修改nproc参数)。

貌似所有的疑问都揭开,但请继续。

 作者采用的环境是5.7.15,同时,作者采用的 *** 作系统是centOS 7,  根据上面http://bugs.mysql.com/bug.php?id=79865 后半部分,Meiji Kimura 的描述信息,该bug在centos 6上复现了, 而在centOS7上没有复现。而作者正是采用了centos 7.

通常情况下在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事件循环中,当数据库返回结果时会回调指定函数,这个过程是完全异步非阻塞的。

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活动的能力。


欢迎分享,转载请注明来源:内存溢出

原文地址:https://54852.com/zaji/8440428.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-04-16
下一篇2023-04-16

发表评论

登录后才能评论

评论列表(0条)

    保存