当有网络延迟时，ticdc 建议在部署在下游，这是什么原理 ？

🪐 TiDB 技术问题
1

image
image1818×402 78.5 KB

请问下各位老师，当有网络延迟时，ticdc 建议在部署在下游，这是什么原理 ？

2

你可以这么看，如果异地tidb集群用ticdc同步数据，部署在源端，就是低延时select，高延时update，部署在目标端，就是高延时select，低延时update，当然也不是真的select，就是读取源端变化数据，update就是变更目标端数据。

3

我理解ticdc抓变更是批量的，向下游执行sql是一条一条的。如果延迟高，部署在下游，从上游到下游批量的一个事务，慢点就慢点了，就慢一次。执行sql时快。
如果部署在上游，抓变更快，但是执行sql因为事务解析成了很多条sql，一条一条执行，来回交互，延迟就增加了好多。
拍脑袋想的，也没了解过ticdc的源码

4

只是上下游延迟比较大的时候才有必要，部署在下游因减少了TiCDC与被同步系统之间的网络延迟，使得被同步系统执行更快。

5

我觉得是这么理解的，如果部署在下游的话，ticdc 只需要读取上游的日志变化，就只需要传输日志，ticdc 在把这些日志转为数据，不需要传输数据
如果ticdc 部署在上游，那么就要往下游传输数据，这样占用网络带宽会多一点，所以ticdc 部署在下游的话，能够节省网络带宽加上有网络延迟的话，就更建议部署在下游了

1 个赞
6
  1. up stream execute SQL → 2. TiCDC (grpc) fetch change event from TiKV → 3. TiCDC (mysql client) write SQL to down stream → down stream execute SQL
    1. 可以认为自带 batch，受游网络延迟影响小一些
    1. 是普通 mysql client 和下游的 TCP 交互，比如在上游开一个 mysql 命令行连到下游执行 SQL，每敲一条 SQL 都会经过完整的网络，大事务受网络延迟影响与事务大小成正比
7
  1. 可以认为自带 batch，受游网络延迟影响小一些
    请问下老师，这句话怎么理解呢
8

我也不熟 TiCDC，我个人这么理解，上游 TiDB → TiCDC 传的是 TiKV change event，这个方式类似 mysql binlog event，并且这个阶段不需要考虑并发的顺序，随后在 TiCDC 解析 event 转换成 mysql SQL / kafka event 并（以表为单位）按顺序写下游，TiCDC → 下游传的是 逻辑 SQL（这一点在下游开 general log 即可观察到）

9

我理解大概是这样：ticdc上游抓一个事务的变更，假设这个事务有个几兆，那就是一次把几兆发送到下游了，到下游以后，这个几兆的事务解析成了千八百条sql，一条一条执行。如果反过来，千八百条sql从上游一个个的发送过来，来回ack也慢。

1 个赞
10

对的，我的理解和你的是一样的，主要是减少网络带宽的延迟

11

感觉这样适合对延迟不敏感的情况

12

嗯，网络有延迟，只能尽可能降低延迟了。