Debezium connector for JDBC

Table of Contents

• Overview

• How the JDBC connector works

  • Consuming complex Debezium change events
  • At-least-once delivery
  • Multiple tasks
  • Data and column type mappings
  • Primary key handling
  • Delete mode
  • Idempotent writes
  • Secondary unique constraints in sink connectors
  • Schema evolution
  • Quoting and case sensitivity
  • Connection Idle Timeouts
  • Changing how table names are resolved

• Data type mappings

  • Kafka Connect primitive data type mappings
  • Kafka Connect logical data type mappings
  • Debezium logical data type mappings
  • Debezium dialect-specific data type mappings
  • Debezium logical vector types mappings
  • Column and data type propagation

• Transformations

  • Naming transformations

• Deployment

  • Debezium JDBC connector configuration

• Connector properties

  • JDBC connector Kafka consumer properties
  • JDBC connector connection properties
  • JDBC connector runtime properties
  • JDBC connector extendable properties
  • JDBC connector hibernate.* passthrough properties

• Frequently asked questions

Overview

The Debezium JDBC connector is a Kafka Connect sink connector implementation that can consume events from multiple source topics, and then write those events to a relational database by using a JDBC driver. This connector supports a wide variety of database dialects, including Db2, MySQL, Oracle, PostgreSQL, and SQL Server.

How the JDBC connector works

The Debezium JDBC connector is a Kafka Connect sink connector, and therefore requires the Kafka Connect runtime. The connector periodically polls the Kafka topics that it subscribes to, consumes events from those topics, and then writes the events to the configured relational database. The connector supports idempotent write operations by using upsert semantics and basic schema evolution.

The Debezium JDBC connector provides the following features:

• Consuming complex Debezium change events
• JDBC at-least-once delivery
• Multiple tasks
• Data and column type mappings
• Primary key handling
• Delete mode
• Idempotent writes
• Schema evolution
• JDBC quoting and case-sensitivity
• Connection idle timeouts

Consuming complex Debezium change events

By default, Debezium source connectors produce complex, hierarchical change events. When Debezium connectors are used with other JDBC sink connector implementations, you might need to apply the ExtractNewRecordState single message transformation (SMT) to flatten the payload of change events, so that they can be consumed by the sink implementation. If you run the Debezium JDBC sink connector, it’s not necessary to deploy the SMT, because the Debezium sink connector can consume native Debezium change events directly, without the use of a transformation.

When the JDBC sink connector consumes a complex change event from a Debezium source connector, it extracts the values from the after section of the original insert or update event. When a delete event is consumed by the sink connector, no part of the event’s payload is consulted.

At-least-once delivery

The Debezium JDBC sink connector guarantees that events that it consumes from Kafka topics are processed at least once.

Multiple tasks

You can run the Debezium JDBC sink connector across multiple Kafka Connect tasks. To run the connector across multiple tasks, set the tasks.max configuration property to the number of tasks that you want the connector to use. The Kafka Connect runtime starts the specified number of tasks, and runs one instance of the connector per task. Multiple tasks can improve performance by reading and processing changes from multiple source topics in parallel.

Data and column type mappings

To enable the Debezium JDBC sink connector to correctly map the data type from an inbound message field to an outbound message field, the connector requires information about the data type of each field that is present in the source event. The connector supports a wide range of column type mappings across different database dialects. To correctly convert the destination column type from the type metadata in an event field, the connector applies the data type mappings that are defined for the source database. You can enhance the way that the connector resolves data types for a column by setting the column.propagate.source.type or datatype.propagate.source.type options in the source connector configuration. When you enable these options, Debezium includes extra parameter metadata, which assists the JDBC sink connector in more accurately resolving the data type of destination columns.

For the Debezium JDBC sink connector to process events from a Kafka topic, the Kafka topic message key, when present, must be a primitive data type or a Struct. In addition, the payload of the source message must be a Struct that has either a flattened structure with no nested struct types, or a nested struct layout that conforms to Debezium’s complex, hierarchical structure.

If the structure of the events in the Kafka topic do not adhere to these rules, you must implement a custom single message transformation to convert the structure of the source events into a usable format.

Primary key handling

By default, the Debezium JDBC sink connector does not transform any of the fields in the source event into the primary key for the event. Unfortunately, the lack of a stable primary key can complicate event processing, depending on your business requirements, or when the sink connector uses upsert semantics. To define a consistent primary key, you can configure the connector to use one of the primary key modes described in the following table:

Mode Description

none

No primary key fields are specified when creating the table.

kafka

The primary key consists of the following three columns:

• __connect_topic
• __connect_partition
• __connect_offset

The values for these columns are sourced from the coordinates of the Kafka event.

record_key

The primary key is composed of the Kafka event’s key.

If the primary key is a primitive type, specify the name of the column to be used by setting the primary.key.fields property. If the primary key is a struct type, the fields in the struct are mapped as columns of the primary key. You can use the primary.key.fields property to restrict the primary key to a subset of columns.

record_value

