背景
最近某集群扩容了一批物理机,其中 TiKV 节点有6台机器12个实例,同时调整了 label 设置增加了一层机柜级容灾。因为前期做了比较充分的准备工作,到了变更窗口只等着执行scale-out
就行,操作过程也很顺利,很快就把所有节点都扩进去了,检查完各实例的运行状态,确保region已经开始正常调度,就放心去睡觉了(半夜变更,结束时凌晨1点左右)。
第二天一大早还在上班路上,业务方反馈数据库有部分SQL报错Region is Unavailable
,怀疑新扩容的 TiKV 节点出了问题,火速赶到公司开始排查。
此时内心os,打工人1024不加班的小小心愿要破灭了。。🤣
故障现象
业务方反馈的报错信息如下:
其实Region is Unavailable
不算什么疑难杂症,从过往经验来判断基本是 TiKV 节点的原因,从字面意思上看就是region在某段时间内不可用,可能的因素有:
- region leader在调度中,或者无法选举出leader(会有内部backoff)
- tikv实例繁忙被限流,同步可能会有
TiKV server is busy
报错 - tikv实例故障挂掉了,同步可能会有
TiKV server is timeout
报错 - 其他tikv未知问题或bug等
前三种基本能覆盖90%以上的场景,所以我一开始还是从tikv着手排查。
但是让人迷惑的是,各种分析下来最后发现和tikv没有关系,这就是最有意思的点。🙈
好戏开始。
排查过程
首先检查前一天晚上扩容的12个tikv实例运行状态,分析监控和日志并未发现有异常现象,无重启,各节点负载也很低不存在性能瓶颈。
接着怀疑是偶发性报错,因为region还处于调度中(到这里感觉到了调度不太正常,比预期中的要慢),偶发性还是有可能的,另外通过监控面板failed query OPM
发现tikv:9005
报错码只是零星出现,也不排除这种可能性。
验证方式:从dashboard日志搜索中找出具体报错的SQL,直接用报错码搜索即可:
把SQL拿出来尝试手动执行,发现也报同样的错,多次执行效果一样。于是怀疑这张表的region有副本丢失,打算用show table regions
看下这张表的region分布,发现了一个奇怪的报错:
从报错信息看,在执行show table regions
的时候tidb server去请求了pd的一个API,这个API是作用是查询region id为xxx的详细信息,但是无法访问pd节点。跟着报错信息,我去检查了这个pd节点的状态,发现没有任何异常,服务正常运行未发生过重启。
接着我进去pd-ctl用报错的region id查询region信息,也能够正常返回,确认pd节点正常。
退出客户端,手动执行curl API,报错依旧,telnet测试报错pd实例,无法连接,然后把三个pd都telnet了一遍,发现只有这一个pd无法访问,异常诡异,初步怀疑网络有问题。
但是扩容前网络环境都检查过都是联通状态,而且都在同一个网段中,不应该有网络故障。
接着转头去看那个连接不上的pd节点日志,跟踪了一段时间发现绝大部分都是region调度的信息,但是一点一点翻发现中间偶尔出现operator timeout
的字样,认真把日志读了几遍总算看清楚了它说的啥,大意就是在两个store之间mv peer超时(应该是10min)失败了:
期间并没有发现pd自身运行异常问题,回想起前面的调度慢,猜测应该和这个现象有关,貌似和Region is Unavailable
有一点点沾边了,但还不能完全解释过去,继续怀疑网络。
吐槽:给个WARN日志是不是好点
接着命令行登录原有的tidb实例,再次执行报错的SQL和show table regions
,神奇的事情发生了,均能够正常返回。再换另一台新扩的tidb节点执行,报错依旧。
到这里基本判定是新扩进来的tidb实例有问题,此时距离故障出现超过2小时,业务方开始着急了,无奈之下只能把新扩的tidb实例从负载均衡中剔除临时绕过,详细原因进一步排查。
重新梳理了一下思路,我们都知道正常select查询和show table regions
都需要从pd获取表的region分布信息,这个请求是从被连接的tidb server上发起的,现在奇怪的地方是新扩容的tidb server无法访问pd,原有的可以访问,那说明极有可能是新节点被限制访问了。
登录pd节点查看防火墙状态,是关闭状态,进一步检查发现iptables服务开启,查看配置规则后虎躯一震:
这简直是在不亚于在代码里下毒啊,所有tidb集群相关的通信端口全都显式地做了限制,只允许原集群的5台机器访问,做了也不算啥,偏偏有的做有的不做,这就有点坑了。。。而且这台机器上还部署了2个tikv实例,那前面operator timeout
也说的通了。
至此复盘一下问题:原集群某些节点设置iptables规则,限制集群外的节点无法与tidb内部服务通信,新扩容的机器并不知道有这个限制,导致新扩容的tidb server无法从pd获取region信息,连接到新tidb server的会话无法读到region,抛出Region is Unavailable
报错。同时该节点上的tikv实例无法与新扩容的tikv实例通信,导致region调度受影响,直观感受是调度非常慢。
回过头再看,还好故障比较简答,1024算是保住了。
解决方案
经过各方沟通,得知iptables是为了解决早期某安全漏扫问题设置,现在也没办法直接关掉。那么解决办法就只有一条路,把新扩容的所有机器ip都加到iptables白名单里即可,顺便也检查了原有的5台机器iptables设置情况,该加的都加上。
vi /etc/iptables.rules
systemctl restart iptables
调整完毕后重新用客户端登录新扩容的tidb server执行SQL,发现一切都恢复正常了。
同时region迁移也明显加速,修改前:
修改后:
总结
看似一个简单的操作就解决了问题,实际背后隐藏了很多工作在里面,碰到问题不可怕,重要的是要有清晰的思路,综合运用自己的经验。
就像有个故事里说的,知道在哪画线比会画线更值钱,troubleshooting就是核心竞争力。
作者介绍:hey-hoho,来自神州数码钛合金战队,是一支致力于为企业提供分布式数据库TiDB整体解决方案的专业技术团队。团队成员拥有丰富的数据库从业背景,全部拥有TiDB高级资格证书,并活跃于TiDB开源社区,是官方认证合作伙伴。目前已为10+客户提供了专业的TiDB交付服务,涵盖金融、证券、物流、电力、政府、零售等重点行业。