TiDB server 其他错误
可能出现的错误
- 发送请求过程中，根据 RegionCache 中的 Region 信息切分，但是 Region 信息可能已经过期，包括
- Region 发生了分裂
- Region 发生了合并
- Region 发生了调度
- 一个请求中的部分 Key 上可能有锁
- 其他错误
错误是如何处理的？
- 如果是 Region 相关的错误，会先进行 Backoff，然后进行重试，比如：
- Region 信息过期会使用新的 Region 信息重试任务
- Region 的 leader 切换，会把请求发送给新的 Leader
- 如果部分 Key 上有锁，会进行 Resolve lock
- 如果有其他错误，则立即向上层返回错误，中断请求
错误相关的监控有哪些？
- KV Errors
- KV Retry Duration：KV 重试请求的时间
- TiClient Region Error OPS：TiKV 返回 Region 相关错误信息的数量
- KV Backoff OPS（TiDB - KV Errors）：TiKV 返回错误信息的数量（事务冲突等）
- Lock Resolve OPS：事务冲突相关的数量
- Other Errors OPS：其他类型的错误数量，包括清锁和更新 SafePoint
一些常见问题补充：
- Backoff 是什么意思？→ Backoff 就是本次请求失败了，sleep 一小段时间再进行重试
- Backoff sleep 的时间长短如何确定？→ TiDB 中的 Backoff 对于不同的请求以及错误类型使用不同的 Backoff 算法，具体可以参考文档1 参考文档2
- Backoff 会一直进行吗？→ 不会
- Backoff 什么时候终止？→ 每一次失败重试之前都会 sleep 一段时间，Backoff 终止的依据是多次重试的 sleep 时间总和大于阈值
- Backoff 的阈值如何确定的？→ 目前是写死在代码之中，参考以下列表，单位毫秒
- copBuildTaskMaxBackoff = 5000
- tsoMaxBackoff = 15000
- scannerNextMaxBackoff = 20000
- batchGetMaxBackoff = 20000
- copNextMaxBackoff = 20000
- getMaxBackoff = 20000
- prewriteMaxBackoff = 20000
- cleanupMaxBackoff = 20000
- GcOneRegionMaxBackoff = 20000
- GcResolveLockMaxBackoff = 100000
- deleteRangeOneRegionMaxBackoff = 100000
- rawkvMaxBackoff = 20000
- splitRegionBackoff = 20000
- maxSplitRegionsBackoff = 120000
- scatterRegionBackoff = 20000
- waitScatterRegionFinishBackoff = 120000
- locateRegionMaxBackoff = 20000
- pessimisticLockMaxBackoff = 10000
- pessimisticRollbackMaxBackoff = 10000
- Region Error 和 Lock 可以通过监控排查，其他错误怎排查？→ 在日志中搜索 “other error”
举一个简单的例子：
一个请求发送到 TiKV 的超时时间是 60s，如果返回了错误之后每次 backoff 1s，总的 Backoff 时间是 5s，那么这种情况可以重试 5 次。考虑一种情况：前四次请求失败，且每次失败都是可重试错误，最后一次请求成功，每次请求返回时间都是 50s，那么这个请求的总的时间为 50 * 4 + 1 * 4 + 50。
这个例子想要说明的问题是什么呢？如果发现 Duration 耗时很长，不但需要去看 Backoff 的监控，还需要去查看单次 KV Duration 的耗时，以及 KV Errors 的监控进一步排查问题。