The primary key is composed of the Kafka event’s value.

Because the value of a Kafka event is always a Struct, by default, all of the fields in the value become columns of the primary key. To use a subset of fields in the primary key, set the primary.key.fields property to specify a comma-separated list of fields in the value from which you want to derive the primary key columns.

record_header

The primary key is composed of the Kafka event’s headers.

Kafka event’s headers contains could contain multiple header that each one could be Struct or primitives data types, the connectors makes a Struct of these headers. Hence, all fields in this Struct become columns of the primary key. To use a subset of fields in the primary key, set the primary.key.fields property to specify a comma-separated list of fields in the value from which you want to derive the primary key columns.

Some database dialects might throw an exception if you set the primary.key.mode to kafka and set schema.evolution to basic. This exception occurs when a dialect maps a STRING data type mapping to a variable length string data type such as TEXT or CLOB, and the dialect does not allow primary key columns to have unbounded lengths. To avoid this problem, apply the following settings in your environment:

• Do not set schema.evolution to basic.
• Create the database table and primary key mappings in advance.

Delete mode

By default, when the connector consumes DELETE or tombstone events, it does not delete the corresponding row in the sink database. You might want the connector to remove rows when you need to maintain data parity between the source and sink databases, so that deletions in the source are also reflected in the sink.

If you want to the connector to remove rows, you must explicitly set delete.enabled=true in the connector configuration. To use this mode you must also set primary.key.fields to a value other than none. The preceding configuration is necessary, because deletes are executed based on the primary key mapping, so if a destination table has no primary key mapping, the connector is unable to delete rows.

Idempotent writes

In an at-least-once delivery pipeline, the connector can receive the same event more than once after a restart or rebalance. Configure the connector to use upsert mode so that data written to the sink database is idempotent, and replaying an event always produces the same final row state.

To enable the connector to perform idempotent writes, you must be explicitly set the insert.mode for the connector to upsert. An upsert operation is applied as either an update or an insert, depending on whether the specified primary key already exists.

If the primary key value already exists, the operation updates values in the row. If the specified primary key value doesn’t exist, an insert adds a new row.

Each database dialect handles idempotent writes differently, because there is no SQL standard for upsert operations. The following table shows, for each database dialect that Debezium supports, the upsert DML syntax and the constraints that trigger an update action during an upsert operation.

Secondary unique constraints in sink connectors

Secondary unique constraints can create ordering dependencies between records that have different primary keys. Kafka guarantees record order only within a partition, and the connector batches and reduces events based only on the configured primary key. For these reasons, you should avoid defining secondary unique constraints or secondary unique indexes on destination tables. If a uniqueness rule is required, enforce the rule in the source database, and omit the constraint from the destination table.

If dependent records are routed to different partitions, the sink connector might apply records out of source order, which can lead to inconsistent results. The following table shows how different database dialects handle conflicts involving secondary unique constraints:

Table 1. Dialect-specific behavior when secondary unique constraint conflicts occur

To prevent data inconsistencies when a destination table includes a secondary unique constraint, the data pipeline must meet all of the following requirements:

Dependent events routed through the same partition

Route all dependent events through the same Kafka partition, and preserve the source event order. For a table with dependencies between arbitrary rows, use a single partition for its Kafka topic. Setting tasks.max=1 is not sufficient to restore ordering between records that are already in different partitions.

Reduction buffering disabled

Retain the default value (false) of the use.reduction.buffer property. Reduction by primary key can remove intermediate row states that are required to satisfy secondary unique constraints.

Batch size set to 1

Set the value of the batch.size property to 1 if any batches might contain multiple events for a primary key that is not defined in the destination table.

Some dialects and driver configurations process a batch in a single pass, rather than validating each row against the effects of the preceding rows in the same batch. For example, MERGE-based dialects can attempt two INSERT operations for the same primary key instead of an INSERT followed by an UPDATE. Similarly, when dialect.postgres.unnest.insert.enabled is set to true, PostgreSQL combines a batch into a single multi-row statement. In each of these cases, the batch fails.

Schema evolution

The schema.evolution property controls whether the connector automatically creates or alters destination tables when event schemas change. The following table describes the available modes, from no evolution (none) through startup validation (validate-only) to automatic table creation and column addition (basic).

When schema.evolution is set to basic, the connector automatically creates or alters the destination database table according to the structure of the incoming event.

When an event is received from a topic for the first time, and the destination table does not yet exist, the Debezium JDBC sink connector uses the event’s key, or the schema structure of the record to resolve the column structure of the table. If schema evolution is enabled, the connector prepares and executes a CREATE TABLE SQL statement before it applies the DML event to the destination table.

When the Debezium JDBC connector receives an event from a topic, if the schema structure of the record differs from the schema structure of the destination table, the connector uses either the event’s key or its schema structure to identify which columns are new, and must be added to the database table. If schema evolution is enabled, the connector prepares and executes an ALTER TABLE SQL statement before it applies the DML event to the destination table. Because changing column data types, dropping columns, and adjusting primary keys can be considered dangerous operations, the connector is prohibited from performing these operations.

