首页 > 其他分享 >TiDB binlog故障处理之drainer周期性罢工

TiDB binlog故障处理之drainer周期性罢工

时间:2023-11-16 16:57:23浏览次数:36  
标签:binlog server drainer pump gc TiDB

背景

前段时间用户反馈某生产环境 TiDB 集群 drainer 频繁发生故障,要么服务崩溃无法启动,要么数据跑着跑着就丢失了,很是折磨人。该集群跑的是离线分析业务,数据量20T ,v4版本,有多个 drainer 往下游同步数据,目标端包括kafka、file、tidb多种形态。

两天前刚恢复过一次,这会又故障重现,不得不来一次根因排查。

故障现象

接业务端反馈,某下游kafka几个小时没收到 TiDB 数据了,但是 pump 和 drainer 节点状态都显示正常,同样在几天前也收到类似的反馈,当时是因为 binlog 发生未知异常导致 TiDB server 停止写入,需要通过以下 API 验证 binlog 状态:

curl http://{tidb-server ip}:{status_port}/info/all

该 API 会返回所有 TiDB server 的元信息,其中就包括每个实例 binlog 的写入状态(binlog_status字段),如果 TiDB server设置了ignore-error,那么在 binlog 故障时通常是 skipping,正常情况下是 on

经确认7个 TiDB server 的 binlog_status 均为 skipping状态,和此前是一样的问题。

处理方法比较简单,重启 TiDB server 即可,但是避免后续重复出现需要搞清楚原因后再重启。

分析过程

数据不同步了相信大家都会第一时间怀疑是 drainer 的问题, 最常见的原因就是大事务导致 drainer 崩溃panic,但是登录到 drainer 所在的机器上分析日志,并没有发现异常现象,日志显示 savepoint 正常写入,checkpoint 正常推进,实例状态up,说明并不是 drainer的问题。

根据 binlog skip 状态,转头去分析 TiDB server监控,在 TiDB->Server->Skip Binlog Count面板可以看到被跳过的 binlog 数量:

企业微信截图_20230824110827.png

从监控看到,在8月18号下午6点左右 Skip Count 突然从高位掉到0,正是因为上一次重启 TiDB server 修复了故障。往后到21号早上左右,Skip Count 又开始出现,那么就要重点分析这个时间点的日志。

进一步分析监控,发现 Skip Count 上升趋势和 Critical Error 相吻合,说明在21号早上07:06左右开始出现大量的 binlog 写入异常,接下来根据这个时间点去排查 pump 的日志。

企业微信截图_20230824110703.png

根据精确的时间点,很快就在 pump 日志中定位到了panic的位置,在panic之后日志发现了一个非常有用的信息:

企业微信截图_20230824111305.png

日志显示,binlog 确实停止写入了,同时指出停止写入的原因是磁盘空间不够,这里有个关键信息StopWriteAtAvailableSpace,也就是说 pump 所在的磁盘可用空间小于这个参数时就会停止写入。我们用edit-config看一下 pump 的配置参数:

  pump:
    gc: 2
    heartbeat-interval: 2
    security:
      ssl-ca: ""
      ssl-cert: ""
      ssl-key: ""
    storage:
      stop-write-at-available-space: 1 gib

发现日志和配置参数可以对应上,确实是磁盘不够了。反手就是一个df -h看看什么情况:

企业微信截图_20230824111549.png

意外的是,上图显示 pump 的数据盘只用了1%,还有大把的空间没被使用,貌似和日志报错原因不符。

到这里我忽略了一个重要的时间因素,就是介入排查的时候离 pump 故障已经过去了3天(从前面第一章监控图可以看到),而 pump gc时间设置的是2天,那么意味着在排查的时候 pump 之前记录的binlog 已经被 gc 掉了,至于这些 binlog 有没有被 drainer正常消费还不得而知。好在 Grafana 监控里面有一个面板记录了 pump storage 的变化情况,路径是:Binlog->pump->Storage Size

企业微信截图_20230824110954.png

从上面这个曲线联想最近两次的故障,貌似问题一下子清楚了:18号下午6点左右重启 TiDB Server 恢复 binlog 写入,pump 可用空间开始变少,到21号早上7点左右几乎被使用完毕,触发StopWriteAtAvailableSpace异常,binlog 停止写入变成 skipping状态,但与此同时 pump gc 还在工作,且没有新的 binlog 进来,两天后存量数据被 gc 完毕在23号早上7点左右恢复到空盘水平,持续到现在。

