一 说明
- canal本身是一个管道,binlog通过管道进入,然后处理,再从管道出去,binlog是在canal端进行过滤的.所以对于单实例多库来说是推送全部binlog的
- 整个canal的解析流程大致分成4步。binlog dump -- parse -- sink -- kafka(rocketmq)
- 我们可以把canal理解成拥有过滤规则的从库,不过要将处理过的日志打入kafka而已
- kafka是canal的主要接收者
二 具体流程说明-三个核心指标
- Put: Canal Server从MySQL拉取到数据后，放到内存中，Put增加
- Get: 消费者（Canal Client）从内存中消费数据，Get增加
- Ack: 消费者消费完成，Ack增加。并且会删除Put中已经被Ack的数据
三 延时问题监控
canal_instance_traffic_delay{destination="example"} / 1000 Server与MySQL master之间的延时。canal_instance_put_delay{destination="example"} / 1000 Store put操作时间点的延时。canal_instance_get_delay{destination="example"} / 1000 Client get操作时间点的延时。canal_instance_ack_delay{destination="example"} / 1000 Client ack操作时间点的延时。
四 延时问题思考
- 源端短时间内产生大量binlog,canal需要进行过滤处理,导致负载升高,同时消费端消费能力也不能及时消费,导致延时-主要原因-上游
- 对于接收端是kafka的,canal解析完就会源源不断的打入kafak中,如果kafka产生消息积压,canal也会导致延时-下游