扫码阅读
手机扫码阅读

数据库|Drainer频繁故障,一次性解决问题!

1918 2024-02-01

我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。

查看原文:数据库|Drainer频繁故障,一次性解决问题!
文章来源:
神州数码云基地
扫码关注公众号
故障分析与解决:TiDB集群Drainer频繁发生故障

摘要

本文由何傲撰写,深入分析了TiDB集群的drainer频繁发生的故障,提出了解决方案,并进行了后续监控和思考。

背景

用户报告生产环境TiDB集群的drainer多次发生服务崩溃和数据丢失。集群运行离线分析业务,数据量达20T,使用v4版本drainer,同步数据到kafka、file、tidb等多种形态的下游。

故障现象

下游kafka几个小时未收到数据,pump和drainer节点状态显示正常。通过API确认7个TiDB server的binlog_status为skipping状态,与之前故障相同,需重启TiDB server。

分析过程

初步怀疑drainer问题,但日志显示正常。监控显示binlog skip与critical error重合,进一步分析pump日志揭示磁盘空间不足为故障原因。监控显示从重启TiDB server后pump空间不足直到gc后空间释放。

解决方案

无法增加磁盘空间,决定缩短pump gc时间至1天,调整后binlog同步恢复正常。下游kafka的不敏感性对于数据丢失问题有缓解作用。

思考

重启TiDB server不是理想解决方案,发现API可用于恢复binlog。binlog同步脆弱,设置ignore-error后critical error频发,导致恢复过程复杂。

总结

在参数设置上留出buffer,注意pump gc的影响,加强对监控指标的研究,以便快速定位问题。

往期精选

  • Pump日志出现错误,你的数据被清空了吗?
  • TiDB v7.1.0:精准资源分配,实现数据流畅运行!
  • 主中心意外故障?同城双中心教你紧急恢复

想要了解更多内容?

查看原文:数据库|Drainer频繁故障,一次性解决问题!
文章来源:
神州数码云基地
扫码关注公众号