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

[Billmay表妹 (表妹)]

7.5 版本中已经集成到 tidb-dashboard 中了，敬请期待
相关 issue https://github.com/tikv/tikv/issues/15927

[有猫万事足]

帅

[TiDB_C罗]

原因：虽然tidb提供了丰富的grafana dashboard，但是在一些常用的场景，往往需要看多个dashboard。
建议：建议对一些经典场景，把一些相关的指标集合到一个dashboard
案例：比如热点写，热点读，读写冲突

[随缘天空 (Ti D Ber Ivw R7o Pj)]

• 建议名称：希望增加一些可视化的管理界面，减少运维成本或者降低维护风险，比如支持组件或者节点服务相关配置的在线修改
• 原因：对于已经启动投入到生产使用的集群，需要修改相关配置或者性能分析调优时，如果通过命令行操作，操作不慎或者对相关变量不熟，容易影响业务使用或者造成集群的不可用
• 案例：集群部署后，修改相关配置；性能分析后，想要修改相关参数测试性能
• Asktug 链接：V7.1.0 tidb 安装部署时拓扑文件如何最优化
  集群监控分析

[人如其名]

可观测行，在数据库内核层面提供的数据还是太少了，且感觉较为混乱。

1. 表的统计信息有的存在于mysql视图下，有的在information视图下，看似较多地方查询实则缺少较为实用直观的视图：比如
   1）、我想查某张表最近一次统计信息更新时间，如果这张表很久没有更新，那么就很难查询到，如果在syscat.tables中存在一列说明统计信息最后一次更新时间，那么还是很有帮助的。
   2）、太多的show stats但缺少直方图的视图查询（默认mysql库下的太不直观），比如快速的查询一个字段的分布频率（用于评估等值条件）和分位数（用于评估范围条件）情况，在视图中可以进行关联等操作。

2. 对于TiDB来讲，多一个索引维护代价就增加较多，因此对索引的监控很重要，在TiDB中缺少自重启以来（或者统计信息搜集以来）索引和表的使用情况，包括：时间周期内某索引的IndexOnlyScan次数，IndexScan次数，IndexFullScan次数，全表扫描次数（或全分区扫描）等等，这样可以让DBA和开发人员根据索引使用情况来进行评估是否删减。

3. 数据库提供的监控数据层次不太清晰，比如应分为数据库层、连接层、事务层、语句层。对于每一层还有很多指标需要更细力度的设计，可以参考DB2或者Oracle（个人认为DB2设计的更简单易用清晰明了）做下加强。目前对于连接泄露，事务执行情况（是否包含多个增删改，修改过多少记录），语句的指标（rows_read,rows_select,用了多少数据读，索引读，CPU，IO等）都还较为粗糙，希望能进一步加强，最好整体设计参考DB2、Oracle做一个TiDB自己专有的视图库。

4. 后台作业应统一视图来进行查询当前进度和近期历史，将统计信息、备份、DDL统一起来，且都可以利用kill进行杀掉。

[人如其名]

对于TiCDC：
1、希望上下游都是tidb集群时，ticdc摆脱对GC的依赖（大集群长时间holdGC）。可以利用BR backup全量恢复，ticdc读取BRlog来追增量，最终再拉去tikv log。
2、希望摆脱对上游集群的依赖，目前上游集群挂掉，ticdc无法工作，希望在上游集群挂掉后还是能完成已经传到ticdc中日志的同步到下游。
3、ticdc redo，当上游出现灾难性故障时，下游的最终一致性可能遭到破坏，为了保证下游同步到一致性点引入了redo的概念，但是6.5后ticdc推荐部署在上游，ticdc redo推荐写在下游（避免上游整体机房出问题），如果下游需跨中心访问，那么还要开通到下游的磁盘共享权限，这块可能有一些企业要求严格，不允许跨中心访问共享NAS，能否提供下游redo的接受日志的客户端工具呢，这样中间还可能能压缩传输减少消耗。
4、尽早完成权限体系设计，权限独立和配置免密等。

[人如其名]

tidb-server <--------------------------> tikv-server 宝贵的网络资源：
1、对于update、delete操作，tidb还是需要把整行记录拿到tidb-server中，我想这主要因为1、需要维护tidb-binlog，需要将整行记录传给下游；2、有较多涉及到的索引字段须读到tidb-server中加工处理后回填维护索引。但是这大量的数据搬动可能消耗大量的网络资源（网络带宽、GRPC通道拥挤）。因此是否能下的功夫优化这个无法绕过的问题。后面不推荐tidb-binlog（ticdc代替下游供数、brlog代替增量恢复），那么更应该着手优化这块，可以设置成开关对于关闭tidb-binlog的对于update和delete不应读取所有数据到tidb-server，只读取需要修改的或者需要删除的rowid字段（包括索引字段）。
2、优化decimal等数据类型带来的放大问题，减少网络资源使用。
3、适当控制全表扫描并发度（存在无法下推函数，前端用游标读取等方式，可能读取大量数据到tidb-server又积压在tidb-server上），减少网络资源使用，也避免在tidb-server侧堆积数据占用大量tidb-server内存。
4、优化tidb-server 的clientGRPC和tikv-server的serverGRPC，增加资源隔离、队列优先级等策略保障小事务，点查，简单索引查的优先级，让全表查、大量回表查、大量数据写入等优先级排低（这块可能对优化器的评估是个巨大的考验）。

