【TUG 话题探讨 005】TiDB 生态工具(DM、TiCDC等)使用场景及常见问题

10 月 28 日晚上 8 点,第五期技术话题探讨会在 TUG 群里如期而至,本次探讨会主要围绕“TiDB 生态工具(DM,TiCDC等)使用场景及常见问题” ,以下为讨论节选,其中有一些对 TiDB 的吐槽,我们也邀请了 PingCAP 的产研同学帮忙做了回应。

想和 TUG 专家深入沟通,你也可以申请加入 TUG 群参与每期技术话题沟通

监控工具

何傲(神州数码):
有没有考虑在Dashboard中集成一下DM和TiCDC的可视化管理?

王贤净(PingCAP):
暂时还没考虑集成 DM 和 TiCDC,有详细使用需求可以在 Asktug 提交产品需求贴。

田朋(同程旅游):
我感觉 我之前用的数据同步工具挺好用的

田朋(同程旅游):
之前用dm 判断主从 dm tidb的延迟不太好判断

田朋(同程旅游):
之前用的是1.0 在就没用

王贤净(PingCAP):
在改了在改了,可以期待一下 DM 2.1 ~ 延迟监控增加了一些更细节的监控项,预计十一月中下旬发版,感兴趣可以关注 release node

江坤(神州数码):
Dashboard 里面能增加一个参数视图嘛,最好能有默认参数和集群设置参数的对比?

王贤净(PingCAP):
默认参数和集群参数设置对比,这个有在考虑,TiUP 有一个小工具 clinic checker 已经在做了。Clinic 诊断工具套件是 Autopilot 组提供的一组 TiDB 集群诊断工具,包括数据采集以及问题诊断,感兴趣的话可以联系我们内部人员优先试用。

迁移工具

代晓磊(360):
我来抛个砖:应用场景1:TiDB 集群多机房互备(经常听人讲2地3中心);2:数仓团队凌晨ETL ;3:MySQL迁移tidb后,替换之前的canal/maxwell等同步工具。

王天宜:
cdc 工具考虑直接将数据同步到 hdfs 的方案吗?

代晓磊(360):
考虑的,做增量备份可以用到

王天宜:
目前 canal 是有对接 hdfs 的接口,cdc 现在还没有吧。TiDB 拥有优秀的 TP 能力,目前 TiFlash 还没有 PB 级别的存储能力,是否可以考虑 cdc 工具落盘到 hdfs。

赵一霖(PingCAP):
目前短期内不会考虑 cdc 工具落盘到 hdfs,有详细使用需求可以在 Asktug 提交产品需求贴。

DM(Data Migration)

代晓磊(360):
DM对MySQL分库分表的主键冲突解决不太友好,1000张表需要配置1000个匹配规则。另外就是DM同步的上下游不太好做数据校验。

田朋(同程旅游):
MySQL的主键+分片键=tidb,联合唯一索引

王贤净(PingCAP):
我记得早期 需要用 column mapping 比较复杂, DM 1.0 后续版本以及 2.0 的话主键冲突问题解决选择性会多一些,比如 联合唯一索引,或者 2.0 下游新增一个主键列 auto_random 都可行~

代晓磊(360):
DM1.0跟2.0的变化还是挺大,之前就有人反馈过,从1.0升级到2.0出现问题又回滚的。

王贤净(PingCAP):
确实,因为内部结构变化比较大, 所以运维起来和 1.0 差距有点多,大家可以看下 PE 的 TiDB 数据同步与复制相关课程了解下。

田朋(同程旅游):
如果 是mycat 或者shard的分库 分表 中间件 咋校对数据,就是 TiDB 和 MySQL的表结构不一样了 这时候校对数据挺麻烦的

王贤净(PingCAP):
这个 sync diff 也在重做呢,预计会添加实时校验功能,不仅是 DM 同步的数据,TiCDC/drainer 这些都可以~

闫颖颖(瑞幸):
TiDB 那个一致性校验工具也可以用于 MySQL 吧?

