建议，可以去查看下日志，看看到底啥导致的报错

怀疑是默认值 因为一开始是没有开启的，所以 checkpoint 是没有 GTID 的； 后续开启之后，由于 checkpoint 还没更新，取到的值就是默认值（空），所以就都是 0 了

@miya 建议具体描述下做了啥操作、出现了啥现象、报错具体啥错误 另外，最好提供下表结构、索引 方便复现

理论上说，tidb 执行 query 的时候，如果报 region 相关的错误的话，本身就会重试；如果 retry 超时之后，就会返回 region is unavailable，即本身就是长时间不可用了。 所以，建议check 下 tidb 集群状态 另外，不知道你的命令是怎么样的，机器配置怎么样。如果并发太高，而集群配置不高、可能也会导致 集群负载过高而出现异常

现在情况怎么样啊

感觉这个是你 shell 环境的问题？因为没找到到这个 文件、目录 或者你试试其它二进制能否执行（非 tidb 的）？

抱歉啊，你这个似乎没有 unified read pool 的 cpu 监控啊？ 看 thread cpu，主要目的是为了看看那个步骤 cpu 高了，从而确定方向、进一步分析

在dashboard 应该可以直接抓取 pprof 的，建议包括内存、cpu、goroutine 都抓下吧 [image]

可以执行如下命令，然后通过 web 方式访问，可以清楚的看到调用链 go tool pprof --http :9090 xx.prof 另外，有个 tidb-runtime ，可以看到 tidb 实例的 runtime 情况（包括内存使用、gc 等情况） [image]

是不是执行计划走错了，走到 应该走 tikv 的，实际tiflash 去了？

这里主要两个事情： 1、是 auto random 有一定的使用限制。比如，需要是 int ： https://docs.pingcap.com/zh/tidb/stable/auto-random#使用限制 2、partition 也有一定的使用限制，比如 分区键必须是 主键（唯一键）的一部分。https://docs.pingcap.com/zh/tidb/stable/partitioned-table#分区的约束和限制

找了下没找到，应该是自动调整的吧

host:port/dashboard 另外，一般来说，服务器重启会导致 防火墙有打开了；所以，可以如果还要追查，可以check 下是否重启了

怀疑有问题，可以考虑抓个 pprof 看看，分析下

插个眼 看看现在情况怎么样了，能搞定吗

羡慕你们

AUTO_RANDOM(5) 的话，说明最大值是能够达到 2^59，这是一个极大的值 简单验证下就是： max(id)&0x07ffffff ffffffff 就可以看看到多大了 其次，如果是因为id 生成重复，那比如是溢出之后从头开始，你这9000万没到这个数量级（2^32 就 20亿了，你这9千万不够看的） 那要么就是表中原来就有数据？ 或者就是那位仁兄说的 uk 重复？

hello，先这个问题恢复了吗？ 求教

既然跟 br 类似，那么这个就是一个 task show backups 应该就是一个 task 状态，即 备份的运行状态，我觉得应该在内存中维护的