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

🌠 社区资讯及活动
#1

亲爱的 TiDBer ，

大家好，马上就年末了，很多朋友也都在进行过去 2020 年的一些总结和盘点。过去一年，TiDB 在所有社区小伙伴的支持和帮助下快速发展，成长过程中难免会有一些磕磕绊绊，让大家觉得不舒服、不开心以及需要改进的地方。

因此，我们特地举办此次吐槽活动，不论您是开发者，还是社区用户，大家在了解、学习、使用、贡献 TiDB 过程中有任何需求、建议和问题都可以吐槽给我们。每一位小伙伴的吐槽我们都会认真倾听和思考，积极采纳与改进。 更重要的是，参与的小伙伴还有机会获得我们提供的丰厚的奖品，快快行动吧！

时间 ：

2021 年 1 月 27 日 — 2021 年 1 月 29 日

格式：

您可以任选其中的一些项目在本贴内留言吐槽

  • 产品使用过程中遇到的问题及建议：
  • 现有功能建议：
  • 期望产品新增功能：
  • 社区组织的活动体验：
  • 对于目前的社区技术支持服务体验：
  • 对于目前 TiDB 社区项目的吐槽：
  • 对于目前 TiDB 社区运营人员的吐槽：
  • 其他需求和建议：

礼品：

为了感谢大家给予的反馈，本次吐槽活动我们准备了丰厚的礼品：

留言点赞数第一名的小伙伴将获得蓝牙音箱一台；

留言点赞数前 5 名的小伙伴将获得 TUG 冬日定制围巾一条；

前 20 位认真吐槽的小伙伴将获得 TUG 周年定制T恤一件；

另外参与本次活动的小伙伴都可以获得 500 积分奖励。

58
581492×786 210 KB

WX20210127-105233%402x
WX20210127-105233%402x2038×992 342 KB

感谢有您，让 TiDB 勇往直前；期待有您，陪伴和见证 TiDB 的每一点进步，欢迎您畅所欲言！

获奖名单公布：

恭喜 TUG微尘 获得蓝牙音箱一台
恭喜 18515065291，bbhy135258，Tjianke，sykp241095，honor100，tsthght 获得周年定制围巾一条

4 个赞
Tidb 如何为grafana 配置http_proxy 以及https_proxy
#2

是否有可以有图形化的安装部署和配置管理及日志搜集呀？谢谢！

#3

我想很清晰的看到每个表所占的存储空间大小。

#4

1、TiDB写入速度不能让人太满意，且调优复杂
2、TiFlash AP性能不能让人满意，且内存无限制
3、dashboard，拉时间范围的组件不好用
4、TiUP的问题居多，例如：
a:tiup执行pd-ctl 命令不能外部调用
b:离线部署多版本，才支持
c:对运维的工作、需求了解不好
d:对于3.x版本升级过来的，还会造成误删除节点
e:总改相关输出项目，导致自动化难度高，改自动化代码频繁（例如获取dashboard地址，新旧版本输出不一样）
5、TiDB对于机器资源要求、使用很高，尤其CPU/磁盘，导致选型困难
6、主键不能操作，最近的问题：自增主键，业务自己指定主键写入，导致写写冲突，主键值变的很大
7、alter 还是只能指定一个操作，不能一个SQL操作加多个索引
8、很多类型不能改，例如varchar只能加长，decimal不能改

16 个赞
#5
#6

后面稳定版本是否可以推出 日志结构描述的内容呀？谢谢

#7

1 按业务场景，提供现有接入的最佳实践+采坑/避坑指南，用户之间分享经验
2 稳定性加强，确定每个组件异常宕机最大故障时间和故障范围，以及对应故障处理手册
3 TP性能提升，尤其是在混合TP workload 下的性能提升
4 可观测性增强，监控力度更细，能够在dashboard上可以提供按照表维度或者用户维度的监控等

2 个赞
#8

1、分区表一直不支持 key 分区，也就是不支持 字符串 hash 分区；等待了好久，说是 5.0 会出，结果 5.0 出了，还是没有
2、希望 tikv 也和 tiflash 一样，支持多块盘存储

2 个赞
#9

