BR 恢复失败 split region failed

yuqi1129 · 2022 年6 月 7 日 01:49

【 TiDB 使用环境】生产\测试环境\ POC
生产
【 TiDB 版本】
4.0.15
【遇到的问题】

[2022/06/07 09:30:36.995 +08:00] [ERROR] [restore.go:34] [“failed to restore”] [error=“split region failed: err=message:"Coprocessor [components/raftstore/src/coprocessor/split_observer.rs:154]: no valid key found for split." : [BR:Restore:ErrRestoreSplitFailed]fail to split region”] [errorVerbose=“[BR:Restore:ErrRestoreSplitFailed]fail to split region
split region failed: err=message:"Coprocessor [components/raftstore/src/coprocessor/split_observer.rs:154]: no valid key found for split."
github.com/pingcap/br/pkg/restore.(*pdClient).sendSplitRegionRequest
\tgithub.com/pingcap/br@/pkg/restore/split_client.go:287
github.com/pingcap/br/pkg/restore.(*pdClient).BatchSplitRegionsWithOrigin
\tgithub.com/pingcap/br@/pkg/restore/split_client.go:332
github.com/pingcap/br/pkg/restore.(*pdClient).BatchSplitRegions
\tgithub.com/pingcap/br@/pkg/restore/split_client.go:371
github.com/pingcap/br/pkg/restore.(*RegionSplitter).splitAndScatterRegions
\tgithub.com/pingcap/br@/pkg/restore/split.go:271
github.com/pingcap/br/pkg/restore.(*RegionSplitter).Split
\tgithub.com/pingcap/br@/pkg/restore/split.go:131
github.com/pingcap/br/pkg/restore.SplitRanges
\tgithub.com/pingcap/br@/pkg/restore/util.go:390
github.com/pingcap/br/pkg/restore.(*tikvSender).splitWorker
\tgithub.com/pingcap/br@/pkg/restore/pipeline_items.go:234
runtime.goexit
\truntime/asm_amd64.s:1357”] [stack=“github.com/pingcap/br/cmd.runRestoreCommand
\tgithub.com/pingcap/br@/cmd/restore.go:34
github.com/pingcap/br/cmd.newDBRestoreCommand.func1
\tgithub.com/pingcap/br@/cmd/restore.go:131
github.com/spf13/cobra.(*Command).execute
\tgithub.com/spf13/cobra@v1.0.0/command.go:842
github.com/spf13/cobra.(*Command).ExecuteC
\tgithub.com/spf13/cobra@v1.0.0/command.go:950
github.com/spf13/cobra.(*Command).Execute
\tgithub.com/spf13/cobra@v1.0.0/command.go:887
main.main
\tgithub.com/pingcap/br@/main.go:58
runtime.main
\truntime/proc.go:203”]
[2022/06/07 09:30:36.995 +08:00] [ERROR] [main.go:59] [“br failed”] [error=“split region failed: err=message:"Coprocessor [components/raftstore/src/coprocessor/split_observer.rs:154]: no valid key found for split." : [BR:Restore:ErrRestoreSplitFailed]fail to split region”] [errorVerbose=“[BR:Restore:ErrRestoreSplitFailed]fail to split region
split region failed: err=message:"Coprocessor [components/raftstore/src/coprocessor/split_observer.rs:154]: no valid key found for split."
github.com/pingcap/br/pkg/restore.(*pdClient).sendSplitRegionRequest
\tgithub.com/pingcap/br@/pkg/restore/split_client.go:287
github.com/pingcap/br/pkg/restore.(*pdClient).BatchSplitRegionsWithOrigin
\tgithub.com/pingcap/br@/pkg/restore/split_client.go:332
github.com/pingcap/br/pkg/restore.(*pdClient).BatchSplitRegions
\tgithub.com/pingcap/br@/pkg/restore/split_client.go:371
github.com/pingcap/br/pkg/restore.(*RegionSplitter).splitAndScatterRegions
\tgithub.com/pingcap/br@/pkg/restore/split.go:271
github.com/pingcap/br/pkg/restore.(*RegionSplitter).Split
\tgithub.com/pingcap/br@/pkg/restore/split.go:131
github.com/pingcap/br/pkg/restore.SplitRanges
\tgithub.com/pingcap/br@/pkg/restore/util.go:390
github.com/pingcap/br/pkg/restore.(*tikvSender).splitWorker
\tgithub.com/pingcap/br@/pkg/restore/pipeline_items.go:234
runtime.goexit
\truntime/asm_amd64.s:1357”] [stack=“main.main
\tgithub.com/pingcap/br@/main.go:59
runtime.main
\truntime/proc.go:203”]
【复现路径】做过哪些操作出现的问题