The schema of each field determines whether a column is NULL or NOT NULL. The schema also defines the default values for each column. If the connector attempts to create a table with a nullability setting or a default value that don’t want, you must either create the table manually, ahead of time, or adjust the schema of the associated field before the sink connector processes the event. To adjust nullability settings or default values, you can introduce a custom single message transformation that applies changes in the pipeline, or modifies the column state defined in the source database.

A field’s data type is resolved based on a predefined set of mappings. For more information, see JDBC field types.

When you introduce new fields to the event structure of tables that already exist in the destination database, you must define the new fields as optional, or the fields must have a default value specified in the database schema. If you want a field to be removed from the destination table, use one of the following options:

• Remove the field manually.
• Drop the column.
• Assign a default value to the field.
• Define the field a nullable.

Quoting and case sensitivity

The Debezium JDBC sink connector consumes Kafka messages by constructing either DDL (schema changes) or DML (data changes) SQL statements that are executed on the destination database. By default, the connector uses the names of the source topic and the event fields as the basis for the table and column names in the destination table. The constructed SQL does not automatically delimit identifiers with quotes to preserve the case of the original strings. As a result, by default, the text case of table or column names in the destination database depends entirely on how the database handles name strings when the case is not specified.

For example, if the destination database dialect is Oracle and the event’s topic is orders, the destination table will be created as ORDERS because Oracle defaults to uppercase names when the name is not quoted. Similarly, if the destination database dialect is PostgreSQL and the event’s topic is ORDERS, the destination table will be created as orders because PostgreSQL defaults to lower-case names when the name is not quoted.

To explicitly preserve the case of the table and field names that are present in a Kafka event, in the connector configuration, set the value of the quote.identifiers property to true. When this options is set, when an incoming event is for a topic called orders, and the destination database dialect is Oracle, the connector creates a table with the name orders, because the constructed SQL defines the name of the table as "orders". Enabling quoting results in the same behavior when the connector creates column names.

Connection Idle Timeouts

Connections held idle in the pool can time out if they remain inactive beyond the database’s configured threshold, causing subsequent write operations to fail. Set the hibernate.agroal.idleValidation property to enable periodic validation of pooled connections and prevent idle timeout errors.

The JDBC sink connector for Debezium leverages a connection pool to enhance performance. Connection pools are engineered to establish an initial set of connections, maintain a specified number of connections, and efficiently allocate connections to the application as required. However, a challenge arises when connections linger idle in the pool, potentially triggering timeouts if they remain inactive beyond the configured idle timeout threshold of the database.

To mitigate the potential for idle connection threads to trigger timeouts, connection pools offer a mechanism that periodically validates the activity of each connection. This validation ensures that connections remain active, and prevents the database from flagging them as idle. In the event of a network disruption, if Debezium attempts to use a terminated connection, the connector prompts the pool to generate a new connection.

By default, the Debezium JDBC sink connector does not conduct idle timeout tests. However, you can configure the connector to request the pool to perform timeout tests at a specified interval by setting the hibernate.agroal.idleValidation property. For example:

Example timeout configuration

{
  "hibernate.agroal.idleValidation": "300"
}

The Debezium JDBC sink connector uses the Hibernate Agroal connection pool. You can customize the Agroal connection pool by setting properties in the hibernate.agroal.* configuration namespace. In the preceding example, the setting of the hibernate.agroal.idleValidation property configures the connection pool to perform idle timeout tests every 300 seconds. After you apply the configuration, the connection pool begins to assess unused connections every five minutes.

Changing how table names are resolved

The Debezium JDBC sink connector uses a io.debezium.sink.naming.CollectionNamingStrategy to control how an event is mapped to a target table. The default behavior is to use the collection.name.format configuration property and apply the following rules:

• Replace all occurrences of . with _ in the event’s topic name.
• Replace any reference to ${topic} in the collection.name.format with the sanitized topic name.
• Replace any reference to ${source.<fieldName>} in the collection.name.format with the appropriate field value from the source block.

While this behavior covers many use cases, this may not always be ideal in all situations. In some cases, you may wish to directly map the event’s topic name to the table name, without any sanitization. This can be accomplished by setting the collection.naming.strategy to use a passthrough implementation. For example:

Example using the passthrough collection naming strategy

{
  "collection.naming.strategy": "io.debezium.sink.naming.PassthroughCollectionNamingStrategy"
}

The passthrough naming strategy applies the following simplified rules:

• Replace any reference to ${topic} in the collection.name.format with the event’s topic name, without sanitization.
• Ignore any reference to ${source.<fieldName>} in the collection.name.format.

If neither of these solutions provide the behavior needed, you can also implement your own io.debezium.sink.naming.CollectionNamingStrategy. The custom implementation should be placed alongside the Debezium JDBC sink connector files. Be sure to set the collection.naming.strategy to the fully qualified class name of the custom implementation.

Data type mappings

