tiup 在执行命令的时候，去192.169.10.119:22机器执行命令 systemctl daemon-reload && systemctl enable tiflash-9000.service 报错了，本质上是在这台机器上执行它不成功。可以手动去执行看看什么报错，是不是不存在服务 tiflash-9000.service 。

报错里提示很清楚了，是你在执行 chaod工具命令的时候，没有找到对应的依赖库导致报错了

1、建议分层次去排查问题，确认是web服务问题，还是chaod工具问题，还是主机相关的问题。 2、可以到后台先去检查下web服务的运行日志情况，里面应该会有报错信息。 3、然后再chaod命令行工具是否可以正常执行。 分步骤排查和确认

除非是专门的技术领域，不然现在几乎不会去用C做应用的开发了。不管是从技术门槛，还是从相关生态支撑，与人于己于公司，都有很多更好的选择。

磁盘空间用的这么满，要么清理数据/日志，要么扩容吧，没有其他的方法。

贴上报这些错误时tikv节点的监控情况，比如节点的资源使用、事务提交相关的监控面板灯，光看上面的日志分析不出啥来

现在集群的访问是否正常，访问的QPS和延迟情况如何？可以从grafana的TiDB 面板查看到

现在最首要的问题，是需要对全部tikv节点都做检查，如果出现磁盘空间不够的，先清理一些过期日志紧急释放，然后考虑扩容。

个人始终要持续学习，向优秀的老师们虚心学习

线下老师们技术交流的氛围很热烈！

一般是建议备份到一个共享存储，比如S3。 你这个是保存到本地吗，如果是的话，到各个tikv节点上去看对应的目录，看看有无数据。

各位大佬，深圳见~

大佬技术分享，必须来学习学习

【你使用了哪些国产分布式数据库】 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，硬限制，不可调) → …

官方工具兼容性相对比较好，基本都有涉猎

2025继续加油👏 试了好几次都是“锦鲤附体”

集中在一个region的写，推测是热点问题，可以结合tidb Dashboard和tikv details面板的资源使用的情况进一步判断，确认后可以根据官网的建议打散热点

大佬我们做数据展示，一般是后台任务执行分析计算，结果存储在tidb里再用grafana做可视化，高效又快速，很方便灵活可控