6月4号20点做了一次全备
6月6号10点开始全备恢复，大概在第二天的凌晨恢复完
6月7号10点开始增量恢复（6月4号20点到6月6号17点的增量），出现的错误如下
此时gc 时间设置的比较长168h(7天)
后经沟通可能是gc 设置过长导致该问题，于是调小gc 并执行compact , 结果磁盘满了，集群挂了，于是重做集群& 全量恢复

第二次全量恢复完之后， gc 相关信息如下

6月9号10点多开始做增量恢复，结果又出现一样的错误

【问题现象及影响】
【附件】

相关日志、配置文件、Grafana 监控（https://metricstool.pingcap.com/)
TiUP Cluster Display 信息
TiUP CLuster Edit config 信息
TiDB-Overview 监控
对应模块的 Grafana 监控（如有 BR、TiDB-binlog、TiCDC 等）
对应模块日志（包含问题前后 1 小时日志）

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

xfworld · 2022 年6 月 7 日 08:01

看起来是一个已知，已经修复的bug

https://github.com/pingcap/br/issues/627

有相关的操作步骤的描述么？

yuqi1129 · 2022 年6 月 7 日 08:27

这个issue 我看了一下合并日期，4.0.15似乎已经修复了，怎么还会报错误呀~~

有相关的操作步骤的描述么？你指的是相关配置吗？

jansu-dev · 2022 年6 月 7 日 09:03

麻烦提供下全部 br restore log

yuqi1129 · 2022 年6 月 7 日 09:12

restore_test-2022-06-06-17.log (292.6 KB)

这个是恢复日志

jansu-dev · 2022 年6 月 7 日 09:52

这问题是重启就过去了吗？所以关闭？
还是重新下了个该版本的 br ?

yuqi1129 · 2022 年6 月 7 日 10:15

这问题是重启就过去了吗？所以关闭？没有，我没有重启啥东西。。。， tikv没有重启

还是重新下了个该版本的 br ? 这个是啥意思啊

jansu-dev · 2022 年6 月 7 日 10:21

为什么该帖会已点《该内容对我有帮助》？
按我理解该问题《该内容对我有帮助》表示对应问题已解决，以为你通过某种操作绕过了该问题；

yuqi1129 · 2022 年6 月 9 日 03:30

6月9号的错误信息如下；
BR: 信息

restore_test-2022-06-06-18.log (9.6 MB)

TiKV 信息：

yuqi1129 · 2022 年6 月 9 日 03:39

另外: 想请教一下，增备支持幂等吗？我想重试一下，但又不确定重新执行的话会不会导致数据问题比如说数据重复之类的

spc_monkey · 2022 年6 月 9 日 05:26