Before the Debezium JDBC sink connector sends data to a sink database, it converts data types in the original source record to a corresponding type in the target system. Appropriate data type mapping ensures that the original data is accurately represented in the destination database.

The Debezium JDBC sink connector resolves a column’s data type by using a logical or primitive type-mapping system. Primitive types include values such as integers, floating points, Booleans, strings, and bytes. Typically, Kafka messages use a specific Kafka Connect Schema type code to represent primitive data types.

By contrast, to represent more complex data, Debezium uses logical schema names, which provide logical groupings of named fields that can represent a range of data types (strings, arrays, JSON, XML, and so forth). These structured types take into account the semantic meaning of the data and provide a more opinionated interpretation about how to serialize the underlying primitive types. Logical types are useful in representing values that have a specific encoding, such as numbers that represent the time since the epoch.

The following examples show representative structures of primitive and logical data types:

Example 1. Primitive field schema

{
  "schema": {
    "type": "INT64"
  }
}

Example 2. Logical field schema

{
  "schema": {
    "type": "INT64",
    "name": "org.apache.kafka.connect.data.Date"
  }
}

Kafka Connect is not the only source for these complex, logical types. In fact, when a Debezium source connector emits a change event, it can assign similar logical types to event fields to represent such data types as timestamps, dates, and even JSON data.

The Debezium JDBC sink connector uses these primitive and logical types to resolve a column’s type to a JDBC SQL code, which represents a column’s type. These JDBC SQL codes are then used by the underlying Hibernate persistence framework to resolve the column’s type to a logical data type for the dialect in use. The following tables illustrate the primitive and logical mappings between Kafka Connect and JDBC SQL types, and between Debezium and JDBC SQL types. The actual final column type varies with for each database type.

1. Kafka Connect primitive data type mappings
2. Kafka Connect logical data type mappings
3. Debezium logical data type mappings
4. Debezium dialect-specific data type mappings
5. Debezium logical vector types mappings

Kafka Connect primitive data type mappings

The following table maps each Kafka Connect primitive type to its corresponding JDBC SQL type, which the Debezium JDBC sink connector uses when creating or altering columns in the destination database.

Table 2. Mappings between Kafka Connect primitive data types and column data types

Kafka Connect logical data type mappings

The following table maps each Kafka Connect logical type to its corresponding JDBC SQL type, which the Debezium JDBC sink connector uses when writing structured data such as dates, times, and decimals to the destination database.

Table 3. Mappings between Kafka Connect logical data types and column data types

Debezium logical data type mappings

The following table maps Debezium logical types to their corresponding JDBC SQL types, which the connector uses when writing Debezium change event fields — such as timestamps, durations, and variable-scale decimals — to the destination database.

Table 4. Mappings between Debezium logical types and column data types

Debezium dialect-specific data type mappings

The following table maps Debezium logical types to dialect-specific column types for each supported database, which you can use to understand how the connector resolves fields such as JSON, geospatial data, and bit strings when targeting a specific database dialect.

Table 5. Mappings between Debezium dialect-specific logical types and column data types

1 When a logical type maps to more than one type, the Debezium JDBC connector defaults to the first more generalized data type. If the connector consumes change events from topics that are populated by a Debezium source connector, the JDBC connector can use stricter, more concrete data types when it sends data to some targets. To enable the use of these stricter data type conversions, set the column.propagate.source.type or datatype.propagate.source.type properties in the source connector configuration. When these properties are set in the source connector, the events that it generates include additional column metadata that the JDBC connector then uses to construct columns with a stricter concrete data type. In the preceding table, where a second entry, marked with an asterisk, appears in a table cell, it represents the stricter data type.

Debezium logical vector types mappings

The Debezium JDBC sink connector supports direct mapping of logical vector data types from source events to sink destinations, provided that the target database supports a comparable representation.

If a vector field in the source has a logical name, Debezium uses it to determine the appropriate mapping. For certain databases, the connector recognizes the following logical names under the io.debezium.data.vector.* namespace:

• FloatVector
• DoubleVector
• SparseVector

When the connector processes a message, if these logical types are present, the connector checks for a corresponding mapping in the target database. If a mapping exists, it applies it; otherwise, it defaults to serializing the data as a string, based on the Kafka Connect schema type.

For example, a connector that is configured to send data to a PostgreSQL database sink maps fields with the io.debezium.data.FloatVector logical name to the halfvector column type, using the special override mapping. By contrast, if no direct mapping is available in the sink database, as for example with an Oracle sink, the connector defaults to serializing vector data in its raw string format.

Support for the special vector types is not available for all releases of the supported databases. Sink databases must meet the following requirements to support direct mapping of logical vector types:

• MariaDB version 11.7 or later
• MySQL version 9.0 or later
• PostgreSQL requires the pgvector extension

Earlier versions of MariaDB or MySQL, and PostgreSQL without pgvector, do not support special vector types.

Table 6. Mappings between Debezium Vector Types and Column Data Types

Column and data type propagation

