如果只要需要单机RocksDB，从生产实践上单点的风险太高，其实没什么必要。
如果是从技术调研、测试环境使用的角度，可以试试，但是估计不能兼容上层PD和TiDB的节点。
12 天前
一年一度的征文大赛又开启了~ 
12 天前
博文老师的分享很有技术，PPT也做的很精美
12 天前
【大家学习 TiDB 课程的进度如何？看过哪些课程，体验如何？】
体验很赞，老师的声线很有磁性~
【你希望未来 TIDB 社区举办哪些主题的 TiDB 学习活动呢？你最期待的活动形式和学习内容是？】
希望大家多参与线上的知识分享，文档大赛就是一种很不错的方式
12 天前
pending-peer-region-count 表示正在pending的region数据量，通常在做内部raft log同步时会出现，如果是少量的 pending peer 是正常的。
但是如果持续很高，可能有问题，说明短时间内有大量的数据需要进行pending。此时需要排查：
观察 region health 面板，检查 pending_peer_region_count 是否在不断减少。
检查 TiKV 之间的网络状况，网络是否有波动、是否卡顿、带宽是否足够等。
确认TiKV节点去访问pd 的网络是否正常，PD节点当时是否有卡顿等。
通常是网络抖动的因素会多一点，请注意排查和确…
1 个月前
二者可以分开考虑。
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/
2 个月前
月初的时候做统计信息收集？这个触发的操作是脚本做的么？
这个其实是可以手动配置相关参数限制内存使用的，也可以进行采样操作，方法有不少，建议看看官网介绍。
TiDB 从 v6.1.0 开始引入了统计信息收集的内存限制，你可以通过 tidb_mem_quota_analyze 变量来控制 TiDB 更新统计信息时的最大总内存占用。
要合理地配置 tidb_mem_quota_analyze 的值，你需要考虑集群的数据规模。在使用默认采样率的情况下，主要考虑列的数量、列值的大小，以及 TiDB 的内存配置。
https://docs.pingcap.com/zh/tidb/stable/st…
2 个月前
就这么点资源去做超过2亿表的复杂大SQL，肯定会有问题的，目前来看是面向OLTP业务部署的集群，如果要上大SQL业务，建议要根据业务的实际情况去合理分配资源才行。
2 个月前
Tiflash应对的场景是大量数据的实时分析能力，一般场景下都没问题。
复杂大SQL的实时分析+高并发，这个能力要求其实是很高的，业界能支撑的数据库如果有，我们也想学习了解下。如果仅仅考虑能执行SQL，你可以考虑试用doris、CK、HBASE等，但是这些库你需要先把实时数据迁移过来，迁移的管理成本就会比较高。
TiDB（TiKV+TiFlash）是一个折中的方案，支持实时OLTP+OLAP，即HTAP，集群内部包含行存和列存两种引擎。如果打算采用这个方案，建议先测试验证，然后你可能需要针对性去修改SQL、引入中间表等，降低SQL复杂度，使得满足这个需求。
总之，要看你具体的业务需求和访…
2 个月前
tiup 在执行命令的时候，去192.169.10.119:22机器执行命令 systemctl daemon-reload && systemctl enable tiflash-9000.service 报错了，本质上是在这台机器上执行它不成功。可以手动去执行看看什么报错，是不是不存在服务 tiflash-9000.service 。
2 个月前
1、建议分层次去排查问题，确认是web服务问题，还是chaod工具问题，还是主机相关的问题。
2、可以到后台先去检查下web服务的运行日志情况，里面应该会有报错信息。
3、然后再chaod命令行工具是否可以正常执行。
分步骤排查和确认
2 个月前
除非是专门的技术领域，不然现在几乎不会去用C做应用的开发了。不管是从技术门槛，还是从相关生态支撑，与人于己于公司，都有很多更好的选择。
2 个月前
没有更多内容了