做了内部限制，没有小于等于的，是在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后，应该就可以了。

tidb不是针对空更新吧，tidb侧是有数据的，是mysql侧没数据

他这个更改不是针对所有update失效，而是针对在你已有但是下游没有的数据行，进行不同步，当你执行update where id = 1000;的时候，这个update应该是可以同步下去的

表有主键吗

你希望活动在哪个城市举办？ 哈尔滨 你希望听到哪些技术主题分享？线上&线下皆可 实践架构分享 是否愿意成为活动讲师?如果答案是愿意的话，你想分享什么技术主题？ 否

在服务器上curl api可以吧 curl -s http://IP:9093/api/v2/alerts | jq