最多允许连续发3贴，下面这个不相干但只能放在这里：
sync_diff_inspector是一个非常强大的数据比对工具，考虑了很多方面，且非常实用，完全比自己写对比脚本要好用很多，在功能、配置、效率、结果展现等方面都有点出乎我预期，但是在分析该工具时发现还是会存在一些可能会导致集群抖动的问题，在实际测试使用时也是验证了这一点。见帖子：sync_diff_inspector做上下游数据对比时可能会导致集群性能抖动 。

[TiDBer_yyy]

• 建议名称：提升集群稳定性，向前兼容。
• 原因：TiDB升级7.1之后，很多业务出现SQL不兼容问题
• 案例：tidb-5.0.4升级到tidb7.1.0 sql 不兼容反馈，踩坑血泪史【欢迎大家补充】
• Asktug 链接：tidb-5.0.4升级到tidb7.1.0 sql 不兼容反馈，踩坑血泪史【欢迎大家补充】

[xingzhenxiang]

1、稳定，大版本发的有点快，多打磨一个稳定的版本
2、性能，oltp使用需要更快的相应速度

[ShawnYan]

@xingzhenxiang

大版本

可以直接关注LTS版本，今年至今只发了7.1 LTS，7.5还在路上。

[Jellybean (李文杰)]

+1
TiCDC对上游的影响，尤其是与PD的耦合程度如果能够大大降低，甚至是解耦独立出来，就可以比较好地保护原集群不受TiCDC的故障影响。曾经我们没什么经验用了低版本的CDC，然后同步状态信息存储在etcd踩到坑导致整个PD集群不可用，全部业务受到了影响，深有感触。

[Billmay表妹 (表妹)]

@heiwandou

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

建议结论：

tiproxy 的支持做了，预计下周可以上线，但是不支持 haproxy，目前暂时不考虑支持~

[Billmay表妹 (表妹)]

@Kongdom

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

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

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

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

来自文档团队的回复：

感谢建议，对于跨版本升级的用户，废弃或删除的变量的确不太方便在一个页面查看。

除了直接汇总废弃和删除信息，我们也在评估另一种方案：对于删除和废弃的变量，保留文档中的变量标题和描述，并直接标记它开始废弃或删除的版本信息。

例如对于 v7.5 系统变量文档：

tidb_enable_tiflash_pipeline_model 从 v7.2.0 版本开始引入

• 已删除：从 v7.4.0 开始，开启 TiFlash 资源管控功能时，Pipeline Model 模型将自动启用，因此，删除了该变量。

• 作用域：SESSION | GLOBAL

• 是否持久化到集群：是

• 类型：布尔型

• 默认值：OFF

• 这个变量用来控制是否启用 TiFlash 新的执行模型 Pipeline Model。

[Billmay表妹 (表妹)]

@有猫万事足

• 建议名称： 建议将tikv的heap分析集成进dashboard
• 原因：tikv的heap分析藏的很深，有点难找
• 案例：
  tikv火焰图从哪里调出来的？
• Asktug 链接：
  建议将tikv的heap分析集成进dashboard

相关的团队负责人回复：

7.5 版本中已经集成到 tidb-dashboard 中了，敬请期待
相关 issue Improve TiKV OOM diagnosis routine · Issue #15927 · tikv/tikv · GitHub

[nongfushanquan]

谢谢反馈，针对你反馈的这些问题（TiCDC），目前我们有一些改进的计划了，不过需要一些时间。

[ealam_小羽]

• 建议名称：文档或视频增加一些监控面板的常见使用案例及参数说明、指标正常区间
• 原因：经常会有小伙伴问某个参数的是否有问题或如何计算？且排查问题时，监控指标的文档部分有点不是特别清晰，之前根据读性能排查的帖子排查起来有时候也有点似是而非的感觉。
• 案例：
• Asktug 链接：
  grafana面板中慢查询时间疑问
  写入热点问题确认
  全表扫描的慢查询是否会影响其他请求

[望海崖2084]

我在写 SQL 遇到如下，会遇到报错。

WITH A (
SELECT ID FROM TABLE_A WHERE ...
)

SELECT ...
FROM TABLE_A
LEFT JOIN TABLE_B
ON A.ID = B.ID 
AND TABLE_B.ID IN A
GROUP BY ...

需求场景是这样，TABLE_A 是维度表，TABLE_B 是明细表， AND TABLE_B.ID2 IN A 是为了减少全表关联。

[裤衩儿飞上天]

建议：升级出现故障可以回退

原因：升级出现故障，由于时间窗口，回退功能是非常必要的

案例： TiDB升级后回退 - TiDB 技术问题 - TiDB 的问答社区 (asktug.com)

[普罗米修斯]

建议名称：优化drainer增量同步时内存使用问题
原因：增量同步时使用内存过高
案例：之前生产环境不支持cdc，使用binlog同步时drainer占用了200多G的内存，当时将服务器内存＋到近300G，启用drainer时间也很长，ansible start已经报error，当时排查一头雾水
Asktug 链接：drainer进程在，端口无法启动

[Billmay表妹 (表妹)]

@望海崖2084

我在写 SQL 遇到如下，会遇到报错。

WITH A (
SELECT ID FROM TABLE_A WHERE ...
)

SELECT ...
FROM TABLE_A
LEFT JOIN TABLE_B
ON A.ID = B.ID 
AND TABLE_B.ID IN A
GROUP BY ...

需求场景是这样，TABLE_A 是维度表，TABLE_B 是明细表， AND TABLE_B.ID2 IN A 是为了减少全表关联。

要求：

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

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

可以按照以下模板输出：

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