王贤净(PingCAP):
Sync-diff 当前版本可以校验 MySQL/TiDB 中两份数据是否一致

又回到监控

代晓磊(360):
Tidb推进自有TiDB cloud后希望能在tidb operator上还要继续更新迭代,因为不少公司使用私有云,对该“工具”还是比较依赖的。

田朋(同程旅游):
全量 可以增加一些监控 比如 总量多少 同步多少 还有多少没同步完。增量 能展示出 完成多少gtid 上游gtid的位置 手动调整gtid啥的

王贤净(PingCAP):
这个的话,目前是有一个监控,load unit 导入过程的进度百分比的,不过需求收到,看看能不能更细粒度的展示~

陈加持(哗啦啦):
增量可以计算差距多少 binlog 文件数。

田朋(同程旅游):
用dm比较少 我还是感觉 我们dbrep好用

代晓磊(360):
Tidb dashboard 希望能像之前东旭那篇可观测性的文章那样,把一些能够定位问题的核心指标加入其中(用好的话,可以费了grafana),以后grafana就只是排查更细节的问题时使用了。其实dashboard 中像热点可视化等这种功能点多一些就好了。

王贤净(PingCAP):
需求已接收,感谢晓磊老师建议,目前也在逐步完善 dashboard 的相关指标中。

备份工具

陈臣:
之前用mydumper备份tidb的时候,会有个select min (id),max(id) from t的操作,走的是全表扫描,即使id是自增主键,不知道这个修了嘛?

房晓乐(PingCAP):
这个早修复了,但不知道版本

王贤净(PingCAP):
dumpling 不香嘛!强烈推荐 dumpling ~

田朋(同程旅游):
dumping真的香,我用dumping搞过超大的库,单表备份出来 都1t 2t多,大概有99个表吧,用 Tidb Lightning 恢复的 有时候还会异常 在重新拉起就行。

王贤净(PingCAP):
tidb-lightning 配置不同后端 工作原理不太一样,不过都支持断点续传,重新拉起来就可以

王贤净(PingCAP):
各位老师觉得 lightning local 模式导入快么 ?未来会把 lightning 集合在 DM 里,全量阶段导入就快很多了

田朋(同程旅游):
嗯 MySQL 和tidb 表结构不一定一致,而且 多个MySQL 导进去 可以嘛 local 不是 不能有数据嘛

王贤净(PingCAP):
lightning local 模式支持并行导入啦,从并行角度理解可以是非空表,但是注意还不能增量导入

田朋(同程旅游):
表结构不一致也可以嘛

王贤净(PingCAP):
哪种场景呢?下游多列是可以的,传送一波官方文档 https://docs.pingcap.com/zh/tidb/dev/tidb-lightning-distributed-import#tidb-lightning-分布式并行导入

田朋(同程旅游):
MySQl 的备份 用light 恢复 恢复到tidb 用local模式,但tidb列比MySQL多

王贤净(PingCAP):
亲测可行,之前也有用户这样用过,下游 tidb 列比上游 mysql 多

王贤净(PingCAP):
还有各位老师 觉得 DM 同步延迟慢的问题,也在优化啦~~ 感兴趣的记得参加 360 企业行

王贤净(PingCAP):
话说大家觉得 生态工具类 troubleshooting 的文档 各位老师需要嘛 ,好像目前比较少

陈臣:
这个需要,确实有点少

往期技术探讨回顾

话题征集,参与奖励 100 分,采纳奖励 300 分

加入 TUG

如果你也对数据库、大数据感兴趣,想与业界大咖们一起交流最前沿的数据库与大数据知识,欢迎加入 TUG,和 TUG 一起成长!

扫码报名或者点击链接跳转报名

3赞

在DM配置数据源时有个疑问,如何做到 功能强的 worker 机器给规模大的 数据库,功能弱的 worker 给小的。能在最初配置的时候就定义,如果不配置 master 在自动分配。

2赞

DM 加载上游数据源时目前是随机 worker 绑定,在绑定后,可以手动的去 transfer 将配置更好的 DM-worker 机器绑定上游规模比较大的数据库。

1赞