为了支持online ddl，引入了一个非常致命的软肋。
tidb几次心跳内无法加载最新的schema就导致tidb服务不可用。
这个事儿有点大。

真正的生产环境，修改表结构是个非常低频的操作，为了支持一个非常低频的操作，引入一个几十秒就要同步一下schema信息，同步不到就拒绝服务的机制，代价有点大。

建议整个选项，或者优化这个机制，如果没有ddl的job，就不需要同步schema了。

1 个赞
#10

大家肯定会很多不爽的地方，只要实事求是，都可以吐槽。除此之外，我们还有个传统，就是会定期举办《吐槽大会》，本周末 TUG 牵头搞第三期《吐槽大会》，我们会邀请大家当中的代表和 TiDB 产研负责人进行面对面。目前已经有潇姐、春雷、晓磊报名。欢迎更多小伙伴来报名或者给直接给他们几位提供弹药与建议。

3 个赞
#11

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

问题：

1.执行计划突然改变导致业务出问题(频率较高影响较大)
2.Tiflash查询优化，Tiflash查询前需要同步所有数据，保证读取到最新的数据，会影响查询效率
3.tidb insert优化，目前在生产环境遇到过一些瓶颈，希望insert能更快
4. 关于调度，没配置label，我这边扩容之后新节点磁盘降的很慢(调大store limit会加快)，老节点磁盘还在快速下降(重点)，并且集群稳定后，各节点磁盘使用量并不平衡
5. 集群中有tikv节点磁盘爆掉之后drop partition未执行
6. cdc下游配置mysql/tidb时，配置的用户没检查权限是否满足要求
7. TiUP元数据怎么备份，目前元数据单份，有一定的风险

现有功能建议

1.加强分区表partition的功能

案例：下推至tiflash的执行计划未做分区裁剪

需求：

  • 支持更优的分区裁剪功能，加快查询效率
  • 目前mysql规范中，分区键一定要加入到pk/uk中，但是这对业务会有一些侵入性。比如分区键是时间字段，用upsert逻辑更新时间字段会导致多一条数据出来，业务还要先删除原来的数据。需求是upsert也能在原来的数据上直接改。（这个突破了mysql对分区表的定义，或许tiflash/tidb可以支持一种更高级的分区功能）

2.加强算子下推

案例：length、ADDDATE算子未下推至tiflash

需求：

  • 案例中的 length, ADDDATE 等算子的下推，特别是和时间处理相关的函数下推，因为分析业务中时间是常用的过滤条件
  • 下推能力至少能和tikv持平，即当前tikv能支持的下推，tiflash都需要支持一下，否则tikv就会比tiflash算得快，tiflash就没有使用的理由
  • 我们某些特殊的业务，里面用到的json类型，相关的json算子也需要支持下推一下，比如json_length, json_extract…，不限于这些。

3.ddl同步至tiflash

案例: enum类型添加枚举值未同步到tiflash

一个是schema层面上忽略了这个enum的变化，第二个是存储层也不支持这个enum的变化

需求：

  • DDL要同步到tiflash

4.insert/update/delete/replace select不会走tiflash

案例：replace into select 语句无法走tiflash

需求：

  • insert into xxx select from xxx 是很常见的sql业务，这是利用数据库本身的能力做一些简单的类似于物化视图的行为，一个sql同时存在读写，tiflash需要支持这种场景

5.Tiup没对网络打通这一块感觉考虑不足，一般存储服务都在内网，一些功能涉及到内外网或者管理网不通就无法使用了

6.TiUP的设计希望能更贴合一般公司的架构，更方便的接入公司系统。

期望产品新增功能

1.TiDB: 提供智能的表结构优化功能
背景:

  • 一些平台化的服务，在后端建表仅会建字段和属性，并不会考虑加索引、sql优化等事情
  • 业务侧开发人员水平不齐，会造成一些表未加索引或者索引不够优
  1. TiUP搞个Console?

社区组织的活动体验

希望能增加一些偏db开发的分享会

对于目前的社区服务体验

很赞

对于目前 TiDB 社区项目的吐槽

1.建议TUG答疑帖与技术文章分开

对于目前 TiDB 社区运营人员的吐槽

无

其他需求和建议

1.是否可以考虑对给开源组件首次提pr的同学安排个mentor

