binlog主备延迟

🪐 TiDB 技术问题 性能调优
21

多个drainer并⾏增量必须指定⽬的端checkpoint.schema为不同库drainer配置说明

> ＃从备份⽂件中获取全量备份开始时的位点TSO
> grep "BackupTS=" /data/dbatemp/0110_backupdfp.log 
> 430388153465177629 
> #第⼀次⼀个drainer进⾏增量同步关键配置
> drainer_servers: 
> - host: xxxxxx 
> commit_ts: 430388153465177629 
> deploy_dir: "/data/tidb-deploy/drainer-8249" 
> config: 
> syncer.db-type: "tidb" 
> syncer.to.host: "xxxdmall.db.com" 
> syncer.worker-count: 550 1516
> 
> 
> #第⼆次多个drainer进⾏并⾏增量同步
> drainer_servers: 
> - host: xxxxxx 
> commit_ts: 430505424238936397 #该位点TSO为从第⼀次1个drainer增量停⽌后⽬的端ch eckpoint表中的Commit_Ts
> config: 
> syncer.replicate-do-db: [db1,db2,....] 
> syncer.db-type: "tidb" 
> syncer.to.host: "xxxdmall.db.com" 
> syncer.worker-count: 550 
> syncer.to.checkpoint.schema: "tidb_binlog2"
2 个赞
22

binlog还要搞个集群收集各个tidb节点的日志太麻烦了，成本也高

23

好的 我去测试环境试试，这样数据就不会重复吗

24

在目前没有办法改变架构的情况下，也只能去做优化了。 升级的是后面一个中长期计划。

25

我看文档写的
扩容前确认下游checkpoint信息不存在或已清理
如果下游之前接过drainer，相关位点在⽬标端tidb_binlog.checkpoint表中，重做的时候需要清理
谨慎操作
commit_ts: 430505424238936397 #该位点TSO为从第⼀次1个drainer增量停⽌后⽬的端checkpoint表中的Commit_Ts

26

好，先找个测试环境试试

27

drainer是单独部署的吗 在资源允许的情况下适当调整下参数配置

28

已经调整了txn-batch和worker-count

29

延迟高，一般受网络和IO影响较大

30

网络没啥压力，io还好，就是想修改某些参数，把资源利用起来。

31

ticdc和binlog哪个延时低

1 个赞
32

我也想问问这个。 :joy:

33

下游是 TiDB 吗？可以先看看下游的写 sql latency 是否也这么大，排除网络延迟。
然后可以监控中 “queue_size” 是不是基本为 0 判断是不是写下游存在积压的情况。
最后如果下游还可以抗压，业务也允许的话可以多起几个 drainer，把单个 drainer 同步的表打散拆分到多个 drainer 做同步。
当然最佳还是升级到 TiCDC 做迁移，不会像 Binlog 这样有一个 drainer 是单点。

1 个赞
34

我也去试试

35

有大事务吧

36

sql latency 正常 200ms左右，queue_size 也是7 - 10左右 drainer拆成多个的方案试了 测试环境发现延迟更大了。单节点还没有延迟。

37

都有延迟，200ms不算很高呀

38

queue_size 还没到 0 那说明下游消费还有瓶颈，可以试着优化下网络和下游数据库的写性能
drainer 和下游数据库在一个网络环境吗

39

这两个工具本来就不是实时同步的，但凡大事务就会延迟，性能波动也会延迟