按照使用经验来说,这个Tombstone Stores是表示历史上 变为tombstone的tikv节点数量。当年我们首次使用的时候也和原厂工程师做过沟通,这是个合理正常的数值,方便查看,用户可以不用关注这个点。
如果说有什么“不合理”的点,那就是不应该标注为“红色”,避免以为是有问题,其实当前集群是正常的,可能标记为灰色更符合大家的习惯。
根据楼主贴的监控图信息,是store-1 这个tikv节点出现了访问延迟过高,单点瓶颈问题导致cop 任务(在存储层扫描读取数据的过程)出现了慢的现象。
先确认store-1对应的ip和节点,然后重点分析下它:
1、是否有热点问题
2、是否节点当时过于繁忙导致的抖动问题
3、根据该节点的tikv日志,分析当时有无其他异常信息,结合集群当时的现状深入分析
根据描述,可以确认的是TiDB的执优化器对于这个SQL的执行计划的理解,和我们预期的不一致。
这里有两个思路可以评估下:
1、 统计信息是否过期?如果过期请使用analyze尝试更新下。
2、根据SQL的语义,是需要将满足条件的数据全部逆序排序再返回,过滤、排序是会尽量依靠索引来实现的,所以重点评估索引的创建是否合理。
建议使用v8.5.x的最新版本。
TiDB v7.1以来的版本不管是从功能、性能等方面,都有比较大的改善了,可以择一而用。
【简化技术栈是一个必然的趋势吗?】
是,也不是。
整个系统的技术复杂度不会改变,随着业务发展或规模增长,甚至更加复杂,但是如果从用户使用的角度出发、对业务使用侧来说外形态是会高度融合的,以前TP、AP都是分开,现在是HTAP,接着是HTAP+向量能力。对外是一个单一的产品,内部却是能力边界的不断扩展和深度整合。
【在使用 TiDB 过程中,有哪些优质的极简开发体验令你印象深刻?】
HTAP、高可用、高可扩展能力。
以及tiup工具的使用极大简化了使用管理的心智负担。
【已落地或正在规划的AI 应用业务场景有哪些?用 TiDB 来支持过哪些 AI 业务 & 应用 ?】
正在规划推动既定的方案。
【目前你所在的企业数据类型有哪些?向量数据更倾向于存在向量数据库还是 TiDB 这种一体化数据库?】
考虑到学习门槛和掌握成本等综合考虑,更加优先考虑在已知数据库的基础上加上向量功能。如TiDB 一体化、PG Vector的方案。
如果只要需要单机RocksDB,从生产实践上单点的风险太高,其实没什么必要。
如果是从技术调研、测试环境使用的角度,可以试试,但是估计不能兼容上层PD和TiDB的节点。
一年一度的征文大赛又开启了~

【大家学习 TiDB 课程的进度如何?看过哪些课程,体验如何?】
体验很赞,老师的声线很有磁性~
【你希望未来 TIDB 社区举办哪些主题的 TiDB 学习活动呢?你最期待的活动形式和学习内容是?】
希望大家多参与线上的知识分享,文档大赛就是一种很不错的方式
pending-peer-region-count 表示正在pending的region数据量,通常在做内部raft log同步时会出现,如果是少量的 pending peer 是正常的。
但是如果持续很高,可能有问题,说明短时间内有大量的数据需要进行pending。此时需要排查:
观察 region health 面板,检查 pending_peer_region_count 是否在不断减少。
检查 TiKV 之间的网络状况,网络是否有波动、是否卡顿、带宽是否足够等。
确认TiKV节点去访问pd 的网络是否正常,PD节点当时是否有卡顿等。
通常是网络抖动的因素会多一点,请注意排查和确…
我们之前的经验,如果是按月分区,提前建好半年的,如果是按天分区也提前建好90天,然后脚本定期去加新的分区,提前建好分区应该不会有这个问题。可以考虑看看。