通过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应该是可以同步下去的
你希望活动在哪个城市举办?
哈尔滨
你希望听到哪些技术主题分享?线上&线下皆可
实践架构分享
是否愿意成为活动讲师?如果答案是愿意的话,你想分享什么技术主题?
否
sudo iptables -A INPUT -s 192.168.1.100 -p tcp -m tcp --dport 2379 -j ACCEPT
sudo iptables -A INPUT -s 192.168.1.101 -p tcp -m tcp --dport 2379 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 2379 -j DROP
sudo iptables -L -n
sudo iptables-save > /etc/sysconfig/iptables
sudo systemctl restart ip…