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函数的童鞋,可能要注意下它的限制。



本文转自 bxst 51CTO博客,原文链接:http://blog.51cto.com/13013670/1943924

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
MySQL中的半同步复制(r11笔记第65天)
关于MySQL的复制架构,大体有下面三种方式,异步,全同步复制,半同步复制。 三种复制方式     第一种是异步复制,是比较经典的主从复制,搭建主从默认的架构方式,就是属于异步的,相对来说性能要好一些。
941 0
PostgreSQL 10.1 手册_部分 III. 服务器管理_第 31 章 逻辑复制_31.2. 订阅
31.2. 订阅 31.2.1. 复制槽管理 订阅是逻辑复制的下游端。定义订阅的节点被称为 订阅者。 订阅定义了与另一个数据库的连接以及它想要订阅的一组发布(一个或多个)。 订阅者数据库的行为与任何其他PostgreSQL实例的行为相同, 并且可以通过定义自己的发布来用作其他数据库的发布者。
1250 0
PostgreSQL 10.1 手册_部分 III. 服务器管理_第 31 章 逻辑复制_31.3. 冲突
31.3. 冲突 逻辑复制的行为与普通的DML操作类似,因为即使订阅者节点本地更改了数据, 数据也将被更新。如果传入数据违反任何限制,复制将停止。 这被称为冲突。当复制UPDATE 或者DELETE操作时,丢失的数据不会产生冲突,这样的操作将被忽略。
1082 0
PostgreSQL 10.1 手册_部分 III. 服务器管理_第 31 章 逻辑复制_31.4. 限制
31.4. 限制 逻辑复制目前有以下限制或缺少的功能。 这些可能会在未来的版本中解决。 不复制数据库模式和DDL命令。初始模式可以使用pg_dump --schema-only 手动复制。后续的模式更改需要手动保持同步。
1027 0
PostgreSQL 10.1 手册_部分 III. 服务器管理_第 31 章 逻辑复制_31.5. 架构
31.5. 架构 31.5.1. 初始快照 逻辑复制首先复制发布者数据库上的数据快照。一旦完成, 发布者的变化就会实时发送给订阅者。订阅者按照发布者提交的顺序应用数据, 以确保任何单个订阅中的发布的事务一致性。
1089 0
PostgreSQL 10.1 手册_部分 III. 服务器管理_第 26 章 高可用、负载均衡和复制_26.5. 热备
26.5. 热备 26.5.1. 用户概览 26.5.2. 处理查询冲突 26.5.3. 管理员概览 26.5.4. 热备参数参考 26.5.5. 警告 术语热备用来描述服务器处于归档恢复或后备模式时连接到服务器并运行只读查询的能力。
1296 0
PostgreSQL 10.1 手册_部分 III. 服务器管理_第 26 章 高可用、负载均衡和复制
第 26 章 高可用、负载均衡和复制 目录 26.1. 不同方案的比较 26.2. 日志传送后备服务器 26.2.1. 规划 26.2.2. 后备服务器操作 26.2.3. 为后备服务器准备主控机 26.
1012 0
MySQL5.6同步复制新特性详解
作者:贺春阳,出处:mysqlpub.com ! 继5.5半同步复制后,5.6又对其进行了优化与改进,其中有两个地方较为重要: 1、对运维人员来说应该是一件大喜的事情,在主从切换后,在传统的方式里,你需要找到binlog和POS点,然后hangemasterto指向,而不是很有经验的运维,往往会将其找错,造成主从同步复制报错,在mysql5.6里,你无须再知道binlog和POS点,你
1063 0
14426
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载