15 个赞
#12

给线上资料的一些建议：有一种感觉，资料十分多，但找不到主线

5 个赞
#13

期待小表场景的优化。如果Index 和 Data 在不同的 TiKV 上面，就多了一次额外的网络开销

#14
  1. alter 对多个表操作可合并
  2. 增强AP方面的能力
  3. 完善资源隔离性(比如控制SQL占用内存 多少 cpu多少 避免一个SQL 引发集群抖动 )
  4. 添加read_only 范围影响 全局 或者单个tidb server。如果只开单个tidb server read_only 则所有读请求转发到tikv非leard节点，该节点可以给业务做 非实时数据分析,以及elt抽数。
#15
  1. 字段只可以扩容，字段不可以缩容吧
#16

5.安全漏扫 绿盟等软件 扫描tidb时会报成MySQL版本，可以把MySQL版本号调高。或者跟安全厂商沟通，引入tidb漏扫机制。
6.可修改 添加删除自增主键列，使用自增主键也可以使用shard_row_id_bits(主键改为逻辑主键，实际存储还是使用row_id方式 作为物理主键)
7.tidb自带监控项目太多。tidb多套集群监控、报警系统整合一套，避免重复搭建 。

#17

Hi，感谢提出这些中肯的回馈，先回答一下部分与 DDL 限制相关的问题：

  • alter 还是只能指定一个操作，不能一个SQL操作加多个索引
    这一点在 TiDB 中被我们称为 “multi schema change”，目前这部分工作正在进行中(https://github.com/pingcap/tidb/issues/14766)，例如 master 分支上，TiDB 已经允许在一条 alter 语句中添加/删除多列。
  • 主键不能操作，最近的问题：自增主键，业务自己指定主键写入，导致写写冲突，主键值变的很大
    这部分工作还没有开展，但是在中长期的 Roadmap 里：https://github.com/pingcap/tidb/issues/18090

总而言之，我们在持续地对 TiDB 的 DDL 能力进行改进，但考虑到元数据操作的重要性和影响，一些已经开发的功能还没有在正式的发布版本中支持，这一点还请理解并期待后续的 TiDB 版本。

#18

慢日志的谜团

希望知道具体 SQL 慢在什么地方…

  • 有些时候看到"整体慢其他地方都很快"…
  • 有的时候看可以看出"某个部分慢"却不知道细分下去什么地方慢(比如 backoff total 慢具体什么 backoff 慢?)
  • Backoff 这个指标非常诡异, cop 部分有个字段, 2pc 部分又有个字段…都自己叫 backoff 如果同时写入+读取(比如 cop + update) 读写都 backoff 日志比较迷惑…希望完善下 Backoff 日志, 能逻辑清晰的知道什么在读写的哪个阶段遇到 Backoff
  • 但目前的"不完善"的慢日志已经被其他用户的日志解析工具使用, 不过如果改格式应该会被其他用户质疑日志格式为什么老变 (逃~
#19

感谢反馈和建议！

对于这一点，我有不同的想法：

tidb几次心跳内无法加载最新的schema就导致tidb服务不可用。

建议整个选项，或者优化这个机制，如果没有ddl的job，就不需要同步schema了。

在这种情况下，我个人会更担心 “这个 TiDB-server 为什么不能加载 schema”，很可能是 TiDB 与 PD/TiKV 之间的通信出现了问题，在这种情况下，即便我们不同步 Schema，TiDB 很可能也无法正常工作。

想象一下，这时候 TiDB 很可能无法确认 “是否真的没有 DDL Job”，相应地，也不敢跳过 “是否需要同步 Schema” 的检查。

2 个赞
#20

比如说tikv很忙，确实没忙过来，导致tidb加载schema失败。tidb就完全拒绝服务了。这个不科学，一个tikv很忙，其他tikv可以继续提供部分服务，不至于某个tidb上所有请求全部block吧。这是我们集群确实遇到的问题，一个tikv很忙，发生了oom，导致整个tidb服务不可用，这符合tidb的设计理念吗？

至于怎么动态决定是否需要load schema，这个可以再考虑。或者干脆就一个选项，我的集群就关掉了online ddl的支持，我需要的改表结构的时候打开就行了。