【已结束】“我的 TiDB 听我的”第二季来袭——TiDB 5.0 需求全面征集

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

image

我这边需求是想要备份中包含如图中这些syncer_checkpoint中的mysql binlog信息，这样如果某一个schema DM同步出现丢数据或者其它异常导致tidb无法使用，可以恢复备份，然后从syncer_checkpoint中的位点开启同步。在br工具中不知是否可以实现？

66

Hi，感谢建议。目前 Coprocessor 算子其实非常 TiDB Specific，还包括 TiDB 特有的 Key 格式解码等等。如果是为了让 TiKV 上层非 TiDB 应用工作效率更高的话，实现 Coprocessor 插件机制是否能更好地满足需求？

67

Hi, 3.0 版本起的 TiDB, PD, TiKV 组件均遵循统一的日志格式（具体格式 spec 在这里），这个日志格式有遇到什么问题吗？

68

Hi，从慢日志设计来说 pt-query-digest 是支持分析 TiDB 慢日志的（文档），这个是否已经能满足需求了呢

69

个人感觉插件机制是作为一个补充手段，bson和pb格式作为一个非常通用的二进制序列化格式，我认为作为内置支持是有必要的。这在未来也可以拓展出更多的功能。例如用于优化tidb的json函数支持。当然，插件机制也是完全可以满足实现非关系型数据库的需求的，只是在部署上会比内置支持稍显不便。

70

这两个格式指的是 TiKV Coprocessor 对外回传的数据格式，还是 TiKV 解析 Row Value 时候希望的 Row Value 的格式呢？如果指是 Row Value 的话，Row Key 是否满足 TiDB 行编码方案 tXXXXXXXX_rXXXXXXXXYYYYYYYY 的格式呢？如果 Key 格式不满足的话，仅仅 Row Value 支持 bson / pb 解码是不足以支撑 TiKV 上非 TiDB 应用的下推计算需求的。

具体 Coprocessor 的处理逻辑解析可以参见源码阅读文章：

关于 Coprocessor 支持的 Value 格式（的其中最新的一种）：

关于 Coprocessor 支持的 Key 格式：

72

1.TiKV支持多磁盘

现在TiKV不支持直接使用多块磁盘，容易造成磁盘浪费

2.TiKV使用更多的CPU

3.TiDB完全兼容MySQL DDL

现在TiDB不完全兼容MySQL DDL，导致Syncer同步MySQL数据经常报错

4.TiDB支持UDF UDAF UDTF

提高TiDB易用性

5.TiDB OOM发出报警

TiDB更多关键信息支持报警
73

指的是解析Row Value的格式。Row Key不能完全满足TiDB的编码格式，非关系数据库的数据组织结构与TiDB并不相似。 如果这样的话，插件Coprocessor能否处理任意格式的Row Key的下推计算呢？另外下推计算中如果使用到Index的情况下，现在的Coprocessor应该也无法处理非TiDB格式吧?

74

Exactly，从这个描述来看我觉得还是需要插件来解决，写插件注册为一个服务，自行按照某个逻辑扫表、执行某个计算并决定返回什么数据。现在的 Coprocessor 协处理与 TiDB 深度绑定，协处理其他任务不大够。

75

这样的话可以与现有的默认Coprocessor并存，对TiDB那边影响比较小。不过这样的话插件系统的设计也将会是一个复杂的工作。但是我希望能够有这个功能，这能极大的拓展TiKV的适用范围，可以作为更多的需要分布式事务存储系统的后端。

76
  • 功能/改进说明 ：大表增加索引时，提供高峰时间暂停功能
  • 为什么需要这个功能/改进 ：使用TiDB之后不再需要分库分表，那么就会出现单表数据量极大，此时在线增加索引的操作会持续较长时间，容易跨越多个业务高峰时间，而业务高峰时间还在添加索引的话，会造成业务写入延迟上升，业务感知明显，通过添加索引暂停的功能可以缓解该问题
  • 其他数据库对应功能 ：pt-osc/gh-ost 工具给MySQL变更表结构时可以暂停变更操作
77
  • 功能/改进说明 ：支持 DDL 停机有损变更
  • 为什么需要这个功能/改进 ：我们并非任何时候都需要 Online DDL，在容忍锁表和数据截断的前提下，应允许 DDL 有损变更。例如，大量 Python 项目使用 Alembic 进行基于版本化 DDL 的 Migration，会在集群迁移时，重放所有执行过的 DDL。一旦 DDL 中存在有损变更，则无法通过原生手段迁移表结构，需要做许多 hack 工作。
  • 其他数据库对应功能 ：MySQL alter 语句支持变更字段类型 float to int
1 个赞
78
  1. 功能/改进说明 ：除tikv_gc_life_time控制最久保存时间外，增加safe point 内多个版本只保留最近一个的支持
  2. 为什么需要这个功能/改进 ：我们的使用场景是在用户的点击点赞等等行为序列的记录上:比如每点击一次就触发replace into操作，更新点击序列，相应保存更新前的数据，加一个时间戳作为版本号；
    现在遇到的问题就是如果有的用户一分钟内点击了十多次，或者一天累积点击上千次(先tikv_gc_life_time设置为24小时)，相应就会产生很多时间比较近的时间戳版本；通过safe point 只保留最近一个版本(时间戳)的支持以加速rockdb的seek操作；对应维度变化比较慢的(比如1天才被update一次)，仍然使用tikv_gc_life_time控制最久保存时间；
  3. 其他数据库对应功能 ：类似hbase的timestamp功能
79

在 4.0 还是有看到不少日志命名不统一的，举个例子，region id 在 pd.log 里写的是：[region-id=xxxx]，在 tikv 里则是 [region_id=xxxx]

在程序员的世界里，中划线 - 在特定场景下可能会有特定的意义，建议全部统一成下划线 [region_id=xxxx]

1 个赞
80

所有的命令行增加auto complete，加强易用性

81

br备份恢复工具。支持恢复时修改表名或者库名。