In addition to the primitive and logical mappings shown in the preceding tables, if the source of the change events is a Debezium source connector, the resolution of the column type, along with its length, precision, and scale, can be further influenced by enabling column or data type propagation. Column and data type propagation helps to determine how the structure and data types of incoming data are translated and applied to the sink destination. As discussed earlier in Data and column type mappings, you can enforce propagation by setting one of the following properties in the source connector configuration:

• column.propagate.source.type
• datatype.propagate.source.type

The Debezium JDBC sink connector applies only the values with the higher precedence.

To illustrate how propagation affects how the connector maps data types, let’s look at an example. The following example shows a field schema that might be included within a change event:

Example 3. Debezium change event field schema with column or data type propagation enabled

{
  "schema": {
    "type": "INT8",
    "parameters": {
      "__debezium.source.column.type": "TINYINT",
      "__debezium.source.column.length": "1"
    }
  }
}

Because the source connector that emitted the event was configured to use column or data type propagation, the event includes parameters that specify column type and length.

If propagation were not enabled for the source connector, the type and length parameters would be absent, and the Debezium JDBC sink connector would default to mapping the INT8 value in the type field to a column type of Types.SMALLINT. Depending on the SQL dialect of the target database, the connector would then resolve the JDBC Types.SMALLINT type to any of several logical types, For example, for a MySQL sink target, the JDBC connector defaults to converting Types.SMALLINT to a TINYINT column type with no specified length.

However, because type propagation is enabled in the source connector, the event that it emitted includes the type and length, providing more specific mapping instructions. Thus, rather than using the default mapping, the Debezium JDBC sink connector uses the given parameter values to refine the mapping, and creates a column in the sink database with the type TINYINT(1).

Transformations

The Debezium JDBC connector provides several transformations that can be added to the connector configuration to modify the consumed events in-flight before they’re processed by the connector.

Naming transformations

The Debezium JDBC connector provides two naming transformations that you can apply to change the naming styles of topic or field names within an event. Optionally, you can also use the naming transformations to apply a prefix or suffix to the transformed name.

You can configure naming transformations to use one of the following naming styles:

camel_case

Removes all period (.) and underscore (_) characters, and converts the immediate next character to uppercase. For example, the value inventory.customers is changed to inventoryCustomers.

snake_case

Removes all period (.) characters and replaces them with underscore (_) characters. Additionally, all numeric sequences are prefixed with an underscore (_), and all uppercase characters are converted to lowercase and then prefixed with an underscore (_) character. For example, the value public.inventory becomes public_inventory, while TopicWith123Numbers becomes topic_with_123_numbers.

upper_case

Converts to uppercase. For example, the value public.inventory would become PUBLIC.INVENTORY.

lower_case

Converts to lowercase. For example, the value PUBLIC.INVENTORY would become public.inventory.

The connector provides the following naming transformations:

CollectionNameTransformation

The CollectionNameTransformation provides a way to change the case of the topic names before the event is consumed. This transformation has the following configuration properties:

The following configuration example illustrates using the CollectionNameTransformation SMT to set the topic name to uppercase and prefix the topic name with ADT_. For example, given a topic called public.inventory, the topic name becomes ADT_PUBLIC.INVENTORY.

Example CollectionNameTransformation configuration

{
  "transforms": "topic-uppercase",
  "transforms.topic-uppercase.type": "io.debezium.connector.jdbc.transforms.CollectionNameTransformation",
  "transforms.topic-uppercase.collection.naming.style": "upper_case",
  "transforms.topic-uppercase.collection.naming.prefix": "ADT_"
}

FieldNameTransformation

The FieldNameTransformation provides a way to change the case of field names before the event is consumed. If the event is a Debezium source connector event, only the fields within the before and after sections are changed. When the event is not a Debezium source connector event, all top-level field names are changed.

This transformation has the following configuration properties:

The following example shows how to configure the FieldNameTransformation SMT to convert field names name to lowercase and prefix the names with the string adt_. After you apply the SMT to an event that includes a field with the name ID, the field is renamed to adt_id.

Example FieldNameTransformation configuration

{
  "transforms": "topic-lowercase",
  "transforms.topic-lowercase.type": "io.debezium.connector.jdbc.transforms.FieldNameTransformation",
  "transforms.topic-lowercase.column.naming.style": "lower_case",
  "transforms.topic-lowercase.column.naming.prefix": "adt_"
}

Deployment

To deploy the Debezium JDBC sink connector, install the connector archive in your Kafka Connect environment, configure the connector properties, and register the connector with Kafka Connect.

Prerequisites

• Apache Kafka and Kafka Connect are installed.
• You have a Kafka topic from which the connector can read change event records.
• A destination database is installed and is configured to accept JDBC connections.

Procedure

1. Download the Debezium JDBC connector plug-in archive.

2. Extract the files into your Kafka Connect environment.

3. Optionally download the JDBC driver from Maven Central and extract the downloaded driver file to the directory that contains the JDBC sink connector JAR file.

   	Drivers for Oracle and Db2 are not included with the JDBC sink connector. You must download the drivers and install them manually.

