TiDB 故障处理之让人迷惑的 Region is Unavailable

原文来源：https://tidb.net/blog/8f7e13dc

背景

最近某集群扩容了一批物理机，其中 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.rulessystemctl restart iptables

调整完毕后重新用客户端登录新扩容的 tidb server 执行 SQL，发现一切都恢复正常了。

同时 region 迁移也明显加速，修改前：

修改后：

总结

看似一个简单的操作就解决了问题，实际背后隐藏了很多工作在里面，碰到问题不可怕，重要的是要有清晰的思路，综合运用自己的经验。

就像有个故事里说的，知道在哪画线比会画线更值钱，troubleshooting 就是核心竞争力。

作者介绍：hey-hoho，来自神州数码钛合金战队，是一支致力于为企业提供分布式数据库 TiDB 整体解决方案的专业技术团队。团队成员拥有丰富的数据库从业背景，全部拥有 TiDB 高级资格证书，并活跃于 TiDB 开源社区，是官方认证合作伙伴。目前已为 10+ 客户提供了专业的 TiDB 交付服务，涵盖金融、证券、物流、电力、政府、零售等重点行业。