排查mysql半同步复制问题详细步骤

本文主要给大家简单讲讲排查Mysql半同步复制问题详细步骤，相关专业术语大家可以上网查查或者找一些相关书籍补充一下，这里就不涉猎了，我们就直奔主题吧，希望排查mysql半同步复制问题详细步骤这篇文章可以给大家带来一些实际帮助。                                                           

1.问题背景
      默认情况下，线上的mysql复制都是异步复制，因此在极端情况下，主备切换时，会有一定的概率备库比主库数据少，因此切换后，我们会通过工具进行回滚回补，确保数据不丢失。半同步复制则要求主库执行每一个事务，都要求至少一个备库成功接收后，才真正执行完成，因此可以保持主备库的强一致性。为了确保主备库数据强一致，减少数据丢失，尝试在生产环境中开启mysql的复制的半同步(semi-sync)特性。实际操作过程中，发现大部分实例半同步都可以正常运行，但有少部分实例始终开不起来(只能以普通复制方式运行)，更奇葩的是同一个主机的两个实例，一个能开启，一个不能。最终定位的问题也很简单，但排查出来还是花了一番功夫，下文将描述整个问题的排查过程。

2.半同步复制原理
     mysql的主备库通过binlog日志保持一致，主库本地执行完事务，binlog日志落盘后即返回给用户；备库通过拉取主库binlog日志来同步主库的操作。默认情况下，主库与备库并没有严格的同步，因此存在一定的概率备库与主库的数据是不对等的。半同步特性的出现，就是为了保证在任何时刻主备数据一致的问题。相对于异步复制，半同步复制要求执行的每一个事务，都要求至少有一个备库成功接收后，才返回给用户。实现原理也很简单，主库本地执行完毕后，等待备库的响应消息(包含最新备库接收到的binlog(file,pos))，接收到备库响应消息后，再返回给用户，这样一个事务才算真正完成。在主库实例上，有一个专门的线程(ack_receiver)接收备库的响应消息，并以通知机制告知主库备库已经接收的日志，可以继续执行。有关半同步的具体实现，可以参考另外一篇文章，mysql半同步(semi-sync)源码实现。

3.问题分析
     前面简单介绍了半同步复制的原理，现在来看看具体问题。在主备库打开半同步开关后，问题实例的状态变量"Rpl_semi_sync_master_status"始终是OFF，表示复制一直运行在普通复制的状态。
(1).修改rpl_semi_sync_master_timeout参数。
     半同步复制参数中有一个rpl_semi_sync_master_timeout参数，用以控制主库等待备库响应消息的时间，如果超过该值，则认为备库一直没有收到(备库可能挂了，也可能备库执行很慢，较主库相差很远)，这个时候复制会切换为普通复制，避免主库的执行事务长时间等待。线上这个值默认是50ms，简单想是不是这个值太小了，遂将其改到10s，但问题依然不解。
(2).打印日志
      排查问题最简单最笨的方法就是打日志，看看到底是哪个环节出了问题。主库和备库分别有rpl_semi_sync_master_trace_level和rpl_semi_sync_slave_trace_level参数来控制半同步复制打印日志。将两个参数值设置为80(64+16)，记录详细日志信息，以及进出的函数调用。

master:2016-01-04 18:00:30 13212 [Note] ReplSemiSyncMaster::updateSyncHeader: server(-1721062019), (mysql-bin.000006, 500717950) sync(1), repl(1)2016-01-04 18:00:40 13212 [Warning] Timeout waiting for reply of binlog (file: mysql-bin.000006, pos: 500717950), semi-sync up to file , position 0.2016-01-04 18:00:40 13212 [Note] Semi-sync replication switched OFF.

slave:2016-01-04 18:00:30 38932 [Note] ---> ReplSemiSyncSlave::slaveReply enter2016-01-04 18:00:30 38932 [Note] ReplSemiSyncSlave::slaveReply: reply (mysql-bin.000006, 500717950)2016-01-04 18:00:30 38932 [Note] <--- ReplSemiSyncSlave::slaveReply exit (0)

从master日志可以看到在2016-01-04 18:00:30时，主库设置了半同步标记，并开始等待备库的响应，等待10s后，仍然没有收到响应，则认为超时，遂将半同步模式关闭，切换为普通模式。但从slave日志来看，在2016-01-04 18:00:30已经将(mysql-bin.000006, 500717950)发送给主库，表示已经收到该日志。这就说明，master日志已经打了semi-sync标，slave收到了日志，并且也回了包，master也确实等了10s，就是没有收到包，所以就切换为普通复制。现在问题就变成了，为什么master没有收到？

