标签：主库 同步 slave 函数 semi sync net bug
研发的同事反馈，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 . 在此，非常感谢宋老师的热情的无偿援助。
我们来看看采用了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.
现在留下了的疑问是？
centos 7 是否也没有能突破这个限制？ 所以导致了bug的产生。 如果可以突破这个限制，作者的环境出现semi-sync的错误是什么原因导致？
2. 如果有这个Bug，如何避免？
3. 周末在家，作者没有测试环境来继续跟进这个问题，来复现这个问题。但基本思路已有，期待下周复现。
但几乎无疑问的是，一定是跟多路复用IO模型select()函数有关。作者想确认的是，这个bug跟操作系统是否完全无关。因此，再次感谢宋老师跟我指明方向。
另外，很幸运的是，宋老师让我关注下一个版本的发布，也就是5.7.17。暗含就是这个问题应该在下一个版本中解决。
标签：主库,同步,slave,函数,semi,sync,net,bug 来源： https://blog.51cto.com/15057824/2648683
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。