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…
应该是一个增量同步的,一个lightning导入的。
看一下你的task配置文件怎么写的。
任务名_lightning_checkpoint_list
任务名_onlineddl
任务名_syncer_checkpoint
任务名_syncer_sharding_meta
有tiflash的话,需要在tiflash节点也挂上NFS
没有备份的话就无法恢复,GC结束就代表已经物理删除了
TiFlash目前不支持包含Bit、Set和Geometry类型的表达式的下推计算。这意味着如果查询中包含这些类型的字段或表达式,它们不能被下推到TiFlash进行计算,而必须在TiDB层完成,这可能会影响性能。
解决方案:
修改数据类型:如果可能,考虑将Bit类型的字段转换为TiFlash支持的数据类型,例如INT或VARCHAR,以避免下推限制。
调整查询逻辑:重新设计查询逻辑,尽量避免在查询中使用Bit类型的字段,或者将涉及Bit类型字段的计算移到TiFlash支持的表达式中。
可以是用逻辑导出工具,Dumpling
-T 指定表名导出,将导出目录打包存放起来