TiDB 喊你来吐槽了！丰厚奖品等你来拿

🌠 社区资讯及活动 活动回顾
21

部分PR（all tests passed）较长时间没人review（差不多一个月？不知道在tidb算不算正常的节奏），对新人来说感觉比较挫败

PR reviewer的指派机制是否可以再优化？明显能感觉到如果部分reviewer级别较高或者与pr涉及的issue无关时，review进展很慢

3 个赞
22

现在这样的设计变成了tikv中所有数据的可访问依赖某一小片kv的可访问。

另外，我咨询过一次判定schema超期之前会有几次机会load schema，得到的答案好像是只有1次，比如说20秒心跳一次，30秒没有拿到新的schema就判定超期。我得到的这个答复如果对的话，那也是有风险的。假如说20秒更新一次，然后确实在那一时刻网络故障了1秒，那整个集群不可用时间就放大到了一个20秒。

这样总结下，你看对吗：每20秒访问整个tikv中的1%甚至更低比例的数据，如果在这1秒的时间读取整个集群中1%的数据没有读取到，集群的100%的数据在接下来的20秒都无法访问。引入这一个故障放大的隐患的收益是，为了支持一个低频的online ddl。

当然online ddl是非常好的功能，并且也是不可放弃的，吐槽这一点并不是说这个功能不好，只是希望能不能再优化下，让集群更健壮一些。

1 个赞
23

DM数据同步中能实现对单表实施初始化同步吗？

DM数据同步能实现表字段类型更改同步就完美了。

DM数据同步监控中能自带同步延迟监控就好了。

24
  1. TUG 可以考虑把 Hackathon 比赛的一些项目或者 incubator 孵化的项目跟更大程度的介绍和推进落地；
  2. TUG 跟 TiDB 产品研发（包括社区）可以建立一个推动 PR 和特性社区认领的连接；
  3. TUG 对 TiDB 新特性等并未做精细化运营（一堆 changelog 并不能体现 TUG 在这件事情上的投入）；
  4. TUG 与 tidb.io toc 组织有什么连接规划？
1 个赞
25

增加对外键的支持。

26

关于 TiUP

  • 部署集群过程中，重要信息保存在本地，丢失了就无法管理集群，是个单点；
  • 部署集群涉及的其中两个账户：一个是远程已经存在的账户，另一个是要创建的远程账户(默认是tidb，免创建目前是个实验功能)，给用户造成了很大的困扰；
  • 命令行的自动补全功能挺 鸡肋 的，tiup 的子命令自动补全不完整，子命令的自动补全 完全没有。
1 个赞
27

感谢！

您所提到的情况，之前我们的确很少收到类似的反馈，所以很少考虑这部分的优化或者说改进。

你看对吗：每20秒访问整个tikv中的1%甚至更低比例的数据，如果在这1秒的时间读取整个集群中1%的数据没有读取到，集群的100%的数据在接下来的20秒都无法访问。引入这一个故障放大的隐患的收益是，为了支持一个低频的online ddl。

这里整体上我是同意的，只不过希望补充下：1% 的数据由于是元信息，因此它们相对是 “特殊” 的。我们对它们的处理需要特别谨慎。

如果有兴趣，可否加入我们的社区 SIG-SQL-Infra，展开讨论一些细节？

28

这个语句应该就能查询到吧

SELECT 
  TABLE_SCHEMA AS '数据库名称',
  TABLE_NAME AS '数据表名称',
  TABLE_ROWS AS '数据表记录数',
  CONCAT(ROUND(DATA_LENGTH/1024/1024,2),'MB') AS '占用空间' 
FROM INFORMATION_SCHEMA.TABLES 
#WHERE TABLE_SCHEMA = 'mysql'
#AND TABLE_NAME = 'user'
ORDER BY TABLE_SCHEMA,TABLE_NAME;
1 个赞
29