这个问题是 mvcc 版本太多导致分裂的时候，找到的中间 key（middle key 和左边界key 一致了导致），（mvcc 版本产生的速度超过了 GC 的速度），需要咱们咱们 compact 一下。
1、可以手动 split region一下（region id 在报错中有提到：1735105），然后检查日志是否可以 split（如果ok，那就ok，不过大概率还是报同样的错误）
2、tidb API 有查看 region 的mvcc 版本的 API（asktug 上也能搜到），一会我补充一下
3、上面都是辅助验证的信息，但想解决，还是需要 compact-cluster ，主动 compact 一下
4、看这次的 region id 不一样了，建议把 tikv 日志过滤一下，看看类似的问题region 多吗，另外，最好帮描述一下，这些 region 所涉及的表，更新频率如何

spc_monkey · 2022 年6 月 9 日 05:34

补充：
1、上面提到的 compact 命令，可参考官网，或如下： tiup ctl:v4.0.15 tikv --pd xx.xx.xx.xx:2379 compact-cluster --bottommost force -d kv -c write
2、tidb http API 查看 mvcc 版本：https://github.com/pingcap/tidb/blob/master/docs/tidb_http_api.md（刚看了一下，这里的 API 好像结果都不直接），可以用下面的命令：
2.1 用 tikv-ctl 命令查看 size 很大，mvcc.num_rows 非常多
tikv-ctl --host : size -r
tikv-ctl --host : region-properties -r

spc_monkey · 2022 年6 月 9 日 05:40

另外，帮确认一下：是否开启了 compaction filter 功能，show variables like ‘%compaction%’

yuqi1129 · 2022 年6 月 9 日 06:06

看这次的 region id 不一样了，建议把 tikv 日志过滤一下，看看类似的问题region 多吗，另外，最好帮描述一下，这些 region 所涉及的表，更新频率如何

你是指除了这个region, 还有没有其它region 也报region split error
今天BR恢复只涉及一张表，这个表比较大， 300亿行，平均第天新增5000w行

yuqi1129 · 2022 年6 月 9 日 06:07

xxx@xxx (supply_chain_factory) > show variables like ‘%compaction%’;
Empty set (0.01 sec)

Thu Jun 9 14:01:42 2022

yuqi1129 · 2022 年6 月 9 日 06:11

compact-cluster 我现在不敢直接执行，昨天磁盘占用在80%，执行完之后磁盘直接100%了，集群直接无法起动，连space_holder 删除掉都没有用。现在磁盘占用近70%，执行完之后情况不明

不太理解啊，现在gc 10min, 怎么还是有 mvcc 版本太多问题啊？另处一个增量恢复是幂等的吗？即使可以做compact-cluster，是幂等才能再次重试呀

spc_monkey · 2022 年6 月 9 日 07:25

1、上面的不是 show variables 是 show config 查看，我写错了
2、担心 GC 正常推进，但实际没有正常 GC ，所以想看看上面的参数是否开启
3、BR 增量备份是否幂等，准确说不是：增量都是只从上一次备份时间到现在的时间，建议看这个：https://docs.pingcap.com/zh/tidb/dev/br-usage-backup#备份-tidb-集群增量数据
4、compact-cluster 可以替换成 compact 命令试试，https://docs.pingcap.com/zh/tidb/stable/tikv-control#通用参数（如果真不方便，上面的 compaction filter 功能先关闭试试）

yuqi1129 · 2022 年6 月 9 日 07:59

1、上面的不是 show variables 是 show config 查看，我写错了
这个show config like ‘%compaction%’
x@xxx ((none)) > show config like ‘%compaction%’
-> ;
Empty set (0.03 sec)

见上
我是说增量恢复是否幂等，因为恢复中途失败了，我想能不能重试
我可以试试使用compact 而不是compact-cluster，不过麻烦确认一下第三个问题

spc_monkey · 2022 年6 月 9 日 15:00

哦，你的版本没有 compaction filter 参数，至于 BR 增量备份，中途失败，可以再次执行，每次都是针对上一次全备时 tso 来进行的增量

yuqi1129 · 2022 年6 月 9 日 15:14

大佬我想问的是恢复是否是幂等？备份我知道每次都是基于tso 快照，现在恢复不是中途失败了么我想重试看看