4. Add the directory with the JAR files to Kafka Connect’s plugin.path. Make sure that the path where you install the JDBC sink connector is part of the Kafka Connect plugin.path.

5. Restart the Kafka Connect process to pick up the new JAR files.

Debezium JDBC connector configuration

Typically, you register a Debezium JDBC connector by submitting a JSON request that specifies the configuration properties for the connector. The following example shows a JSON request for registering an instance of the Debezium JDBC sink connector that consumes events from a topic called orders with the most common configuration settings:

Example: Debezium JDBC connector configuration

{
    "name": "jdbc-connector",
    "config": {
        "connector.class": "io.debezium.connector.jdbc.JdbcSinkConnector",
        "tasks.max": "1",
        "connection.url": "jdbc:postgresql://localhost/db",
        "connection.username": "pguser",
        "connection.password": "pgpassword",
        "insert.mode": "upsert",
        "delete.enabled": "true",
        "primary.key.mode": "record_key",
        "schema.evolution": "basic",
        "use.time.zone": "UTC",
        "topics": "orders"
    }
}

The following list describes select fields in the preceding connector configuration example:

name

The name that is assigned to the connector when you register it with Kafka Connect service.

connector.class

The name of the JDBC sink connector class.

tasks.max

The maximum number of tasks to create for this connector.

connection.url

The JDBC URL that the connector uses to connect to the sink database that it writes to.

connection.username

The name of the database user that is used for authentication.

connection.password

The password of the database user used for authentication.

insert.mode

The insert.mode that the connector uses.

delete.enabled

Enables the deletion of records in the database. For more information, see the delete.enabled configuration property.

primary.key.mode

Specifies the method used to resolve primary key columns. For more information, see the primary.key.mode configuration property.

schema.evolution

Enables the connector to evolve the destination database’s schema. For more information, see the schema.evolution configuration property.

use.time.zone

Specifies the timezone used when writing temporal field types.

topics

List of topics to consume, separated by commas.

For a complete list of configuration properties that you can set for the Debezium JDBC connector, see JDBC connector properties.

You can send this configuration with a POST command to a running Kafka Connect service. The service records the configuration and starts a sink connector task(s) that performs the following operations:

• Connects to the database.
• Consumes events from subscribed Kafka topics.
• Writes the events to the configured database.

Connector properties

The Debezium JDBC sink connector has several configuration properties that you can use to achieve the connector behavior that meets your needs. Many properties have default values. Information about the properties is organized as follows:

• JCBC connector Kafka consumer properties
• JDBC connector connection properties
• JDBC connector runtime properties
• JDBC connector extendable properties
• JDBC connector hibernate.* passthrough properties

JDBC connector Kafka consumer properties

The following table describes the Kafka consumer properties that control how the Debezium JDBC sink connector identifies itself to Kafka Connect and specifies the topics it consumes.

JDBC connector connection properties

The following table describes the properties that control how the Debezium JDBC sink connector connects to and authenticates with the destination database, including connection pool settings.

Property Default Description

connection.provider

org.hibernate.agroal.internal.AgroalConnectionProvider

The connection provider implementation to use.

connection.url

No default

The JDBC connection URL used to connect to the database.

connection.username

No default

The name of the database user account that the connector uses to connect to the database.

connection.password

No default

The password that the connector uses to connect to the database.

connection.pool.min_size

5

Specifies the minimum number of connections in the pool.

connection.pool.max_size

32

Specifies the maximum number of concurrent connections that the pool maintains.

connection.pool.timeout

1800

Specifies the number of seconds that an unused connection is kept before it is discarded.

connection.restart.on.errors

false

Specifies whether the connector retries after a transient JDBC connection error.

When enabled (true), the connector treats connection issues (such as socket closures or timeouts) as retriable, allowing it to retry processing instead of failing the task. This reduces downtime and improves resilience against temporary disruptions.

Setting this option to true can reduce downtime. However, in master-replica environments with asynchronous replication, it may lead to data loss if retries occur before all changes are fully replicated.

Use with caution where strong data consistency is required.

JDBC connector runtime properties

The following table describes the runtime properties that control how the Debezium JDBC sink connector processes events and writes data to the destination database, including insert mode, primary key resolution, schema evolution, and batching behavior.

Property Default Description

use.time.zone

UTC

Specifies the timezone used when inserting JDBC temporal values.

delete.enabled

false

Specifies whether the connector processes DELETE or tombstone events and removes the corresponding row from the database. Use of this option requires that you set the primary.key.mode to record.key.

truncate.enabled

false

Specifies whether the connector processes TRUNCATE events and truncates the corresponding tables from the database.

Although support for TRUNCATE statements has been available in Db2 since version 9.7, currently, the JDBC connector is unable to process standard TRUNCATE events that the Db2 connector emits.

To ensure that the JDBC connector can process TRUNCATE events received from Db2, perform the truncation by using an alternative to the standard TRUNCATE TABLE statement. For example:

ALTER TABLE <table_name> ACTIVATE NOT LOGGED INITIALLY WITH EMPTY TABLE

The user account that submits the preceding query requires ALTER privileges on the table to be truncated.

insert.mode

insert

Specifies the strategy used to insert events into the database. The following options are available:

insert

Specifies that all events should construct INSERT-based SQL statements. Use this option only when no primary key is used, or when you can be certain that no updates can occur to rows with existing primary key values.

update

Specifies that all events should construct UPDATE-based SQL statements. Use this option only when you can be certain that the connector receives only events that apply to existing rows.

upsert

Specifies that the connector adds events to the table using upsert semantics. That is, if the primary key does not exist, the connector performs an INSERT operation, and if the key does exist, the connector performs an UPDATE operation. When idempotent writes are required, the connector should be configured to use this option.

primary.key.mode

none

Specifies how the connector resolves the primary key columns from the event.

none

Specifies that no primary key columns are created.

kafka

Specifies that the connector uses Kafka coordinates as the primary key columns. The key coordinates are defined from the topic name, partition, and offset of the event, and are mapped to columns with the following names:

• __connect_topic
• __connect_partition
• __connect_offset

record_key

Specifies that the primary key columns are sourced from the event’s record key. If the record key is a primitive type, the primary.key.fields property is required to specify the name of the primary key column. If the record key is a struct type, the primary.key.fields property is optional, and can be used to specify a subset of columns from the event’s key as the table’s primary key.

record_value

Specifies that the primary key columns is sourced from the event’s value. You can set the primary.key.fields property to define the primary key as a subset of fields from the event’s value; otherwise all fields are used by default.

primary.key.fields

No default

Either the name of the primary key column or a comma-separated list of fields to derive the primary key from.

When primary.key.mode is set to record_key and the event’s key is a primitive type, it is expected that this property specifies the column name to be used for the key.

When the primary.key.mode is set to record_key with a non-primitive key, or record_value, it is expected that this property specifies a comma-separated list of field names from either the key or value. If the primary.key.mode is set to record_key with a non-primitive key, or record_value, and this property is not specified, the connector derives the primary key from all fields of either the record key or record value, depending on the specified mode.

quote.identifiers

false

Specifies whether generated SQL statements use quotation marks to delimit table and column names. See the JDBC quoting case-sensitivity section for more details.

schema.evolution

none

Specifies how the connector evolves the destination table schemas. For more information, see Schema evolution. The following options are available:

none

Specifies that the connector does not evolve the destination schema.

basic

Specifies that basic evolution occurs. The connector adds missing columns to the table by comparing the incoming event’s record schema to the database table structure.

collection.name.format

${topic}

Specifies a string pattern that the connector uses to construct the names of destination tables. When the property is set to its default value, ${topic}, after the connector reads an event from Kafka, it writes the event record to a destination table with a name that matches the name of the source topic.

You can also configure this property to extract values from specific fields in incoming event records and then use those values to dynamically generate the names of target tables. This ability to generate table names from values in the message source would otherwise require the use of a custom Kafka Connect single message transformation (SMT).

To configure the property to dynamically generate the names of destination tables, set its value to a pattern such as ${source._field_}. When you specify this type of pattern, the connector extracts values from the source block of the Debezium change event, and then uses those values to construct the table name. For example, you might set the value of the property to the pattern ${source.schema}_${source.table}. Based on this pattern, if the connector reads an event in which the schema field in the source block contains the value, user, and the table field contains the value, tab, the connector writes the event record to a table with the name user_tab.

dialect.postgres.postgis.schema

public

Specifies the schema name where the PostgreSQL PostGIS extension is installed. The default is public; however, if the PostGIS extension was installed in another schema, this property should be used to specify the alternate schema name.

dialect.postgres.unnest.insert.enabled

false

Specifies whether to enable UNNEST-based batch inserts for PostgreSQL.

When enabled, uses PostgreSQL UNNEST() for batch inserts, which can significantly improve performance by reducing the number of SQL statements executed. This optimization is compatible with INSERT and UPSERT modes.

For information about the performance benefits of enabling the UNNEST function, see "Boosting Postgres Insert Performance" in the Tiger Data blog.

dialect.sqlserver.identity.insert

false

Specifies whether the connector automatically sets an IDENTITY_INSERT before an INSERT or UPSERT operation into the identity column of SQL Server tables, and then unsets it immediately after the operation. When the default setting (false) is in effect, an INSERT or UPSERT operation into the IDENTITY column of a table results in a SQL exception.

batch.size

500

Specifies how many records to attempt to batch together into the destination table.

use.reduction.buffer

false

Specifies whether to enable the Debezium JDBC connector’s reduction buffer.

Choose one of the following settings:

false

(default) The connector writes each change event that it consumes from Kafka as a separate logical SQL change.

true

The connector uses the reduction buffer to reduce change events before it writes them to the sink database. That is, if multiple events refer to the same primary key, the connector consolidates the SQL queries and writes only a single logical SQL change, based on the row state that is reported in the most recent offset record. Choose this option to reduce the SQL load on the target database. Do not enable the reduction buffer if destination constraints create dependencies between records with different primary keys. Reduction by primary key can remove intermediate row states that are required to satisfy secondary unique constraints.

