https://docs.pingcap.com/zh/tidb/v6.5/alert-rules/#tidb_tikvclient_backoff_seconds_count 发生重试的次数，很卡有可能是重试次数多，具体还是需要看SQL慢在哪里。

去Dashboard的TOP SQL观察对应服务器对应组件的资源占用SQL是什么

不会，但是好像需要有

你挂一个在备份恢复试试，印象里tifalsh是需要挂载的，恢复时候要用到

tiflash上面挂在NFS了吗

做了内部限制，没有小于等于的，是在24h内

通过store输出信息确认IP地址，然后观察要恢复的tikv地址的leader_count和region_count是否有在上升，就可以判断了把。

tiup ctl:版本 pd -u IP:端口 operator show 这个可以看到一些正在操作某些调度任务的region

2025年，祝社区的小伙伴们，健康常伴，笑口常开；

select * from information_schema.ddl_jobs where JOB_ID = ‘22381’\G 看一下这个DDL是什么

参数都在配置文件里面，就是tiup cluster deploy 指定的那个yaml文件，在里面进行参数修改。 tiup下面会有一份，路径在：~/.tiup/storage/cluster/clusters/${cluster_name}/meta.yaml

if [[ ! $clusterversion =~ ^6 ]]; then

1.确认PD IP:PORT是否填写正确 2.telnet一下，看看使用tidb-lightning命令的服务器，对于PD网络通吗。

1.参加社区组织的地区活动，有精美小礼品赠送 2.参加社区的一些比赛，则可以获取排名奖励 3.通过社区问答发布问题、回答问题，tidb课程学习，文章发布，可以快速获取积分，通过积分兑换

sync-diff工具可以直接用命令启动，二进制命令在toolkit包里面（tidb-community-server-${version}-linux-amd64） 这个下面找到sync_diff_inspector则可以直接使用

我感觉他应该是报错恢复后有一个短时间的自动更改为safe-mode = true，随后又改了回来。 具体这么做是否有自己的考量，不太清楚。

对呀，因为safe-mode = true后，传下去的update变成了delete+replace的方式，我意思这样改的话，除了第一条以外，后续的也会传下来了。 而不是像最开始的一样，只传下来首条，后面的update mysql没有的行传不下来

可以复现，如果你现在对主键字段进行变更，是可以传下去的，他把update变成了delete+insert的方式。 然后第一次的时候传下去应该也是因为CDC报错重启，自动更改了一下safe-mode=true，然后把update变为了delete+replace，导致传下去一条，然后又转回了默认值，safe-mode=false，默认值下不进行主键变更，update就是传下去update，所以没有进行更新数据。 在sink-uri里面，指定上safe-mode=true后，应该就可以了。