Skip to main content
The MySQL source connector pulls messages from MySQL and persists the messages to Pulsar topics by using debezium.
This connector is available as a built-in connector on StreamNative Cloud.

Quick start

Prerequisites

The prerequisites for connecting a Debezium MySQL source connector to external systems include:
  1. Create a MySQL service: This connector uses the debezium v3.2, Please refer to this document to see the compatible MySQL versions.
  2. Prepare MySQL Database: Please refer to this document to complete the prepare steps on MySQL.
  3. Configure topic retention policies: Before running the connector, you must ensure that you have set an infinite retention policy for both the offset.storage.topic and schema.history.internal.pulsar.topic. Refer to the Used Topic On Pulsar section for more details.
If you are using AWS MySQL service, you need to use the params group to set the binlog_format to ROW.

1. Create a table on MySQL

Run the following SQL command on your MySQL.

2. Create a connector

The following command shows how to use pulsarctl to create a builtin connector. If you want to create a non-builtin connector, you need to replace --source-type debezium-mysql with --archive /path/to/pulsar-io-debezium-mysql.nar. You can find the button to download the nar package at the beginning of the document.
If you are a StreamNative Cloud user, you need set up your environment first.
  1. The --parallelism must be set to 1. Debezium connectors do not support parallel consumption within a single instance. If you need to process tables in parallel, you can deploy multiple connector instances, each configured for different database schemas or tables.
  2. You can set multiple tables for “table.include.list”, and the connector will send data from each table to a different topic of pulsar. The topic naming rule is: {{database.server.name}}.{{table.name}}. For examples: public/default/mydbserver.public.io-test.
The --source-config is the minimum necessary configuration for starting this connector, and it is a JSON string. You need to substitute the relevant parameters with your own. If you want to configure more parameters, see Configuration Properties for reference.
You can also choose to use a variety of other tools to create a connector:

3. Insert and update a data to table

You can insert and update using the sql:

4. Show data using Pulsar client

If your connector is created on StreamNative Cloud, you need to authenticate your clients. See Build applications using Pulsar clients for more information.

Configuration Properties

The configuration of Debezium source connector has the following properties. For more configuration properties, please see Debezium Mysql connector configuration properties

Advanced features

Converter options

  • org.apache.kafka.connect.json.JsonConverter Thejson-with-envelope config is valid only for the JsonConverter. By default, the value is set to false. When the json-with-envelope value is set to false, the consumer uses the schema Schema.KeyValue(Schema.AUTO_CONSUME(), Schema.AUTO_CONSUME(), KeyValueEncodingType.SEPARATED), and the message only consists of the payload. When the json-with-envelope value is set to true, the consumer uses the schema Schema.KeyValue(Schema.BYTES, Schema.BYTES), and the message consists of the schema and the payload.
  • org.apache.pulsar.kafka.shade.io.confluent.connect.avro.AvroConverter If you select the AvroConverter, the consumer uses the schema Schema.KeyValue(Schema.AUTO_CONSUME(), Schema.AUTO_CONSUME(), KeyValueEncodingType.SEPARATED), and the message consists of the payload.

Used topic on Pulsar

Currently, the destination topic (specified by the destination-topic-name option ) is a required configuration but it is not used for the Debezium connector to save data. The Debezium connector saves data on the following 4 types of topics:
  • One topic for storing the database metadata messages. It is named with the database server name ( database.server.name), like public/default/database.server.name.
  • One topic (offset.storage.topic) for storing the offset metadata messages. The connector saves the last successfully-committed offsets on this topic.
  • One topic (schema.history.internal.pulsar.topic) for storing the database history information. The connector writes and recovers DDL statements on this topic.
  • One per-table topic. You can set multiple tables for “table.include.list”, and the connector will send data from each table to a different topic of pulsar. The topic naming rule is: {{database.server.name}}.{{table.name}}. For examples: public/default/mydbserver.public.io-test.
If automatic topic creation is disabled on the Pulsar broker, you need to manually create these 4 types of topics and the destination topic. For offset.storage.topic and schema.history.internal.pulsar.topic, If they are not specified in your connector’s configuration, they will be created automatically using the following default naming convention:
  • schema.history.internal.pulsar.topic: "{tenant}/{namespace}/{connector-name}-debezium-history-topic"
  • offset.storage.topic: "{tenant}/{namespace}/{connector-name}-offset-storage-topic"
Here, and refer to the tenant and namespace where the connector is running. Both the history and offset topics require their data to be retained indefinitely to ensure fault-tolerance and prevent data loss. Before running the connector, you must configure an infinite retention policy for both topics. Use the pulsar-admin CLI to set the retention policy: