Canal Format

    Canal is a CDC (Changelog Data Capture) tool that can stream changes in real-time from MySQL into other systems. Canal provides a unified format schema for changelog and supports to serialize messages using JSON and (protobuf is the default format for Canal).

    Flink supports to interpret Canal JSON messages as INSERT/UPDATE/DELETE messages into Flink SQL system. This is useful in many cases to leverage this feature, such as

    • synchronizing incremental data from databases to other systems
    • auditing logs
    • temporal join changing history of a database table and so on.

    Flink also supports to encode the INSERT/UPDATE/DELETE messages in Flink SQL as Canal JSON messages, and emit to storage like Kafka. However, currently Flink can’t combine UPDATE_BEFORE and UPDATE_AFTER into a single UPDATE message. Therefore, Flink encodes UPDATE_BEFORE and UPDATE_AFTER as DELETE and INSERT Canal messages.

    Note: Support for interpreting Canal protobuf messages is on the roadmap.

    Note: please refer to Canal documentation about how to deploy Canal to synchronize changelog to message queues.

    How to use Canal format

    Canal provides a unified format for changelog, here is a simple example for an update operation captured from a MySQL table:

    Note: please refer to Canal documentation about the meaning of each fields.

    The MySQL products table has 4 columns (id, name, description and weight). The above JSON message is an update change event on the products table where the weight value of the row with id = 111 is changed from 5.18 to 5.15. Assuming the messages have been synchronized to Kafka topic products_binlog, then we can use the following DDL to consume this topic and interpret the change events.

    The following format metadata can be exposed as read-only (VIRTUAL) columns in a table definition.

    The following example shows how to access Canal metadata fields in Kafka:

    Format Options

    Under normal operating scenarios, the Canal application delivers every change event exactly-once. Flink works pretty well when consuming Canal produced events in this situation. However, Canal application works in at-least-once delivery if any failover happens. That means, in the abnormal situations, Canal may deliver duplicate change events to message queues and Flink will get the duplicate events. This may cause Flink query to get wrong results or unexpected exceptions. Thus, it is recommended to set job configuration table.exec.source.cdc-events-duplicate to true and define PRIMARY KEY on the source in this situation. Framework will generate an additional stateful operator, and use the primary key to deduplicate the change events and produce a normalized changelog stream.

    Data Type Mapping