Exporting CloudEvents

Table of Contents

Example event format
Example configuration
Configuration options

CloudEvents is a specification for describing event data in a common way. Its aim is to provide interoperability across services, platforms and systems. Debezium enables you to configure a MongoDB, MySQL, PostgreSQL, or SQL Server connector to emit change event records that conform to the CloudEvents specification.

Support for CloudEvents is in an incubating state. This means that exact semantics, configuration options, and other details may change in future revisions based on feedback. Please let us know your specific requirements or if you encounter any problems while using this feature.

The CloudEvents specification defines:

A set of standardized event attributes
Rules for defining custom attributes
Encoding rules for mapping event formats to serialized representations such as JSON or Avro
Protocol bindings for transport layers such as Apache Kafka, HTTP or AMQP

To configure a Debezium connector to emit change event records that conform to the CloudEvents specification, Debezium provides the io.debezium.converters.CloudEventsConverter, which is a Kafka Connect message converter.

Currently, only structured mapping mode is supported. The CloudEvents change event envelope can be JSON or Avro and each envelope type supports JSON or Avro as the data format. It is expected that a future Debezium release will support binary mapping mode.

For information about using Avro, see:

Example event format

The following example shows what a CloudEvents change event record emitted by a PostgreSQL connector looks like. In this example, the PostgreSQL connector is configured to use JSON as the CloudEvents format envelope and also as the data format.

{
  "id" : "name:test_server;lsn:29274832;txId:565",   (1)
  "source" : "/debezium/postgresql/test_server",     (2)
  "specversion" : "1.0",                             (3)
  "type" : "io.debezium.postgresql.datachangeevent", (4)
  "time" : "2020-01-13T13:55:39.738Z",               (5)
  "datacontenttype" : "application/json",            (6)
  "iodebeziumop" : "r",                              (7)
  "iodebeziumversion" : "1.9.2.Final",        (8)
  "iodebeziumconnector" : "postgresql",
  "iodebeziumname" : "test_server",
  "iodebeziumtsms" : "1578923739738",
  "iodebeziumsnapshot" : "true",
  "iodebeziumdb" : "postgres",
  "iodebeziumschema" : "s1",
  "iodebeziumtable" : "a",
  "iodebeziumtxId" : "565",
  "iodebeziumlsn" : "29274832",
  "iodebeziumxmin" : null,
  "iodebeziumtxid": "565",                           (9)
  "iodebeziumtxtotalorder": "1",
  "iodebeziumtxdatacollectionorder": "1",
  "data" : {                                         (10)
    "before" : null,
    "after" : {
      "pk" : 1,
      "name" : "Bob"
    }
  }
}

1	Unique ID that the connector generates for the change event based on the change event’s content.
2	The source of the event, which is the logical name of the database as specified by the `database.server.name` property in the connector’s configuration.
3	The CloudEvents specification version.
4	Connector type that generated the change event. The format of this field is `io.debezium.CONNECTOR_TYPE.datachangeevent`. The value of `CONNECTOR_TYPE` is `mongodb`, `mysql`, `postgresql`, or `sqlserver`.
5	Time of the change in the source database.
6	Describes the content type of the `data` attribute, which is JSON in this example. The only alternative is Avro.
7	An operation identifier. Possible values are `r` for read, `c` for create, `u` for update, or `d` for delete.
8	All `source` attributes that are known from Debezium change events are mapped to CloudEvents extension attributes by using the `iodebezium` prefix for the attribute name.
9	When enabled in the connector, each `transaction` attribute that is known from Debezium change events is mapped to a CloudEvents extension attribute by using the `iodebeziumtx` prefix for the attribute name.
10	The actual data change itself. Depending on the operation and the connector, the data might contain `before`, `after` and/or `patch` fields.

The following example also shows what a CloudEvents change event record emitted by a PostgreSQL connector looks like. In this example, the PostgreSQL connector is again configured to use JSON as the CloudEvents format envelope, but this time the connector is configured to use Avro for the data format.

{
  "id" : "name:test_server;lsn:33227720;txId:578",
  "source" : "/debezium/postgresql/test_server",
  "specversion" : "1.0",
  "type" : "io.debezium.postgresql.datachangeevent",
  "time" : "2020-01-13T14:04:18.597Z",
  "datacontenttype" : "application/avro",            (1)
  "dataschema" : "http://my-registry/schemas/ids/1", (2)
  "iodebeziumop" : "r",
  "iodebeziumversion" : "1.9.2.Final",
  "iodebeziumconnector" : "postgresql",
  "iodebeziumname" : "test_server",
  "iodebeziumtsms" : "1578924258597",
  "iodebeziumsnapshot" : "true",
  "iodebeziumdb" : "postgres",
  "iodebeziumschema" : "s1",
  "iodebeziumtable" : "a",
  "iodebeziumtxId" : "578",
  "iodebeziumlsn" : "33227720",
  "iodebeziumxmin" : null,
  "iodebeziumtxid": "578",
  "iodebeziumtxtotalorder": "1",
  "iodebeziumtxdatacollectionorder": "1",
  "data" : "AAAAAAEAAgICAg=="                        (3)
}

1	Indicates that the `data` attribute contains Avro binary data.
2	URI of the schema to which the Avro data adheres.
3	The `data` attribute contains base64-encoded Avro binary data.

It is also possible to use Avro for the envelope as well as the data attribute.

Example configuration

Configure io.debezium.converters.CloudEventsConverter in your Debezium connector configuration. The following example shows how to configure the CloudEvents converter to emit change event records that have the following characteristics:

Use JSON as the envelope.
Use the schema registry at http://my-registry/schemas/ids/1 to serialize the data attribute as binary Avro data.

...
"value.converter": "io.debezium.converters.CloudEventsConverter",
"value.converter.serializer.type" : "json",          (1)
"value.converter.data.serializer.type" : "avro",
"value.converter.avro.schema.registry.url": "http://my-registry/schemas/ids/1"
...

1	Specifying the `serializer.type` is optional, because `json` is the default.

The CloudEvents converter converts Kafka record values. In the same connector configuration, you can specify key.converter if you want to operate on record keys. For example, you might specify StringConverter, LongConverter, JsonConverter, or AvroConverter.

Configuration options

When you configure a Debezium connector to use the CloudEvent converter you can specify the following options.

Table 1. Descriptions of CloudEvents converter configuration options
Option	Default	Description
`serializer.type`	`json`	The encoding type to use for the CloudEvents envelope structure. The value can be `json` or `avro`.
`data.serializer.type`	`json`	The encoding type to use for the `data` attribute. The value can be `json` or `avro`.
`json. ...`	N/A	Any configuration options to be passed through to the underlying converter when using JSON. The `json.` prefix is removed.
`avro. ...`	N/A	Any configuration options to be passed through to the underlying converter when using Avro. The `avro.` prefix is removed. For example, for Avro `data`, you would specify the `avro.schema.registry.url` option.
`schema.name.adjustment.mode`	`avro`	Specifies how schema names should be adjusted for compatibility with the message converter used by the connector. The value can be `avro` or `none`.