一个不存在的store 0, kv request duration很高

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

  • 【TiDB 版本】:v4.0.5, 从v4.0.2升级到v4.0.4再升级到v4.0.5
  • 【问题描述】:
    dm同步数据到tidb, 经常报Region is unavailable而无法同步, 报以下错误:
    “errors”: [
    {
    “Type”: “ExecSQL”,
    “msg”: “”,
    “error”: {
    “ErrCode”: 10006,
    “ErrClass”: 1,
    “ErrScope”: 0,
    “ErrLevel”: 3,
    “Message”: “execute statement failed: REPLACE INTO lepay5.t_operation_info_40 (F_id,F_order_id,F_merchant_id,F_trade_type,F_operation_type,F_transaction_data,F_create_time,F_update_time,F_settle_amount) VALUES (?,?,?,?,?,?,?,?,?): Error 9005: Region is unavailable”,
    “RawCause”: “Error 9005: Region is unavailable”
    }
    },
    {
    “Type”: “ExecSQL”,
    “msg”: “”,
    “error”: {
    “ErrCode”: 10006,
    “ErrClass”: 1,
    “ErrScope”: 0,
    “ErrLevel”: 3,
    “Message”: “execute statement failed: begin: sql: connection is already closed”,
    “RawCause”: “sql: connection is already closed”
    }
    },

tidb 错误日志:
[txn_mode=PESSIMISTIC] [err=“[tikv:9005]Region is unavailable
github.com/pingcap/errors.AddStack
\t/home/jenkins/agent/workspace/tidb_v4.0.5/go/pkg/mod/github.com/pingcap/errors@v0.11.5-0.20190809092503-95897b64e011/errors.go:174
github.com/pingcap/errors.Trace
\t/home/jenkins/agent/workspace/tidb_v4.0.5/go/pkg/mod/github.com/pingcap/errors@v0.11.5-0.20190809092503-95897b64e011/juju_adaptor.go:15
github.com/pingcap/tidb/store/tikv.(*RegionRequestSender).onRegionError
\t/home/jenkins/agent/workspace/tidb_v4.0.5/go/src/github.com/pingcap/tidb/store/tikv/region_request.go:465
github.com/pingcap/tidb/store/tikv.(*RegionRequestSender).SendReqCtx
\t/home/jenkins/agent/workspace/tidb_v4.0.5/go/src/github.com/pingcap/tidb/store/tikv/region_request.go:276
github.com/pingcap/tidb/store/tikv.(*clientHelper).SendReqCtx
\t/home/jenkins/agent/workspace/tidb_v4.0.5/go/src/github.com/pingcap/tidb/store/tikv/coprocessor.go:879
github.com/pingcap/tidb/store/tikv.(*tikvSnapshot).batchGetSingleRegion
\t/home/jenkins/agent/workspace/tidb_v4.0.5/go/src/github.com/pingcap/tidb/store/tikv/snapshot.go:256
github.com/pingcap/tidb/store/tikv.(*tikvSnapshot).batchGetKeysByRegions.func3
\t/home/jenkins/agent/workspace/tidb_v4.0.5/go/src/github.com/pingcap/tidb/store/tikv/snapshot.go:217
runtime.goexit
\t/usr/local/go/src/runtime/asm_amd64.s:1357”]

tikv 日志: 发生错误期间,tikv没有error级别的日志, 连warn日志也没有
region health经常有少量的pending region:

倒是发现一个异常, store 0 的KV request duration很高,但实际找不到这个store 0, 不存在

pd-ctl 找不到这个store 0
image

从监控看咱们一直使用 replace 在进行操作,是不是咱们的 Task 设置的是 safemode 模式 .并可以检查下 syncer 同步的并发度

1 看了监控,没有发现有abnormal的stores:
image

2 对比了prometheus的配置文件,里面的tikv节点都是实际存在的,在pd-ctl store上也可以找到。 我是通过tiup部署的, 也没有下线过tikv

3 dm版本:
Release Version: v1.0.6
Git Commit Hash: eaf2683c05ab44143bfb286bfbbc3ba157c555cc
Git Branch: release-1.0
UTC Build Time: 2020-06-17 10:22:10
Go Version: go version go1.13 linux/amd64

4 dm-worker日志请看附件

5 dm-work自动resume能同步一小会, 然后失败,在QPS图上可以看到图形与resume间隔一致。 不知什么时候,又能正常同时一段时间,这个正常的时间长短不定,可能 半小时, 也可能好几小时

dm-worker-8265.zip (2.7 MB)

"Region is Unavailable" 一般是由于 region 在一段时间不可用导致(可能会遇到 "TiKV server is busy" 或者发送给 TiKV 的请求由于 not leader 或者 epoch not match 被打回,或者请求 TiKV 超时等),TiDB 内部会进行 backoff 重试机制, backoff 的时间超过了一定阈值(默认 20s),就会报错给客户端,如果 backoff 在阈值内该错误对于客户端是无感知的。

理论上 100 以下的 pending peer 可以忽略。你这个问题可以尝试调整 pd 参数(文档搜索下)调整下 pending peer 的相关参数。

看下 tikv 的使用情况是否出现单个 tikv 节点使用率较高的问题。

现在主要是它会中断DM的同步, 手动resume同步也不行,我也看了文档,没看到有什么解决办法。
不理它,DM每隔5分钟就会尝试resume同步, 有时能继续同步一会,有时不能, 这样导致数据从mysql同步到tidb严重延迟, 并且延迟不可控制,一天断断续续

这个还是需要解决 region is unavailable 才能根治这个问题。可以开贴提供下集群信息。我们跟进下。

现在搬迁机器, 等搞好了,我把集群起来了,再开个贴看怎么解决region unavailable的问题

:ok_hand:辛苦