产品使用过程中遇到的问题及建议：

  • 1、tidb无法使用合并的单表多列ddl
  • 2、cdc节点内存无限制增长直到oom
  • 3、cdc节点重启或者tidb高负载时 changefeed 出现[CDC:ErrSchemaSnapshotNotFound]can not found schema snapshot报错 同步停止
  • 4、cdc通过较早时间的start-ts进行重新同步大概率会报错
  • 5、tidb server节点因查询语句消耗内存导致tidb server节点oom
  • 6、tidb 未支持嵌套事务，应用抛出异常Could not create JDBC savepoint
  • 7、insert into on duplicate update类型插入耗时较长
  • 8、isolation-read.engines无法单独配置到某一个tidb server 强制走tiflash只能使用hint方式
  • 9、dashboard只能使用tidb server的root用户登录 授权码最多只有一天
  • 10、高负载时 dashboard中的慢查询页面因为实时查询数据字典太慢无法加载出来
  • 11、pd节点io wait及cpu消耗较高，高并发负载下可能成为tidb瓶颈
  • 12、新加入tikv节点rebalance完毕，leader节点平均分布，但是region数量分布严重不均衡（3倍的差距）
  • 13、统计信息更新不及时导致走到了错误的执行计划
  • 14、各个组件不同版本的配置变化较大，是否能更多的实现向下兼容，否则增大了运维难度
  • 15、没有类似mysql的mysqlbinlog的工具查看tidb的binlog，排查一些业务问题时不是很方便
    现有功能建议：
  • 1、tidb server对于内存使用需要有个限制
  • 2、cdc同步会消耗pd节点的性能，这点上是否能优化
  • 3、需要能配置单独一个tidb server的isolation-read.engines为tiflash的功能
    期望产品新增功能：
  • 1、dashboard中的慢查询页面可以增加一个分析标签 统计展示类似pt-query-digest的慢查询统计分析结果
    对于目前的社区技术支持服务体验：
  • tidb的技术支持服务很好，都很用心的帮忙分析解决问题，点赞
    其他需求和建议：
    -无

版本：v4.0.6 ticdc因fix相关bug 单独升级到v4.0.9

7 个赞
30

这个语句是不准的

31

哦，还真没有注意到:sweat_smile:

32

还有对监控的一点建议，4.0版本希望可以添加告警，之前的版本是可以的，4.0就不行了。

33

多套tidb集群和DM集群不能使用同一套监控平台，希望官方可以原生支持下吧

1 个赞
34

TiFlash：

1、目前只支持很小的并发查询，不支持高并发，对于密集型、跑批汇总(聚合类型的sql)任务来说，能走TiFlash存储引擎查询的话一定程度上会分担TiDB很大的压力，而且查询速度肯定也提升不少，希望后续能优化，能发挥出TiFlash的最大优势；

2、Grafana中TiFlash-Summary → Server → Memory和CPU Usage不显示，job的名字是job=“tiflash”，改成job="tiflash-proxy"即可显示:upside_down_face:。

35

最后一点，你可以理解 TUG 是用户社区， TOC 是开发者社区。

36

是不同的社区，但是都属于一个生态，可以把两者连接起来。

37

好的，希望TiDB更好~

1 个赞
38

TiDB写入速度不能让人太满意，且调优复杂
参数一大堆，不知道怎么用才是最合理的，对于硬件不太懂的同学，很闹心

39

1、DM同步监控主要指标：同步状态（是否中断），同步延迟，这两项默认有监控，但是默认没有告警规则
2、监控指标很丰富，一段时间不维护就有点忘，如果增加一些常见场景的排查步骤就好了。常见问题场景如：CPU持续飙高，内存使用很高（甚至OOM），热点读，热点写，连接数过多，QPS/TPS过高等等，可以根据每种场景，结合监控指标给出比较具体的排查步骤。先看哪一个监控模块下的哪个或哪几个指标，如果没问题，再看哪一个模块下的哪些指标，最好是一二三这样的顺序步骤

40

2021 年的主旋律就是 Developer Group 跟 User Group 的联动，欢迎一块探讨

1 个赞