TiDB-一次错误缩容binlog带来的问题

本文详细介绍了在TiDB集群中缩容binlog的正确步骤,包括关闭binlog、缩容Drainer和Pump,并提供了两种操作方式。同时,分析了未关闭binlog即进行缩容导致的tidb服务宕机问题及其解决方案。通过关闭binlog以避免tidb因无法连接已缩容的Pump节点而引发的错误。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、正确步骤

首先说下我觉得缩容binlog的正确步骤:

1.关闭binlog

tiup cluster edit-config cluster_name
#去掉下面图片的binlog相关配置,然后重新加载配置
tiup cluster reload cluster_name

在这里插入图片描述

2.缩容drainer,pump

2.1binlogctl(比较推荐)

# 详细操作可以看官网:https://docs.pingcap.com/zh/tidb/v4.0/binlog-control#binlogctl-工具
tiup ctl binlog -pd-urls=http://127.0.0.1:2379 -cmd offline-pump -node-id ip-127-0-0-1:8250

tiup ctl binlog -pd-urls=http://127.0.0.1:2379 -cmd offline-drainer -node-id ip-127-0-0-1:8250

2.2scale-in(比较方便):

tiup cluster scale-in cluster_name -N 192.168.1.1:8250

二、错误原因及解决

1.操作

没有关闭binlog就缩容了pump

2.现象

tidb没有流量进入,tidb服务起来很快就会宕掉,查看内存使用的很少,dmesg -T也没有发现oom的现象,应用无法连接数据库

3.原因

查看tidb.log,发现有如下报错

[2022/03/23 02:58:17.223 +00:00] [FATAL] [conn.go:858] ["critical error, stop the server"] [conn=242] [error="previous statement: sql [global:3]critical error write binlog failed, the last error rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp 192.168.1.1:8250: connect: connection refused\""] [stack="github.com/pingcap/tidb/server.(*clientConn).Run\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/server/conn.go:858\ngithub.com/pingcap/tidb/server.(*Server).onConn\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/server/server.go:453"]

这个是因为tidb需要把sql发送到pump上,但因为pump已经缩容了,所以一直不能链接pump节点,tidb就会自己宕机重启

4.解决

将binlog关闭即可

操作不规范,亲人两行泪啊

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值