关于tidb binlog使用中pump和drainer使用方式的问题

在安装部署使用的时候,遇到一些问题,有些是发现一些使用中不方便或者模棱两可的地方,有些是需要了解原理以便更放心的使用,在官网介绍中没有找到明确答案,微信沟通中按照技术支持的建议把问题整理到这里:

1.多个pump分布式集群对于binlog是否是负载均衡模式的处理,是否是一个表的binlog日志会分散给不同的pump节点处理,是的话,drainer消费使用时是否能保证操作有序?

2.drainer对于pump的消费,似乎没有任何过滤机制,每个drainer都同步binlog所有信息到下游?如果是如此,那么有个问题,单个的下游kafka或者mysql不一定扛得住压力。现在或者后续是否有规划,可以指定drainer同步用户需要的部分数据到下游。

3.drainer应该都是独立工作吧且不存在负载均衡的设计吧,如果要往一个下游目标同步数据,只能起一个drainer?目前drainer数量再多,每个drainer也都是消费binlog里的完整数据,不会互相干扰吧?往多个kafka和mysql同步数据,每个kafka和mysql都要配置启动对应的drainer,只要起不同别名就行了,别名应该不需要必须是"dainer_mysql"这样的形式吧?

以下是几个我觉得需要优化的实践细节:

1.drainer默认端口是8249,pump默认端口8250,这两个没有拉开距离,如果一个节点上部署多个实例,一般习惯是在默认端口上直接递增,但这俩组件就会冲突。tidb生态组件很多,默认端口也很多,设计时应该减少用户出错的机会

2.drainer很容易启动不成功或者运行时遇错停止,这个思路我觉得需要改进。如果是drainer自身的配置出错要修复也得重启drainer,那么drainer自己停掉也无所谓。但很多是上下游环境问题,比如下游mysql或者kafka连接有问题或者权限有问题,我修改下游就行了。这样如果上下游有问题,可能导致drainer(或者tidb其他组件,我担心也有这种思路)也挂掉,那么排除问的成本就要增加,而不是调整上下游后自动可用。

你好,你这边的三个问题我先解答下:

  1. 每个 TiDB 都有个 pump_client 模块,可以通过 range (默认) 或者 hash 的方式轮询发给 pump server (binlog strategy config in TiDB) 所以 binlog 是会分散给不同的 pump 节点处理的,drainer 会向所有的 pump server pull binlog 过来,然后由 drainer 根据 commit_ts 对 binlog 进行排序,以此来保证 binlog 的有序。
  2. drainer 目前的配置上是可以对库表进行一些过滤的,replicate-do-dbsyncer.replicate-do-table 可以指定同步库表的白名单,syncer.ignore-tableignore-schemas 可以指定同步库表的黑名单。
  3. 是的,现在 drainer 都是独立工作的,并且一个 drainer 只能针对一个下游,不具备负载均衡和横向扩展的能力。别名不需要指定下游同步端的嗯,不过 drainer 的 db-type 配置需要指定是 kafka 还是 mysql。

我们 binlog 这块的文档后续会做下加强,确实有些信息没有提到。另外针对一些原理性的介绍,可以参考 TiDB-Binlog 架构演进与实现原理TiDB Binlog 源码阅读

1赞

端口那个建议挺实际的,我们这边看看能不能在后面版本里做下调整。 第二个建议抱歉有点没理解,能否再帮忙讲一下希望 drainer 异常处理做成什么样的效果?希望解决问题的是什么?