二者可以分开考虑。
1、DM你可以简单理解为是一个binlog解析工具，会伪装成上游MySQL的一个Slave，实时解析binlog并生成SQL写入下游集群，它的升级管理是和下游TiDB解耦的，由tiup单独管理。其实下游只要是支持MySQL协议的数据库，应该都可以用它来同步，这样对比你应该就理解了。
2、对于TiDB升级，v7.5.0印象中是可以直接升级到v8.5.1的，可以现在测试环境验证。具体也请详细看看官网介绍：
https://docs.pingcap.com/zh/tidb/stable/upgrade-tidb-using-tiup/
6 天前
月初的时候做统计信息收集？这个触发的操作是脚本做的么？
这个其实是可以手动配置相关参数限制内存使用的，也可以进行采样操作，方法有不少，建议看看官网介绍。
TiDB 从 v6.1.0 开始引入了统计信息收集的内存限制，你可以通过 tidb_mem_quota_analyze 变量来控制 TiDB 更新统计信息时的最大总内存占用。
要合理地配置 tidb_mem_quota_analyze 的值，你需要考虑集群的数据规模。在使用默认采样率的情况下，主要考虑列的数量、列值的大小，以及 TiDB 的内存配置。
https://docs.pingcap.com/zh/tidb/stable/st…
14 天前
就这么点资源去做超过2亿表的复杂大SQL，肯定会有问题的，目前来看是面向OLTP业务部署的集群，如果要上大SQL业务，建议要根据业务的实际情况去合理分配资源才行。
14 天前
Tiflash应对的场景是大量数据的实时分析能力，一般场景下都没问题。
复杂大SQL的实时分析+高并发，这个能力要求其实是很高的，业界能支撑的数据库如果有，我们也想学习了解下。如果仅仅考虑能执行SQL，你可以考虑试用doris、CK、HBASE等，但是这些库你需要先把实时数据迁移过来，迁移的管理成本就会比较高。
TiDB（TiKV+TiFlash）是一个折中的方案，支持实时OLTP+OLAP，即HTAP，集群内部包含行存和列存两种引擎。如果打算采用这个方案，建议先测试验证，然后你可能需要针对性去修改SQL、引入中间表等，降低SQL复杂度，使得满足这个需求。
总之，要看你具体的业务需求和访…
14 天前
tiup 在执行命令的时候，去192.169.10.119:22机器执行命令 systemctl daemon-reload && systemctl enable tiflash-9000.service 报错了，本质上是在这台机器上执行它不成功。可以手动去执行看看什么报错，是不是不存在服务 tiflash-9000.service 。
17 天前
1、建议分层次去排查问题，确认是web服务问题，还是chaod工具问题，还是主机相关的问题。
2、可以到后台先去检查下web服务的运行日志情况，里面应该会有报错信息。
3、然后再chaod命令行工具是否可以正常执行。
分步骤排查和确认
17 天前
除非是专门的技术领域，不然现在几乎不会去用C做应用的开发了。不管是从技术门槛，还是从相关生态支撑，与人于己于公司，都有很多更好的选择。
17 天前
现在最首要的问题，是需要对全部tikv节点都做检查，如果出现磁盘空间不够的，先清理一些过期日志紧急释放，然后考虑扩容。
21 天前
线下老师们技术交流的氛围很热烈！
23 天前
没有更多内容了