扫码阅读
手机扫码阅读
数据库|Drainer频繁故障,一次性解决问题!
1918 2024-02-01
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
文章来源:
神州数码云基地
扫码关注公众号
摘要
本文由何傲撰写,深入分析了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:精准资源分配,实现数据流畅运行!
- 主中心意外故障?同城双中心教你紧急恢复
想要了解更多内容?
文章来源:
神州数码云基地
扫码关注公众号
神州数码云基地的其他文章
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线