(3)select函数
     前面提到了，主库实例上有一个专门接收响应包的线程(ack_receiver)，它通过select函数监听Socket，发现有slave的响应消息后，读取消息，通知工作线程可以继续执行。那么问题是不是出现在select函数上面？因为select是一个系统调用，一直没有怀疑，但已经跟到这里来了，那就得看看。与select函数相关的有几个重要的宏定义和说明。主要实现在/usr/include/bits/typesizes.h，/usr/include/bits/select.h和/usr/include/sys/select.h这三个文件中。

/ __NFDBITS]; /= (  __FD_SET_SIZE 1024  __fd_mask;  __NFDBITS (8 * (int) sizeof (__fd_mask))  __FDMASK(d)    ((__fd_mask) 1 << ((d) % __NFDBITS))  __FDELT(d)    ((d) / __NFDBITS)  __FDS_BITS(set) ((set)->__fds_bits)  __FD_SET(d, set) (__FDS_BITS (set)[__FDELT (d)] |= __FDMASK (d)) __FD_CLR(d, set) (__FDS_BITS (set)[__FDELT (d)] &= ~__FDMASK (d)) __FD_ISSET(d, set) \)[__FDELT (d)] & __FDMASK (d)) != )

     通过FD_SET可以设置我们想要监听的句柄，句柄信息存储在fd_set位数组中，数组元素的个数由__FD_SETSIZE/64决定，对于__FD_SETSIZE=1024而言，整个数组只有16个long int。每个句柄占有一个位，就是1024个位，可以存储1024个句柄。假设句柄值为138，那么138/64=2,138%64=10，那么这个句柄在数组的标示在第2个long int的第10位置1。那么如果句柄值超出1024呢，这里不就溢出了？我仔细撸了撸代码，发现根本就没有容错判断，如果句柄值超过1024就一定会溢出。由于select函数是遍历数组中的每个位，然后去判断该句柄是否可读可写，因此对于超过1024的句柄，永远也不会去判断，因此主库永远不知道备库是否发送了响应包。

(4)验证
上面只是理论分析，如果实际运行的实例句柄确实是超过了1024，那么问题就定位到了。
1.得到mysql进程mysql-pid
ps –aux | grep mysqld | grep port 
2.gdb attach到该进程 
gdb –p mysql-pid 
3.找到ack_receive线程，并切换 
info thread
thread thread_id
4.打印socket的值，这里fd值为2344。
p m_slaves

(5)如何解
     我们看到了由于__FD_SETSIZE的定义，一般是1024，导致select函数最多只能监听1024个句柄，并且最大句柄值不超过1024。第一个方法是调大该参数，但这种方法需要重新编译linux内核。而且由于select机制，每次都需要遍历 的每一位来判断句柄上是否有消息到来，因此如果设置很大，将导致效率非常低。select是一种比较老的IO复用机制，比较先进的poll，epoll都有类似的功能，并且更强大，也没有句柄总数和最大句柄的限制，通过poll或者epoll实现监听这部分功能，就可以彻底解决问题。有关select，poll，epoll等机制，大家可以去网上查资料，这里不展开讨论。

      临时解决方法，前面提到的方法要么需要重新编译linux内核，要么需要改mysql内核代码，这里提供一种临时的解决方法。可以在slave端执行stop slave，start slave命令，重建主库与备库的socket连接，只要1-1024的fd没有被全部使用，新建的socket fd就有机会小于1024，这样select机制不会出问题，半同步也就能正常运行。但如果1-1024的fd全部被长连接使用，那么这种方法就无能为力了。

(6)官方版本
     看了最新oracle官方版本git上5.7的源代码，这块也是用select来实现的，所以也存在类似的问题。当然，由于句柄号有复用机制，当实例上连接数很少，或者长连接不多时，不容易出现fd>1024的情况，所以这个bug不是很容易出现，但问题是普遍存在的。

(7)问题延伸
     问题定位后，另外一个问题还困扰我了半天。因为mysql内核中有监听的部分有3块，1是监听端口的select，2是线程池的监听epoll，3是半同步的select监听。slave binlog dump的线程就是普通的工作线程，而工作线程的socket会受epoll的监听，这样一来，binlog dump的socket会同时受半同步的select监听和线程池的epoll监听，这不乱了吗？后来仔细看了看代码，才发现线程池的epoll监听采用的是EPOLLONESHOT模式，每次接收消息后会解绑，需要重新注册，因此不会出现同一个句柄被两种监听机制同时监听的情况。

     到此，排查问题过程就结束了，结论是比较简单的，但定位这个问题确实花费了一些功夫。由于select一种比较通用的多路IO复用机制，因此有用到select函数的童鞋，可能要注意下它的限制。

排查mysql半同步复制问题详细步骤就先给大家讲到这里，对于其它相关问题大家想要了解的可以持续关注我们的数据库。我们的板块内容每天都会捕捉一些行业新闻及专业知识分享给大家的。