【你使用了哪些国产分布式数据库】
tidb
【使用了多少新功能,体验如何】
测试用到了向量的功能
【分享一个 2024 年你比较满意的数据库使用姿势】
稳定可靠
数据传输链路大概如下,可以根据需要适当配置:
MySQL driver → (1. MySQL协议数据包大小受max_allowed_packet控制,默认64MiB,超过截断,可调)
→ TiDB Server ->(2. 事务中单行大小受 trx-entry-size-limit控制,默认120MB,超过报错,可调)
→ (3. 单个事务的大小,含全部行,受txn-total-size-limit控制,默认100MIB,超过报错,可调)
→ Raft Entry-> (4. 单个日志最大大小,raft-entry-max-size控制,默认8MB,硬限制,不可调)
→ …
集中在一个region的写,推测是热点问题,可以结合tidb Dashboard和tikv details面板的资源使用的情况进一步判断,确认后可以根据官网的建议打散热点
大佬我们做数据展示,一般是后台任务执行分析计算,结果存储在tidb里再用grafana做可视化,高效又快速,很方便灵活可控
tidb使用ticdc工具进行主从集群同步,考虑到cdc需要扫描整个集群的增量kv,然后进行排序,转义后再输出,再加网络传输,根据我们的实践经验是需要至少2s左右的时间的,符合正常延迟。
tikv CPU 高,大概率不是你贴的这个日志的原因。
建议:
1、查看grafana的tikv面板,确认是某个或某几个tikv CPU高,还是全部tikv节点高;以及分析内存、网络带宽、磁盘IO等监控;
2、结合TiDB Dashboard的热力图,确认是否有热点问题
3、如果是热点问题,可以根据官网指引解决热点问题;
4、如果是集群有大SQL出现,通常会有慢查询或通过expensive query 查看tidb.log发现到,然后对应去优化SQL。
自动化运维的前提是自动化识别故障、问题,所以比较难的点在于如何快速、准确识别和归类问题,这一步做到了,解决方法就可以针对性给出
减缓发版速度,深入打磨和完善功能,变得更稳定更可靠更易用
大佬们实至名归,社区因为有你们而更加精彩
通过社区的平台认识到业界的大佬,取其所长,开拓视野,同时了解到各家使用TiDB乃至其他DB的不同场景及经验,非常具有参考价值
不需要,TiDB 集群同步会通过TiCDC 工具实现
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。
是的,所以需要及时备份管理元数据,也就是tiup那块相关的拓扑信息
破案了,经过反复确认是业务侧使用rawkv接口去写入这个集群,导致元数据混乱,出现原TiDB集群无法解码的内容。进而出现这些问题。