半途接手的集群,各种背景信息也不是很了解,经常奇奇怪怪问题一查就是查半天,这就是oncall人的日常。。

标签:binlog,server,drainer,pump,gc,TiDB
From: https://www.cnblogs.com/hohoa/p/17836702.html

相关文章

  • 通过NGINX搭建TiDB负载均衡
    作者:像风一样的男子前言目前TIDB的负载均衡官网推荐使用HAProxy,社区主流也是HAProxy,本文尝试使用nginx四层代理tidb提供TCP协议下的负载均衡能力,因为nginx安装编译需要自己添加模块,很多小伙伴觉得麻烦,本文使用基于Nginx的openresty来安装,可以实现一键安装并打包各个模块,快速......
  • TiDB实践安装及性能测试(上)
    作者:TiDBer_小阿飞TIDB分布式数据库离线实施方案及相关测试(测试版)第一部分 ~~ ~~硬件资源一、硬件资源现有硬件资源环境统计如下|||||||||--|------------|---|-----|----|---------|-------------||序号|IP|CPU|存储|内存|Hostname......
  • TiDB实践安装及性能测试(下)
    作者:TiDBer_小阿飞第六部分 数据备份及数据迁移一、TiDBDataMigration(DM)安装部署TiDBDataMigration(DM)是一款便捷的数据迁移工具,支持从与MySQL协议兼容的数据库(MySQL、MariaDB、AuroraMySQL)到TiDB的全量数据迁移和增量数据同步。1.解压DM包在TOOLS的文件......
  • 记一次 TiDB v7.1 版本生产环境的完整搭建流程
    作者:随缘天空本文包含以下内容:1、安装的硬件要求2、安装前环境检查及系统优化3、集群搭建4、服务访问1、硬件要求tidb集群搭建对服务器的cpu和内存有要求,过低的配置可能会导致搭建失败或影响集群性能2、安装前环境检查及系统优化为了保证安装顺利和集群的性能,安装前我们需......
  • 三地五中心,TiDB POC最佳姿势探索
    POC测试背景在某地震多发省,为了避免地震造成的机房级灾难,或者城市级灾难,导致整个系统不可用,拟建设一套三地五中心五副本分布式高可用数据库系统,保证高可用需求。在该系统中需要接入不同地区的应用流量,且前期应用开发已经采用了百库百表的水平分库表策略。为尽可能减少应用~数据库......
  • 【运维实操】TIDB v6.1.1:全量备份、全量恢复和增量备份方法解析
    作者:Fly-bird背景:由于公司要求必须保证数据库的数据安全,我们生产环境的数据库采取全量备份+增量备份+实时同步从库的方式保证数据库的高可用,本文介绍我公司生产环境的数据库备份方式。注意:我们使用实时同步数据到从库的方式保障高可用(使用pump+drainer),同时支持恢复任意时刻数据的......
  • tidb数据库5.4.3和6.5.3版本性能测试对比
    作者:qizhining一、测试需求:基于历史原因,我们的业务数据库一直使用5.4.3,最近由于研发提出需求:需要升级到6.5.3版本,基于版本不同,需要做个压力测试已验证2个版本之间的性能差异。二、测试目的:验证tidb数据库5.4.3和6.5.3版本性能的差异三、测试结果:tidb数据库6.5.3版本比5.4.3总体性......
  • 理解TiDB集群的P99计算方式
    一、背景简介在学习prometheus时,会遇到一个histogram_quantile()函数,用于对histogram类型的指标进行分位数计算,实际上这个函数就是histogram这个指标类型最常用的函数。此函数在tidb的监控图表中有一个比较明显地方使用:计算P99/P999Duration等延迟指标。新人们对此函数的理解是......
  • TiDB 源码编译之 TiProxy 篇
    作者:ShawnYanTiProxy简介TiProxy是一个基于Apache2.0协议开源的、轻量级的TiDB数据库代理,基于Go语言编写,支持MySQL协议。TiProxy支持负载均衡,接收来自应用程序的请求,然后将其发送到TiDB集群。支持自动故障转移,当后端TiDBServer发生故障,可以自动将连接转移到......
  • 数据库数据恢复—MySQL数据库(无备份,未开启binlog)误删除表数据怎么恢复数据?
    数据库数据恢复环境:一台本地windowssever操作系统服务器,服务器上部署mysql数据库单实例,引擎类型为innodb,表内数据存储所使用表空间类型为独立表空间。无数据库备份,未开启binlog。数据库故障&分析:工作人员在执行Delete命令删除数据时未添加where子句进行筛选,导致全表数据被删除,......