【TiDB 版本】
v4.0.4
【问题描述】
通过dumpling逻辑导出，因tikv down导致导出失败
重启tikv 状态 up，重新导出可能还会因tikv down，导出报错终止，
看导出是根据_tidb_rowid通过 -r 参数控制每次导出的rowid范围，请问如何根据目前报错信息继续导出剩余的表数据？
重启tikv 状态 up，重新导出可能还会因tikv down，导出报错终止，
看导出是根据_tidb_rowid通过 -r 参数控制每次导出的rowid范围，请问如何根据目前报错信息继续导出剩余的表数据？
1.建议首先排查下 tikv down 掉的原因；
2. dumpling 支持按照 where 条件导出数据，可以参考：
https://docs.pingcap.com/zh/tidb/stable/dumpling-overview#使用---where-选项筛选数据
现在 tikv 节点都是 up 状态吗？麻烦反馈下 tiup cluster display {cluster-name} 的结果。
具体的 dumpling 命令麻烦提供下。
nohup /tidb-toolkit-v4.0.4-linux-amd64/bin/dumpling
-u root
-P 30271
-p xxxxxx
-h xxxx
–filetype sql
–threads 20
-o /tidb-backup/real_items1
-r 200000
–sql ‘SELECT * FROM face_world_test.real_items WHERE _tidb_rowid >= 203767723’ &
如果表的主键是整数类型的话，rowid 和 主键是等价的，可以用主键字段代替上面的 “_tidb_rowid”
SELECT MIN(_tidb_rowid),MAX(_tidb_rowid) FROM xxx ;这个sql是能执行成功的，为什么 _tidb_rowid >= 203767723’ 报错 ，通过版本升级可以解决问题么？
主键不是整数类型，是varchar类型，还有什么办法能继续导出呢；
麻烦提供下上面报错的这张表的表结构，谢谢
我这边测试了下没有复现你的现象，麻烦按照实际的情况返回下命令的查询结果：
curl http://{TiDBIP}:{Ports}/mvcc/key/{db}/{table}/{handle}
其中 {handle} 即为上面查询 SQL 的 _tidb_rowid ‘203767723’
看起来有 3 个帖子吧？是否都是 tikv down 导致，如果是建议先在一个帖子中处理，多谢。
上面的端口是 status_port ，默认是 10080，麻烦重新试下。
我理解tikv donw 和dumpling数据导出问题，不是同一个问题
前面报错截图中有个warn信息 ，staleCommand backoffer. maxsleep 40000ms is exceeded. region ID: 786546
查看region信息
这个region group 只有2个peer，有主，对查询有影响么？
这个问题和上面帖子里面就其原因，如果要定位这个问题，涉及到这个 https://asktug.com/t/topic/92880 帖子中操作的步骤和日志一并查看，所以建议通过一个帖子来定位这个问题 ~
社区这边会把这些帖子当成一个问题来查看的 ~
https://asktug.com/t/topic/92880 帖子，引发的后续的问题，比如该贴，解决后。那么您那边可以整理一个『经验分享』的内容，以供社区的其他的小伙伴和老师参考哈 
~