cdc支持可重入同步,你说的这个现象具体报错是什么?
DDL本身这条语句回自动提交事务,可以理解为ddl语句一个语句就是一个事务,执行完它就会隐式自动commit提交事务
1.执行admin show ddl jobs;查看一下集群的ddl任务队列。
2.确认第一个任务是否为大表加索引的DDL任务
可以到 pd leader节点上查看一下日志情况,用empty region 为关键字确认下有没有相关调度策略运行情况
位置元数据信息在of,region 之间可以以grpc直接相互通信
v6.5以后引入的元数据锁MDL,在有大事务DML时,DDL会被卡死,目前亟待完善可观测性,提高用户体验
有执行过scale-in进行缩容吗,集群有几个tikv节点
这个问题是fast online ddl 为了加速部分DDL的执行,会借用磁盘临时处理,默认空间不够引起的。可以设置为一个空间更大的目录。
使用资源管控功能特性,不同业务使用不同租户访问集群资源,互不干扰,实现集群资源错峰使用,减少集群和机器数量。
有任何问题要先学会查看官方文档和到社区论坛搜索关键词,这是个人成长的重要过程。
如果还没找到合适的答案,就发帖子吧,各位大佬会协助查看。
非常赞的互助材料,表妹版人工智能4.0
到ticdc的日志目录,确认下日志里出现报错 table sink stuck 的地方,获取更详细的日志信息。
这个问题解决了没,如果没有则优先处理这个问题,之后再重新执行 resume 恢复同步任务
TiDB 本质上是一个分布式关系型数据,对列数会有要求,列越多,意味着读取一行数据的代价越高,随着数据量增加出现性能问题是必然的。
楼主这个问题,和用户画像、用户特征分析、广告标签的数据分析场景比较类似,这个情况解决思路有下面几个:
垂直拆分,根据业务属性不同,在垂直方向上拆分表,减少单行的列数量。控制在官方建议的合理范围内,否则容易出现各种未知问题。
tidb天然支持超大表的存储,有不少用户都有几十亿、上百亿、甚至上万亿行的单表,且能保持不错的读写性能。基于这个特性,可以考虑调整一下表结构设计,采用列转行方式,把列转为行,每个属性一行存储,因为查询时是根据用户维度检索的,所以这…
龙虾大佬请教下,集群是v5.4.0的,能否使用高版本的ticdc组件,比如通过patch方式替换使用v7.5.x 的cdc。
在实践使用中我们也发现了这个问题,如果 TiCDC 同步流有延迟,出现重启(手动调参重启或任务自动重启)时,会有很高的瞬时 CPU 冲击,如之前遇到的一个案例在同步任务的延迟超过 20 小时后,手动重启同步流,瞬时消耗 CPU达到了 6000%(共8000%)。此时可能会带来一些额外问题,如果是和其他节点混部,可能会对集群产生冲击。
这也说明在极端场景,尤其是延迟接近 24h (GC safe point TTL)时,重启同步流会有很夸张的 CPU 瞬时冲击。这是因为 TiCDC 重启后需要重新全部获取落后的数据,重新进行落后这段时间内的变更数据拉取、排序和同步。
延迟越高,同步流重启时…
粗略计算,预计需要的tikv机器数 9台 = 30TB数据/磁盘占比50%/单盘3.5TB/单机2个盘。
如果想要更低的磁盘使用率,那么机器数要适当调高。
如果单机的内存和CPU足够高,比如有256GB内存、100vCPU这种,结合业务情况可以评估单机挂3个盘。
另外再加上 3台pd节点,tidb节点看业务情况评估是否可以考虑和pd混部,如果业务有比较重的AP分析、有OOM风险,tidb就独立部署。
监控和中控机节点可以部署1台,它们放在一起。tiflash和ticdc根据业务需要再来定。