To optimize query processing in a PostgreSQL sink database when the reduction buffer is enabled, you must also enable the database to execute the batched queries by adding the reWriteBatchedInserts parameter to the JDBC connection URL.

field.include.list

empty string

An optional, comma-separated list of field names that match the fully-qualified names of fields to include from the change event value. Fully-qualified names for fields are of the form fieldName or topicName:_fieldName_.

If you include this property in the configuration, do not set the field.exclude.list property.

field.exclude.list

empty string

An optional, comma-separated list of field names that match the fully-qualified names of fields to exclude from the change event value. Fully-qualified names for fields are of the form fieldName or topicName:_fieldName_.

If you include this property in the configuration, do not set the field.include.list property.

flush.max.retries

5

Specifies the maximum number of retries that the connector performs after an attempt to flush changes to the target database results in certain database errors. If the number of retries exceeds the retry value, the sink connector enters a FAILED state.

flush.retry.delay.ms

1000

Specifies the number of milliseconds that the connector waits to retry a flush operation that failed.

JDBC connector extendable properties

The following table describes the properties that allow you to customize the naming strategies the Debezium JDBC sink connector uses to resolve destination table names and column names from incoming event data.

Property Default Description

column.naming.strategy

io.debezium.connector.jdbc.naming.DefaultColumnNamingStrategy

Specifies the fully-qualified class name of a ColumnNamingStrategy implementation that the connector uses to resolve column names from incoming event field names.

The default behavior is to use the field name as the column name without any transformation.

collection.naming.strategy

io.debezium.connector.jdbc.nnaming.DefaultCollectionNamingStrategy

Specifies the fully-qualified class name of a CollectionNamingStrategy implementation that the connector uses to resolve table names from incoming event topic names.

The default behavior is to:

• Sanitize the topic name by replacing dots (.) with underscores (_).
• Replace the ${topic} placeholder in the collection.name.format configuration property with the event’s topic.

JDBC connector hibernate.* passthrough properties

Kafka Connect supports passthrough configuration, enabling you to modify the behavior of an underlying system by passing certain properties directly from the connector configuration. By default, some Hibernate properties are exposed via the JDBC connector connection properties (for example, connection.url, connection.username, and connection.pool.*_size), and through the connector’s runtime properties (for example, use.time.zone, quote.identifiers).

If you want to customize other Hibernate behavior, you can take advantage of the passthrough mechanism by adding properties that use the hibernate.* namespace to the connector configuration. For example, to assist Hibernate in resolving the type and version of the target database, you can add the hibernate.dialect property and set it to the fully qualified class name of the database, for example, org.hibernate.dialect.MariaDBDialect.

Frequently asked questions

The following questions and answers address common decisions and scenarios when you configure and operate the Debezium JDBC sink connector, including event transformation requirements, schema evolution limitations, data type mapping, and table naming options.

Is the ExtractNewRecordState single message transformation required?

No, that is actually one of the differentiating factors of the Debezium JDBC connector from other implementations. While the connector is capable of ingesting flattened events like its competitors, it can also ingest Debezium’s complex change event structure natively, without requiring any specific type of transformation.

If a column’s type is changed, or if a column is renamed or dropped, is this handled by schema evolution?

No, the Debezium JDBC connector does not make any changes to existing columns. The schema evolution supported by the connector is quite basic. It simply compares the fields in the event structure to the table’s column list, and then adds any fields that are not yet defined as columns in the table. If a column’s type or default value change, the connector does not adjust them in the destination database. If a column is renamed, the old column is left as-is, and the connector appends a column with the new name to the table; however existing rows with data in the old column remain unchanged. These types of schema changes should be handled manually.

If a column’s type does not resolve to the type that I want, how can I enforce mapping to a different data type?

The Debezium JDBC connector uses a sophisticated type system to resolve a column’s data type. For details about how this type system resolves a specific field’s schema definition to a JDBC type, see the Data and column type mappings section. If you want to apply a different data type mapping, define the table manually to explicitly obtain the preferred column type.

How do you specify a prefix or a suffix to the table name without changing the Kafka topic name?

In order to add a prefix or a suffix to the destination table name, adjust the collection.name.format connector configuration property to apply the prefix or suffix that you want. For example, to prefix all table names with jdbc_, specify the collection.name.format configuration property with a value of jdbc_${topic}. If the connector is subscribed to a topic called orders, the resulting table is created as jdbc_orders.

Why are some columns automatically quoted, even though identifier quoting is not enabled?

In some situations, specific column or table names might be explicitly quoted, even when quote.identifiers is not enabled. This is often necessary when the column or table name starts with or uses a specific convention that would otherwise be considered illegal syntax. For example, when the primary.key.mode is set to kafka, some databases only permit column names to begin with an underscore if the column’s name is quoted. Quoting behavior is dialect-specific, and varies among different types of database.