【TiDBer 唠嗑茶话会 93】TiDBer 有话说——为 TiDB 的产品发展提 *** 条建议

本期话题:

为 TiDB 的产品发展提 *** 条建议

活动后会汇总社区小伙伴们的需求给到产研相关部门。

要求:

不谈新需求,不谈未实现的新需求

关于 TiDB 产品发展的建议,关于产品在设计/研发的过程中,会由于一些细节问题,引发了一些本不应该出现的技术问题

可以按照以下模板输出:

  • 建议名称:
  • 原因:
  • 案例:
  • Asktug 链接:

本帖子为 TiDB 社区用户一起共创的内容,已列出来的请勿重复,可以优化或者列出一些对应的案例~

参考案例

建议:执行计划参数如果新版本有增加一些新的参数,应该默认为:关闭,而不是开启

原因:

TiDB 不像 Mysql,一般 TiDB 存放的数据量相比 mysql 来说会大很多,当升级新版后,一些执行计划参数默认开启经常让 DBA 有点措手不及,很容易引发 OOM ,一旦 OOM ,处理起来将特别麻烦,一朝出问题,永世不升级

案例:

tidb_ddl_enable_fast_reorg v6.5的默认值为ON,但是依赖的temp-dir默认为/tmp/tidb目录,而不是data-dir,导致升级后有不少帖子出现DDL报错的问题。

https://docs.pingcap.com/zh/tidb/v6.5/tidb-configuration-file#temp-dir-从-v630-版本开始引入

https://docs.pingcap.com/zh/tidb/v6.5/tidb-configuration-file#temp-dir-从-v630-版本开始引入

Asktug 链接:

建议:新版本新增特性参数配置默认关闭(如6.x版本执行计划缓存参数开启有OOM风险)

原因:

tidb_enable_prepared_plan_cache 从6.1版本开始引入,默认开启Prepare、Execute 执行计划缓存(),在高TPS写入场景下,tidb计算节点内存短时间暴涨至20G左右,发生OOM

案例:

生产环境案例

Asktug 链接:

活动奖励:

参与奖

按照要求提交产品建议即可获得 100 积分奖励~
提需求、闲聊、互动、没有按照要求模板提交的建议不加分。

活动时间:

2023.11.10 -2023.11.17

唠嗑茶话会马上满 100 期啦!

唠嗑茶话会将在 101 期,选出参与数最多的 TOP xxx名小伙伴送出我们的 Ti 能说徽章+神秘周边。

2 个赞

建议:grafana监控中OPS视图中others类型应该记录完整

原因:代码中以外的都在others中,理论上tidb跑的东西应该会有详细的记录,而不应该放在others里让人猜测。https://github.com/pingcap/tidb/blob/533998e5921a8f662c878b60a5d0c9608d52d736/parser/ast/ast.go#L166-L257

案例:一次监控视图中ops中others到达200,select、update等常规操作不到100,无法看到集群在执行什么

建议:文档【系统变量】【配置文件参数】目录下,添加栏目用来记录弃用系统变量或配置文件参数。

原因:新版本发布后可能会有 系统变量或配置文件参数 弃用的情况,目前是分散记录在每个版本发布说明中。无法一次查看到所有已弃用的系统变量或配置文件参数

案例:当跨大版本或较多小版本升级时,只看新版本的文档无法知道哪些 系统变量和配置文件参数 弃用了,只能逐个版本说明查看,费时费力。

Asktug 链接:tidb-server的两个参数是有改变吗?

2 个赞
  • 建议名称:建议在tiup时可选择部署分发器组件(如haproxy)
  • 原因:部署完数据库库后,还需要部署分发器组件,且分发器组件不能像其它组件一样,监控,管理,不能做到统一,建议增加分发器组件,进行统一,安装,监控,管理等。
  • 案例:部署时只能选择tidb, tikv ,pd pump,等组件唯独没有分发器组件,配置管理易出错呀
  • Asktug 链接 haproxy 之后连不上tidb

建议:可以设置自动收集统计信息的并发度和收集比例

原因:目前自动收集是单线程,表大的根本收集不完,都需要用户手工创建脚本来收集,这个可不是一个成熟的数据库应该出现的

案例:论坛中因为大表导致统计信息收集失败问题例子很多

1 个赞

看看能否加上 asktug 相关的问题链接~ :wink:

建议:dashbaord 左上角增加可以自定义设置集群名地方

原因:相同版本集群多时可以能更好的识别是哪个集群
image

3 个赞
  • 建议名称: TiDB+keepalived 的版本问题
  • 建议:TiDB能统一访问层,出自己的或测试通过的统一版本负载均衡组件。
  • 原因: TiDB 的负载均衡策略使用 HAproxy+keepalived 方案,此方案对于版本的支持没有详细建议,毕竟外部组件的自由度是一大隐患,论坛有因负载均衡造成的问题,且KEEPLIVE版本的问题导致使用 2.0.18 的版本发现偶发丢包,造成业务超时。后来替换为低版本的 1.2.8 后解决。
  • 案例:TiDB使用的坑有哪些 - 大数据 - 亿速云
  • Asktug 链接:大家都用什么做tidb server的负载均衡?

建议:CBO的持续改进和优化、tiflash性能提升
原因:
第一条是在与友商产品的性能测试对比和论坛上(人如其名)大佬性能优化帖子中不断学习得出的期望
第二条是POC测试中,发现与doris/starrocks这些还是存在一定差距(我想的是通过横向添加tiflash干掉数仓,免去cdc->数仓的烦恼,简化运维) :upside_down_face:

1 个赞

或者能直接显示出来当前集群的名字

把 asktug 相关的问题链接也加上,这样子证据确凿 hhhh

@人如其名 测出来的很多问题,其实在 v7.4.0 上很多都解决了。
可能需要你更具体地反馈,最好详细地展开说说某个点

建议:新版本最好能加一个tikv on s3

因为现在节能减排
要省钱 tidb能获得更多客户

建议名称:tikv on s3
原因:现在节能减排
案例:30tb的mysql 一天都要300元rmb的快照备份 rds数据库也要很多钱

是什么原理能省钱的?