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

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

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

3 个赞

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

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

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

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

1 个赞

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

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

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

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

增加对外键的支持。

关于 TiUP

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

感谢!

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

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

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

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

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

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 个赞

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

  • 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 个赞

这个语句是不准的

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

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

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

1 个赞

TiFlash:

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

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

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

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

好的,希望TiDB更好~

1 个赞

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

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

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

1 个赞