Chapter 2. Source connectors Debezium provides a library of source connectors that capture changes from a variety of database management systems. Each connector produces change events with very similar structures, making it easy for your applications to consume and respond to events, regardless of their origin. Currently, Debezium provides source connectors for the following databases: Db2 MariaDB (Technology Preview) MongoDB MySQL Oracle PostgreSQL SQL Server 2.1. Debezium connector for Db2 Debezium's Db2 connector can capture row-level changes in the tables of a Db2 database. For information about the Db2 Database versions that are compatible with this connector, see the Debezium Supported Configurations page . This connector is strongly inspired by the Debezium implementation of SQL Server, which uses a SQL-based polling model that puts tables into "capture mode". When a table is in capture mode, the Debezium Db2 connector generates and streams a change event for each row-level update to that table. A table that is in capture mode has an associated change-data table, which Db2 creates. For each change to a table that is in capture mode, Db2 adds data about that change to the table's associated change-data table. A change-data table contains an entry for each state of a row. It also has special entries for deletions. The Debezium Db2 connector reads change events from change-data tables and emits the events to Kafka topics. The first time a Debezium Db2 connector connects to a Db2 database, the connector reads a consistent snapshot of the tables for which the connector is configured to capture changes. By default, this is all non-system tables. There are connector configuration properties that let you specify which tables to put into capture mode, or which tables to exclude from capture mode. When the snapshot is complete the connector begins emitting change events for committed updates to tables that are in capture mode. By default, change events for a particular table go to a Kafka topic that has the same name as the table. Applications and services consume change events from these topics. Note The connector requires the use of the abstract syntax notation (ASN) libraries, which are available as a standard part of Db2 for Linux. To use the ASN libraries, you must have a license for IBM InfoSphere Data Replication (IIDR). You do not have to install IIDR to use the ASN libraries. Information and procedures for using a Debezium Db2 connector is organized as follows: Section 2.1.1, "Overview of Debezium Db2 connector" Section 2.1.2, "How Debezium Db2 connectors work" Section 2.1.3, "Descriptions of Debezium Db2 connector data change events" Section 2.1.4, "How Debezium Db2 connectors map data types" Section 2.1.5, "Setting up Db2 to run a Debezium connector" Section 2.1.6, "Deployment of Debezium Db2 connectors" Section 2.1.7, "Monitoring Debezium Db2 connector performance" Section 2.1.8, "Managing Debezium Db2 connectors" Section 2.1.9, "Updating schemas for Db2 tables in capture mode for Debezium connectors" 2.1.1. Overview of Debezium Db2 connector The Debezium Db2 connector is based on the ASN Capture/Apply agents that enable SQL Replication in Db2. A capture agent: Generates change-data tables for tables that are in capture mode. Monitors tables in capture mode and stores change events for updates to those tables in their corresponding change-data tables. The Debezium connector uses a SQL interface to query change-data tables for change events. The database administrator must put the tables for which you want to capture changes into capture mode. For convenience and for automating testing, there are Debezium management user-defined functions (UDFs) in C that you can compile and then use to do the following management tasks: Start, stop, and reinitialize the ASN agent Put tables into capture mode Create the replication (ASN) schemas and change-data tables Remove tables from capture mode Alternatively, you can use Db2 control commands to accomplish these tasks. After the tables of interest are in capture mode, the connector reads their corresponding change-data tables to obtain change events for table updates. The connector emits a change event for each row-level insert, update, and delete operation to a Kafka topic that has the same name as the changed table. This is default behavior that you can modify. Client applications read the Kafka topics that correspond to the database tables of interest and can react to each row-level change event. Typically, the database administrator puts a table into capture mode in the middle of the life of a table. This means that the connector does not have the complete history of all changes that have been made to the table. Therefore, when the Db2 connector first connects to a particular Db2 database, it starts by performing a consistent snapshot of each table that is in capture mode. After the connector completes the snapshot, the connector streams change events from the point at which the snapshot was made. In this way, the connector starts with a consistent view of the tables that are in capture mode, and does not drop any changes that were made while it was performing the snapshot. Debezium connectors are tolerant of failures. As the connector reads and produces change events, it records the log sequence number (LSN) of the change-data table entry. The LSN is the position of the change event in the database log. If the connector stops for any reason, including communication failures, network problems, or crashes, upon restarting it continues reading the change-data tables where it left off. This includes snapshots. That is, if the snapshot was not complete when the connector stopped, upon restart the connector begins a new snapshot. 2.1.2. How Debezium Db2 connectors work To optimally configure and run a Debezium Db2 connector, it is helpful to understand how the connector performs snapshots, streams change events, determines Kafka topic names, and handles schema changes. Details are in the following topics: Section 2.1.2.1, "How Debezium Db2 connectors perform database snapshots" Section 2.1.2.2, "Ad hoc snapshots" Section 2.1.2.3, "Incremental snapshots" Section 2.1.2.5, "How Debezium Db2 connectors read change-data tables" Section 2.1.2.6, "Default names of Kafka topics that receive Debezium Db2 change event records" Section 2.1.2.8, "About the Debezium Db2 connector schema change topic" Section 2.1.2.9, "Debezium Db2 connector-generated events that represent transaction boundaries" 2.1.2.1. How Debezium Db2 connectors perform database snapshots Db2`s replication feature is not designed to store the complete history of database changes. As a result, the Debezium Db2 connector cannot retrieve the entire history of the database from the logs. To enable the connector to establish a baseline for the current state of the database, the first time that the connector starts, it performs an initial consistent snapshot of the tables that are in capture mode . For each change that the snapshot captures, the connector emits a read event to the Kafka topic for the captured table. You can find more information about snapshots in the following sections: Section 2.1.2.2, "Ad hoc snapshots" Section 2.1.2.3, "Incremental snapshots" 2.1.2.1.1. Default workflow that the Debezium Db2 connector uses to perform an initial snapshot The following workflow lists the steps that Debezium takes to create a snapshot. These steps describe the process for a snapshot when the snapshot.mode configuration property is set to its default value, which is initial . You can customize the way that the connector creates snapshots by changing the value of the snapshot.mode property. If you configure a different snapshot mode, the connector completes the snapshot by using a modified version of this workflow. Establish a connection to the database. Determine which tables are in capture mode and should be included in the snapshot. By default, the connector captures the data for all non-system tables. After the snapshot completes, the connector continues to stream data for the specified tables. If you want the connector to capture data only from specific tables you can direct the connector to capture the data for only a subset of tables or table elements by setting properties such as table.include.list or table.exclude.list . Obtain a lock on each of the tables in capture mode. This lock ensures that no schema changes can occur in those tables until the snapshot completes. The level of the lock is determined by the snapshot.isolation.mode connector configuration property. Read the highest (most recent) LSN position in the server's transaction log. Capture the schema of all tables or all tables that are designated for capture. The connector persists schema information in its internal database schema history topic. The schema history provides information about the structure that is in effect when a change event occurs. Note By default, the connector captures the schema of every table in the database that is in capture mode, including tables that are not configured for capture. If tables are not configured for capture, the initial snapshot captures only their structure; it does not capture any table data. For more information about why snapshots persist schema information for tables that you did not include in the initial snapshot, see Understanding why initial snapshots capture the schema for all tables . Release any locks obtained in Step 3. Other database clients can now write to any previously locked tables. At the LSN position read in Step 4, the connector scans the tables that are designated for capture. During the scan, the connector completes the following tasks: Confirms that the table was created before the snapshot began. If the table was created after the snapshot began, the connector skips the table. After the snapshot is complete, and the connector transitions to streaming, it emits change events for any tables that were created after the snapshot began. Produces a read event for each row that is captured from a table. All read events contain the same LSN position, which is the LSN position that was obtained in step 4. Emits each read event to the Kafka topic for the source table. Releases data table locks, if applicable. Record the successful completion of the snapshot in the connector offsets. The resulting initial snapshot captures the current state of each row in the captured tables. From this baseline state, the connector captures subsequent changes as they occur. After the snapshot process begins, if the process is interrupted due to connector failure, rebalancing, or other reasons, the process restarts after the connector restarts. After the connector completes the initial snapshot, it continues streaming from the position that it read in Step 4 so that it does not miss any updates. If the connector stops again for any reason, after it restarts, it resumes streaming changes from where it previously left off. Table 2.1. Settings for snapshot.mode connector configuration property Setting Description always The connector performs a snapshot every time that it starts. After the snapshot completes, the connector begins to stream event records for subsequent database changes. initial The connector performs a database snapshot as described in the default workflow for creating an initial snapshot . After the snapshot completes, the connector begins to stream event records for subsequent database changes. initial_only The connector performs a database snapshot. After the snapshot completes, the connector stops, and does not stream event records for subsequent database changes. schema_only Deprecated, see no_data . no_data The connector captures the structure of all relevant tables, performing all the steps described in the default snapshot workflow , except that it does not create READ events to represent the data set at the point of the connector's start-up (Step 7.b). recovery Set this option to restore a database schema history topic that is lost or corrupted. After a restart, the connector runs a snapshot that rebuilds the topic from the source tables. You can also set the property to periodically prune a database schema history topic that experiences unexpected growth. Warning Do not use this mode to perform a snapshot if schema changes were committed to the database after the last connector shutdown. when_needed After the connector starts, it performs a snapshot only if it detects one of the following circumstances: It cannot detect any topic offsets. A previously recorded offset specifies a log position that is not available on the server. For more information, see snapshot.mode in the table of connector configuration properties. 2.1.2.1.2. Description of why initial snapshots capture the schema history for all tables The initial snapshot that a connector runs captures two types of information: Table data Information about INSERT , UPDATE , and DELETE operations in tables that are named in the connector's table.include.list property. Schema data DDL statements that describe the structural changes that are applied to tables. Schema data is persisted to both the internal schema history topic, and to the connector's schema change topic, if one is configured. After you run an initial snapshot, you might notice that the snapshot captures schema information for tables that are not designated for capture. By default, initial snapshots are designed to capture schema information for every table that is present in the database, not only from tables that are designated for capture. Connectors require that the table's schema is present in the schema history topic before they can capture a table. By enabling the initial snapshot to capture schema data for tables that are not part of the original capture set, Debezium prepares the connector to readily capture event data from these tables should that later become necessary. If the initial snapshot does not capture a table's schema, you must add the schema to the history topic before the connector can capture data from the table. In some cases, you might want to limit schema capture in the initial snapshot. This can be useful when you want to reduce the time required to complete a snapshot. Or when Debezium connects to the database instance through a user account that has access to multiple logical databases, but you want the connector to capture changes only from tables in a specific logic database. Additional information Capturing data from tables not captured by the initial snapshot (no schema change) Capturing data from tables not captured by the initial snapshot (schema change) Setting the schema.history.internal.store.only.captured.tables.ddl property to specify the tables from which to capture schema information. Setting the schema.history.internal.store.only.captured.databases.ddl property to specify the logical databases from which to capture schema changes. 2.1.2.1.3. Capturing data from tables not captured by the initial snapshot (no schema change) In some cases, you might want the connector to capture data from a table whose schema was not captured by the initial snapshot. Depending on the connector configuration, the initial snapshot might capture the table schema only for specific tables in the database. If the table schema is not present in the history topic, the connector fails to capture the table, and reports a missing schema error. You might still be able to capture data from the table, but you must perform additional steps to add the table schema. Prerequisites You want to capture data from a table with a schema that the connector did not capture during the initial snapshot. No schema changes were applied to the table between the LSNs of the earliest and latest change table entry that the connector reads. For information about capturing data from a new table that has undergone structural changes, see Section 2.1.2.1.4, "Capturing data from tables not captured by the initial snapshot (schema change)" . Procedure Stop the connector. Remove the internal database schema history topic that is specified by the schema.history.internal.kafka.topic property . Clear the offsets in the configured Kafka Connect offset.storage.topic . For more information about how to remove offsets, see the Debezium community FAQ . Warning Removing offsets should be performed only by advanced users who have experience in manipulating internal Kafka Connect data. This operation is potentially destructive, and should be performed only as a last resort. Apply the following changes to the connector configuration: (Optional) Set the value of schema.history.internal.captured.tables.ddl to false . This setting causes the snapshot to capture the schema for all tables, and guarantees that, in the future, the connector can reconstruct the schema history for all tables. Note Snapshots that capture the schema for all tables require more time to complete. Add the tables that you want the connector to capture to table.include.list . Set the snapshot.mode to one of the following values: initial When you restart the connector, it takes a full snapshot of the database that captures the table data and table structures. If you select this option, consider setting the value of the schema.history.internal.captured.tables.ddl property to false to enable the connector to capture the schema of all tables. schema_only When you restart the connector, it takes a snapshot that captures only the table schema. Unlike a full data snapshot, this option does not capture any table data. Use this option if you want to restart the connector more quickly than with a full snapshot. Restart the connector. The connector completes the type of snapshot specified by the snapshot.mode . (Optional) If the connector performed a schema_only snapshot, after the snapshot completes, initiate an incremental snapshot to capture data from the tables that you added. The connector runs the snapshot while it continues to stream real-time changes from the tables. Running an incremental snapshot captures the following data changes: For tables that the connector previously captured, the incremental snapsot captures changes that occur while the connector was down, that is, in the interval between the time that the connector was stopped, and the current restart. For newly added tables, the incremental snapshot captures all existing table rows. 2.1.2.1.4. Capturing data from tables not captured by the initial snapshot (schema change) If a schema change is applied to a table, records that are committed before the schema change have different structures than those that were committed after the change. When Debezium captures data from a table, it reads the schema history to ensure that it applies the correct schema to each event. If the schema is not present in the schema history topic, the connector is unable to capture the table, and an error results. If you want to capture data from a table that was not captured by the initial snapshot, and the schema of the table was modified, you must add the schema to the history topic, if it is not already available. You can add the schema by running a new schema snapshot, or by running an initial snapshot for the table. Prerequisites You want to capture data from a table with a schema that the connector did not capture during the initial snapshot. A schema change was applied to the table so that the records to be captured do not have a uniform structure. Procedure Initial snapshot captured the schema for all tables ( store.only.captured.tables.ddl was set to false ) Edit the table.include.list property to specify the tables that you want to capture. Restart the connector. Initiate an incremental snapshot if you want to capture existing data from the newly added tables. Initial snapshot did not capture the schema for all tables ( store.only.captured.tables.ddl was set to true ) If the initial snapshot did not save the schema of the table that you want to capture, complete one of the following procedures: Procedure 1: Schema snapshot, followed by incremental snapshot In this procedure, the connector first performs a schema snapshot. You can then initiate an incremental snapshot to enable the connector to synchronize data. Stop the connector. Remove the internal database schema history topic that is specified by the schema.history.internal.kafka.topic property . Clear the offsets in the configured Kafka Connect offset.storage.topic . For more information about how to remove offsets, see the Debezium community FAQ . Warning Removing offsets should be performed only by advanced users who have experience in manipulating internal Kafka Connect data. This operation is potentially destructive, and should be performed only as a last resort. Set values for properties in the connector configuration as described in the following steps: Set the value of the snapshot.mode property to schema_only . Edit the table.include.list to add the tables that you want to capture. Restart the connector. Wait for Debezium to capture the schema of the new and existing tables. Data changes that occurred any tables after the connector stopped are not captured. To ensure that no data is lost, initiate an incremental snapshot . Procedure 2: Initial snapshot, followed by optional incremental snapshot In this procedure the connector performs a full initial snapshot of the database. As with any initial snapshot, in a database with many large tables, running an initial snapshot can be a time-consuming operation. After the snapshot completes, you can optionally trigger an incremental snapshot to capture any changes that occur while the connector is off-line. Stop the connector. Remove the internal database schema history topic that is specified by the schema.history.internal.kafka.topic property . Clear the offsets in the configured Kafka Connect offset.storage.topic . For more information about how to remove offsets, see the Debezium community FAQ . Warning Removing offsets should be performed only by advanced users who have experience in manipulating internal Kafka Connect data. This operation is potentially destructive, and should be performed only as a last resort. Edit the table.include.list to add the tables that you want to capture. Set values for properties in the connector configuration as described in the following steps: Set the value of the snapshot.mode property to initial . (Optional) Set schema.history.internal.store.only.captured.tables.ddl to false . Restart the connector. The connector takes a full database snapshot. After the snapshot completes, the connector transitions to streaming. (Optional) To capture any data that changed while the connector was off-line, initiate an incremental snapshot . 2.1.2.2. Ad hoc snapshots By default, a connector runs an initial snapshot operation only after it starts for the first time. Following this initial snapshot, under normal circumstances, the connector does not repeat the snapshot process. Any future change event data that the connector captures comes in through the streaming process only. However, in some situations the data that the connector obtained during the initial snapshot might become stale, lost, or incomplete. To provide a mechanism for recapturing table data, Debezium includes an option to perform ad hoc snapshots. You might want to perform an ad hoc snapshot after any of the following changes occur in your Debezium environment: The connector configuration is modified to capture a different set of tables. Kafka topics are deleted and must be rebuilt. Data corruption occurs due to a configuration error or some other problem. You can re-run a snapshot for a table for which you previously captured a snapshot by initiating a so-called ad-hoc snapshot . Ad hoc snapshots require the use of signaling tables . You initiate an ad hoc snapshot by sending a signal request to the Debezium signaling table. When you initiate an ad hoc snapshot of an existing table, the connector appends content to the topic that already exists for the table. If a previously existing topic was removed, Debezium can create a topic automatically if automatic topic creation is enabled. Ad hoc snapshot signals specify the tables to include in the snapshot. The snapshot can capture the entire contents of the database, or capture only a subset of the tables in the database. Also, the snapshot can capture a subset of the contents of the table(s) in the database. You specify the tables to capture by sending an execute-snapshot message to the signaling table. Set the type of the execute-snapshot signal to incremental or blocking , and provide the names of the tables to include in the snapshot, as described in the following table: Table 2.2. Example of an ad hoc execute-snapshot signal record Field Default Value type incremental Specifies the type of snapshot that you want to run. Currently, you can request incremental or blocking snapshots. data-collections N/A An array that contains regular expressions matching the fully-qualified names of the tables to include in the snapshot. For the Db2 connector, use the following format to specify the fully qualified name of a table: schema.table . additional-conditions N/A An optional array that specifies a set of additional conditions that the connector evaluates to determine the subset of records to include in a snapshot. Each additional condition is an object that specifies the criteria for filtering the data that an ad hoc snapshot captures. You can set the following parameters for each additional condition: data-collection The fully-qualified name of the table that the filter applies to. You can apply different filters to each table. filter Specifies column values that must be present in a database record for the snapshot to include it, for example, "color='blue'" . The values that you assign to the filter parameter are the same types of values that you might specify in the WHERE clause of SELECT statements when you set the snapshot.select.statement.overrides property for a blocking snapshot. surrogate-key N/A An optional string that specifies the column name that the connector uses as the primary key of a table during the snapshot process. Triggering an ad hoc incremental snapshot You initiate an ad hoc incremental snapshot by adding an entry with the execute-snapshot signal type to the signaling table, or by sending a signal message to a Kafka signaling topic . After the connector processes the message, it begins the snapshot operation. The snapshot process reads the first and last primary key values and uses those values as the start and end point for each table. Based on the number of entries in the table, and the configured chunk size, Debezium divides the table into chunks, and proceeds to snapshot each chunk, in succession, one at a time. For more information, see Incremental snapshots . Triggering an ad hoc blocking snapshot You initiate an ad hoc blocking snapshot by adding an entry with the execute-snapshot signal type to the signaling table or signaling topic. After the connector processes the message, it begins the snapshot operation. The connector temporarily stops streaming, and then initiates a snapshot of the specified table, following the same process that it uses during an initial snapshot. After the snapshot completes, the connector resumes streaming. For more information, see Blocking snapshots . 2.1.2.3. Incremental snapshots To provide flexibility in managing snapshots, Debezium includes a supplementary snapshot mechanism, known as incremental snapshotting . Incremental snapshots rely on the Debezium mechanism for sending signals to a Debezium connector . In an incremental snapshot, instead of capturing the full state of a database all at once, as in an initial snapshot, Debezium captures each table in phases, in a series of configurable chunks. You can specify the tables that you want the snapshot to capture and the size of each chunk . The chunk size determines the number of rows that the snapshot collects during each fetch operation on the database. The default chunk size for incremental snapshots is 1024 rows. As an incremental snapshot proceeds, Debezium uses watermarks to track its progress, maintaining a record of each table row that it captures. This phased approach to capturing data provides the following advantages over the standard initial snapshot process: You can run incremental snapshots in parallel with streamed data capture, instead of postponing streaming until the snapshot completes. The connector continues to capture near real-time events from the change log throughout the snapshot process, and neither operation blocks the other. If the progress of an incremental snapshot is interrupted, you can resume it without losing any data. After the process resumes, the snapshot begins at the point where it stopped, rather than recapturing the table from the beginning. You can run an incremental snapshot on demand at any time, and repeat the process as needed to adapt to database updates. For example, you might re-run a snapshot after you modify the connector configuration to add a table to its table.include.list property. Incremental snapshot process When you run an incremental snapshot, Debezium sorts each table by primary key and then splits the table into chunks based on the configured chunk size . Working chunk by chunk, it then captures each table row in a chunk. For each row that it captures, the snapshot emits a READ event. That event represents the value of the row when the snapshot for the chunk began. As a snapshot proceeds, it's likely that other processes continue to access the database, potentially modifying table records. To reflect such changes, INSERT , UPDATE , or DELETE operations are committed to the transaction log as per usual. Similarly, the ongoing Debezium streaming process continues to detect these change events and emits corresponding change event records to Kafka. How Debezium resolves collisions among records with the same primary key In some cases, the UPDATE or DELETE events that the streaming process emits are received out of sequence. That is, the streaming process might emit an event that modifies a table row before the snapshot captures the chunk that contains the READ event for that row. When the snapshot eventually emits the corresponding READ event for the row, its value is already superseded. To ensure that incremental snapshot events that arrive out of sequence are processed in the correct logical order, Debezium employs a buffering scheme for resolving collisions. Only after collisions between the snapshot events and the streamed events are resolved does Debezium emit an event record to Kafka. Snapshot window To assist in resolving collisions between late-arriving READ events and streamed events that modify the same table row, Debezium employs a so-called snapshot window . The snapshot window demarcates the interval during which an incremental snapshot captures data for a specified table chunk. Before the snapshot window for a chunk opens, Debezium follows its usual behavior and emits events from the transaction log directly downstream to the target Kafka topic. But from the moment that the snapshot for a particular chunk opens, until it closes, Debezium performs a de-duplication step to resolve collisions between events that have the same primary key.. For each data collection, the Debezium emits two types of events, and stores the records for them both in a single destination Kafka topic. The snapshot records that it captures directly from a table are emitted as READ operations. Meanwhile, as users continue to update records in the data collection, and the transaction log is updated to reflect each commit, Debezium emits UPDATE or DELETE operations for each change. As the snapshot window opens, and Debezium begins processing a snapshot chunk, it delivers snapshot records to a memory buffer. During the snapshot windows, the primary keys of the READ events in the buffer are compared to the primary keys of the incoming streamed events. If no match is found, the streamed event record is sent directly to Kafka. If Debezium detects a match, it discards the buffered READ event, and writes the streamed record to the destination topic, because the streamed event logically supersede the static snapshot event. After the snapshot window for the chunk closes, the buffer contains only READ events for which no related transaction log events exist. Debezium emits these remaining READ events to the table's Kafka topic. The connector repeats the process for each snapshot chunk. Currently, you can use either of the following methods to initiate an incremental snapshot: Send an ad hoc snapshot signal to the signaling table on the source database . Send a message to a configured Kafka signaling topic . Warning The Debezium connector for Db2 does not support schema changes while an incremental snapshot is running. 2.1.2.3.1. Triggering an incremental snapshot To initiate an incremental snapshot, you can send an ad hoc snapshot signal to the signaling table on the source database. You submit snapshot signals as SQL INSERT queries. After Debezium detects the change in the signaling table, it reads the signal, and runs the requested snapshot operation. The query that you submit specifies the tables to include in the snapshot, and, optionally, specifies the type of snapshot operation. Debezium currently supports the incremental and blocking snapshot types. To specify the tables to include in the snapshot, provide a data-collections array that lists the tables, or an array of regular expressions used to match tables, for example, {"data-collections": ["public.MyFirstTable", "public.MySecondTable"]} The data-collections array for an incremental snapshot signal has no default value. If the data-collections array is empty, Debezium interprets the empty array to mean that no action is required, and it does not perform a snapshot. Note If the name of a table that you want to include in a snapshot contains a dot ( . ), a space, or some other non-alphanumeric character, you must escape the table name in double quotes. For example, to include a table that exists in the public schema and that has the name My.Table , use the following format: "public.\"My.Table\"" . Prerequisites Signaling is enabled . A signaling data collection exists on the source database. The signaling data collection is specified in the signal.data.collection property. Using a source signaling channel to trigger an incremental snapshot Send a SQL query to add the ad hoc incremental snapshot request to the signaling table: INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}'); For example, INSERT INTO myschema.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'execute-snapshot', 3 '{"data-collections": ["schema1.table1", "schema1.table2"], 4 "type":"incremental", 5 "additional-conditions":[{"data-collection": "schema1.table1" ,"filter":"color=\'blue\'"}]}'); 6 The values of the id , type , and data parameters in the command correspond to the fields of the signaling table . The following table describes the parameters in the example: Table 2.3. Descriptions of fields in a SQL command for sending an incremental snapshot signal to the signaling table Item Value Description 1 schema.debezium_signal Specifies the fully-qualified name of the signaling table on the source database. 2 ad-hoc-1 The id parameter specifies an arbitrary string that is assigned as the id identifier for the signal request. Use this string to identify logging messages to entries in the signaling table. Debezium does not use this string. Rather, during the snapshot, Debezium generates its own id string as a watermarking signal. 3 execute-snapshot The type parameter specifies the operation that the signal is intended to trigger. 4 data-collections A required component of the data field of a signal that specifies an array of table names or regular expressions to match table names to include in the snapshot. The array lists regular expressions that use the format schema.table to match the fully-qualified names of the tables. This format is the same as the one that you use to specify the name of the connector's signaling table . 5 incremental An optional type component of the data field of a signal that specifies the type of snapshot operation to run. Valid values are incremental and blocking . If you do not specify a value, the connector defaults to performing an incremental snapshot. 6 additional-conditions An optional array that specifies a set of additional conditions that the connector evaluates to determine the subset of records to include in a snapshot. Each additional condition is an object with data-collection and filter properties. You can specify different filters for each data collection. * The data-collection property is the fully-qualified name of the data collection that the filter applies to. For more information about the additional-conditions parameter, see Section 2.1.2.3.2, "Running an ad hoc incremental snapshots with additional-conditions " . 2.1.2.3.2. Running an ad hoc incremental snapshots with additional-conditions If you want a snapshot to include only a subset of the content in a table, you can modify the signal request by appending an additional-conditions parameter to the snapshot signal. The SQL query for a typical snapshot takes the following form: SELECT * FROM <tableName> .... By adding an additional-conditions parameter, you append a WHERE condition to the SQL query, as in the following example: SELECT * FROM <data-collection> WHERE <filter> .... The following example shows a SQL query to send an ad hoc incremental snapshot request with an additional condition to the signaling table: INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}'); For example, suppose you have a products table that contains the following columns: id (primary key) color quantity If you want an incremental snapshot of the products table to include only the data items where color=blue , you can use the following SQL statement to trigger the snapshot: INSERT INTO myschema.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["schema1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "schema1.products", "filter": "color=blue"}]}'); The additional-conditions parameter also enables you to pass conditions that are based on more than one column. For example, using the products table from the example, you can submit a query that triggers an incremental snapshot that includes the data of only those items for which color=blue and quantity>10 : INSERT INTO myschema.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["schema1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "schema1.products", "filter": "color=blue AND quantity>10"}]}'); The following example, shows the JSON for an incremental snapshot event that is captured by a connector. Example 2.1. Incremental snapshot event message { "before":null, "after": { "pk":"1", "value":"New data" }, "source": { ... "snapshot":"incremental" 1 }, "op":"r", 2 "ts_ms":"1620393591654", "ts_us":"1620393591654547", "ts_ns":"1620393591654547920", "transaction":null } Table 2.4. Description of fields in an incremental snapshot event message Item Field name Description 1 snapshot Specifies the type of snapshot operation to run. Currently, the only valid options are blocking and incremental . Specifying a type value in the SQL query that you submit to the signaling table is optional. If you do not specify a value, the connector runs an incremental snapshot. 2 op Specifies the event type. The value for snapshot events is r , signifying a READ operation. 2.1.2.3.3. Using the Kafka signaling channel to trigger an incremental snapshot You can send a message to the configured Kafka topic to request the connector to run an ad hoc incremental snapshot. The key of the Kafka message must match the value of the topic.prefix connector configuration option. The value of the message is a JSON object with type and data fields. The signal type is execute-snapshot , and the data field must have the following fields: Table 2.5. Execute snapshot data fields Field Default Value type incremental The type of the snapshot to be executed. Currently Debezium supports the incremental and blocking types. See the section for more details. data-collections N/A An array of comma-separated regular expressions that match the fully-qualified names of tables to include in the snapshot. Specify the names by using the same format as is required for the signal.data.collection configuration option. additional-conditions N/A An optional array of additional conditions that specifies criteria that the connector evaluates to designate a subset of records to include in a snapshot. Each additional condition is an object that specifies the criteria for filtering the data that an ad hoc snapshot captures. You can set the following parameters for each additional condition: data-collection :: The fully-qualified name of the table that the filter applies to. You can apply different filters to each table. filter :: Specifies column values that must be present in a database record for the snapshot to include it, for example, "color='blue'" . The values that you assign to the filter parameter are the same types of values that you might specify in the WHERE clause of SELECT statements when you set the snapshot.select.statement.overrides property for a blocking snapshot. Example 2.2. An execute-snapshot Kafka message Ad hoc incremental snapshots with additional-conditions Debezium uses the additional-conditions field to select a subset of a table's content. Typically, when Debezium runs a snapshot, it runs a SQL query such as: SELECT * FROM <tableName> ... . When the snapshot request includes an additional-conditions property, the data-collection and filter parameters of the property are appended to the SQL query, for example: SELECT * FROM <data-collection> WHERE <filter> ... . For example, given a products table with the columns id (primary key), color , and brand , if you want a snapshot to include only content for which color='blue' , when you request the snapshot, you could add the additional-conditions property to filter the content: Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["schema1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "schema1.products" ,"filter":"color='blue'"}]}}` You can also use the additional-conditions property to pass conditions based on multiple columns. For example, using the same products table as in the example, if you want a snapshot to include only the content from the products table for which color='blue' , and brand='MyBrand' , you could send the following request: Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["schema1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "schema1.products" ,"filter":"color='blue' AND brand='MyBrand'"}]}}` 2.1.2.3.4. Stopping an incremental snapshot In some situations, it might be necessary to stop an incremental snapshot. For example, you might realize that snapshot was not configured correctly, or maybe you want to ensure that resources are available for other database operations. You can stop a snapshot that is already running by sending a signal to the signaling table on the source database. You submit a stop snapshot signal to the signaling table by sending it in a SQL INSERT query. The stop-snapshot signal specifies the type of the snapshot operation as incremental , and optionally specifies the tables that you want to omit from the currently running snapshot. After Debezium detects the change in the signaling table, it reads the signal, and stops the incremental snapshot operation if it's in progress. Additional resources You can also stop an incremental snapshot by sending a JSON message to the Kafka signaling topic . Prerequisites Signaling is enabled . A signaling data collection exists on the source database. The signaling data collection is specified in the signal.data.collection property. Using a source signaling channel to stop an incremental snapshot Send a SQL query to stop the ad hoc incremental snapshot to the signaling table: INSERT INTO <signalTable> (id, type, data) values ( '<id>' , 'stop-snapshot', '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":"incremental"}'); For example, INSERT INTO myschema.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'stop-snapshot', 3 '{"data-collections": ["schema1.table1", "schema1.table2"], 4 "type":"incremental"}'); 5 The values of the id , type , and data parameters in the signal command correspond to the fields of the signaling table . The following table describes the parameters in the example: Table 2.6. Descriptions of fields in a SQL command for sending a stop incremental snapshot signal to the signaling table Item Value Description 1 schema.debezium_signal Specifies the fully-qualified name of the signaling table on the source database. 2 ad-hoc-1 The id parameter specifies an arbitrary string that is assigned as the id identifier for the signal request. Use this string to identify logging messages to entries in the signaling table. Debezium does not use this string. 3 stop-snapshot Specifies type parameter specifies the operation that the signal is intended to trigger. 4 data-collections An optional component of the data field of a signal that specifies an array of table names or regular expressions to match table names to remove from the snapshot. The array lists regular expressions which match tables by their fully-qualified names in the format schema.table If you omit this component from the data field, the signal stops the entire incremental snapshot that is in progress. 5 incremental A required component of the data field of a signal that specifies the type of snapshot operation that is to be stopped. Currently, the only valid option is incremental . If you do not specify a type value, the signal fails to stop the incremental snapshot. 2.1.2.3.5. Using the Kafka signaling channel to stop an incremental snapshot You can send a signal message to the configured Kafka signaling topic to stop an ad hoc incremental snapshot. The key of the Kafka message must match the value of the topic.prefix connector configuration option. The value of the message is a JSON object with type and data fields. The signal type is stop-snapshot , and the data field must have the following fields: Table 2.7. Execute snapshot data fields Field Default Value type incremental The type of the snapshot to be executed. Currently Debezium supports only the incremental type. See the section for more details. data-collections N/A An optional array of comma-separated regular expressions that match the fully-qualified names of the tables an array of table names or regular expressions to match table names to remove from the snapshot. Specify table names by using the format schema.table . The following example shows a typical stop-snapshot Kafka message: Key = `test_connector` Value = `{"type":"stop-snapshot","data": {"data-collections": ["schema1.table1", "schema1.table2"], "type": "INCREMENTAL"}}` 2.1.2.4. Blocking snapshots To provide more flexibility in managing snapshots, Debezium includes a supplementary ad hoc snapshot mechanism, known as a blocking snapshot . Blocking snapshots rely on the Debezium mechanism for sending signals to a Debezium connector . A blocking snapshot behaves just like an initial snapshot , except that you can trigger it at run time. You might want to run a blocking snapshot rather than use the standard initial snapshot process in the following situations: You add a new table and you want to complete the snapshot while the connector is running. You add a large table, and you want the snapshot to complete in less time than is possible with an incremental snapshot. Blocking snapshot process When you run a blocking snapshot, Debezium stops streaming, and then initiates a snapshot of the specified table, following the same process that it uses during an initial snapshot. After the snapshot completes, the streaming is resumed. Configure snapshot You can set the following properties in the data component of a signal: data-collections: to specify which tables must be snapshot additional-conditions: You can specify different filters for different table. The data-collection property is the fully-qualified name of the table for which the filter will be applied. The filter property will have the same value used in the snapshot.select.statement.overrides For example: {"type": "blocking", "data-collections": ["schema1.table1", "schema1.table2"], "additional-conditions": [{"data-collection": "schema1.table1", "filter": "SELECT * FROM [schema1].[table1] WHERE column1 = 0 ORDER BY column2 DESC"}, {"data-collection": "schema1.table2", "filter": "SELECT * FROM [schema1].[table2] WHERE column2 > 0"}]} Possible duplicates A delay might exist between the time that you send the signal to trigger the snapshot, and the time when streaming stops and the snapshot starts. As a result of this delay, after the snapshot completes, the connector might emit some event records that duplicate records captured by the snapshot. 2.1.2.5. How Debezium Db2 connectors read change-data tables After a complete snapshot, when a Debezium Db2 connector starts for the first time, the connector identifies the change-data table for each source table that is in capture mode. The connector does the following for each change-data table: Reads change events that were created between the last stored, highest LSN and the current, highest LSN. Orders the change events according to the commit LSN and the change LSN for each event. This ensures that the connector emits the change events in the order in which the table changes occurred. Passes commit and change LSNs as offsets to Kafka Connect. Stores the highest LSN that the connector passed to Kafka Connect. After a restart, the connector resumes emitting change events from the offset (commit and change LSNs) where it left off. While the connector is running and emitting change events, if you remove a table from capture mode or add a table to capture mode, the connector detects the change, and modifies its behavior accordingly. 2.1.2.6. Default names of Kafka topics that receive Debezium Db2 change event records By default, the Db2 connector writes change events for all of the INSERT , UPDATE , and DELETE operations that occur in a table to a single Apache Kafka topic that is specific to that table. The connector uses the following convention to name change event topics: topicPrefix . schemaName . tableName The following list provides definitions for the components of the default name: topicPrefix The topic prefix as specified by the topic.prefix connector configuration property. schemaName The name of the schema in which the operation occurred. tableName The name of the table in which the operation occurred. For example, consider a Db2 installation with the mydatabase database, which contains four tables: PRODUCTS , PRODUCTS_ON_HAND , CUSTOMERS , and ORDERS that are in the MYSCHEMA schema. The connector would emit events to these four Kafka topics: mydatabase.MYSCHEMA.PRODUCTS mydatabase.MYSCHEMA.PRODUCTS_ON_HAND mydatabase.MYSCHEMA.CUSTOMERS mydatabase.MYSCHEMA.ORDERS The connector applies similar naming conventions to label its internal database schema history topics, schema change topics , and transaction metadata topics . If the default topic name do not meet your requirements, you can configure custom topic names. To configure custom topic names, you specify regular expressions in the logical topic routing SMT. For more information about using the logical topic routing SMT to customize topic naming, see Topic routing . 2.1.2.7. How Debezium Db2 connectors handle database schema changes When a database client queries a database, the client uses the database's current schema. However, the database schema can be changed at any time, which means that the connector must be able to identify what the schema was at the time each insert, update, or delete operation was recorded. Also, a connector cannot necessarily apply the current schema to every event. If an event is relatively old, it's possible that it was recorded before the current schema was applied. To ensure correct processing of events that occur after a schema change, the Debezium Db2 connector stores a snapshot of the new schema based on the structures of the Db2 change data tables, which mirror the structures of their associated data tables. The connector stores the table schema information, together with the LSN of operations the result in schema changes, in the database schema history Kafka topic. The connector uses the stored schema representation to produce change events that correctly mirror the structure of tables at the time of each insert, update, or delete operation. When the connector restarts after either a crash or a graceful stop, it resumes reading entries in the Db2 change data tables from the last position that it read. Based on the schema information that the connector reads from the database schema history topic, the connector applies the table structures that existed at the position where the connector restarts. If you update the schema of a Db2 table that is in capture mode, it's important that you also update the schema of the corresponding change table. You must be a Db2 database administrator with elevated privileges to update database schema. For more information about how to update Db2 database schema in Debezium environments, see Schema history eveolution . The database schema history topic is for internal connector use only. Optionally, the connector can also emit schema change events to a different topic that is intended for consumer applications . Additional resources Default names for topics that receive Debezium event records. 2.1.2.8. About the Debezium Db2 connector schema change topic You can configure a Debezium Db2 connector to produce schema change events that describe schema changes that are applied to tables in the database. Debezium emits a message to the schema change topic when: A new table goes into capture mode. A table is removed from capture mode. During a database schema update , there is a change in the schema for a table that is in capture mode. The connector writes schema change events to a Kafka schema change topic that has the name <topicPrefix> where <topicPrefix> is the topic prefix that is specified in the topic.prefix connector configuration property. The schema for the schema change event has the following elements: name The name of the schema change event message. type The type of the change event message. version The version of the schema. The version is an integer that is incremented each time the schema is changed. fields The fields that are included in the change event message. Example: Schema of the Db2 connector schema change topic The following example shows a typical schema in JSON format. { "schema": { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "databaseName" } ], "optional": false, "name": "io.debezium.connector.db2.SchemaChangeKey", "version": 1 }, "payload": { "databaseName": "inventory" } } Messages that the connector sends to the schema change topic contain a payload that includes the following elements: databaseName The name of the database to which the statements are applied. The value of databaseName serves as the message key. pos The position in the transaction log where the statements appear. tableChanges A structured representation of the entire table schema after the schema change. The tableChanges field contains an array that includes entries for each column of the table. Because the structured representation presents data in JSON or Avro format, consumers can easily read messages without first processing them through a DDL parser. Important For a table that is in capture mode, the connector not only stores the history of schema changes in the schema change topic, but also in an internal database schema history topic. The internal database schema history topic is for connector use only and it is not intended for direct use by consuming applications. Ensure that applications that require notifications about schema changes consume that information only from the schema change topic. Important Never partition the database schema history topic. For the database schema history topic to function correctly, it must maintain a consistent, global order of the event records that the connector emits to it. To ensure that the topic is not split among partitions, set the partition count for the topic by using one of the following methods: If you create the database schema history topic manually, specify a partition count of 1 . If you use the Apache Kafka broker to create the database schema history topic automatically, the topic is created, set the value of the Kafka num.partitions configuration option to 1 . Warning The format of messages that a connector emits to its schema change topic is in an incubating state and can change without notice. Example: Message emitted to the Db2 connector schema change topic The following example shows a message in the schema change topic. The message contains a logical representation of the table schema. { "schema": { ... }, "payload": { "source": { "version": "2.7.3.Final", "connector": "db2", "name": "db2", "ts_ms": 0, "snapshot": "true", "db": "testdb", "schema": "DB2INST1", "table": "CUSTOMERS", "change_lsn": null, "commit_lsn": "00000025:00000d98:00a2", "event_serial_no": null }, "ts_ms": 1588252618953, 1 "databaseName": "TESTDB", 2 "schemaName": "DB2INST1", "ddl": null, 3 "tableChanges": [ 4 { "type": "CREATE", 5 "id": "\"DB2INST1\".\"CUSTOMERS\"", 6 "table": { 7 "defaultCharsetName": null, "primaryKeyColumnNames": [ 8 "ID" ], "columns": [ 9 { "name": "ID", "jdbcType": 4, "nativeType": null, "typeName": "int identity", "typeExpression": "int identity", "charsetName": null, "length": 10, "scale": 0, "position": 1, "optional": false, "autoIncremented": false, "generated": false }, { "name": "FIRST_NAME", "jdbcType": 12, "nativeType": null, "typeName": "varchar", "typeExpression": "varchar", "charsetName": null, "length": 255, "scale": null, "position": 2, "optional": false, "autoIncremented": false, "generated": false }, { "name": "LAST_NAME", "jdbcType": 12, "nativeType": null, "typeName": "varchar", "typeExpression": "varchar", "charsetName": null, "length": 255, "scale": null, "position": 3, "optional": false, "autoIncremented": false, "generated": false }, { "name": "EMAIL", "jdbcType": 12, "nativeType": null, "typeName": "varchar", "typeExpression": "varchar", "charsetName": null, "length": 255, "scale": null, "position": 4, "optional": false, "autoIncremented": false, "generated": false } ], "attributes": [ 10 { "customAttribute": "attributeValue" } ] } } ] } } Table 2.8. Descriptions of fields in messages emitted to the schema change topic Item Field name Description 1 ts_ms Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms, you can determine the lag between the source database update and Debezium. 2 databaseName schemaName Identifies the database and the schema that contain the change. 3 ddl Always null for the Db2 connector. For other connectors, this field contains the DDL responsible for the schema change. This DDL is not available to Db2 connectors. 4 tableChanges An array of one or more items that contain the schema changes generated by a DDL command. 5 type Describes the kind of change. The value is one of the following: CREATE - table created ALTER - table modified DROP - table deleted 6 id Full identifier of the table that was created, altered, or dropped. 7 table Represents table metadata after the applied change. 8 primaryKeyColumnNames List of columns that compose the table's primary key. 9 columns Metadata for each column in the changed table. 10 attributes Custom attribute metadata for each table change. In messages that the connector sends to the schema change topic, the message key is the name of the database that contains the schema change. In the following example, the payload field contains the key: { "schema": { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "databaseName" } ], "optional": false, "name": "io.debezium.connector.db2.SchemaChangeKey", "version": 1 }, "payload": { "databaseName": "TESTDB" } } 2.1.2.9. Debezium Db2 connector-generated events that represent transaction boundaries Debezium can generate events that represent transaction boundaries and that enrich change data event messages. Limits on when Debezium receives transaction metadata Debezium registers and receives metadata only for transactions that occur after you deploy the connector. Metadata for transactions that occur before you deploy the connector is not available. Debezium generates transaction boundary events for the BEGIN and END delimiters in every transaction. Transaction boundary events contain the following fields: status BEGIN or END . id String representation of the unique transaction identifier. ts_ms The time of a transaction boundary event ( BEGIN or END event) at the data source. If the data source does not provide Debezium with the event time, then the field instead represents the time at which Debezium processes the event. event_count (for END events) Total number of events emmitted by the transaction. data_collections (for END events) An array of pairs of data_collection and event_count elements that indicates the number of events that the connector emits for changes that originate from a data collection. Example { "status": "BEGIN", "id": "00000025:00000d08:0025", "ts_ms": 1486500577125, "event_count": null, "data_collections": null } { "status": "END", "id": "00000025:00000d08:0025", "ts_ms": 1486500577691, "event_count": 2, "data_collections": [ { "data_collection": "testDB.dbo.tablea", "event_count": 1 }, { "data_collection": "testDB.dbo.tableb", "event_count": 1 } ] } Unless overridden via the topic.transaction option, the connector emits transaction events to the <topic.prefix> .transaction topic. Data change event enrichment When transaction metadata is enabled the connector enriches the change event Envelope with a new transaction field. This field provides information about every event in the form of a composite of fields: id String representation of unique transaction identifier. total_order The absolute position of the event among all events generated by the transaction. data_collection_order The per-data collection position of the event among all events that were emitted by the transaction. Following is an example of a message: { "before": null, "after": { "pk": "2", "aa": "1" }, "source": { ... }, "op": "c", "ts_ms": "1580390884335", "ts_us": "1580390884335875", "ts_ns": "1580390884335875412", "transaction": { "id": "00000025:00000d08:0025", "total_order": "1", "data_collection_order": "1" } } 2.1.3. Descriptions of Debezium Db2 connector data change events The Debezium Db2 connector generates a data change event for each row-level INSERT , UPDATE , and DELETE operation. Each event contains a key and a value. The structure of the key and the value depends on the table that was changed. Debezium and Kafka Connect are designed around continuous streams of event messages . However, the structure of these events may change over time, which can be difficult for consumers to handle. To address this, each event contains the schema for its content or, if you are using a schema registry, a schema ID that a consumer can use to obtain the schema from the registry. This makes each event self-contained. The following skeleton JSON shows the basic four parts of a change event. However, how you configure the Kafka Connect converter that you choose to use in your application determines the representation of these four parts in change events. A schema field is in a change event only when you configure the converter to produce it. Likewise, the event key and event payload are in a change event only if you configure a converter to produce it. If you use the JSON converter and you configure it to produce all four basic change event parts, change events have this structure: { "schema": { 1 ... }, "payload": { 2 ... }, "schema": { 3 ... }, "payload": { 4 ... }, } Table 2.9. Overview of change event basic content Item Field name Description 1 schema The first schema field is part of the event key. It specifies a Kafka Connect schema that describes what is in the event key's payload portion. In other words, the first schema field describes the structure of the primary key, or the unique key if the table does not have a primary key, for the table that was changed. It is possible to override the table's primary key by setting the message.key.columns connector configuration property . In this case, the first schema field describes the structure of the key identified by that property. 2 payload The first payload field is part of the event key. It has the structure described by the schema field and it contains the key for the row that was changed. 3 schema The second schema field is part of the event value. It specifies the Kafka Connect schema that describes what is in the event value's payload portion. In other words, the second schema describes the structure of the row that was changed. Typically, this schema contains nested schemas. 4 payload The second payload field is part of the event value. It has the structure described by the schema field and it contains the actual data for the row that was changed. By default, the connector streams change event records to topics with names that are the same as the event's originating table. For more information, see topic names . Warning The Debezium Db2 connector ensures that all Kafka Connect schema names adhere to the Avro schema name format . This means that the logical server name must start with a Latin letter or an underscore, that is, a-z, A-Z, or _. Each remaining character in the logical server name and each character in the database and table names must be a Latin letter, a digit, or an underscore, that is, a-z, A-Z, 0-9, or \_. If there is an invalid character it is replaced with an underscore character. This can lead to unexpected conflicts if the logical server name, a database name, or a table name contains invalid characters, and the only characters that distinguish names from one another are invalid and thus replaced with underscores. Also, Db2 names for databases, schemas, and tables can be case sensitive. This means that the connector could emit event records for more than one table to the same Kafka topic. Details are in the following topics: Section 2.1.3.1, "About keys in Debezium db2 change events" Section 2.1.3.2, "About values in Debezium Db2 change events" 2.1.3.1. About keys in Debezium db2 change events A change event's key contains the schema for the changed table's key and the changed row's actual key. Both the schema and its corresponding payload contain a field for each column in the changed table's PRIMARY KEY (or unique constraint) at the time the connector created the event. Consider the following customers table, which is followed by an example of a change event key for this table. Example table CREATE TABLE customers ( ID INTEGER IDENTITY(1001,1) NOT NULL PRIMARY KEY, FIRST_NAME VARCHAR(255) NOT NULL, LAST_NAME VARCHAR(255) NOT NULL, EMAIL VARCHAR(255) NOT NULL UNIQUE ); Example change event key Every change event that captures a change to the customers table has the same event key schema. For as long as the customers table has the definition, every change event that captures a change to the customers table has the following key structure. In JSON, it looks like this: { "schema": { 1 "type": "struct", "fields": [ 2 { "type": "int32", "optional": false, "field": "ID" } ], "optional": false, 3 "name": "mydatabase.MYSCHEMA.CUSTOMERS.Key" 4 }, "payload": { 5 "ID": 1004 } } Table 2.10. Description of change event key Item Field name Description 1 schema The schema portion of the key specifies a Kafka Connect schema that describes what is in the key's payload portion. 2 fields Specifies each field that is expected in the payload , including each field's name, type, and whether it is required. 3 optional Indicates whether the event key must contain a value in its payload field. In this example, a value in the key's payload is required. A value in the key's payload field is optional when a table does not have a primary key. 4 mydatabase.MYSCHEMA.CUSTOMERS.Key Name of the schema that defines the structure of the key's payload. This schema describes the structure of the primary key for the table that was changed. Key schema names have the format connector-name . database-name . table-name . Key . In this example: mydatabase is the name of the connector that generated this event. MYSCHEMA is the database schema that contains the table that was changed. CUSTOMERS is the table that was updated. 5 payload Contains the key for the row for which this change event was generated. In this example, the key, contains a single ID field whose value is 1004 . 2.1.3.2. About values in Debezium Db2 change events The value in a change event is a bit more complicated than the key. Like the key, the value has a schema section and a payload section. The schema section contains the schema that describes the Envelope structure of the payload section, including its nested fields. Change events for operations that create, update or delete data all have a value payload with an envelope structure. Consider the same sample table that was used to show an example of a change event key: Example table CREATE TABLE customers ( ID INTEGER IDENTITY(1001,1) NOT NULL PRIMARY KEY, FIRST_NAME VARCHAR(255) NOT NULL, LAST_NAME VARCHAR(255) NOT NULL, EMAIL VARCHAR(255) NOT NULL UNIQUE ); The event value portion of every change event for the customers table specifies the same schema. The event value's payload varies according to the event type: create events update events delete events create events The following example shows the value portion of a change event that the connector generates for an operation that creates data in the customers table: { "schema": { 1 "type": "struct", "fields": [ { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "ID" }, { "type": "string", "optional": false, "field": "FIRST_NAME" }, { "type": "string", "optional": false, "field": "LAST_NAME" }, { "type": "string", "optional": false, "field": "EMAIL" } ], "optional": true, "name": "mydatabase.MYSCHEMA.CUSTOMERS.Value", 2 "field": "before" }, { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "ID" }, { "type": "string", "optional": false, "field": "FIRST_NAME" }, { "type": "string", "optional": false, "field": "LAST_NAME" }, { "type": "string", "optional": false, "field": "EMAIL" } ], "optional": true, "name": "mydatabase.MYSCHEMA.CUSTOMERS.Value", "field": "after" }, { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "version" }, { "type": "string", "optional": false, "field": "connector" }, { "type": "string", "optional": false, "field": "name" }, { "type": "int64", "optional": false, "field": "ts_ms" }, { "type": "int64", "optional": false, "field": "ts_us" }, { "type": "int64", "optional": false, "field": "ts_ns" }, { "type": "boolean", "optional": true, "default": false, "field": "snapshot" }, { "type": "string", "optional": false, "field": "db" }, { "type": "string", "optional": false, "field": "schema" }, { "type": "string", "optional": false, "field": "table" }, { "type": "string", "optional": true, "field": "change_lsn" }, { "type": "string", "optional": true, "field": "commit_lsn" }, ], "optional": false, "name": "io.debezium.connector.db2.Source", 3 "field": "source" }, { "type": "string", "optional": false, "field": "op" }, { "type": "int64", "optional": true, "field": "ts_ms" }, { "type": "int64", "optional": true, "field": "ts_us" }, { "type": "int64", "optional": true, "field": "ts_ns" } ], "optional": false, "name": "mydatabase.MYSCHEMA.CUSTOMERS.Envelope" 4 }, "payload": { 5 "before": null, 6 "after": { 7 "ID": 1005, "FIRST_NAME": "john", "LAST_NAME": "doe", "EMAIL": "john.doe@example.org" }, "source": { 8 "version": "2.7.3.Final", "connector": "db2", "name": "myconnector", "ts_ms": 1559729468470, "ts_us": 1559729468470476, "ts_ns": 1559729468470476000, "snapshot": false, "db": "mydatabase", "schema": "MYSCHEMA", "table": "CUSTOMERS", "change_lsn": "00000027:00000758:0003", "commit_lsn": "00000027:00000758:0005", }, "op": "c", 9 "ts_ms": 1559729471739, 10 "ts_us": 1559729471739762, 11 "ts_ns": 1559729471739762314 12 } } Table 2.11. Descriptions of create event value fields Item Field name Description 1 schema The value's schema, which describes the structure of the value's payload. A change event's value schema is the same in every change event that the connector generates for a particular table. 2 name In the schema section, each name field specifies the schema for a field in the value's payload. mydatabase.MYSCHEMA.CUSTOMERS.Value is the schema for the payload's before and after fields. This schema is specific to the customers table. The connector uses this schema for all rows in the MYSCHEMA.CUSTOMERS table. Names of schemas for before and after fields are of the form logicalName . schemaName . tableName .Value , which ensures that the schema name is unique in the database. This means that when using the Avro converter , the resulting Avro schema for each table in each logical source has its own evolution and history. 3 name io.debezium.connector.db2.Source is the schema for the payload's source field. This schema is specific to the Db2 connector. The connector uses it for all events that it generates. 4 name mydatabase.MYSCHEMA.CUSTOMERS.Envelope is the schema for the overall structure of the payload, where mydatabase is the database, MYSCHEMA is the schema, and CUSTOMERS is the table. 5 payload The value's actual data. This is the information that the change event is providing. It may appear that JSON representations of events are much larger than the rows they describe. This is because a JSON representation must include the schema portion and the payload portion of the message. However, by using the Avro converter , you can significantly decrease the size of the messages that the connector streams to Kafka topics. 6 before An optional field that specifies the state of the row before the event occurred. When the op field is c for create, as it is in this example, the before field is null since this change event is for new content. 7 after An optional field that specifies the state of the row after the event occurred. In this example, the after field contains the values of the new row's ID , FIRST_NAME , LAST_NAME , and EMAIL columns. 8 source Mandatory field that describes the source metadata for the event. The source structure shows Db2 information about this change, which provides traceability. It also has information you can use to compare to other events in the same topic or in other topics to know whether this event occurred before, after, or as part of the same commit as other events. The source metadata includes: Debezium version Connector type and name Timestamp for when the change was made in the database Whether the event is part of an ongoing snapshot Name of the database, schema, and table that contain the new row Change LSN Commit LSN (omitted if this event is part of a snapshot) 9 op Mandatory string that describes the type of operation that caused the connector to generate the event. In this example, c indicates that the operation created a row. Valid values are: c = create u = update d = delete r = read (applies to only snapshots) 10 ts_ms , ts_us , ts_ns Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. update events The value of a change event for an update in the sample customers table has the same schema as a create event for that table. Likewise, the update event value's payload has the same structure. However, the event value payload contains different values in an update event. Here is an example of a change event value in an event that the connector generates for an update in the customers table: { "schema": { ... }, "payload": { "before": { 1 "ID": 1005, "FIRST_NAME": "john", "LAST_NAME": "doe", "EMAIL": "john.doe@example.org" }, "after": { 2 "ID": 1005, "FIRST_NAME": "john", "LAST_NAME": "doe", "EMAIL": "noreply@example.org" }, "source": { 3 "version": "2.7.3.Final", "connector": "db2", "name": "myconnector", "ts_ms": 1559729995937, "ts_us": 1559729995937497, "ts_ns": 1559729995937497000, "snapshot": false, "db": "mydatabase", "schema": "MYSCHEMA", "table": "CUSTOMERS", "change_lsn": "00000027:00000ac0:0002", "commit_lsn": "00000027:00000ac0:0007", }, "op": "u", 4 "ts_ms": 1559729998706, 5 "ts_us": 1559729998706647, 6 "ts_ns": 1559729998706647825 7 } } Table 2.12. Descriptions of update event value fields Item Field name Description 1 before An optional field that specifies the state of the row before the event occurred. In an update event value, the before field contains a field for each table column and the value that was in that column before the database commit. In this example, note that the EMAIL value is john.doe@example.com . 2 after An optional field that specifies the state of the row after the event occurred. You can compare the before and after structures to determine what the update to this row was. In the example, the EMAIL value is now noreply@example.com . 3 source Mandatory field that describes the source metadata for the event. The source field structure contains the same fields as in a create event, but some values are different, for example, the sample update event has different LSNs. You can use this information to compare this event to other events to know whether this event occurred before, after, or as part of the same commit as other events. The source metadata includes: Debezium version Connector type and name Timestamp for when the change was made in the database Whether the event is part of an ongoing snapshot Name of the database, schema, and table that contain the new row Change LSN Commit LSN (omitted if this event is part of a snapshot) 4 op Mandatory string that describes the type of operation. In an update event value, the op field value is u , signifying that this row changed because of an update. 5 ts_ms , ts_us , ts_ns Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. Note Updating the columns for a row's primary/unique key changes the value of the row's key. When a key changes, Debezium outputs three events: a DELETE event and a tombstone event with the old key for the row, followed by an event with the new key for the row. delete events The value in a delete change event has the same schema portion as create and update events for the same table. The event value payload in a delete event for the sample customers table looks like this: { "schema": { ... }, }, "payload": { "before": { 1 "ID": 1005, "FIRST_NAME": "john", "LAST_NAME": "doe", "EMAIL": "noreply@example.org" }, "after": null, 2 "source": { 3 "version": "2.7.3.Final", "connector": "db2", "name": "myconnector", "ts_ms": 1559730445243, "ts_us": 1559730445243482, "ts_ns": 1559730445243482000, "snapshot": false, "db": "mydatabase", "schema": "MYSCHEMA", "table": "CUSTOMERS", "change_lsn": "00000027:00000db0:0005", "commit_lsn": "00000027:00000db0:0007" }, "op": "d", 4 "ts_ms": 1559730450205, 5 "ts_us": 1559730450205521, 6 "ts_ns": 1559730450205521475 7 } } Table 2.13. Descriptions of delete event value fields Item Field name Description 1 before Optional field that specifies the state of the row before the event occurred. In a delete event value, the before field contains the values that were in the row before it was deleted with the database commit. 2 after Optional field that specifies the state of the row after the event occurred. In a delete event value, the after field is null , signifying that the row no longer exists. 3 source Mandatory field that describes the source metadata for the event. In a delete event value, the source field structure is the same as for create and update events for the same table. Many source field values are also the same. In a delete event value, the ts_ms and LSN field values, as well as other values, might have changed. But the source field in a delete event value provides the same metadata: Debezium version Connector type and name Timestamp for when the change was made in the database Whether the event is part of an ongoing snapshot Name of the database, schema, and table that contain the new row Change LSN Commit LSN (omitted if this event is part of a snapshot) 4 op Mandatory string that describes the type of operation. The op field value is d , signifying that this row was deleted. 5 ts_ms , ts_us , ts_ns Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. A delete change event record provides a consumer with the information it needs to process the removal of this row. The old values are included because some consumers might require them in order to properly handle the removal. Db2 connector events are designed to work with Kafka log compaction . Log compaction enables removal of some older messages as long as at least the most recent message for every key is kept. This lets Kafka reclaim storage space while ensuring that the topic contains a complete data set and can be used for reloading key-based state. When a row is deleted, the delete event value still works with log compaction, because Kafka can remove all earlier messages that have that same key. However, for Kafka to remove all messages that have that same key, the message value must be null . To make this possible, after Debezium's Db2 connector emits a delete event, the connector emits a special tombstone event that has the same key but a null value. 2.1.4. How Debezium Db2 connectors map data types For a complete description of the data types that Db2 supports, see Data Types in the Db2 documentation. The Db2 connector represents changes to rows with events that are structured like the table in which the row exists. The event contains a field for each column value. How that value is represented in the event depends on the Db2 data type of the column. This section describes these mappings. If the default data type conversions do not meet your needs, you can create a custom converter for the connector. Details are in the following sections: Basic types Temporal types Timestamp types Table 2.17, "Decimal types" Basic types The following table describes how the connector maps each Db2 data type to a literal type and a semantic type in event fields. literal type describes how the value is represented using Kafka Connect schema types: INT8 , INT16 , INT32 , INT64 , FLOAT32 , FLOAT64 , BOOLEAN , STRING , BYTES , ARRAY , MAP , and STRUCT . semantic type describes how the Kafka Connect schema captures the meaning of the field using the name of the Kafka Connect schema for the field. Table 2.14. Mappings for Db2 basic data types Db2 data type Literal type (schema type) Semantic type (schema name) and Notes BOOLEAN BOOLEAN Only snapshots can be taken from tables with BOOLEAN type columns. Currently SQL Replication on Db2 does not support BOOLEAN, so Debezium can not perform CDC on those tables. Consider using a different type. BIGINT INT64 n/a BINARY BYTES n/a BLOB BYTES n/a CHAR[(N)] STRING n/a CLOB STRING n/a DATE INT32 io.debezium.time.Date String representation of a timestamp without timezone information DECFLOAT BYTES org.apache.kafka.connect.data.Decimal DECIMAL BYTES org.apache.kafka.connect.data.Decimal DBCLOB STRING n/a DOUBLE FLOAT64 n/a INTEGER INT32 n/a REAL FLOAT32 n/a SMALLINT INT16 n/a TIME INT32 io.debezium.time.Time String representation of a time without timezone information TIMESTAMP INT64 io.debezium.time.MicroTimestamp String representation of a timestamp without timezone information VARBINARY BYTES n/a VARCHAR[(N)] STRING n/a VARGRAPHIC STRING n/a XML STRING io.debezium.data.Xml String representation of an XML document If present, a column's default value is propagated to the corresponding field's Kafka Connect schema. Change events contain the field's default value unless an explicit column value had been given. Consequently, there is rarely a need to obtain the default value from the schema. Temporal types Except for the DATETIMEOFFSET data type, which contains time zone information, Db2 maps temporal types based on the value of the time.precision.mode connector configuration property. The following sections describe these mappings: time.precision.mode=adaptive time.precision.mode=connect time.precision.mode=adaptive When the time.precision.mode configuration property is set to adaptive , the default, the connector determines the literal type and semantic type based on the column's data type definition. This ensures that events exactly represent the values in the database. Table 2.15. Mappings when time.precision.mode is adaptive Db2 data type Literal type (schema type) Semantic type (schema name) and Notes DATE INT32 io.debezium.time.Date Represents the number of days since the epoch. TIME(0) , TIME(1) , TIME(2) , TIME(3) INT32 io.debezium.time.Time Represents the number of milliseconds past midnight, and does not include timezone information. TIME(4) , TIME(5) , TIME(6) INT64 io.debezium.time.MicroTime Represents the number of microseconds past midnight, and does not include timezone information. TIME(7) INT64 io.debezium.time.NanoTime Represents the number of nanoseconds past midnight, and does not include timezone information. DATETIME INT64 io.debezium.time.Timestamp Represents the number of milliseconds since the epoch, and does not include timezone information. time.precision.mode=connect When the time.precision.mode configuration property is set to connect , the connector uses Kafka Connect logical types. This may be useful when consumers can handle only the built-in Kafka Connect logical types and are unable to handle variable-precision time values. However, since Db2 supports tenth of a microsecond precision, the events generated by a connector with the connect time precision results in a loss of precision when the database column has a fractional second precision value that is greater than 3. Table 2.16. Mappings when time.precision.mode is connect Db2 data type Literal type (schema type) Semantic type (schema name) and Notes DATE INT32 org.apache.kafka.connect.data.Date Represents the number of days since the epoch. TIME([P]) INT64 org.apache.kafka.connect.data.Time Represents the number of milliseconds since midnight, and does not include timezone information. Db2 allows P to be in the range 0-7 to store up to tenth of a microsecond precision, though this mode results in a loss of precision when P is greater than 3. DATETIME INT64 org.apache.kafka.connect.data.Timestamp Represents the number of milliseconds since the epoch, and does not include timezone information. Timestamp types The DATETIME type represents a timestamp without time zone information. Such columns are converted into an equivalent Kafka Connect value based on UTC. For example, the DATETIME value "2018-06-20 15:13:16.945104" is represented by an io.debezium.time.Timestamp with the value "1529507596000". The timezone of the JVM running Kafka Connect and Debezium does not affect this conversion. Table 2.17. Decimal types Db2 data type Literal type (schema type) Semantic type (schema name) and Notes NUMERIC[(P[,S])] BYTES org.apache.kafka.connect.data.Decimal The scale schema parameter contains an integer that represents how many digits the decimal point is shifted. The connect.decimal.precision schema parameter contains an integer that represents the precision of the given decimal value. DECIMAL[(P[,S])] BYTES org.apache.kafka.connect.data.Decimal The scale schema parameter contains an integer that represents how many digits the decimal point is shifted. The connect.decimal.precision schema parameter contains an integer that represents the precision of the given decimal value. 2.1.5. Setting up Db2 to run a Debezium connector For Debezium to capture change events that are committed to Db2 tables, a Db2 database administrator with the necessary privileges must configure tables in the database for change data capture. After you begin to run Debezium you can adjust the configuration of the capture agent to optimize performance. For details about setting up Db2 for use with the Debezium connector, see the following sections: Section 2.1.5.1, "Configuring Db2 tables for change data capture" Section 2.1.5.2, "Effect of Db2 capture agent configuration on server load and latency" Section 2.1.5.3, "Db2 capture agent configuration parameters" 2.1.5.1. Configuring Db2 tables for change data capture To put tables into capture mode, Debezium provides a set of user-defined functions (UDFs) for your convenience. The procedure here shows how to install and run these management UDFs. Alternatively, you can run Db2 control commands to put tables into capture mode. The administrator must then enable CDC for each table that you want Debezium to capture. Prerequisites You are logged in to Db2 as the db2instl user. On the Db2 host, the Debezium management UDFs are available in the USDHOME/asncdctools/src directory. UDFs are available from the Debezium examples repository . The Db2 command bldrtn is on PATH, e.g. by running export PATH=USDPATH:/opt/ibm/db2/V11.5.0.0/samples/c/ with Db2 11.5 Procedure Compile the Debezium management UDFs on the Db2 server host by using the bldrtn command provided with Db2: cd USDHOME/asncdctools/src bldrtn asncdc Start the database if it is not already running. Replace DB_NAME with the name of the database that you want Debezium to connect to. db2 start db DB_NAME Ensure that JDBC can read the Db2 metadata catalog: cd USDHOME/sqllib/bnd db2 connect to DB_NAME db2 bind db2schema.bnd blocking all grant public sqlerror continue Ensure that the database was recently backed-up. The ASN agents must have a recent starting point to read from. If you need to perform a backup, run the following commands, which prune the data so that only the most recent version is available. If you do not need to retain the older versions of the data, specify dev/null for the backup location. Back up the database. Replace DB_NAME and BACK_UP_LOCATION with appropriate values: db2 backup db DB_NAME to BACK_UP_LOCATION Restart the database: db2 restart db DB_NAME Connect to the database to install the Debezium management UDFs. It is assumed that you are logged in as the db2instl user so the UDFs should be installed on the db2inst1 user. db2 connect to DB_NAME Copy the Debezium management UDFs and set permissions for them: cp USDHOME/asncdctools/src/asncdc USDHOME/sqllib/function chmod 777 USDHOME/sqllib/function Enable the Debezium UDF that starts and stops the ASN capture agent: db2 -tvmf USDHOME/asncdctools/src/asncdc_UDF.sql Create the ASN control tables: USD db2 -tvmf USDHOME/asncdctools/src/asncdctables.sql Enable the Debezium UDF that adds tables to capture mode and removes tables from capture mode: USD db2 -tvmf USDHOME/asncdctools/src/asncdcaddremove.sql After you set up the Db2 server, use the UDFs to control Db2 replication (ASN) with SQL commands. Some of the UDFs expect a return value in which case you use the SQL VALUE statement to invoke them. For other UDFs, use the SQL CALL statement. Start the ASN agent from an SQL client: VALUES ASNCDC.ASNCDCSERVICES('start','asncdc'); or from the shell: db2 "VALUES ASNCDC.ASNCDCSERVICES('start','asncdc');" The preceding statement returns one of the following results: asncap is already running start --> <COMMAND> In this case, enter the specified <COMMAND> in the terminal window as shown in the following example: /database/config/db2inst1/sqllib/bin/asncap capture_schema=asncdc capture_server=SAMPLE & Put tables into capture mode. Invoke the following statement for each table that you want to put into capture. Replace MYSCHEMA with the name of the schema that contains the table you want to put into capture mode. Likewise, replace MYTABLE with the name of the table to put into capture mode: CALL ASNCDC.ADDTABLE('MYSCHEMA', 'MYTABLE'); Reinitialize the ASN service: VALUES ASNCDC.ASNCDCSERVICES('reinit','asncdc'); Additional resource Reference table for Debezium Db2 management UDFs 2.1.5.2. Effect of Db2 capture agent configuration on server load and latency When a database administrator enables change data capture for a source table, the capture agent begins to run. The agent reads new change event records from the transaction log and replicates the event records to a capture table. Between the time that a change is committed in the source table, and the time that the change appears in the corresponding change table, there is always a small latency interval. This latency interval represents a gap between when changes occur in the source table and when they become available for Debezium to stream to Apache Kafka. Ideally, for applications that must respond quickly to changes in data, you want to maintain close synchronization between the source and capture tables. You might imagine that running the capture agent to continuously process change events as rapidly as possible might result in increased throughput and reduced latency - populating change tables with new event records as soon as possible after the events occur, in near real time. However, this is not necessarily the case. There is a performance penalty to pay in the pursuit of more immediate synchronization. Each time that the change agent queries the database for new event records, it increases the CPU load on the database host. The additional load on the server can have a negative effect on overall database performance, and potentially reduce transaction efficiency, especially during times of peak database use. It's important to monitor database metrics so that you know if the database reaches the point where the server can no longer support the capture agent's level of activity. If you experience performance issues while running the capture agent, adjust capture agent settings to reduce CPU load. 2.1.5.3. Db2 capture agent configuration parameters On Db2, the IBMSNAP_CAPPARMS table contains parameters that control the behavior of the capture agent. You can adjust the values for these parameters to balance the configuration of the capture process to reduce CPU load and still maintain acceptable levels of latency. Note Specific guidance about how to configure Db2 capture agent parameters is beyond the scope of this documentation. In the IBMSNAP_CAPPARMS table, the following parameters have the greatest effect on reducing CPU load: COMMIT_INTERVAL Specifies the number of seconds that the capture agent waits to commit data to the change data tables. A higher value reduces the load on the database host and increases latency. The default value is 30 . SLEEP_INTERVAL Specifies the number of seconds that the capture agent waits to start a new commit cycle after it reaches the end of the active transaction log. A higher value reduces the load on the server, and increases latency. The default value is 5 . Additional resources For more information about capture agent parameters, see the Db2 documentation. 2.1.6. Deployment of Debezium Db2 connectors You can use either of the following methods to deploy a Debezium Db2 connector: Use Streams for Apache Kafka to automatically create an image that includes the connector plug-in . This is the preferred method. Build a custom Kafka Connect container image from a Dockerfile . Important Due to licensing requirements, the Debezium Db2 connector archive does not include the Db2 JDBC driver that Debezium requires to connect to a Db2 database. To enable the connector to access the database, you must add the driver to your connector environment. For information about how to obtain the driver, see Obtaining the Db2 JDBC driver . Additional resources Section 2.1.6.6, "Descriptions of Debezium Db2 connector configuration properties" 2.1.6.1. Obtaining the Db2 JDBC driver Due to licensing requirements, the Db2 JDBC driver file that Debezium requires to connect to an Db2 database is not included in the Debezium Db2 connector archive. The driver is available for download from Maven Central. Depending on the deployment method that you use, you retrieve the driver by adding a command to the Kafka Connect custom resource or to the Dockerfile that you use to build the connector image. If you use Streams for Apache Kafka to add the connector to your Kafka Connect image, add the Maven Central location for the driver to builds.plugins.artifact.url in the KafkaConnect custom resource as shown in Section 2.1.6.3, "Using Streams for Apache Kafka to deploy a Debezium Db2 connector" . If you use a Dockerfile to build a container image for the connector, insert a curl command in the Dockerfile to specify the URL for downloading the required driver file from Maven Central. For more information, see Section 2.1.6.4, "Deploying a Debezium Db2 connector by building a custom Kafka Connect container image from a Dockerfile" . 2.1.6.2. Db2 connector deployment using Streams for Apache Kafka Beginning with Debezium 1.7, the preferred method for deploying a Debezium connector is to use Streams for Apache Kafka to build a Kafka Connect container image that includes the connector plug-in. During the deployment process, you create and use the following custom resources (CRs): A KafkaConnect CR that defines your Kafka Connect instance and includes information about the connector artifacts needs to include in the image. A KafkaConnector CR that provides details that include information the connector uses to access the source database. After Streams for Apache Kafka starts the Kafka Connect pod, you start the connector by applying the KafkaConnector CR. In the build specification for the Kafka Connect image, you can specify the connectors that are available to deploy. For each connector plug-in, you can also specify other components that you want to make available for deployment. For example, you can add Apicurio Registry artifacts, or the Debezium scripting component. When Streams for Apache Kafka builds the Kafka Connect image, it downloads the specified artifacts, and incorporates them into the image. The spec.build.output parameter in the KafkaConnect CR specifies where to store the resulting Kafka Connect container image. Container images can be stored in a Docker registry, or in an OpenShift ImageStream. To store images in an ImageStream, you must create the ImageStream before you deploy Kafka Connect. ImageStreams are not created automatically. Note If you use a KafkaConnect resource to create a cluster, afterwards you cannot use the Kafka Connect REST API to create or update connectors. You can still use the REST API to retrieve information. Additional resources Configuring Kafka Connect in Deploying and Managing Streams for Apache Kafka on OpenShift. Building a new container image automatically in Deploying and Managing Streams for Apache Kafka on OpenShift. 2.1.6.3. Using Streams for Apache Kafka to deploy a Debezium Db2 connector With earlier versions of Streams for Apache Kafka, to deploy Debezium connectors on OpenShift, you were required to first build a Kafka Connect image for the connector. The current preferred method for deploying connectors on OpenShift is to use a build configuration in Streams for Apache Kafka to automatically build a Kafka Connect container image that includes the Debezium connector plug-ins that you want to use. During the build process, the Streams for Apache Kafka Operator transforms input parameters in a KafkaConnect custom resource, including Debezium connector definitions, into a Kafka Connect container image. The build downloads the necessary artifacts from the Red Hat Maven repository or another configured HTTP server. The newly created container is pushed to the container registry that is specified in .spec.build.output , and is used to deploy a Kafka Connect cluster. After Streams for Apache Kafka builds the Kafka Connect image, you create KafkaConnector custom resources to start the connectors that are included in the build. Prerequisites You have access to an OpenShift cluster on which the cluster Operator is installed. The Streams for Apache Kafka Operator is running. An Apache Kafka cluster is deployed as documented in Deploying and Managing Streams for Apache Kafka on OpenShift . Kafka Connect is deployed on Streams for Apache Kafka You have a Red Hat build of Debezium license. The OpenShift oc CLI client is installed or you have access to the OpenShift Container Platform web console. Depending on how you intend to store the Kafka Connect build image, you need registry permissions or you must create an ImageStream resource: To store the build image in an image registry, such as Red Hat Quay.io or Docker Hub An account and permissions to create and manage images in the registry. To store the build image as a native OpenShift ImageStream An ImageStream resource is deployed to the cluster for storing new container images. You must explicitly create an ImageStream for the cluster. ImageStreams are not available by default. For more information about ImageStreams, see Managing image streams on OpenShift Container Platform . Procedure Log in to the OpenShift cluster. Create a Debezium KafkaConnect custom resource (CR) for the connector, or modify an existing one. For example, create a KafkaConnect CR with the name dbz-connect.yaml that specifies the metadata.annotations and spec.build properties. The following example shows an excerpt from a dbz-connect.yaml file that describes a KafkaConnect custom resource. Example 2.3. A dbz-connect.yaml file that defines a KafkaConnect custom resource that includes a Debezium connector In the example that follows, the custom resource is configured to download the following artifacts: The Debezium Db2 connector archive. The Red Hat build of Apicurio Registry archive. The Apicurio Registry is an optional component. Add the Apicurio Registry component only if you intend to use Avro serialization with the connector. The Debezium scripting SMT archive and the associated language dependencies that you want to use with the Debezium connector. The SMT archive and language dependencies are optional components. Add these components only if you intend to use the Debezium content-based routing SMT or filter SMT . The Db2 JDBC driver, which is required to connect to Db2 databases, but is not included in the connector archive. apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: debezium-kafka-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: version: 3.6.0 build: 2 output: 3 type: imagestream 4 image: debezium-streams-connect:latest plugins: 5 - name: debezium-connector-db2 artifacts: - type: zip 6 url: https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-db2/2.7.3.Final-redhat-00001/debezium-connector-db2-2.7.3.Final-redhat-00001-plugin.zip 7 - type: zip url: https://maven.repository.redhat.com/ga/io/apicurio/apicurio-registry-distro-connect-converter/2.4.4.Final-redhat- <build-number> /apicurio-registry-distro-connect-converter-2.4.4.Final-redhat- <build-number> .zip 8 - type: zip url: https://maven.repository.redhat.com/ga/io/debezium/debezium-scripting/2.7.3.Final-redhat-00001/debezium-scripting-2.7.3.Final-redhat-00001.zip 9 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy/3.0.11/groovy-3.0.11.jar 10 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-jsr223/3.0.11/groovy-jsr223-3.0.11.jar - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-json3.0.11/groovy-json-3.0.11.jar - type: jar 11 url: https://repo1.maven.org/maven2/com/ibm/db2/jcc/11.5.0.0/jcc-11.5.0.0.jar bootstrapServers: debezium-kafka-cluster-kafka-bootstrap:9093 ... Table 2.18. Descriptions of Kafka Connect configuration settings Item Description 1 Sets the strimzi.io/use-connector-resources annotation to "true" to enable the Cluster Operator to use KafkaConnector resources to configure connectors in this Kafka Connect cluster. 2 The spec.build configuration specifies where to store the build image and lists the plug-ins to include in the image, along with the location of the plug-in artifacts. 3 The build.output specifies the registry in which the newly built image is stored. 4 Specifies the name and image name for the image output. Valid values for output.type are docker to push into a container registry such as Docker Hub or Quay, or imagestream to push the image to an internal OpenShift ImageStream. To use an ImageStream, an ImageStream resource must be deployed to the cluster. For more information about specifying the build.output in the KafkaConnect configuration, see the Streams for Apache Kafka Build schema reference in {NameConfiguringStreamsOpenShift}. 5 The plugins configuration lists all of the connectors that you want to include in the Kafka Connect image. For each entry in the list, specify a plug-in name , and information for about the artifacts that are required to build the connector. Optionally, for each connector plug-in, you can include other components that you want to be available for use with the connector. For example, you can add Service Registry artifacts, or the Debezium scripting component. 6 The value of artifacts.type specifies the file type of the artifact specified in the artifacts.url . Valid types are zip , tgz , or jar . Debezium connector archives are provided in .zip file format. JDBC driver files are in .jar format. The type value must match the type of the file that is referenced in the url field. 7 The value of artifacts.url specifies the address of an HTTP server, such as a Maven repository, that stores the file for the connector artifact. The OpenShift cluster must have access to the specified server. 8 (Optional) Specifies the artifact type and url for downloading the Apicurio Registry component. Include the Apicurio Registry artifact, only if you want the connector to use Apache Avro to serialize event keys and values with the Red Hat build of Apicurio Registry, instead of using the default JSON converter. 9 (Optional) Specifies the artifact type and url for the Debezium scripting SMT archive to use with the Debezium connector. Include the scripting SMT only if you intend to use the Debezium content-based routing SMT or filter SMT To use the scripting SMT, you must also deploy a JSR 223-compliant scripting implementation, such as groovy. 10 (Optional) Specifies the artifact type and url for the JAR files of a JSR 223-compliant scripting implementation, which is required by the Debezium scripting SMT. Important If you use Streams for Apache Kafka to incorporate the connector plug-in into your Kafka Connect image, for each of the required scripting language components, artifacts.url must specify the location of a JAR file, and the value of artifacts.type must also be set to jar . Invalid values cause the connector fails at runtime. To enable use of the Apache Groovy language with the scripting SMT, the custom resource in the example retrieves JAR files for the following libraries: groovy groovy-jsr223 (scripting agent) groovy-json (module for parsing JSON strings) The Debezium scripting SMT also supports the use of the JSR 223 implementation of GraalVM JavaScript. 11 Specifies the location of the Db2 JDBC driver in Maven Central. The required driver is not included in the Debezium Db2 connector archive. Apply the KafkaConnect build specification to the OpenShift cluster by entering the following command: oc create -f dbz-connect.yaml Based on the configuration specified in the custom resource, the Streams Operator prepares a Kafka Connect image to deploy. After the build completes, the Operator pushes the image to the specified registry or ImageStream, and starts the Kafka Connect cluster. The connector artifacts that you listed in the configuration are available in the cluster. Create a KafkaConnector resource to define an instance of each connector that you want to deploy. For example, create the following KafkaConnector CR, and save it as db2-inventory-connector.yaml Example 2.4. db2-inventory-connector.yaml file that defines the KafkaConnector custom resource for a Debezium connector apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: labels: strimzi.io/cluster: debezium-kafka-connect-cluster name: inventory-connector-db2 1 spec: class: io.debezium.connector.db2.Db2ConnectorConnector 2 tasksMax: 1 3 config: 4 schema.history.internal.kafka.bootstrap.servers: debezium-kafka-cluster-kafka-bootstrap.debezium.svc.cluster.local:9092 schema.history.internal.kafka.topic: schema-changes.inventory database.hostname: db2.debezium-db2.svc.cluster.local 5 database.port: 50000 6 database.user: debezium 7 database.password: dbz 8 database.dbname: mydatabase 9 topic.prefix: inventory-connector-db2 10 table.include.list: public.inventory 11 ... Table 2.19. Descriptions of connector configuration settings Item Description 1 The name of the connector to register with the Kafka Connect cluster. 2 The name of the connector class. 3 The number of tasks that can operate concurrently. 4 The connector's configuration. 5 The address of the host database instance. 6 The port number of the database instance. 7 The name of the account that Debezium uses to connect to the database. 8 The password that Debezium uses to connect to the database user account. 9 The name of the database to capture changes from. 10 The topic prefix for the database instance or cluster. The specified name must be formed only from alphanumeric characters or underscores. Because the topic prefix is used as the prefix for any Kafka topics that receive change events from this connector, the name must be unique among the connectors in the cluster. This namespace is also used in the names of related Kafka Connect schemas, and the namespaces of a corresponding Avro schema if you integrate the connector with the Avro connector . 11 The list of tables from which the connector captures change events. Create the connector resource by running the following command: oc create -n <namespace> -f <kafkaConnector> .yaml For example, oc create -n debezium -f db2-inventory-connector.yaml The connector is registered to the Kafka Connect cluster and starts to run against the database that is specified by spec.config.database.dbname in the KafkaConnector CR. After the connector pod is ready, Debezium is running. You are now ready to verify the Debezium Db2 deployment . 2.1.6.4. Deploying a Debezium Db2 connector by building a custom Kafka Connect container image from a Dockerfile To deploy a Debezium Db2 connector, you must build a custom Kafka Connect container image that contains the Debezium connector archive, and then push this container image to a container registry. You then need to create the following custom resources (CRs): A KafkaConnect CR that defines your Kafka Connect instance. The image property in the CR specifies the name of the container image that you create to run your Debezium connector. You apply this CR to the OpenShift instance where Red Hat Streams for Apache Kafka is deployed. Streams for Apache Kafka offers operators and images that bring Apache Kafka to OpenShift. A KafkaConnector CR that defines your Debezium Db2 connector. Apply this CR to the same OpenShift instance where you applied the KafkaConnect CR. Prerequisites Db2 is running and you completed the steps to set up Db2 to work with a Debezium connector . Streams for Apache Kafka is deployed on OpenShift and is running Apache Kafka and Kafka Connect. For more information, see Deploying and Managing Streams for Apache Kafka on OpenShift . Podman or Docker is installed. The Kafka Connect server has access to Maven Central to download the required JDBC driver for Db2. You can also use a local copy of the driver, or one that is available from a local Maven repository or other HTTP server. You have an account and permissions to create and manage containers in the container registry (such as quay.io or docker.io ) to which you plan to add the container that will run your Debezium connector. Procedure Create the Debezium Db2 container for Kafka Connect: Create a Dockerfile that uses registry.redhat.io/amq-streams-kafka-35-rhel8:2.5.0 as the base image. For example, from a terminal window, enter the following command: cat <<EOF >debezium-container-for-db2.yaml 1 FROM registry.redhat.io/amq-streams-kafka-35-rhel8:2.5.0 USER root:root RUN mkdir -p /opt/kafka/plugins/debezium 2 RUN cd /opt/kafka/plugins/debezium/ \ && curl -O https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-db2/2.7.3.Final-redhat-00001/debezium-connector-db2-2.7.3.Final-redhat-00001-plugin.zip \ && unzip debezium-connector-db2-2.7.3.Final-redhat-00001-plugin.zip \ && rm debezium-connector-db2-2.7.3.Final-redhat-00001-plugin.zip RUN cd /opt/kafka/plugins/debezium/ \ && curl -O https://repo1.maven.org/maven2/com/ibm/db2/jcc/11.5.0.0/jcc-11.5.0.0.jar USER 1001 EOF Item Description 1 You can specify any file name that you want. 2 Specifies the path to your Kafka Connect plug-ins directory. If your Kafka Connect plug-ins directory is in a different location, replace this path with the actual path of your directory. The command creates a Dockerfile with the name debezium-container-for-db2.yaml in the current directory. Build the container image from the debezium-container-for-db2.yaml Docker file that you created in the step. From the directory that contains the file, open a terminal window and enter one of the following commands: podman build -t debezium-container-for-db2:latest . docker build -t debezium-container-for-db2:latest . The preceding commands build a container image with the name debezium-container-for-db2 . Push your custom image to a container registry, such as quay.io or an internal container registry. The container registry must be available to the OpenShift instance where you want to deploy the image. Enter one of the following commands: podman push <myregistry.io> /debezium-container-for-db2:latest docker push <myregistry.io> /debezium-container-for-db2:latest Create a new Debezium Db2 KafkaConnect custom resource (CR). For example, create a KafkaConnect CR with the name dbz-connect.yaml that specifies annotations and image properties. The following example shows an excerpt from a dbz-connect.yaml file that describes a KafkaConnect custom resource. apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: #... image: debezium-container-for-db2 2 ... Item Description 1 metadata.annotations indicates to the Cluster Operator that KafkaConnector resources are used to configure connectors in this Kafka Connect cluster. 2 spec.image specifies the name of the image that you created to run your Debezium connector. This property overrides the STRIMZI_DEFAULT_KAFKA_CONNECT_IMAGE variable in the Cluster Operator. Apply the KafkaConnect CR to the OpenShift Kafka Connect environment by entering the following command: oc create -f dbz-connect.yaml The command adds a Kafka Connect instance that specifies the name of the image that you created to run your Debezium connector. Create a KafkaConnector custom resource that configures your Debezium Db2 connector instance. You configure a Debezium Db2 connector in a .yaml file that specifies the configuration properties for the connector. The connector configuration might instruct Debezium to produce events for a subset of the schemas and tables, or it might set properties so that Debezium ignores, masks, or truncates values in specified columns that are sensitive, too large, or not needed. The following example configures a Debezium connector that connects to a Db2 server host, 192.168.99.100 , on port 50000 . This host has a database named mydatabase , a table with the name inventory , and inventory-connector-db2 is the server's logical name. Db2 inventory-connector.yaml apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: inventory-connector-db2 1 labels: strimzi.io/cluster: my-connect-cluster annotations: strimzi.io/use-connector-resources: 'true' spec: class: io.debezium.connector.db2.Db2Connector 2 tasksMax: 1 3 config: 4 database.hostname: 192.168.99.100 5 database.port: 50000 6 database.user: db2inst1 7 database.password: Password! 8 database.dbname: mydatabase 9 topic.prefix: inventory-connector-db2 10 table.include.list: public.inventory 11 ... Table 2.20. Descriptions of connector configuration settings Item Description 1 The name of the connector when we register it with a Kafka Connect cluster. 2 The name of this Db2 connector class. 3 Only one task should operate at any one time. 4 The connector's configuration. 5 The database host, which is the address of the Db2 instance. 6 The port number of the Db2 instance. 7 The name of the Db2 user. 8 The password for the Db2 user. 9 The name of the database to capture changes from. 10 The logical name of the Db2 instance/cluster, which forms a namespace and is used in the names of the Kafka topics to which the connector writes, the names of Kafka Connect schemas, and the namespaces of the corresponding Avro schema when the Avro Connector is used. 11 The connector captures changes from the public.inventory table only. Create your connector instance with Kafka Connect. For example, if you saved your KafkaConnector resource in the inventory-connector.yaml file, you would run the following command: oc apply -f inventory-connector.yaml The preceding command registers inventory-connector and the connector starts to run against the mydatabase database as defined in the KafkaConnector CR. For the complete list of the configuration properties that you can set for the Debezium Db2 connector, see Db2 connector properties . Results After the connector starts, it performs a consistent snapshot of the Db2 database tables that the connector is configured to capture changes for. The connector then starts generating data change events for row-level operations and streaming change event records to Kafka topics. 2.1.6.5. Verifying that the Debezium Db2 connector is running If the connector starts correctly without errors, it creates a topic for each table that the connector is configured to capture. Downstream applications can subscribe to these topics to retrieve information events that occur in the source database. To verify that the connector is running, you perform the following operations from the OpenShift Container Platform web console, or through the OpenShift CLI tool (oc): Verify the connector status. Verify that the connector generates topics. Verify that topics are populated with events for read operations ("op":"r") that the connector generates during the initial snapshot of each table. Prerequisites A Debezium connector is deployed to Streams for Apache Kafka on OpenShift. The OpenShift oc CLI client is installed. You have access to the OpenShift Container Platform web console. Procedure Check the status of the KafkaConnector resource by using one of the following methods: From the OpenShift Container Platform web console: Navigate to Home Search . On the Search page, click Resources to open the Select Resource box, and then type KafkaConnector . From the KafkaConnectors list, click the name of the connector that you want to check, for example inventory-connector-db2 . In the Conditions section, verify that the values in the Type and Status columns are set to Ready and True . From a terminal window: Enter the following command: oc describe KafkaConnector <connector-name> -n <project> For example, oc describe KafkaConnector inventory-connector-db2 -n debezium The command returns status information that is similar to the following output: Example 2.5. KafkaConnector resource status Name: inventory-connector-db2 Namespace: debezium Labels: strimzi.io/cluster=debezium-kafka-connect-cluster Annotations: <none> API Version: kafka.strimzi.io/v1beta2 Kind: KafkaConnector ... Status: Conditions: Last Transition Time: 2021-12-08T17:41:34.897153Z Status: True Type: Ready Connector Status: Connector: State: RUNNING worker_id: 10.131.1.124:8083 Name: inventory-connector-db2 Tasks: Id: 0 State: RUNNING worker_id: 10.131.1.124:8083 Type: source Observed Generation: 1 Tasks Max: 1 Topics: inventory-connector-db2.inventory inventory-connector-db2.inventory.addresses inventory-connector-db2.inventory.customers inventory-connector-db2.inventory.geom inventory-connector-db2.inventory.orders inventory-connector-db2.inventory.products inventory-connector-db2.inventory.products_on_hand Events: <none> Verify that the connector created Kafka topics: From the OpenShift Container Platform web console. Navigate to Home Search . On the Search page, click Resources to open the Select Resource box, and then type KafkaTopic . From the KafkaTopics list, click the name of the topic that you want to check, for example, inventory-connector-db2.inventory.orders---ac5e98ac6a5d91e04d8ec0dc9078a1ece439081d . In the Conditions section, verify that the values in the Type and Status columns are set to Ready and True . From a terminal window: Enter the following command: oc get kafkatopics The command returns status information that is similar to the following output: Example 2.6. KafkaTopic resource status Check topic content. From a terminal window, enter the following command: oc exec -n <project> -it <kafka-cluster> -- /opt/kafka/bin/kafka-console-consumer.sh \ > --bootstrap-server localhost:9092 \ > --from-beginning \ > --property print.key=true \ > --topic= <topic-name > For example, oc exec -n debezium -it debezium-kafka-cluster-kafka-0 -- /opt/kafka/bin/kafka-console-consumer.sh \ > --bootstrap-server localhost:9092 \ > --from-beginning \ > --property print.key=true \ > --topic=inventory-connector-db2.inventory.products_on_hand The format for specifying the topic name is the same as the oc describe command returns in Step 1, for example, inventory-connector-db2.inventory.addresses . For each event in the topic, the command returns information that is similar to the following output: Example 2.7. Content of a Debezium change event In the preceding example, the payload value shows that the connector snapshot generated a read ( "op" ="r" ) event from the table inventory.products_on_hand . The "before" state of the product_id record is null , indicating that no value exists for the record. The "after" state shows a quantity of 3 for the item with product_id 101 . 2.1.6.6. Descriptions of Debezium Db2 connector configuration properties The Debezium Db2 connector has numerous configuration properties that you can use to achieve the right connector behavior for your application. Many properties have default values. Information about the properties is organized as follows: Required configuration properties Advanced configuration properties Database schema history connector configuration properties that control how Debezium processes events that it reads from the database schema history topic. Pass-through Db2 connector configuration properties Pass-through database schema history properties for configuring producer and consumer clients Pass-through Kafka signals configuration properties Pass-through Kafka signals consumer client configuration properties Pass-through sink notification configuration properties Pass-through database driver configuration properties Required Debezium Db2 connector configuration properties The following configuration properties are required unless a default value is available. Property Default Description name No default Unique name for the connector. Attempting to register again with the same name will fail. This property is required by all Kafka Connect connectors. connector.class No default The name of the Java class for the connector. Always use a value of io.debezium.connector.db2.Db2Connector for the Db2 connector. tasks.max 1 The maximum number of tasks that should be created for this connector. The Db2 connector always uses a single task and therefore does not use this value, so the default is always acceptable. database.hostname No default IP address or hostname of the Db2 database server. database.port 50000 Integer port number of the Db2 database server. database.user No default Name of the Db2 database user for connecting to the Db2 database server. database.password No default Password to use when connecting to the Db2 database server. database.dbname No default The name of the Db2 database from which to stream the changes topic.prefix No default Topic prefix which provides a namespace for the particular Db2 database server that hosts the database for which Debezium is capturing changes. Only alphanumeric characters, hyphens, dots and underscores must be used in the topic prefix name. The topic prefix should be unique across all other connectors, since this topic prefix is used for all Kafka topics that receive records from this connector. Warning Do not change the value of this property. If you change the name value, after a restart, instead of continuing to emit events to the original topics, the connector emits subsequent events to topics whose names are based on the new value. The connector is also unable to recover its database schema history topic. table.include.list No default An optional, comma-separated list of regular expressions that match fully-qualified table identifiers for tables whose changes you want the connector to capture. When this property is set, the connector captures changes only from the specified tables. Each identifier is of the form schemaName . tableName . By default, the connector captures changes in every non-system table. To match the name of a table, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the table it does not match substrings that might be present in a table name. If you include this property in the configuration, do not also set the table.exclude.list property. table.exclude.list No default An optional, comma-separated list of regular expressions that match fully-qualified table identifiers for tables whose changes you do not want the connector to capture. The connector captures changes in each non-system table that is not included in the exclude list. Each identifier is of the form schemaName . tableName . To match the name of a table, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the table it does not match substrings that might be present in a table name. If you include this property in the configuration, do not also set the table.include.list property. column.include.list empty string An optional, comma-separated list of regular expressions that match the fully-qualified names of columns to include in change event record values. Fully-qualified names for columns are of the form schemaName . tableName . columnName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; it does not match substrings that might be present in a column name. If you include this property in the configuration, do not also set the column.exclude.list property. column.exclude.list empty string An optional, comma-separated list of regular expressions that match the fully-qualified names of columns to exclude from change event values. Fully-qualified names for columns are of the form schemaName . tableName . columnName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; it does not match substrings that might be present in a column name. Primary key columns are always included in the event's key, even if they are excluded from the value. If you include this property in the configuration, do not set the column.include.list property. column.mask.hash. hashAlgorithm .with.salt. salt n/a An optional, comma-separated list of regular expressions that match the fully-qualified names of character-based columns. Fully-qualified names for columns are of the form schemaName . tableName . columnName . To match the name of a column Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. In the resulting change event record, the values for the specified columns are replaced with pseudonyms. A pseudonym consists of the hashed value that results from applying the specified hashAlgorithm and salt . Based on the hash function that is used, referential integrity is maintained, while column values are replaced with pseudonyms. Supported hash functions are described in the MessageDigest section of the Java Cryptography Architecture Standard Algorithm Name Documentation. In the following example, CzQMA0cB5K is a randomly selected salt. If necessary, the pseudonym is automatically shortened to the length of the column. The connector configuration can include multiple properties that specify different hash algorithms and salts. Depending on the hashAlgorithm used, the salt selected, and the actual data set, the resulting data set might not be completely masked. time.precision.mode adaptive Time, date, and timestamps can be represented with different kinds of precision: adaptive captures the time and timestamp values exactly as in the database using either millisecond, microsecond, or nanosecond precision values based on the database column's type. connect always represents time and timestamp values by using Kafka Connect's built-in representations for Time , Date , and Timestamp , which uses millisecond precision regardless of the database columns' precision. For more information, see temporal types . tombstones.on.delete true Controls whether a delete event is followed by a tombstone event. true - a delete operation is represented by a delete event and a subsequent tombstone event. false - only a delete event is emitted. After a source record is deleted, emitting a tombstone event (the default behavior) allows Kafka to completely delete all events that pertain to the key of the deleted row in case log compaction is enabled for the topic. include.schema.changes true Boolean value that specifies whether the connector should publish changes in the database schema to a Kafka topic with the same name as the database server ID. Each schema change is recorded with a key that contains the database name and a value that is a JSON structure that describes the schema update. This is independent of how the connector internally records database schema history. column.truncate.to. length .chars n/a An optional, comma-separated list of regular expressions that match the fully-qualified names of character-based columns. Set this property if you want to truncate the data in a set of columns when it exceeds the number of characters specified by the length in the property name. Set length to a positive integer value, for example, column.truncate.to.20.chars . The fully-qualified name of a column observes the following format: schemaName . tableName . columnName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. You can specify multiple properties with different lengths in a single configuration. column.mask.with. length .chars n/a An optional, comma-separated list of regular expressions that match the fully-qualified names of character-based columns. Set this property if you want the connector to mask the values for a set of columns, for example, if they contain sensitive data. Set length to a positive integer to replace data in the specified columns with the number of asterisk ( * ) characters specified by the length in the property name. Set length to 0 (zero) to replace data in the specified columns with an empty string. The fully-qualified name of a column observes the following format: schemaName . tableName . columnName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. You can specify multiple properties with different lengths in a single configuration. column.propagate.source.type n/a An optional, comma-separated list of regular expressions that match the fully-qualified names of columns for which you want the connector to emit extra parameters that represent column metadata. When this property is set, the connector adds the following fields to the schema of event records: __debezium.source.column.type __debezium.source.column.length __debezium.source.column.scale These parameters propagate a column's original type name and length (for variable-width types), respectively. Enabling the connector to emit this extra data can assist in properly sizing specific numeric or character-based columns in sink databases. The fully-qualified name of a column observes one of the following formats: databaseName . tableName . columnName , or databaseName . schemaName . tableName . columnName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. datatype.propagate.source.type n/a An optional, comma-separated list of regular expressions that specify the fully-qualified names of data types that are defined for columns in a database. When this property is set, for columns with matching data types, the connector emits event records that include the following extra fields in their schema: __debezium.source.column.type __debezium.source.column.length __debezium.source.column.scale These parameters propagate a column's original type name and length (for variable-width types), respectively. Enabling the connector to emit this extra data can assist in properly sizing specific numeric or character-based columns in sink databases. The fully-qualified name of a column observes one of the following formats: databaseName . tableName . typeName , or databaseName . schemaName . tableName . typeName . To match the name of a data type, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the data type; the expression does not match substrings that might be present in a type name. For the list of Db2-specific data type names, see the Db2 data type mappings . message.key.columns empty string A list of expressions that specify the columns that the connector uses to form custom message keys for change event records that it publishes to the Kafka topics for specified tables. By default, Debezium uses the primary key column of a table as the message key for records that it emits. In place of the default, or to specify a key for tables that lack a primary key, you can configure custom message keys based on one or more columns. To establish a custom message key for a table, list the table, followed by the columns to use as the message key. Each list entry takes the following format: <fully-qualified_tableName> : <keyColumn> , <keyColumn> To base a table key on multiple column names, insert commas between the column names. Each fully-qualified table name is a regular expression in the following format: <schemaName> . <tableName> The property can list entries for multiple tables. Use a semicolon to separate entries for different tables in the list. The following example sets the message key for the tables inventory.customers and purchaseorders : inventory.customers:pk1,pk2;(.*).purchaseorders:pk3,pk4 In the preceding example, the columns pk1 and pk2 are specified as the message key for the table inventory.customer . For purchaseorders tables in any schema, the columns pk3 and pk4 serve as the message key. schema.name.adjustment.mode none Specifies how schema names should be adjusted for compatibility with the message converter used by the connector. Possible settings: none does not apply any adjustment. avro replaces the characters that cannot be used in the Avro type name with underscore. avro_unicode replaces the underscore or characters that cannot be used in the Avro type name with corresponding unicode like _uxxxx. Note: _ is an escape sequence like backslash in Java field.name.adjustment.mode none Specifies how field names should be adjusted for compatibility with the message converter used by the connector. Possible settings: none does not apply any adjustment. avro replaces the characters that cannot be used in the Avro type name with underscore. avro_unicode replaces the underscore or characters that cannot be used in the Avro type name with corresponding unicode like _uxxxx. Note: _ is an escape sequence like backslash in Java See Avro naming for more details. Advanced connector configuration properties The following advanced configuration properties have defaults that work in most situations and therefore rarely need to be specified in the connector's configuration. Property Default Description converters No default Enumerates a comma-separated list of the symbolic names of the custom converter instances that the connector can use. For example, isbn You must set the converters property to enable the connector to use a custom converter. For each converter that you configure for a connector, you must also add a .type property, which specifies the fully-qualified name of the class that implements the converter interface. The .type property uses the following format: <converterSymbolicName> .type For example, If you want to further control the behavior of a configured converter, you can add one or more configuration parameters to pass values to the converter. To associate any additional configuration parameter with a converter, prefix the parameter names with the symbolic name of the converter. For example, snapshot.mode initial Specifies the criteria for performing a snapshot when the connector starts: always The connector performs a snapshot every time that it starts. The snapshot includes the structure and data of the captured tables. Specify this value to populate topics with a complete representation of the data from the captured tables every time that the connector starts. After the snapshot completes, the connector begins to stream event records for subsequent database changes. initial The connector performs a database snapshot as described in the default workflow for creating an initial snapshot . After the snapshot completes, the connector begins to stream event records for subsequent database changes. initial_only The connector performs a database a snapshot only when no offsets have been recorded for the logical server name. After the snapshot completes, the connector stops. It does not transition to streaming event records for subsequent database changes. schema_only Deprecated, see no_data . no_data The connector runs a snapshot that captures the structure of all relevant tables, performing all the steps described in the default snapshot workflow , except that it does not create READ events to represent the data set at the point of the connector's start-up (Step 7.b). recovery Set this option to restore a database schema history topic that is lost or corrupted. After a restart, the connector runs a snapshot that rebuilds the topic from the source tables. You can also set the property to periodically prune a database schema history topic that experiences unexpected growth. Warning Do not use this mode to perform a snapshot if schema changes were committed to the database after the last connector shutdown. when_needed After the connector starts, it performs a snapshot only if it detects one of the following circumstances: It cannot detect any topic offsets. A previously recorded offset specifies a log position that is not available on the server. snapshot.locking.mode exclusive Controls whether and for how long the connector holds a table lock. Table locks prevent other database clients from performing certain table operations during a snapshot. You can set the following values: exclusive Controls how the connector holds locks on tables while performing the schema snapshot when snapshot.isolation.mode is REPEATABLE_READ or EXCLUSIVE . The connector holds a table lock that ensures exclusive table access during only the initial phase of the snapshot in which the connector reads the database schema and other metadata. In subsequent phases of the snapshot, the connector uses a flashback query, which requires no locks, to select all rows from each table. If you prefer snapshots to run without setting any locks, set the following option, none . none Prevents the connector from acquiring any table locks during the snapshot. Use this setting only if no schema changes might occur during the creation of the snapshot. snapshot.query.mode select_all Specifies how the connector queries data while performing a snapshot. Set one of the following options: select_all The connector performs a select all query by default, optionally adjusting the columns selected based on the column include and exclude list configurations. This setting enables you to manage snapshot content in a more flexible manner compared to using the snapshot.select.statement.overrides property. snapshot.isolation.mode repeatable_read During a snapshot, controls the transaction isolation level and how long the connector locks the tables that are in capture mode. The possible values are: read_uncommitted - Does not prevent other transactions from updating table rows during an initial snapshot. This mode has no data consistency guarantees; some data might be lost or corrupted. read_committed - Does not prevent other transactions from updating table rows during an initial snapshot. It is possible for a new record to appear twice: once in the initial snapshot and once in the streaming phase. However, this consistency level is appropriate for data mirroring. repeatable_read - Prevents other transactions from updating table rows during an initial snapshot. It is possible for a new record to appear twice: once in the initial snapshot and once in the streaming phase. However, this consistency level is appropriate for data mirroring. exclusive - Uses repeatable read isolation level but takes an exclusive lock for all tables to be read. This mode prevents other transactions from updating table rows during an initial snapshot. Only exclusive mode guarantees full consistency; the initial snapshot and streaming logs constitute a linear history. event.processing.failure.handling.mode fail Specifies how the connector handles exceptions during processing of events. The possible values are: fail - The connector logs the offset of the problematic event and stops processing. warn - The connector logs the offset of the problematic event and continues processing with the event. skip - The connector skips the problematic event and continues processing with the event. poll.interval.ms 500 Positive integer value that specifies the number of milliseconds the connector should wait for new change events to appear before it starts processing a batch of events. Defaults to 500 milliseconds, or 0.5 second. max.batch.size 2048 Positive integer value that specifies the maximum size of each batch of events that the connector processes. max.queue.size 8192 Positive integer value that specifies the maximum number of records that the blocking queue can hold. When Debezium reads events streamed from the database, it places the events in the blocking queue before it writes them to Kafka. The blocking queue can provide backpressure for reading change events from the database in cases where the connector ingests messages faster than it can write them to Kafka, or when Kafka becomes unavailable. Events that are held in the queue are disregarded when the connector periodically records offsets. Always set the value of max.queue.size to be larger than the value of max.batch.size . max.queue.size.in.bytes 0 A long integer value that specifies the maximum volume of the blocking queue in bytes. By default, volume limits are not specified for the blocking queue. To specify the number of bytes that the queue can consume, set this property to a positive long value. If max.queue.size is also set, writing to the queue is blocked when the size of the queue reaches the limit specified by either property. For example, if you set max.queue.size=1000 , and max.queue.size.in.bytes=5000 , writing to the queue is blocked after the queue contains 1000 records, or after the volume of the records in the queue reaches 5000 bytes. heartbeat.interval.ms 0 Controls how frequently the connector sends heartbeat messages to a Kafka topic. The default behavior is that the connector does not send heartbeat messages. Heartbeat messages are useful for monitoring whether the connector is receiving change events from the database. Heartbeat messages might help decrease the number of change events that need to be re-sent when a connector restarts. To send heartbeat messages, set this property to a positive integer, which indicates the number of milliseconds between heartbeat messages. Heartbeat messages are useful when there are many updates in a database that is being tracked but only a tiny number of updates are in tables that are in capture mode. In this situation, the connector reads from the database transaction log as usual but rarely emits change records to Kafka. This means that the connector has few opportunities to send the latest offset to Kafka. Sending heartbeat messages enables the connector to send the latest offset to Kafka. snapshot.delay.ms No default An interval in milliseconds that the connector should wait before performing a snapshot when the connector starts. If you are starting multiple connectors in a cluster, this property is useful for avoiding snapshot interruptions, which might cause re-balancing of connectors. streaming.delay.ms 0 Specifies the time, in milliseconds, that the connector delays the start of the streaming process after it completes a snapshot. Setting a delay interval helps to prevent the connector from restarting snapshots in the event that a failure occurs immediately after the snapshot completes, but before the streaming process begins. Set a delay value that is higher than the value of the offset.flush.interval.ms property that is set for the Kafka Connect worker. snapshot.include.collection.list All tables specified in table.include.list An optional, comma-separated list of regular expressions that match the fully-qualified names ( <schemaName>.<tableName> ) of the tables to include in a snapshot. The specified items must be named in the connector's table.include.list property. This property takes effect only if the connector's snapshot.mode property is set to a value other than never . This property does not affect the behavior of incremental snapshots. To match the name of a table, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the table; it does not match substrings that might be present in a table name. snapshot.fetch.size 2000 During a snapshot, the connector reads table content in batches of rows. This property specifies the maximum number of rows in a batch. snapshot.lock.timeout.ms 10000 Positive integer value that specifies the maximum amount of time (in milliseconds) to wait to obtain table locks when performing a snapshot. If the connector cannot acquire table locks in this interval, the snapshot fails. How the connector performs snapshots provides details. Other possible settings are: 0 - The connector immediately fails when it cannot obtain a lock. -1 - The connector waits infinitely. snapshot.select.statement.overrides No default Specifies the table rows to include in a snapshot. Use the property if you want a snapshot to include only a subset of the rows in a table. This property affects snapshots only. It does not apply to events that the connector reads from the log. The property contains a comma-separated list of fully-qualified table names in the form <schemaName>.<tableName> . For example, "snapshot.select.statement.overrides": "inventory.products,customers.orders" For each table in the list, add a further configuration property that specifies the SELECT statement for the connector to run on the table when it takes a snapshot. The specified SELECT statement determines the subset of table rows to include in the snapshot. Use the following format to specify the name of this SELECT statement property: snapshot.select.statement.overrides. <schemaName> . <tableName> . For example, snapshot.select.statement.overrides.customers.orders . Example: From a customers.orders table that includes the soft-delete column, delete_flag , add the following properties if you want a snapshot to include only those records that are not soft-deleted: In the resulting snapshot, the connector includes only the records for which delete_flag = 0 . provide.transaction.metadata false Determines whether the connector generates events with transaction boundaries and enriches change event envelopes with transaction metadata. Specify true if you want the connector to do this. See Transaction metadata for details. skipped.operations t A comma-separated list of operation types that will be skipped during streaming. The operations include: c for inserts/create, u for updates, d for deletes, t for truncates, and none to not skip any operations. By default, truncate operations are skipped (not emitted by this connector). signal.data.collection No default Fully-qualified name of the data collection that is used to send signals to the connector. Use the following format to specify the collection name: <schemaName> . <tableName> signal.enabled.channels source List of the signaling channel names that are enabled for the connector. By default, the following channels are available: source kafka file jmx notification.enabled.channels No default List of the notification channel names that are enabled for the connector. By default, the following channels are available: sink log jmx incremental.snapshot.chunk.size 1024 The maximum number of rows that the connector fetches and reads into memory during an incremental snapshot chunk. Increasing the chunk size provides greater efficiency, because the snapshot runs fewer snapshot queries of a greater size. However, larger chunk sizes also require more memory to buffer the snapshot data. Adjust the chunk size to a value that provides the best performance in your environment. incremental.snapshot.watermarking.strategy insert_insert Specifies the watermarking mechanism that the connector uses during an incremental snapshot to deduplicate events that might be captured by an incremental snapshot and then recaptured after streaming resumes. You can specify one of the following options: insert_insert When you send a signal to initiate an incremental snapshot, for every chunk that Debezium reads during the snapshot, it writes an entry to the signaling data collection to record the signal to open the snapshot window. After the snapshot completes, Debezium inserts a second entry that records the signal to close the window. insert_delete When you send a signal to initiate an incremental snapshot, for every chunk that Debezium reads, it writes a single entry to the signaling data collection to record the signal to open the snapshot window. After the snapshot completes, this entry is removed. No entry is created for the signal to close the snapshot window. Set this option to prevent rapid growth of the signaling data collection. topic.naming.strategy io.debezium.schema.SchemaTopicNamingStrategy The name of the TopicNamingStrategy class that should be used to determine the topic name for data change, schema change, transaction, heartbeat event etc., defaults to SchemaTopicNamingStrategy . topic.delimiter . Specify the delimiter for topic name, defaults to . . topic.cache.size 10000 The size used for holding the topic names in bounded concurrent hash map. This cache will help to determine the topic name corresponding to a given data collection. topic.heartbeat.prefix __debezium-heartbeat Controls the name of the topic to which the connector sends heartbeat messages. The topic name has this pattern: topic.heartbeat.prefix . topic.prefix For example, if the topic prefix is fulfillment , the default topic name is __debezium-heartbeat.fulfillment . topic.transaction transaction Controls the name of the topic to which the connector sends transaction metadata messages. The topic name has this pattern: topic.prefix . topic.transaction For example, if the topic prefix is fulfillment , the default topic name is fulfillment.transaction . snapshot.max.threads 1 Specifies the number of threads that the connector uses when performing an initial snapshot. To enable parallel initial snapshots, set the property to a value greater than 1. In a parallel initial snapshot, the connector processes multiple tables concurrently. Important Parallel initial snapshots is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope . custom.metric.tags No default Defines tags that customize MBean object names by adding metadata that provides contextual information. Specify a comma-separated list of key-value pairs. Each key represents a tag for the MBean object name, and the corresponding value represents a value for the key, for example, k1=v1,k2=v2 The connector appends the specified tags to the base MBean object name. Tags can help you to organize and categorize metrics data. You can define tags to identify particular application instances, environments, regions, versions, and so forth. For more information, see Customized MBean names . errors.max.retries -1 Specifies how the connector responds after an operation that results in a retriable error, such as a connection error. Set one of the following options: -1 No limit. The connector always restarts automatically, and retries the operation, regardless of the number of failures. 0 Disabled. The connector fails immediately, and never retries the operation. User intervention is required to restart the connector. > 0 The connector restarts automatically until it reaches the specified maximum number of retries. After the failure, the connector stops, and user intervention is required to restart it. database.query.timeout.ms 600000 (10 minutes) Specifies the time, in milliseconds, that the connector waits for a query to complete. Set the value to 0 (zero) to remove the timeout limit. Debezium Db2 connector database schema history configuration properties Debezium provides a set of schema.history.internal.* properties that control how the connector interacts with the schema history topic. The following table describes the schema.history.internal properties for configuring the Debezium connector. Table 2.21. Connector database schema history configuration properties Property Default Description schema.history.internal.kafka.topic No default The full name of the Kafka topic where the connector stores the database schema history. schema.history.internal.kafka.bootstrap.servers No default A list of host/port pairs that the connector uses for establishing an initial connection to the Kafka cluster. This connection is used for retrieving the database schema history previously stored by the connector, and for writing each DDL statement read from the source database. Each pair should point to the same Kafka cluster used by the Kafka Connect process. schema.history.internal.kafka.recovery.poll.interval.ms 100 An integer value that specifies the maximum number of milliseconds the connector should wait during startup/recovery while polling for persisted data. The default is 100ms. schema.history.internal.kafka.query.timeout.ms 3000 An integer value that specifies the maximum number of milliseconds the connector should wait while fetching cluster information using Kafka admin client. schema.history.internal.kafka.create.timeout.ms 30000 An integer value that specifies the maximum number of milliseconds the connector should wait while create kafka history topic using Kafka admin client. schema.history.internal.kafka.recovery.attempts 100 The maximum number of times that the connector should try to read persisted history data before the connector recovery fails with an error. The maximum amount of time to wait after receiving no data is recovery.attempts x recovery.poll.interval.ms . schema.history.internal.skip.unparseable.ddl false A Boolean value that specifies whether the connector should ignore malformed or unknown database statements or stop processing so a human can fix the issue. The safe default is false . Skipping should be used only with care as it can lead to data loss or mangling when the binlog is being processed. schema.history.internal.store.only.captured.tables.ddl false A Boolean value that specifies whether the connector records schema structures from all tables in a schema or database, or only from tables that are designated for capture. Specify one of the following values: false (default) During a database snapshot, the connector records the schema data for all non-system tables in the database, including tables that are not designated for capture. It's best to retain the default setting. If you later decide to capture changes from tables that you did not originally designate for capture, the connector can easily begin to capture data from those tables, because their schema structure is already stored in the schema history topic. Debezium requires the schema history of a table so that it can identify the structure that was present at the time that a change event occurred. true During a database snapshot, the connector records the table schemas only for the tables from which Debezium captures change events. If you change the default value, and you later configure the connector to capture data from other tables in the database, the connector lacks the schema information that it requires to capture change events from the tables. schema.history.internal.store.only.captured.databases.ddl false A Boolean value that specifies whether the connector records schema structures from all logical databases in the database instance. Specify one of the following values: true The connector records schema structures only for tables in the logical database and schema from which Debezium captures change events. false The connector records schema structures for all logical databases. Pass-through Db2 connector configuration properties The connector supports pass-through properties that enable Debezium to specify custom configuration options for fine-tuning the behavior of the Apache Kafka producer and consumer. For information about the full range of configuration properties for Kafka producers and consumers, see the Kafka documentation . Pass-through properties for configuring how producer and consumer clients interact with schema history topics Debezium relies on an Apache Kafka producer to write schema changes to database schema history topics. Similarly, it relies on a Kafka consumer to read from database schema history topics when a connector starts. You define the configuration for the Kafka producer and consumer clients by assigning values to a set of pass-through configuration properties that begin with the schema.history.internal.producer.* and schema.history.internal.consumer.* prefixes. The pass-through producer and consumer database schema history properties control a range of behaviors, such as how these clients secure connections with the Kafka broker, as shown in the following example: Debezium strips the prefix from the property name before it passes the property to the Kafka client. For more information about Kafka producer configuration properties and Kafka consumer configuration properties , see the Apache Kafka documentation . Pass-through properties for configuring how the Db2 connector interacts with the Kafka signaling topic Debezium provides a set of signal.* properties that control how the connector interacts with the Kafka signals topic. The following table describes the Kafka signal properties. Table 2.22. Kafka signals configuration properties Property Default Description signal.kafka.topic <topic.prefix>-signal The name of the Kafka topic that the connector monitors for ad hoc signals. Note If automatic topic creation is disabled, you must manually create the required signaling topic. A signaling topic is required to preserve signal ordering. The signaling topic must have a single partition. signal.kafka.groupId kafka-signal The name of the group ID that is used by Kafka consumers. signal.kafka.bootstrap.servers No default A list of the host and port pairs that the connector uses to establish its initial connection to the Kafka cluster. Each pair references the Kafka cluster that is used by the Debezium Kafka Connect process. signal.kafka.poll.timeout.ms 100 An integer value that specifies the maximum number of milliseconds that the connector waits when polling signals. kafka.consumer.offset.commit.enabled false Specifies whether the Kafka consumer writes an offset commit after it reads a message from the signaling topic. The value that you assign to this property determines whether the connector can process requests that the signaling topic receives while the connector is offline. Choose one of the following settings: false When the connector is unavailable, the Kafka consumer does not commit an offset after it reads a signal received by the signaling topic. As a result, if the connector is offline for any interval, it cannot process requests that the signaling topic receives during the downtime. After the connector restarts, it always reads from the last position in the Kafka signaling topic, processing only signals that it receives after the restart. Signals received while the connector is offline are ignored, and are effectively lost. true When a user submits a request to the signaling topic, after the Kafka consumer reads the signal message it commits a topic offset, even if the connector is offline. Choose this option to provide Debezium with information about the last signal message that the consumer read, helping to ensure At-Least-Once delivery. After a connector restarts, it resumes processing from the last recorded offset, responding to signals that users submitted while the connector is offline. Pass-through properties for configuring the Kafka consumer client for the signaling channel The Debezium connector provides for pass-through configuration of the signals Kafka consumer. Pass-through signals properties begin with the prefix signals.consumer.* . For example, the connector passes properties such as signal.consumer.security.protocol=SSL to the Kafka consumer. Debezium strips the prefixes from the properties before it passes the properties to the Kafka signals consumer. Pass-through properties for configuring the Db2 connector sink notification channel The following table describes properties that you can use to configure the Debezium sink notification channel. Table 2.23. Sink notification configuration properties Property Default Description notification.sink.topic.name No default The name of the topic that receives notifications from Debezium. This property is required when you configure the notification.enabled.channels property to include sink as one of the enabled notification channels. Debezium connector pass-through database driver configuration properties The Debezium connector provides for pass-through configuration of the database driver. Pass-through database properties begin with the prefix driver.* . For example, the connector passes properties such as driver.foobar=false to the JDBC URL. Debezium strips the prefixes from the properties before it passes the properties to the database driver. 2.1.7. Monitoring Debezium Db2 connector performance The Debezium Db2 connector provides three types of metrics that are in addition to the built-in support for JMX metrics that Apache ZooKeeper, Apache Kafka, and Kafka Connect provide. Snapshot metrics provide information about connector operation while performing a snapshot. Streaming metrics provide information about connector operation when the connector is capturing changes and streaming change event records. Schema history metrics provide information about the status of the connector's schema history. Debezium monitoring documentation provides details for how to expose these metrics by using JMX. 2.1.7.1. Customized names for Db2 connector snapshot and streaming MBean objects Debezium connectors expose metrics via the MBean name for the connector. These metrics, which are specific to each connector instance, provide data about the behavior of the connector's snapshot, streaming, and schema history processes. By default, when you deploy a correctly configured connector, Debezium generates a unique MBean name for each of the different connector metrics. To view the metrics for a connector process, you configure your observability stack to monitor its MBean. But these default MBean names depend on the connector configuration; configuration changes can result in changes to the MBean names. A change to the MBean name breaks the linkage between the connector instance and the MBean, disrupting monitoring activity. In this scenario, you must reconfigure the observability stack to use the new MBean name if you want to resume monitoring. To prevent monitoring disruptions that result from MBean name changes, you can configure custom metrics tags. You configure custom metrics by adding the custom.metric.tags property to the connector configuration. The property accepts key-value pairs in which each key represents a tag for the MBean object name, and the corresponding value represents the value of that tag. For example: k1=v1,k2=v2 . Debezium appends the specified tags to the MBean name of the connector. After you configure the custom.metric.tags property for a connector, you can configure the observability stack to retrieve metrics associated with the specified tags. The observability stack then uses the specified tags, rather than the mutable MBean names to uniquely identify connectors. Later, if Debezium redefines how it constructs MBean names, or if the topic.prefix in the connector configuration changes, metrics collection is uninterrupted, because the metrics scrape task uses the specified tag patterns to identify the connector. A further benefit of using custom tags, is that you can use tags that reflect the architecture of your data pipeline, so that metrics are organized in a way that suits you operational needs. For example, you might specify tags with values that declare the type of connector activity, the application context, or the data source, for example, db1-streaming-for-application-abc . If you specify multiple key-value pairs, all of the specified pairs are appended to the connector's MBean name. The following example illustrates how tags modify the default MBean name. Example 2.8. How custom tags modify the connector MBean name By default, the Db2 connector uses the following MBean name for streaming metrics: If you set the value of custom.metric.tags to database=salesdb-streaming,table=inventory , Debezium generates the following custom MBean name: 2.1.7.2. Monitoring Debezium during snapshots of Db2 databases The MBean is debezium.db2:type=connector-metrics,context=snapshot,server= <topic.prefix> . Snapshot metrics are not exposed unless a snapshot operation is active, or if a snapshot has occurred since the last connector start. The following table lists the snapshot metrics that are available. Attributes Type Description LastEvent string The last snapshot event that the connector has read. MilliSecondsSinceLastEvent long The number of milliseconds since the connector has read and processed the most recent event. TotalNumberOfEventsSeen long The total number of events that this connector has seen since last started or reset. NumberOfEventsFiltered long The number of events that have been filtered by include/exclude list filtering rules configured on the connector. CapturedTables string[] The list of tables that are captured by the connector. QueueTotalCapacity int The length the queue used to pass events between the snapshotter and the main Kafka Connect loop. QueueRemainingCapacity int The free capacity of the queue used to pass events between the snapshotter and the main Kafka Connect loop. TotalTableCount int The total number of tables that are being included in the snapshot. RemainingTableCount int The number of tables that the snapshot has yet to copy. SnapshotRunning boolean Whether the snapshot was started. SnapshotPaused boolean Whether the snapshot was paused. SnapshotAborted boolean Whether the snapshot was aborted. SnapshotCompleted boolean Whether the snapshot completed. SnapshotDurationInSeconds long The total number of seconds that the snapshot has taken so far, even if not complete. Includes also time when snapshot was paused. SnapshotPausedDurationInSeconds long The total number of seconds that the snapshot was paused. If the snapshot was paused several times, the paused time adds up. RowsScanned Map<String, Long> Map containing the number of rows scanned for each table in the snapshot. Tables are incrementally added to the Map during processing. Updates every 10,000 rows scanned and upon completing a table. MaxQueueSizeInBytes long The maximum buffer of the queue in bytes. This metric is available if max.queue.size.in.bytes is set to a positive long value. CurrentQueueSizeInBytes long The current volume, in bytes, of records in the queue. The connector also provides the following additional snapshot metrics when an incremental snapshot is executed: Attributes Type Description ChunkId string The identifier of the current snapshot chunk. ChunkFrom string The lower bound of the primary key set defining the current chunk. ChunkTo string The upper bound of the primary key set defining the current chunk. TableFrom string The lower bound of the primary key set of the currently snapshotted table. TableTo string The upper bound of the primary key set of the currently snapshotted table. 2.1.7.3. Monitoring Debezium Db2 connector record streaming The MBean is debezium.db2:type=connector-metrics,context=streaming,server= <topic.prefix> . The following table lists the streaming metrics that are available. Attributes Type Description LastEvent string The last streaming event that the connector has read. MilliSecondsSinceLastEvent long The number of milliseconds since the connector has read and processed the most recent event. TotalNumberOfEventsSeen long The total number of data change events reported by the source database since the last connector start, or since a metrics reset. Represents the data change workload for Debezium to process. TotalNumberOfCreateEventsSeen long The total number of create events processed by the connector since its last start or metrics reset. TotalNumberOfUpdateEventsSeen long The total number of update events processed by the connector since its last start or metrics reset. TotalNumberOfDeleteEventsSeen long The total number of delete events processed by the connector since its last start or metrics reset. NumberOfEventsFiltered long The number of events that have been filtered by include/exclude list filtering rules configured on the connector. CapturedTables string[] The list of tables that are captured by the connector. QueueTotalCapacity int The length the queue used to pass events between the streamer and the main Kafka Connect loop. QueueRemainingCapacity int The free capacity of the queue used to pass events between the streamer and the main Kafka Connect loop. Connected boolean Flag that denotes whether the connector is currently connected to the database server. MilliSecondsBehindSource long The number of milliseconds between the last change event's timestamp and the connector processing it. The values will incorporate any differences between the clocks on the machines where the database server and the connector are running. NumberOfCommittedTransactions long The number of processed transactions that were committed. SourceEventPosition Map<String, String> The coordinates of the last received event. LastTransactionId string Transaction identifier of the last processed transaction. MaxQueueSizeInBytes long The maximum buffer of the queue in bytes. This metric is available if max.queue.size.in.bytes is set to a positive long value. CurrentQueueSizeInBytes long The current volume, in bytes, of records in the queue. 2.1.7.4. Monitoring Debezium Db2 connector schema history The MBean is debezium.db2:type=connector-metrics,context=schema-history,server= <topic.prefix> . The following table lists the schema history metrics that are available. Attributes Type Description Status string One of STOPPED , RECOVERING (recovering history from the storage), RUNNING describing the state of the database schema history. RecoveryStartTime long The time in epoch seconds at what recovery has started. ChangesRecovered long The number of changes that were read during recovery phase. ChangesApplied long the total number of schema changes applied during recovery and runtime. MilliSecondsSinceLast RecoveredChange long The number of milliseconds that elapsed since the last change was recovered from the history store. MilliSecondsSinceLast AppliedChange long The number of milliseconds that elapsed since the last change was applied. LastRecoveredChange string The string representation of the last change recovered from the history store. LastAppliedChange string The string representation of the last applied change. 2.1.8. Managing Debezium Db2 connectors After you deploy a Debezium Db2 connector, use the Debezium management UDFs to control Db2 replication (ASN) with SQL commands. Some of the UDFs expect a return value in which case you use the SQL VALUE statement to invoke them. For other UDFs, use the SQL CALL statement. Table 2.24. Descriptions of Debezium management UDFs Task Command and notes Start the ASN agent VALUES ASNCDC.ASNCDCSERVICES('start','asncdc'); Stop the ASN agent VALUES ASNCDC.ASNCDCSERVICES('stop','asncdc'); Check the status of the ASN agent VALUES ASNCDC.ASNCDCSERVICES('status','asncdc'); Put a table into capture mode CALL ASNCDC.ADDTABLE('MYSCHEMA', 'MYTABLE'); Replace MYSCHEMA with the name of the schema that contains the table you want to put into capture mode. Likewise, replace MYTABLE with the name of the table to put into capture mode. Remove a table from capture mode CALL ASNCDC.REMOVETABLE('MYSCHEMA', 'MYTABLE'); Reinitialize the ASN service VALUES ASNCDC.ASNCDCSERVICES('reinit','asncdc'); Do this after you put a table into capture mode or after you remove a table from capture mode. 2.1.9. Updating schemas for Db2 tables in capture mode for Debezium connectors While a Debezium Db2 connector can capture schema changes, to update a schema, you must collaborate with a database administrator to ensure that the connector continues to produce change events. This is required by the way that Db2 implements replication. For each table in capture mode, the replication feature in Db2 creates a change-data table that contains all changes to that source table. However, change-data table schemas are static. If you update the schema for a table in capture mode then you must also update the schema of its corresponding change-data table. A Debezium Db2 connector cannot do this. A database administrator with elevated privileges must update schemas for tables that are in capture mode. Warning It is vital to execute a schema update procedure completely before there is a new schema update on the same table. Consequently, the recommendation is to execute all DDLs in a single batch so the schema update procedure is done only once. There are generally two procedures for updating table schemas: Offline - executed while Debezium is stopped Online - executed while Debezium is running Each approach has advantages and disadvantages. 2.1.9.1. Performing offline schema updates for Debezium Db2 connectors You stop the Debezium Db2 connector before you perform an offline schema update. While this is the safer schema update procedure, it might not be feasible for applications with high-availability requirements. Prerequisites One or more tables that are in capture mode require schema updates. Procedure Suspend the application that updates the database. Wait for the Debezium connector to stream all unstreamed change event records. Stop the Debezium connector. Apply all changes to the source table schema. In the ASN register table, mark the tables with updated schemas as INACTIVE . Reinitialize the ASN capture service . Remove the source table with the old schema from capture mode by running the Debezium UDF for removing tables from capture mode . Add the source table with the new schema to capture mode by running the Debezium UDF for adding tables to capture mode . In the ASN register table, mark the updated source tables as ACTIVE . Reinitialize the ASN capture service. Resume the application that updates the database. Restart the Debezium connector. 2.1.9.2. Performing online schema updates for Debezium Db2 connectors An online schema update does not require application and data processing downtime. That is, you do not stop the Debezium Db2 connector before you perform an online schema update. Also, an online schema update procedure is simpler than the procedure for an offline schema update. However, when a table is in capture mode, after a change to a column name, the Db2 replication feature continues to use the old column name. The new column name does not appear in Debezium change events. You must restart the connector to see the new column name in change events. Prerequisites One or more tables that are in capture mode require schema updates. Procedure when adding a column to the end of a table Lock the source tables whose schema you want to change. In the ASN register table, mark the locked tables as INACTIVE . Reinitialize the ASN capture service. Apply all changes to the schemas for the source tables. Apply all changes to the schemas for the corresponding change-data tables. In the ASN register table, mark the source tables as ACTIVE . Reinitialize the ASN capture service. Optional. Restart the connector to see updated column names in change events. Procedure when adding a column to the middle of a table Lock the source table(s) to be changed. In the ASN register table, mark the locked tables as INACTIVE . Reinitialize the ASN capture service. For each source table to be changed: Export the data in the source table. Truncate the source table. Alter the source table and add the column. Load the exported data into the altered source table. Export the data in the source table's corresponding change-data table. Truncate the change-data table. Alter the change-data table and add the column. Load the exported data into the altered change-data table. In the ASN register table, mark the tables as INACTIVE . This marks the old change-data tables as inactive, which allows the data in them to remain but they are no longer updated. Reinitialize the ASN capture service. Optional. Restart the connector to see updated column names in change events. 2.2. Debezium connector for MariaDB (Technology Preview) Important The Debezium connector for MariaDB is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope . MariaDB has a binary log (binlog) that records all operations in the order in which they are committed to the database. This includes changes to table schemas as well as changes to the data in tables. MariaDB uses the binlog for replication and recovery. The Debezium MariaDB connector reads the binlog, produces change events for row-level INSERT , UPDATE , and DELETE operations, and emits the change events to Kafka topics. Client applications read those Kafka topics. Because MariaDB is typically set up to purge binlogs after a specified period of time, the MariaDB connector performs an initial consistent snapshot of each of your databases. The MariaDB connector reads the binlog from the point at which the snapshot was made. For information about the MariaDB Database versions that are compatible with this connector, see the Debezium Supported Configurations page . Information and procedures for using a Debezium MariaDB connector are organized as follows: Section 2.2.1, "How Debezium MariaDB connectors work" Section 2.2.2, "Descriptions of Debezium MariaDB connector data change events" Section 2.2.3, "How Debezium MariaDB connectors map data types" Section 2.2.4, "Custom converters for mapping MariaDB data to alternative data types" Section 2.2.5, "Setting up MariaDB to run a Debezium connector" Section 2.2.6, "Deployment of Debezium MariaDB connectors" Section 2.2.7, "Monitoring Debezium MariaDB connector performance" Section 2.2.8, "How Debezium MariaDB connectors handle faults and problems" 2.2.1. How Debezium MariaDB connectors work An overview of the MariaDB topologies that the connector supports is useful for planning your application. To optimally configure and run a Debezium MariaDB connector, it is helpful to understand how the connector tracks the structure of tables, exposes schema changes, performs snapshots, and determines Kafka topic names. Details are in the following topics: Section 2.2.1.1, "MariaDB topologies supported by Debezium connectors" Section 2.2.1.2, "How Debezium MariaDB connectors handle database schema changes" Section 2.2.1.3, "How Debezium MariaDB connectors expose database schema changes" Section 2.2.1.4, "How Debezium MariaDB connectors perform database snapshots" Section 2.2.1.5, "Ad hoc snapshots" Section 2.2.1.6, "Incremental snapshots" Section 2.2.1.8, "Default names of Kafka topics that receive Debezium MariaDB change event records" 2.2.1.1. MariaDB topologies supported by Debezium connectors The Debezium MariaDB connector supports the following MariaDB topologies: Standalone When a single MariaDB server is used, the server must have the binlog enabled so the Debezium MariaDB connector can monitor the server. This is often acceptable, since the binary log can also be used as an incremental [backup]. In this case, the MariaDB connector always connects to and follows this standalone MariaDB server instance. Primary and replica The Debezium MariaDB connector can follow one of the primary servers, or one of the replicas ( if that replica has its binlog enabled ), but the connector detects changes only in the cluster that is visible to that server. Generally, this is not a problem except for the multi-primary topologies. The connector records its position in the server's binlog, which is different on each server in the cluster. Therefore, the connector must follow just one MariaDB server instance. If that server fails, that server must be restarted or recovered before the connector can continue. High available clusters A variety of [high availability] solutions exist for MariaDB, and they make it significantly easier to tolerate and almost immediately recover from problems and failures. Because HA MariaDB clusters use GTIDs, replicas are able to track all of the changes that occur on any primary server. Multi-primary uses one or more MariaDB replica nodes that each replicate from multiple primary servers. Cluster replication provides a powerful way to aggregate the replication of multiple MariaDB clusters. A Debezium MariaDB connector can use these multi-primary MariaDB replicas as sources, and can fail over to different multi-primary MariaDB replicas as long as the new replica is caught up to the old replica. That is, the new replica has all transactions that were seen on the first replica. This works even if the connector is using only a subset of databases and/or tables, because the connector can be configured to include or exclude specific GTID sources when attempting to reconnect to a new multi-primary MariaDB replica and find the correct position in the binlog. Hosted The Debezium MariaDB connector can use hosted database options such as Amazon RDS and Amazon Aurora. Because these hosted options do not permit the use of global read locks, the connector uses table-level locks when it creates a consistent snapshot. 2.2.1.2. How Debezium MariaDB connectors handle database schema changes When a database client queries a database, the client uses the database's current schema. However, the database schema can be changed at any time, which means that the connector must be able to identify what the schema was at the time each insert, update, or delete operation was recorded. Also, a connector cannot necessarily apply the current schema to every event. If an event is relatively old, it's possible that it was recorded before the current schema was applied. To ensure correct processing of events that occur after a schema change, MariaDB includes in the transaction log not only the row-level changes that affect the data, but also the DDL statements that are applied to the database. As the connector encounters these DDL statements in the binlog, it parses them and updates an in-memory representation of each table's schema. The connector uses this schema representation to identify the structure of the tables at the time of each insert, update, or delete operation and to produce the appropriate change event. In a separate database schema history Kafka topic, the connector records all DDL statements along with the position in the binlog where each DDL statement appeared. When the connector restarts after either a crash or a graceful stop, it starts reading the binlog from a specific position, that is, from a specific point in time. The connector rebuilds the table structures that existed at this point in time by reading the database schema history Kafka topic and parsing all DDL statements up to the point in the binlog where the connector is starting. This database schema history topic is for internal connector use only. Optionally, the connector can also emit schema change events to a different topic that is intended for consumer applications . When the MariaDB connector captures changes in a table to which a schema change tool such as gh-ost or pt-online-schema-change is applied, there are helper tables created during the migration process. You must configure the connector to capture changes that occur in these helper tables. If consumers do not need the records the connector generates for helper tables, configure a single message transform (SMT) to remove these records from the messages that the connector emits. Additional resources Default names for topics that receive Debezium event records. 2.2.1.3. How Debezium MariaDB connectors expose database schema changes You can configure a Debezium MariaDB connector to produce schema change events that describe schema changes that are applied to tables in the database. The connector writes schema change events to a Kafka topic named <topicPrefix> , where topicPrefix is the namespace specified in the topic.prefix connector configuration property. Messages that the connector sends to the schema change topic contain a payload, and, optionally, also contain the schema of the change event message. The schema for the schema change event has the following elements: name The name of the schema change event message. type The type of the change event message. version The version of the schema. The version is an integer that is incremented each time the schema is changed. fields The fields that are included in the change event message. Example: Schema of the MariaDB connector schema change topic The following example shows a typical schema in JSON format. { "schema": { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "databaseName" } ], "optional": false, "name": "io.debezium.connector.mariadb.SchemaChangeKey", "version": 1 }, "payload": { "databaseName": "inventory" } } The payload of a schema change event message includes the following elements: ddl Provides the SQL CREATE , ALTER , or DROP statement that results in the schema change. databaseName The name of the database to which the DDL statements are applied. The value of databaseName serves as the message key. pos The position in the binlog where the statements appear. tableChanges A structured representation of the entire table schema after the schema change. The tableChanges field contains an array that includes entries for each column of the table. Because the structured representation presents data in JSON or Avro format, consumers can easily read messages without first processing them through a DDL parser. Important For a table that is in capture mode, the connector not only stores the history of schema changes in the schema change topic, but also in an internal database schema history topic. The internal database schema history topic is for connector use only, and it is not intended for direct use by consuming applications. Ensure that applications that require notifications about schema changes consume that information only from the schema change topic. Important Never partition the database schema history topic. For the database schema history topic to function correctly, it must maintain a consistent, global order of the event records that the connector emits to it. To ensure that the topic is not split among partitions, set the partition count for the topic by using one of the following methods: If you create the database schema history topic manually, specify a partition count of 1 . If you use the Apache Kafka broker to create the database schema history topic automatically, the topic is created, set the value of the Kafka num.partitions configuration option to 1 . Warning The format of the messages that a connector emits to its schema change topic is in an incubating state and is subject to change without notice. Example: Message emitted to the MariaDB connector schema change topic The following example shows a typical schema change message in JSON format. The message contains a logical representation of the table schema. { "schema": { }, "payload": { "source": { 1 "version": "2.7.3.Final", "connector": "mariadb", "name": "mariadb", "ts_ms": 1651535750218, 2 "ts_us": 1651535750218000, 3 "ts_ns": 1651535750218000000, 4 "snapshot": "false", "db": "inventory", "sequence": null, "table": "customers", "server_id": 223344, "gtid": null, "file": "mariadb-bin.000003", "pos": 570, "row": 0, "thread": null, "query": null }, "databaseName": "inventory", 5 "schemaName": null, "ddl": "ALTER TABLE customers ADD middle_name varchar(255) AFTER first_name", 6 "tableChanges": [ 7 { "type": "ALTER", 8 "id": "\"inventory\".\"customers\"", 9 "table": { 10 "defaultCharsetName": "utf8mb4", "primaryKeyColumnNames": [ 11 "id" ], "columns": [ 12 { "name": "id", "jdbcType": 4, "nativeType": null, "typeName": "INT", "typeExpression": "INT", "charsetName": null, "length": null, "scale": null, "position": 1, "optional": false, "autoIncremented": true, "generated": true }, { "name": "first_name", "jdbcType": 12, "nativeType": null, "typeName": "VARCHAR", "typeExpression": "VARCHAR", "charsetName": "utf8mb4", "length": 255, "scale": null, "position": 2, "optional": false, "autoIncremented": false, "generated": false }, { "name": "middle_name", "jdbcType": 12, "nativeType": null, "typeName": "VARCHAR", "typeExpression": "VARCHAR", "charsetName": "utf8mb4", "length": 255, "scale": null, "position": 3, "optional": true, "autoIncremented": false, "generated": false }, { "name": "last_name", "jdbcType": 12, "nativeType": null, "typeName": "VARCHAR", "typeExpression": "VARCHAR", "charsetName": "utf8mb4", "length": 255, "scale": null, "position": 4, "optional": false, "autoIncremented": false, "generated": false }, { "name": "email", "jdbcType": 12, "nativeType": null, "typeName": "VARCHAR", "typeExpression": "VARCHAR", "charsetName": "utf8mb4", "length": 255, "scale": null, "position": 5, "optional": false, "autoIncremented": false, "generated": false } ], "attributes": [ 13 { "customAttribute": "attributeValue" } ] } } ] } } Table 2.25. Descriptions of fields in messages emitted to the schema change topic Item Field name Description 1 source The source field is structured exactly as standard data change events that the connector writes to table-specific topics. This field is useful to correlate events on different topics. 2 ts_ms , ts_us , ts_ns Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms, you can determine the lag between the source database update and Debezium. 3 databaseName schemaName Identifies the database and the schema that contains the change. The value of the databaseName field is used as the message key for the record. 4 ddl This field contains the DDL that is responsible for the schema change. The ddl field can contain multiple DDL statements. Each statement applies to the database in the databaseName field. Multiple DDL statements appear in the order in which they were applied to the database. Clients can submit multiple DDL statements that apply to multiple databases. If MariaDB applies them atomically, the connector takes the DDL statements in order, groups them by database, and creates a schema change event for each group. If MariaDB applies them individually, the connector creates a separate schema change event for each statement. 5 tableChanges An array of one or more items that contain the schema changes generated by a DDL command. 6 type Describes the kind of change. The value is one of the following: CREATE Table created. ALTER Table modified. DROP Table deleted. 7 id Full identifier of the table that was created, altered, or dropped. In the case of a table rename, this identifier is a concatenation of <old> , <new> table names. 8 table Represents table metadata after the applied change. 9 primaryKeyColumnNames List of columns that compose the table's primary key. 10 columns Metadata for each column in the changed table. 11 attributes Custom attribute metadata for each table change. For more information, see schema history topic . 2.2.1.4. How Debezium MariaDB connectors perform database snapshots When a Debezium MariaDB connector is first started, it performs an initial consistent snapshot of your database. This snapshot enables the connector to establish a baseline for the current state of the database. Debezium can use different modes when it runs a snapshot. The snapshot mode is determined by the snapshot.mode configuration property. The default value of the property is initial . You can customize the way that the connector creates snapshots by changing the value of the snapshot.mode property. You can find more information about snapshots in the following sections: Section 2.2.1.5, "Ad hoc snapshots" Section 2.2.1.6, "Incremental snapshots" The connector completes a series of tasks when it performs the snapshot. The exact steps vary with the snapshot mode and with the table locking policy that is in effect for the database. The Debezium MariaDB connector completes different steps when it performs an initial snapshot that uses a global read lock or table-level locks . 2.2.1.4.1. Initial snapshots that use a global read lock You can customize the way that the connector creates snapshots by changing the value of the snapshot.mode property. If you configure a different snapshot mode, the connector completes the snapshot by using a modified version of this workflow. For information about the snapshot process in environments that do not permit global read locks, see the snapshot workflow for table-level locks . Default workflow that the Debezium MariaDB connector uses to perform an initial snapshot with a global read lock The following table shows the steps in the workflow that Debezium follows to create a snapshot with a global read lock. Step Action 1 Establish a connection to the database. 2 Determine the tables to be captured. By default, the connector captures the data for all non-system tables. After the snapshot completes, the connector continues to stream data for the specified tables. If you want the connector to capture data only from specific tables you can direct the connector to capture the data for only a subset of tables or table elements by setting properties such as table.include.list or table.exclude.list . 3 Obtain a global read lock on the tables to be captured to block writes by other database clients. The snapshot itself does not prevent other clients from applying DDL that might interfere with the connector's attempt to read the binlog position and table schemas. The connector retains the global read lock while it reads the binlog position, and releases the lock as described in a later step. 4 Note The use of these isolation semantics can slow the progress of the snapshot. If the snapshot takes too long to complete, consider using a different isolation configuration, or skip the initial snapshot and run an incremental snapshot instead. 5 Read the current binlog position. 6 Capture the structure of all tables in the database, or all tables that are designated for capture. The connector persists schema information in its internal database schema history topic, including all necessary DROP... and CREATE... DDL statements. The schema history provides information about the structure that is in effect when a change event occurs. Note By default, the connector captures the schema of every table in the database, including tables that are not configured for capture. If tables are not configured for capture, the initial snapshot captures only their structure; it does not capture any table data. For more information about why snapshots persist schema information for tables that you did not include in the initial snapshot, see Understanding why initial snapshots capture the schema for all tables . 7 Release the global read lock obtained in Step 3. Other database clients can now write to the database. 8 At the binlog position that the connector read in Step 5, the connector begins to scan the tables that are designated for capture. During the scan, the connector completes the following tasks: Confirms that the table was created before the snapshot began. If the table was created after the snapshot began, the connector skips the table. After the snapshot is complete, and the connector transitions to streaming, it emits change events for any tables that were created after the snapshot began. Produces a read event for each row that is captured from a table. All read events contain the same binlog position, which is the position that was obtained in step 5. Emits each read event to the Kafka topic for the source table. Releases data table locks, if applicable. 9 Commit the transaction. 10 The resulting initial snapshot captures the current state of each row in the captured tables. From this baseline state, the connector captures subsequent changes as they occur. After the snapshot process begins, if the process is interrupted due to connector failure, rebalancing, or other reasons, the process restarts after the connector restarts. After the connector completes the initial snapshot, it continues streaming from the position that it read in Step 5 so that it does not miss any updates. If the connector stops again for any reason, after it restarts, it resumes streaming changes from where it previously left off. After the connector restarts, if the logs have been pruned, the connector's position in the logs might no longer available. The connector then fails, and returns an error that indicates that a new snapshot is required. To configure the connector to automatically initiate a snapshot in this situation, set the value of the snapshot.mode property to when_needed . For more tips on troubleshooting the Debezium MariaDB connector, see behavior when things go wrong . 2.2.1.4.2. Initial snapshots that use table-level locks In some database environments, administrators do not permit global read locks. If the Debezium MariaDB connector detects that global read locks are not permitted, the connector uses table-level locks when it performs snapshots. For the connector to perform a snapshot that uses table-level locks, the database account that the Debezium connector uses to connect to MariaDB must have LOCK TABLES privileges. Default workflow that the Debezium MariaDB connector uses to perform an initial snapshot with table-level locks The following table shows the steps in the workflow that Debezium follows to create a snapshot with table-level read locks. For information about the snapshot process in environments that do not permit global read locks, see the snapshot workflow for global read locks . Step Action 1 Establish a connection to the database. 2 Determine the tables to be captured. By default, the connector captures all non-system tables. To have the connector capture a subset of tables or table elements, you can set a number of include and exclude properties to filter the data, for example, table.include.list or table.exclude.list . 3 Obtain table-level locks. 4 5 Read the current binlog position. 6 Read the schema of the databases and tables for which the connector is configured to capture changes. The connector persists schema information in its internal database schema history topic, including all necessary DROP... and CREATE... DDL statements. The schema history provides information about the structure that is in effect when a change event occurs. Note By default, the connector captures the schema of every table in the database, including tables that are not configured for capture. If tables are not configured for capture, the initial snapshot captures only their structure; it does not capture any table data. For more information about why snapshots persist schema information for tables that you did not include in the initial snapshot, see Understanding why initial snapshots capture the schema for all tables . 7 At the binlog position that the connector read in Step 5, the connector begins to scan the tables that are designated for capture. During the scan, the connector completes the following tasks: Confirms that the table was created before the snapshot began. If the table was created after the snapshot began, the connector skips the table. After the snapshot is complete, and the connector transitions to streaming, it emits change events for any tables that were created after the snapshot began. Produces a read event for each row that is captured from a table. All read events contain the same binlog position, which is the position that was obtained in step 5. Emits each read event to the Kafka topic for the source table. Releases data table locks, if applicable. 8 Commit the transaction. 9 Release the table-level locks. Other database clients can now write to any previously locked tables. 10 Table 2.26. Settings for snapshot.mode connector configuration property Setting Description always The connector performs a snapshot every time that it starts. The snapshot includes the structure and data of the captured tables. Specify this value to populate topics with a complete representation of the data from the captured tables every time that the connector starts. After the snapshot completes, the connector begins to stream event records for subsequent database changes. initial The connector performs a database snapshot as described in the default workflow for creating an initial snapshot . After the snapshot completes, the connector begins to stream event records for subsequent database changes. initial_only The connector performs a database snapshot. After the snapshot completes, the connector stops, and does not stream event records for subsequent database changes. schema_only Deprecated, see no_data . no_data The connector captures the structure of all relevant tables, performing all the steps described in the default workflow for creating an initial snapshot , except that it does not create READ events to represent the data set at the point of the connector's start-up (Step 7.2). never When the connector starts, rather than performing a snapshot, it immediately begins to stream event records for subsequent database changes. This option is under consideration for future deprecation, in favor of the no_data option. schema_only_recovery Deprecated, see recovery . recovery Set this option to restore a database schema history topic that is lost or corrupted. After a restart, the connector runs a snapshot that rebuilds the topic from the source tables. You can also set the property to periodically prune a database schema history topic that experiences unexpected growth. WARNING: Do not use this mode to perform a snapshot if schema changes were committed to the database after the last connector shutdown. when_needed After the connector starts, it performs a snapshot only if it detects one of the following circumstances: It cannot detect any topic offsets. A previously recorded offset specifies a log position that is not available on the server. For more information, see snapshot.mode in the table of connector configuration properties. 2.2.1.4.3. Description of why initial snapshots capture the schema history for all tables The initial snapshot that a connector runs captures two types of information: Table data Information about INSERT , UPDATE , and DELETE operations in tables that are named in the connector's table.include.list property. Schema data DDL statements that describe the structural changes that are applied to tables. Schema data is persisted to both the internal schema history topic, and to the connector's schema change topic, if one is configured. After you run an initial snapshot, you might notice that the snapshot captures schema information for tables that are not designated for capture. By default, initial snapshots are designed to capture schema information for every table that is present in the database, not only from tables that are designated for capture. Connectors require that the table's schema is present in the schema history topic before they can capture a table. By enabling the initial snapshot to capture schema data for tables that are not part of the original capture set, Debezium prepares the connector to readily capture event data from these tables should that later become necessary. If the initial snapshot does not capture a table's schema, you must add the schema to the history topic before the connector can capture data from the table. In some cases, you might want to limit schema capture in the initial snapshot. This can be useful when you want to reduce the time required to complete a snapshot. Or when Debezium connects to the database instance through a user account that has access to multiple logical databases, but you want the connector to capture changes only from tables in a specific logic database. Additional information Capturing data from tables not captured by the initial snapshot (no schema change) Capturing data from tables not captured by the initial snapshot (schema change) Setting the schema.history.internal.store.only.captured.tables.ddl property to specify the tables from which to capture schema information. Setting the schema.history.internal.store.only.captured.databases.ddl property to specify the logical databases from which to capture schema changes. 2.2.1.4.4. Capturing data from tables not captured by the initial snapshot (no schema change) In some cases, you might want the connector to capture data from a table whose schema was not captured by the initial snapshot. Depending on the connector configuration, the initial snapshot might capture the table schema only for specific tables in the database. If the table schema is not present in the history topic, the connector fails to capture the table, and reports a missing schema error. You might still be able to capture data from the table, but you must perform additional steps to add the table schema. Prerequisites You want to capture data from a table with a schema that the connector did not capture during the initial snapshot. In the transaction log, all entries for the table use the same schema. For information about capturing data from a new table that has undergone structural changes, see Capturing data from tables not captured by the initial snapshot (schema change) . Procedure Stop the connector. Remove the internal database schema history topic that is specified by the schema.history.internal.kafka.topic property . Apply the following changes to the connector configuration: Set the snapshot.mode to schema_only_recovery . Set the value of schema.history.internal.store.only.captured.tables.ddl to false . Add the tables that you want the connector to capture to table.include.list . This guarantees that in the future, the connector can reconstruct the schema history for all tables. Restart the connector. The snapshot recovery process rebuilds the schema history based on the current structure of the tables. (Optional) After the snapshot completes, initiate an incremental snapshot to capture existing data for newly added tables along with changes to other tables that occurred while that connector was off-line. (Optional) Reset the snapshot.mode back to schema_only to prevent the connector from initiating recovery after a future restart. 2.2.1.4.5. Capturing data from tables not captured by the initial snapshot (schema change) If a schema change is applied to a table, records that are committed before the schema change have different structures than those that were committed after the change. When Debezium captures data from a table, it reads the schema history to ensure that it applies the correct schema to each event. If the schema is not present in the schema history topic, the connector is unable to capture the table, and an error results. If you want to capture data from a table that was not captured by the initial snapshot, and the schema of the table was modified, you must add the schema to the history topic, if it is not already available. You can add the schema by running a new schema snapshot, or by running an initial snapshot for the table. Prerequisites You want to capture data from a table with a schema that the connector did not capture during the initial snapshot. A schema change was applied to the table so that the records to be captured do not have a uniform structure. Procedure Initial snapshot captured the schema for all tables ( store.only.captured.tables.ddl was set to false ) Edit the table.include.list property to specify the tables that you want to capture. Restart the connector. Initiate an incremental snapshot if you want to capture existing data from the newly added tables. Initial snapshot did not capture the schema for all tables ( store.only.captured.tables.ddl was set to true ) If the initial snapshot did not save the schema of the table that you want to capture, complete one of the following procedures: Procedure 1: Schema snapshot, followed by incremental snapshot In this procedure, the connector first performs a schema snapshot. You can then initiate an incremental snapshot to enable the connector to synchronize data. Stop the connector. Remove the internal database schema history topic that is specified by the schema.history.internal.kafka.topic property . Clear the offsets in the configured Kafka Connect offset.storage.topic . For more information about how to remove offsets, see the Debezium community FAQ . Warning Removing offsets should be performed only by advanced users who have experience in manipulating internal Kafka Connect data. This operation is potentially destructive, and should be performed only as a last resort. Set values for properties in the connector configuration as described in the following steps: Set the value of the snapshot.mode property to schema_only . Edit the table.include.list to add the tables that you want to capture. Restart the connector. Wait for Debezium to capture the schema of the new and existing tables. Data changes that occurred any tables after the connector stopped are not captured. To ensure that no data is lost, initiate an incremental snapshot . Procedure 2: Initial snapshot, followed by optional incremental snapshot In this procedure the connector performs a full initial snapshot of the database. As with any initial snapshot, in a database with many large tables, running an initial snapshot can be a time-consuming operation. After the snapshot completes, you can optionally trigger an incremental snapshot to capture any changes that occur while the connector is off-line. Stop the connector. Remove the internal database schema history topic that is specified by the schema.history.internal.kafka.topic property . Clear the offsets in the configured Kafka Connect offset.storage.topic . For more information about how to remove offsets, see the Debezium community FAQ . Warning Removing offsets should be performed only by advanced users who have experience in manipulating internal Kafka Connect data. This operation is potentially destructive, and should be performed only as a last resort. Edit the table.include.list to add the tables that you want to capture. Set values for properties in the connector configuration as described in the following steps: Set the value of the snapshot.mode property to initial . (Optional) Set schema.history.internal.store.only.captured.tables.ddl to false . Restart the connector. The connector takes a full database snapshot. After the snapshot completes, the connector transitions to streaming. (Optional) To capture any data that changed while the connector was off-line, initiate an incremental snapshot . 2.2.1.5. Ad hoc snapshots By default, a connector runs an initial snapshot operation only after it starts for the first time. Following this initial snapshot, under normal circumstances, the connector does not repeat the snapshot process. Any future change event data that the connector captures comes in through the streaming process only. However, in some situations the data that the connector obtained during the initial snapshot might become stale, lost, or incomplete. To provide a mechanism for recapturing table data, Debezium includes an option to perform ad hoc snapshots. You might want to perform an ad hoc snapshot after any of the following changes occur in your Debezium environment: The connector configuration is modified to capture a different set of tables. Kafka topics are deleted and must be rebuilt. Data corruption occurs due to a configuration error or some other problem. You can re-run a snapshot for a table for which you previously captured a snapshot by initiating a so-called ad-hoc snapshot . Ad hoc snapshots require the use of signaling tables . You initiate an ad hoc snapshot by sending a signal request to the Debezium signaling table. When you initiate an ad hoc snapshot of an existing table, the connector appends content to the topic that already exists for the table. If a previously existing topic was removed, Debezium can create a topic automatically if automatic topic creation is enabled. Ad hoc snapshot signals specify the tables to include in the snapshot. The snapshot can capture the entire contents of the database, or capture only a subset of the tables in the database. Also, the snapshot can capture a subset of the contents of the table(s) in the database. You specify the tables to capture by sending an execute-snapshot message to the signaling table. Set the type of the execute-snapshot signal to incremental or blocking , and provide the names of the tables to include in the snapshot, as described in the following table: Table 2.27. Example of an ad hoc execute-snapshot signal record Field Default Value type incremental Specifies the type of snapshot that you want to run. Currently, you can request incremental or blocking snapshots. data-collections N/A An array that contains regular expressions matching the fully-qualified names of the tables to include in the snapshot. For the MariaDB connector, use the following format to specify the fully qualified name of a table: database.table . additional-conditions N/A An optional array that specifies a set of additional conditions that the connector evaluates to determine the subset of records to include in a snapshot. Each additional condition is an object that specifies the criteria for filtering the data that an ad hoc snapshot captures. You can set the following parameters for each additional condition: data-collection The fully-qualified name of the table that the filter applies to. You can apply different filters to each table. filter Specifies column values that must be present in a database record for the snapshot to include it, for example, "color='blue'" . The values that you assign to the filter parameter are the same types of values that you might specify in the WHERE clause of SELECT statements when you set the snapshot.select.statement.overrides property for a blocking snapshot. surrogate-key N/A An optional string that specifies the column name that the connector uses as the primary key of a table during the snapshot process. Triggering an ad hoc incremental snapshot You initiate an ad hoc incremental snapshot by adding an entry with the execute-snapshot signal type to the signaling table, or by sending a signal message to a Kafka signaling topic . After the connector processes the message, it begins the snapshot operation. The snapshot process reads the first and last primary key values and uses those values as the start and end point for each table. Based on the number of entries in the table, and the configured chunk size, Debezium divides the table into chunks, and proceeds to snapshot each chunk, in succession, one at a time. For more information, see Incremental snapshots . Triggering an ad hoc blocking snapshot You initiate an ad hoc blocking snapshot by adding an entry with the execute-snapshot signal type to the signaling table or signaling topic. After the connector processes the message, it begins the snapshot operation. The connector temporarily stops streaming, and then initiates a snapshot of the specified table, following the same process that it uses during an initial snapshot. After the snapshot completes, the connector resumes streaming. For more information, see Blocking snapshots . 2.2.1.6. Incremental snapshots To provide flexibility in managing snapshots, Debezium includes a supplementary snapshot mechanism, known as incremental snapshotting . Incremental snapshots rely on the Debezium mechanism for sending signals to a Debezium connector . In an incremental snapshot, instead of capturing the full state of a database all at once, as in an initial snapshot, Debezium captures each table in phases, in a series of configurable chunks. You can specify the tables that you want the snapshot to capture and the size of each chunk . The chunk size determines the number of rows that the snapshot collects during each fetch operation on the database. The default chunk size for incremental snapshots is 1024 rows. As an incremental snapshot proceeds, Debezium uses watermarks to track its progress, maintaining a record of each table row that it captures. This phased approach to capturing data provides the following advantages over the standard initial snapshot process: You can run incremental snapshots in parallel with streamed data capture, instead of postponing streaming until the snapshot completes. The connector continues to capture near real-time events from the change log throughout the snapshot process, and neither operation blocks the other. If the progress of an incremental snapshot is interrupted, you can resume it without losing any data. After the process resumes, the snapshot begins at the point where it stopped, rather than recapturing the table from the beginning. You can run an incremental snapshot on demand at any time, and repeat the process as needed to adapt to database updates. For example, you might re-run a snapshot after you modify the connector configuration to add a table to its table.include.list property. Incremental snapshot process When you run an incremental snapshot, Debezium sorts each table by primary key and then splits the table into chunks based on the configured chunk size . Working chunk by chunk, it then captures each table row in a chunk. For each row that it captures, the snapshot emits a READ event. That event represents the value of the row when the snapshot for the chunk began. As a snapshot proceeds, it's likely that other processes continue to access the database, potentially modifying table records. To reflect such changes, INSERT , UPDATE , or DELETE operations are committed to the transaction log as per usual. Similarly, the ongoing Debezium streaming process continues to detect these change events and emits corresponding change event records to Kafka. How Debezium resolves collisions among records with the same primary key In some cases, the UPDATE or DELETE events that the streaming process emits are received out of sequence. That is, the streaming process might emit an event that modifies a table row before the snapshot captures the chunk that contains the READ event for that row. When the snapshot eventually emits the corresponding READ event for the row, its value is already superseded. To ensure that incremental snapshot events that arrive out of sequence are processed in the correct logical order, Debezium employs a buffering scheme for resolving collisions. Only after collisions between the snapshot events and the streamed events are resolved does Debezium emit an event record to Kafka. Snapshot window To assist in resolving collisions between late-arriving READ events and streamed events that modify the same table row, Debezium employs a so-called snapshot window . The snapshot window demarcates the interval during which an incremental snapshot captures data for a specified table chunk. Before the snapshot window for a chunk opens, Debezium follows its usual behavior and emits events from the transaction log directly downstream to the target Kafka topic. But from the moment that the snapshot for a particular chunk opens, until it closes, Debezium performs a de-duplication step to resolve collisions between events that have the same primary key.. For each data collection, the Debezium emits two types of events, and stores the records for them both in a single destination Kafka topic. The snapshot records that it captures directly from a table are emitted as READ operations. Meanwhile, as users continue to update records in the data collection, and the transaction log is updated to reflect each commit, Debezium emits UPDATE or DELETE operations for each change. As the snapshot window opens, and Debezium begins processing a snapshot chunk, it delivers snapshot records to a memory buffer. During the snapshot windows, the primary keys of the READ events in the buffer are compared to the primary keys of the incoming streamed events. If no match is found, the streamed event record is sent directly to Kafka. If Debezium detects a match, it discards the buffered READ event, and writes the streamed record to the destination topic, because the streamed event logically supersede the static snapshot event. After the snapshot window for the chunk closes, the buffer contains only READ events for which no related transaction log events exist. Debezium emits these remaining READ events to the table's Kafka topic. The connector repeats the process for each snapshot chunk. Currently, you can use either of the following methods to initiate an incremental snapshot: Send an ad hoc snapshot signal to the signaling table on the source database . Send a message to a configured Kafka signaling topic . 2.2.1.6.1. Triggering an incremental snapshot To initiate an incremental snapshot, you can send an ad hoc snapshot signal to the signaling table on the source database. You submit snapshot signals as SQL INSERT queries. After Debezium detects the change in the signaling table, it reads the signal, and runs the requested snapshot operation. The query that you submit specifies the tables to include in the snapshot, and, optionally, specifies the type of snapshot operation. Debezium currently supports the incremental and blocking snapshot types. To specify the tables to include in the snapshot, provide a data-collections array that lists the tables, or an array of regular expressions used to match tables, for example, {"data-collections": ["public.MyFirstTable", "public.MySecondTable"]} The data-collections array for an incremental snapshot signal has no default value. If the data-collections array is empty, Debezium interprets the empty array to mean that no action is required, and it does not perform a snapshot. Note If the name of a table that you want to include in a snapshot contains a dot ( . ), a space, or some other non-alphanumeric character, you must escape the table name in double quotes. For example, to include a table that exists in the db1 database, and that has the name My.Table , use the following format: "db1.\"My.Table\"" . Prerequisites Signaling is enabled . A signaling data collection exists on the source database. The signaling data collection is specified in the signal.data.collection property. Using a source signaling channel to trigger an incremental snapshot Send a SQL query to add the ad hoc incremental snapshot request to the signaling table: INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}'); For example, INSERT INTO db1.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'execute-snapshot', 3 '{"data-collections": ["db1.table1", "db1.table2"], 4 "type":"incremental", 5 "additional-conditions":[{"data-collection": "db1.table1" ,"filter":"color=\'blue\'"}]}'); 6 The values of the id , type , and data parameters in the command correspond to the fields of the signaling table . The following table describes the parameters in the example: Table 2.28. Descriptions of fields in a SQL command for sending an incremental snapshot signal to the signaling table Item Value Description 1 database.debezium_signal Specifies the fully-qualified name of the signaling table on the source database. 2 ad-hoc-1 The id parameter specifies an arbitrary string that is assigned as the id identifier for the signal request. Use this string to identify logging messages to entries in the signaling table. Debezium does not use this string. Rather, during the snapshot, Debezium generates its own id string as a watermarking signal. 3 execute-snapshot The type parameter specifies the operation that the signal is intended to trigger. 4 data-collections A required component of the data field of a signal that specifies an array of table names or regular expressions to match table names to include in the snapshot. The array lists regular expressions that use the format database.table to match the fully-qualified names of the tables. This format is the same as the one that you use to specify the name of the connector's signaling table . 5 incremental An optional type component of the data field of a signal that specifies the type of snapshot operation to run. Valid values are incremental and blocking . If you do not specify a value, the connector defaults to performing an incremental snapshot. 6 additional-conditions An optional array that specifies a set of additional conditions that the connector evaluates to determine the subset of records to include in a snapshot. Each additional condition is an object with data-collection and filter properties. You can specify different filters for each data collection. * The data-collection property is the fully-qualified name of the data collection that the filter applies to. For more information about the additional-conditions parameter, see Running an ad hoc incremental snapshots with additional-conditions . Running an ad hoc incremental snapshots with additional-conditions If you want a snapshot to include only a subset of the content in a table, you can modify the signal request by appending an additional-conditions parameter to the snapshot signal. The SQL query for a typical snapshot takes the following form: SELECT * FROM <tableName> .... By adding an additional-conditions parameter, you append a WHERE condition to the SQL query, as in the following example: SELECT * FROM <data-collection> WHERE <filter> .... The following example shows a SQL query to send an ad hoc incremental snapshot request with an additional condition to the signaling table: INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}'); For example, suppose you have a products table that contains the following columns: id (primary key) color quantity If you want an incremental snapshot of the products table to include only the data items where color=blue , you can use the following SQL statement to trigger the snapshot: INSERT INTO db1.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["db1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "db1.products", "filter": "color=blue"}]}'); The additional-conditions parameter also enables you to pass conditions that are based on more than one column. For example, using the products table from the example, you can submit a query that triggers an incremental snapshot that includes the data of only those items for which color=blue and quantity>10 : INSERT INTO db1.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["db1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "db1.products", "filter": "color=blue AND quantity>10"}]}'); The following example, shows the JSON for an incremental snapshot event that is captured by a connector. Example 2.9. Incremental snapshot event message { "before":null, "after": { "pk":"1", "value":"New data" }, "source": { ... "snapshot":"incremental" 1 }, "op":"r", 2 "ts_ms":"1620393591654", "ts_us":"1620393591654547", "ts_ns":"1620393591654547920", "transaction":null } Table 2.29. Description of fields in an incremental snapshot event message Item Field name Description 1 snapshot Specifies the type of snapshot operation to run. Currently, the only valid options are blocking and incremental . Specifying a type value in the SQL query that you submit to the signaling table is optional. If you do not specify a value, the connector runs an incremental snapshot. 2 op Specifies the event type. The value for snapshot events is r , signifying a READ operation. 2.2.1.6.2. Using the Kafka signaling channel to trigger an incremental snapshot You can send a message to the configured Kafka topic to request the connector to run an ad hoc incremental snapshot. The key of the Kafka message must match the value of the topic.prefix connector configuration option. The value of the message is a JSON object with type and data fields. The signal type is execute-snapshot , and the data field must have the following fields: Table 2.30. Execute snapshot data fields Field Default Value type incremental The type of the snapshot to be executed. Currently Debezium supports the incremental and blocking types. See the section for more details. data-collections N/A An array of comma-separated regular expressions that match the fully-qualified names of tables to include in the snapshot. Specify the names by using the same format as is required for the signal.data.collection configuration option. additional-conditions N/A An optional array of additional conditions that specifies criteria that the connector evaluates to designate a subset of records to include in a snapshot. Each additional condition is an object that specifies the criteria for filtering the data that an ad hoc snapshot captures. You can set the following parameters for each additional condition: data-collection :: The fully-qualified name of the table that the filter applies to. You can apply different filters to each table. filter :: Specifies column values that must be present in a database record for the snapshot to include it, for example, "color='blue'" . The values that you assign to the filter parameter are the same types of values that you might specify in the WHERE clause of SELECT statements when you set the snapshot.select.statement.overrides property for a blocking snapshot. Example 2.10. An execute-snapshot Kafka message Ad hoc incremental snapshots with additional-conditions Debezium uses the additional-conditions field to select a subset of a table's content. Typically, when Debezium runs a snapshot, it runs a SQL query such as: SELECT * FROM <tableName> ... . When the snapshot request includes an additional-conditions property, the data-collection and filter parameters of the property are appended to the SQL query, for example: SELECT * FROM <data-collection> WHERE <filter> ... . For example, given a products table with the columns id (primary key), color , and brand , if you want a snapshot to include only content for which color='blue' , when you request the snapshot, you could add the additional-conditions property to filter the content: Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["db1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "db1.products" ,"filter":"color='blue'"}]}}` You can also use the additional-conditions property to pass conditions based on multiple columns. For example, using the same products table as in the example, if you want a snapshot to include only the content from the products table for which color='blue' , and brand='MyBrand' , you could send the following request: Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["db1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "db1.products" ,"filter":"color='blue' AND brand='MyBrand'"}]}}` 2.2.1.6.3. Stopping an incremental snapshot In some situations, it might be necessary to stop an incremental snapshot. For example, you might realize that snapshot was not configured correctly, or maybe you want to ensure that resources are available for other database operations. You can stop a snapshot that is already running by sending a signal to the signaling table on the source database. You submit a stop snapshot signal to the signaling table by sending it in a SQL INSERT query. The stop-snapshot signal specifies the type of the snapshot operation as incremental , and optionally specifies the tables that you want to omit from the currently running snapshot. After Debezium detects the change in the signaling table, it reads the signal, and stops the incremental snapshot operation if it's in progress. Additional resources You can also stop an incremental snapshot by sending a JSON message to the Kafka signaling topic . Prerequisites Signaling is enabled . A signaling data collection exists on the source database. The signaling data collection is specified in the signal.data.collection property. Using a source signaling channel to stop an incremental snapshot Send a SQL query to stop the ad hoc incremental snapshot to the signaling table: INSERT INTO <signalTable> (id, type, data) values ( '<id>' , 'stop-snapshot', '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":"incremental"}'); For example, INSERT INTO db1.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'stop-snapshot', 3 '{"data-collections": ["db1.table1", "db1.table2"], 4 "type":"incremental"}'); 5 The values of the id , type , and data parameters in the signal command correspond to the fields of the signaling table . The following table describes the parameters in the example: Table 2.31. Descriptions of fields in a SQL command for sending a stop incremental snapshot signal to the signaling table Item Value Description 1 database.debezium_signal Specifies the fully-qualified name of the signaling table on the source database. 2 ad-hoc-1 The id parameter specifies an arbitrary string that is assigned as the id identifier for the signal request. Use this string to identify logging messages to entries in the signaling table. Debezium does not use this string. 3 stop-snapshot Specifies type parameter specifies the operation that the signal is intended to trigger. 4 data-collections An optional component of the data field of a signal that specifies an array of table names or regular expressions to match table names to remove from the snapshot. The array lists regular expressions which match tables by their fully-qualified names in the format database.table If you omit this component from the data field, the signal stops the entire incremental snapshot that is in progress. 5 incremental A required component of the data field of a signal that specifies the type of snapshot operation that is to be stopped. Currently, the only valid option is incremental . If you do not specify a type value, the signal fails to stop the incremental snapshot. 2.2.1.6.4. Using the Kafka signaling channel to stop an incremental snapshot You can send a signal message to the configured Kafka signaling topic to stop an ad hoc incremental snapshot. The key of the Kafka message must match the value of the topic.prefix connector configuration option. The value of the message is a JSON object with type and data fields. The signal type is stop-snapshot , and the data field must have the following fields: Table 2.32. Execute snapshot data fields Field Default Value type incremental The type of the snapshot to be executed. Currently Debezium supports only the incremental type. See the section for more details. data-collections N/A An optional array of comma-separated regular expressions that match the fully-qualified names of the tables an array of table names or regular expressions to match table names to remove from the snapshot. Specify table names by using the format database.table . The following example shows a typical stop-snapshot Kafka message: Key = `test_connector` Value = `{"type":"stop-snapshot","data": {"data-collections": ["db1.table1", "db1.table2"], "type": "INCREMENTAL"}}` 2.2.1.7. Blocking snapshots To provide more flexibility in managing snapshots, Debezium includes a supplementary ad hoc snapshot mechanism, known as a blocking snapshot . Blocking snapshots rely on the Debezium mechanism for sending signals to a Debezium connector . A blocking snapshot behaves just like an initial snapshot , except that you can trigger it at run time. You might want to run a blocking snapshot rather than use the standard initial snapshot process in the following situations: You add a new table and you want to complete the snapshot while the connector is running. You add a large table, and you want the snapshot to complete in less time than is possible with an incremental snapshot. Blocking snapshot process When you run a blocking snapshot, Debezium stops streaming, and then initiates a snapshot of the specified table, following the same process that it uses during an initial snapshot. After the snapshot completes, the streaming is resumed. Configure snapshot You can set the following properties in the data component of a signal: data-collections: to specify which tables must be snapshot additional-conditions: You can specify different filters for different table. The data-collection property is the fully-qualified name of the table for which the filter will be applied. The filter property will have the same value used in the snapshot.select.statement.overrides For example: {"type": "blocking", "data-collections": ["schema1.table1", "schema1.table2"], "additional-conditions": [{"data-collection": "schema1.table1", "filter": "SELECT * FROM [schema1].[table1] WHERE column1 = 0 ORDER BY column2 DESC"}, {"data-collection": "schema1.table2", "filter": "SELECT * FROM [schema1].[table2] WHERE column2 > 0"}]} Possible duplicates A delay might exist between the time that you send the signal to trigger the snapshot, and the time when streaming stops and the snapshot starts. As a result of this delay, after the snapshot completes, the connector might emit some event records that duplicate records captured by the snapshot. 2.2.1.8. Default names of Kafka topics that receive Debezium MariaDB change event records By default, the MariaDB connector writes change events for all of the INSERT , UPDATE , and DELETE operations that occur in a table to a single Apache Kafka topic that is specific to that table. The connector uses the following convention to name change event topics: topicPrefix.databaseName.tableName Suppose that fulfillment is the topic prefix, inventory is the database name, and the database contains tables named orders , customers , and products . The Debezium MariaDB connector emits events to three Kafka topics, one for each table in the database: The following list provides definitions for the components of the default name: topicPrefix The topic prefix as specified by the topic.prefix connector configuration property. schemaName The name of the schema in which the operation occurred. tableName The name of the table in which the operation occurred. The connector applies similar naming conventions to label its internal database schema history topics, schema change topics , and transaction metadata topics . If the default topic name do not meet your requirements, you can configure custom topic names. To configure custom topic names, you specify regular expressions in the logical topic routing SMT. For more information about using the logical topic routing SMT to customize topic naming, see Topic routing . Transaction metadata Debezium can generate events that represent transaction boundaries and that enrich data change event messages. Limits on when Debezium receives transaction metadata Debezium registers and receives metadata only for transactions that occur after you deploy the connector. Metadata for transactions that occur before you deploy the connector is not available. Debezium generates transaction boundary events for the BEGIN and END delimiters in every transaction. Transaction boundary events contain the following fields: status BEGIN or END . id String representation of the unique transaction identifier. ts_ms The time of a transaction boundary event ( BEGIN or END event) at the data source. If the data source does not provide Debezium with the event time, then the field instead represents the time at which Debezium processes the event. event_count (for END events) Total number of events emitted by the transaction. data_collections (for END events) An array of pairs of data_collection and event_count elements that indicates the number of events that the connector emits for changes that originate from a data collection. Example { "status": "BEGIN", "id": "0e4d5dcd-a33b-11ea-80f1-02010a22a99e:10", "ts_ms": 1486500577125, "event_count": null, "data_collections": null } { "status": "END", "id": "0e4d5dcd-a33b-11ea-80f1-02010a22a99e:10", "ts_ms": 1486500577691, "event_count": 2, "data_collections": [ { "data_collection": "s1.a", "event_count": 1 }, { "data_collection": "s2.a", "event_count": 1 } ] } Unless overridden via the topic.transaction option, the connector emits transaction events to the <topic.prefix> .transaction topic. Change data event enrichment When transaction metadata is enabled the data message Envelope is enriched with a new transaction field. This field provides information about every event in the form of a composite of fields: id String representation of unique transaction identifier. total_order The absolute position of the event among all events generated by the transaction. data_collection_order The per-data collection position of the event among all events that were emitted by the transaction. Following is an example of a message: { "before": null, "after": { "pk": "2", "aa": "1" }, "source": { ... }, "op": "c", "ts_ms": "1580390884335", "ts_us": "1580390884335472", "ts_ns": "1580390884335472987", "transaction": { "id": "0e4d5dcd-a33b-11ea-80f1-02010a22a99e:10", "total_order": "1", "data_collection_order": "1" } } 2.2.2. Descriptions of Debezium MariaDB connector data change events The Debezium MariaDB connector generates a data change event for each row-level INSERT , UPDATE , and DELETE operation. Each event contains a key and a value. The structure of the key and the value depends on the table that was changed. Debezium and Kafka Connect are designed around continuous streams of event messages . However, the structure of these events may change over time, which can be difficult for consumers to handle. To address this, each event contains the schema for its content or, if you are using a schema registry, a schema ID that a consumer can use to obtain the schema from the registry. This makes each event self-contained. The following skeleton JSON shows the basic four parts of a change event. However, how you configure the Kafka Connect converter that you choose to use in your application determines the representation of these four parts in change events. A schema field is in a change event only when you configure the converter to produce it. Likewise, the event key and event payload are in a change event only if you configure a converter to produce it. If you use the JSON converter and you configure it to produce all four basic change event parts, change events have this structure: { "schema": { 1 ... }, "payload": { 2 ... }, "schema": { 3 ... }, "payload": { 4 ... }, } Table 2.33. Overview of change event basic content Item Field name Description 1 schema The first schema field is part of the event key. It specifies a Kafka Connect schema that describes what is in the event key's payload portion. In other words, the first schema field describes the structure of the primary key, or the unique key if the table does not have a primary key, for the table that was changed. It is possible to override the table's primary key by setting the message.key.columns connector configuration property . In this case, the first schema field describes the structure of the key identified by that property. 2 payload The first payload field is part of the event key. It has the structure described by the schema field, and it contains the key for the row that was changed. 3 schema The second schema field is part of the event value. It specifies the Kafka Connect schema that describes what is in the event value's payload portion. In other words, the second schema describes the structure of the row that was changed. Typically, this schema contains nested schemas. 4 payload The second payload field is part of the event value. It has the structure described by the schema field and it contains the actual data for the row that was changed. By default, the connector streams change event records to topics with names that are the same as the event's originating table. See topic names . Warning The MariaDB connector ensures that all Kafka Connect schema names adhere to the Avro schema name format . This means that the logical server name must start with a Latin letter or an underscore, that is, a-z, A-Z, or _. Each remaining character in the logical server name and each character in the database and table names must be a Latin letter, a digit, or an underscore, that is, a-z, A-Z, 0-9, or _. If there is an invalid character it is replaced with an underscore character. This can lead to unexpected conflicts if the logical server name, a database name, or a table name contains invalid characters, and the only characters that distinguish names from one another are invalid and thus replaced with underscores. More details are in the following topics: Section 2.2.2.1, "About keys in Debezium MariaDB change events" Section 2.2.2.2, "About values in Debezium MariaDB change events" 2.2.2.1. About keys in Debezium MariaDB change events A change event's key contains the schema for the changed table's key and the changed row's actual key. Both the schema and its corresponding payload contain a field for each column in the changed table's PRIMARY KEY (or unique constraint) at the time the connector created the event. Consider the following customers table, which is followed by an example of a change event key for this table. CREATE TABLE customers ( id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY, first_name VARCHAR(255) NOT NULL, last_name VARCHAR(255) NOT NULL, email VARCHAR(255) NOT NULL UNIQUE KEY ) AUTO_INCREMENT=1001; Every change event that captures a change to the customers table has the same event key schema. For as long as the customers table has the definition, every change event that captures a change to the customers table has the following key structure. In JSON, it looks like this: { "schema": { 1 "type": "struct", "name": "mariadb-server-1.inventory.customers.Key", 2 "optional": false, 3 "fields": [ 4 { "field": "id", "type": "int32", "optional": false } ] }, "payload": { 5 "id": 1001 } } Table 2.34. Description of change event key Item Field name Description 1 schema The schema portion of the key specifies a Kafka Connect schema that describes what is in the key's payload portion. 2 mariadb-server-1.inventory.customers.Key Name of the schema that defines the structure of the key's payload. This schema describes the structure of the primary key for the table that was changed. Key schema names have the format connector-name . database-name . table-name . Key . In this example: mariadb-server-1 is the name of the connector that generated this event. inventory is the database that contains the table that was changed. customers is the table that was updated. 3 optional Indicates whether the event key must contain a value in its payload field. In this example, a value in the key's payload is required. A value in the key's payload field is optional when a table does not have a primary key. 4 fields Specifies each field that is expected in the payload , including each field's name, type, and whether it is required. 5 payload Contains the key for the row for which this change event was generated. In this example, the key, contains a single id field whose value is 1001 . 2.2.2.2. About values in Debezium MariaDB change events The value in a change event is a bit more complicated than the key. Like the key, the value has a schema section and a payload section. The schema section contains the schema that describes the Envelope structure of the payload section, including its nested fields. Change events for operations that create, update or delete data all have a value payload with an envelope structure. Consider the same sample table that was used to show an example of a change event key: CREATE TABLE customers ( id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY, first_name VARCHAR(255) NOT NULL, last_name VARCHAR(255) NOT NULL, email VARCHAR(255) NOT NULL UNIQUE KEY ) AUTO_INCREMENT=1001; The value portion of a change event for a change to this table is described for: create events update events Primary key updates delete events Tombstone events truncate events create events The following example shows the value portion of a change event that the connector generates for an operation that creates data in the customers table: { "schema": { 1 "type": "struct", "fields": [ { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "id" }, { "type": "string", "optional": false, "field": "first_name" }, { "type": "string", "optional": false, "field": "last_name" }, { "type": "string", "optional": false, "field": "email" } ], "optional": true, "name": "mariadb-server-1.inventory.customers.Value", 2 "field": "before" }, { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "id" }, { "type": "string", "optional": false, "field": "first_name" }, { "type": "string", "optional": false, "field": "last_name" }, { "type": "string", "optional": false, "field": "email" } ], "optional": true, "name": "mariadb-server-1.inventory.customers.Value", "field": "after" }, { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "version" }, { "type": "string", "optional": false, "field": "connector" }, { "type": "string", "optional": false, "field": "name" }, { "type": "int64", "optional": false, "field": "ts_ms" }, { "type": "int64", "optional": false, "field": "ts_us" }, { "type": "int64", "optional": false, "field": "ts_ns" }, { "type": "boolean", "optional": true, "default": false, "field": "snapshot" }, { "type": "string", "optional": false, "field": "db" }, { "type": "string", "optional": true, "field": "table" }, { "type": "int64", "optional": false, "field": "server_id" }, { "type": "string", "optional": true, "field": "gtid" }, { "type": "string", "optional": false, "field": "file" }, { "type": "int64", "optional": false, "field": "pos" }, { "type": "int32", "optional": false, "field": "row" }, { "type": "int64", "optional": true, "field": "thread" }, { "type": "string", "optional": true, "field": "query" } ], "optional": false, "name": "io.debezium.connector.mariadb.Source", 3 "field": "source" }, { "type": "string", "optional": false, "field": "op" }, { "type": "int64", "optional": true, "field": "ts_ms" }, { "type": "int64", "optional": true, "field": "ts_us" }, { "type": "int64", "optional": true, "field": "ts_ns" } ], "optional": false, "name": "mariadb-server-1.inventory.customers.Envelope" 4 }, "payload": { 5 "op": "c", 6 "ts_ms": 1465491411815, 7 "ts_us": 1465491411815437, 8 "ts_ns": 1465491411815437158, 9 "before": null, 10 "after": { 11 "id": 1004, "first_name": "Anne", "last_name": "Kretchmar", "email": "annek@noanswer.org" }, "source": { 12 "version": "2.7.3.Final", "connector": "mariadb", "name": "mariadb-server-1", "ts_ms": 0, "ts_us": 0, "ts_ns": 0, "snapshot": false, "db": "inventory", "table": "customers", "server_id": 0, "gtid": null, "file": "mariadb-bin.000003", "pos": 154, "row": 0, "thread": 7, "query": "INSERT INTO customers (first_name, last_name, email) VALUES ('Anne', 'Kretchmar', 'annek@noanswer.org')" } } } Table 2.35. Descriptions of create event value fields Item Field name Description 1 schema The value's schema, which describes the structure of the value's payload. A change event's value schema is the same in every change event that the connector generates for a particular table. 2 name In the schema section, each name field specifies the schema for a field in the value's payload. mariadb-server-1.inventory.customers.Value is the schema for the payload's before and after fields. This schema is specific to the customers table. Names of schemas for before and after fields are of the form logicalName . tableName .Value , which ensures that the schema name is unique in the database. This means that when using the Avro converter , the resulting Avro schema for each table in each logical source has its own evolution and history. 3 name io.debezium.connector.mariadb.Source is the schema for the payload's source field. This schema is specific to the MariaDB connector. The connector uses it for all events that it generates. 4 name mariadb-server-1.inventory.customers.Envelope is the schema for the overall structure of the payload, where mariadb-server-1 is the connector name, inventory is the database, and customers is the table. 5 payload The value's actual data. This is the information that the change event is providing. It may appear that the JSON representations of the events are much larger than the rows they describe. This is because the JSON representation must include the schema and the payload portions of the message. However, by using the Avro converter , you can significantly decrease the size of the messages that the connector streams to Kafka topics. 6 op Mandatory string that describes the type of operation that caused the connector to generate the event. In this example, c indicates that the operation created a row. Valid values are: c = create u = update d = delete r = read (applies to only snapshots) 7 ts_ms , ts_us , ts_ns Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. 8 before An optional field that specifies the state of the row before the event occurred. When the op field is c for create, as it is in this example, the before field is null since this change event is for new content. 9 after An optional field that specifies the state of the row after the event occurred. In this example, the after field contains the values of the new row's id , first_name , last_name , and email columns. 10 source Mandatory field that describes the source metadata for the event. This field contains information that you can use to compare this event with other events, with regard to the origin of the events, the order in which the events occurred, and whether events were part of the same transaction. The source metadata includes: Debezium version Connector name binlog name where the event was recorded binlog position Row within the event If the event was part of a snapshot Name of the database and table that contain the new row ID of the MariaDB thread that created the event (non-snapshot only) MariaDB server ID (if available) Timestamp for when the change was made in the database update events The value of a change event for an update in the sample customers table has the same schema as a create event for that table. Likewise, the event value's payload has the same structure. However, the event value payload contains different values in an update event. Here is an example of a change event value in an event that the connector generates for an update in the customers table: { "schema": { ... }, "payload": { "before": { 1 "id": 1004, "first_name": "Anne", "last_name": "Kretchmar", "email": "annek@noanswer.org" }, "after": { 2 "id": 1004, "first_name": "Anne Marie", "last_name": "Kretchmar", "email": "annek@noanswer.org" }, "source": { 3 "version": "2.7.3.Final", "name": "mariadb-server-1", "connector": "mariadb", "name": "mariadb-server-1", "ts_ms": 1465581029100, "ts_ms": 1465581029100000, "ts_ms": 1465581029100000000, "snapshot": false, "db": "inventory", "table": "customers", "server_id": 223344, "gtid": null, "file": "mariadb-bin.000003", "pos": 484, "row": 0, "thread": 7, "query": "UPDATE customers SET first_name='Anne Marie' WHERE id=1004" }, "op": "u", 4 "ts_ms": 1465581029523, 5 "ts_ms": 1465581029523758, 6 "ts_ms": 1465581029523758914 7 } } Table 2.36. Descriptions of update event value fields Item Field name Description 1 before An optional field that specifies the state of the row before the event occurred. In an update event value, the before field contains a field for each table column and the value that was in that column before the database commit. In this example, the first_name value is Anne. 2 after An optional field that specifies the state of the row after the event occurred. You can compare the before and after structures to determine what the update to this row was. In the example, the first_name value is now Anne Marie . 3 source Mandatory field that describes the source metadata for the event. The source field structure has the same fields as in a create event, but some values are different, for example, the sample update event is from a different position in the binlog. The source metadata includes: Debezium version Connector name binlog name where the event was recorded binlog position Row within the event If the event was part of a snapshot Name of the database and table that contain the updated row ID of the MariaDB thread that created the event (non-snapshot only) MariaDB server ID (if available) Timestamp for when the change was made in the database 4 op Mandatory string that describes the type of operation. In an update event value, the op field value is u , signifying that this row changed because of an update. 5 ts_ms Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. 6 ts_us Optional field that displays the time at which the connector processed the event, in microseconds. The time is based on the system clock in the JVM running the Kafka Connect task. 7 ts_ns Optional field that displays the time at which the connector processed the event, in nanoseconds. The time is based on the system clock in the JVM running the Kafka Connect task. Note Updating the columns for a row's primary/unique key changes the value of the row's key. When a key changes, Debezium outputs three events: a DELETE event and a tombstone event with the old key for the row, followed by an event with the new key for the row. Details are in the section. Primary key updates An UPDATE operation that changes a row's primary key field(s) is known as a primary key change. For a primary key change, in place of an UPDATE event record, the connector emits a DELETE event record for the old key and a CREATE event record for the new (updated) key. These events have the usual structure and content, and in addition, each one has a message header related to the primary key change: The DELETE event record has __debezium.newkey as a message header. The value of this header is the new primary key for the updated row. The CREATE event record has __debezium.oldkey as a message header. The value of this header is the (old) primary key that the updated row had. delete events The value in a delete change event has the same schema portion as create and update events for the same table. The payload portion in a delete event for the sample customers table looks like this: { "schema": { ... }, "payload": { "before": { 1 "id": 1004, "first_name": "Anne Marie", "last_name": "Kretchmar", "email": "annek@noanswer.org" }, "after": null, 2 "source": { 3 "version": "2.7.3.Final", "connector": "mariadb", "name": "mariadb-server-1", "ts_ms": 1465581902300, "ts_us": 1465581902300000, "ts_ns": 1465581902300000000, "snapshot": false, "db": "inventory", "table": "customers", "server_id": 223344, "gtid": null, "file": "mariadb-bin.000003", "pos": 805, "row": 0, "thread": 7, "query": "DELETE FROM customers WHERE id=1004" }, "op": "d", 4 "ts_ms": 1465581902461, 5 "ts_us": 1465581902461842, 6 "ts_ns": 1465581902461842579 7 } } Table 2.37. Descriptions of delete event value fields Item Field name Description 1 before Optional field that specifies the state of the row before the event occurred. In a delete event value, the before field contains the values that were in the row before it was deleted with the database commit. 2 after Optional field that specifies the state of the row after the event occurred. In a delete event value, the after field is null , signifying that the row no longer exists. 3 source Mandatory field that describes the source metadata for the event. In a delete event value, the source field structure is the same as for create and update events for the same table. Many source field values are also the same. In a delete event value, the ts_ms and pos field values, as well as other values, might have changed. But the source field in a delete event value provides the same metadata: Debezium version Connector name binlog name where the event was recorded binlog position Row within the event If the event was part of a snapshot Name of the database and table that contain the updated row ID of the MariaDB thread that created the event (non-snapshot only) MariaDB server ID (if available) Timestamp for when the change was made in the database 4 op Mandatory string that describes the type of operation. The op field value is d , signifying that this row was deleted. 5 ts_ms Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. 6 ts_us Optional field that displays the time at which the connector processed the event, in microseconds. The time is based on the system clock in the JVM running the Kafka Connect task. 7 ts_ns Optional field that displays the time at which the connector processed the event, in nanoseconds. The time is based on the system clock in the JVM running the Kafka Connect task. A delete change event record provides a consumer with the information it needs to process the removal of this row. The old values are included because some consumers might require them in order to properly handle the removal. MariaDB connector events are designed to work with Kafka log compaction . Log compaction enables removal of some older messages as long as at least the most recent message for every key is kept. This lets Kafka reclaim storage space while ensuring that the topic contains a complete data set and can be used for reloading key-based state. Tombstone events When a row is deleted, the delete event value still works with log compaction, because Kafka can remove all earlier messages that have that same key. However, for Kafka to remove all messages that have that same key, the message value must be null . To make this possible, after the Debezium MariaDB connector emits a delete event, the connector emits a special tombstone event that has the same key but a null value. truncate events A truncate change event signals that a table has been truncated. The message key of a truncate event is null . The message value resembles the following example: { "schema": { ... }, "payload": { "source": { 1 "version": "2.7.3.Final", "name": "mariadb-server-1", "connector": "mariadb", "name": "mariadb-server-1", "ts_ms": 1465581029100, "ts_us": 1465581029100000, "ts_ns": 1465581029100000000, "snapshot": false, "db": "inventory", "table": "customers", "server_id": 223344, "gtid": null, "file": "mariadb-bin.000003", "pos": 484, "row": 0, "thread": 7, "query": "UPDATE customers SET first_name='Anne Marie' WHERE id=1004" }, "op": "t", 2 "ts_ms": 1465581029523, 3 "ts_us": 1465581029523468, 4 "ts_ns": 1465581029523468471 5 } } Table 2.38. Descriptions of truncate event value fields Item Field name Description 1 source Mandatory field that describes the source metadata for the event. In a truncate event value, the source field structure is the same as for create , update , and delete events for the same table, provides this metadata: Debezium version Connector type and name Binlog name where the event was recorded Binlog position Row within the event If the event was part of a snapshot Name of the database and table ID of the MariaDB thread that truncated the event (non-snapshot only) MariaDB server ID (if available) Timestamp for when the change was made in the database 2 op Mandatory string that describes the type of operation. The op field value is t , signifying that this table was truncated. 3 ts_ms Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. 4 ts_us Optional field that displays the time at which the connector processed the event, in microseconds. The time is based on the system clock in the JVM running the Kafka Connect task. 5 ts_ns Optional field that displays the time at which the connector processed the event, in nanoseconds. The time is based on the system clock in the JVM running the Kafka Connect task. In case a single TRUNCATE statement applies to multiple tables, one truncate change event record for each truncated table will be emitted. Note A truncate event represents a change that applies to an entire table, and it does not have a message key. In topics that span multiple partition, the order of change events that apply to an entire table is is not guaranteed. That is, there is no ordering guarantee for ( create , update , etc.), or for the truncate events for that table. When a consumer reads events from different partition, it might read an update event for a table from one partition only after it reads a truncate event for the same table from a second partition. 2.2.3. How Debezium MariaDB connectors map data types The Debezium MariaDB connector represents changes to rows with events that are structured like the table in which the row exists. The event contains a field for each column value. The MariaDB data type of that column dictates how Debezium represents the value in the event. Columns that store strings are defined in MariaDB with a character set and collation. The MariaDB connector uses the column's character set when reading the binary representation of the column values in the binlog events. The connector can map MariaDB data types to both literal and semantic types. Literal type : how the value is represented using Kafka Connect schema types. Semantic type : how the Kafka Connect schema captures the meaning of the field (schema name). If the default data type conversions do not meet your needs, you can create a custom converter for the connector. Details are in the following sections: Basic types Temporal types Decimal types Boolean values Spatial types Basic types The following table shows how the connector maps basic MariaDB data types. Table 2.39. Descriptions of basic type mappings MariaDB type Literal type Semantic type BOOLEAN, BOOL BOOLEAN n/a BIT(1) BOOLEAN n/a BIT(>1) BYTES io.debezium.data.Bits The length schema parameter contains an integer that represents the number of bits. The byte[] contains the bits in little-endian form and is sized to contain the specified number of bits. For example, where n is bits: numBytes = n/8 + (n%8== 0 ? 0 : 1) TINYINT INT16 n/a SMALLINT[(M)] INT16 n/a MEDIUMINT[(M)] INT32 n/a INT, INTEGER[(M)] INT32 n/a BIGINT[(M)] INT64 n/a REAL[(M,D)] FLOAT32 n/a FLOAT[(P)] FLOAT32 or FLOAT64 The precision is used only to determine storage size. A precision P from 0 to 23 results in a 4-byte single-precision FLOAT32 column. A precision P from 24 to 53 results in an 8-byte double-precision FLOAT64 column. DOUBLE[(M,D)] FLOAT64 n/a CHAR(M)] STRING n/a VARCHAR(M)] STRING n/a BINARY(M)] BYTES or STRING n/a Either the raw bytes (the default), a base64-encoded String, or a base64-url-safe-encoded String, or a hex-encoded String, based on the binary.handling.mode connector configuration property setting. VARBINARY(M)] BYTES or STRING n/a Either the raw bytes (the default), a base64-encoded String, or a base64-url-safe-encoded String, or a hex-encoded String, based on the binary.handling.mode connector configuration property setting. TINYBLOB BYTES or STRING n/a Either the raw bytes (the default), a base64-encoded String, or a base64-url-safe-encoded String, or a hex-encoded String, based on the binary.handling.mode connector configuration property setting. TINYTEXT STRING n/a BLOB BYTES or STRING n/a Either the raw bytes (the default), a base64-encoded String, or a base64-url-safe-encoded String, or a hex-encoded String, based on the binary.handling.mode connector configuration property setting. Only values with a size of up to 2GB are supported. It is recommended to externalize large column values, using the claim check pattern. TEXT STRING n/a Only values with a size of up to 2GB are supported. It is recommended to externalize large column values, using the claim check pattern. MEDIUMBLOB BYTES or STRING n/a Either the raw bytes (the default), a base64-encoded String, or a base64-url-safe-encoded String, or a hex-encoded String, based on the binary.handling.mode connector configuration property setting. MEDIUMTEXT STRING n/a LONGBLOB BYTES or STRING n/a Either the raw bytes (the default), a base64-encoded String, or a base64-url-safe-encoded String, or a hex-encoded String, based on the binary.handling.mode connector configuration property setting. Only values with a size of up to 2GB are supported. It is recommended to externalize large column values, using the claim check pattern. LONGTEXT STRING n/a Only values with a size of up to 2GB are supported. It is recommended to externalize large column values, using the claim check pattern. JSON STRING io.debezium.data.Json Contains the string representation of a JSON document, array, or scalar. ENUM STRING io.debezium.data.Enum The allowed schema parameter contains the comma-separated list of allowed values. SET STRING io.debezium.data.EnumSet The allowed schema parameter contains the comma-separated list of allowed values. YEAR[(2|4)] INT32 io.debezium.time.Year TIMESTAMP[(M)] STRING io.debezium.time.ZonedTimestamp In ISO 8601 format with microsecond precision. MariaDB allows M to be in the range of 0-6 . Temporal types Excluding the TIMESTAMP data type, MariaDB temporal types depend on the value of the time.precision.mode connector configuration property. For TIMESTAMP columns whose default value is specified as CURRENT_TIMESTAMP or NOW , the value 1970-01-01 00:00:00 is used as the default value in the Kafka Connect schema. MariaDB allows zero-values for DATE , DATETIME , and TIMESTAMP columns because zero-values are sometimes preferred over null values. The MariaDB connector represents zero-values as null values when the column definition allows null values, or as the epoch day when the column does not allow null values. Temporal values without time zones The DATETIME type represents a local date and time such as "2018-01-13 09:48:27". As you can see, there is no time zone information. Such columns are converted into epoch milliseconds or microseconds based on the column's precision by using UTC. The TIMESTAMP type represents a timestamp without time zone information. It is converted by MariaDB from the server (or session's) current time zone into UTC when writing and from UTC into the server (or session's) current time zone when reading back the value. For example: DATETIME with a value of 2018-06-20 06:37:03 becomes 1529476623000 . TIMESTAMP with a value of 2018-06-20 06:37:03 becomes 2018-06-20T13:37:03Z . Such columns are converted into an equivalent io.debezium.time.ZonedTimestamp in UTC based on the server (or session's) current time zone. The time zone will be queried from the server by default. The time zone of the JVM running Kafka Connect and Debezium does not affect these conversions. More details about properties related to temporal values are in the documentation for MariaDB connector configuration properties . time.precision.mode=adaptive_time_microseconds(default) The MariaDB connector determines the literal type and semantic type based on the column's data type definition so that events represent exactly the values in the database. All time fields are in microseconds. Only positive TIME field values in the range of 00:00:00.000000 to 23:59:59.999999 can be captured correctly. Table 2.40. Mappings when time.precision.mode=adaptive_time_microseconds MariaDB type Literal type Semantic type DATE INT32 io.debezium.time.Date Represents the number of days since the epoch. TIME[(M)] INT64 io.debezium.time.MicroTime Represents the time value in microseconds and does not include time zone information. MariaDB allows M to be in the range of 0-6 . DATETIME, DATETIME(0), DATETIME(1), DATETIME(2), DATETIME(3) INT64 io.debezium.time.Timestamp Represents the number of milliseconds past the epoch and does not include time zone information. DATETIME(4), DATETIME(5), DATETIME(6) INT64 io.debezium.time.MicroTimestamp Represents the number of microseconds past the epoch and does not include time zone information. time.precision.mode=connect The MariaDB connector uses defined Kafka Connect logical types. This approach is less precise than the default approach and the events could be less precise if the database column has a fractional second precision value of greater than 3 . Values in only the range of 00:00:00.000 to 23:59:59.999 can be handled. Set time.precision.mode=connect only if you can ensure that the TIME values in your tables never exceed the supported ranges. The connect setting is expected to be removed in a future version of Debezium. Table 2.41. Mappings when time.precision.mode=connect MariaDB type Literal type Semantic type DATE INT32 org.apache.kafka.connect.data.Date Represents the number of days since the epoch. TIME[(M)] INT64 org.apache.kafka.connect.data.Time Represents the time value in microseconds since midnight and does not include time zone information. DATETIME[(M)] INT64 org.apache.kafka.connect.data.Timestamp Represents the number of milliseconds since the epoch, and does not include time zone information. Decimal types Debezium connectors handle decimals according to the setting of the decimal.handling.mode connector configuration property. decimal.handling.mode=precise Table 2.42. Mappings when decimal.handling.mode=precise MariaDB type Literal type Semantic type NUMERIC[(M[,D])] BYTES org.apache.kafka.connect.data.Decimal The scale schema parameter contains an integer that represents how many digits the decimal point shifted. DECIMAL[(M[,D])] BYTES org.apache.kafka.connect.data.Decimal The scale schema parameter contains an integer that represents how many digits the decimal point shifted. decimal.handling.mode=double Table 2.43. Mappings when decimal.handling.mode=double MariaDB type Literal type Semantic type NUMERIC[(M[,D])] FLOAT64 n/a DECIMAL[(M[,D])] FLOAT64 n/a decimal.handling.mode=string Table 2.44. Mappings when decimal.handling.mode=string MariaDB type Literal type Semantic type NUMERIC[(M[,D])] STRING n/a DECIMAL[(M[,D])] STRING n/a Boolean values MariaDB handles the BOOLEAN value internally in a specific way. The BOOLEAN column is internally mapped to the TINYINT(1) data type. When the table is created during streaming then it uses proper BOOLEAN mapping as Debezium receives the original DDL. During snapshots, Debezium executes SHOW CREATE TABLE to obtain table definitions that return TINYINT(1) for both BOOLEAN and TINYINT(1) columns. Debezium then has no way to obtain the original type mapping and so maps to TINYINT(1) . To enable you to convert source columns to Boolean data types, Debezium provides a TinyIntOneToBooleanConverter custom converter that you can use in one of the following ways: Map all TINYINT(1) or TINYINT(1) UNSIGNED columns to BOOLEAN types. Enumerate a subset of columns by using a comma-separated list of regular expressions. To use this type of conversion, you must set the converters configuration property with the selector parameter, as shown in the following example: NOTE: In some cases, the database may not show the length of tinyint unsigned when the snapshot executes SHOW CREATE TABLE , which means this converter doesn't work. The new option length.checker can solve this issue, the default value is true . Disable the length.checker and specify the columns that need to be converted to selected property instead of converting all columns based on type, as shown in the following example: Spatial types Currently, the Debezium MariaDB connector supports the following spatial data types. Table 2.45. Description of spatial type mappings MariaDB type Literal type Semantic type GEOMETRY, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, GEOMETRYCOLLECTION STRUCT io.debezium.data.geometry.Geometry Contains a structure with two fields: srid (INT32 : spatial reference system ID that defines the type of geometry object stored in the structure wkb (BYTES) : binary representation of the geometry object encoded in the Well-Known-Binary (wkb) format. See the Open Geospatial Consortium for more details. 2.2.4. Custom converters for mapping MariaDB data to alternative data types By default, the Debezium MariaDB connector provides several CustomConverter implementations for MariaDB data types. These custom converters provide alternative mappings for specific data types based on the connector configuration. To add a CustomConverter to the connector, follow the instructions in the Custom Converters documentation . TINYINT(1) to Boolean By default, during a connector snapshot, the Debezium MariaDB connector obtains column types from the JDBC driver, which assigns the TINYINT(1) type to BOOLEAN columns. Debezium then uses these JDBC column types to define the schema for the snapshot events. After the connector transitions from the snapshot to the streaming phase, the change event schema that results from the default mapping can lead to inconsistent mappings for BOOLEAN columns. To help ensure that MariaDB emits BOOLEAN columns uniformly, you can apply the custom TinyIntOneToBooleanConverter , as shown in the following configuration example. Example: TinyIntOneToBooleanConverter configuration In the preceding example, the selector and length.checker properties are optional. By default, the converter checks that TINYINT data types conform to a length of 1 . If length.checker to false , the converter does not explicitly confirm that the TINYINT data type conforms to a length of 1 . The selector designates the tables or columns to convert, based on the supplied regular expression. If you omit the selector property, the converter maps all TINYINT columns to logical BOOL field types. If you do not configure a selector option, and you want to map TINYINT columns to TINYINT(1) , omit the length.checker property, or set its value to true . JDBC sink data types If you integrate the Debezium JDBC sink connector with a Debezium MariaDB source connector, the MariaDB connector emits some column attributes differently during the snapshot and streaming phases. For the JDBC sink connector to consistently consume changes from both the snapshot and streaming phase, you must include the JdbcSinkDataTypesConverter converter as part of the MariaDB source connector configuration, as shown in the following example: Example: JdbcSinkDataTypesConverter configuration In the preceding example, the selector.* and treat.real.as.double configuration properties are optional. The selector.* properties specify comma-separated lists of regular expressions that specify which tables and columns that the converter applies to. By default, the converter applies the following rules apply to all Boolean, real, and string-based column data types, across all tables: BOOLEAN data types are always emitted as INT16 logical types, with 1 representing true and 0 representing false REAL data types are always emitted as FLOAT64 logical types. String-based columns always include the __debezium.source.column.character_set schema parameter that contains the column's character set. For each data type, you can configure a selector rule to override the default scope and apply the selector to specific tables and columns only. For example, to set the scope of the Boolean converter, add the following rule to the connector configuration, as in the preceding example: converters.jdbc-sink.selector.boolean=.*.MY_TABLE.BOOL_COL 2.2.5. Setting up MariaDB to run a Debezium connector Some MariaDB setup tasks are required before you can install and run a Debezium connector. Details are in the following sections: Section 2.2.5.1, "Creating a MariaDB user for a Debezium connector" Section 2.2.5.2, "Enabling the MariaDB binlog for Debezium" Section 2.2.5.3, "Enabling MariaDB Global Transaction Identifiers for Debezium" Section 2.2.5.4, "Configuring MariaDB session timeouts for Debezium" Section 2.2.5.5, "Enabling query log events for Debezium MariaDB connectors" 2.2.5.1. Creating a MariaDB user for a Debezium connector A Debezium MariaDB connector requires a MariaDB user account. This MariaDB user must have appropriate permissions on all databases for which the Debezium MariaDB connector captures changes. Prerequisites A MariaDB server. Basic knowledge of SQL commands. Procedure Create the MariaDB user: mariadb> CREATE USER 'user'@'localhost' IDENTIFIED BY 'password'; Grant the required permissions to the user: mariadb> GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'user' IDENTIFIED BY 'password'; For a description of the required permissions, see Table 2.46, "Descriptions of user permissions" . Important If using a hosted option such as Amazon RDS or Amazon Aurora that does not allow a global read lock, table-level locks are used to create the consistent snapshot . In this case, you need to also grant LOCK TABLES permissions to the user that you create. See snapshots for more details. Finalize the user's permissions: mariadb> FLUSH PRIVILEGES; Table 2.46. Descriptions of user permissions Keyword Description SELECT Enables the connector to select rows from tables in databases. This is used only when performing a snapshot. RELOAD Enables the connector the use of the FLUSH statement to clear or reload internal caches, flush tables, or acquire locks. This is used only when performing a snapshot. SHOW DATABASES Enables the connector to see database names by issuing the SHOW DATABASE statement. This is used only when performing a snapshot. REPLICATION SLAVE Enables the connector to connect to and read the MariaDB server binlog. REPLICATION CLIENT Enables the connector the use of the following statements: SHOW MASTER STATUS SHOW SLAVE STATUS SHOW BINARY LOGS The connector always requires this. ON Identifies the database to which the permissions apply. TO 'user' Specifies the user to grant the permissions to. IDENTIFIED BY 'password' Specifies the user's MariaDB password. 2.2.5.2. Enabling the MariaDB binlog for Debezium You must enable binary logging for MariaDB replication. The binary logs record transaction updates in a way that enables replicas to propagate those changes. Prerequisites A MariaDB server. Appropriate MariaDB user privileges. Procedure Check whether the log-bin option is enabled: If the binlog is OFF , add the properties in the following table to the configuration file for the MariaDB server: server-id = 223344 # Querying variable is called server_id, e.g. SELECT variable_value FROM information_schema.global_variables WHERE variable_name='server_id'; log_bin = mariadb-bin binlog_format = ROW binlog_row_image = FULL binlog_expire_logs_seconds = 864000 Confirm your changes by checking the binlog status once more: If you run MariaDB on Amazon RDS, you must enable automated backups for your database instance for binary logging to occur. If the database instance is not configured to perform automated backups, the binlog is disabled, even if you apply the settings described in the steps. Table 2.47. Descriptions of MariaDB binlog configuration properties Property Description server-id The value for the server-id must be unique for each server and replication client in the MariaDB cluster. log_bin The value of log_bin is the base name of the sequence of binlog files. binlog_format The binlog-format must be set to ROW or row . binlog_row_image The binlog_row_image must be set to FULL or full . binlog_expire_logs_seconds The binlog_expire_logs_seconds corresponds to deprecated system variable expire_logs_days . This is the number of seconds for automatic binlog file removal. The default value is 2592000 , which equals 30 days. Set the value to match the needs of your environment. For more information, see MariaDB purges binlog files . 2.2.5.3. Enabling MariaDB Global Transaction Identifiers for Debezium Global transaction identifiers (GTIDs) uniquely identify transactions that occur on a server within a cluster. Although not required for a Debezium MariaDB connector, using GTIDs simplifies replication and enables you to more easily confirm if primary and replica servers are consistent. For MariaDB, GTIDs are enabled by default and no additional configuration is necessary. 2.2.5.4. Configuring MariaDB session timeouts for Debezium When an initial consistent snapshot is made for large databases, your established connection could timeout while the tables are being read. You can prevent this behavior by configuring interactive_timeout and wait_timeout in your MariaDB configuration file. Prerequisites A MariaDB server. Basic knowledge of SQL commands. Access to the MariaDB configuration file. Procedure Configure interactive_timeout : mariadb> interactive_timeout=<duration-in-seconds> Configure wait_timeout : mariadb> wait_timeout=<duration-in-seconds> Table 2.48. Descriptions of MariaDB session timeout options Option Description interactive_timeout The number of seconds the server waits for activity on an interactive connection before closing it. For more information see the: wait_timeout The number of seconds that the server waits for activity on a non-interactive connection before closing it. 2.2.5.5. Enabling query log events for Debezium MariaDB connectors You might want to see the original SQL statement for each binlog event. Enabling the binlog_annotate_row_events option in the MariaDB configuration allows you to do this. Prerequisites A MariaDB server. Basic knowledge of SQL commands. Access to the MariaDB configuration file. Procedure Enable binlog_annotate_row_events in MariaDB: mariadb> binlog_annotate_row_events=ON binlog_annotate_row_events is set to a value that enables/disables support for including the original SQL statement in the binlog entry. ON = enabled OFF = disabled 2.2.5.6. validate binlog row value options for Debezium MariaDB connectors Verify the setting of the binlog_row_value_options variable in the database. To enable the connector to consume UPDATE events, this variable must be set to a value other than PARTIAL_JSON . Prerequisites A MariaDB server. Basic knowledge of SQL commands. Access to the MariaDB configuration file. Procedure Check current variable value mariadb> show global variables where variable_name = 'binlog_row_value_options'; Result +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | binlog_row_value_options | | +--------------------------+-------+ If the value of the variable is set to PARTIAL_JSON , run the following command to unset it: mariadb> set @@global.binlog_row_value_options="" ; 2.2.6. Deployment of Debezium MariaDB connectors You can use either of the following methods to deploy a Debezium MariaDB connector: Use Streams for Apache Kafka to automatically create an image that includes the connector plug-in . This is the preferred method. Build a custom Kafka Connect container image from a Dockerfile . Additional resources Section 2.2.6.5, "Descriptions of Debezium MariaDB connector configuration properties" 2.2.6.1. MariaDB connector deployment using Streams for Apache Kafka Beginning with Debezium 1.7, the preferred method for deploying a Debezium connector is to use Streams for Apache Kafka to build a Kafka Connect container image that includes the connector plug-in. During the deployment process, you create and use the following custom resources (CRs): A KafkaConnect CR that defines your Kafka Connect instance and includes information about the connector artifacts needs to include in the image. A KafkaConnector CR that provides details that include information the connector uses to access the source database. After Streams for Apache Kafka starts the Kafka Connect pod, you start the connector by applying the KafkaConnector CR. In the build specification for the Kafka Connect image, you can specify the connectors that are available to deploy. For each connector plug-in, you can also specify other components that you want to make available for deployment. For example, you can add Apicurio Registry artifacts, or the Debezium scripting component. When Streams for Apache Kafka builds the Kafka Connect image, it downloads the specified artifacts, and incorporates them into the image. The spec.build.output parameter in the KafkaConnect CR specifies where to store the resulting Kafka Connect container image. Container images can be stored in a Docker registry, or in an OpenShift ImageStream. To store images in an ImageStream, you must create the ImageStream before you deploy Kafka Connect. ImageStreams are not created automatically. Note If you use a KafkaConnect resource to create a cluster, afterwards you cannot use the Kafka Connect REST API to create or update connectors. You can still use the REST API to retrieve information. Additional resources Configuring Kafka Connect in Deploying and Managing Streams for Apache Kafka on OpenShift. Building a new container image automatically in Deploying and Managing Streams for Apache Kafka on OpenShift. 2.2.6.2. Using Streams for Apache Kafka to deploy a Debezium MariaDB connector With earlier versions of Streams for Apache Kafka, to deploy Debezium connectors on OpenShift, you were required to first build a Kafka Connect image for the connector. The current preferred method for deploying connectors on OpenShift is to use a build configuration in Streams for Apache Kafka to automatically build a Kafka Connect container image that includes the Debezium connector plug-ins that you want to use. During the build process, the Streams for Apache Kafka Operator transforms input parameters in a KafkaConnect custom resource, including Debezium connector definitions, into a Kafka Connect container image. The build downloads the necessary artifacts from the Red Hat Maven repository or another configured HTTP server. The newly created container is pushed to the container registry that is specified in .spec.build.output , and is used to deploy a Kafka Connect cluster. After Streams for Apache Kafka builds the Kafka Connect image, you create KafkaConnector custom resources to start the connectors that are included in the build. Prerequisites You have access to an OpenShift cluster on which the cluster Operator is installed. The Streams for Apache Kafka Operator is running. An Apache Kafka cluster is deployed as documented in Deploying and Managing Streams for Apache Kafka on OpenShift . Kafka Connect is deployed on Streams for Apache Kafka You have a Red Hat build of Debezium license. The OpenShift oc CLI client is installed or you have access to the OpenShift Container Platform web console. Depending on how you intend to store the Kafka Connect build image, you need registry permissions or you must create an ImageStream resource: To store the build image in an image registry, such as Red Hat Quay.io or Docker Hub An account and permissions to create and manage images in the registry. To store the build image as a native OpenShift ImageStream An ImageStream resource is deployed to the cluster for storing new container images. You must explicitly create an ImageStream for the cluster. ImageStreams are not available by default. For more information about ImageStreams, see Managing image streams in the OpenShift Container Platform documentation. Procedure Log in to the OpenShift cluster. Create a Debezium KafkaConnect custom resource (CR) for the connector, or modify an existing one. For example, create a KafkaConnect CR with the name dbz-connect.yaml that specifies the metadata.annotations and spec.build properties. The following example shows an excerpt from a dbz-connect.yaml file that describes a KafkaConnect custom resource. Example 2.11. A dbz-connect.yaml file that defines a KafkaConnect custom resource that includes a Debezium connector In the example that follows, the custom resource is configured to download the following artifacts: The Debezium MariaDB connector archive. The Red Hat build of Apicurio Registry archive. The Apicurio Registry is an optional component. Add the Apicurio Registry component only if you intend to use Avro serialization with the connector. The Debezium scripting SMT archive and the associated scripting engine that you want to use with the Debezium connector. The SMT archive and scripting language dependencies are optional components. Add these components only if you intend to use the Debezium content-based routing SMT or filter SMT . apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: debezium-kafka-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: version: 3.6.0 build: 2 output: 3 type: imagestream 4 image: debezium-streams-connect:latest plugins: 5 - name: debezium-connector-mariadb artifacts: - type: zip 6 url: https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-mariadb/2.7.3.Final-redhat-00001/debezium-connector-mariadb-2.7.3.Final-redhat-00001-plugin.zip 7 - type: zip url: https://maven.repository.redhat.com/ga/io/apicurio/apicurio-registry-distro-connect-converter/2.4.4.Final-redhat- <build-number> /apicurio-registry-distro-connect-converter-2.4.4.Final-redhat- <build-number> .zip 8 - type: zip url: https://maven.repository.redhat.com/ga/io/debezium/debezium-scripting/2.7.3.Final-redhat-00001/debezium-scripting-2.7.3.Final-redhat-00001.zip 9 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy/3.0.11/groovy-3.0.11.jar 10 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-jsr223/3.0.11/groovy-jsr223-3.0.11.jar - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-json3.0.11/groovy-json-3.0.11.jar bootstrapServers: debezium-kafka-cluster-kafka-bootstrap:9093 ... Table 2.49. Descriptions of Kafka Connect configuration settings Item Description 1 Sets the strimzi.io/use-connector-resources annotation to "true" to enable the Cluster Operator to use KafkaConnector resources to configure connectors in this Kafka Connect cluster. 2 The spec.build configuration specifies where to store the build image and lists the plug-ins to include in the image, along with the location of the plug-in artifacts. 3 The build.output specifies the registry in which the newly built image is stored. 4 Specifies the name and image name for the image output. Valid values for output.type are docker to push into a container registry such as Docker Hub or Quay, or imagestream to push the image to an internal OpenShift ImageStream. To use an ImageStream, an ImageStream resource must be deployed to the cluster. For more information about specifying the build.output in the KafkaConnect configuration, see the Streams for Apache Kafka Build schema reference in {NameConfiguringStreamsOpenShift}. 5 The plugins configuration lists all of the connectors that you want to include in the Kafka Connect image. For each entry in the list, specify a plug-in name , and information for about the artifacts that are required to build the connector. Optionally, for each connector plug-in, you can include other components that you want to be available for use with the connector. For example, you can add Service Registry artifacts, or the Debezium scripting component. 6 The value of artifacts.type specifies the file type of the artifact specified in the artifacts.url . Valid types are zip , tgz , or jar . Debezium connector archives are provided in .zip file format. The type value must match the type of the file that is referenced in the url field. 7 The value of artifacts.url specifies the address of an HTTP server, such as a Maven repository, that stores the file for the connector artifact. Debezium connector artifacts are available in the Red Hat Maven repository. The OpenShift cluster must have access to the specified server. 8 (Optional) Specifies the artifact type and url for downloading the Apicurio Registry component. Include the Apicurio Registry artifact, only if you want the connector to use Apache Avro to serialize event keys and values with the Red Hat build of Apicurio Registry, instead of using the default JSON converter. 9 (Optional) Specifies the artifact type and url for the Debezium scripting SMT archive to use with the Debezium connector. Include the scripting SMT only if you intend to use the Debezium content-based routing SMT or filter SMT To use the scripting SMT, you must also deploy a JSR 223-compliant scripting implementation, such as groovy. 10 (Optional) Specifies the artifact type and url for the JAR files of a JSR 223-compliant scripting implementation, which is required by the Debezium scripting SMT. Important If you use Streams for Apache Kafka to incorporate the connector plug-in into your Kafka Connect image, for each of the required scripting language components artifacts.url must specify the location of a JAR file, and the value of artifacts.type must also be set to jar . Invalid values cause the connector fails at runtime. To enable use of the Apache Groovy language with the scripting SMT, the custom resource in the example retrieves JAR files for the following libraries: groovy groovy-jsr223 (scripting agent) groovy-json (module for parsing JSON strings) As an alternative, the Debezium scripting SMT also supports the use of the JSR 223 implementation of GraalVM JavaScript. Apply the KafkaConnect build specification to the OpenShift cluster by entering the following command: oc create -f dbz-connect.yaml Based on the configuration specified in the custom resource, the Streams Operator prepares a Kafka Connect image to deploy. After the build completes, the Operator pushes the image to the specified registry or ImageStream, and starts the Kafka Connect cluster. The connector artifacts that you listed in the configuration are available in the cluster. Create a KafkaConnector resource to define an instance of each connector that you want to deploy. For example, create the following KafkaConnector CR, and save it as mariadb-inventory-connector.yaml Example 2.12. mariadb-inventory-connector.yaml file that defines the KafkaConnector custom resource for a Debezium connector apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: labels: strimzi.io/cluster: debezium-kafka-connect-cluster name: inventory-connector-mariadb 1 spec: class: io.debezium.connector.mariadb.MariaDbConnector 2 tasksMax: 1 3 config: 4 schema.history.internal.kafka.bootstrap.servers: debezium-kafka-cluster-kafka-bootstrap.debezium.svc.cluster.local:9092 schema.history.internal.kafka.topic: schema-changes.inventory database.hostname: mariadb.debezium-mariadb.svc.cluster.local 5 database.port: 3306 6 database.user: debezium 7 database.password: dbz 8 database.server.id: 184054 9 topic.prefix: inventory-connector-mariadb 10 table.include.list: inventory.* 11 ... Table 2.50. Descriptions of connector configuration settings Item Description 1 The name of the connector to register with the Kafka Connect cluster. 2 The name of the connector class. 3 The number of tasks that can operate concurrently. 4 The connector's configuration. 5 The address of the host database instance. 6 The port number of the database instance. 7 The name of the account that Debezium uses to connect to the database. 8 The password that Debezium uses to connect to the database user account. 9 Unique numeric ID of the connector. 10 The topic prefix for the database instance or cluster. The specified name must be formed only from alphanumeric characters or underscores. Because the topic prefix is used as the prefix for any Kafka topics that receive change events from this connector, the name must be unique among the connectors in the cluster. This namespace is also used in the names of related Kafka Connect schemas, and the namespaces of a corresponding Avro schema if you integrate the connector with the Avro connector . 11 The list of tables from which the connector captures change events. Create the connector resource by running the following command: oc create -n <namespace> -f <kafkaConnector> .yaml For example, oc create -n debezium -f mariadb-inventory-connector.yaml The connector is registered to the Kafka Connect cluster and starts to run against the database that is specified by spec.config.database.dbname in the KafkaConnector CR. After the connector pod is ready, Debezium is running. You are now ready to verify the Debezium MariaDB deployment . 2.2.6.3. Deploying Debezium MariaDB connectors by building a custom Kafka Connect container image from a Dockerfile To deploy a Debezium MariaDB connector, you must build a custom Kafka Connect container image that contains the Debezium connector archive, and then push this container image to a container registry. You then need to create the following custom resources (CRs): A KafkaConnect CR that defines your Kafka Connect instance. The image property in the CR specifies the name of the container image that you create to run your Debezium connector. You apply this CR to the OpenShift instance where Red Hat Streams for Apache Kafka is deployed. Streams for Apache Kafka offers operators and images that bring Apache Kafka to OpenShift. A KafkaConnector CR that defines your Debezium MariaDB connector. Apply this CR to the same OpenShift instance where you apply the KafkaConnect CR. Prerequisites MariaDB is running and you completed the steps to set up MariaDB to work with a Debezium connector . Streams for Apache Kafka is deployed on OpenShift and is running Apache Kafka and Kafka Connect. For more information, see Deploying and Managing Streams for Apache Kafka on OpenShift . Podman or Docker is installed. You have an account and permissions to create and manage containers in the container registry (such as quay.io or docker.io ) to which you plan to add the container that will run your Debezium connector. Procedure Create the Debezium MariaDB container for Kafka Connect: Create a Dockerfile that uses registry.redhat.io/amq-streams-kafka-35-rhel8:2.5.0 as the base image. For example, from a terminal window, enter the following command: cat <<EOF >debezium-container-for-mariadb.yaml 1 FROM registry.redhat.io/amq-streams-kafka-35-rhel8:2.5.0 USER root:root RUN mkdir -p /opt/kafka/plugins/debezium 2 RUN cd /opt/kafka/plugins/debezium/ \ && curl -O https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-mariadb/2.7.3.Final-redhat-00001/debezium-connector-mariadb-2.7.3.Final-redhat-00001-plugin.zip \ && unzip debezium-connector-mariadb-2.7.3.Final-redhat-00001-plugin.zip \ && rm debezium-connector-mariadb-2.7.3.Final-redhat-00001-plugin.zip RUN cd /opt/kafka/plugins/debezium/ USER 1001 EOF Item Description 1 You can specify any file name that you want. 2 Specifies the path to your Kafka Connect plug-ins directory. If your Kafka Connect plug-ins directory is in a different location, replace this path with the actual path of your directory. The command creates a Dockerfile with the name debezium-container-for-mariadb.yaml in the current directory. Build the container image from the debezium-container-for-mariadb.yaml Docker file that you created in the step. From the directory that contains the file, open a terminal window and enter one of the following commands: podman build -t debezium-container-for-mariadb:latest . docker build -t debezium-container-for-mariadb:latest . The preceding commands build a container image with the name debezium-container-for-mariadb . Push your custom image to a container registry, such as quay.io or an internal container registry. The container registry must be available to the OpenShift instance where you want to deploy the image. Enter one of the following commands: podman push <myregistry.io> /debezium-container-for-mariadb:latest docker push <myregistry.io> /debezium-container-for-mariadb:latest Create a new Debezium MariaDB KafkaConnect custom resource (CR). For example, create a KafkaConnect CR with the name dbz-connect.yaml that specifies annotations and image properties. The following example shows an excerpt from a dbz-connect.yaml file that describes a KafkaConnect custom resource. apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: #... image: debezium-container-for-mariadb 2 ... Item Description 1 metadata.annotations indicates to the Cluster Operator that KafkaConnector resources are used to configure connectors in this Kafka Connect cluster. 2 spec.image specifies the name of the image that you created to run your Debezium connector. This property overrides the STRIMZI_DEFAULT_KAFKA_CONNECT_IMAGE variable in the Cluster Operator. Apply the KafkaConnect CR to the OpenShift Kafka Connect environment by entering the following command: oc create -f dbz-connect.yaml The command adds a Kafka Connect instance that specifies the name of the image that you created to run your Debezium connector. Create a KafkaConnector custom resource that configures your Debezium MariaDB connector instance. You configure a Debezium MariaDB connector in a .yaml file that specifies the configuration properties for the connector. The connector configuration might instruct Debezium to produce events for a subset of the schemas and tables, or it might set properties so that Debezium ignores, masks, or truncates values in specified columns that are sensitive, too large, or not needed. The following example configures a Debezium connector that connects to a MariaDB host, 192.168.99.100 , on port 3306 , and captures changes to the inventory database. dbserver1 is the server's logical name. MariaDB inventory-connector.yaml apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: inventory-connector-mariadb 1 labels: strimzi.io/cluster: my-connect-cluster spec: class: io.debezium.connector.mariadb.MariaDbConnector tasksMax: 1 2 config: 3 database.hostname: mariadb 4 database.port: 3306 database.user: debezium database.password: dbz database.server.id: 184054 5 topic.prefix: inventory-connector-mariadb 6 table.include.list: inventory 7 schema.history.internal.kafka.bootstrap.servers: my-cluster-kafka-bootstrap:9092 8 schema.history.internal.kafka.topic: schema-changes.inventory 9 Table 2.51. Descriptions of connector configuration settings Item Description 1 The name of the connector. 2 Only one task should operate at any one time. Because the MariaDB connector reads the MariaDB server's binlog , using a single connector task ensures proper order and event handling. The Kafka Connect service uses connectors to start one or more tasks that do the work, and it automatically distributes the running tasks across the cluster of Kafka Connect services. If any of the services stop or crash, those tasks will be redistributed to running services. 3 The connector's configuration. 4 The database host, which is the name of the container running the MariaDB server ( mariadb ). 5 Unique ID of the connector. 6 Topic prefix for the MariaDB server or cluster. This name is used as the prefix for all Kafka topics that receive change event records. 7 The connector captures changes from the inventory table only. 8 The list of Kafka brokers that this connector will use to write and recover DDL statements to the database schema history topic. Upon restart, the connector recovers the schemas of the database that existed at the point in time in the binlog when the connector should begin reading. 9 The name of the database schema history topic. This topic is for internal use only and should not be used by consumers. Create your connector instance with Kafka Connect. For example, if you saved your KafkaConnector resource in the inventory-connector.yaml file, you would run the following command: oc apply -f inventory-connector.yaml The preceding command registers inventory-connector and the connector starts to run against the inventory database as defined in the KafkaConnector CR. For the complete list of the configuration properties that you can set for the Debezium MariaDB connector, see MariaDB connector configuration properties . Results After the connector starts, it performs a consistent snapshot of the MariaDB databases that the connector is configured for. The connector then starts generating data change events for row-level operations and streaming change event records to Kafka topics. 2.2.6.4. Verifying that the Debezium MariaDB connector is running If the connector starts correctly without errors, it creates a topic for each table that the connector is configured to capture. Downstream applications can subscribe to these topics to retrieve information events that occur in the source database. To verify that the connector is running, you perform the following operations from the OpenShift Container Platform web console, or through the OpenShift CLI tool (oc): Verify the connector status. Verify that the connector generates topics. Verify that topics are populated with events for read operations ("op":"r") that the connector generates during the initial snapshot of each table. Prerequisites A Debezium connector is deployed to Streams for Apache Kafka on OpenShift. The OpenShift oc CLI client is installed. You have access to the OpenShift Container Platform web console. Procedure Check the status of the KafkaConnector resource by using one of the following methods: From the OpenShift Container Platform web console: Navigate to Home Search . On the Search page, click Resources to open the Select Resource box, and then type KafkaConnector . From the KafkaConnectors list, click the name of the connector that you want to check, for example inventory-connector-mariadb . In the Conditions section, verify that the values in the Type and Status columns are set to Ready and True . From a terminal window: Enter the following command: oc describe KafkaConnector <connector-name> -n <project> For example, oc describe KafkaConnector inventory-connector-mariadb -n debezium The command returns status information that is similar to the following output: Example 2.13. KafkaConnector resource status Name: inventory-connector-mariadb Namespace: debezium Labels: strimzi.io/cluster=debezium-kafka-connect-cluster Annotations: <none> API Version: kafka.strimzi.io/v1beta2 Kind: KafkaConnector ... Status: Conditions: Last Transition Time: 2021-12-08T17:41:34.897153Z Status: True Type: Ready Connector Status: Connector: State: RUNNING worker_id: 10.131.1.124:8083 Name: inventory-connector-mariadb Tasks: Id: 0 State: RUNNING worker_id: 10.131.1.124:8083 Type: source Observed Generation: 1 Tasks Max: 1 Topics: inventory-connector-mariadb.inventory inventory-connector-mariadb.inventory.addresses inventory-connector-mariadb.inventory.customers inventory-connector-mariadb.inventory.geom inventory-connector-mariadb.inventory.orders inventory-connector-mariadb.inventory.products inventory-connector-mariadb.inventory.products_on_hand Events: <none> Verify that the connector created Kafka topics: From the OpenShift Container Platform web console. Navigate to Home Search . On the Search page, click Resources to open the Select Resource box, and then type KafkaTopic . From the KafkaTopics list, click the name of the topic that you want to check, for example, inventory-connector-mariadb.inventory.orders---ac5e98ac6a5d91e04d8ec0dc9078a1ece439081d . In the Conditions section, verify that the values in the Type and Status columns are set to Ready and True . From a terminal window: Enter the following command: oc get kafkatopics The command returns status information that is similar to the following output: Example 2.14. KafkaTopic resource status Check topic content. From a terminal window, enter the following command: oc exec -n <project> -it <kafka-cluster> -- /opt/kafka/bin/kafka-console-consumer.sh \ > --bootstrap-server localhost:9092 \ > --from-beginning \ > --property print.key=true \ > --topic= <topic-name > For example, oc exec -n debezium -it debezium-kafka-cluster-kafka-0 -- /opt/kafka/bin/kafka-console-consumer.sh \ > --bootstrap-server localhost:9092 \ > --from-beginning \ > --property print.key=true \ > --topic=inventory-connector-mariadb.inventory.products_on_hand The format for specifying the topic name is the same as the oc describe command returns in Step 1, for example, inventory-connector-mariadb.inventory.addresses . For each event in the topic, the command returns information that is similar to the following output: Example 2.15. Content of a Debezium change event In the preceding example, the payload value shows that the connector snapshot generated a read ( "op" ="r" ) event from the table inventory.products_on_hand . The "before" state of the product_id record is null , indicating that no value exists for the record. The "after" state shows a quantity of 3 for the item with product_id 101 . 2.2.6.5. Descriptions of Debezium MariaDB connector configuration properties The Debezium MariaDB connector has numerous configuration properties that you can use to achieve the right connector behavior for your application. Many properties have default values. Information about the properties is organized as follows: Required connector configuration properties Advanced connector configuration properties Database schema history connector configuration properties that control how Debezium processes events that it reads from the database schema history topic. Pass-through MariaDB connector configuration properties Pass-through database schema history properties for configuring producer and consumer clients Pass-through Kafka signals configuration properties Pass-through Kafka signals consumer client configuration properties Pass-through sink notification configuration properties Pass-through database driver configuration properties Required Debezium MariaDB connector configuration properties The following configuration properties are required unless a default value is available. bigint.unsigned.handling.mode Default value: long Specifies how the connector represents BIGINT UNSIGNED columns in change events. Set one of the following options: long Uses Java long data types to represent BIGINT UNSIGNED column values. Although the long type does not offer the greatest precision, it is easy implement in most consumers. In most environments, this is the preferred setting. precise Uses java.math.BigDecimal data types to represent values. The connector uses the Kafka Connect org.apache.kafka.connect.data.Decimal data type to represent values in encoded binary format. Set this option if the connector typically works with values larger than 2^63. The long data type cannot convey values of that size. binary.handling.mode Default value: bytes Specifies how the connector represents values for binary columns, such as, blob , binary , varbinary , in change events. Set one of the following options: bytes Represents binary data as a byte array. base64 Represents binary data as a base64-encoded String. base64-url-safe Represents binary data as a base64-url-safe-encoded String. hex Represents binary data as a hex-encoded (base16) String. column.exclude.list Default value: empty string An optional, comma-separated list of regular expressions that match the fully-qualified names of columns to exclude from change event record values. Other columns in the source record are captured as usual. Fully-qualified names for columns are of the form databaseName . tableName . columnName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; it does not match substrings that might be present in a column name. If you include this property in the configuration, do not also set the column.include.list property. column.include.list Default value: empty string An optional, comma-separated list of regular expressions that match the fully-qualified names of columns to include in change event record values. Other columns are omitted from the event record. Fully-qualified names for columns are of the form databaseName . tableName . columnName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; it does not match substrings that might be present in a column name. If you include this property in the configuration, do not set the column.exclude.list property. column.mask.hash. hashAlgorithm .with.salt. salt column.mask.hash.v2. hashAlgorithm .with.salt. salt Default value: No default An optional, comma-separated list of regular expressions that match the fully-qualified names of character-based columns. Fully-qualified names for columns are of the form <databaseName> . <tableName> . <columnName> . To match the name of a column Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. In the resulting change event record, the values for the specified columns are replaced with pseudonyms. A pseudonym consists of the hashed value that results from applying the specified hashAlgorithm and salt . Based on the hash function that is used, referential integrity is maintained, while column values are replaced with pseudonyms. Supported hash functions are described in the MessageDigest section of the Java Cryptography Architecture Standard Algorithm Name Documentation. In the following example, CzQMA0cB5K is a randomly selected salt. If necessary, the pseudonym is automatically shortened to the length of the column. The connector configuration can include multiple properties that specify different hash algorithms and salts. Depending on the hashAlgorithm used, the salt selected, and the actual data set, the resulting data set might not be completely masked. Hashing strategy version 2 ensures fidelity of values that are hashed in different places or systems. column.mask.with. length .chars Default value: No default An optional, comma-separated list of regular expressions that match the fully-qualified names of character-based columns. Set this property if you want the connector to mask the values for a set of columns, for example, if they contain sensitive data. Set length to a positive integer to replace data in the specified columns with the number of asterisk ( * ) characters specified by the length in the property name. Set length to 0 (zero) to replace data in the specified columns with an empty string. The fully-qualified name of a column observes the following format: databaseName . tableName . columnName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. You can specify multiple properties with different lengths in a single configuration. column.propagate.source.type Default value: No default An optional, comma-separated list of regular expressions that match the fully-qualified names of columns for which you want the connector to emit extra parameters that represent column metadata. When this property is set, the connector adds the following fields to the schema of event records: __debezium.source.column.type __debezium.source.column.length __debezium.source.column.scale These parameters propagate a column's original type name and length (for variable-width types), respectively. Enabling the connector to emit this extra data can assist in properly sizing specific numeric or character-based columns in sink databases. The fully-qualified name of a column observes one of the following formats: databaseName . tableName . columnName , or databaseName . schemaName . tableName . columnName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. column.truncate.to. length .chars Default value: No default An optional, comma-separated list of regular expressions that match the fully-qualified names of character-based columns. Set this property if you want to truncate the data in a set of columns when it exceeds the number of characters specified by the length in the property name. Set length to a positive integer value, for example, column.truncate.to.20.chars . The fully-qualified name of a column observes the following format: databaseName . tableName . columnName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. You can specify multiple properties with different lengths in a single configuration. connect.timeout.ms Default value: 30000 (30 seconds) A positive integer value that specifies the maximum time in milliseconds that the connector waits to establish a connection to the MariaDB database server before the connection request times out. connector.class Default value: No default The name of the Java class for the connector. Always specify for the MariaDB connector. database.exclude.list Default value: empty string An optional, comma-separated list of regular expressions that match the names of databases from which you do not want the connector to capture changes. The connector captures changes in any database that is not named in the database.exclude.list . To match the name of a database, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the database; it does not match substrings that might be present in a database name. If you include this property in the configuration, do not also set the database.include.list property. database.hostname Default value: No default The IP address or hostname of the MariaDB database server. database.include.list Default value: empty string An optional, comma-separated list of regular expressions that match the names of the databases from which the connector captures changes. The connector does not capture changes in any database whose name is not in database.include.list . By default, the connector captures changes in all databases. To match the name of a database, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the database; it does not match substrings that might be present in a database name. If you include this property in the configuration, do not also set the database.exclude.list property. database.password Default value: No default The password of the MariaDB user that the connector uses to connect to the MariaDB database server. database.port Default value: 3306 Integer port number of the MariaDB database server. database.server.id Default value: No default The numeric ID of this database client. The specified ID must be unique across all currently running database processes in the MariaDB cluster. To enable it to read the binlog, the connector uses this unique ID to join the MariaDB database cluster as another server. database.user Default value: No default The name of the MariaDB user that the connector uses to connect to the MariaDB database server. decimal.handling.mode Default value: precise Specifies how the connector handles values for DECIMAL and NUMERIC columns in change events. Set one of the following options: precise (default) Uses java.math.BigDecimal values in binary form to represent values precisely. double Uses the double data type to represent values. This option can result in a loss of precision, but it is easier for most consumers to use. string Encodes values as formatted strings. This option is easy to consume, but can result in the loss of semantic information about the real type. event.deserialization.failure.handling.mode Default value: fail Specifies how the connector reacts after an exception occurs during deserialization of binlog events. This option is deprecated, please use event.processing.failure.handling.mode option instead. fail Propagates the exception, which indicates the problematic event and its binlog offset, and causes the connector to stop. warn Logs the problematic event and its binlog offset and then skips the event. ignore Passes over the problematic event and does not log anything. field.name.adjustment.mode Default value: No default Specifies how field names should be adjusted for compatibility with the message converter used by the connector. Set one of the following options: none No adjustment. avro Replaces characters that are not valid in Avro names with underscore characters. avro_unicode Replaces underscore characters or characters that cannot be used in Avro names with corresponding unicode, such as _uxxxx . Note For more information, see: Avro naming . gtid.source.excludes Default value: No default A comma-separated list of regular expressions that match source domain IDs in the GTID set that the connector uses to find the binlog position on the MariaDB server. When this property is set, the connector uses only the GTID ranges that have source UUIDs that do not match any of the specified exclude patterns. To match the value of a GTID, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the GTID's domain identifier. If you include this property in the configuration, do not also set the gtid.source.includes property. gtid.source.includes Default value: No default A comma-separated list of regular expressions that match source domain IDs in the GTID set used that the connector uses to find the binlog position on the MariaDB server. When this property is set, the connector uses only the GTID ranges that have source UUIDs that match one of the specified include patterns. To match the value of a GTID, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the GTID's domain identifier. If you include this property in the configuration, do not also set the gtid.source.excludes property. include.query Default value: false Boolean value that specifies whether the connector should include the original SQL query that generated the change event. If you set this option to true then you must also configure MariaDB with the binlog_annotate_row_events option set to ON . When include.query is true , the query is not present for events that the snapshot process generates. Setting include.query to true might expose tables or fields that are explicitly excluded or masked by including the original SQL statement in the change event. For this reason, the default setting is false . For more information about configuring the database to return the original SQL statement for each log event, see Enabling query log events . include.schema.changes Default value: true Boolean value that specifies whether the connector publishes changes that occur to the database schema to a Kafka topic with the name of the database server ID. Each schema change event that the connector captures uses a key that contains the database name and a value that includes the DDL statements that describe the change. This setting does not affect how the connector records schema changes in its internal database schema history. include.schema.comments Default value: false Boolean value that specifies whether the connector parses and publishes table and column comments on metadata objects. Note When you set this option to true , the schema comments that the connector includes can add a significant amount of string data to each schema object. Increasing the number and size of logical schema objects increases the amount of memory that the connector uses. inconsistent.schema.handling.mode Default value: fail Specifies how the connector responds to binlog events that refer to tables that are not present in the internal schema representation. That is, the internal representation is not consistent with the database. Set one of the following options: fail The connector throws an exception that reports the problematic event and its binlog offset. The connector then stops. warn The connector logs the problematic event and its binlog offset, and then skips the event. skip The connector skips the problematic event and does not report it in the log. message.key.columns Default value: No default A list of expressions that specify the columns that the connector uses to form custom message keys for change event records that it publishes to the Kafka topics for specified tables. By default, Debezium uses the primary key column of a table as the message key for records that it emits. In place of the default, or to specify a key for tables that lack a primary key, you can configure custom message keys based on one or more columns. To establish a custom message key for a table, list the table, followed by the columns to use as the message key. Each list entry takes the following format: <fully-qualified_tableName> : <keyColumn> , <keyColumn> To base a table key on multiple column names, insert commas between the column names. Each fully-qualified table name is a regular expression in the following format: <databaseName> . <tableName> The property can include entries for multiple tables. Use a semicolon to separate table entries in the list. The following example sets the message key for the tables inventory.customers and purchase.orders : inventory.customers:pk1,pk2;(.*).purchaseorders:pk3,pk4 For the table inventory.customer , the columns pk1 and pk2 are specified as the message key. For the purchaseorders tables in any database, the columns pk3 and pk4 server as the message key. There is no limit to the number of columns that you use to create custom message keys. However, it's best to use the minimum number that are required to specify a unique key. name Default value: No default Unique name for the connector. If you attempt to use the same name to register another connector, registration fails. This property is required by all Kafka Connect connectors. schema.name.adjustment.mode Default value: No default Specifies how the connector adjusts schema names for compatibility with the message converter used by the connector. Set one of the following options: none No adjustment. avro Replaces characters that are not valid in Avro names with underscore characters. avro_unicode Replaces underscore characters or characters that cannot be used in Avro names with corresponding unicode, such as _uxxxx. NOTE: _ is an escape sequence, similar to a backslash in Java skip.messages.without.change Default value: false Specifies whether the connector emits messages for records when it does not detect a change in the included columns. Columns are considered to be included if they are listed in the column.include.list , or are not listed in the column.exclude.list . Set the value to true to prevent the connector from capturing records when no changes are present in the included columns. table.exclude.list Default value: empty string An optional, comma-separated list of regular expressions that match fully-qualified table identifiers of tables from which you do not want the connector to capture changes. The connector captures changes in any table that is not included in table.exclude.list . Each identifier is of the form databaseName . tableName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the table; it does not match substrings that might be present in a table name. If you include this property in the configuration, do not also set the table.include.list property. table.include.list Default value: empty string An optional, comma-separated list of regular expressions that match fully-qualified table identifiers of tables whose changes you want to capture. The connector does not capture changes in any table that is not included in table.include.list . Each identifier is of the form databaseName . tableName . By default, the connector captures changes in all non-system tables in every database from which it is configured to captures changes. To match the name of a table, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the table; it does not match substrings that might be present in a table name. If you include this property in the configuration, do not also set the table.exclude.list property. tasks.max Default value: 1 The maximum number of tasks to create for this connector. Because the MariaDB connector always uses a single task, changing the default value has no effect. time.precision.mode Default value: adaptive_time_microseconds Specifies the type of precision that the connector uses to represent time, date, and timestamps values. Set one of the following options: adaptive_time_microseconds (default) The connector captures the date, datetime and timestamp values exactly as in the database using either millisecond, microsecond, or nanosecond precision values based on the database column's type, with the exception of TIME type fields, which are always captured as microseconds. connect The connector always represents time and timestamp values using Kafka Connect's built-in representations for Time, Date, and Timestamp, which use millisecond precision regardless of the database columns' precision. tombstones.on.delete Default value: true Specifies whether a delete event is followed by a tombstone event. After a source record is deleted, the connector can emit a tombstone event (the default behavior) to enable Kafka to completely delete all events that pertain to the key of the deleted row in case log compaction is enabled for the topic. Set one of the following options: true (default) The connector represents delete operations by emitting a delete event and a subsequent tombstone event. false The connector emits only delete events. topic.prefix Default value: No default Topic prefix that provides a namespace for the particular MariaDB database server or cluster in which Debezium is capturing changes. Because the topic prefix is used to name all of the Kafka topics that receive events that this connector emits, it's important that the topic prefix is unique across all connectors. Values must contain only alphanumeric characters, hyphens, dots, and underscores. Warning After you set this property, do not change its value. If you change the value, after the connector restarts, instead of continuing to emit events to the original topics, the connector emits subsequent events to topics whose names are based on the new value. The connector is also unable to recover its database schema history topic. Advanced Debezium MariaDB connector configuration properties The following list describes advanced MariaDB connector configuration properties. The default values for these properties rarely require changes. Therefore, you do not need to specify them in the connector configuration. connect.keep.alive Default value: true A Boolean value that specifies whether a separate thread should be used to ensure that the connection to the MariaDB server or cluster is kept alive. converters Default value: No default Enumerates a comma-separated list of the symbolic names of the custom converter instances that the connector can use. For example, boolean . This property is required to enable the connector to use a custom converter. For each converter that you configure for a connector, you must also add a .type property, which specifies the fully-qualified name of the class that implements the converter interface. The .type property uses the following format: <converterSymbolicName> .type For example, If you want to further control the behavior of a configured converter, you can add one or more configuration parameters to pass values to the converter. To associate these additional configuration parameter with a converter, prefix the parameter name with the symbolic name of the converter. For example, to define a selector parameter that specifies the subset of columns that the boolean converter processes, add the following property: custom.metric.tags Default value: No default Defines tags that customize MBean object names by adding metadata that provides contextual information. Specify a comma-separated list of key-value pairs. Each key represents a tag for the MBean object name, and the corresponding value represents a value for the key, for example, k1=v1,k2=v2 The connector appends the specified tags to the base MBean object name. Tags can help you to organize and categorize metrics data. You can define tags to identify particular application instances, environments, regions, versions, and so forth. For more information, see Customized MBean names . database.initial.statements Default value: No default A semicolon separated list of SQL statements to be executed when a JDBC connection, not the connection that is reading the transaction log, to the database is established. To specify a semicolon as a character in a SQL statement and not as a delimiter, use two semicolons, ( ;; ). The connector might establish JDBC connections at its own discretion, so this property is ony for configuring session parameters. It is not for executing DML statements. database.query.timeout.ms Default value: 600000 (10 minutes) Specifies the time, in milliseconds, that the connector waits for a query to complete. Set the value to 0 (zero) to remove the timeout limit. database.ssl.keystore Default value: No default An optional setting that specifies the location of the key store file. A key store file can be used for two-way authentication between the client and the MariaDB server. database.ssl.keystore.password Default value: No default The password for the key store file. Specify a password only if the database.ssl.keystore is configured. database.ssl.mode Default value: preferred Specifies whether the connector uses an encrypted connection. The following settings are available: disabled Specifies the use of an unencrypted connection. preferred (Default) The connector establishes an encrypted connection if the server supports secure connections. If the server does not support secure connections, the connector falls back to using an unencrypted connection. required The connector establishes an encrypted connection. If it is unable to establish an encrypted connection, the connector fails. verify_ca The connector behaves as when you set the required option, but it also verifies the server TLS certificate against the configured Certificate Authority (CA) certificates. If the server TLS certificate does not match any valid CA certificates, the connector fails. verify_identity The connector behaves as when you set the verify_ca option, but it also verifies that the server certificate matches the host of the remote connection. database.ssl.truststore Default value: No default The location of the trust store file for the server certificate verification. database.ssl.truststore.password Default value: No default The password for the trust store file. Used to check the integrity of the truststore, and unlock the truststore. enable.time.adjuster Default value: true Boolean value that indicates whether the connector converts a 2-digit year specification to 4 digits. Set the value to false when conversion is fully delegated to the database. MariaDB users can insert year values with either 2-digits or 4-digits. 2-digit values are mapped to a year in the range 1970 - 2069. By default, the connector performs the conversion. errors.max.retries Default value: -1 Specifies how the connector responds after an operation that results in a retriable error, such as a connection error. Set one of the following options: -1 No limit. The connector always restarts automatically, and retries the operation, regardless of the number of failures. 0 Disabled. The connector fails immediately, and never retries the operation. User intervention is required to restart the connector. > 0 The connector restarts automatically until it reaches the specified maximum number of retries. After the failure, the connector stops, and user intervention is required to restart it. event.converting.failure.handling.mode Default value: warn Specifies how the connector responds when it cannot convert a table record due to a mismatch between the data type of a column and the type specified by the Debezium internal schema. Set one of the following options: fail An exception reports that conversion failed because the data type of the field did not match the schema type, and indicates that it might be necessary to restart the connector in schema _only_recovery mode to enable a successful conversion. warn The connector writes a null value to the event field for the column that failed conversion, writes a message to the warning log . skip The connector writes a null value to the event field for the column that failed conversion, and writes a message to the debug log. event.processing.failure.handling.mode Default value: fail Specifies how the connector handles failures that occur when processing events, for example, if it encounters a corrupted event. The following settings are available: fail The connector raises an exception that reports the problematic event and its position. The connector then stops. warn The connector does not raise an exception. Instead, it logs the problematic event and its position, and then skips the event. ignore The connector ignores the problematic event, and does not generate a log entry. heartbeat.action.query Default value: No default Specifies a query that the connector executes on the source database when the connector sends a heartbeat message. For example, the following query periodically captures the state of the executed GTID set in the source database. INSERT INTO gtid_history_table (select @gtid_executed) heartbeat.interval.ms Default value: 0 Specifies how frequently the connector sends heartbeat messages to a Kafka topic. By default, the connector does not send heartbeat messages. Heartbeat messages are useful for monitoring whether the connector is receiving change events from the database. Heartbeat messages might help decrease the number of change events that need to be re-sent when a connector restarts. To send heartbeat messages, set this property to a positive integer, which indicates the number of milliseconds between heartbeat messages. incremental.snapshot.allow.schema.changes Default value: false Specifies whether the connector allows schema changes during an incremental snapshot. When the value is set to true , the connector detects schema change during an incremental snapshot, and re-select a current chunk to avoid locking DDLs. Changes to a primary key are not supported. Changing the primary during an incremental snapshot, can lead to incorrect results. A further limitation is that if a schema change affects only the default values of columns, then the change is not detected until the DDL is processed from the binlog stream. This does not affect the values of snapshot events, but the schema of these snapshot events may have outdated defaults. incremental.snapshot.chunk.size Default value: 1024 The maximum number of rows that the connector fetches and reads into memory when it retrieves an incremental snapshot chunk. Increasing the chunk size provides greater efficiency, because the snapshot runs fewer snapshot queries of a greater size. However, larger chunk sizes also require more memory to buffer the snapshot data. Adjust the chunk size to a value that provides the best performance in your environment. incremental.snapshot.watermarking.strategy Default value: insert_insert Specifies the watermarking mechanism that the connector uses during an incremental snapshot to deduplicate events that might be captured by an incremental snapshot and then recaptured after streaming resumes. You can specify one of the following options: insert_insert (default) When you send a signal to initiate an incremental snapshot, for every chunk that Debezium reads during the snapshot, it writes an entry to the signaling data collection to record the signal to open the snapshot window. After the snapshot completes, Debezium inserts a second entry that records the signal to close the window. insert_delete When you send a signal to initiate an incremental snapshot, for every chunk that Debezium reads, it writes a single entry to the signaling data collection to record the signal to open the snapshot window. After the snapshot completes, this entry is removed. No entry is created for the signal to close the snapshot window. Set this option to prevent rapid growth of the signaling data collection. max.batch.size Default value: 2048 Positive integer value that specifies the maximum size of each batch of events that should be processed during each iteration of this connector. max.queue.size Default value: 8192 A positive integer value that specifies the maximum number of records that the blocking queue can hold. When Debezium reads events streamed from the database, it places the events in the blocking queue before it writes them to Kafka. The blocking queue can provide backpressure for reading change events from the database in cases where the connector ingests messages faster than it can write them to Kafka, or when Kafka becomes unavailable. Events that are held in the queue are disregarded when the connector periodically records offsets. Always set max.queue.size to a value that is larger than the value of max.batch.size . max.queue.size.in.bytes Default value: 0 A long integer value that specifies the maximum volume of the blocking queue in bytes. By default, volume limits are not specified for the blocking queue. To specify the number of bytes that the queue can consume, set this property to a positive long value. If max.queue.size is also set, writing to the queue is blocked when the size of the queue reaches the limit specified by either property. For example, if you set max.queue.size=1000 , and max.queue.size.in.bytes=5000 , writing to the queue is blocked after the queue contains 1000 records, or after the volume of the records in the queue reaches 5000 bytes. min.row.count.to.stream.results Default value: 1000 During a snapshot, the connector queries each table for which the connector is configured to capture changes. The connector uses each query result to produce a read event that contains data for all rows in that table. This property determines whether the MariaDB connector puts results for a table into memory, which is fast but requires large amounts of memory, or streams the results, which can be slower but work for very large tables. The setting of this property specifies the minimum number of rows a table must contain before the connector streams results. To skip all table size checks and always stream all results during a snapshot, set this property to 0 . notification.enabled.channels Default value: No default List of notification channel names that are enabled for the connector. By default, the following channels are available: sink log jmx poll.interval.ms Default value: 500 (0.5 seconds) Positive integer value that specifies the number of milliseconds the connector waits for new change events to appear before it starts processing a batch of events. provide.transaction.metadata Default value: false Determines whether the connector generates events with transaction boundaries and enriches change event envelopes with transaction metadata. Specify true if you want the connector to do this. For more information, see Transaction metadata . signal.data.collection Default value: No default Fully-qualified name of the data collection that is used to send signals to the connector. Use the following format to specify the collection name: <databaseName> . <tableName> signal.enabled.channels Default value: No default List of the signaling channel names that are enabled for the connector. By default, the following channels are available: source kafka file jmx skipped.operations Default value: t A comma-separated list of operation types that will be skipped during streaming. The operations include: c for inserts/create, u for updates, d for deletes, t for truncates, and none to not skip any operations. By default, truncate operations are skipped. snapshot.delay.ms Default value: No default An interval in milliseconds that the connector should wait before performing a snapshot when the connector starts. If you are starting multiple connectors in a cluster, this property is useful for avoiding snapshot interruptions, which might cause re-balancing of connectors. snapshot.fetch.size Default value: Unset By default, during a snapshot, the connector reads table content in batches of rows. Set this property to specify the maximum number of rows in a batch. snapshot.include.collection.list Default value: All tables specified in the table.include.list . An optional, comma-separated list of regular expressions that match the fully-qualified names ( <databaseName>.<tableName> ) of the tables to include in a snapshot. The specified items must be named in the connector's table.include.list property. This property takes effect only if the connector's snapshot.mode property is set to a value other than never . This property does not affect the behavior of incremental snapshots. To match the name of a table, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the table; it does not match substrings that might be present in a table name. snapshot.lock.timeout.ms Default value: 10000 Positive integer that specifies the maximum amount of time (in milliseconds) to wait to obtain table locks when performing a snapshot. If the connector cannot acquire table locks in this time interval, the snapshot fails. For more information, see snapshot.locking.mode Default value: minimal Specifies whether and for how long the connector holds the global MariaDB read lock, which prevents any updates to the database while the connector is performing a snapshot. The following settings are available: minimal The connector holds the global read lock for only the initial phase of the snapshot during which it reads the database schemas and other metadata. During the phase of the snapshot, the connector releases the lock as it selects all rows from each table. To perform the SELECT operation in a consistent fashion, the connector uses a REPEATABLE READ transaction. Although the release of the global read lock permits other MariaDB clients to update the database, use of REPEATABLE READ isolation ensures a consistent snapshot, because the connector continues to read the same data for the duration of the transaction. extended Blocks all write operations for the duration of the snapshot. Use this setting if clients submit concurrent operations that are incompatible with the REPEATABLE READ isolation level in MariaDB. none Prevents the connector from acquiring any table locks during the snapshot. Although this option is allowed with all snapshot modes, it is safe to use only if no schema changes occur while the snapshot is running. Tables that are defined with the MyISAM engine always acquire a table lock. As a result, such tables are locked even if you set this option. This behavior differs from tables that are defined by the InnoDB engine, which acquire row-level locks. snapshot.max.threads Default value: 1 Specifies the number of threads that the connector uses when performing an initial snapshot. To enable parallel initial snapshots, set the property to a value greater than 1. In a parallel initial snapshot, the connector processes multiple tables concurrently. Important Parallel initial snapshots is a Developer Preview feature only. Developer Preview software is not supported by Red Hat in any way and is not functionally complete or production-ready. Do not use Developer Preview software for production or business-critical workloads. Developer Preview software provides early access to upcoming product software in advance of its possible inclusion in a Red Hat product offering. Customers can use this software to test functionality and provide feedback during the development process. This software is subject to change or removal at any time, and has received limited testing. Red Hat might provide ways to submit feedback on Developer Preview software without an associated SLA. For more information about the support scope of Red Hat Developer Preview software, see Developer Preview Support Scope . snapshot.mode Default value: initial Specifies the criteria for running a snapshot when the connector starts. The following settings are available: always The connector performs a snapshot every time that it starts. The snapshot includes the structure and data of the captured tables. Specify this value to populate topics with a complete representation of the data from the captured tables every time that the connector starts. initial (default) The connector runs a snapshot only when no offsets have been recorded for the logical server name, or if it detects that an earlier snapshot failed to complete. After the snapshot completes, the connector begins to stream event records for subsequent database changes. initial_only The connector runs a snapshot only when no offsets have been recorded for the logical server name. After the snapshot completes, the connector stops. It does not transition to streaming to read change events from the binlog. schema_only Deprecated, see no_data . no_data The connector runs a snapshot that captures only the schema, but not any table data. Set this option if you do not need the topics to contain a consistent snapshot of the data, but you want to capture any schema changes that were applied after the last connector restart. schema_only_recovery Deprecated, see recovery . recovery Set this option to restore a database schema history topic that is lost or corrupted. After a restart, the connector runs a snapshot that rebuilds the topic from the source tables. You can also set the property to periodically prune a database schema history topic that experiences unexpected growth. Warning Do not use this mode to perform a snapshot if schema changes were committed to the database after the last connector shutdown. never When the connector starts, rather than performing a snapshot, it immediately begins to stream event records for subsequent database changes. This option is under consideration for future deprecation, in favor of the no_data option. when_needed After the connector starts, it performs a snapshot only if it detects one of the following circumstances: It cannot detect any topic offsets. A previously recorded offset specifies a binlog position or GTID that is not available on the server. snapshot.query.mode Default value: select_all Specifies how the connector queries data while performing a snapshot. Set one of the following options: select_all (default) The connector uses a select all query to retrieve rows from captured tables, optionally adjusting the columns selected based on the column include and exclude list configurations. This setting enables you to manage snapshot content in a more flexible manner compared to using the snapshot.select.statement.overrides property. snapshot.select.statement.overrides Default value: No default Specifies the table rows to include in a snapshot. Use the property if you want a snapshot to include only a subset of the rows in a table. This property affects snapshots only. It does not apply to events that the connector reads from the log. The property contains a comma-separated list of fully-qualified table names in the form <databaseName>.<tableName> . For example, "snapshot.select.statement.overrides": "inventory.products,customers.orders" For each table in the list, add a further configuration property that specifies the SELECT statement for the connector to run on the table when it takes a snapshot. The specified SELECT statement determines the subset of table rows to include in the snapshot. Use the following format to specify the name of this SELECT statement property: snapshot.select.statement.overrides. <databaseName> . <tableName> For example, snapshot.select.statement.overrides.customers.orders From a customers.orders table that includes the soft-delete column, delete_flag , add the following properties if you want a snapshot to include only those records that are not soft-deleted: In the resulting snapshot, the connector includes only the records for which delete_flag = 0 . snapshot.tables.order.by.row.count Default value: disabled Specifies the order in which the connector processes tables when it performs an initial snapshot. Set one of the following options: descending The connector snapshots tables in order, based on the number of rows from the highest to the lowest. ascending The connector snapshots tables in order, based on the number of rows, from lowest to highest. disabled The connector disregards row count when performing an initial snapshot. streaming.delay.ms Default value: 0 Specifies the time, in milliseconds, that the connector delays the start of the streaming process after it completes a snapshot. Setting a delay interval helps to prevent the connector from restarting snapshots in the event that a failure occurs immediately after the snapshot completes, but before the streaming process begins. Set a delay value that is higher than the value of the offset.flush.interval.ms property that is set for the Kafka Connect worker. table.ignore.builtin Default value: true A Boolean value that specifies whether built-in system tables should be ignored. This applies regardless of the table include and exclude lists. By default, changes that occur to the values in system tables are excluded from capture, and Debezium does not generate events for system table changes. topic.cache.size Default value: 10000 Specifies the number of topic names that can be stored in memory in a bounded concurrent hash map. The connector uses the cache to help determine the topic name that corresponds to a data collection. topic.delimiter Default value: . Specifies the delimiter that the connector inserts between components of the topic name. topic.heartbeat.prefix Default value: __debezium-heartbeat Specifies the name of the topic to which the connector sends heartbeat messages. The topic name takes the following format: topic.heartbeat.prefix . topic.prefix For example, if the topic prefix is fulfillment , the default topic name is __debezium-heartbeat.fulfillment . topic.naming.strategy Default value: io.debezium.schema.DefaultTopicNamingStrategy The name of the TopicNamingStrategy class that the connector uses. The specified strategy determines how the connector names the topics that store event records for data changes, schema changes, transactions, heartbeats, and so forth. topic.transaction Default value: transaction Specifies the name of the topic to which the connector sends transaction metadata messages. The topic name takes the following pattern: topic.prefix . topic.transaction For example, if the topic prefix is fulfillment , the default topic name is fulfillment.transaction . use.nongraceful.disconnect Default value: false A Boolean value that specifies whether the binary log client's keepalive thread sets the SO_LINGER socket option to 0 to immediately close stale TCP connections. Set the value to true if the connector experiences deadlocks in SSLSocketImpl.close . Debezium connector database schema history configuration properties Debezium provides a set of schema.history.internal.* properties that control how the connector interacts with the schema history topic. The following table describes the schema.history.internal properties for configuring the Debezium connector. Table 2.52. Connector database schema history configuration properties Property Default Description schema.history.internal.kafka.topic No default The full name of the Kafka topic where the connector stores the database schema history. schema.history.internal.kafka.bootstrap.servers No default A list of host/port pairs that the connector uses for establishing an initial connection to the Kafka cluster. This connection is used for retrieving the database schema history previously stored by the connector, and for writing each DDL statement read from the source database. Each pair should point to the same Kafka cluster used by the Kafka Connect process. schema.history.internal.kafka.recovery.poll.interval.ms 100 An integer value that specifies the maximum number of milliseconds the connector should wait during startup/recovery while polling for persisted data. The default is 100ms. schema.history.internal.kafka.query.timeout.ms 3000 An integer value that specifies the maximum number of milliseconds the connector should wait while fetching cluster information using Kafka admin client. schema.history.internal.kafka.create.timeout.ms 30000 An integer value that specifies the maximum number of milliseconds the connector should wait while create kafka history topic using Kafka admin client. schema.history.internal.kafka.recovery.attempts 100 The maximum number of times that the connector should try to read persisted history data before the connector recovery fails with an error. The maximum amount of time to wait after receiving no data is recovery.attempts x recovery.poll.interval.ms . schema.history.internal.skip.unparseable.ddl false A Boolean value that specifies whether the connector should ignore malformed or unknown database statements or stop processing so a human can fix the issue. The safe default is false . Skipping should be used only with care as it can lead to data loss or mangling when the binlog is being processed. schema.history.internal.store.only.captured.tables.ddl false A Boolean value that specifies whether the connector records schema structures from all tables in a schema or database, or only from tables that are designated for capture. Specify one of the following values: false (default) During a database snapshot, the connector records the schema data for all non-system tables in the database, including tables that are not designated for capture. It's best to retain the default setting. If you later decide to capture changes from tables that you did not originally designate for capture, the connector can easily begin to capture data from those tables, because their schema structure is already stored in the schema history topic. Debezium requires the schema history of a table so that it can identify the structure that was present at the time that a change event occurred. true During a database snapshot, the connector records the table schemas only for the tables from which Debezium captures change events. If you change the default value, and you later configure the connector to capture data from other tables in the database, the connector lacks the schema information that it requires to capture change events from the tables. schema.history.internal.store.only.captured.databases.ddl true A Boolean value that specifies whether the connector records schema structures from all logical databases in the database instance. Specify one of the following values: true The connector records schema structures only for tables in the logical database and schema from which Debezium captures change events. false The connector records schema structures for all logical databases. Pass-through MariaDB connector configuration properties You can set pass-through properties in the connector configuration to customize the behavior of the Apache Kafka producer and consumer. For information about the full range of configuration properties for Kafka producers and consumers, see the Kafka documentation . Pass-through properties for configuring how producer and consumer clients interact with schema history topics Debezium relies on an Apache Kafka producer to write schema changes to database schema history topics. Similarly, it relies on a Kafka consumer to read from database schema history topics when a connector starts. You define the configuration for the Kafka producer and consumer clients by assigning values to a set of pass-through configuration properties that begin with the schema.history.internal.producer.* and schema.history.internal.consumer.* prefixes. The pass-through producer and consumer database schema history properties control a range of behaviors, such as how these clients secure connections with the Kafka broker, as shown in the following example: Debezium strips the prefix from the property name before it passes the property to the Kafka client. For more information about Kafka producer configuration properties and Kafka consumer configuration properties , see the Apache Kafka documentation . Pass-through properties for configuring how the MariaDB connector interacts with the Kafka signaling topic Debezium provides a set of signal.* properties that control how the connector interacts with the Kafka signals topic. The following table describes the Kafka signal properties. Table 2.53. Kafka signals configuration properties Property Default Description signal.kafka.topic <topic.prefix>-signal The name of the Kafka topic that the connector monitors for ad hoc signals. Note If automatic topic creation is disabled, you must manually create the required signaling topic. A signaling topic is required to preserve signal ordering. The signaling topic must have a single partition. signal.kafka.groupId kafka-signal The name of the group ID that is used by Kafka consumers. signal.kafka.bootstrap.servers No default A list of the host and port pairs that the connector uses to establish its initial connection to the Kafka cluster. Each pair references the Kafka cluster that is used by the Debezium Kafka Connect process. signal.kafka.poll.timeout.ms 100 An integer value that specifies the maximum number of milliseconds that the connector waits when polling signals. kafka.consumer.offset.commit.enabled false Specifies whether the Kafka consumer writes an offset commit after it reads a message from the signaling topic. The value that you assign to this property determines whether the connector can process requests that the signaling topic receives while the connector is offline. Choose one of the following settings: false When the connector is unavailable, the Kafka consumer does not commit an offset after it reads a signal received by the signaling topic. As a result, if the connector is offline for any interval, it cannot process requests that the signaling topic receives during the downtime. After the connector restarts, it always reads from the last position in the Kafka signaling topic, processing only signals that it receives after the restart. Signals received while the connector is offline are ignored, and are effectively lost. true When a user submits a request to the signaling topic, after the Kafka consumer reads the signal message it commits a topic offset, even if the connector is offline. Choose this option to provide Debezium with information about the last signal message that the consumer read, helping to ensure At-Least-Once delivery. After a connector restarts, it resumes processing from the last recorded offset, responding to signals that users submitted while the connector is offline. Pass-through properties for configuring the Kafka consumer client for the signaling channel The Debezium connector provides for pass-through configuration of the signals Kafka consumer. Pass-through signals properties begin with the prefix signals.consumer.* . For example, the connector passes properties such as signal.consumer.security.protocol=SSL to the Kafka consumer. Debezium strips the prefixes from the properties before it passes the properties to the Kafka signals consumer. Pass-through properties for configuring the MariaDB connector sink notification channel The following table describes properties that you can use to configure the Debezium sink notification channel. Table 2.54. Sink notification configuration properties Property Default Description notification.sink.topic.name No default The name of the topic that receives notifications from Debezium. This property is required when you configure the notification.enabled.channels property to include sink as one of the enabled notification channels. Debezium connector pass-through database driver configuration properties The Debezium connector provides for pass-through configuration of the database driver. Pass-through database properties begin with the prefix driver.* . For example, the connector passes properties such as driver.foobar=false to the JDBC URL. Debezium strips the prefixes from the properties before it passes the properties to the database driver. 2.2.7. Monitoring Debezium MariaDB connector performance The Debezium MariaDB connector provides three types of metrics that are in addition to the built-in support for JMX metrics that Zookeeper, Kafka, and Kafka Connect provide. Snapshot metrics provide information about connector operation while performing a snapshot. Streaming metrics provide information about connector operation when the connector is reading the binlog. Schema history metrics provide information about the status of the connector's schema history. Debezium monitoring documentation provides details for how to expose these metrics by using JMX. 2.2.7.1. Customized names for MariaDB connector snapshot and streaming MBean objects Debezium connectors expose metrics via the MBean name for the connector. These metrics, which are specific to each connector instance, provide data about the behavior of the connector's snapshot, streaming, and schema history processes. By default, when you deploy a correctly configured connector, Debezium generates a unique MBean name for each of the different connector metrics. To view the metrics for a connector process, you configure your observability stack to monitor its MBean. But these default MBean names depend on the connector configuration; configuration changes can result in changes to the MBean names. A change to the MBean name breaks the linkage between the connector instance and the MBean, disrupting monitoring activity. In this scenario, you must reconfigure the observability stack to use the new MBean name if you want to resume monitoring. To prevent monitoring disruptions that result from MBean name changes, you can configure custom metrics tags. You configure custom metrics by adding the custom.metric.tags property to the connector configuration. The property accepts key-value pairs in which each key represents a tag for the MBean object name, and the corresponding value represents the value of that tag. For example: k1=v1,k2=v2 . Debezium appends the specified tags to the MBean name of the connector. After you configure the custom.metric.tags property for a connector, you can configure the observability stack to retrieve metrics associated with the specified tags. The observability stack then uses the specified tags, rather than the mutable MBean names to uniquely identify connectors. Later, if Debezium redefines how it constructs MBean names, or if the topic.prefix in the connector configuration changes, metrics collection is uninterrupted, because the metrics scrape task uses the specified tag patterns to identify the connector. A further benefit of using custom tags, is that you can use tags that reflect the architecture of your data pipeline, so that metrics are organized in a way that suits you operational needs. For example, you might specify tags with values that declare the type of connector activity, the application context, or the data source, for example, db1-streaming-for-application-abc . If you specify multiple key-value pairs, all of the specified pairs are appended to the connector's MBean name. The following example illustrates how tags modify the default MBean name. Example 2.16. How custom tags modify the connector MBean name By default, the MariaDB connector uses the following MBean name for streaming metrics: If you set the value of custom.metric.tags to database=salesdb-streaming,table=inventory , Debezium generates the following custom MBean name: 2.2.7.2. Monitoring Debezium during snapshots of MariaDB databases The MBean is debezium.mariadb:type=connector-metrics,context=snapshot,server= <topic.prefix> . Snapshot metrics are not exposed unless a snapshot operation is active, or if a snapshot has occurred since the last connector start. The following table lists the snapshot metrics that are available. Attributes Type Description LastEvent string The last snapshot event that the connector has read. MilliSecondsSinceLastEvent long The number of milliseconds since the connector has read and processed the most recent event. TotalNumberOfEventsSeen long The total number of events that this connector has seen since last started or reset. NumberOfEventsFiltered long The number of events that have been filtered by include/exclude list filtering rules configured on the connector. CapturedTables string[] The list of tables that are captured by the connector. QueueTotalCapacity int The length the queue used to pass events between the snapshotter and the main Kafka Connect loop. QueueRemainingCapacity int The free capacity of the queue used to pass events between the snapshotter and the main Kafka Connect loop. TotalTableCount int The total number of tables that are being included in the snapshot. RemainingTableCount int The number of tables that the snapshot has yet to copy. SnapshotRunning boolean Whether the snapshot was started. SnapshotPaused boolean Whether the snapshot was paused. SnapshotAborted boolean Whether the snapshot was aborted. SnapshotCompleted boolean Whether the snapshot completed. SnapshotDurationInSeconds long The total number of seconds that the snapshot has taken so far, even if not complete. Includes also time when snapshot was paused. SnapshotPausedDurationInSeconds long The total number of seconds that the snapshot was paused. If the snapshot was paused several times, the paused time adds up. RowsScanned Map<String, Long> Map containing the number of rows scanned for each table in the snapshot. Tables are incrementally added to the Map during processing. Updates every 10,000 rows scanned and upon completing a table. MaxQueueSizeInBytes long The maximum buffer of the queue in bytes. This metric is available if max.queue.size.in.bytes is set to a positive long value. CurrentQueueSizeInBytes long The current volume, in bytes, of records in the queue. The connector also provides the following additional snapshot metrics when an incremental snapshot is executed: Attributes Type Description ChunkId string The identifier of the current snapshot chunk. ChunkFrom string The lower bound of the primary key set defining the current chunk. ChunkTo string The upper bound of the primary key set defining the current chunk. TableFrom string The lower bound of the primary key set of the currently snapshotted table. TableTo string The upper bound of the primary key set of the currently snapshotted table. 2.2.7.3. Monitoring Debezium MariaDB connector record streaming The Debezium MariaDB connector provides three types of metrics that are in addition to the built-in support for JMX metrics that Zookeeper, Kafka, and Kafka Connect provide. Snapshot metrics provide information about connector operation while performing a snapshot. Streaming metrics provide information about connector operation when the connector is reading the binlog. Schema history metrics provide information about the status of the connector's schema history. Debezium monitoring documentation provides details for how to expose these metrics by using JMX. The MBean is debezium.mariadb:type=connector-metrics,context=streaming,server= <topic.prefix> . The following table lists the streaming metrics that are available. Attributes Type Description LastEvent string The last streaming event that the connector has read. MilliSecondsSinceLastEvent long The number of milliseconds since the connector has read and processed the most recent event. TotalNumberOfEventsSeen long The total number of data change events reported by the source database since the last connector start, or since a metrics reset. Represents the data change workload for Debezium to process. TotalNumberOfCreateEventsSeen long The total number of create events processed by the connector since its last start or metrics reset. TotalNumberOfUpdateEventsSeen long The total number of update events processed by the connector since its last start or metrics reset. TotalNumberOfDeleteEventsSeen long The total number of delete events processed by the connector since its last start or metrics reset. NumberOfEventsFiltered long The number of events that have been filtered by include/exclude list filtering rules configured on the connector. CapturedTables string[] The list of tables that are captured by the connector. QueueTotalCapacity int The length the queue used to pass events between the streamer and the main Kafka Connect loop. QueueRemainingCapacity int The free capacity of the queue used to pass events between the streamer and the main Kafka Connect loop. Connected boolean Flag that denotes whether the connector is currently connected to the database server. MilliSecondsBehindSource long The number of milliseconds between the last change event's timestamp and the connector processing it. The values will incorporate any differences between the clocks on the machines where the database server and the connector are running. NumberOfCommittedTransactions long The number of processed transactions that were committed. SourceEventPosition Map<String, String> The coordinates of the last received event. LastTransactionId string Transaction identifier of the last processed transaction. MaxQueueSizeInBytes long The maximum buffer of the queue in bytes. This metric is available if max.queue.size.in.bytes is set to a positive long value. CurrentQueueSizeInBytes long The current volume, in bytes, of records in the queue. 2.2.7.4. Monitoring Debezium MariaDB connector schema history The MBean is debezium.mariadb:type=connector-metrics,context=schema-history,server= <topic.prefix> . The following table lists the schema history metrics that are available. Attributes Type Description Status string One of STOPPED , RECOVERING (recovering history from the storage), RUNNING describing the state of the database schema history. RecoveryStartTime long The time in epoch seconds at what recovery has started. ChangesRecovered long The number of changes that were read during recovery phase. ChangesApplied long the total number of schema changes applied during recovery and runtime. MilliSecondsSinceLast RecoveredChange long The number of milliseconds that elapsed since the last change was recovered from the history store. MilliSecondsSinceLast AppliedChange long The number of milliseconds that elapsed since the last change was applied. LastRecoveredChange string The string representation of the last change recovered from the history store. LastAppliedChange string The string representation of the last applied change. 2.2.8. How Debezium MariaDB connectors handle faults and problems Debezium is a distributed system that captures all changes in multiple upstream databases; it never misses or loses an event. When the system is operating normally or being managed carefully then Debezium provides exactly once delivery of every change event record. If a fault does occur, the system does not lose any events. However, while Debezium is recovering from a fault, it might repeat some change events. In these abnormal situations, Debezium, like Kafka, provides at least once delivery of change events. Details are in the following sections: Configuration and startup errors MariaDB becomes unavailable Kafka Connect stops gracefully Kafka Connect process crashes Kafka becomes unavailable MariaDB purges binlog files Configuration and startup errors In the following situations, the connector fails when trying to start, reports an error or exception in the log, and stops running: The connector's configuration is invalid. The connector cannot successfully connect to the MariaDB server by using the specified connection parameters. The connector is attempting to restart at a position in the binlog for which MariaDB no longer has the history available. In these cases, the error message has details about the problem and possibly a suggested workaround. After you correct the configuration or address the MariaDB problem, restart the connector. MariaDB becomes unavailable If your MariaDB server becomes unavailable, the Debezium MariaDB connector fails with an error and the connector stops. When the server is available again, restart the connector. However, if you are connecting to a highly available MariaDB cluster, you can restart the connector immediately. It will connect to a different MariaDB server in the cluster, find the location in the server's binlog that represents the last transaction, and begin reading the new server's binlog from that specific location. Kafka Connect stops gracefully When Kafka Connect stops gracefully, there is a short delay while the Debezium MariaDB connector tasks are stopped and restarted on new Kafka Connect processes. Kafka Connect process crashes If Kafka Connect crashes, the process stops and any Debezium MariaDB connector tasks terminate without their most recently-processed offsets being recorded. In distributed mode, Kafka Connect restarts the connector tasks on other processes. However, the MariaDB connector resumes from the last offset recorded by the earlier processes. As a result, the replacement tasks might regenerate some events that were processed before the crash, creating duplicate events. Each change event message includes source-specific information that you can use to identify duplicate events, for example: Event origin MariaDB server's event time The binlog file name and position GTIDs. Kafka becomes unavailable The Kafka Connect framework records Debezium change events in Kafka by using the Kafka producer API. If the Kafka brokers become unavailable, the Debezium MariaDB connector pauses until the connection is reestablished, and the connector then resumes where it left off. MariaDB purges binlog files If the Debezium MariaDB connector stops for too long, the MariaDB server purges older binlog files and the connector's last position may be lost. When the connector is restarted, the MariaDB server no longer has the starting point and the connector performs another initial snapshot. If the snapshot is disabled, the connector fails with an error. See snapshots for details about how MariaDB connectors perform initial snapshots. 2.3. Debezium connector for MongoDB Debezium's MongoDB connector tracks a MongoDB replica set or a MongoDB sharded cluster for document changes in databases and collections, recording those changes as events in Kafka topics. The connector automatically handles the addition or removal of shards in a sharded cluster, changes in membership of each replica set, elections within each replica set, and awaiting the resolution of communications problems. For information about the MongoDB versions that are compatible with this connector, see the Debezium Supported Configurations page . Information and procedures for using a Debezium MongoDB connector is organized as follows: Section 2.3.1, "Overview of Debezium MongoDB connector" Section 2.3.2, "How Debezium MongoDB connectors work" Section 2.3.3, "Descriptions of Debezium MongoDB connector data change events" Section 2.3.4, "Setting up MongoDB to work with a Debezium connector" Section 2.3.5, "Deployment of Debezium MongoDB connectors" Section 2.3.6, "Monitoring Debezium MongoDB connector performance" Section 2.3.7, "How Debezium MongoDB connectors handle faults and problems" 2.3.1. Overview of Debezium MongoDB connector MongoDB's replication mechanism provides redundancy and high availability, and is the preferred way to run MongoDB in production. MongoDB connector captures the changes in a replica set or sharded cluster. A MongoDB replica set consists of a set of servers that all have copies of the same data, and replication ensures that all changes made by clients to documents on the replica set's primary are correctly applied to the other replica set's servers, called secondaries . MongoDB replication works by having the primary record the changes in its oplog (or operation log), and then each of the secondaries reads the primary's oplog and applies in order all of the operations to their own documents. When a new server is added to a replica set, that server first performs an snapshot of all of the databases and collections on the primary, and then reads the primary's oplog to apply all changes that might have been made since it began the snapshot. This new server becomes a secondary (and able to handle queries) when it catches up to the tail of the primary's oplog. 2.3.1.1. Description of how the MongoDB connector uses change streams to capture event records Although the Debezium MongoDB connector does not become part of a replica set, it uses a similar replication mechanism to obtain oplog data. The main difference is that the connector does not read the oplog directly. Instead, it delegates the capture and decoding of oplog data to the MongoDB change streams feature. With change streams, the MongoDB server exposes the changes that occur in a collection as an event stream. The Debezium connector monitors the stream and then delivers the changes downstream. The first time that the connector detects a replica set, it examines the oplog to obtain the last recorded transaction, and then performs a snapshot of the primary's databases and collections. After the connector finishes copying the data, it creates a change stream beginning from the oplog position that it read earlier. As the MongoDB connector processes changes, it periodically records the position at which the event originated in the oplog stream. When the connector stops, it records the last oplog stream position that it processed, so that after a restart it can resume streaming from that position. In other words, the connector can be stopped, upgraded or maintained, and restarted some time later, and always pick up exactly where it left off without losing a single event. Of course, MongoDB oplogs are usually capped at a maximum size, so if the connector is stopped for long periods, operations in the oplog might be purged before the connector has a chance to read them. In this case, after a restart the connector detects the missing oplog operations, performs a snapshot, and then proceeds to stream changes. The MongoDB connector is also quite tolerant of changes in membership and leadership of the replica sets, of additions or removals of shards within a sharded cluster, and network problems that might cause communication failures. The connector always uses the replica set's primary node to stream changes, so when the replica set undergoes an election and a different node becomes primary, the connector will immediately stop streaming changes, connect to the new primary, and start streaming changes using the new primary node. Similarly, if connector is unable to communicate with the replica set primary, it attempts to reconnect (using exponential backoff so as to not overwhelm the network or replica set). After connection is reestablished, the connector continues to stream changes from the last event that it captured. In this way the connector dynamically adjusts to changes in replica set membership, and automatically handles communication disruptions. Additional resources Replication mechanism Replica set Replica set elections Sharded cluster Shard addition Shard removal Change Streams 2.3.1.2. Description of how the MongoDB connector uses the MongoDB read preference You specify read preferences for a MongoDB connection by setting the readPreference parameter in the mongodb.connection.string . 2.3.2. How Debezium MongoDB connectors work An overview of the MongoDB topologies that the connector supports is useful for planning your application. The following topics provide details about how the Debezium MongoDB connector works: Section 2.3.2.1, "MongoDB topologies supported by Debezium connectors" Section 2.3.2.3, "How Debezium MongoDB connectors use logical names for replica sets and sharded clusters" Section 2.3.2.5, "How Debezium MongoDB connectors perform snapshots" Section 2.3.2.6, "Ad hoc snapshots" Section 2.3.2.7, "Incremental snapshots" Section 2.3.2.9, "How the Debezium MongoDB connector streams change event records" Section 2.3.2.11, "Default names of Kafka topics that receive Debezium MongoDB change event records" Section 2.3.2.12, "How event keys control topic partitioning for the Debezium MongoDB connector" Section 2.3.2.13, "Debezium MongoDB connector-generated events that represent transaction boundaries" 2.3.2.1. MongoDB topologies supported by Debezium connectors The MongoDB connector supports the following MongoDB topologies: MongoDB replica set The Debezium MongoDB connector can capture changes from a single MongoDB replica set . Production replica sets require a minimum of at least three members . To use the MongoDB connector with a replica set, you must set the value of the mongodb.connection.string property in the connector configuration to the replica set connection string . When the connector is ready to begin capturing changes from a MongoDB change stream, it starts a connection task. The connection task then uses the specified connection string to establish a connection to an available replica set member. MongoDB sharded cluster A MongoDB sharded cluster consists of: One or more shards , each deployed as a replica set; A separate replica set that acts as the cluster's configuration server One or more routers (also called mongos ) to which clients connect and that routes requests to the appropriate shards To use the MongoDB connector with a sharded cluster, in the connector configuration, set the value of the mongodb.connection.string property to the sharded cluster connection string . MongoDB standalone server The MongoDB connector is not capable of monitoring the changes of a standalone MongoDB server, since standalone servers do not have an oplog. The connector will work if the standalone server is converted to a replica set with one member. Note MongoDB does not recommend running a standalone server in production. For more information, see the MongoDB documentation . 2.3.2.2. User permissions required by Debezium connectors To capture data from MongoDB, Debezium attaches to the database as a MongoDB user. The MongoDB user account that you create for Debezium requires specific database permissions to read from the database. The connector user requires the following permissions: Read from the database. Run the hello command. The connector user might also require the following permission: Read from the config.shards system collection. Database read permissions The connector user must be able to read from all databases, or to read from a specific database, depending on the value of the connector's capture.scope property. Assign one of the following permissions to the user, depending on the capture.scope setting: capture.scope is set to deployment Grant the user permission to read any database. capture.scope is set to database Grant the user permission to read the database specified by the connector's capture.target property. capture.scope is set to collection Grant the user permission to read the collection specified by the connector's capture.target property. Important The use of the Debezium collection option for the capture.scope property is a Developer Preview feature. Developer Preview features are not supported by Red Hat in any way and are not functionally complete or production-ready. Do not use Developer Preview software for production or business-critical workloads. Developer Preview software provides early access to upcoming product software in advance of its possible inclusion in a Red Hat product offering. Customers can use this software to test functionality and provide feedback during the development process. Red Hat might provide ways to submit feedback on Developer Preview software without an associated SLA. For more information about the support scope of Red Hat Developer Preview software, see Developer Preview Support Scope . Permission to use the MongoDB hello command Regardless of the capture.scope setting, the user requires permission to run the MongoDB hello command. Permission to read the config.shards collection Depending on your Debezium environment, to enable the connector to perform offset consolidation, you must grant the connector user explicit permission to read the config.shards collection. Permission to read the config.shards collection is required for the following connector environments: Connectors upgraded from Debezium 2.5 or earlier. Connectors configured to capture changes from a sharded MongoDB cluster. 2.3.2.3. How Debezium MongoDB connectors use logical names for replica sets and sharded clusters The connector configuration property topic.prefix serves as a logical name for the MongoDB replica set or sharded cluster. The connector uses the logical name in a number of ways: as the prefix for all topic names, and as a unique identifier when recording the change stream position of each replica set. You should give each MongoDB connector a unique logical name that meaningfully describes the source MongoDB system. We recommend logical names begin with an alphabetic or underscore character, and remaining characters that are alphanumeric or underscore. 2.3.2.4. How Debezium MongoDB connectors perform offset consolidation The Debezium MongoDB connector no longer supports replica_set connections to sharded MongoDB deployments. As a result, the offsets recorded by connector versions that used the replica_set connection mode are incompatible with the current version. To minimize the affects of the connection mode change, and to prevent the connector from running unnecessary snapshots, when the connector restarts after the upgrade, it runs a procedure to consolidate offsets. During this offset consolidation procedure, the connector completes the following steps to reconcile offsets that were recorded by the earlier connector version: Offsets that were recorded by connector versions later than 2.5 are used as-is. Offsets for events that were captured in sharded connection mode from sharded MongoDB deployments, or from MongoDB replica set deployments, are used as-is. Shard-specific offsets that were recorded by connector versions 2.5.x and earlier are used as-is, if both of the following conditions apply: The offsets exist for all current database shards. Offset invalidation is enabled. If offset invalidation is disabled, the connector fails to start. After the connector processes existing offsets in the preceding steps, it resumes streaming changes, and then commits offsets for new events that it captures. If the offset consolidation procedure does not detect any existing offsets, the connector performs an initial snapshot . 2.3.2.5. How Debezium MongoDB connectors perform snapshots When a Debezium task starts to use a replica set, it uses the connector's logical name and the replica set name to find an offset that describes the position where the connector previously stopped reading changes. If an offset can be found and it still exists in the oplog, then the task immediately proceeds with streaming changes , starting at the recorded offset position. However, if no offset is found, or if the oplog no longer contains that position, the task must first obtain the current state of the replica set contents by performing a snapshot . This process starts by recording the current position of the oplog and recording that as the offset (along with a flag that denotes a snapshot has been started). The task then proceeds to copy each collection, spawning as many threads as possible (up to the value of the snapshot.max.threads configuration property) to perform this work in parallel. The connector records a separate read event for each document it sees. Each read event contains the object's identifier, the complete state of the object, and source information about the MongoDB replica set where the object was found. The source information also includes a flag that denotes that the event was produced during a snapshot. This snapshot will continue until it has copied all collections that match the connector's filters. If the connector is stopped before the tasks' snapshots are completed, upon restart the connector begins the snapshot again. Note Try to avoid task reassignment and reconfiguration while the connector performs snapshots of any replica sets. The connector generates log messages to report on the progress of the snapshot. To provide for the greatest control, run a separate Kafka Connect cluster for each connector. You can find more information about snapshots in the following sections: Section 2.6.2.3, "Ad hoc snapshots" Section 2.6.2.4, "Incremental snapshots" Table 2.55. Settings for snapshot.mode connector configuration property Setting Description always The connector performs a snapshot every time that it starts. After the snapshot completes, the connector begins to stream event records for subsequent database changes. initial After the connector starts, it performs an initial database snapshot. initial_only The connector performs a database snapshot. After the snapshot completes, the connector stops, and does not stream event records for subsequent database changes. never Deprecated, see no_data . no_data The connector captures the structure of all relevant tables, but it does not create READ events to represent the data set at the point of the connector's start-up. when_needed After the connector starts, it performs a snapshot only if it detects one of the following circumstances: It cannot detect any topic offsets. A previously recorded offset specifies a log position that is not available on the server. For more information, see snapshot.mode in the table of connector configuration properties. 2.3.2.6. Ad hoc snapshots By default, a connector runs an initial snapshot operation only after it starts for the first time. Following this initial snapshot, under normal circumstances, the connector does not repeat the snapshot process. Any future change event data that the connector captures comes in through the streaming process only. However, in some situations the data that the connector obtained during the initial snapshot might become stale, lost, or incomplete. To provide a mechanism for recapturing collection data, Debezium includes an option to perform ad hoc snapshots. You might want to perform an ad hoc snapshot after any of the following changes occur in your Debezium environment: The connector configuration is modified to capture a different set of collections. Kafka topics are deleted and must be rebuilt. Data corruption occurs due to a configuration error or some other problem. You can re-run a snapshot for a collection for which you previously captured a snapshot by initiating a so-called ad-hoc snapshot . Ad hoc snapshots require the use of signaling collections . You initiate an ad hoc snapshot by sending a signal request to the Debezium signaling collection. When you initiate an ad hoc snapshot of an existing collection, the connector appends content to the topic that already exists for the collection. If a previously existing topic was removed, Debezium can create a topic automatically if automatic topic creation is enabled. Ad hoc snapshot signals specify the collections to include in the snapshot. The snapshot can capture the entire contents of the database, or capture only a subset of the collections in the database. Also, the snapshot can capture a subset of the contents of the collection(s) in the database. You specify the collections to capture by sending an execute-snapshot message to the signaling collection. Set the type of the execute-snapshot signal to incremental or blocking , and provide the names of the collections to include in the snapshot, as described in the following table: Table 2.56. Example of an ad hoc execute-snapshot signal record Field Default Value type incremental Specifies the type of snapshot that you want to run. Currently, you can request incremental or blocking snapshots. data-collections N/A An array that contains regular expressions matching the fully-qualified names of the collections to include in the snapshot. For the MongoDB connector, use the following format to specify the fully qualified name of a collection: database.collection . additional-conditions N/A An optional array that specifies a set of additional conditions that the connector evaluates to determine the subset of records to include in a snapshot. Each additional condition is an object that specifies the criteria for filtering the data that an ad hoc snapshot captures. You can set the following parameters for each additional condition: data-collection The fully-qualified name of the collection that the filter applies to. You can apply different filters to each collection. filter Specifies column values that must be present in a database record for the snapshot to include it, for example, "color='blue'" . The values that you assign to the filter parameter are the same types of values that you might specify in the WHERE clause of SELECT statements when you set the snapshot.select.statement.overrides property for a blocking snapshot. surrogate-key N/A An optional string that specifies the column name that the connector uses as the primary key of a collection during the snapshot process. Triggering an ad hoc incremental snapshot You initiate an ad hoc incremental snapshot by adding an entry with the execute-snapshot signal type to the signaling collection, or by sending a signal message to a Kafka signaling topic . After the connector processes the message, it begins the snapshot operation. The snapshot process reads the first and last primary key values and uses those values as the start and end point for each collection. Based on the number of entries in the collection, and the configured chunk size, Debezium divides the collection into chunks, and proceeds to snapshot each chunk, in succession, one at a time. For more information, see Incremental snapshots . Triggering an ad hoc blocking snapshot You initiate an ad hoc blocking snapshot by adding an entry with the execute-snapshot signal type to the signaling collection or signaling topic. After the connector processes the message, it begins the snapshot operation. The connector temporarily stops streaming, and then initiates a snapshot of the specified collection, following the same process that it uses during an initial snapshot. After the snapshot completes, the connector resumes streaming. For more information, see Blocking snapshots . 2.3.2.7. Incremental snapshots To provide flexibility in managing snapshots, Debezium includes a supplementary snapshot mechanism, known as incremental snapshotting . Incremental snapshots rely on the Debezium mechanism for sending signals to a Debezium connector . In an incremental snapshot, instead of capturing the full state of a database all at once, as in an initial snapshot, Debezium captures each collection in phases, in a series of configurable chunks. You can specify the collections that you want the snapshot to capture and the size of each chunk . The chunk size determines the number of rows that the snapshot collects during each fetch operation on the database. The default chunk size for incremental snapshots is 1024 rows. As an incremental snapshot proceeds, Debezium uses watermarks to track its progress, maintaining a record of each collection row that it captures. This phased approach to capturing data provides the following advantages over the standard initial snapshot process: You can run incremental snapshots in parallel with streamed data capture, instead of postponing streaming until the snapshot completes. The connector continues to capture near real-time events from the change log throughout the snapshot process, and neither operation blocks the other. If the progress of an incremental snapshot is interrupted, you can resume it without losing any data. After the process resumes, the snapshot begins at the point where it stopped, rather than recapturing the collection from the beginning. You can run an incremental snapshot on demand at any time, and repeat the process as needed to adapt to database updates. For example, you might re-run a snapshot after you modify the connector configuration to add a collection to its collection.include.list property. Incremental snapshot process When you run an incremental snapshot, Debezium sorts each collection by primary key and then splits the collection into chunks based on the configured chunk size . Working chunk by chunk, it then captures each collection row in a chunk. For each row that it captures, the snapshot emits a READ event. That event represents the value of the row when the snapshot for the chunk began. As a snapshot proceeds, it's likely that other processes continue to access the database, potentially modifying collection records. To reflect such changes, INSERT , UPDATE , or DELETE operations are committed to the transaction log as per usual. Similarly, the ongoing Debezium streaming process continues to detect these change events and emits corresponding change event records to Kafka. How Debezium resolves collisions among records with the same primary key In some cases, the UPDATE or DELETE events that the streaming process emits are received out of sequence. That is, the streaming process might emit an event that modifies a collection row before the snapshot captures the chunk that contains the READ event for that row. When the snapshot eventually emits the corresponding READ event for the row, its value is already superseded. To ensure that incremental snapshot events that arrive out of sequence are processed in the correct logical order, Debezium employs a buffering scheme for resolving collisions. Only after collisions between the snapshot events and the streamed events are resolved does Debezium emit an event record to Kafka. Snapshot window To assist in resolving collisions between late-arriving READ events and streamed events that modify the same collection row, Debezium employs a so-called snapshot window . The snapshot window demarcates the interval during which an incremental snapshot captures data for a specified collection chunk. Before the snapshot window for a chunk opens, Debezium follows its usual behavior and emits events from the transaction log directly downstream to the target Kafka topic. But from the moment that the snapshot for a particular chunk opens, until it closes, Debezium performs a de-duplication step to resolve collisions between events that have the same primary key.. For each data collection, the Debezium emits two types of events, and stores the records for them both in a single destination Kafka topic. The snapshot records that it captures directly from a table are emitted as READ operations. Meanwhile, as users continue to update records in the data collection, and the transaction log is updated to reflect each commit, Debezium emits UPDATE or DELETE operations for each change. As the snapshot window opens, and Debezium begins processing a snapshot chunk, it delivers snapshot records to a memory buffer. During the snapshot windows, the primary keys of the READ events in the buffer are compared to the primary keys of the incoming streamed events. If no match is found, the streamed event record is sent directly to Kafka. If Debezium detects a match, it discards the buffered READ event, and writes the streamed record to the destination topic, because the streamed event logically supersede the static snapshot event. After the snapshot window for the chunk closes, the buffer contains only READ events for which no related transaction log events exist. Debezium emits these remaining READ events to the collection's Kafka topic. The connector repeats the process for each snapshot chunk. Currently, you can use either of the following methods to initiate an incremental snapshot: Send an ad hoc snapshot signal to the signaling collection on the source database . Send a message to a configured Kafka signaling topic . Warning Incremental snapshots require that the primary key for each table is stably ordered. Because String fields can include special characters, and are subject to different encodings, string-based primary keys do not lend themselves to sorting in a consistent and predictable order. When performing incremental snapshots, it's best to set the primary key to a data type other than String . For more information about BSON string types in MongoDB, see the MongoDB documentation ). Incremental snapshots for sharded clusters To use incremental snapshots with sharded MongoDB clusters, you must set incremental.snapshot.chunk.size to a value that is high enough to compensate for the increased complexity of change stream pipelines. 2.3.2.7.1. Triggering an incremental snapshot To initiate an incremental snapshot, you can send an ad hoc snapshot signal to the signaling collection on the source database. You submit a signal to the signaling collection by using the MongoDB insert() method. After Debezium detects the change in the signaling collection, it reads the signal, and runs the requested snapshot operation. The query that you submit specifies the collections to include in the snapshot, and, optionally, specifies the type of snapshot operation. Currently, the only valid options for snapshots operations are incremental and blocking . To specify the collections to include in the snapshot, provide a data-collections array that lists the collections or an array of regular expressions used to match collections, for example, {"data-collections": ["public.Collection1", "public.Collection2"]} The data-collections array for an incremental snapshot signal has no default value. If the data-collections array is empty, Debezium detects that no action is required and does not perform a snapshot. Note If the name of a collection that you want to include in a snapshot contains a dot ( . ) in the name of the database, schema, or table, to add the collection to the data-collections array, you must escape each part of the name in double quotes. For example, to include a data collection that exists in the public database, and that has the name My.Collection , use the following format: "public"."My.Collection" . Prerequisites Signaling is enabled . A signaling data collection exists on the source database. The signaling data collection is specified in the signal.data.collection property. Using a source signaling channel to trigger an incremental snapshot Insert a snapshot signal document into the signaling collection: <signalDataCollection> .insert({" id" : _<idNumber> ,"type" : <snapshotType> , "data" : {"data-collections" [" <collectionName> ", " <collectionName> "],"type": <snapshotType> , "additional-conditions" : [{"data-collections" : " <collectionName> ", "filter" : " <additional-condition> "}] }}); For example, db.debeziumSignal.insert({ 1 "type" : "execute-snapshot", 2 3 "data" : { "data-collections" ["\"public\".\"Collection1\"", "\"public\".\"Collection2\""], 4 "type": "incremental"} 5 "additional-conditions":[{"data-collection": "schema1.table1" ,"filter":"color=\'blue\'"}]}'); 6 }); The values of the id , type , and data parameters in the command correspond to the fields of the signaling collection . The following table describes the parameters in the example: Table 2.57. Descriptions of fields in a MongoDB insert() command for sending an incremental snapshot signal to the signaling collection Item Value Description 1 db.debeziumSignal Specifies the fully-qualified name of the signaling collection on the source database. 2 null The _id parameter specifies an arbitrary string that is assigned as the id identifier for the signal request. The insert method in the preceding example omits use of the optional _id parameter. Because the document does not explicitly assign a value for the parameter, the arbitrary id that MongoDB automatically assigns to the document becomes the id identifier for the signal request. Use this string to identify logging messages to entries in the signaling collection. Debezium does not use this identifier string. Rather, during the snapshot, Debezium generates its own id string as a watermarking signal. 3 execute-snapshot Specifies type parameter specifies the operation that the signal is intended to trigger. 4 data-collections A required component of the data field of a signal that specifies an array of collection names or regular expressions to match collection names to include in the snapshot. The array lists regular expressions which match collections by their fully-qualified names, using the same format as you use to specify the name of the connector's signaling collection in the signal.data.collection configuration property. 5 incremental An optional type component of the data field of a signal that specifies the type of snapshot operation to run. Currently supports the incremental and blocking types. If you do not specify a value, the connector runs an incremental snapshot. 6 additional-conditions An optional array that specifies a set of additional conditions that the connector evaluates to determine the subset of records to include in a snapshot. Each element in the additional-conditions array is an object that includes the following keys: data-collection :: The fully-qualified name of the data collection for which the filter will be applied. filter :: Specifies the column values that must be present in a data collection record for the snapshot to include it, for example, "color='blue'" . The following example, shows the JSON for an incremental snapshot event that is captured by a connector. Example: Incremental snapshot event message { "before":null, "after": { "pk":"1", "value":"New data" }, "source": { ... "snapshot":"incremental" 1 }, "op":"r", 2 "ts_ms":"1620393591654", "ts_us":"1620393591654962", "ts_ns":"1620393591654962147", "transaction":null } Item Field name Description 1 snapshot Specifies the type of snapshot operation to run. Currently, the only valid options are blocking and incremental . Specifying a type value in the SQL query that you submit to the signaling collection is optional. If you do not specify a value, the connector runs an incremental snapshot. 2 op Specifies the event type. The value for snapshot events is r , signifying a READ operation. 2.3.2.7.2. Using the Kafka signaling channel to trigger an incremental snapshot You can send a message to the configured Kafka topic to request the connector to run an ad hoc incremental snapshot. The key of the Kafka message must match the value of the topic.prefix connector configuration option. The value of the message is a JSON object with type and data fields. The signal type is execute-snapshot , and the data field must have the following fields: Table 2.58. Execute snapshot data fields Field Default Value type incremental The type of the snapshot to be executed. Currently Debezium supports the incremental and blocking types. See the section for more details. data-collections N/A An array of comma-separated regular expressions that match the fully-qualified names of tables to include in the snapshot. Specify the names by using the same format as is required for the signal.data.collection configuration option. additional-conditions N/A An optional array of additional conditions that specifies criteria that the connector evaluates to designate a subset of records to include in a snapshot. Each additional condition is an object that specifies the criteria for filtering the data that an ad hoc snapshot captures. You can set the following parameters for each additional condition: data-collection :: The fully-qualified name of the collection that the filter applies to. You can apply different filters to each collection. filter :: Specifies column values that must be present in a database record for the snapshot to include it, for example, "color='blue'" . The values that you assign to the filter parameter are the same types of values that you might specify in the WHERE clause of SELECT statements when you set the snapshot.select.statement.overrides property for a blocking snapshot. Example 2.17. An execute-snapshot Kafka message Ad hoc incremental snapshots with additional-conditions Debezium uses the additional-conditions field to select a subset of a collection's content. Typically, when Debezium runs a snapshot, it runs a SQL query such as: SELECT * FROM <tableName> ... . When the snapshot request includes an additional-conditions property, the data-collection and filter parameters of the property are appended to the SQL query, for example: SELECT * FROM <data-collection> WHERE <filter> ... . For example, given a products collection with the columns id (primary key), color , and brand , if you want a snapshot to include only content for which color='blue' , when you request the snapshot, you could add the additional-conditions property to filter the content: Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["db1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "db1.products" ,"filter":"color='blue'"}]}}` You can also use the additional-conditions property to pass conditions based on multiple columns. For example, using the same products collection as in the example, if you want a snapshot to include only the content from the products collection for which color='blue' , and brand='MyBrand' , you could send the following request: Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["db1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "db1.products" ,"filter":"color='blue' AND brand='MyBrand'"}]}}` 2.3.2.7.3. Stopping an incremental snapshot In some situations, it might be necessary to stop an incremental snapshot. For example, you might realize that snapshot was not configured correctly, or maybe you want to ensure that resources are available for other database operations. You can stop a snapshot that is already running by sending a signal to the collection on the source database. You submit a stop snapshot signal to the signaling collection by inserting a stop snapshot signal document into it. The stop snapshot signal that you submit specifies the type of the snapshot operation as incremental , and, optionally specifies the collections that you want to omit from the currently running snapshot. After Debezium detects the change in the signaling collection, it reads the signal, and stops the incremental snapshot operation if it's in progress. Additional resources You can also stop an incremental snapshot by sending a JSON message to the Kafka signaling topic . Prerequisites Signaling is enabled . A signaling data collection exists on the source database. The signaling data collection is specified in the signal.data.collection property. Using a source signaling channel to stop an incremental snapshot Insert a stop snapshot signal document into the signaling collection: <signalDataCollection> .insert({" id" : _<idNumber> ,"type" : "stop-snapshot", "data" : {"data-collections" [" <collectionName> ", " <collectionName> "],"type": "incremental"}}); For example, db.debeziumSignal.insert({ 1 "type" : "stop-snapshot", 2 3 "data" : { "data-collections" ["\"public\".\"Collection1\"", "\"public\".\"Collection2\""], 4 "type": "incremental"} 5 }); The values of the id , type , and data parameters in the signal command correspond to the fields of the signaling collection . The following table describes the parameters in the example: Table 2.59. Descriptions of fields in an insert command for sending a stop incremental snapshot document to the signaling collection Item Value Description 1 db.debeziumSignal Specifies the fully-qualified name of the signaling collection on the source database. 2 null The insert method in the preceding example omits use of the optional _id parameter. Because the document does not explicitly assign a value for the parameter, the arbitrary id that MongoDB automatically assigns to the document becomes the id identifier for the signal request. Use this string to identify logging messages to entries in the signaling collection. Debezium does not use this identifier string. 3 stop-snapshot The type parameter specifies the operation that the signal is intended to trigger. 4 data-collections An optional component of the data field of a signal that specifies an array of collection names or regular expressions to match collection names to remove from the snapshot. The array lists regular expressions that match collections by their fully-qualified names in the format database.collection . If you omit the data-collections array from the data field, the signal stops the entire incremental snapshot that is in progress. 5 incremental A required component of the data field of a signal that specifies the type of snapshot operation that is to be stopped. Currently, the only valid option is incremental . If you do not specify a type value, the signal fails to stop the incremental snapshot. 2.3.2.7.4. Using the Kafka signaling channel to stop an incremental snapshot You can send a signal message to the configured Kafka signaling topic to stop an ad hoc incremental snapshot. The key of the Kafka message must match the value of the topic.prefix connector configuration option. The value of the message is a JSON object with type and data fields. The signal type is stop-snapshot , and the data field must have the following fields: Table 2.60. Execute snapshot data fields Field Default Value type incremental The type of the snapshot to be executed. Currently Debezium supports only the incremental type. See the section for more details. data-collections N/A An optional array of comma-separated regular expressions that match the fully-qualified names of the tables an array of collection names or regular expressions to match collection names to remove from the snapshot. Specify collection names by using the format database.collection . The following example shows a typical stop-snapshot Kafka message: Key = `test_connector` Value = `{"type":"stop-snapshot","data": {"data-collections": ["db1.table1", "db1.table2"], "type": "INCREMENTAL"}}` 2.3.2.8. Blocking snapshots To provide more flexibility in managing snapshots, Debezium includes a supplementary ad hoc snapshot mechanism, known as a blocking snapshot . Blocking snapshots rely on the Debezium mechanism for sending signals to a Debezium connector . A blocking snapshot behaves just like an initial snapshot , except that you can trigger it at run time. You might want to run a blocking snapshot rather than use the standard initial snapshot process in the following situations: You add a new collection and you want to complete the snapshot while the connector is running. You add a large collection, and you want the snapshot to complete in less time than is possible with an incremental snapshot. Blocking snapshot process When you run a blocking snapshot, Debezium stops streaming, and then initiates a snapshot of the specified collection, following the same process that it uses during an initial snapshot. After the snapshot completes, the streaming is resumed. Configure snapshot You can set the following properties in the data component of a signal: data-collections: to specify which collections must be snapshot additional-conditions: You can specify different filters for different collection. The data-collection property is the fully-qualified name of the collection for which the filter will be applied. The filter property will have the same value used in the snapshot.select.statement.overrides For example: {"type": "blocking", "data-collections": ["schema1.table1", "schema1.table2"], "additional-conditions": [{"data-collection": "schema1.table1", "filter": "SELECT * FROM [schema1].[table1] WHERE column1 = 0 ORDER BY column2 DESC"}, {"data-collection": "schema1.table2", "filter": "SELECT * FROM [schema1].[table2] WHERE column2 > 0"}]} Possible duplicates A delay might exist between the time that you send the signal to trigger the snapshot, and the time when streaming stops and the snapshot starts. As a result of this delay, after the snapshot completes, the connector might emit some event records that duplicate records captured by the snapshot. 2.3.2.9. How the Debezium MongoDB connector streams change event records After the connector task for a replica set records an offset, it uses the offset to determine the position in the oplog where it should start streaming changes. The task then (depending on the configuration) either connects to the replica set's primary node or connects to a replica-set-wide change stream and starts streaming changes from that position. It processes all of create, insert, and delete operations, and converts them into Debezium change events . Each change event includes the position in the oplog where the operation was found, and the connector periodically records this as its most recent offset. The interval at which the offset is recorded is governed by offset.flush.interval.ms , which is a Kafka Connect worker configuration property. When the connector is stopped gracefully, the last offset processed is recorded so that, upon restart, the connector will continue exactly where it left off. If the connector's tasks terminate unexpectedly, however, then the tasks may have processed and generated events after it last records the offset but before the last offset is recorded; upon restart, the connector begins at the last recorded offset, possibly generating some the same events that were previously generated just prior to the crash. Note When all components in a Kafka pipeline operate nominally, Kafka consumers receive every message exactly once . However, when things go wrong, Kafka can only guarantee that consumers receive every message at least once . To avoid unexpected results, consumers must be able to handle duplicate messages. As mentioned earlier, the connector tasks always use the replica set's primary node to stream changes from the oplog, ensuring that the connector sees the most up-to-date operations as possible and can capture the changes with lower latency than if secondaries were to be used instead. When the replica set elects a new primary, the connector immediately stops streaming changes, connects to the new primary, and starts streaming changes from the new primary node at the same position. Likewise, if the connector experiences any problems communicating with the replica set members, it tries to reconnect, by using exponential backoff so as to not overwhelm the replica set, and once connected it continues streaming changes from where it last left off. In this way, the connector is able to dynamically adjust to changes in replica set membership and automatically handle communication failures. To summarize, the MongoDB connector continues running in most situations. Communication problems might cause the connector to wait until the problems are resolved. 2.3.2.10. MongoDB support for populating the before field in Debezium change event In MongoDB 6.0 and later, you can configure change streams to emit the pre-image state of a document to populate the before field for MongoDB change events. To enable the use of pre-images in MongoDB, you must set the changeStreamPreAndPostImages for a collection by using db.createCollection() , create , or collMod . To enable the Debezium MongoDB to include pre-images in change events, set the capture.mode for the connector to one of the *_with_pre_image options. Size limits on MongoDB change stream events The size of a MongoDB change stream event is limited to 16 megabytes. The use of pre-images thus increases the likelihood of exceeding this threshold, which can lead to failures. For information about how to avoid exceeding the change stream limit, see the MongoDB documentation . 2.3.2.11. Default names of Kafka topics that receive Debezium MongoDB change event records The MongoDB connector writes events for all insert, update, and delete operations to documents in each collection to a single Kafka topic. The name of the Kafka topics always takes the form logicalName . databaseName . collectionName , where logicalName is the logical name of the connector as specified with the topic.prefix configuration property, databaseName is the name of the database where the operation occurred, and collectionName is the name of the MongoDB collection in which the affected document existed. For example, consider a MongoDB replica set with an inventory database that contains four collections: products , products_on_hand , customers , and orders . If the connector monitoring this database were given a logical name of fulfillment , then the connector would produce events on these four Kafka topics: fulfillment.inventory.products fulfillment.inventory.products_on_hand fulfillment.inventory.customers fulfillment.inventory.orders Notice that the topic names do not incorporate the replica set name or shard name. As a result, all changes to a sharded collection (where each shard contains a subset of the collection's documents) all go to the same Kafka topic. You can set up Kafka to auto-create the topics as they are needed. If not, then you must use Kafka administration tools to create the topics before starting the connector. 2.3.2.12. How event keys control topic partitioning for the Debezium MongoDB connector The MongoDB connector does not make any explicit determination about how to partition topics for events. Instead, it allows Kafka to determine how to partition topics based on event keys. You can change Kafka's partitioning logic by defining the name of the Partitioner implementation in the Kafka Connect worker configuration. Kafka maintains total order only for events written to a single topic partition. Partitioning the events by key does mean that all events with the same key always go to the same partition. This ensures that all events for a specific document are always totally ordered. 2.3.2.13. Debezium MongoDB connector-generated events that represent transaction boundaries Debezium can generate events that represents transaction metadata boundaries and enrich change data event messages. Limits on when Debezium receives transaction metadata Debezium registers and receives metadata only for transactions that occur after you deploy the connector. Metadata for transactions that occur before you deploy the connector is not available. For every transaction BEGIN and END , Debezium generates an event that contains the following fields: status BEGIN or END id String representation of unique transaction identifier. event_count (for END events) Total number of events emitted by the transaction. data_collections (for END events) An array of pairs of data_collection and event_count that provides number of events emitted by changes originating from given data collection. The following example shows a typical message: { "status": "BEGIN", "id": "1462833718356672513", "event_count": null, "data_collections": null } { "status": "END", "id": "1462833718356672513", "event_count": 2, "data_collections": [ { "data_collection": "rs0.testDB.collectiona", "event_count": 1 }, { "data_collection": "rs0.testDB.collectionb", "event_count": 1 } ] } Unless overridden via the topic.transaction option, transaction events are written to the topic named <topic.prefix> .transaction . Change data event enrichment When transaction metadata is enabled, the data message Envelope is enriched with a new transaction field. This field provides information about every event in the form of a composite of fields: id String representation of unique transaction identifier. total_order The absolute position of the event among all events generated by the transaction. data_collection_order The per-data collection position of the event among all events that were emitted by the transaction. Following is an example of what a message looks like: { "after": "{\"_id\" : {\"USDnumberLong\" : \"1004\"},\"first_name\" : \"Anne\",\"last_name\" : \"Kretchmar\",\"email\" : \"annek@noanswer.org\"}", "source": { ... }, "op": "c", "ts_ms": "1580390884335", "ts_us": "1580390884335486", "ts_ns": "1580390884335486281", "transaction": { "id": "1462833718356672513", "total_order": "1", "data_collection_order": "1" } } 2.3.3. Descriptions of Debezium MongoDB connector data change events The Debezium MongoDB connector generates a data change event for each document-level operation that inserts, updates, or deletes data. Each event contains a key and a value. The structure of the key and the value depends on the collection that was changed. Debezium and Kafka Connect are designed around continuous streams of event messages . However, the structure of these events may change over time, which can be difficult for consumers to handle. To address this, each event contains the schema for its content or, if you are using a schema registry, a schema ID that a consumer can use to obtain the schema from the registry. This makes each event self-contained. The following skeleton JSON shows the basic four parts of a change event. However, how you configure the Kafka Connect converter that you choose to use in your application determines the representation of these four parts in change events. A schema field is in a change event only when you configure the converter to produce it. Likewise, the event key and event payload are in a change event only if you configure a converter to produce it. If you use the JSON converter and you configure it to produce all four basic change event parts, change events have this structure: { "schema": { 1 ... }, "payload": { 2 ... }, "schema": { 3 ... }, "payload": { 4 ... }, } Table 2.61. Overview of change event basic content Item Field name Description 1 schema The first schema field is part of the event key. It specifies a Kafka Connect schema that describes what is in the event key's payload portion. In other words, the first schema field describes the structure of the key for the document that was changed. 2 payload The first payload field is part of the event key. It has the structure described by the schema field and it contains the key for the document that was changed. 3 schema The second schema field is part of the event value. It specifies the Kafka Connect schema that describes what is in the event value's payload portion. In other words, the second schema describes the structure of the document that was changed. Typically, this schema contains nested schemas. 4 payload The second payload field is part of the event value. It has the structure described by the schema field and it contains the actual data for the document that was changed. By default, the connector streams change event records to topics with names that are the same as the event's originating collection. See topic names . Warning The MongoDB connector ensures that all Kafka Connect schema names adhere to the Avro schema name format . This means that the logical server name must start with a Latin letter or an underscore, that is, a-z, A-Z, or _. Each remaining character in the logical server name and each character in the database and collection names must be a Latin letter, a digit, or an underscore, that is, a-z, A-Z, 0-9, or \_. If there is an invalid character it is replaced with an underscore character. This can lead to unexpected conflicts if the logical server name, a database name, or a collection name contains invalid characters, and the only characters that distinguish names from one another are invalid and thus replaced with underscores. For more information, see the following topics: Section 2.3.3.1, "About keys in Debezium MongoDB change events" Section 2.3.3.2, "About values in Debezium MongoDB change events" 2.3.3.1. About keys in Debezium MongoDB change events A change event's key contains the schema for the changed document's key and the changed document's actual key. For a given collection, both the schema and its corresponding payload contain a single id field. The value of this field is the document's identifier represented as a string that is derived from MongoDB extended JSON serialization strict mode . Consider a connector with a logical name of fulfillment , a replica set containing an inventory database, and a customers collection that contains documents such as the following. Example document { "_id": 1004, "first_name": "Anne", "last_name": "Kretchmar", "email": "annek@noanswer.org" } Example change event key Every change event that captures a change to the customers collection has the same event key schema. For as long as the customers collection has the definition, every change event that captures a change to the customers collection has the following key structure. In JSON, it looks like this: { "schema": { 1 "type": "struct", "name": "fulfillment.inventory.customers.Key", 2 "optional": false, 3 "fields": [ 4 { "field": "id", "type": "string", "optional": false } ] }, "payload": { 5 "id": "1004" } } Table 2.62. Description of change event key Item Field name Description 1 schema The schema portion of the key specifies a Kafka Connect schema that describes what is in the key's payload portion. 2 fulfillment.inventory.customers.Key Name of the schema that defines the structure of the key's payload. This schema describes the structure of the key for the document that was changed. Key schema names have the format connector-name . database-name . collection-name . Key . In this example: fulfillment is the name of the connector that generated this event. inventory is the database that contains the collection that was changed. customers is the collection that contains the document that was updated. 3 optional Indicates whether the event key must contain a value in its payload field. In this example, a value in the key's payload is required. A value in the key's payload field is optional when a document does not have a key. 4 fields Specifies each field that is expected in the payload , including each field's name, type, and whether it is required. 5 payload Contains the key for the document for which this change event was generated. In this example, the key contains a single id field of type string whose value is 1004 . This example uses a document with an integer identifier, but any valid MongoDB document identifier works the same way, including a document identifier. For a document identifier, an event key's payload.id value is a string that represents the updated document's original _id field as a MongoDB extended JSON serialization that uses strict mode. The following table provides examples of how different types of _id fields are represented. Table 2.63. Examples of representing document _id fields in event key payloads Type MongoDB _id Value Key's payload Integer 1234 { "id" : "1234" } Float 12.34 { "id" : "12.34" } String "1234" { "id" : "\"1234\"" } Document { "hi" : "kafka", "nums" : [10.0, 100.0, 1000.0] } { "id" : "{\"hi\" : \"kafka\", \"nums\" : [10.0, 100.0, 1000.0]}" } ObjectId ObjectId("596e275826f08b2730779e1f") { "id" : "{\"USDoid\" : \"596e275826f08b2730779e1f\"}" } Binary BinData("a2Fma2E=",0) { "id" : "{\"USDbinary\" : \"a2Fma2E=\", \"USDtype\" : \"00\"}" } 2.3.3.2. About values in Debezium MongoDB change events The value in a change event is a bit more complicated than the key. Like the key, the value has a schema section and a payload section. The schema section contains the schema that describes the Envelope structure of the payload section, including its nested fields. Change events for operations that create, update or delete data all have a value payload with an envelope structure. Consider the same sample document that was used to show an example of a change event key: Example document { "_id": 1004, "first_name": "Anne", "last_name": "Kretchmar", "email": "annek@noanswer.org" } The value portion of a change event for a change to this document is described for each event type: create events update events delete events Tombstone events create events The following example shows the value portion of a change event that the connector generates for an operation that creates data in the customers collection: { "schema": { 1 "type": "struct", "fields": [ { "type": "string", "optional": true, "name": "io.debezium.data.Json", 2 "version": 1, "field": "after" }, { "type": "string", "optional": true, "name": "io.debezium.data.Json", "version": 1, "field": "patch" }, { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "version" }, { "type": "string", "optional": false, "field": "connector" }, { "type": "string", "optional": false, "field": "name" }, { "type": "int64", "optional": false, "field": "ts_ms" }, { "type": "int64", "optional": false, "field": "ts_us" }, { "type": "int64", "optional": false, "field": "ts_ns" }, { "type": "boolean", "optional": true, "default": false, "field": "snapshot" }, { "type": "string", "optional": false, "field": "db" }, { "type": "string", "optional": false, "field": "rs" }, { "type": "string", "optional": false, "field": "collection" }, { "type": "int32", "optional": false, "field": "ord" }, { "type": "int64", "optional": true, "field": "h" } ], "optional": false, "name": "io.debezium.connector.mongo.Source", 3 "field": "source" }, { "type": "string", "optional": true, "field": "op" }, { "type": "int64", "optional": true, "field": "ts_ms" }, { "type": "int64", "optional": true, "field": "ts_us" }, { "type": "int64", "optional": true, "field": "ts_ns" } ], "optional": false, "name": "dbserver1.inventory.customers.Envelope" 4 }, "payload": { 5 "after": "{\"_id\" : {\"USDnumberLong\" : \"1004\"},\"first_name\" : \"Anne\",\"last_name\" : \"Kretchmar\",\"email\" : \"annek@noanswer.org\"}", 6 "source": { 7 "version": "2.7.3.Final", "connector": "mongodb", "name": "fulfillment", "ts_ms": 1558965508000, "ts_ms": 1558965508000000, "ts_ms": 1558965508000000000, "snapshot": false, "db": "inventory", "rs": "rs0", "collection": "customers", "ord": 31, "h": 1546547425148721999 }, "op": "c", 8 "ts_ms": 1558965515240, 9 "ts_us": 1558965515240142, 10 "ts_ns": 1558965515240142879, 11 } } Table 2.64. Descriptions of create event value fields Item Field name Description 1 schema The value's schema, which describes the structure of the value's payload. A change event's value schema is the same in every change event that the connector generates for a particular collection. 2 name In the schema section, each name field specifies the schema for a field in the value's payload. io.debezium.data.Json is the schema for the payload's after , patch , and filter fields. This schema is specific to the customers collection. A create event is the only kind of event that contains an after field. An update event contains a filter field and a patch field. A delete event contains a filter field, but not an after field nor a patch field. 3 name io.debezium.connector.mongo.Source is the schema for the payload's source field. This schema is specific to the MongoDB connector. The connector uses it for all events that it generates. 4 name dbserver1.inventory.customers.Envelope is the schema for the overall structure of the payload, where dbserver1 is the connector name, inventory is the database, and customers is the collection. This schema is specific to the collection. 5 payload The value's actual data. This is the information that the change event is providing. It may appear that the JSON representations of the events are much larger than the documents they describe. This is because the JSON representation must include the schema and the payload portions of the message. However, by using the Avro converter , you can significantly decrease the size of the messages that the connector streams to Kafka topics. 6 after An optional field that specifies the state of the document after the event occurred. In this example, the after field contains the values of the new document's _id , first_name , last_name , and email fields. The after value is always a string. By convention, it contains a JSON representation of the document. MongoDB oplog entries contain the full state of a document only for _create_ events and also for update events, when the capture.mode option is set to change_streams_update_full ; in other words, a create event is the only kind of event that contains an after field regardless of capture.mode option. 7 source Mandatory field that describes the source metadata for the event. This field contains information that you can use to compare this event with other events, with regard to the origin of the events, the order in which the events occurred, and whether events were part of the same transaction. The source metadata includes: Debezium version. Name of the connector that generated the event. Logical name of the MongoDB replica set, which forms a namespace for generated events and is used in Kafka topic names to which the connector writes. Names of the collection and database that contain the new document. If the event was part of a snapshot. Timestamp for when the change was made in the database and ordinal of the event within the timestamp. Unique identifier of the MongoDB operation (the h field in the oplog event). Unique identifiers of the MongoDB session lsid and transaction number txnNumber in case the change was executed inside a transaction (change streams capture mode only). 8 op Mandatory string that describes the type of operation that caused the connector to generate the event. In this example, c indicates that the operation created a document. Valid values are: c = create u = update d = delete r = read (applies to only snapshots) 9 ts_ms Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. 10 ts_us Optional field that displays the time at which the connector processed the event, in microseconds. The time is based on the system clock in the JVM running the Kafka Connect task. 9 ts_ns Optional field that displays the time at which the connector processed the event, in nanoseconds. The time is based on the system clock in the JVM running the Kafka Connect task. Change streams capture mode The value of a change event for an update in the sample customers collection has the same schema as a create event for that collection. Likewise, the event value's payload has the same structure. However, the event value payload contains different values in an update event. An update event includes an after value only if the capture.mode option is set to change_streams_update_full . A before value is provided if the capture.mode option is set to one of the *_with_pre_image option. There is a new structured field updateDescription with a few additional fields in this case: updatedFields is a string field that contains the JSON representation of the updated document fields with their values removedFields is a list of field names that were removed from the document truncatedArrays is a list of arrays in the document that were truncated Here is an example of a change event value in an event that the connector generates for an update in the customers collection: { "schema": { ... }, "payload": { "op": "u", 1 "ts_ms": 1465491461815, 2 "ts_us": 1465491461815698, 3 "ts_ns": 1465491461815698142, 4 "before":"{\"_id\": {\"USDnumberLong\": \"1004\"},\"first_name\": \"unknown\",\"last_name\": \"Kretchmar\",\"email\": \"annek@noanswer.org\"}", 5 "after":"{\"_id\": {\"USDnumberLong\": \"1004\"},\"first_name\": \"Anne Marie\",\"last_name\": \"Kretchmar\",\"email\": \"annek@noanswer.org\"}", 6 "updateDescription": { "removedFields": null, "updatedFields": "{\"first_name\": \"Anne Marie\"}", 7 "truncatedArrays": null }, "source": { 8 "version": "2.7.3.Final", "connector": "mongodb", "name": "fulfillment", "ts_ms": 1558965508000, "ts_us": 1558965508000000, "ts_ns": 1558965508000000000, "snapshot": false, "db": "inventory", "rs": "rs0", "collection": "customers", "ord": 1, "h": null, "tord": null, "stxnid": null, "lsid":"{\"id\": {\"USDbinary\": \"FA7YEzXgQXSX9OxmzllH2w==\",\"USDtype\": \"04\"},\"uid\": {\"USDbinary\": \"47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=\",\"USDtype\": \"00\"}}", "txnNumber":1 } } } Table 2.65. Descriptions of update event value fields Item Field name Description 1 op Mandatory string that describes the type of operation that caused the connector to generate the event. In this example, u indicates that the operation updated a document. 2 ts_ms , ts_us , ts_ns Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. 3 before Contains the JSON string representation of the actual MongoDB document before change. An update event value does not contain a before field if the capture mode is not set to one of the *_with_preimage options. 4 after Contains the JSON string representation of the actual MongoDB document. An update event value does not contain an after field if the capture mode is not set to change_streams_update_full 5 updatedFields Contains the JSON string representation of the updated field values of the document. In this example, the update changed the first_name field to a new value. 6 source Mandatory field that describes the source metadata for the event. This field contains the same information as a create event for the same collection, but the values are different since this event is from a different position in the oplog. The source metadata includes: Debezium version. Name of the connector that generated the event. Logical name of the MongoDB replica set, which forms a namespace for generated events and is used in Kafka topic names to which the connector writes. Names of the collection and database that contain the updated document. If the event was part of a snapshot. Timestamp for when the change was made in the database and ordinal of the event within the timestamp. Unique identifiers of the MongoDB session lsid and transaction number txnNumber in case the change was executed inside a transaction. Warning The after value in the event should be handled as the at-point-of-time value of the document. The value is not calculated dynamically but is obtained from the collection. It is thus possible if multiple updates are closely following one after the other, that all update updates events will contain the same after value which will be representing the last value stored in the document. If your application depends on gradual change evolution then you should rely on updateDescription only. delete events The value in a delete change event has the same schema portion as create and update events for the same collection. The payload portion in a delete event contains values that are different from create and update events for the same collection. In particular, a delete event contains neither an after value nor a updateDescription value. Here is an example of a delete event for a document in the customers collection: { "schema": { ... }, "payload": { "op": "d", 1 "ts_ms": 1465495462115, 2 "ts_us": 1465495462115748, 3 "ts_ns": 1465495462115748263, 4 "before":"{\"_id\": {\"USDnumberLong\": \"1004\"},\"first_name\": \"Anne Marie\",\"last_name\": \"Kretchmar\",\"email\": \"annek@noanswer.org\"}", 5 "source": { 6 "version": "2.7.3.Final", "connector": "mongodb", "name": "fulfillment", "ts_ms": 1558965508000, "ts_us": 1558965508000000, "ts_ns": 1558965508000000000, "snapshot": true, "db": "inventory", "rs": "rs0", "collection": "customers", "ord": 6, "h": 1546547425148721999 } } } Table 2.66. Descriptions of delete event value fields Item Field name Description 1 op Mandatory string that describes the type of operation. The op field value is d , signifying that this document was deleted. 2 ts_ms , ts_us . ts_ns Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. 3 before Contains the JSON string representation of the actual MongoDB document before change. An update event value does not contain a before field if the capture mode is not set to one of the *_with_preimage options. 4 source Mandatory field that describes the source metadata for the event. This field contains the same information as a create or update event for the same collection, but the values are different since this event is from a different position in the oplog. The source metadata includes: Debezium version. Name of the connector that generated the event. Logical name of the MongoDB replica set, which forms a namespace for generated events and is used in Kafka topic names to which the connector writes. Names of the collection and database that contained the deleted document. If the event was part of a snapshot. Timestamp for when the change was made in the database and ordinal of the event within the timestamp. Unique identifier of the MongoDB operation (the h field in the oplog event). Unique identifiers of the MongoDB session lsid and transaction number txnNumber in case the change was executed inside a transaction (change streams capture mode only). MongoDB connector events are designed to work with Kafka log compaction . Log compaction enables removal of some older messages as long as at least the most recent message for every key is kept. This lets Kafka reclaim storage space while ensuring that the topic contains a complete data set and can be used for reloading key-based state. Tombstone events All MongoDB connector events for a uniquely identified document have exactly the same key. When a document is deleted, the delete event value still works with log compaction because Kafka can remove all earlier messages that have that same key. However, for Kafka to remove all messages that have that key, the message value must be null . To make this possible, after Debezium's MongoDB connector emits a delete event, the connector emits a special tombstone event that has the same key but a null value. A tombstone event informs Kafka that all messages with that same key can be removed. 2.3.4. Setting up MongoDB to work with a Debezium connector The MongoDB connector uses MongoDB's change streams to capture the changes, so the connector works only with MongoDB replica sets or with sharded clusters where each shard is a separate replica set. See the MongoDB documentation for setting up a replica set or sharded cluster . Also, be sure to understand how to enable access control and authentication with replica sets. You must also have a MongoDB user that has the appropriate roles to read the admin database where the oplog can be read. Additionally, the user must also be able to read the config database in the configuration server of a sharded cluster and must have listDatabases privilege action. When change streams are used (the default) the user also must have cluster-wide privilege actions find and changeStream . When you intend to utilize pre-image and populate the before field, you need to first enable changeStreamPreAndPostImages for a collection using db.createCollection() , create , or collMod . Optimal Oplog Config The Debezium MongoDB connector reads change streams to obtain oplog data for a replica set. Because the oplog is a fixed-sized, capped collection, if it exceeds its maximum configured size, it begins to overwrite its oldest entries. If the connector is stopped for any reason, when it restarts, it attempts to resume streaming from the last oplog stream position. However, if last stream position was removed from the oplog, depending on the value specified in the connector's snapshot.mode property, the connector might fail to start, reporting an invalid resume token error . In the event of a failure, you must create a new connector to enable Debezium to continue capturing records from the database. For more information, see Connector fails after it is stopped for a long interval if snapshot.mode is set to initial . To ensure that the oplog retains the offset values that Debezium requires to resume streaming, you can use either of the following approaches: Increase the size of the oplog . Based on your typical workloads, set the oplog size to a value that is greater than the peak number of oplog entries per hour. Increase the minimum number of hours that an oplog entry is retained (MongoDB 4.4 and greater). This setting is time-based, such that entries in the last n hours are guaranteed to be available even if the oplog reaches its maximum configured size. Although this is generally the preferred option, for clusters with high workloads that are nearing capacity, specify the maximum oplog size. To help prevent failures that are related to missing oplog entries, it's important to track metrics that report replication behavior, and to optimize the oplog size to support Debezium. In particular, you should monitor the values of Oplog GB/Hour and Replication Oplog Window. If Debezium is offline for an interval that exceeds the value of the replication oplog window, and the primary oplog grows faster than Debezium can consume entries, a connector failure can result. For information about how to monitor these metrics, see the MongoDB documentation . It's best to set the maximum oplog size to a value that is based on the anticipated hourly growth of the oplog ( Oplog GB/Hour ), multiplied by the time that might be required to address a Debezium failure. That is, Oplog GB/Hour X average reaction time to Debezium failure For example, if the oplog size limit is set to 1GB, and the oplog grows by 3GB per hour, oplog entries are cleared three times per hour. If Debezium were to fail during this time, its last oplog position is likely to be removed. If the oplog grows at the rate of 3GB/hour, and Debezium is offline for two hours, you would thus set the oplog size to 3GB/hour X 2 hours, or 6GB. 2.3.5. Deployment of Debezium MongoDB connectors You can use either of the following methods to deploy a Debezium MongoDB connector: Use Streams for Apache Kafka to automatically create an image that includes the connector plug-in . This is the preferred method. Build a custom Kafka Connect container image from a Dockerfile . Additional resources Section 2.3.5.5, "Descriptions of Debezium MongoDB connector configuration properties" 2.3.5.1. MongoDB connector deployment using Streams for Apache Kafka Beginning with Debezium 1.7, the preferred method for deploying a Debezium connector is to use Streams for Apache Kafka to build a Kafka Connect container image that includes the connector plug-in. During the deployment process, you create and use the following custom resources (CRs): A KafkaConnect CR that defines your Kafka Connect instance and includes information about the connector artifacts needs to include in the image. A KafkaConnector CR that provides details that include information the connector uses to access the source database. After Streams for Apache Kafka starts the Kafka Connect pod, you start the connector by applying the KafkaConnector CR. In the build specification for the Kafka Connect image, you can specify the connectors that are available to deploy. For each connector plug-in, you can also specify other components that you want to make available for deployment. For example, you can add Apicurio Registry artifacts, or the Debezium scripting component. When Streams for Apache Kafka builds the Kafka Connect image, it downloads the specified artifacts, and incorporates them into the image. The spec.build.output parameter in the KafkaConnect CR specifies where to store the resulting Kafka Connect container image. Container images can be stored in a Docker registry, or in an OpenShift ImageStream. To store images in an ImageStream, you must create the ImageStream before you deploy Kafka Connect. ImageStreams are not created automatically. Note If you use a KafkaConnect resource to create a cluster, afterwards you cannot use the Kafka Connect REST API to create or update connectors. You can still use the REST API to retrieve information. Additional resources Configuring Kafka Connect in Deploying and Managing Streams for Apache Kafka on OpenShift. Building a new container image automatically in Deploying and Managing Streams for Apache Kafka on OpenShift. 2.3.5.2. Using Streams for Apache Kafka to deploy a Debezium MongoDB connector With earlier versions of Streams for Apache Kafka, to deploy Debezium connectors on OpenShift, you were required to first build a Kafka Connect image for the connector. The current preferred method for deploying connectors on OpenShift is to use a build configuration in Streams for Apache Kafka to automatically build a Kafka Connect container image that includes the Debezium connector plug-ins that you want to use. During the build process, the Streams for Apache Kafka Operator transforms input parameters in a KafkaConnect custom resource, including Debezium connector definitions, into a Kafka Connect container image. The build downloads the necessary artifacts from the Red Hat Maven repository or another configured HTTP server. The newly created container is pushed to the container registry that is specified in .spec.build.output , and is used to deploy a Kafka Connect cluster. After Streams for Apache Kafka builds the Kafka Connect image, you create KafkaConnector custom resources to start the connectors that are included in the build. Prerequisites You have access to an OpenShift cluster on which the cluster Operator is installed. The Streams for Apache Kafka Operator is running. An Apache Kafka cluster is deployed as documented in Deploying and Managing Streams for Apache Kafka on OpenShift . Kafka Connect is deployed on Streams for Apache Kafka You have a Red Hat build of Debezium license. The OpenShift oc CLI client is installed or you have access to the OpenShift Container Platform web console. Depending on how you intend to store the Kafka Connect build image, you need registry permissions or you must create an ImageStream resource: To store the build image in an image registry, such as Red Hat Quay.io or Docker Hub An account and permissions to create and manage images in the registry. To store the build image as a native OpenShift ImageStream An ImageStream resource is deployed to the cluster for storing new container images. You must explicitly create an ImageStream for the cluster. ImageStreams are not available by default. For more information about ImageStreams, see Managing image streams on OpenShift Container Platform . Procedure Log in to the OpenShift cluster. Create a Debezium KafkaConnect custom resource (CR) for the connector, or modify an existing one. For example, create a KafkaConnect CR with the name dbz-connect.yaml that specifies the metadata.annotations and spec.build properties. The following example shows an excerpt from a dbz-connect.yaml file that describes a KafkaConnect custom resource. Example 2.18. A dbz-connect.yaml file that defines a KafkaConnect custom resource that includes a Debezium connector In the example that follows, the custom resource is configured to download the following artifacts: The Debezium MongoDB connector archive. The Red Hat build of Apicurio Registry archive. The Apicurio Registry is an optional component. Add the Apicurio Registry component only if you intend to use Avro serialization with the connector. The Debezium scripting SMT archive and the associated scripting engine that you want to use with the Debezium connector. The SMT archive and scripting language dependencies are optional components. Add these components only if you intend to use the Debezium content-based routing SMT or filter SMT . apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: debezium-kafka-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: version: 3.6.0 build: 2 output: 3 type: imagestream 4 image: debezium-streams-connect:latest plugins: 5 - name: debezium-connector-mongodb artifacts: - type: zip 6 url: https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-mongodb/2.7.3.Final-redhat-00001/debezium-connector-mongodb-2.7.3.Final-redhat-00001-plugin.zip 7 - type: zip url: https://maven.repository.redhat.com/ga/io/apicurio/apicurio-registry-distro-connect-converter/2.4.4.Final-redhat- <build-number> /apicurio-registry-distro-connect-converter-2.4.4.Final-redhat- <build-number> .zip 8 - type: zip url: https://maven.repository.redhat.com/ga/io/debezium/debezium-scripting/2.7.3.Final-redhat-00001/debezium-scripting-2.7.3.Final-redhat-00001.zip 9 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy/3.0.11/groovy-3.0.11.jar 10 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-jsr223/3.0.11/groovy-jsr223-3.0.11.jar - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-json3.0.11/groovy-json-3.0.11.jar bootstrapServers: debezium-kafka-cluster-kafka-bootstrap:9093 ... Table 2.67. Descriptions of Kafka Connect configuration settings Item Description 1 Sets the strimzi.io/use-connector-resources annotation to "true" to enable the Cluster Operator to use KafkaConnector resources to configure connectors in this Kafka Connect cluster. 2 The spec.build configuration specifies where to store the build image and lists the plug-ins to include in the image, along with the location of the plug-in artifacts. 3 The build.output specifies the registry in which the newly built image is stored. 4 Specifies the name and image name for the image output. Valid values for output.type are docker to push into a container registry such as Docker Hub or Quay, or imagestream to push the image to an internal OpenShift ImageStream. To use an ImageStream, an ImageStream resource must be deployed to the cluster. For more information about specifying the build.output in the KafkaConnect configuration, see the Streams for Apache Kafka Build schema reference in {NameConfiguringStreamsOpenShift}. 5 The plugins configuration lists all of the connectors that you want to include in the Kafka Connect image. For each entry in the list, specify a plug-in name , and information for about the artifacts that are required to build the connector. Optionally, for each connector plug-in, you can include other components that you want to be available for use with the connector. For example, you can add Service Registry artifacts, or the Debezium scripting component. 6 The value of artifacts.type specifies the file type of the artifact specified in the artifacts.url . Valid types are zip , tgz , or jar . Debezium connector archives are provided in .zip file format. The type value must match the type of the file that is referenced in the url field. 7 The value of artifacts.url specifies the address of an HTTP server, such as a Maven repository, that stores the file for the connector artifact. Debezium connector artifacts are available in the Red Hat Maven repository. The OpenShift cluster must have access to the specified server. 8 (Optional) Specifies the artifact type and url for downloading the Apicurio Registry component. Include the Apicurio Registry artifact, only if you want the connector to use Apache Avro to serialize event keys and values with the Red Hat build of Apicurio Registry, instead of using the default JSON converter. 9 (Optional) Specifies the artifact type and url for the Debezium scripting SMT archive to use with the Debezium connector. Include the scripting SMT only if you intend to use the Debezium content-based routing SMT or filter SMT To use the scripting SMT, you must also deploy a JSR 223-compliant scripting implementation, such as groovy. 10 (Optional) Specifies the artifact type and url for the JAR files of a JSR 223-compliant scripting implementation, which is required by the Debezium scripting SMT. Important If you use Streams for Apache Kafka to incorporate the connector plug-in into your Kafka Connect image, for each of the required scripting language components artifacts.url must specify the location of a JAR file, and the value of artifacts.type must also be set to jar . Invalid values cause the connector fails at runtime. To enable use of the Apache Groovy language with the scripting SMT, the custom resource in the example retrieves JAR files for the following libraries: groovy groovy-jsr223 (scripting agent) groovy-json (module for parsing JSON strings) As an alternative, the Debezium scripting SMT also supports the use of the JSR 223 implementation of GraalVM JavaScript. Apply the KafkaConnect build specification to the OpenShift cluster by entering the following command: oc create -f dbz-connect.yaml Based on the configuration specified in the custom resource, the Streams Operator prepares a Kafka Connect image to deploy. After the build completes, the Operator pushes the image to the specified registry or ImageStream, and starts the Kafka Connect cluster. The connector artifacts that you listed in the configuration are available in the cluster. Create a KafkaConnector resource to define an instance of each connector that you want to deploy. For example, create the following KafkaConnector CR, and save it as mongodb-inventory-connector.yaml Example 2.19. mongodb-inventory-connector.yaml file that defines the KafkaConnector custom resource for a Debezium connector apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: labels: strimzi.io/cluster: debezium-kafka-connect-cluster name: inventory-connector-mongodb 1 spec: class: io.debezium.connector.mongodb.MongoDbConnector 2 tasksMax: 1 3 config: 4 mongodb.hosts: rs0/192.168.99.100:27017 5 mongodb.user: debezium 6 mongodb.password: dbz 7 topic.prefix: inventory-connector-mongodb 8 collection.include.list: inventory[.]* 9 Table 2.68. Descriptions of connector configuration settings Item Description 1 The name of the connector to register with the Kafka Connect cluster. 2 The name of the connector class. 3 The number of tasks that can operate concurrently. 4 The connector's configuration. 5 The address and port number of the host database instance. 7 The name of the account that Debezium uses to connect to the database. 8 The password that Debezium uses to connect to the database user account. 8 The topic prefix for the database instance or cluster. The specified name must be formed only from alphanumeric characters or underscores. Because the topic prefix is used as the prefix for any Kafka topics that receive change events from this connector, the name must be unique among the connectors in the cluster. This namespace is also used in the names of related Kafka Connect schemas, and the namespaces of a corresponding Avro schema if you integrate the connector with the Avro connector . 9 The names of the collections that the connector captures changes from. Create the connector resource by running the following command: oc create -n <namespace> -f <kafkaConnector> .yaml For example, oc create -n debezium -f mongodb-inventory-connector.yaml The connector is registered to the Kafka Connect cluster and starts to run against the database that is specified by spec.config.database.dbname in the KafkaConnector CR. After the connector pod is ready, Debezium is running. You are now ready to verify the Debezium MongoDB deployment . 2.3.5.3. Deploying a Debezium MongoDB connector by building a custom Kafka Connect container image from a Dockerfile To deploy a Debezium MongoDB connector, you must build a custom Kafka Connect container image that contains the Debezium connector archive and then push this container image to a container registry. You then create two custom resources (CRs): A KafkaConnect CR that defines your Kafka Connect instance. The image property in the CR specifies the name of the container image that you create to run your Debezium connector. You apply this CR to the OpenShift instance where Red Hat Streams for Apache Kafka is deployed. Streams for Apache Kafka offers operators and images that bring Apache Kafka to OpenShift. A KafkaConnector CR that defines your Debezium MongoDB connector. Apply this CR to the same OpenShift instance where you apply the KafkaConnect CR. Prerequisites MongoDB is running and you completed the steps to set up MongoDB to work with a Debezium connector . Streams for Apache Kafka is deployed on OpenShift and is running Apache Kafka and Kafka Connect. For more information, see Deploying and Managing Streams for Apache Kafka on OpenShift . Podman or Docker is installed. You have an account and permissions to create and manage containers in the container registry (such as quay.io or docker.io ) to which you plan to add the container that will run your Debezium connector. Procedure Create the Debezium MongoDB container for Kafka Connect: Create a Dockerfile that uses registry.redhat.io/amq-streams-kafka-35-rhel8:2.5.0 as the base image. For example, from a terminal window, enter the following command: cat <<EOF >debezium-container-for-mongodb.yaml 1 FROM registry.redhat.io/amq-streams-kafka-35-rhel8:2.5.0 USER root:root RUN mkdir -p /opt/kafka/plugins/debezium 2 RUN cd /opt/kafka/plugins/debezium/ \ && curl -O https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-mongodb/2.7.3.Final-redhat-00001/debezium-connector-mongodb-2.7.3.Final-redhat-00001-plugin.zip \ && unzip debezium-connector-mongodb-2.7.3.Final-redhat-00001-plugin.zip \ && rm debezium-connector-mongodb-2.7.3.Final-redhat-00001-plugin.zip RUN cd /opt/kafka/plugins/debezium/ USER 1001 EOF Item Description 1 You can specify any file name that you want. 2 Specifies the path to your Kafka Connect plug-ins directory. If your Kafka Connect plug-ins directory is in a different location, replace this path with the actual path of your directory. The command creates a Dockerfile with the name debezium-container-for-mongodb.yaml in the current directory. Build the container image from the debezium-container-for-mongodb.yaml Docker file that you created in the step. From the directory that contains the file, open a terminal window and enter one of the following commands: podman build -t debezium-container-for-mongodb:latest . docker build -t debezium-container-for-mongodb:latest . The preceding commands build a container image with the name debezium-container-for-mongodb . Push your custom image to a container registry, such as quay.io or an internal container registry. The container registry must be available to the OpenShift instance where you want to deploy the image. Enter one of the following commands: podman push <myregistry.io> /debezium-container-for-mongodb:latest docker push <myregistry.io> /debezium-container-for-mongodb:latest Create a new Debezium MongoDB KafkaConnect custom resource (CR). For example, create a KafkaConnect CR with the name dbz-connect.yaml that specifies annotations and image properties. The following example shows an excerpt from a dbz-connect.yaml file that describes a KafkaConnect custom resource. apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: #... image: debezium-container-for-mongodb 2 ... Item Description 1 metadata.annotations indicates to the Cluster Operator that KafkaConnector resources are used to configure connectors in this Kafka Connect cluster. 2 spec.image specifies the name of the image that you created to run your Debezium connector. This property overrides the STRIMZI_DEFAULT_KAFKA_CONNECT_IMAGE variable in the Cluster Operator. Apply the KafkaConnect CR to the OpenShift Kafka Connect environment by entering the following command: oc create -f dbz-connect.yaml The command adds a Kafka Connect instance that specifies the name of the image that you created to run your Debezium connector. Create a KafkaConnector custom resource that configures your Debezium MongoDB connector instance. You configure a Debezium MongoDB connector in a .yaml file that specifies the configuration properties for the connector. The connector configuration might instruct Debezium to produce change events for a subset of MongoDB replica sets or sharded clusters. Optionally, you can set properties that filter out collections that are not needed. The following example configures a Debezium connector that connects to a MongoDB replica set rs0 at port 27017 on 192.168.99.100 , and captures changes that occur in the inventory collection. inventory-connector-mongodb is the logical name of the replica set. MongoDB inventory-connector.yaml apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: inventory-connector-mongodb 1 labels: strimzi.io/cluster: my-connect-cluster spec: class: io.debezium.connector.mongodb.MongoDbConnector 2 config: mongodb.connection.string: mongodb://192.168.99.100:27017/?replicaSet=rs0 3 topic.prefix: inventory-connector-mongodb 4 collection.include.list: inventory[.]* 5 Table 2.69. Descriptions of settings in the MongoDB inventory-connector.yaml example Item Description 1 The name that is used to register the connector with Kafka Connect. 2 The name of the MongoDB connector class. 3 The host addresses to use to connect to the MongoDB replica set. 4 The logical name of the MongoDB replica set. The logical name forms a namespace for generated events, and is used in the names of the Kafka topics to which the connector writes, the Kafka Connect schema names, and the namespaces of the corresponding Avro schema when the Avro converter is used. 5 An optional list of regular expressions that match the collection namespaces (for example, <dbName>.<collectionName> ) of all collections to be monitored. Create your connector instance with Kafka Connect. For example, if you saved your KafkaConnector resource in the inventory-connector.yaml file, you would run the following command: oc apply -f inventory-connector.yaml The preceding command registers inventory-connector and the connector starts to run against the inventory collection as defined in the KafkaConnector CR. For the complete list of the configuration properties that you can set for the Debezium MongoDB connector, see MongoDB connector configuration properties . Results After the connector starts, it completes the following actions: Performs a consistent snapshot of the collections in your MongoDB replica sets. Reads the change streams for the replica sets. Produces change events for every inserted, updated, and deleted document. Streams change event records to Kafka topics. 2.3.5.4. Verifying that the Debezium MongoDB connector is running If the connector starts correctly without errors, it creates a topic for each table that the connector is configured to capture. Downstream applications can subscribe to these topics to retrieve information events that occur in the source database. To verify that the connector is running, you perform the following operations from the OpenShift Container Platform web console, or through the OpenShift CLI tool (oc): Verify the connector status. Verify that the connector generates topics. Verify that topics are populated with events for read operations ("op":"r") that the connector generates during the initial snapshot of each table. Prerequisites A Debezium connector is deployed to Streams for Apache Kafka on OpenShift. The OpenShift oc CLI client is installed. You have access to the OpenShift Container Platform web console. Procedure Check the status of the KafkaConnector resource by using one of the following methods: From the OpenShift Container Platform web console: Navigate to Home Search . On the Search page, click Resources to open the Select Resource box, and then type KafkaConnector . From the KafkaConnectors list, click the name of the connector that you want to check, for example inventory-connector-mongodb . In the Conditions section, verify that the values in the Type and Status columns are set to Ready and True . From a terminal window: Enter the following command: oc describe KafkaConnector <connector-name> -n <project> For example, oc describe KafkaConnector inventory-connector-mongodb -n debezium The command returns status information that is similar to the following output: Example 2.20. KafkaConnector resource status Name: inventory-connector-mongodb Namespace: debezium Labels: strimzi.io/cluster=debezium-kafka-connect-cluster Annotations: <none> API Version: kafka.strimzi.io/v1beta2 Kind: KafkaConnector ... Status: Conditions: Last Transition Time: 2021-12-08T17:41:34.897153Z Status: True Type: Ready Connector Status: Connector: State: RUNNING worker_id: 10.131.1.124:8083 Name: inventory-connector-mongodb Tasks: Id: 0 State: RUNNING worker_id: 10.131.1.124:8083 Type: source Observed Generation: 1 Tasks Max: 1 Topics: inventory-connector-mongodb.inventory inventory-connector-mongodb.inventory.addresses inventory-connector-mongodb.inventory.customers inventory-connector-mongodb.inventory.geom inventory-connector-mongodb.inventory.orders inventory-connector-mongodb.inventory.products inventory-connector-mongodb.inventory.products_on_hand Events: <none> Verify that the connector created Kafka topics: From the OpenShift Container Platform web console. Navigate to Home Search . On the Search page, click Resources to open the Select Resource box, and then type KafkaTopic . From the KafkaTopics list, click the name of the topic that you want to check, for example, inventory-connector-mongodb.inventory.orders---ac5e98ac6a5d91e04d8ec0dc9078a1ece439081d . In the Conditions section, verify that the values in the Type and Status columns are set to Ready and True . From a terminal window: Enter the following command: oc get kafkatopics The command returns status information that is similar to the following output: Example 2.21. KafkaTopic resource status Check topic content. From a terminal window, enter the following command: oc exec -n <project> -it <kafka-cluster> -- /opt/kafka/bin/kafka-console-consumer.sh \ > --bootstrap-server localhost:9092 \ > --from-beginning \ > --property print.key=true \ > --topic= <topic-name > For example, oc exec -n debezium -it debezium-kafka-cluster-kafka-0 -- /opt/kafka/bin/kafka-console-consumer.sh \ > --bootstrap-server localhost:9092 \ > --from-beginning \ > --property print.key=true \ > --topic=inventory-connector-mongodb.inventory.products_on_hand The format for specifying the topic name is the same as the oc describe command returns in Step 1, for example, inventory-connector-mongodb.inventory.addresses . For each event in the topic, the command returns information that is similar to the following output: Example 2.22. Content of a Debezium change event In the preceding example, the payload value shows that the connector snapshot generated a read ( "op" ="r" ) event from the table inventory.products_on_hand . The "before" state of the product_id record is null , indicating that no value exists for the record. The "after" state shows a quantity of 3 for the item with product_id 101 . 2.3.5.5. Descriptions of Debezium MongoDB connector configuration properties The Debezium MongoDB connector has numerous configuration properties that you can use to achieve the right connector behavior for your application. Many properties have default values. Information about the properties is organized as follows: Required Debezium MongoDB connector configuration properties Advanced Debezium MongoDB connector configuration properties Pass-through Kafka signals configuration properties Pass-through sink notification configuration properties The following configuration properties are required unless a default value is available. Table 2.70. Required Debezium MongoDB connector configuration properties Property Default Description internal.mongodb.allow.offset.invalidation false Set this property to true to enable the connector to invalidate and consolidate shard-specific offsets that were recorded by earlier connector versions. Warning This property permits you to modify the current default behavior. The property is subject to removal in a future release if the default behavior changes to permit the connector to automatically invalidate and consolidate offsets that are recorded by earlier connector versions. name No default Unique name for the connector. Attempting to register again with the same name will fail. (This property is required by all Kafka Connect connectors.) connector.class No default The name of the Java class for the connector. Always use a value of io.debezium.connector.mongodb.MongoDbConnector for the MongoDB connector. mongodb.connection.string No default Specifies a connection string that the connector uses to connect to a MongoDB replica set. This property replaces the mongodb.hosts property that was available in versions of the MongoDB connector. topic.prefix No default A unique name that identifies the connector and/or MongoDB replica set or sharded cluster that this connector monitors. Each server should be monitored by at most one Debezium connector, since this server name prefixes all persisted Kafka topics emanating from the MongoDB replica set or cluster. Use only alphanumeric characters, hyphens, dots and underscores to form the name. The logical name should be unique across all other connectors, because the name is used as the prefix in naming the Kafka topics that receive records from this connector. Warning Do not change the value of this property. If you change the name value, after a restart, instead of continuing to emit events to the original topics, the connector emits subsequent events to topics whose names are based on the new value. mongodb.authentication.class DefaultMongoDbAuthProvider A full Java class name that is an implementation of the io.debezium.connector.mongodb.connection.MongoDbAuthProvider interface. This class handles setting the credentials on the MongoDB connection (called on each app boot). Default behavior uses the mongodb.user , mongodb.password , and mongodb.authsource properties according to each of their documentation, but other implementations may use them differently or ignore them altogether. Note that any setting in mongodb.connection.string will override settings set by this class mongodb.user No default When using default mongodb.authentication.class : Name of the database user to be used when connecting to MongoDB. This is required only when MongoDB is configured to use authentication. mongodb.password No default When using default mongodb.authentication.class : Password to be used when connecting to MongoDB. This is required only when MongoDB is configured to use authentication. mongodb.authsource admin When using default mongodb.authentication.class : Database (authentication source) containing MongoDB credentials. This is required only when MongoDB is configured to use authentication with another authentication database than admin . mongodb.ssl.enabled false Connector will use SSL to connect to MongoDB instances. mongodb.ssl.invalid.hostname.allowed false When SSL is enabled this setting controls whether strict hostname checking is disabled during connection phase. If true the connection will not prevent man-in-the-middle attacks. filters.match.mode regex The mode used to match events based on included/excluded database and collection names. Set the property to one of the following values: regex Database and collection includes/excludes are evaluated as comma-separated list of regular expressions. literal Database and collection includes/excludes are evaluated as comma-separated list of string literals. Whitespace characters surrounding these literals are stripped. database.include.list empty string An optional comma-separated list of regular expressions or literals that match database names to be monitored. By default, all databases are monitored. When database.include.list is set, the connector monitors only the databases that the property specifies. Other databases are excluded from monitoring. To match the name of a database, Debezium performs one of the following actions based on the value of filters.match.mode property applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the database; it does not match substrings that might be present in a database name. compares the literals that you specify with the entire name string of the database If you include this property in the configuration, do not also set the database.exclude.list property. database.exclude.list empty string An optional comma-separated list of regular expressions or literals that match database names to be excluded from monitoring. When database.exclude.list is set, the connector monitors every database except the ones that the property specifies. To match the name of a database, Debezium performs one of the following actions based on the value of filters.match.mode property applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the database; it does not match substrings that might be present in a database name. compares the literals that you specify with the entire name string of the database If you include this property in the configuration, do not set the database.include.list property. collection.include.list empty string An optional comma-separated list of regular expressions or literals that match fully-qualified namespaces for MongoDB collections to be monitored. By default, the connector monitors all collections except those in the local and admin databases. When collection.include.list is set, the connector monitors only the collections that the property specifies. Other collections are excluded from monitoring. Collection identifiers are of the form databaseName . collectionName . To match the name of a namespace, Debezium performs one of the following actions based on the value of filters.match.mode property applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the namespace; it does not match substrings in the name. compares the literals that you specify with the entire name string of the namespace If you include this property in the configuration, do not also set the collection.exclude.list property. collection.exclude.list empty string An optional comma-separated list of regular expressions or literals that match fully-qualified namespaces for MongoDB collections to be excluded from monitoring. When collection.exclude.list is set, the connector monitors every collection except the ones that the property specifies. Collection identifiers are of the form databaseName . collectionName . To match the name of a namespace, Debezium performs one of the following actions based on the value of filters.match.mode property applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the namespace; it does not match substrings that might be present in a database name. compares the literals that you specify with the entire name string of the namespace If you include this property in the configuration, do not set the collection.include.list property. capture.mode change_streams_update_full Specifies the method that the connector uses to capture update event changes from a MongoDB server. Set this property to one of the following values: change_streams update event messages do not include the full document. Messages do not include a field that represents the state of the document before the change. change_streams_update_full update event messages include the full document. Messages do not include a before field that represents the state of the document before the update. The event message returns the full state of the document in the after field. Set capture.mode.full.update.type to specify how the connector fetches full documents from the database. Note In some situations, when capture.mode is configured to return full documents, the updateDescription and after fields of the update event message might report inconsistent values. Such discrepancies can result after multiple updates are applied to a document in rapid succession. The connector requests the full document from the MongoDB database only after it receives the update described in the event's updateDescription field. If a later update modifies the source document before the connector can retrieve it from the database, the connector receives the document that is modified by this later update. change_streams_update_full_with_pre_image update event event messages include the full document, and include a field that represents the state of the document before the change. Set capture.mode.full.update.type to specify how the connector fetches full documents from the database. change_streams_with_pre_image update events do not include the full document, but include a field that represents the state of the document before the change. capture.scope deployment Specifies the scope of the change streams that the connector opens. Set this property to one of the following values: deployment Opens a change stream cursor for a deployment (either a replica set or a sharded cluster) to watch for changes to all non-system collections across all databases, except for admin , local , and config . database Opens a change stream cursor for a single database to watch for changes to all of its non-system collections. Warning To support Debezium signaling , if you set capture.scope to database , the signaling data collection must reside in a database that is specified by the capture.target property. collection Opens a change stream cursor for a single collection to watch for changes to that collection. Important The use of the Debezium collection option for the capture.scope property is a Developer Preview feature. Developer Preview features are not supported by Red Hat in any way and are not functionally complete or production-ready. Do not use Developer Preview software for production or business-critical workloads. Developer Preview software provides early access to upcoming product software in advance of its possible inclusion in a Red Hat product offering. Customers can use this software to test functionality and provide feedback during the development process. Red Hat might provide ways to submit feedback on Developer Preview software without an associated SLA. For more information about the support scope of Red Hat Developer Preview software, see Developer Preview Support Scope . Warning Setting the value of the capture.scope property to collection prevents the connector from using the default source signaling channel. Because the source channel must be enabled to permit connectors to process incremental snapshot signals - even for signals are sent over the Kafka, JMX, or File channels - the connector cannot perform incremental snapshots when capture-scope is set to collection . capture.target Specifies the database that the connector monitors for changes. This property applies only if the capture.scope is set to database . field.exclude.list empty string An optional comma-separated list of the fully-qualified names of fields that should be excluded from change event message values. Fully-qualified names for fields are of the form databaseName . collectionName . fieldName . nestedFieldName , where databaseName and collectionName may contain the wildcard (*) which matches any characters. field.renames empty string An optional comma-separated list of the fully-qualified replacements of fields that should be used to rename fields in change event message values. Fully-qualified replacements for fields are of the form databaseName . collectionName . fieldName . nestedFieldName : newNestedFieldName , where databaseName and collectionName may contain the wildcard (*) which matches any characters, the colon character (:) is used to determine rename mapping of field. The field replacement is applied to the result of the field replacement in the list, so keep this in mind when renaming multiple fields that are in the same path. tombstones.on.delete true Controls whether a delete event is followed by a tombstone event. true - a delete operation is represented by a delete event and a subsequent tombstone event. false - only a delete event is emitted. After a source record is deleted, emitting a tombstone event (the default behavior) allows Kafka to completely delete all events that pertain to the key of the deleted row in case log compaction is enabled for the topic. schema.name.adjustment.mode none Specifies how schema names should be adjusted for compatibility with the message converter used by the connector. Possible settings: none does not apply any adjustment. avro replaces the characters that cannot be used in the Avro type name with underscore. avro_unicode replaces the underscore or characters that cannot be used in the Avro type name with corresponding unicode like _uxxxx. Note: _ is an escape sequence like backslash in Java field.name.adjustment.mode none Specifies how field names should be adjusted for compatibility with the message converter used by the connector. Possible settings: none does not apply any adjustment. avro replaces the characters that cannot be used in the Avro type name with underscore. avro_unicode replaces the underscore or characters that cannot be used in the Avro type name with corresponding unicode like _uxxxx. Note: _ is an escape sequence like backslash in Java See Avro naming for more details. The following advanced configuration properties have good defaults that will work in most situations and therefore rarely need to be specified in the connector's configuration. Table 2.71. Debezium MongoDB connector advanced configuration properties Property Default Description capture.mode.full.update.type lookup Specifies how the connector looks up the full value of an updated document when the capture.mode is set retrieve full documents. The connector retrieves full documents when its capture.mode is set to one of the following options: change_streams_update_full change_streams_update_full_with_pre-image To use this option with a MongoDB change streams collection, you must configure the collection to return document pre- and post-images . Pre- and post-images for an operation are available only if the required configuration is in place before the operation occurs. Set this property to one of the following values: lookup The connector uses a separate lookup to fetch the updated full MongoDB document. Warning If the lookup process fails to retrieve a document, it cannot populate the full document to the after state in the event payload. In such a situation, the connector emits an event message that contains a null value in the after field. Failed lookups can occur because a delete operation removed the document immediately after it was created, or because a change to the sharding key results in the document being moved to a different location. Sharding key changes can result when you modify any of the properties that make up the key. post_image The connector uses MongoDB post images to populate events with the full MongoDB document. The database must be running MongoDB 6.0 or later to use this option. max.batch.size 2048 Positive integer value that specifies the maximum size of each batch of events that should be processed during each iteration of this connector. Defaults to 2048. max.queue.size 8192 Positive integer value that specifies the maximum number of records that the blocking queue can hold. When Debezium reads events streamed from the database, it places the events in the blocking queue before it writes them to Kafka. The blocking queue can provide backpressure for reading change events from the database in cases where the connector ingests messages faster than it can write them to Kafka, or when Kafka becomes unavailable. Events that are held in the queue are disregarded when the connector periodically records offsets. Always set the value of max.queue.size to be larger than the value of max.batch.size . max.queue.size.in.bytes 0 A long integer value that specifies the maximum volume of the blocking queue in bytes. By default, volume limits are not specified for the blocking queue. To specify the number of bytes that the queue can consume, set this property to a positive long value. If max.queue.size is also set, writing to the queue is blocked when the size of the queue reaches the limit specified by either property. For example, if you set max.queue.size=1000 , and max.queue.size.in.bytes=5000 , writing to the queue is blocked after the queue contains 1000 records, or after the volume of the records in the queue reaches 5000 bytes. poll.interval.ms 1000 Positive integer value that specifies the number of milliseconds the connector should wait during each iteration for new change events to appear. Defaults to 500 milliseconds, or 0.5 second. connect.backoff.initial.delay.ms 1000 Positive integer value that specifies the initial delay when trying to reconnect to a primary after the first failed connection attempt or when no primary is available. Defaults to 1 second (1000 ms). connect.backoff.max.delay.ms 1000 Positive integer value that specifies the maximum delay when trying to reconnect to a primary after repeated failed connection attempts or when no primary is available. Defaults to 120 seconds (120,000 ms). connect.max.attempts 16 Positive integer value that specifies the maximum number of failed connection attempts to a replica set primary before an exception occurs and task is aborted. Defaults to 16, which with the defaults for connect.backoff.initial.delay.ms and connect.backoff.max.delay.ms results in just over 20 minutes of attempts before failing. heartbeat.interval.ms 0 Controls how frequently heartbeat messages are sent. This property contains an interval in milliseconds that defines how frequently the connector sends messages into a heartbeat topic. This can be used to monitor whether the connector is still receiving change events from the database. You also should leverage heartbeat messages in cases where only records in non-captured collections are changed for a longer period of time. In such situation the connector would proceed to read the oplog/change stream from the database but never emit any change messages into Kafka, which in turn means that no offset updates are committed to Kafka. This will cause the oplog files to be rotated out but connector will not notice it so on restart some events are no longer available which leads to the need of re-execution of the initial snapshot. Set this parameter to 0 to not send heartbeat messages at all. Disabled by default. skipped.operations t A comma-separated list of operation types that will be skipped during streaming. The operations include: c for inserts/create, u for updates/replace, d for deletes, t for truncates, and none to not skip any aforementioned operations. By default, for consistency with other Debezium connectors, truncate operations are skipped (not emitted by this connector). However, since MongoDB does not support truncate change events, this is effectively the same as specifying none . snapshot.collection.filter.overrides No default Controls which collection items are included in snapshot. This property affects snapshots only. Specify a comma-separated list of collection names in the form databaseName.collectionName . For each collection that you specify, also specify another configuration property: snapshot.collection.filter.overrides. databaseName . collectionName . For example, the name of the other configuration property might be: snapshot.collection.filter.overrides.customers.orders . Set this property to a valid filter expression that retrieves only the items that you want in the snapshot. When the connector performs a snapshot, it retrieves only the items that matches the filter expression. snapshot.delay.ms No default An interval in milliseconds that the connector should wait before taking a snapshot after starting up; Can be used to avoid snapshot interruptions when starting multiple connectors in a cluster, which may cause re-balancing of connectors. streaming.delay.ms 0 Specifies the time, in milliseconds, that the connector delays the start of the streaming process after it completes a snapshot. Setting a delay interval helps to prevent the connector from restarting snapshots in the event that a failure occurs immediately after the snapshot completes, but before the streaming process begins. Set a delay value that is higher than the value of the offset.flush.interval.ms property that is set for the Kafka Connect worker. snapshot.fetch.size 0 Specifies the maximum number of documents that should be read in one go from each collection while taking a snapshot. The connector will read the collection contents in multiple batches of this size. Defaults to 0, which indicates that the server chooses an appropriate fetch size. snapshot.include.collection.list All collections specified in collection.include.list An optional, comma-separated list of regular expressions that match the fully-qualified names ( <databaseName> . <collectionName> ) of the schemas that you want to include in a snapshot. The specified items must be named in the connectors's collection.include.list property. This property takes effect only if the connector's snapshot.mode property is set to a value other than never . This property does not affect the behavior of incremental snapshots. To match the name of a schema, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the schema; it does not match substrings that might be present in a schema name. snapshot.max.threads 1 Positive integer value that specifies the maximum number of threads used to perform an intial sync of the collections in a replica set. Defaults to 1. snapshot.mode initial Specifies the criteria for performing a snapshot when the connector starts. Set the property to one of the following values: always The connector performs a snapshot every time that it starts. The snapshot includes the structure and data of the captured tables. Specify this value to populate topics with a complete representation of the data from the captured tables every time that the connector starts. After the snapshot completes, the connector begins to stream event records for subsequent database changes. initial When the connector starts, it performs an initial database snapshot. After the snapshot completes, the connector begins to stream event records for subsequent database changes. initial_only The connector performs a database a snapshot only when no offsets have been recorded for the logical server name. After the snapshot completes, the connector stops. It does not transition to streaming event records for subsequent database changes. never Deprecated, see no_data . no_data The connector runs a snapshot that captures the structure of all relevant tables, but it does not create READ events to represent the data set at the point of the connector's start-up. when_needed After the connector starts, it performs a snapshot only if it detects one of the following circumstances: It cannot detect any topic offsets. A previously recorded offset specifies a log position that is not available on the server. provide.transaction.metadata false When set to true Debezium generates events with transaction boundaries and enriches data events envelope with transaction metadata. See Transaction Metadata for additional details. retriable.restart.connector.wait.ms 10000 (10 seconds) The number of milliseconds to wait before restarting a connector after a retriable error occurs. mongodb.poll.interval.ms 30000 The interval in which the connector polls for new, removed, or changed replica sets. mongodb.connect.timeout.ms 10000 (10 seconds) The number of milliseconds the driver will wait before a new connection attempt is aborted. mongodb.heartbeat.frequency.ms 10000 (10 seconds) The frequency that the cluster monitor attempts to reach each server. mongodb.socket.timeout.ms 0 The number of milliseconds before a send/receive on the socket can take before a timeout occurs. A value of 0 disables this behavior. mongodb.server.selection.timeout.ms 30000 (30 seconds) The number of milliseconds the driver will wait to select a server before it times out and throws an error. cursor.pipeline No default When streaming changes, this setting applies processing to change stream events as part of the standard MongoDB aggregation stream pipeline. A pipeline is a MongoDB aggregation pipeline composed of instructions to the database to filter or transform data. This can be used customize the data that the connector consumes. The value of this property must be an array of permitted aggregation pipeline stages in JSON format. Note that this is appended after the internal pipeline used to support the connector (e.g. filtering operation types, database names, collection names, etc.). cursor.pipeline.order internal_first The order used to construct the effective MongoDB aggregation stream pipeline. Set the property to one of the following values: internal_first Internal stages defined by the connector are applied first. This means that only the events which ought to be captured by the connector are fed to the user defined stages (configured by setting cursor.pipeline ). user_first Stages defined by the 'cursor.pipeline' property are applied first. In this mode all events, included those not captured by the connector, are fed to user defined pipeline stages. This mode can have negative performance impact if the value of cursor.pipeline contains complex operations. user_only Stages defined by the 'cursor.pipeline' property will replace internal stages defined by the connector. This mode is intended only for expert users since all events are processed only by user defined pipeline stages. This mode can have negative impact on performance and overall functionality of the connector! cursor.oversize.handling.mode fail The strategy used to handle change events for documents exceeding specified BSON size. Set the property to one of the following values: fail The connector fails if the total size of change event exceed the maximum BSON size. skip Any change events for documents exceeding the maximum (specified by the cursor.oversize.skip.threshold property) size will be ignored split Change events exceeding the maximum BSON size will be split using the USDchangeStreamSplitLargeEvent aggregation. This option requires MongoDB 6.0.9 or newer . cursor.oversize.skip.threshold 0 The maximum allowed size in bytes of the stored document for which change events are processed. This includes both, the size before and after database operation, more specifically this limits the size of fullDocument and fullDocumentBeforeChange filed of MongoDB change events. cursor.max.await.time.ms 0 Specifies the maximum number of milliseconds the oplog/change stream cursor will wait for the server to produce a result before causing an execution timeout exception. A value of 0 indicates using the server/driver default wait timeout. signal.data.collection No default Fully-qualified name of the data collection that is used to send signals to the connector. Use the following format to specify the collection name: <databaseName> . <collectionName> signal.enabled.channels source List of the signaling channel names that are enabled for the connector. By default, the following channels are available: source kafka file jmx notification.enabled.channels No default List of notification channel names that are enabled for the connector. By default, the following channels are available: sink log jmx incremental.snapshot.chunk.size 1024 The maximum number of documents that the connector fetches and reads into memory during an incremental snapshot chunk. Increasing the chunk size provides greater efficiency, because the snapshot runs fewer snapshot queries of a greater size. However, larger chunk sizes also require more memory to buffer the snapshot data. Adjust the chunk size to a value that provides the best performance in your environment. incremental.snapshot.watermarking.strategy insert_insert Specifies the watermarking mechanism that the connector uses during an incremental snapshot to deduplicate events that might be captured by an incremental snapshot and then recaptured after streaming resumes. You can specify one of the following options: insert_insert When you send a signal to initiate an incremental snapshot, for every chunk that Debezium reads during the snapshot, it writes an entry to the signaling data collection to record the signal to open the snapshot window. After the snapshot completes, Debezium inserts a second entry that records the signal to close the window. insert_delete When you send a signal to initiate an incremental snapshot, for every chunk that Debezium reads, it writes a single entry to the signaling data collection to record the signal to open the snapshot window. After the snapshot completes, this entry is removed. No entry is created for the signal to close the snapshot window. Set this option to prevent rapid growth of the signaling data collection. topic.naming.strategy io.debezium.schema.DefaultTopicNamingStrategy The name of the TopicNamingStrategy class that should be used to determine the topic name for data change, schema change, transaction, heartbeat event etc., defaults to DefaultTopicNamingStrategy . topic.delimiter . Specify the delimiter for topic name, defaults to . . topic.cache.size 10000 The size used for holding the topic names in bounded concurrent hash map. This cache will help to determine the topic name corresponding to a given data collection. topic.heartbeat.prefix __debezium-heartbeat Controls the name of the topic to which the connector sends heartbeat messages. The topic name has this pattern: topic.heartbeat.prefix . topic.prefix For example, if the topic prefix is fulfillment , the default topic name is __debezium-heartbeat.fulfillment . topic.transaction transaction Controls the name of the topic to which the connector sends transaction metadata messages. The topic name has this pattern: topic.prefix . topic.transaction For example, if the topic prefix is fulfillment , the default topic name is fulfillment.transaction . custom.metric.tags No default Defines tags that customize MBean object names by adding metadata that provides contextual information. Specify a comma-separated list of key-value pairs. Each key represents a tag for the MBean object name, and the corresponding value represents a value for the key, for example, k1=v1,k2=v2 The connector appends the specified tags to the base MBean object name. Tags can help you to organize and categorize metrics data. You can define tags to identify particular application instances, environments, regions, versions, and so forth. For more information, see Customized MBean names . errors.max.retries -1 Specifies how the connector responds after an operation that results in a retriable error, such as a connection error. Set one of the following options: -1 No limit. The connector always restarts automatically, and retries the operation, regardless of the number of failures. 0 Disabled. The connector fails immediately, and never retries the operation. User intervention is required to restart the connector. > 0 The connector restarts automatically until it reaches the specified maximum number of retries. After the failure, the connector stops, and user intervention is required to restart it. Pass-through properties for configuring how the MongoDB connector interacts with the Kafka signaling topic Debezium provides a set of signal.* properties that control how the connector interacts with the Kafka signals topic. The following table describes the Kafka signal properties. Table 2.72. Kafka signals configuration properties Property Default Description signal.kafka.topic <topic.prefix>-signal The name of the Kafka topic that the connector monitors for ad hoc signals. Note If automatic topic creation is disabled, you must manually create the required signaling topic. A signaling topic is required to preserve signal ordering. The signaling topic must have a single partition. signal.kafka.groupId kafka-signal The name of the group ID that is used by Kafka consumers. signal.kafka.bootstrap.servers No default A list of the host and port pairs that the connector uses to establish its initial connection to the Kafka cluster. Each pair references the Kafka cluster that is used by the Debezium Kafka Connect process. signal.kafka.poll.timeout.ms 100 An integer value that specifies the maximum number of milliseconds that the connector waits when polling signals. kafka.consumer.offset.commit.enabled false Specifies whether the Kafka consumer writes an offset commit after it reads a message from the signaling topic. The value that you assign to this property determines whether the connector can process requests that the signaling topic receives while the connector is offline. Choose one of the following settings: false When the connector is unavailable, the Kafka consumer does not commit an offset after it reads a signal received by the signaling topic. As a result, if the connector is offline for any interval, it cannot process requests that the signaling topic receives during the downtime. After the connector restarts, it always reads from the last position in the Kafka signaling topic, processing only signals that it receives after the restart. Signals received while the connector is offline are ignored, and are effectively lost. true When a user submits a request to the signaling topic, after the Kafka consumer reads the signal message it commits a topic offset, even if the connector is offline. Choose this option to provide Debezium with information about the last signal message that the consumer read, helping to ensure At-Least-Once delivery. After a connector restarts, it resumes processing from the last recorded offset, responding to signals that users submitted while the connector is offline. Pass-through properties for configuring the MongoDB connector sink notification channel The following table describes properties that you can use to configure the Debezium sink notification channel. Table 2.73. Sink notification configuration properties Property Default Description notification.sink.topic.name No default The name of the topic that receives notifications from Debezium. This property is required when you configure the notification.enabled.channels property to include sink as one of the enabled notification channels. 2.3.6. Monitoring Debezium MongoDB connector performance The Debezium MongoDB connector has two metric types in addition to the built-in support for JMX metrics that Zookeeper, Kafka, and Kafka Connect have. Snapshot metrics provide information about connector operation while performing a snapshot. Streaming metrics provide information about connector operation when the connector is capturing changes and streaming change event records. The Debezium monitoring documentation provides details about how to expose these metrics by using JMX. 2.3.6.1. Customized names for MongoDB connector snapshot and streaming MBean objects Debezium connectors expose metrics via the MBean name for the connector. These metrics, which are specific to each connector instance, provide data about the behavior of the connector's snapshot, streaming, and schema history processes. By default, when you deploy a correctly configured connector, Debezium generates a unique MBean name for each of the different connector metrics. To view the metrics for a connector process, you configure your observability stack to monitor its MBean. But these default MBean names depend on the connector configuration; configuration changes can result in changes to the MBean names. A change to the MBean name breaks the linkage between the connector instance and the MBean, disrupting monitoring activity. In this scenario, you must reconfigure the observability stack to use the new MBean name if you want to resume monitoring. To prevent monitoring disruptions that result from MBean name changes, you can configure custom metrics tags. You configure custom metrics by adding the custom.metric.tags property to the connector configuration. The property accepts key-value pairs in which each key represents a tag for the MBean object name, and the corresponding value represents the value of that tag. For example: k1=v1,k2=v2 . Debezium appends the specified tags to the MBean name of the connector. After you configure the custom.metric.tags property for a connector, you can configure the observability stack to retrieve metrics associated with the specified tags. The observability stack then uses the specified tags, rather than the mutable MBean names to uniquely identify connectors. Later, if Debezium redefines how it constructs MBean names, or if the topic.prefix in the connector configuration changes, metrics collection is uninterrupted, because the metrics scrape task uses the specified tag patterns to identify the connector. A further benefit of using custom tags, is that you can use tags that reflect the architecture of your data pipeline, so that metrics are organized in a way that suits you operational needs. For example, you might specify tags with values that declare the type of connector activity, the application context, or the data source, for example, db1-streaming-for-application-abc . If you specify multiple key-value pairs, all of the specified pairs are appended to the connector's MBean name. The following example illustrates how tags modify the default MBean name. Example 2.23. How custom tags modify the connector MBean name By default, the MongoDB connector uses the following MBean name for streaming metrics: If you set the value of custom.metric.tags to database=salesdb-streaming,table=inventory , Debezium generates the following custom MBean name: 2.3.6.2. Monitoring Debezium during MongoDB snapshots The MBean is debezium.mongodb:type=connector-metrics,context=snapshot,server= <topic.prefix> ,task= <task.id> . Snapshot metrics are not exposed unless a snapshot operation is active, or if a snapshot has occurred since the last connector start. The following table lists the snapshot metrics that are available. Attributes Type Description LastEvent string The last snapshot event that the connector has read. MilliSecondsSinceLastEvent long The number of milliseconds since the connector has read and processed the most recent event. TotalNumberOfEventsSeen long The total number of events that this connector has seen since last started or reset. NumberOfEventsFiltered long The number of events that have been filtered by include/exclude list filtering rules configured on the connector. CapturedTables string[] The list of tables that are captured by the connector. QueueTotalCapacity int The length the queue used to pass events between the snapshotter and the main Kafka Connect loop. QueueRemainingCapacity int The free capacity of the queue used to pass events between the snapshotter and the main Kafka Connect loop. TotalTableCount int The total number of tables that are being included in the snapshot. RemainingTableCount int The number of tables that the snapshot has yet to copy. SnapshotRunning boolean Whether the snapshot was started. SnapshotPaused boolean Whether the snapshot was paused. SnapshotAborted boolean Whether the snapshot was aborted. SnapshotCompleted boolean Whether the snapshot completed. SnapshotDurationInSeconds long The total number of seconds that the snapshot has taken so far, even if not complete. Includes also time when snapshot was paused. SnapshotPausedDurationInSeconds long The total number of seconds that the snapshot was paused. If the snapshot was paused several times, the paused time adds up. RowsScanned Map<String, Long> Map containing the number of rows scanned for each table in the snapshot. Tables are incrementally added to the Map during processing. Updates every 10,000 rows scanned and upon completing a table. MaxQueueSizeInBytes long The maximum buffer of the queue in bytes. This metric is available if max.queue.size.in.bytes is set to a positive long value. CurrentQueueSizeInBytes long The current volume, in bytes, of records in the queue. The Debezium MongoDB connector also provides the following custom snapshot metrics: Attribute Type Description NumberOfDisconnects long Number of database disconnects. 2.3.6.3. Monitoring Debezium MongoDB connector record streaming The MBean is debezium.mongodb:type=connector-metrics,context=streaming,server= <topic.prefix> ,task= <task.id> . The following table lists the streaming metrics that are available. Attributes Type Description LastEvent string The last streaming event that the connector has read. MilliSecondsSinceLastEvent long The number of milliseconds since the connector has read and processed the most recent event. TotalNumberOfEventsSeen long The total number of data change events reported by the source database since the last connector start, or since a metrics reset. Represents the data change workload for Debezium to process. TotalNumberOfCreateEventsSeen long The total number of create events processed by the connector since its last start or metrics reset. TotalNumberOfUpdateEventsSeen long The total number of update events processed by the connector since its last start or metrics reset. TotalNumberOfDeleteEventsSeen long The total number of delete events processed by the connector since its last start or metrics reset. NumberOfEventsFiltered long The number of events that have been filtered by include/exclude list filtering rules configured on the connector. CapturedTables string[] The list of tables that are captured by the connector. QueueTotalCapacity int The length the queue used to pass events between the streamer and the main Kafka Connect loop. QueueRemainingCapacity int The free capacity of the queue used to pass events between the streamer and the main Kafka Connect loop. Connected boolean Flag that denotes whether the connector is currently connected to the database server. MilliSecondsBehindSource long The number of milliseconds between the last change event's timestamp and the connector processing it. The values will incorporate any differences between the clocks on the machines where the database server and the connector are running. NumberOfCommittedTransactions long The number of processed transactions that were committed. SourceEventPosition Map<String, String> The coordinates of the last received event. LastTransactionId string Transaction identifier of the last processed transaction. MaxQueueSizeInBytes long The maximum buffer of the queue in bytes. This metric is available if max.queue.size.in.bytes is set to a positive long value. CurrentQueueSizeInBytes long The current volume, in bytes, of records in the queue. The Debezium MongoDB connector also provides the following custom streaming metrics: Attribute Type Description NumberOfDisconnects long Number of database disconnects. NumberOfPrimaryElections long Number of primary node elections. 2.3.7. How Debezium MongoDB connectors handle faults and problems Debezium is a distributed system that captures all changes in multiple upstream databases, and will never miss or lose an event. When the system is operating normally and is managed carefully, then Debezium provides exactly once delivery of every change event. If a fault occurs, the system does not lose any events. However, while it is recovering from the fault, it might repeat some change events. In such situations, Debezium, like Kafka, provides at least once delivery of change events. The following topics provide details about how the Debezium MongoDB connector handles various kinds of faults and problems. Configuration and startup errors MongoDB becomes unavailable Kafka Connect process stops gracefully Kafka Connect process crashes Kafka becomes unavailable Connector fails after it is stopped for a long interval if snapshot.mode is set to initial MongoDB loses writes Configuration and startup errors In the following situations, the connector fails when trying to start, reports an error or exception in the log, and stops running: The connector's configuration is invalid. The connector cannot successfully connect to MongoDB by using the specified connection parameters. After a failure, the connector attempts to reconnect by using exponential backoff. You can configure the maximum number of reconnection attempts. In these cases, the error will have more details about the problem and possibly a suggested work around. The connector can be restarted when the configuration has been corrected or the MongoDB problem has been addressed. MongoDB becomes unavailable Once the connector is running, if the primary node of any of the MongoDB replica sets become unavailable or unreachable, the connector will repeatedly attempt to reconnect to the primary node, using exponential backoff to prevent saturating the network or servers. If the primary remains unavailable after the configurable number of connection attempts, the connector will fail. The attempts to reconnect are controlled by three properties: connect.backoff.initial.delay.ms - The delay before attempting to reconnect for the first time, with a default of 1 second (1000 milliseconds). connect.backoff.max.delay.ms - The maximum delay before attempting to reconnect, with a default of 120 seconds (120,000 milliseconds). connect.max.attempts - The maximum number of attempts before an error is produced, with a default of 16. Each delay is double that of the prior delay, up to the maximum delay. Given the default values, the following table shows the delay for each failed connection attempt and the total accumulated time before failure. Reconnection attempt number Delay before attempt, in seconds Total delay before attempt, in minutes and seconds 1 1 00:01 2 2 00:03 3 4 00:07 4 8 00:15 5 16 00:31 6 32 01:03 7 64 02:07 8 120 04:07 9 120 06:07 10 120 08:07 11 120 10:07 12 120 12:07 13 120 14:07 14 120 16:07 15 120 18:07 16 120 20:07 Connector Unable to Start - InvalidResumeToken or ChangeStreamHistoryLost A connector that is stopped for a long period fails to start, and reports the following exception: The preceding exception indicates that the entry that corresponds to the connector's resume token is no longer present in the oplog. Because the oplog no longer contains the last offset that the connector processed, the connector cannot resume streaming. You can use either of the following options to recover from the failure: Delete the failed connector, and create a new connector with the same configuration but with a different connector name. Pause the connector and then remove offsets, or change the offset topic. To help prevent failures related to missing resume tokens, optimize configuration of the oplog . Kafka Connect process stops gracefully If Kafka Connect is being run in distributed mode, and a Kafka Connect process is stopped gracefully, then prior to shutdown of that processes Kafka Connect will migrate all of the process' connector tasks to another Kafka Connect process in that group, and the new connector tasks will pick up exactly where the prior tasks left off. There is a short delay in processing while the connector tasks are stopped gracefully and restarted on the new processes. If the group contains only one process and that process is stopped gracefully, then Kafka Connect will stop the connector and record the last offset for each replica set. Upon restart, the replica set tasks will continue exactly where they left off. Kafka Connect process crashes If the Kafka Connector process stops unexpectedly, then any connector tasks it was running will terminate without recording their most recently-processed offsets. When Kafka Connect is being run in distributed mode, it will restart those connector tasks on other processes. However, the MongoDB connectors will resume from the last offset recorded by the earlier processes, which means that the new replacement tasks may generate some of the same change events that were processed just prior to the crash. The number of duplicate events depends on the offset flush period and the volume of data changes just before the crash. Note Because there is a chance that some events may be duplicated during a recovery from failure, consumers should always anticipate some events may be duplicated. Debezium changes are idempotent, so a sequence of events always results in the same state. Debezium also includes with each change event message the source-specific information about the origin of the event, including the MongoDB event's unique transaction identifier ( h ) and timestamp ( sec and ord ). Consumers can keep track of other of these values to know whether it has already seen a particular event. Kafka becomes unavailable As the connector generates change events, the Kafka Connect framework records those events in Kafka using the Kafka producer API. Kafka Connect will also periodically record the latest offset that appears in those change events, at a frequency that you have specified in the Kafka Connect worker configuration. If the Kafka brokers become unavailable, the Kafka Connect worker process running the connectors will simply repeatedly attempt to reconnect to the Kafka brokers. In other words, the connector tasks will simply pause until a connection can be reestablished, at which point the connectors will resume exactly where they left off. Connector fails after it is stopped for a long interval if snapshot.mode is set to initial If the connector is gracefully stopped, users might continue to perform operations on replica set members. Changes that occur while the connector is offline continue to be recorded in MongoDB's oplog. In most cases, after the connector is restarted, it reads the offset value in the oplog to determine the last operation that it streamed for each replica set, and then resumes streaming changes from that point. After the restart, database operations that occurred while the connector was stopped are emitted to Kafka as usual, and after some time, the connector catches up with the database. The amount of time required for the connector to catch up depends on the capabilities and performance of Kafka and the volume of changes that occurred in the database. However, if the connector remains stopped for a long enough interval, it can occur that MongoDB purges the oplog during the time that the connector is inactive, resulting in the loss of information about the connector's last position. After the connector restarts, it cannot resume streaming, because the oplog no longer contains the offset value that marks the last operation that the connector processed. The connector also cannot perform a snapshot, as it typically would when the snapshot.mode property is set to initial , and no offset value is present. In this case, a mismatch exists, because the oplog does not contain the value of the offset, but the offset value is present in the connector's internal Kafka offsets topic. An error results and the connector fails. To recover from the failure, delete the failed connector, and create a new connector with the same configuration but with a different connector name. When you start the new connector, it performs a snapshot to ingest the state of database, and then resumes streaming. MongoDB loses writes In certain failure situations, MongoDB can lose commits, which results in the MongoDB connector being unable to capture the lost changes. For example, if the primary crashes suddenly after it applies a change and records the change to its oplog, the oplog might become unavailable before secondary nodes can read its contents. As a result, the secondary node that is elected as the new primary node might be missing the most recent changes from its oplog. At this time, there is no way to prevent this side effect in MongoDB. 2.4. Debezium connector for MySQL MySQL has a binary log (binlog) that records all operations in the order in which they are committed to the database. This includes changes to table schemas as well as changes to the data in tables. MySQL uses the binlog for replication and recovery. The Debezium MySQL connector reads the binlog, produces change events for row-level INSERT , UPDATE , and DELETE operations, and emits the change events to Kafka topics. Client applications read those Kafka topics. Because MySQL is typically set up to purge binlogs after a specified period of time, the MySQL connector performs an initial consistent snapshot of each of your databases. The MySQL connector reads the binlog from the point at which the snapshot was made. For information about the MySQL Database versions that are compatible with this connector, see the Debezium Supported Configurations page . Information and procedures for using a Debezium MySQL connector are organized as follows: Section 2.4.1, "How Debezium MySQL connectors work" Section 2.4.2, "Descriptions of Debezium MySQL connector data change events" Section 2.4.3, "How Debezium MySQL connectors map data types" Section 2.4.4, "Custom converters for mapping MySQL data to alternative data types" Section 2.4.5, "Setting up MySQL to run a Debezium connector" Section 2.4.6, "Deployment of Debezium MySQL connectors" Section 2.4.7, "Monitoring Debezium MySQL connector performance" Section 2.4.8, "How Debezium MySQL connectors handle faults and problems" 2.4.1. How Debezium MySQL connectors work An overview of the MySQL topologies that the connector supports is useful for planning your application. To optimally configure and run a Debezium MySQL connector, it is helpful to understand how the connector tracks the structure of tables, exposes schema changes, performs snapshots, and determines Kafka topic names. Details are in the following topics: Section 2.4.1.1, "MySQL topologies supported by Debezium connectors" Section 2.4.1.2, "How Debezium MySQL connectors handle database schema changes" Section 2.4.1.3, "How Debezium MySQL connectors expose database schema changes" Section 2.4.1.4, "How Debezium MySQL connectors perform database snapshots" Section 2.4.1.5, "Ad hoc snapshots" Section 2.4.1.6, "Incremental snapshots" Section 2.4.1.8, "Default names of Kafka topics that receive Debezium MySQL change event records" 2.4.1.1. MySQL topologies supported by Debezium connectors The Debezium MySQL connector supports the following MySQL topologies: Standalone When a single MySQL server is used, the server must have the binlog enabled so the Debezium MySQL connector can monitor the server. This is often acceptable, since the binary log can also be used as an incremental [backup]. In this case, the MySQL connector always connects to and follows this standalone MySQL server instance. Primary and replica The Debezium MySQL connector can follow one of the primary servers, or one of the replicas ( if that replica has its binlog enabled ), but the connector detects changes only in the cluster that is visible to that server. Generally, this is not a problem except for the multi-primary topologies. The connector records its position in the server's binlog, which is different on each server in the cluster. Therefore, the connector must follow just one MySQL server instance. If that server fails, that server must be restarted or recovered before the connector can continue. High available clusters A variety of [high availability] solutions exist for MySQL, and they make it significantly easier to tolerate and almost immediately recover from problems and failures. Because HA MySQL clusters use GTIDs, replicas are able to track all of the changes that occur on any primary server. Multi-primary uses one or more MySQL replica nodes that each replicate from multiple primary servers. Cluster replication provides a powerful way to aggregate the replication of multiple MySQL clusters. A Debezium MySQL connector can use these multi-primary MySQL replicas as sources, and can fail over to different multi-primary MySQL replicas as long as the new replica is caught up to the old replica. That is, the new replica has all transactions that were seen on the first replica. This works even if the connector is using only a subset of databases and/or tables, because the connector can be configured to include or exclude specific GTID sources when attempting to reconnect to a new multi-primary MySQL replica and find the correct position in the binlog. Hosted The Debezium MySQL connector can use hosted database options such as Amazon RDS and Amazon Aurora. Because these hosted options do not permit the use of global read locks, the connector uses table-level locks when it creates a consistent snapshot. 2.4.1.2. How Debezium MySQL connectors handle database schema changes When a database client queries a database, the client uses the database's current schema. However, the database schema can be changed at any time, which means that the connector must be able to identify what the schema was at the time each insert, update, or delete operation was recorded. Also, a connector cannot necessarily apply the current schema to every event. If an event is relatively old, it's possible that it was recorded before the current schema was applied. To ensure correct processing of events that occur after a schema change, MySQL includes in the transaction log not only the row-level changes that affect the data, but also the DDL statements that are applied to the database. As the connector encounters these DDL statements in the binlog, it parses them and updates an in-memory representation of each table's schema. The connector uses this schema representation to identify the structure of the tables at the time of each insert, update, or delete operation and to produce the appropriate change event. In a separate database schema history Kafka topic, the connector records all DDL statements along with the position in the binlog where each DDL statement appeared. When the connector restarts after either a crash or a graceful stop, it starts reading the binlog from a specific position, that is, from a specific point in time. The connector rebuilds the table structures that existed at this point in time by reading the database schema history Kafka topic and parsing all DDL statements up to the point in the binlog where the connector is starting. This database schema history topic is for internal connector use only. Optionally, the connector can also emit schema change events to a different topic that is intended for consumer applications . When the MySQL connector captures changes in a table to which a schema change tool such as gh-ost or pt-online-schema-change is applied, there are helper tables created during the migration process. You must configure the connector to capture changes that occur in these helper tables. If consumers do not need the records the connector generates for helper tables, configure a single message transform (SMT) to remove these records from the messages that the connector emits. Additional resources Default names for topics that receive Debezium event records. 2.4.1.3. How Debezium MySQL connectors expose database schema changes You can configure a Debezium MySQL connector to produce schema change events that describe schema changes that are applied to tables in the database. The connector writes schema change events to a Kafka topic named <topicPrefix> , where topicPrefix is the namespace specified in the topic.prefix connector configuration property. Messages that the connector sends to the schema change topic contain a payload, and, optionally, also contain the schema of the change event message. The schema for the schema change event has the following elements: name The name of the schema change event message. type The type of the change event message. version The version of the schema. The version is an integer that is incremented each time the schema is changed. fields The fields that are included in the change event message. Example: Schema of the MySQL connector schema change topic The following example shows a typical schema in JSON format. { "schema": { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "databaseName" } ], "optional": false, "name": "io.debezium.connector.mysql.SchemaChangeKey", "version": 1 }, "payload": { "databaseName": "inventory" } } The payload of a schema change event message includes the following elements: ddl Provides the SQL CREATE , ALTER , or DROP statement that results in the schema change. databaseName The name of the database to which the DDL statements are applied. The value of databaseName serves as the message key. pos The position in the binlog where the statements appear. tableChanges A structured representation of the entire table schema after the schema change. The tableChanges field contains an array that includes entries for each column of the table. Because the structured representation presents data in JSON or Avro format, consumers can easily read messages without first processing them through a DDL parser. Important For a table that is in capture mode, the connector not only stores the history of schema changes in the schema change topic, but also in an internal database schema history topic. The internal database schema history topic is for connector use only, and it is not intended for direct use by consuming applications. Ensure that applications that require notifications about schema changes consume that information only from the schema change topic. Important Never partition the database schema history topic. For the database schema history topic to function correctly, it must maintain a consistent, global order of the event records that the connector emits to it. To ensure that the topic is not split among partitions, set the partition count for the topic by using one of the following methods: If you create the database schema history topic manually, specify a partition count of 1 . If you use the Apache Kafka broker to create the database schema history topic automatically, the topic is created, set the value of the Kafka num.partitions configuration option to 1 . Warning The format of the messages that a connector emits to its schema change topic is in an incubating state and is subject to change without notice. Example: Message emitted to the MySQL connector schema change topic The following example shows a typical schema change message in JSON format. The message contains a logical representation of the table schema. { "schema": { }, "payload": { "source": { 1 "version": "2.7.3.Final", "connector": "mysql", "name": "mysql", "ts_ms": 1651535750218, 2 "ts_us": 1651535750218000, 3 "ts_ns": 1651535750218000000, 4 "snapshot": "false", "db": "inventory", "sequence": null, "table": "customers", "server_id": 223344, "gtid": null, "file": "mysql-bin.000003", "pos": 570, "row": 0, "thread": null, "query": null }, "databaseName": "inventory", 5 "schemaName": null, "ddl": "ALTER TABLE customers ADD middle_name varchar(255) AFTER first_name", 6 "tableChanges": [ 7 { "type": "ALTER", 8 "id": "\"inventory\".\"customers\"", 9 "table": { 10 "defaultCharsetName": "utf8mb4", "primaryKeyColumnNames": [ 11 "id" ], "columns": [ 12 { "name": "id", "jdbcType": 4, "nativeType": null, "typeName": "INT", "typeExpression": "INT", "charsetName": null, "length": null, "scale": null, "position": 1, "optional": false, "autoIncremented": true, "generated": true }, { "name": "first_name", "jdbcType": 12, "nativeType": null, "typeName": "VARCHAR", "typeExpression": "VARCHAR", "charsetName": "utf8mb4", "length": 255, "scale": null, "position": 2, "optional": false, "autoIncremented": false, "generated": false }, { "name": "middle_name", "jdbcType": 12, "nativeType": null, "typeName": "VARCHAR", "typeExpression": "VARCHAR", "charsetName": "utf8mb4", "length": 255, "scale": null, "position": 3, "optional": true, "autoIncremented": false, "generated": false }, { "name": "last_name", "jdbcType": 12, "nativeType": null, "typeName": "VARCHAR", "typeExpression": "VARCHAR", "charsetName": "utf8mb4", "length": 255, "scale": null, "position": 4, "optional": false, "autoIncremented": false, "generated": false }, { "name": "email", "jdbcType": 12, "nativeType": null, "typeName": "VARCHAR", "typeExpression": "VARCHAR", "charsetName": "utf8mb4", "length": 255, "scale": null, "position": 5, "optional": false, "autoIncremented": false, "generated": false } ], "attributes": [ 13 { "customAttribute": "attributeValue" } ] } } ] } } Table 2.74. Descriptions of fields in messages emitted to the schema change topic Item Field name Description 1 source The source field is structured exactly as standard data change events that the connector writes to table-specific topics. This field is useful to correlate events on different topics. 2 ts_ms , ts_us , ts_ns Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms, you can determine the lag between the source database update and Debezium. 3 databaseName schemaName Identifies the database and the schema that contains the change. The value of the databaseName field is used as the message key for the record. 4 ddl This field contains the DDL that is responsible for the schema change. The ddl field can contain multiple DDL statements. Each statement applies to the database in the databaseName field. Multiple DDL statements appear in the order in which they were applied to the database. Clients can submit multiple DDL statements that apply to multiple databases. If MySQL applies them atomically, the connector takes the DDL statements in order, groups them by database, and creates a schema change event for each group. If MySQL applies them individually, the connector creates a separate schema change event for each statement. 5 tableChanges An array of one or more items that contain the schema changes generated by a DDL command. 6 type Describes the kind of change. The value is one of the following: CREATE Table created. ALTER Table modified. DROP Table deleted. 7 id Full identifier of the table that was created, altered, or dropped. In the case of a table rename, this identifier is a concatenation of <old> , <new> table names. 8 table Represents table metadata after the applied change. 9 primaryKeyColumnNames List of columns that compose the table's primary key. 10 columns Metadata for each column in the changed table. 11 attributes Custom attribute metadata for each table change. For more information, see schema history topic . 2.4.1.4. How Debezium MySQL connectors perform database snapshots When a Debezium MySQL connector is first started, it performs an initial consistent snapshot of your database. This snapshot enables the connector to establish a baseline for the current state of the database. Debezium can use different modes when it runs a snapshot. The snapshot mode is determined by the snapshot.mode configuration property. The default value of the property is initial . You can customize the way that the connector creates snapshots by changing the value of the snapshot.mode property. You can find more information about snapshots in the following sections: Section 2.4.1.5, "Ad hoc snapshots" Section 2.4.1.6, "Incremental snapshots" The connector completes a series of tasks when it performs the snapshot. The exact steps vary with the snapshot mode and with the table locking policy that is in effect for the database. The Debezium MySQL connector completes different steps when it performs an initial snapshot that uses a global read lock or table-level locks . 2.4.1.4.1. Initial snapshots that use a global read lock You can customize the way that the connector creates snapshots by changing the value of the snapshot.mode property. If you configure a different snapshot mode, the connector completes the snapshot by using a modified version of this workflow. For information about the snapshot process in environments that do not permit global read locks, see the snapshot workflow for table-level locks . Default workflow that the Debezium MySQL connector uses to perform an initial snapshot with a global read lock The following table shows the steps in the workflow that Debezium follows to create a snapshot with a global read lock. Step Action 1 Establish a connection to the database. 2 Determine the tables to be captured. By default, the connector captures the data for all non-system tables. After the snapshot completes, the connector continues to stream data for the specified tables. If you want the connector to capture data only from specific tables you can direct the connector to capture the data for only a subset of tables or table elements by setting properties such as table.include.list or table.exclude.list . 3 Obtain a global read lock on the tables to be captured to block writes by other database clients. The snapshot itself does not prevent other clients from applying DDL that might interfere with the connector's attempt to read the binlog position and table schemas. The connector retains the global read lock while it reads the binlog position, and releases the lock as described in a later step. 4 Note The use of these isolation semantics can slow the progress of the snapshot. If the snapshot takes too long to complete, consider using a different isolation configuration, or skip the initial snapshot and run an incremental snapshot instead. 5 Read the current binlog position. 6 Capture the structure of all tables in the database, or all tables that are designated for capture. The connector persists schema information in its internal database schema history topic, including all necessary DROP... and CREATE... DDL statements. The schema history provides information about the structure that is in effect when a change event occurs. Note By default, the connector captures the schema of every table in the database, including tables that are not configured for capture. If tables are not configured for capture, the initial snapshot captures only their structure; it does not capture any table data. For more information about why snapshots persist schema information for tables that you did not include in the initial snapshot, see Understanding why initial snapshots capture the schema for all tables . 7 Release the global read lock obtained in Step 3. Other database clients can now write to the database. 8 At the binlog position that the connector read in Step 5, the connector begins to scan the tables that are designated for capture. During the scan, the connector completes the following tasks: Confirms that the table was created before the snapshot began. If the table was created after the snapshot began, the connector skips the table. After the snapshot is complete, and the connector transitions to streaming, it emits change events for any tables that were created after the snapshot began. Produces a read event for each row that is captured from a table. All read events contain the same binlog position, which is the position that was obtained in step 5. Emits each read event to the Kafka topic for the source table. Releases data table locks, if applicable. 9 Commit the transaction. 10 The resulting initial snapshot captures the current state of each row in the captured tables. From this baseline state, the connector captures subsequent changes as they occur. After the snapshot process begins, if the process is interrupted due to connector failure, rebalancing, or other reasons, the process restarts after the connector restarts. After the connector completes the initial snapshot, it continues streaming from the position that it read in Step 5 so that it does not miss any updates. If the connector stops again for any reason, after it restarts, it resumes streaming changes from where it previously left off. After the connector restarts, if the logs have been pruned, the connector's position in the logs might no longer available. The connector then fails, and returns an error that indicates that a new snapshot is required. To configure the connector to automatically initiate a snapshot in this situation, set the value of the snapshot.mode property to when_needed . For more tips on troubleshooting the Debezium MySQL connector, see behavior when things go wrong . 2.4.1.4.2. Initial snapshots that use table-level locks In some database environments, administrators do not permit global read locks. If the Debezium MySQL connector detects that global read locks are not permitted, the connector uses table-level locks when it performs snapshots. For the connector to perform a snapshot that uses table-level locks, the database account that the Debezium connector uses to connect to MySQL must have LOCK TABLES privileges. Default workflow that the Debezium MySQL connector uses to perform an initial snapshot with table-level locks The following table shows the steps in the workflow that Debezium follows to create a snapshot with table-level read locks. For information about the snapshot process in environments that do not permit global read locks, see the snapshot workflow for global read locks . Step Action 1 Establish a connection to the database. 2 Determine the tables to be captured. By default, the connector captures all non-system tables. To have the connector capture a subset of tables or table elements, you can set a number of include and exclude properties to filter the data, for example, table.include.list or table.exclude.list . 3 Obtain table-level locks. 4 5 Read the current binlog position. 6 Read the schema of the databases and tables for which the connector is configured to capture changes. The connector persists schema information in its internal database schema history topic, including all necessary DROP... and CREATE... DDL statements. The schema history provides information about the structure that is in effect when a change event occurs. Note By default, the connector captures the schema of every table in the database, including tables that are not configured for capture. If tables are not configured for capture, the initial snapshot captures only their structure; it does not capture any table data. For more information about why snapshots persist schema information for tables that you did not include in the initial snapshot, see Understanding why initial snapshots capture the schema for all tables . 7 At the binlog position that the connector read in Step 5, the connector begins to scan the tables that are designated for capture. During the scan, the connector completes the following tasks: Confirms that the table was created before the snapshot began. If the table was created after the snapshot began, the connector skips the table. After the snapshot is complete, and the connector transitions to streaming, it emits change events for any tables that were created after the snapshot began. Produces a read event for each row that is captured from a table. All read events contain the same binlog position, which is the position that was obtained in step 5. Emits each read event to the Kafka topic for the source table. Releases data table locks, if applicable. 8 Commit the transaction. 9 Release the table-level locks. Other database clients can now write to any previously locked tables. 10 Table 2.75. Settings for snapshot.mode connector configuration property Setting Description always The connector performs a snapshot every time that it starts. The snapshot includes the structure and data of the captured tables. Specify this value to populate topics with a complete representation of the data from the captured tables every time that the connector starts. After the snapshot completes, the connector begins to stream event records for subsequent database changes. initial The connector performs a database snapshot as described in the default workflow for creating an initial snapshot . After the snapshot completes, the connector begins to stream event records for subsequent database changes. initial_only The connector performs a database snapshot. After the snapshot completes, the connector stops, and does not stream event records for subsequent database changes. schema_only Deprecated, see no_data . no_data The connector captures the structure of all relevant tables, performing all the steps described in the default workflow for creating an initial snapshot , except that it does not create READ events to represent the data set at the point of the connector's start-up (Step 7.2). never When the connector starts, rather than performing a snapshot, it immediately begins to stream event records for subsequent database changes. This option is under consideration for future deprecation, in favor of the no_data option. schema_only_recovery Deprecated, see recovery . recovery Set this option to restore a database schema history topic that is lost or corrupted. After a restart, the connector runs a snapshot that rebuilds the topic from the source tables. You can also set the property to periodically prune a database schema history topic that experiences unexpected growth. WARNING: Do not use this mode to perform a snapshot if schema changes were committed to the database after the last connector shutdown. when_needed After the connector starts, it performs a snapshot only if it detects one of the following circumstances: It cannot detect any topic offsets. A previously recorded offset specifies a log position that is not available on the server. For more information, see snapshot.mode in the table of connector configuration properties. 2.4.1.4.3. Description of why initial snapshots capture the schema history for all tables The initial snapshot that a connector runs captures two types of information: Table data Information about INSERT , UPDATE , and DELETE operations in tables that are named in the connector's table.include.list property. Schema data DDL statements that describe the structural changes that are applied to tables. Schema data is persisted to both the internal schema history topic, and to the connector's schema change topic, if one is configured. After you run an initial snapshot, you might notice that the snapshot captures schema information for tables that are not designated for capture. By default, initial snapshots are designed to capture schema information for every table that is present in the database, not only from tables that are designated for capture. Connectors require that the table's schema is present in the schema history topic before they can capture a table. By enabling the initial snapshot to capture schema data for tables that are not part of the original capture set, Debezium prepares the connector to readily capture event data from these tables should that later become necessary. If the initial snapshot does not capture a table's schema, you must add the schema to the history topic before the connector can capture data from the table. In some cases, you might want to limit schema capture in the initial snapshot. This can be useful when you want to reduce the time required to complete a snapshot. Or when Debezium connects to the database instance through a user account that has access to multiple logical databases, but you want the connector to capture changes only from tables in a specific logic database. Additional information Capturing data from tables not captured by the initial snapshot (no schema change) Capturing data from tables not captured by the initial snapshot (schema change) Setting the schema.history.internal.store.only.captured.tables.ddl property to specify the tables from which to capture schema information. Setting the schema.history.internal.store.only.captured.databases.ddl property to specify the logical databases from which to capture schema changes. 2.4.1.4.4. Capturing data from tables not captured by the initial snapshot (no schema change) In some cases, you might want the connector to capture data from a table whose schema was not captured by the initial snapshot. Depending on the connector configuration, the initial snapshot might capture the table schema only for specific tables in the database. If the table schema is not present in the history topic, the connector fails to capture the table, and reports a missing schema error. You might still be able to capture data from the table, but you must perform additional steps to add the table schema. Prerequisites You want to capture data from a table with a schema that the connector did not capture during the initial snapshot. In the transaction log, all entries for the table use the same schema. For information about capturing data from a new table that has undergone structural changes, see Capturing data from tables not captured by the initial snapshot (schema change) . Procedure Stop the connector. Remove the internal database schema history topic that is specified by the schema.history.internal.kafka.topic property . Apply the following changes to the connector configuration: Set the snapshot.mode to schema_only_recovery . Set the value of schema.history.internal.store.only.captured.tables.ddl to false . Add the tables that you want the connector to capture to table.include.list . This guarantees that in the future, the connector can reconstruct the schema history for all tables. Restart the connector. The snapshot recovery process rebuilds the schema history based on the current structure of the tables. (Optional) After the snapshot completes, initiate an incremental snapshot to capture existing data for newly added tables along with changes to other tables that occurred while that connector was off-line. (Optional) Reset the snapshot.mode back to schema_only to prevent the connector from initiating recovery after a future restart. 2.4.1.4.5. Capturing data from tables not captured by the initial snapshot (schema change) If a schema change is applied to a table, records that are committed before the schema change have different structures than those that were committed after the change. When Debezium captures data from a table, it reads the schema history to ensure that it applies the correct schema to each event. If the schema is not present in the schema history topic, the connector is unable to capture the table, and an error results. If you want to capture data from a table that was not captured by the initial snapshot, and the schema of the table was modified, you must add the schema to the history topic, if it is not already available. You can add the schema by running a new schema snapshot, or by running an initial snapshot for the table. Prerequisites You want to capture data from a table with a schema that the connector did not capture during the initial snapshot. A schema change was applied to the table so that the records to be captured do not have a uniform structure. Procedure Initial snapshot captured the schema for all tables ( store.only.captured.tables.ddl was set to false ) Edit the table.include.list property to specify the tables that you want to capture. Restart the connector. Initiate an incremental snapshot if you want to capture existing data from the newly added tables. Initial snapshot did not capture the schema for all tables ( store.only.captured.tables.ddl was set to true ) If the initial snapshot did not save the schema of the table that you want to capture, complete one of the following procedures: Procedure 1: Schema snapshot, followed by incremental snapshot In this procedure, the connector first performs a schema snapshot. You can then initiate an incremental snapshot to enable the connector to synchronize data. Stop the connector. Remove the internal database schema history topic that is specified by the schema.history.internal.kafka.topic property . Clear the offsets in the configured Kafka Connect offset.storage.topic . For more information about how to remove offsets, see the Debezium community FAQ . Warning Removing offsets should be performed only by advanced users who have experience in manipulating internal Kafka Connect data. This operation is potentially destructive, and should be performed only as a last resort. Set values for properties in the connector configuration as described in the following steps: Set the value of the snapshot.mode property to schema_only . Edit the table.include.list to add the tables that you want to capture. Restart the connector. Wait for Debezium to capture the schema of the new and existing tables. Data changes that occurred any tables after the connector stopped are not captured. To ensure that no data is lost, initiate an incremental snapshot . Procedure 2: Initial snapshot, followed by optional incremental snapshot In this procedure the connector performs a full initial snapshot of the database. As with any initial snapshot, in a database with many large tables, running an initial snapshot can be a time-consuming operation. After the snapshot completes, you can optionally trigger an incremental snapshot to capture any changes that occur while the connector is off-line. Stop the connector. Remove the internal database schema history topic that is specified by the schema.history.internal.kafka.topic property . Clear the offsets in the configured Kafka Connect offset.storage.topic . For more information about how to remove offsets, see the Debezium community FAQ . Warning Removing offsets should be performed only by advanced users who have experience in manipulating internal Kafka Connect data. This operation is potentially destructive, and should be performed only as a last resort. Edit the table.include.list to add the tables that you want to capture. Set values for properties in the connector configuration as described in the following steps: Set the value of the snapshot.mode property to initial . (Optional) Set schema.history.internal.store.only.captured.tables.ddl to false . Restart the connector. The connector takes a full database snapshot. After the snapshot completes, the connector transitions to streaming. (Optional) To capture any data that changed while the connector was off-line, initiate an incremental snapshot . 2.4.1.5. Ad hoc snapshots By default, a connector runs an initial snapshot operation only after it starts for the first time. Following this initial snapshot, under normal circumstances, the connector does not repeat the snapshot process. Any future change event data that the connector captures comes in through the streaming process only. However, in some situations the data that the connector obtained during the initial snapshot might become stale, lost, or incomplete. To provide a mechanism for recapturing table data, Debezium includes an option to perform ad hoc snapshots. You might want to perform an ad hoc snapshot after any of the following changes occur in your Debezium environment: The connector configuration is modified to capture a different set of tables. Kafka topics are deleted and must be rebuilt. Data corruption occurs due to a configuration error or some other problem. You can re-run a snapshot for a table for which you previously captured a snapshot by initiating a so-called ad-hoc snapshot . Ad hoc snapshots require the use of signaling tables . You initiate an ad hoc snapshot by sending a signal request to the Debezium signaling table. When you initiate an ad hoc snapshot of an existing table, the connector appends content to the topic that already exists for the table. If a previously existing topic was removed, Debezium can create a topic automatically if automatic topic creation is enabled. Ad hoc snapshot signals specify the tables to include in the snapshot. The snapshot can capture the entire contents of the database, or capture only a subset of the tables in the database. Also, the snapshot can capture a subset of the contents of the table(s) in the database. You specify the tables to capture by sending an execute-snapshot message to the signaling table. Set the type of the execute-snapshot signal to incremental or blocking , and provide the names of the tables to include in the snapshot, as described in the following table: Table 2.76. Example of an ad hoc execute-snapshot signal record Field Default Value type incremental Specifies the type of snapshot that you want to run. Currently, you can request incremental or blocking snapshots. data-collections N/A An array that contains regular expressions matching the fully-qualified names of the tables to include in the snapshot. For the MySQL connector, use the following format to specify the fully qualified name of a table: database.table . additional-conditions N/A An optional array that specifies a set of additional conditions that the connector evaluates to determine the subset of records to include in a snapshot. Each additional condition is an object that specifies the criteria for filtering the data that an ad hoc snapshot captures. You can set the following parameters for each additional condition: data-collection The fully-qualified name of the table that the filter applies to. You can apply different filters to each table. filter Specifies column values that must be present in a database record for the snapshot to include it, for example, "color='blue'" . The values that you assign to the filter parameter are the same types of values that you might specify in the WHERE clause of SELECT statements when you set the snapshot.select.statement.overrides property for a blocking snapshot. surrogate-key N/A An optional string that specifies the column name that the connector uses as the primary key of a table during the snapshot process. Triggering an ad hoc incremental snapshot You initiate an ad hoc incremental snapshot by adding an entry with the execute-snapshot signal type to the signaling table, or by sending a signal message to a Kafka signaling topic . After the connector processes the message, it begins the snapshot operation. The snapshot process reads the first and last primary key values and uses those values as the start and end point for each table. Based on the number of entries in the table, and the configured chunk size, Debezium divides the table into chunks, and proceeds to snapshot each chunk, in succession, one at a time. For more information, see Incremental snapshots . Triggering an ad hoc blocking snapshot You initiate an ad hoc blocking snapshot by adding an entry with the execute-snapshot signal type to the signaling table or signaling topic. After the connector processes the message, it begins the snapshot operation. The connector temporarily stops streaming, and then initiates a snapshot of the specified table, following the same process that it uses during an initial snapshot. After the snapshot completes, the connector resumes streaming. For more information, see Blocking snapshots . 2.4.1.6. Incremental snapshots To provide flexibility in managing snapshots, Debezium includes a supplementary snapshot mechanism, known as incremental snapshotting . Incremental snapshots rely on the Debezium mechanism for sending signals to a Debezium connector . In an incremental snapshot, instead of capturing the full state of a database all at once, as in an initial snapshot, Debezium captures each table in phases, in a series of configurable chunks. You can specify the tables that you want the snapshot to capture and the size of each chunk . The chunk size determines the number of rows that the snapshot collects during each fetch operation on the database. The default chunk size for incremental snapshots is 1024 rows. As an incremental snapshot proceeds, Debezium uses watermarks to track its progress, maintaining a record of each table row that it captures. This phased approach to capturing data provides the following advantages over the standard initial snapshot process: You can run incremental snapshots in parallel with streamed data capture, instead of postponing streaming until the snapshot completes. The connector continues to capture near real-time events from the change log throughout the snapshot process, and neither operation blocks the other. If the progress of an incremental snapshot is interrupted, you can resume it without losing any data. After the process resumes, the snapshot begins at the point where it stopped, rather than recapturing the table from the beginning. You can run an incremental snapshot on demand at any time, and repeat the process as needed to adapt to database updates. For example, you might re-run a snapshot after you modify the connector configuration to add a table to its table.include.list property. Incremental snapshot process When you run an incremental snapshot, Debezium sorts each table by primary key and then splits the table into chunks based on the configured chunk size . Working chunk by chunk, it then captures each table row in a chunk. For each row that it captures, the snapshot emits a READ event. That event represents the value of the row when the snapshot for the chunk began. As a snapshot proceeds, it's likely that other processes continue to access the database, potentially modifying table records. To reflect such changes, INSERT , UPDATE , or DELETE operations are committed to the transaction log as per usual. Similarly, the ongoing Debezium streaming process continues to detect these change events and emits corresponding change event records to Kafka. How Debezium resolves collisions among records with the same primary key In some cases, the UPDATE or DELETE events that the streaming process emits are received out of sequence. That is, the streaming process might emit an event that modifies a table row before the snapshot captures the chunk that contains the READ event for that row. When the snapshot eventually emits the corresponding READ event for the row, its value is already superseded. To ensure that incremental snapshot events that arrive out of sequence are processed in the correct logical order, Debezium employs a buffering scheme for resolving collisions. Only after collisions between the snapshot events and the streamed events are resolved does Debezium emit an event record to Kafka. Snapshot window To assist in resolving collisions between late-arriving READ events and streamed events that modify the same table row, Debezium employs a so-called snapshot window . The snapshot window demarcates the interval during which an incremental snapshot captures data for a specified table chunk. Before the snapshot window for a chunk opens, Debezium follows its usual behavior and emits events from the transaction log directly downstream to the target Kafka topic. But from the moment that the snapshot for a particular chunk opens, until it closes, Debezium performs a de-duplication step to resolve collisions between events that have the same primary key.. For each data collection, the Debezium emits two types of events, and stores the records for them both in a single destination Kafka topic. The snapshot records that it captures directly from a table are emitted as READ operations. Meanwhile, as users continue to update records in the data collection, and the transaction log is updated to reflect each commit, Debezium emits UPDATE or DELETE operations for each change. As the snapshot window opens, and Debezium begins processing a snapshot chunk, it delivers snapshot records to a memory buffer. During the snapshot windows, the primary keys of the READ events in the buffer are compared to the primary keys of the incoming streamed events. If no match is found, the streamed event record is sent directly to Kafka. If Debezium detects a match, it discards the buffered READ event, and writes the streamed record to the destination topic, because the streamed event logically supersede the static snapshot event. After the snapshot window for the chunk closes, the buffer contains only READ events for which no related transaction log events exist. Debezium emits these remaining READ events to the table's Kafka topic. The connector repeats the process for each snapshot chunk. Currently, you can use either of the following methods to initiate an incremental snapshot: Send an ad hoc snapshot signal to the signaling table on the source database . Send a message to a configured Kafka signaling topic . 2.4.1.6.1. Triggering an incremental snapshot To initiate an incremental snapshot, you can send an ad hoc snapshot signal to the signaling table on the source database. You submit snapshot signals as SQL INSERT queries. After Debezium detects the change in the signaling table, it reads the signal, and runs the requested snapshot operation. The query that you submit specifies the tables to include in the snapshot, and, optionally, specifies the type of snapshot operation. Debezium currently supports the incremental and blocking snapshot types. To specify the tables to include in the snapshot, provide a data-collections array that lists the tables, or an array of regular expressions used to match tables, for example, {"data-collections": ["public.MyFirstTable", "public.MySecondTable"]} The data-collections array for an incremental snapshot signal has no default value. If the data-collections array is empty, Debezium interprets the empty array to mean that no action is required, and it does not perform a snapshot. Note If the name of a table that you want to include in a snapshot contains a dot ( . ), a space, or some other non-alphanumeric character, you must escape the table name in double quotes. For example, to include a table that exists in the db1 database, and that has the name My.Table , use the following format: "db1.\"My.Table\"" . Prerequisites Signaling is enabled . A signaling data collection exists on the source database. The signaling data collection is specified in the signal.data.collection property. Using a source signaling channel to trigger an incremental snapshot Send a SQL query to add the ad hoc incremental snapshot request to the signaling table: INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}'); For example, INSERT INTO db1.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'execute-snapshot', 3 '{"data-collections": ["db1.table1", "db1.table2"], 4 "type":"incremental", 5 "additional-conditions":[{"data-collection": "db1.table1" ,"filter":"color=\'blue\'"}]}'); 6 The values of the id , type , and data parameters in the command correspond to the fields of the signaling table . The following table describes the parameters in the example: Table 2.77. Descriptions of fields in a SQL command for sending an incremental snapshot signal to the signaling table Item Value Description 1 database.debezium_signal Specifies the fully-qualified name of the signaling table on the source database. 2 ad-hoc-1 The id parameter specifies an arbitrary string that is assigned as the id identifier for the signal request. Use this string to identify logging messages to entries in the signaling table. Debezium does not use this string. Rather, during the snapshot, Debezium generates its own id string as a watermarking signal. 3 execute-snapshot The type parameter specifies the operation that the signal is intended to trigger. 4 data-collections A required component of the data field of a signal that specifies an array of table names or regular expressions to match table names to include in the snapshot. The array lists regular expressions that use the format database.table to match the fully-qualified names of the tables. This format is the same as the one that you use to specify the name of the connector's signaling table . 5 incremental An optional type component of the data field of a signal that specifies the type of snapshot operation to run. Valid values are incremental and blocking . If you do not specify a value, the connector defaults to performing an incremental snapshot. 6 additional-conditions An optional array that specifies a set of additional conditions that the connector evaluates to determine the subset of records to include in a snapshot. Each additional condition is an object with data-collection and filter properties. You can specify different filters for each data collection. * The data-collection property is the fully-qualified name of the data collection that the filter applies to. For more information about the additional-conditions parameter, see Section 2.4.1.6.2, "Running an ad hoc incremental snapshots with additional-conditions " . 2.4.1.6.2. Running an ad hoc incremental snapshots with additional-conditions If you want a snapshot to include only a subset of the content in a table, you can modify the signal request by appending an additional-conditions parameter to the snapshot signal. The SQL query for a typical snapshot takes the following form: SELECT * FROM <tableName> .... By adding an additional-conditions parameter, you append a WHERE condition to the SQL query, as in the following example: SELECT * FROM <data-collection> WHERE <filter> .... The following example shows a SQL query to send an ad hoc incremental snapshot request with an additional condition to the signaling table: INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}'); For example, suppose you have a products table that contains the following columns: id (primary key) color quantity If you want an incremental snapshot of the products table to include only the data items where color=blue , you can use the following SQL statement to trigger the snapshot: INSERT INTO db1.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["db1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "db1.products", "filter": "color=blue"}]}'); The additional-conditions parameter also enables you to pass conditions that are based on more than one column. For example, using the products table from the example, you can submit a query that triggers an incremental snapshot that includes the data of only those items for which color=blue and quantity>10 : INSERT INTO db1.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["db1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "db1.products", "filter": "color=blue AND quantity>10"}]}'); The following example, shows the JSON for an incremental snapshot event that is captured by a connector. Example 2.24. Incremental snapshot event message { "before":null, "after": { "pk":"1", "value":"New data" }, "source": { ... "snapshot":"incremental" 1 }, "op":"r", 2 "ts_ms":"1620393591654", "ts_us":"1620393591654547", "ts_ns":"1620393591654547920", "transaction":null } Table 2.78. Description of fields in an incremental snapshot event message Item Field name Description 1 snapshot Specifies the type of snapshot operation to run. Currently, the only valid options are blocking and incremental . Specifying a type value in the SQL query that you submit to the signaling table is optional. If you do not specify a value, the connector runs an incremental snapshot. 2 op Specifies the event type. The value for snapshot events is r , signifying a READ operation. 2.4.1.6.3. Using the Kafka signaling channel to trigger an incremental snapshot You can send a message to the configured Kafka topic to request the connector to run an ad hoc incremental snapshot. The key of the Kafka message must match the value of the topic.prefix connector configuration option. The value of the message is a JSON object with type and data fields. The signal type is execute-snapshot , and the data field must have the following fields: Table 2.79. Execute snapshot data fields Field Default Value type incremental The type of the snapshot to be executed. Currently Debezium supports the incremental and blocking types. See the section for more details. data-collections N/A An array of comma-separated regular expressions that match the fully-qualified names of tables to include in the snapshot. Specify the names by using the same format as is required for the signal.data.collection configuration option. additional-conditions N/A An optional array of additional conditions that specifies criteria that the connector evaluates to designate a subset of records to include in a snapshot. Each additional condition is an object that specifies the criteria for filtering the data that an ad hoc snapshot captures. You can set the following parameters for each additional condition: data-collection :: The fully-qualified name of the table that the filter applies to. You can apply different filters to each table. filter :: Specifies column values that must be present in a database record for the snapshot to include it, for example, "color='blue'" . The values that you assign to the filter parameter are the same types of values that you might specify in the WHERE clause of SELECT statements when you set the snapshot.select.statement.overrides property for a blocking snapshot. Example 2.25. An execute-snapshot Kafka message Ad hoc incremental snapshots with additional-conditions Debezium uses the additional-conditions field to select a subset of a table's content. Typically, when Debezium runs a snapshot, it runs a SQL query such as: SELECT * FROM <tableName> ... . When the snapshot request includes an additional-conditions property, the data-collection and filter parameters of the property are appended to the SQL query, for example: SELECT * FROM <data-collection> WHERE <filter> ... . For example, given a products table with the columns id (primary key), color , and brand , if you want a snapshot to include only content for which color='blue' , when you request the snapshot, you could add the additional-conditions property to filter the content: Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["db1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "db1.products" ,"filter":"color='blue'"}]}}` You can also use the additional-conditions property to pass conditions based on multiple columns. For example, using the same products table as in the example, if you want a snapshot to include only the content from the products table for which color='blue' , and brand='MyBrand' , you could send the following request: Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["db1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "db1.products" ,"filter":"color='blue' AND brand='MyBrand'"}]}}` 2.4.1.6.4. Stopping an incremental snapshot In some situations, it might be necessary to stop an incremental snapshot. For example, you might realize that snapshot was not configured correctly, or maybe you want to ensure that resources are available for other database operations. You can stop a snapshot that is already running by sending a signal to the signaling table on the source database. You submit a stop snapshot signal to the signaling table by sending it in a SQL INSERT query. The stop-snapshot signal specifies the type of the snapshot operation as incremental , and optionally specifies the tables that you want to omit from the currently running snapshot. After Debezium detects the change in the signaling table, it reads the signal, and stops the incremental snapshot operation if it's in progress. Additional resources You can also stop an incremental snapshot by sending a JSON message to the Kafka signaling topic . Prerequisites Signaling is enabled . A signaling data collection exists on the source database. The signaling data collection is specified in the signal.data.collection property. Using a source signaling channel to stop an incremental snapshot Send a SQL query to stop the ad hoc incremental snapshot to the signaling table: INSERT INTO <signalTable> (id, type, data) values ( '<id>' , 'stop-snapshot', '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":"incremental"}'); For example, INSERT INTO db1.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'stop-snapshot', 3 '{"data-collections": ["db1.table1", "db1.table2"], 4 "type":"incremental"}'); 5 The values of the id , type , and data parameters in the signal command correspond to the fields of the signaling table . The following table describes the parameters in the example: Table 2.80. Descriptions of fields in a SQL command for sending a stop incremental snapshot signal to the signaling table Item Value Description 1 database.debezium_signal Specifies the fully-qualified name of the signaling table on the source database. 2 ad-hoc-1 The id parameter specifies an arbitrary string that is assigned as the id identifier for the signal request. Use this string to identify logging messages to entries in the signaling table. Debezium does not use this string. 3 stop-snapshot Specifies type parameter specifies the operation that the signal is intended to trigger. 4 data-collections An optional component of the data field of a signal that specifies an array of table names or regular expressions to match table names to remove from the snapshot. The array lists regular expressions which match tables by their fully-qualified names in the format database.table If you omit this component from the data field, the signal stops the entire incremental snapshot that is in progress. 5 incremental A required component of the data field of a signal that specifies the type of snapshot operation that is to be stopped. Currently, the only valid option is incremental . If you do not specify a type value, the signal fails to stop the incremental snapshot. 2.4.1.6.5. Using the Kafka signaling channel to stop an incremental snapshot You can send a signal message to the configured Kafka signaling topic to stop an ad hoc incremental snapshot. The key of the Kafka message must match the value of the topic.prefix connector configuration option. The value of the message is a JSON object with type and data fields. The signal type is stop-snapshot , and the data field must have the following fields: Table 2.81. Execute snapshot data fields Field Default Value type incremental The type of the snapshot to be executed. Currently Debezium supports only the incremental type. See the section for more details. data-collections N/A An optional array of comma-separated regular expressions that match the fully-qualified names of the tables an array of table names or regular expressions to match table names to remove from the snapshot. Specify table names by using the format database.table . The following example shows a typical stop-snapshot Kafka message: Key = `test_connector` Value = `{"type":"stop-snapshot","data": {"data-collections": ["db1.table1", "db1.table2"], "type": "INCREMENTAL"}}` 2.4.1.7. Blocking snapshots To provide more flexibility in managing snapshots, Debezium includes a supplementary ad hoc snapshot mechanism, known as a blocking snapshot . Blocking snapshots rely on the Debezium mechanism for sending signals to a Debezium connector . A blocking snapshot behaves just like an initial snapshot , except that you can trigger it at run time. You might want to run a blocking snapshot rather than use the standard initial snapshot process in the following situations: You add a new table and you want to complete the snapshot while the connector is running. You add a large table, and you want the snapshot to complete in less time than is possible with an incremental snapshot. Blocking snapshot process When you run a blocking snapshot, Debezium stops streaming, and then initiates a snapshot of the specified table, following the same process that it uses during an initial snapshot. After the snapshot completes, the streaming is resumed. Configure snapshot You can set the following properties in the data component of a signal: data-collections: to specify which tables must be snapshot additional-conditions: You can specify different filters for different table. The data-collection property is the fully-qualified name of the table for which the filter will be applied. The filter property will have the same value used in the snapshot.select.statement.overrides For example: {"type": "blocking", "data-collections": ["schema1.table1", "schema1.table2"], "additional-conditions": [{"data-collection": "schema1.table1", "filter": "SELECT * FROM [schema1].[table1] WHERE column1 = 0 ORDER BY column2 DESC"}, {"data-collection": "schema1.table2", "filter": "SELECT * FROM [schema1].[table2] WHERE column2 > 0"}]} Possible duplicates A delay might exist between the time that you send the signal to trigger the snapshot, and the time when streaming stops and the snapshot starts. As a result of this delay, after the snapshot completes, the connector might emit some event records that duplicate records captured by the snapshot. 2.4.1.8. Default names of Kafka topics that receive Debezium MySQL change event records By default, the MySQL connector writes change events for all of the INSERT , UPDATE , and DELETE operations that occur in a table to a single Apache Kafka topic that is specific to that table. The connector uses the following convention to name change event topics: topicPrefix.databaseName.tableName Suppose that fulfillment is the topic prefix, inventory is the database name, and the database contains tables named orders , customers , and products . The Debezium MySQL connector emits events to three Kafka topics, one for each table in the database: The following list provides definitions for the components of the default name: topicPrefix The topic prefix as specified by the topic.prefix connector configuration property. schemaName The name of the schema in which the operation occurred. tableName The name of the table in which the operation occurred. The connector applies similar naming conventions to label its internal database schema history topics, schema change topics , and transaction metadata topics . If the default topic name do not meet your requirements, you can configure custom topic names. To configure custom topic names, you specify regular expressions in the logical topic routing SMT. For more information about using the logical topic routing SMT to customize topic naming, see Topic routing . Transaction metadata Debezium can generate events that represent transaction boundaries and that enrich data change event messages. Limits on when Debezium receives transaction metadata Debezium registers and receives metadata only for transactions that occur after you deploy the connector. Metadata for transactions that occur before you deploy the connector is not available. Debezium generates transaction boundary events for the BEGIN and END delimiters in every transaction. Transaction boundary events contain the following fields: status BEGIN or END . id String representation of the unique transaction identifier. ts_ms The time of a transaction boundary event ( BEGIN or END event) at the data source. If the data source does not provide Debezium with the event time, then the field instead represents the time at which Debezium processes the event. event_count (for END events) Total number of events emitted by the transaction. data_collections (for END events) An array of pairs of data_collection and event_count elements that indicates the number of events that the connector emits for changes that originate from a data collection. Example { "status": "BEGIN", "id": "0e4d5dcd-a33b-11ea-80f1-02010a22a99e:10", "ts_ms": 1486500577125, "event_count": null, "data_collections": null } { "status": "END", "id": "0e4d5dcd-a33b-11ea-80f1-02010a22a99e:10", "ts_ms": 1486500577691, "event_count": 2, "data_collections": [ { "data_collection": "s1.a", "event_count": 1 }, { "data_collection": "s2.a", "event_count": 1 } ] } Unless overridden via the topic.transaction option, the connector emits transaction events to the <topic.prefix> .transaction topic. Change data event enrichment When transaction metadata is enabled the data message Envelope is enriched with a new transaction field. This field provides information about every event in the form of a composite of fields: id String representation of unique transaction identifier. total_order The absolute position of the event among all events generated by the transaction. data_collection_order The per-data collection position of the event among all events that were emitted by the transaction. Following is an example of a message: { "before": null, "after": { "pk": "2", "aa": "1" }, "source": { ... }, "op": "c", "ts_ms": "1580390884335", "ts_us": "1580390884335472", "ts_ns": "1580390884335472987", "transaction": { "id": "0e4d5dcd-a33b-11ea-80f1-02010a22a99e:10", "total_order": "1", "data_collection_order": "1" } } 2.4.2. Descriptions of Debezium MySQL connector data change events The Debezium MySQL connector generates a data change event for each row-level INSERT , UPDATE , and DELETE operation. Each event contains a key and a value. The structure of the key and the value depends on the table that was changed. Debezium and Kafka Connect are designed around continuous streams of event messages . However, the structure of these events may change over time, which can be difficult for consumers to handle. To address this, each event contains the schema for its content or, if you are using a schema registry, a schema ID that a consumer can use to obtain the schema from the registry. This makes each event self-contained. The following skeleton JSON shows the basic four parts of a change event. However, how you configure the Kafka Connect converter that you choose to use in your application determines the representation of these four parts in change events. A schema field is in a change event only when you configure the converter to produce it. Likewise, the event key and event payload are in a change event only if you configure a converter to produce it. If you use the JSON converter and you configure it to produce all four basic change event parts, change events have this structure: { "schema": { 1 ... }, "payload": { 2 ... }, "schema": { 3 ... }, "payload": { 4 ... }, } Table 2.82. Overview of change event basic content Item Field name Description 1 schema The first schema field is part of the event key. It specifies a Kafka Connect schema that describes what is in the event key's payload portion. In other words, the first schema field describes the structure of the primary key, or the unique key if the table does not have a primary key, for the table that was changed. It is possible to override the table's primary key by setting the message.key.columns connector configuration property . In this case, the first schema field describes the structure of the key identified by that property. 2 payload The first payload field is part of the event key. It has the structure described by the schema field, and it contains the key for the row that was changed. 3 schema The second schema field is part of the event value. It specifies the Kafka Connect schema that describes what is in the event value's payload portion. In other words, the second schema describes the structure of the row that was changed. Typically, this schema contains nested schemas. 4 payload The second payload field is part of the event value. It has the structure described by the schema field and it contains the actual data for the row that was changed. By default, the connector streams change event records to topics with names that are the same as the event's originating table. See topic names . Warning The MySQL connector ensures that all Kafka Connect schema names adhere to the Avro schema name format . This means that the logical server name must start with a Latin letter or an underscore, that is, a-z, A-Z, or _. Each remaining character in the logical server name and each character in the database and table names must be a Latin letter, a digit, or an underscore, that is, a-z, A-Z, 0-9, or _. If there is an invalid character it is replaced with an underscore character. This can lead to unexpected conflicts if the logical server name, a database name, or a table name contains invalid characters, and the only characters that distinguish names from one another are invalid and thus replaced with underscores. More details are in the following topics: Section 2.4.2.1, "About keys in Debezium MySQL change events" Section 2.4.2.2, "About values in Debezium MySQL change events" 2.4.2.1. About keys in Debezium MySQL change events A change event's key contains the schema for the changed table's key and the changed row's actual key. Both the schema and its corresponding payload contain a field for each column in the changed table's PRIMARY KEY (or unique constraint) at the time the connector created the event. Consider the following customers table, which is followed by an example of a change event key for this table. CREATE TABLE customers ( id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY, first_name VARCHAR(255) NOT NULL, last_name VARCHAR(255) NOT NULL, email VARCHAR(255) NOT NULL UNIQUE KEY ) AUTO_INCREMENT=1001; Every change event that captures a change to the customers table has the same event key schema. For as long as the customers table has the definition, every change event that captures a change to the customers table has the following key structure. In JSON, it looks like this: { "schema": { 1 "type": "struct", "name": "mysql-server-1.inventory.customers.Key", 2 "optional": false, 3 "fields": [ 4 { "field": "id", "type": "int32", "optional": false } ] }, "payload": { 5 "id": 1001 } } Table 2.83. Description of change event key Item Field name Description 1 schema The schema portion of the key specifies a Kafka Connect schema that describes what is in the key's payload portion. 2 mysql-server-1.inventory.customers.Key Name of the schema that defines the structure of the key's payload. This schema describes the structure of the primary key for the table that was changed. Key schema names have the format connector-name . database-name . table-name . Key . In this example: mysql-server-1 is the name of the connector that generated this event. inventory is the database that contains the table that was changed. customers is the table that was updated. 3 optional Indicates whether the event key must contain a value in its payload field. In this example, a value in the key's payload is required. A value in the key's payload field is optional when a table does not have a primary key. 4 fields Specifies each field that is expected in the payload , including each field's name, type, and whether it is required. 5 payload Contains the key for the row for which this change event was generated. In this example, the key, contains a single id field whose value is 1001 . 2.4.2.2. About values in Debezium MySQL change events The value in a change event is a bit more complicated than the key. Like the key, the value has a schema section and a payload section. The schema section contains the schema that describes the Envelope structure of the payload section, including its nested fields. Change events for operations that create, update or delete data all have a value payload with an envelope structure. Consider the same sample table that was used to show an example of a change event key: CREATE TABLE customers ( id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY, first_name VARCHAR(255) NOT NULL, last_name VARCHAR(255) NOT NULL, email VARCHAR(255) NOT NULL UNIQUE KEY ) AUTO_INCREMENT=1001; The value portion of a change event for a change to this table is described for: create events update events Primary key updates delete events Tombstone events truncate events create events The following example shows the value portion of a change event that the connector generates for an operation that creates data in the customers table: { "schema": { 1 "type": "struct", "fields": [ { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "id" }, { "type": "string", "optional": false, "field": "first_name" }, { "type": "string", "optional": false, "field": "last_name" }, { "type": "string", "optional": false, "field": "email" } ], "optional": true, "name": "mysql-server-1.inventory.customers.Value", 2 "field": "before" }, { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "id" }, { "type": "string", "optional": false, "field": "first_name" }, { "type": "string", "optional": false, "field": "last_name" }, { "type": "string", "optional": false, "field": "email" } ], "optional": true, "name": "mysql-server-1.inventory.customers.Value", "field": "after" }, { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "version" }, { "type": "string", "optional": false, "field": "connector" }, { "type": "string", "optional": false, "field": "name" }, { "type": "int64", "optional": false, "field": "ts_ms" }, { "type": "int64", "optional": false, "field": "ts_us" }, { "type": "int64", "optional": false, "field": "ts_ns" }, { "type": "boolean", "optional": true, "default": false, "field": "snapshot" }, { "type": "string", "optional": false, "field": "db" }, { "type": "string", "optional": true, "field": "table" }, { "type": "int64", "optional": false, "field": "server_id" }, { "type": "string", "optional": true, "field": "gtid" }, { "type": "string", "optional": false, "field": "file" }, { "type": "int64", "optional": false, "field": "pos" }, { "type": "int32", "optional": false, "field": "row" }, { "type": "int64", "optional": true, "field": "thread" }, { "type": "string", "optional": true, "field": "query" } ], "optional": false, "name": "io.debezium.connector.mysql.Source", 3 "field": "source" }, { "type": "string", "optional": false, "field": "op" }, { "type": "int64", "optional": true, "field": "ts_ms" }, { "type": "int64", "optional": true, "field": "ts_us" }, { "type": "int64", "optional": true, "field": "ts_ns" } ], "optional": false, "name": "mysql-server-1.inventory.customers.Envelope" 4 }, "payload": { 5 "op": "c", 6 "ts_ms": 1465491411815, 7 "ts_us": 1465491411815437, 8 "ts_ns": 1465491411815437158, 9 "before": null, 10 "after": { 11 "id": 1004, "first_name": "Anne", "last_name": "Kretchmar", "email": "annek@noanswer.org" }, "source": { 12 "version": "2.7.3.Final", "connector": "mysql", "name": "mysql-server-1", "ts_ms": 0, "ts_us": 0, "ts_ns": 0, "snapshot": false, "db": "inventory", "table": "customers", "server_id": 0, "gtid": null, "file": "mysql-bin.000003", "pos": 154, "row": 0, "thread": 7, "query": "INSERT INTO customers (first_name, last_name, email) VALUES ('Anne', 'Kretchmar', 'annek@noanswer.org')" } } } Table 2.84. Descriptions of create event value fields Item Field name Description 1 schema The value's schema, which describes the structure of the value's payload. A change event's value schema is the same in every change event that the connector generates for a particular table. 2 name In the schema section, each name field specifies the schema for a field in the value's payload. mysql-server-1.inventory.customers.Value is the schema for the payload's before and after fields. This schema is specific to the customers table. Names of schemas for before and after fields are of the form logicalName . tableName .Value , which ensures that the schema name is unique in the database. This means that when using the Avro converter , the resulting Avro schema for each table in each logical source has its own evolution and history. 3 name io.debezium.connector.mysql.Source is the schema for the payload's source field. This schema is specific to the MySQL connector. The connector uses it for all events that it generates. 4 name mysql-server-1.inventory.customers.Envelope is the schema for the overall structure of the payload, where mysql-server-1 is the connector name, inventory is the database, and customers is the table. 5 payload The value's actual data. This is the information that the change event is providing. It may appear that the JSON representations of the events are much larger than the rows they describe. This is because the JSON representation must include the schema and the payload portions of the message. However, by using the Avro converter , you can significantly decrease the size of the messages that the connector streams to Kafka topics. 6 op Mandatory string that describes the type of operation that caused the connector to generate the event. In this example, c indicates that the operation created a row. Valid values are: c = create u = update d = delete r = read (applies to only snapshots) 7 ts_ms , ts_us , ts_ns Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. 8 before An optional field that specifies the state of the row before the event occurred. When the op field is c for create, as it is in this example, the before field is null since this change event is for new content. 9 after An optional field that specifies the state of the row after the event occurred. In this example, the after field contains the values of the new row's id , first_name , last_name , and email columns. 10 source Mandatory field that describes the source metadata for the event. This field contains information that you can use to compare this event with other events, with regard to the origin of the events, the order in which the events occurred, and whether events were part of the same transaction. The source metadata includes: Debezium version Connector name binlog name where the event was recorded binlog position Row within the event If the event was part of a snapshot Name of the database and table that contain the new row ID of the MySQL thread that created the event (non-snapshot only) MySQL server ID (if available) Timestamp for when the change was made in the database update events The value of a change event for an update in the sample customers table has the same schema as a create event for that table. Likewise, the event value's payload has the same structure. However, the event value payload contains different values in an update event. Here is an example of a change event value in an event that the connector generates for an update in the customers table: { "schema": { ... }, "payload": { "before": { 1 "id": 1004, "first_name": "Anne", "last_name": "Kretchmar", "email": "annek@noanswer.org" }, "after": { 2 "id": 1004, "first_name": "Anne Marie", "last_name": "Kretchmar", "email": "annek@noanswer.org" }, "source": { 3 "version": "2.7.3.Final", "name": "mysql-server-1", "connector": "mysql", "name": "mysql-server-1", "ts_ms": 1465581029100, "ts_ms": 1465581029100000, "ts_ms": 1465581029100000000, "snapshot": false, "db": "inventory", "table": "customers", "server_id": 223344, "gtid": null, "file": "mysql-bin.000003", "pos": 484, "row": 0, "thread": 7, "query": "UPDATE customers SET first_name='Anne Marie' WHERE id=1004" }, "op": "u", 4 "ts_ms": 1465581029523, 5 "ts_ms": 1465581029523758, 6 "ts_ms": 1465581029523758914 7 } } Table 2.85. Descriptions of update event value fields Item Field name Description 1 before An optional field that specifies the state of the row before the event occurred. In an update event value, the before field contains a field for each table column and the value that was in that column before the database commit. In this example, the first_name value is Anne. 2 after An optional field that specifies the state of the row after the event occurred. You can compare the before and after structures to determine what the update to this row was. In the example, the first_name value is now Anne Marie . 3 source Mandatory field that describes the source metadata for the event. The source field structure has the same fields as in a create event, but some values are different, for example, the sample update event is from a different position in the binlog. The source metadata includes: Debezium version Connector name binlog name where the event was recorded binlog position Row within the event If the event was part of a snapshot Name of the database and table that contain the updated row ID of the MySQL thread that created the event (non-snapshot only) MySQL server ID (if available) Timestamp for when the change was made in the database 4 op Mandatory string that describes the type of operation. In an update event value, the op field value is u , signifying that this row changed because of an update. 5 ts_ms Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. 6 ts_us Optional field that displays the time at which the connector processed the event, in microseconds. The time is based on the system clock in the JVM running the Kafka Connect task. 7 ts_ns Optional field that displays the time at which the connector processed the event, in nanoseconds. The time is based on the system clock in the JVM running the Kafka Connect task. Note Updating the columns for a row's primary/unique key changes the value of the row's key. When a key changes, Debezium outputs three events: a DELETE event and a tombstone event with the old key for the row, followed by an event with the new key for the row. Details are in the section. Primary key updates An UPDATE operation that changes a row's primary key field(s) is known as a primary key change. For a primary key change, in place of an UPDATE event record, the connector emits a DELETE event record for the old key and a CREATE event record for the new (updated) key. These events have the usual structure and content, and in addition, each one has a message header related to the primary key change: The DELETE event record has __debezium.newkey as a message header. The value of this header is the new primary key for the updated row. The CREATE event record has __debezium.oldkey as a message header. The value of this header is the (old) primary key that the updated row had. delete events The value in a delete change event has the same schema portion as create and update events for the same table. The payload portion in a delete event for the sample customers table looks like this: { "schema": { ... }, "payload": { "before": { 1 "id": 1004, "first_name": "Anne Marie", "last_name": "Kretchmar", "email": "annek@noanswer.org" }, "after": null, 2 "source": { 3 "version": "2.7.3.Final", "connector": "mysql", "name": "mysql-server-1", "ts_ms": 1465581902300, "ts_us": 1465581902300000, "ts_ns": 1465581902300000000, "snapshot": false, "db": "inventory", "table": "customers", "server_id": 223344, "gtid": null, "file": "mysql-bin.000003", "pos": 805, "row": 0, "thread": 7, "query": "DELETE FROM customers WHERE id=1004" }, "op": "d", 4 "ts_ms": 1465581902461, 5 "ts_us": 1465581902461842, 6 "ts_ns": 1465581902461842579 7 } } Table 2.86. Descriptions of delete event value fields Item Field name Description 1 before Optional field that specifies the state of the row before the event occurred. In a delete event value, the before field contains the values that were in the row before it was deleted with the database commit. 2 after Optional field that specifies the state of the row after the event occurred. In a delete event value, the after field is null , signifying that the row no longer exists. 3 source Mandatory field that describes the source metadata for the event. In a delete event value, the source field structure is the same as for create and update events for the same table. Many source field values are also the same. In a delete event value, the ts_ms and pos field values, as well as other values, might have changed. But the source field in a delete event value provides the same metadata: Debezium version Connector name binlog name where the event was recorded binlog position Row within the event If the event was part of a snapshot Name of the database and table that contain the updated row ID of the MySQL thread that created the event (non-snapshot only) MySQL server ID (if available) Timestamp for when the change was made in the database 4 op Mandatory string that describes the type of operation. The op field value is d , signifying that this row was deleted. 5 ts_ms Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. 6 ts_us Optional field that displays the time at which the connector processed the event, in microseconds. The time is based on the system clock in the JVM running the Kafka Connect task. 7 ts_ns Optional field that displays the time at which the connector processed the event, in nanoseconds. The time is based on the system clock in the JVM running the Kafka Connect task. A delete change event record provides a consumer with the information it needs to process the removal of this row. The old values are included because some consumers might require them in order to properly handle the removal. MySQL connector events are designed to work with Kafka log compaction . Log compaction enables removal of some older messages as long as at least the most recent message for every key is kept. This lets Kafka reclaim storage space while ensuring that the topic contains a complete data set and can be used for reloading key-based state. Tombstone events When a row is deleted, the delete event value still works with log compaction, because Kafka can remove all earlier messages that have that same key. However, for Kafka to remove all messages that have that same key, the message value must be null . To make this possible, after the Debezium MySQL connector emits a delete event, the connector emits a special tombstone event that has the same key but a null value. truncate events A truncate change event signals that a table has been truncated. The message key of a truncate event is null . The message value resembles the following example: { "schema": { ... }, "payload": { "source": { 1 "version": "2.7.3.Final", "name": "mysql-server-1", "connector": "mysql", "name": "mysql-server-1", "ts_ms": 1465581029100, "ts_us": 1465581029100000, "ts_ns": 1465581029100000000, "snapshot": false, "db": "inventory", "table": "customers", "server_id": 223344, "gtid": null, "file": "mysql-bin.000003", "pos": 484, "row": 0, "thread": 7, "query": "UPDATE customers SET first_name='Anne Marie' WHERE id=1004" }, "op": "t", 2 "ts_ms": 1465581029523, 3 "ts_us": 1465581029523468, 4 "ts_ns": 1465581029523468471 5 } } Table 2.87. Descriptions of truncate event value fields Item Field name Description 1 source Mandatory field that describes the source metadata for the event. In a truncate event value, the source field structure is the same as for create , update , and delete events for the same table, provides this metadata: Debezium version Connector type and name Binlog name where the event was recorded Binlog position Row within the event If the event was part of a snapshot Name of the database and table ID of the MySQL thread that truncated the event (non-snapshot only) MySQL server ID (if available) Timestamp for when the change was made in the database 2 op Mandatory string that describes the type of operation. The op field value is t , signifying that this table was truncated. 3 ts_ms Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. 4 ts_us Optional field that displays the time at which the connector processed the event, in microseconds. The time is based on the system clock in the JVM running the Kafka Connect task. 5 ts_ns Optional field that displays the time at which the connector processed the event, in nanoseconds. The time is based on the system clock in the JVM running the Kafka Connect task. In case a single TRUNCATE statement applies to multiple tables, one truncate change event record for each truncated table will be emitted. Note A truncate event represents a change that applies to an entire table, and it does not have a message key. In topics that span multiple partition, the order of change events that apply to an entire table is is not guaranteed. That is, there is no ordering guarantee for ( create , update , etc.), or for the truncate events for that table. When a consumer reads events from different partition, it might read an update event for a table from one partition only after it reads a truncate event for the same table from a second partition. 2.4.3. How Debezium MySQL connectors map data types The Debezium MySQL connector represents changes to rows with events that are structured like the table in which the row exists. The event contains a field for each column value. The MySQL data type of that column dictates how Debezium represents the value in the event. Columns that store strings are defined in MySQL with a character set and collation. The MySQL connector uses the column's character set when reading the binary representation of the column values in the binlog events. The connector can map MySQL data types to both literal and semantic types. Literal type : how the value is represented using Kafka Connect schema types. Semantic type : how the Kafka Connect schema captures the meaning of the field (schema name). If the default data type conversions do not meet your needs, you can create a custom converter for the connector. Details are in the following sections: Basic types Temporal types Decimal types Boolean values Spatial types Basic types The following table shows how the connector maps basic MySQL data types. Table 2.88. Descriptions of basic type mappings MySQL type Literal type Semantic type BOOLEAN, BOOL BOOLEAN n/a BIT(1) BOOLEAN n/a BIT(>1) BYTES io.debezium.data.Bits The length schema parameter contains an integer that represents the number of bits. The byte[] contains the bits in little-endian form and is sized to contain the specified number of bits. For example, where n is bits: numBytes = n/8 + (n%8== 0 ? 0 : 1) TINYINT INT16 n/a SMALLINT[(M)] INT16 n/a MEDIUMINT[(M)] INT32 n/a INT, INTEGER[(M)] INT32 n/a BIGINT[(M)] INT64 n/a REAL[(M,D)] FLOAT32 n/a FLOAT[(P)] FLOAT32 or FLOAT64 The precision is used only to determine storage size. A precision P from 0 to 23 results in a 4-byte single-precision FLOAT32 column. A precision P from 24 to 53 results in an 8-byte double-precision FLOAT64 column. DOUBLE[(M,D)] FLOAT64 n/a CHAR(M)] STRING n/a VARCHAR(M)] STRING n/a BINARY(M)] BYTES or STRING n/a Either the raw bytes (the default), a base64-encoded String, or a base64-url-safe-encoded String, or a hex-encoded String, based on the binary.handling.mode connector configuration property setting. VARBINARY(M)] BYTES or STRING n/a Either the raw bytes (the default), a base64-encoded String, or a base64-url-safe-encoded String, or a hex-encoded String, based on the binary.handling.mode connector configuration property setting. TINYBLOB BYTES or STRING n/a Either the raw bytes (the default), a base64-encoded String, or a base64-url-safe-encoded String, or a hex-encoded String, based on the binary.handling.mode connector configuration property setting. TINYTEXT STRING n/a BLOB BYTES or STRING n/a Either the raw bytes (the default), a base64-encoded String, or a base64-url-safe-encoded String, or a hex-encoded String, based on the binary.handling.mode connector configuration property setting. Only values with a size of up to 2GB are supported. It is recommended to externalize large column values, using the claim check pattern. TEXT STRING n/a Only values with a size of up to 2GB are supported. It is recommended to externalize large column values, using the claim check pattern. MEDIUMBLOB BYTES or STRING n/a Either the raw bytes (the default), a base64-encoded String, or a base64-url-safe-encoded String, or a hex-encoded String, based on the binary.handling.mode connector configuration property setting. MEDIUMTEXT STRING n/a LONGBLOB BYTES or STRING n/a Either the raw bytes (the default), a base64-encoded String, or a base64-url-safe-encoded String, or a hex-encoded String, based on the binary.handling.mode connector configuration property setting. Only values with a size of up to 2GB are supported. It is recommended to externalize large column values, using the claim check pattern. LONGTEXT STRING n/a Only values with a size of up to 2GB are supported. It is recommended to externalize large column values, using the claim check pattern. JSON STRING io.debezium.data.Json Contains the string representation of a JSON document, array, or scalar. ENUM STRING io.debezium.data.Enum The allowed schema parameter contains the comma-separated list of allowed values. SET STRING io.debezium.data.EnumSet The allowed schema parameter contains the comma-separated list of allowed values. YEAR[(2|4)] INT32 io.debezium.time.Year TIMESTAMP[(M)] STRING io.debezium.time.ZonedTimestamp In ISO 8601 format with microsecond precision. MySQL allows M to be in the range of 0-6 . . Temporal types Excluding the TIMESTAMP data type, MySQL temporal types depend on the value of the time.precision.mode connector configuration property. For TIMESTAMP columns whose default value is specified as CURRENT_TIMESTAMP or NOW , the value 1970-01-01 00:00:00 is used as the default value in the Kafka Connect schema. MySQL allows zero-values for DATE , DATETIME , and TIMESTAMP columns because zero-values are sometimes preferred over null values. The MySQL connector represents zero-values as null values when the column definition allows null values, or as the epoch day when the column does not allow null values. Temporal values without time zones The DATETIME type represents a local date and time such as "2018-01-13 09:48:27". As you can see, there is no time zone information. Such columns are converted into epoch milliseconds or microseconds based on the column's precision by using UTC. The TIMESTAMP type represents a timestamp without time zone information. It is converted by MySQL from the server (or session's) current time zone into UTC when writing and from UTC into the server (or session's) current time zone when reading back the value. For example: DATETIME with a value of 2018-06-20 06:37:03 becomes 1529476623000 . TIMESTAMP with a value of 2018-06-20 06:37:03 becomes 2018-06-20T13:37:03Z . Such columns are converted into an equivalent io.debezium.time.ZonedTimestamp in UTC based on the server (or session's) current time zone. The time zone will be queried from the server by default. The time zone of the JVM running Kafka Connect and Debezium does not affect these conversions. More details about properties related to temporal values are in the documentation for MySQL connector configuration properties . time.precision.mode=adaptive_time_microseconds(default) The MySQL connector determines the literal type and semantic type based on the column's data type definition so that events represent exactly the values in the database. All time fields are in microseconds. Only positive TIME field values in the range of 00:00:00.000000 to 23:59:59.999999 can be captured correctly. Table 2.89. Mappings when time.precision.mode=adaptive_time_microseconds MySQL type Literal type Semantic type DATE INT32 io.debezium.time.Date Represents the number of days since the epoch. TIME[(M)] INT64 io.debezium.time.MicroTime Represents the time value in microseconds and does not include time zone information. MySQL allows M to be in the range of 0-6 . DATETIME, DATETIME(0), DATETIME(1), DATETIME(2), DATETIME(3) INT64 io.debezium.time.Timestamp Represents the number of milliseconds past the epoch and does not include time zone information. DATETIME(4), DATETIME(5), DATETIME(6) INT64 io.debezium.time.MicroTimestamp Represents the number of microseconds past the epoch and does not include time zone information. time.precision.mode=connect The MySQL connector uses defined Kafka Connect logical types. This approach is less precise than the default approach and the events could be less precise if the database column has a fractional second precision value of greater than 3 . Values in only the range of 00:00:00.000 to 23:59:59.999 can be handled. Set time.precision.mode=connect only if you can ensure that the TIME values in your tables never exceed the supported ranges. The connect setting is expected to be removed in a future version of Debezium. Table 2.90. Mappings when time.precision.mode=connect MySQL type Literal type Semantic type DATE INT32 org.apache.kafka.connect.data.Date Represents the number of days since the epoch. TIME[(M)] INT64 org.apache.kafka.connect.data.Time Represents the time value in microseconds since midnight and does not include time zone information. DATETIME[(M)] INT64 org.apache.kafka.connect.data.Timestamp Represents the number of milliseconds since the epoch, and does not include time zone information. Decimal types Debezium connectors handle decimals according to the setting of the decimal.handling.mode connector configuration property. decimal.handling.mode=precise Table 2.91. Mappings when decimal.handling.mode=precise MySQL type Literal type Semantic type NUMERIC[(M[,D])] BYTES org.apache.kafka.connect.data.Decimal The scale schema parameter contains an integer that represents how many digits the decimal point shifted. DECIMAL[(M[,D])] BYTES org.apache.kafka.connect.data.Decimal The scale schema parameter contains an integer that represents how many digits the decimal point shifted. decimal.handling.mode=double Table 2.92. Mappings when decimal.handling.mode=double MySQL type Literal type Semantic type NUMERIC[(M[,D])] FLOAT64 n/a DECIMAL[(M[,D])] FLOAT64 n/a decimal.handling.mode=string Table 2.93. Mappings when decimal.handling.mode=string MySQL type Literal type Semantic type NUMERIC[(M[,D])] STRING n/a DECIMAL[(M[,D])] STRING n/a Boolean values MySQL handles the BOOLEAN value internally in a specific way. The BOOLEAN column is internally mapped to the TINYINT(1) data type. When the table is created during streaming then it uses proper BOOLEAN mapping as Debezium receives the original DDL. During snapshots, Debezium executes SHOW CREATE TABLE to obtain table definitions that return TINYINT(1) for both BOOLEAN and TINYINT(1) columns. Debezium then has no way to obtain the original type mapping and so maps to TINYINT(1) . To enable you to convert source columns to Boolean data types, Debezium provides a TinyIntOneToBooleanConverter custom converter that you can use in one of the following ways: Map all TINYINT(1) or TINYINT(1) UNSIGNED columns to BOOLEAN types. Enumerate a subset of columns by using a comma-separated list of regular expressions. To use this type of conversion, you must set the converters configuration property with the selector parameter, as shown in the following example: NOTE: In some cases, the database may not show the length of tinyint unsigned when the snapshot executes SHOW CREATE TABLE , which means this converter doesn't work. The new option length.checker can solve this issue, the default value is true . Disable the length.checker and specify the columns that need to be converted to selected property instead of converting all columns based on type, as shown in the following example: Spatial types Currently, the Debezium MySQL connector supports the following spatial data types. Table 2.94. Description of spatial type mappings MySQL type Literal type Semantic type GEOMETRY, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, GEOMETRYCOLLECTION STRUCT io.debezium.data.geometry.Geometry Contains a structure with two fields: srid (INT32 : spatial reference system ID that defines the type of geometry object stored in the structure wkb (BYTES) : binary representation of the geometry object encoded in the Well-Known-Binary (wkb) format. See the Open Geospatial Consortium for more details. 2.4.4. Custom converters for mapping MySQL data to alternative data types By default, the Debezium MySQL connector provides several CustomConverter implementations for MySQL data types. These custom converters provide alternative mappings for specific data types based on the connector configuration. To add a CustomConverter to the connector, follow the instructions in the Custom Converters documentation . TINYINT(1) to Boolean By default, during a connector snapshot, the Debezium MySQL connector obtains column types from the JDBC driver, which assigns the TINYINT(1) type to BOOLEAN columns. Debezium then uses these JDBC column types to define the schema for the snapshot events. After the connector transitions from the snapshot to the streaming phase, the change event schema that results from the default mapping can lead to inconsistent mappings for BOOLEAN columns. To help ensure that MySQL emits BOOLEAN columns uniformly, you can apply the custom TinyIntOneToBooleanConverter , as shown in the following configuration example. Example: TinyIntOneToBooleanConverter configuration In the preceding example, the selector and length.checker properties are optional. By default, the converter checks that TINYINT data types conform to a length of 1 . If length.checker to false , the converter does not explicitly confirm that the TINYINT data type conforms to a length of 1 . The selector designates the tables or columns to convert, based on the supplied regular expression. If you omit the selector property, the converter maps all TINYINT columns to logical BOOL field types. If you do not configure a selector option, and you want to map TINYINT columns to TINYINT(1) , omit the length.checker property, or set its value to true . JDBC sink data types If you integrate the Debezium JDBC sink connector with a Debezium MySQL source connector, the MySQL connector emits some column attributes differently during the snapshot and streaming phases. For the JDBC sink connector to consistently consume changes from both the snapshot and streaming phase, you must include the JdbcSinkDataTypesConverter converter as part of the MySQL source connector configuration, as shown in the following example: Example: JdbcSinkDataTypesConverter configuration In the preceding example, the selector.* and treat.real.as.double configuration properties are optional. The selector.* properties specify comma-separated lists of regular expressions that specify which tables and columns that the converter applies to. By default, the converter applies the following rules apply to all Boolean, real, and string-based column data types, across all tables: BOOLEAN data types are always emitted as INT16 logical types, with 1 representing true and 0 representing false REAL data types are always emitted as FLOAT64 logical types. String-based columns always include the __debezium.source.column.character_set schema parameter that contains the column's character set. For each data type, you can configure a selector rule to override the default scope and apply the selector to specific tables and columns only. For example, to set the scope of the Boolean converter, add the following rule to the connector configuration, as in the preceding example: converters.jdbc-sink.selector.boolean=.*.MY_TABLE.BOOL_COL 2.4.5. Setting up MySQL to run a Debezium connector Some MySQL setup tasks are required before you can install and run a Debezium connector. Details are in the following sections: Section 2.4.5.1, "Creating a MySQL user for a Debezium connector" Section 2.4.5.2, "Enabling the MySQL binlog for Debezium" Section 2.4.5.3, "Enabling MySQL Global Transaction Identifiers for Debezium" Section 2.4.5.4, "Configuring MySQL session timesouts for Debezium" Section 2.4.5.5, "Enabling query log events for Debezium MySQL connectors" 2.4.5.1. Creating a MySQL user for a Debezium connector A Debezium MySQL connector requires a MySQL user account. This MySQL user must have appropriate permissions on all databases for which the Debezium MySQL connector captures changes. Prerequisites A MySQL server. Basic knowledge of SQL commands. Procedure Create the MySQL user: mysql> CREATE USER 'user'@'localhost' IDENTIFIED BY 'password'; Grant the required permissions to the user: mysql> GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'user' IDENTIFIED BY 'password'; For a description of the required permissions, see Table 2.95, "Descriptions of user permissions" . Important If using a hosted option such as Amazon RDS or Amazon Aurora that does not allow a global read lock, table-level locks are used to create the consistent snapshot . In this case, you need to also grant LOCK TABLES permissions to the user that you create. See snapshots for more details. Finalize the user's permissions: mysql> FLUSH PRIVILEGES; Table 2.95. Descriptions of user permissions Keyword Description SELECT Enables the connector to select rows from tables in databases. This is used only when performing a snapshot. RELOAD Enables the connector the use of the FLUSH statement to clear or reload internal caches, flush tables, or acquire locks. This is used only when performing a snapshot. SHOW DATABASES Enables the connector to see database names by issuing the SHOW DATABASE statement. This is used only when performing a snapshot. REPLICATION SLAVE Enables the connector to connect to and read the MySQL server binlog. REPLICATION CLIENT Enables the connector the use of the following statements: SHOW MASTER STATUS SHOW SLAVE STATUS SHOW BINARY LOGS The connector always requires this. ON Identifies the database to which the permissions apply. TO 'user' Specifies the user to grant the permissions to. IDENTIFIED BY 'password' Specifies the user's MySQL password. 2.4.5.2. Enabling the MySQL binlog for Debezium You must enable binary logging for MySQL replication. The binary logs record transaction updates in a way that enables replicas to propagate those changes. Prerequisites A MySQL server. Appropriate MySQL user privileges. Procedure Check whether the log-bin option is enabled: If the binlog is OFF , add the properties in the following table to the configuration file for the MySQL server: server-id = 223344 # Querying variable is called server_id, e.g. SELECT variable_value FROM information_schema.global_variables WHERE variable_name='server_id'; log_bin = mysql-bin binlog_format = ROW binlog_row_image = FULL binlog_expire_logs_seconds = 864000 Confirm your changes by checking the binlog status once more: If you run MySQL on Amazon RDS, you must enable automated backups for your database instance for binary logging to occur. If the database instance is not configured to perform automated backups, the binlog is disabled, even if you apply the settings described in the steps. Table 2.96. Descriptions of MySQL binlog configuration properties Property Description server-id The value for the server-id must be unique for each server and replication client in the MySQL cluster. log_bin The value of log_bin is the base name of the sequence of binlog files. binlog_format The binlog-format must be set to ROW or row . binlog_row_image The binlog_row_image must be set to FULL or full . binlog_expire_logs_seconds The binlog_expire_logs_seconds corresponds to deprecated system variable expire_logs_days . This is the number of seconds for automatic binlog file removal. The default value is 2592000 , which equals 30 days. Set the value to match the needs of your environment. For more information, see MySQL purges binlog files . 2.4.5.3. Enabling MySQL Global Transaction Identifiers for Debezium Global transaction identifiers (GTIDs) uniquely identify transactions that occur on a server within a cluster. Though not required for a Debezium MySQL connector, using GTIDs simplifies replication and enables you to more easily confirm if primary and replica servers are consistent. GTIDs are available in MySQL 5.6.5 and later. See the MySQL documentation for more details. Prerequisites A MySQL server. Basic knowledge of SQL commands. Access to the MySQL configuration file. Procedure Enable gtid_mode : mysql> gtid_mode=ON Enable enforce_gtid_consistency : mysql> enforce_gtid_consistency=ON Confirm the changes: mysql> show global variables like '%GTID%'; Result +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | enforce_gtid_consistency | ON | | gtid_mode | ON | +--------------------------+-------+ Table 2.97. Descriptions of GTID options Option Description gtid_mode Boolean that specifies whether GTID mode of the MySQL server is enabled or not. ON = enabled OFF = disabled enforce_gtid_consistency Boolean that specifies whether the server enforces GTID consistency by allowing the execution of statements that can be logged in a transactionally safe manner. Required when using GTIDs. ON = enabled OFF = disabled 2.4.5.4. Configuring MySQL session timesouts for Debezium When an initial consistent snapshot is made for large databases, your established connection could timeout while the tables are being read. You can prevent this behavior by configuring interactive_timeout and wait_timeout in your MySQL configuration file. Prerequisites A MySQL server. Basic knowledge of SQL commands. Access to the MySQL configuration file. Procedure Configure interactive_timeout : mysql> interactive_timeout=<duration-in-seconds> Configure wait_timeout : mysql> wait_timeout=<duration-in-seconds> Table 2.98. Descriptions of MySQL session timeout options Option Description interactive_timeout The number of seconds the server waits for activity on an interactive connection before closing it. For more information see the: wait_timeout The number of seconds that the server waits for activity on a non-interactive connection before closing it. 2.4.5.5. Enabling query log events for Debezium MySQL connectors You might want to see the original SQL statement for each binlog event. Enabling the binlog_rows_query_log_events option in the MySQL configuration file allows you to do this. This option is available in MySQL 5.6 and later. Prerequisites A MySQL server. Basic knowledge of SQL commands. Access to the MySQL configuration file. Procedure Enable binlog_rows_query_log_events in MySQL: mysql> binlog_rows_query_log_events=ON binlog_rows_query_log_events is set to a value that enables/disables support for including the original SQL statement in the binlog entry. ON = enabled OFF = disabled 2.4.5.6. validate binlog row value options for Debezium MySQL connectors Verify the setting of the binlog_row_value_options variable in the database. To enable the connector to consume UPDATE events, this variable must be set to a value other than PARTIAL_JSON . Prerequisites A MySQL server. Basic knowledge of SQL commands. Access to the MySQL configuration file. Procedure Check current variable value mysql> show global variables where variable_name = 'binlog_row_value_options'; Result +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | binlog_row_value_options | | +--------------------------+-------+ If the value of the variable is set to PARTIAL_JSON , run the following command to unset it: mysql> set @@global.binlog_row_value_options="" ; 2.4.6. Deployment of Debezium MySQL connectors You can use either of the following methods to deploy a Debezium MySQL connector: Use Streams for Apache Kafka to automatically create an image that includes the connector plug-in . This is the preferred method. Build a custom Kafka Connect container image from a Dockerfile . Additional resources Section 2.4.6.5, "Descriptions of Debezium MySQL connector configuration properties" 2.4.6.1. MySQL connector deployment using Streams for Apache Kafka Beginning with Debezium 1.7, the preferred method for deploying a Debezium connector is to use Streams for Apache Kafka to build a Kafka Connect container image that includes the connector plug-in. During the deployment process, you create and use the following custom resources (CRs): A KafkaConnect CR that defines your Kafka Connect instance and includes information about the connector artifacts needs to include in the image. A KafkaConnector CR that provides details that include information the connector uses to access the source database. After Streams for Apache Kafka starts the Kafka Connect pod, you start the connector by applying the KafkaConnector CR. In the build specification for the Kafka Connect image, you can specify the connectors that are available to deploy. For each connector plug-in, you can also specify other components that you want to make available for deployment. For example, you can add Apicurio Registry artifacts, or the Debezium scripting component. When Streams for Apache Kafka builds the Kafka Connect image, it downloads the specified artifacts, and incorporates them into the image. The spec.build.output parameter in the KafkaConnect CR specifies where to store the resulting Kafka Connect container image. Container images can be stored in a Docker registry, or in an OpenShift ImageStream. To store images in an ImageStream, you must create the ImageStream before you deploy Kafka Connect. ImageStreams are not created automatically. Note If you use a KafkaConnect resource to create a cluster, afterwards you cannot use the Kafka Connect REST API to create or update connectors. You can still use the REST API to retrieve information. Additional resources Configuring Kafka Connect in Deploying and Managing Streams for Apache Kafka on OpenShift. Building a new container image automatically in Deploying and Managing Streams for Apache Kafka on OpenShift. 2.4.6.2. Using Streams for Apache Kafka to deploy a Debezium MySQL connector With earlier versions of Streams for Apache Kafka, to deploy Debezium connectors on OpenShift, you were required to first build a Kafka Connect image for the connector. The current preferred method for deploying connectors on OpenShift is to use a build configuration in Streams for Apache Kafka to automatically build a Kafka Connect container image that includes the Debezium connector plug-ins that you want to use. During the build process, the Streams for Apache Kafka Operator transforms input parameters in a KafkaConnect custom resource, including Debezium connector definitions, into a Kafka Connect container image. The build downloads the necessary artifacts from the Red Hat Maven repository or another configured HTTP server. The newly created container is pushed to the container registry that is specified in .spec.build.output , and is used to deploy a Kafka Connect cluster. After Streams for Apache Kafka builds the Kafka Connect image, you create KafkaConnector custom resources to start the connectors that are included in the build. Prerequisites You have access to an OpenShift cluster on which the cluster Operator is installed. The Streams for Apache Kafka Operator is running. An Apache Kafka cluster is deployed as documented in Deploying and Managing Streams for Apache Kafka on OpenShift . Kafka Connect is deployed on Streams for Apache Kafka You have a Red Hat build of Debezium license. The OpenShift oc CLI client is installed or you have access to the OpenShift Container Platform web console. Depending on how you intend to store the Kafka Connect build image, you need registry permissions or you must create an ImageStream resource: To store the build image in an image registry, such as Red Hat Quay.io or Docker Hub An account and permissions to create and manage images in the registry. To store the build image as a native OpenShift ImageStream An ImageStream resource is deployed to the cluster for storing new container images. You must explicitly create an ImageStream for the cluster. ImageStreams are not available by default. For more information about ImageStreams, see Managing image streams in the OpenShift Container Platform documentation. Procedure Log in to the OpenShift cluster. Create a Debezium KafkaConnect custom resource (CR) for the connector, or modify an existing one. For example, create a KafkaConnect CR with the name dbz-connect.yaml that specifies the metadata.annotations and spec.build properties. The following example shows an excerpt from a dbz-connect.yaml file that describes a KafkaConnect custom resource. Example 2.26. A dbz-connect.yaml file that defines a KafkaConnect custom resource that includes a Debezium connector In the example that follows, the custom resource is configured to download the following artifacts: The Debezium MySQL connector archive. The Red Hat build of Apicurio Registry archive. The Apicurio Registry is an optional component. Add the Apicurio Registry component only if you intend to use Avro serialization with the connector. The Debezium scripting SMT archive and the associated scripting engine that you want to use with the Debezium connector. The SMT archive and scripting language dependencies are optional components. Add these components only if you intend to use the Debezium content-based routing SMT or filter SMT . apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: debezium-kafka-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: version: 3.6.0 build: 2 output: 3 type: imagestream 4 image: debezium-streams-connect:latest plugins: 5 - name: debezium-connector-mysql artifacts: - type: zip 6 url: https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-mysql/2.7.3.Final-redhat-00001/debezium-connector-mysql-2.7.3.Final-redhat-00001-plugin.zip 7 - type: zip url: https://maven.repository.redhat.com/ga/io/apicurio/apicurio-registry-distro-connect-converter/2.4.4.Final-redhat- <build-number> /apicurio-registry-distro-connect-converter-2.4.4.Final-redhat- <build-number> .zip 8 - type: zip url: https://maven.repository.redhat.com/ga/io/debezium/debezium-scripting/2.7.3.Final-redhat-00001/debezium-scripting-2.7.3.Final-redhat-00001.zip 9 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy/3.0.11/groovy-3.0.11.jar 10 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-jsr223/3.0.11/groovy-jsr223-3.0.11.jar - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-json3.0.11/groovy-json-3.0.11.jar bootstrapServers: debezium-kafka-cluster-kafka-bootstrap:9093 ... Table 2.99. Descriptions of Kafka Connect configuration settings Item Description 1 Sets the strimzi.io/use-connector-resources annotation to "true" to enable the Cluster Operator to use KafkaConnector resources to configure connectors in this Kafka Connect cluster. 2 The spec.build configuration specifies where to store the build image and lists the plug-ins to include in the image, along with the location of the plug-in artifacts. 3 The build.output specifies the registry in which the newly built image is stored. 4 Specifies the name and image name for the image output. Valid values for output.type are docker to push into a container registry such as Docker Hub or Quay, or imagestream to push the image to an internal OpenShift ImageStream. To use an ImageStream, an ImageStream resource must be deployed to the cluster. For more information about specifying the build.output in the KafkaConnect configuration, see the Streams for Apache Kafka Build schema reference in {NameConfiguringStreamsOpenShift}. 5 The plugins configuration lists all of the connectors that you want to include in the Kafka Connect image. For each entry in the list, specify a plug-in name , and information for about the artifacts that are required to build the connector. Optionally, for each connector plug-in, you can include other components that you want to be available for use with the connector. For example, you can add Service Registry artifacts, or the Debezium scripting component. 6 The value of artifacts.type specifies the file type of the artifact specified in the artifacts.url . Valid types are zip , tgz , or jar . Debezium connector archives are provided in .zip file format. The type value must match the type of the file that is referenced in the url field. 7 The value of artifacts.url specifies the address of an HTTP server, such as a Maven repository, that stores the file for the connector artifact. Debezium connector artifacts are available in the Red Hat Maven repository. The OpenShift cluster must have access to the specified server. 8 (Optional) Specifies the artifact type and url for downloading the Apicurio Registry component. Include the Apicurio Registry artifact, only if you want the connector to use Apache Avro to serialize event keys and values with the Red Hat build of Apicurio Registry, instead of using the default JSON converter. 9 (Optional) Specifies the artifact type and url for the Debezium scripting SMT archive to use with the Debezium connector. Include the scripting SMT only if you intend to use the Debezium content-based routing SMT or filter SMT To use the scripting SMT, you must also deploy a JSR 223-compliant scripting implementation, such as groovy. 10 (Optional) Specifies the artifact type and url for the JAR files of a JSR 223-compliant scripting implementation, which is required by the Debezium scripting SMT. Important If you use Streams for Apache Kafka to incorporate the connector plug-in into your Kafka Connect image, for each of the required scripting language components artifacts.url must specify the location of a JAR file, and the value of artifacts.type must also be set to jar . Invalid values cause the connector fails at runtime. To enable use of the Apache Groovy language with the scripting SMT, the custom resource in the example retrieves JAR files for the following libraries: groovy groovy-jsr223 (scripting agent) groovy-json (module for parsing JSON strings) As an alternative, the Debezium scripting SMT also supports the use of the JSR 223 implementation of GraalVM JavaScript. Apply the KafkaConnect build specification to the OpenShift cluster by entering the following command: oc create -f dbz-connect.yaml Based on the configuration specified in the custom resource, the Streams Operator prepares a Kafka Connect image to deploy. After the build completes, the Operator pushes the image to the specified registry or ImageStream, and starts the Kafka Connect cluster. The connector artifacts that you listed in the configuration are available in the cluster. Create a KafkaConnector resource to define an instance of each connector that you want to deploy. For example, create the following KafkaConnector CR, and save it as mysql-inventory-connector.yaml Example 2.27. mysql-inventory-connector.yaml file that defines the KafkaConnector custom resource for a Debezium connector apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: labels: strimzi.io/cluster: debezium-kafka-connect-cluster name: inventory-connector-mysql 1 spec: class: io.debezium.connector.mysql.MySqlConnector 2 tasksMax: 1 3 config: 4 schema.history.internal.kafka.bootstrap.servers: debezium-kafka-cluster-kafka-bootstrap.debezium.svc.cluster.local:9092 schema.history.internal.kafka.topic: schema-changes.inventory database.hostname: mysql.debezium-mysql.svc.cluster.local 5 database.port: 3306 6 database.user: debezium 7 database.password: dbz 8 database.server.id: 184054 9 topic.prefix: inventory-connector-mysql 10 table.include.list: inventory.* 11 ... Table 2.100. Descriptions of connector configuration settings Item Description 1 The name of the connector to register with the Kafka Connect cluster. 2 The name of the connector class. 3 The number of tasks that can operate concurrently. 4 The connector's configuration. 5 The address of the host database instance. 6 The port number of the database instance. 7 The name of the account that Debezium uses to connect to the database. 8 The password that Debezium uses to connect to the database user account. 9 Unique numeric ID of the connector. 10 The topic prefix for the database instance or cluster. The specified name must be formed only from alphanumeric characters or underscores. Because the topic prefix is used as the prefix for any Kafka topics that receive change events from this connector, the name must be unique among the connectors in the cluster. This namespace is also used in the names of related Kafka Connect schemas, and the namespaces of a corresponding Avro schema if you integrate the connector with the Avro connector . 11 The list of tables from which the connector captures change events. Create the connector resource by running the following command: oc create -n <namespace> -f <kafkaConnector> .yaml For example, oc create -n debezium -f mysql-inventory-connector.yaml The connector is registered to the Kafka Connect cluster and starts to run against the database that is specified by spec.config.database.dbname in the KafkaConnector CR. After the connector pod is ready, Debezium is running. You are now ready to verify the Debezium MySQL deployment . 2.4.6.3. Deploying Debezium MySQL connectors by building a custom Kafka Connect container image from a Dockerfile To deploy a Debezium MySQL connector, you must build a custom Kafka Connect container image that contains the Debezium connector archive, and then push this container image to a container registry. You then need to create the following custom resources (CRs): A KafkaConnect CR that defines your Kafka Connect instance. The image property in the CR specifies the name of the container image that you create to run your Debezium connector. You apply this CR to the OpenShift instance where Red Hat Streams for Apache Kafka is deployed. Streams for Apache Kafka offers operators and images that bring Apache Kafka to OpenShift. A KafkaConnector CR that defines your Debezium MySQL connector. Apply this CR to the same OpenShift instance where you apply the KafkaConnect CR. Prerequisites MySQL is running and you completed the steps to set up MySQL to work with a Debezium connector . Streams for Apache Kafka is deployed on OpenShift and is running Apache Kafka and Kafka Connect. For more information, see Deploying and Managing Streams for Apache Kafka on OpenShift . Podman or Docker is installed. You have an account and permissions to create and manage containers in the container registry (such as quay.io or docker.io ) to which you plan to add the container that will run your Debezium connector. Procedure Create the Debezium MySQL container for Kafka Connect: Create a Dockerfile that uses registry.redhat.io/amq-streams-kafka-35-rhel8:2.5.0 as the base image. For example, from a terminal window, enter the following command: cat <<EOF >debezium-container-for-mysql.yaml 1 FROM registry.redhat.io/amq-streams-kafka-35-rhel8:2.5.0 USER root:root RUN mkdir -p /opt/kafka/plugins/debezium 2 RUN cd /opt/kafka/plugins/debezium/ \ && curl -O https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-mysql/2.7.3.Final-redhat-00001/debezium-connector-mysql-2.7.3.Final-redhat-00001-plugin.zip \ && unzip debezium-connector-mysql-2.7.3.Final-redhat-00001-plugin.zip \ && rm debezium-connector-mysql-2.7.3.Final-redhat-00001-plugin.zip RUN cd /opt/kafka/plugins/debezium/ USER 1001 EOF Item Description 1 You can specify any file name that you want. 2 Specifies the path to your Kafka Connect plug-ins directory. If your Kafka Connect plug-ins directory is in a different location, replace this path with the actual path of your directory. The command creates a Dockerfile with the name debezium-container-for-mysql.yaml in the current directory. Build the container image from the debezium-container-for-mysql.yaml Docker file that you created in the step. From the directory that contains the file, open a terminal window and enter one of the following commands: podman build -t debezium-container-for-mysql:latest . docker build -t debezium-container-for-mysql:latest . The preceding commands build a container image with the name debezium-container-for-mysql . Push your custom image to a container registry, such as quay.io or an internal container registry. The container registry must be available to the OpenShift instance where you want to deploy the image. Enter one of the following commands: podman push <myregistry.io> /debezium-container-for-mysql:latest docker push <myregistry.io> /debezium-container-for-mysql:latest Create a new Debezium MySQL KafkaConnect custom resource (CR). For example, create a KafkaConnect CR with the name dbz-connect.yaml that specifies annotations and image properties. The following example shows an excerpt from a dbz-connect.yaml file that describes a KafkaConnect custom resource. apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: #... image: debezium-container-for-mysql 2 ... Item Description 1 metadata.annotations indicates to the Cluster Operator that KafkaConnector resources are used to configure connectors in this Kafka Connect cluster. 2 spec.image specifies the name of the image that you created to run your Debezium connector. This property overrides the STRIMZI_DEFAULT_KAFKA_CONNECT_IMAGE variable in the Cluster Operator. Apply the KafkaConnect CR to the OpenShift Kafka Connect environment by entering the following command: oc create -f dbz-connect.yaml The command adds a Kafka Connect instance that specifies the name of the image that you created to run your Debezium connector. Create a KafkaConnector custom resource that configures your Debezium MySQL connector instance. You configure a Debezium MySQL connector in a .yaml file that specifies the configuration properties for the connector. The connector configuration might instruct Debezium to produce events for a subset of the schemas and tables, or it might set properties so that Debezium ignores, masks, or truncates values in specified columns that are sensitive, too large, or not needed. The following example configures a Debezium connector that connects to a MySQL host, 192.168.99.100 , on port 3306 , and captures changes to the inventory database. dbserver1 is the server's logical name. MySQL inventory-connector.yaml apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: inventory-connector-mysql 1 labels: strimzi.io/cluster: my-connect-cluster spec: class: io.debezium.connector.mysql.MariaDbConnector tasksMax: 1 2 config: 3 database.hostname: mysql 4 database.port: 3306 database.user: debezium database.password: dbz database.server.id: 184054 5 topic.prefix: inventory-connector-mysql 6 table.include.list: inventory 7 schema.history.internal.kafka.bootstrap.servers: my-cluster-kafka-bootstrap:9092 8 schema.history.internal.kafka.topic: schema-changes.inventory 9 Table 2.101. Descriptions of connector configuration settings Item Description 1 The name of the connector. 2 Only one task should operate at any one time. Because the MySQL connector reads the MySQL server's binlog , using a single connector task ensures proper order and event handling. The Kafka Connect service uses connectors to start one or more tasks that do the work, and it automatically distributes the running tasks across the cluster of Kafka Connect services. If any of the services stop or crash, those tasks will be redistributed to running services. 3 The connector's configuration. 4 The database host, which is the name of the container running the MySQL server ( mysql ). 5 Unique ID of the connector. 6 Topic prefix for the MySQL server or cluster. This name is used as the prefix for all Kafka topics that receive change event records. 7 The connector captures changes from the inventory table only. 8 The list of Kafka brokers that this connector will use to write and recover DDL statements to the database schema history topic. Upon restart, the connector recovers the schemas of the database that existed at the point in time in the binlog when the connector should begin reading. 9 The name of the database schema history topic. This topic is for internal use only and should not be used by consumers. Create your connector instance with Kafka Connect. For example, if you saved your KafkaConnector resource in the inventory-connector.yaml file, you would run the following command: oc apply -f inventory-connector.yaml The preceding command registers inventory-connector and the connector starts to run against the inventory database as defined in the KafkaConnector CR. For the complete list of the configuration properties that you can set for the Debezium MySQL connector, see MySQL connector configuration properties . Results After the connector starts, it performs a consistent snapshot of the MySQL databases that the connector is configured for. The connector then starts generating data change events for row-level operations and streaming change event records to Kafka topics. 2.4.6.4. Verifying that the Debezium MySQL connector is running If the connector starts correctly without errors, it creates a topic for each table that the connector is configured to capture. Downstream applications can subscribe to these topics to retrieve information events that occur in the source database. To verify that the connector is running, you perform the following operations from the OpenShift Container Platform web console, or through the OpenShift CLI tool (oc): Verify the connector status. Verify that the connector generates topics. Verify that topics are populated with events for read operations ("op":"r") that the connector generates during the initial snapshot of each table. Prerequisites A Debezium connector is deployed to Streams for Apache Kafka on OpenShift. The OpenShift oc CLI client is installed. You have access to the OpenShift Container Platform web console. Procedure Check the status of the KafkaConnector resource by using one of the following methods: From the OpenShift Container Platform web console: Navigate to Home Search . On the Search page, click Resources to open the Select Resource box, and then type KafkaConnector . From the KafkaConnectors list, click the name of the connector that you want to check, for example inventory-connector-mysql . In the Conditions section, verify that the values in the Type and Status columns are set to Ready and True . From a terminal window: Enter the following command: oc describe KafkaConnector <connector-name> -n <project> For example, oc describe KafkaConnector inventory-connector-mysql -n debezium The command returns status information that is similar to the following output: Example 2.28. KafkaConnector resource status Name: inventory-connector-mysql Namespace: debezium Labels: strimzi.io/cluster=debezium-kafka-connect-cluster Annotations: <none> API Version: kafka.strimzi.io/v1beta2 Kind: KafkaConnector ... Status: Conditions: Last Transition Time: 2021-12-08T17:41:34.897153Z Status: True Type: Ready Connector Status: Connector: State: RUNNING worker_id: 10.131.1.124:8083 Name: inventory-connector-mysql Tasks: Id: 0 State: RUNNING worker_id: 10.131.1.124:8083 Type: source Observed Generation: 1 Tasks Max: 1 Topics: inventory-connector-mysql.inventory inventory-connector-mysql.inventory.addresses inventory-connector-mysql.inventory.customers inventory-connector-mysql.inventory.geom inventory-connector-mysql.inventory.orders inventory-connector-mysql.inventory.products inventory-connector-mysql.inventory.products_on_hand Events: <none> Verify that the connector created Kafka topics: From the OpenShift Container Platform web console. Navigate to Home Search . On the Search page, click Resources to open the Select Resource box, and then type KafkaTopic . From the KafkaTopics list, click the name of the topic that you want to check, for example, inventory-connector-mysql.inventory.orders---ac5e98ac6a5d91e04d8ec0dc9078a1ece439081d . In the Conditions section, verify that the values in the Type and Status columns are set to Ready and True . From a terminal window: Enter the following command: oc get kafkatopics The command returns status information that is similar to the following output: Example 2.29. KafkaTopic resource status Check topic content. From a terminal window, enter the following command: oc exec -n <project> -it <kafka-cluster> -- /opt/kafka/bin/kafka-console-consumer.sh \ > --bootstrap-server localhost:9092 \ > --from-beginning \ > --property print.key=true \ > --topic= <topic-name > For example, oc exec -n debezium -it debezium-kafka-cluster-kafka-0 -- /opt/kafka/bin/kafka-console-consumer.sh \ > --bootstrap-server localhost:9092 \ > --from-beginning \ > --property print.key=true \ > --topic=inventory-connector-mysql.inventory.products_on_hand The format for specifying the topic name is the same as the oc describe command returns in Step 1, for example, inventory-connector-mysql.inventory.addresses . For each event in the topic, the command returns information that is similar to the following output: Example 2.30. Content of a Debezium change event In the preceding example, the payload value shows that the connector snapshot generated a read ( "op" ="r" ) event from the table inventory.products_on_hand . The "before" state of the product_id record is null , indicating that no value exists for the record. The "after" state shows a quantity of 3 for the item with product_id 101 . 2.4.6.5. Descriptions of Debezium MySQL connector configuration properties The Debezium MySQL connector has numerous configuration properties that you can use to achieve the right connector behavior for your application. Many properties have default values. Information about the properties is organized as follows: Required connector configuration properties Advanced connector configuration properties Database schema history connector configuration properties that control how Debezium processes events that it reads from the database schema history topic. Pass-through MySQL connector configuration properties Pass-through database schema history properties for configuring producer and consumer clients Pass-through Kafka signals configuration properties Pass-through Kafka signals consumer client configuration properties Pass-through sink notification configuration properties Pass-through database driver configuration properties Required Debezium MySQL connector configuration properties The following configuration properties are required unless a default value is available. bigint.unsigned.handling.mode Default value: long Specifies how the connector represents BIGINT UNSIGNED columns in change events. Set one of the following options: long Uses Java long data types to represent BIGINT UNSIGNED column values. Although the long type does not offer the greatest precision, it is easy implement in most consumers. In most environments, this is the preferred setting. precise Uses java.math.BigDecimal data types to represent values. The connector uses the Kafka Connect org.apache.kafka.connect.data.Decimal data type to represent values in encoded binary format. Set this option if the connector typically works with values larger than 2^63. The long data type cannot convey values of that size. binary.handling.mode Default value: bytes Specifies how the connector represents values for binary columns, such as, blob , binary , varbinary , in change events. Set one of the following options: bytes Represents binary data as a byte array. base64 Represents binary data as a base64-encoded String. base64-url-safe Represents binary data as a base64-url-safe-encoded String. hex Represents binary data as a hex-encoded (base16) String. column.exclude.list Default value: empty string An optional, comma-separated list of regular expressions that match the fully-qualified names of columns to exclude from change event record values. Other columns in the source record are captured as usual. Fully-qualified names for columns are of the form databaseName . tableName . columnName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; it does not match substrings that might be present in a column name. If you include this property in the configuration, do not also set the column.include.list property. column.include.list Default value: empty string An optional, comma-separated list of regular expressions that match the fully-qualified names of columns to include in change event record values. Other columns are omitted from the event record. Fully-qualified names for columns are of the form databaseName . tableName . columnName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; it does not match substrings that might be present in a column name. If you include this property in the configuration, do not set the column.exclude.list property. column.mask.hash. hashAlgorithm .with.salt. salt column.mask.hash.v2. hashAlgorithm .with.salt. salt Default value: No default An optional, comma-separated list of regular expressions that match the fully-qualified names of character-based columns. Fully-qualified names for columns are of the form <databaseName> . <tableName> . <columnName> . To match the name of a column Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. In the resulting change event record, the values for the specified columns are replaced with pseudonyms. A pseudonym consists of the hashed value that results from applying the specified hashAlgorithm and salt . Based on the hash function that is used, referential integrity is maintained, while column values are replaced with pseudonyms. Supported hash functions are described in the MessageDigest section of the Java Cryptography Architecture Standard Algorithm Name Documentation. In the following example, CzQMA0cB5K is a randomly selected salt. If necessary, the pseudonym is automatically shortened to the length of the column. The connector configuration can include multiple properties that specify different hash algorithms and salts. Depending on the hashAlgorithm used, the salt selected, and the actual data set, the resulting data set might not be completely masked. Hashing strategy version 2 ensures fidelity of values that are hashed in different places or systems. column.mask.with. length .chars Default value: No default An optional, comma-separated list of regular expressions that match the fully-qualified names of character-based columns. Set this property if you want the connector to mask the values for a set of columns, for example, if they contain sensitive data. Set length to a positive integer to replace data in the specified columns with the number of asterisk ( * ) characters specified by the length in the property name. Set length to 0 (zero) to replace data in the specified columns with an empty string. The fully-qualified name of a column observes the following format: databaseName . tableName . columnName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. You can specify multiple properties with different lengths in a single configuration. column.propagate.source.type Default value: No default An optional, comma-separated list of regular expressions that match the fully-qualified names of columns for which you want the connector to emit extra parameters that represent column metadata. When this property is set, the connector adds the following fields to the schema of event records: __debezium.source.column.type __debezium.source.column.length __debezium.source.column.scale These parameters propagate a column's original type name and length (for variable-width types), respectively. Enabling the connector to emit this extra data can assist in properly sizing specific numeric or character-based columns in sink databases. The fully-qualified name of a column observes one of the following formats: databaseName . tableName . columnName , or databaseName . schemaName . tableName . columnName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. column.truncate.to. length .chars Default value: No default An optional, comma-separated list of regular expressions that match the fully-qualified names of character-based columns. Set this property if you want to truncate the data in a set of columns when it exceeds the number of characters specified by the length in the property name. Set length to a positive integer value, for example, column.truncate.to.20.chars . The fully-qualified name of a column observes the following format: databaseName . tableName . columnName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. You can specify multiple properties with different lengths in a single configuration. connect.timeout.ms Default value: 30000 (30 seconds) A positive integer value that specifies the maximum time in milliseconds that the connector waits to establish a connection to the MySQL database server before the connection request times out. connector.class Default value: No default The name of the Java class for the connector. Always specify for the MySQL connector. database.exclude.list Default value: empty string An optional, comma-separated list of regular expressions that match the names of databases from which you do not want the connector to capture changes. The connector captures changes in any database that is not named in the database.exclude.list . To match the name of a database, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the database; it does not match substrings that might be present in a database name. If you include this property in the configuration, do not also set the database.include.list property. database.hostname Default value: No default The IP address or hostname of the MySQL database server. database.include.list Default value: empty string An optional, comma-separated list of regular expressions that match the names of the databases from which the connector captures changes. The connector does not capture changes in any database whose name is not in database.include.list . By default, the connector captures changes in all databases. To match the name of a database, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the database; it does not match substrings that might be present in a database name. If you include this property in the configuration, do not also set the database.exclude.list property. database.password Default value: No default The password of the MySQL user that the connector uses to connect to the MySQL database server. database.port Default value: 3306 Integer port number of the MySQL database server. database.server.id Default value: No default The numeric ID of this database client. The specified ID must be unique across all currently running database processes in the MySQL cluster. To enable it to read the binlog, the connector uses this unique ID to join the MySQL database cluster as another server. database.user Default value: No default The name of the MySQL user that the connector uses to connect to the MySQL database server. decimal.handling.mode Default value: precise Specifies how the connector handles values for DECIMAL and NUMERIC columns in change events. Set one of the following options: precise (default) Uses java.math.BigDecimal values in binary form to represent values precisely. double Uses the double data type to represent values. This option can result in a loss of precision, but it is easier for most consumers to use. string Encodes values as formatted strings. This option is easy to consume, but can result in the loss of semantic information about the real type. event.deserialization.failure.handling.mode Default value: fail Specifies how the connector reacts after an exception occurs during deserialization of binlog events. This option is deprecated, please use event.processing.failure.handling.mode option instead. fail Propagates the exception, which indicates the problematic event and its binlog offset, and causes the connector to stop. warn Logs the problematic event and its binlog offset and then skips the event. ignore Passes over the problematic event and does not log anything. field.name.adjustment.mode Default value: No default Specifies how field names should be adjusted for compatibility with the message converter used by the connector. Set one of the following options: none No adjustment. avro Replaces characters that are not valid in Avro names with underscore characters. avro_unicode Replaces underscore characters or characters that cannot be used in Avro names with corresponding unicode, such as _uxxxx . Note For more information, see: Avro naming . gtid.source.excludes Default value: No default A comma-separated list of regular expressions that match source domain IDs in the GTID set that the connector uses to find the binlog position on the MySQL server. When this property is set, the connector uses only the GTID ranges that have source UUIDs that do not match any of the specified exclude patterns. To match the value of a GTID, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the GTID's domain identifier. If you include this property in the configuration, do not also set the gtid.source.includes property. gtid.source.includes Default value: No default A comma-separated list of regular expressions that match source domain IDs in the GTID set used that the connector uses to find the binlog position on the MySQL server. When this property is set, the connector uses only the GTID ranges that have source UUIDs that match one of the specified include patterns. To match the value of a GTID, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the GTID's domain identifier. If you include this property in the configuration, do not also set the gtid.source.excludes property. include.query Default value: false Boolean value that specifies whether the connector should include the original SQL query that generated the change event. If you set this option to true then you must also configure MySQL with the binlog_annotate_row_events option set to ON . When include.query is true , the query is not present for events that the snapshot process generates. Setting include.query to true might expose tables or fields that are explicitly excluded or masked by including the original SQL statement in the change event. For this reason, the default setting is false . For more information about configuring the database to return the original SQL statement for each log event, see Enabling query log events . include.schema.changes Default value: true Boolean value that specifies whether the connector publishes changes that occur to the database schema to a Kafka topic with the name of the database server ID. Each schema change event that the connector captures uses a key that contains the database name and a value that includes the DDL statements that describe the change. This setting does not affect how the connector records schema changes in its internal database schema history. include.schema.comments Default value: false Boolean value that specifies whether the connector parses and publishes table and column comments on metadata objects. Note When you set this option to true , the schema comments that the connector includes can add a significant amount of string data to each schema object. Increasing the number and size of logical schema objects increases the amount of memory that the connector uses. inconsistent.schema.handling.mode Default value: fail Specifies how the connector responds to binlog events that refer to tables that are not present in the internal schema representation. That is, the internal representation is not consistent with the database. Set one of the following options: fail The connector throws an exception that reports the problematic event and its binlog offset. The connector then stops. warn The connector logs the problematic event and its binlog offset, and then skips the event. skip The connector skips the problematic event and does not report it in the log. message.key.columns Default value: No default A list of expressions that specify the columns that the connector uses to form custom message keys for change event records that it publishes to the Kafka topics for specified tables. By default, Debezium uses the primary key column of a table as the message key for records that it emits. In place of the default, or to specify a key for tables that lack a primary key, you can configure custom message keys based on one or more columns. To establish a custom message key for a table, list the table, followed by the columns to use as the message key. Each list entry takes the following format: <fully-qualified_tableName> : <keyColumn> , <keyColumn> To base a table key on multiple column names, insert commas between the column names. Each fully-qualified table name is a regular expression in the following format: <databaseName> . <tableName> The property can include entries for multiple tables. Use a semicolon to separate table entries in the list. The following example sets the message key for the tables inventory.customers and purchase.orders : inventory.customers:pk1,pk2;(.*).purchaseorders:pk3,pk4 For the table inventory.customer , the columns pk1 and pk2 are specified as the message key. For the purchaseorders tables in any database, the columns pk3 and pk4 server as the message key. There is no limit to the number of columns that you use to create custom message keys. However, it's best to use the minimum number that are required to specify a unique key. name Default value: No default Unique name for the connector. If you attempt to use the same name to register another connector, registration fails. This property is required by all Kafka Connect connectors. schema.name.adjustment.mode Default value: No default Specifies how the connector adjusts schema names for compatibility with the message converter used by the connector. Set one of the following options: none No adjustment. avro Replaces characters that are not valid in Avro names with underscore characters. avro_unicode Replaces underscore characters or characters that cannot be used in Avro names with corresponding unicode, such as _uxxxx. NOTE: _ is an escape sequence, similar to a backslash in Java skip.messages.without.change Default value: false Specifies whether the connector emits messages for records when it does not detect a change in the included columns. Columns are considered to be included if they are listed in the column.include.list , or are not listed in the column.exclude.list . Set the value to true to prevent the connector from capturing records when no changes are present in the included columns. table.exclude.list Default value: empty string An optional, comma-separated list of regular expressions that match fully-qualified table identifiers of tables from which you do not want the connector to capture changes. The connector captures changes in any table that is not included in table.exclude.list . Each identifier is of the form databaseName . tableName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the table; it does not match substrings that might be present in a table name. If you include this property in the configuration, do not also set the table.include.list property. table.include.list Default value: empty string An optional, comma-separated list of regular expressions that match fully-qualified table identifiers of tables whose changes you want to capture. The connector does not capture changes in any table that is not included in table.include.list . Each identifier is of the form databaseName . tableName . By default, the connector captures changes in all non-system tables in every database from which it is configured to captures changes. To match the name of a table, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the table; it does not match substrings that might be present in a table name. If you include this property in the configuration, do not also set the table.exclude.list property. tasks.max Default value: 1 The maximum number of tasks to create for this connector. Because the MySQL connector always uses a single task, changing the default value has no effect. time.precision.mode Default value: adaptive_time_microseconds Specifies the type of precision that the connector uses to represent time, date, and timestamps values. Set one of the following options: adaptive_time_microseconds (default) The connector captures the date, datetime and timestamp values exactly as in the database using either millisecond, microsecond, or nanosecond precision values based on the database column's type, with the exception of TIME type fields, which are always captured as microseconds. connect The connector always represents time and timestamp values using Kafka Connect's built-in representations for Time, Date, and Timestamp, which use millisecond precision regardless of the database columns' precision. tombstones.on.delete Default value: true Specifies whether a delete event is followed by a tombstone event. After a source record is deleted, the connector can emit a tombstone event (the default behavior) to enable Kafka to completely delete all events that pertain to the key of the deleted row in case log compaction is enabled for the topic. Set one of the following options: true (default) The connector represents delete operations by emitting a delete event and a subsequent tombstone event. false The connector emits only delete events. topic.prefix Default value: No default Topic prefix that provides a namespace for the particular MySQL database server or cluster in which Debezium is capturing changes. Because the topic prefix is used to name all of the Kafka topics that receive events that this connector emits, it's important that the topic prefix is unique across all connectors. Values must contain only alphanumeric characters, hyphens, dots, and underscores. Warning After you set this property, do not change its value. If you change the value, after the connector restarts, instead of continuing to emit events to the original topics, the connector emits subsequent events to topics whose names are based on the new value. The connector is also unable to recover its database schema history topic. Advanced Debezium MySQL connector configuration properties The following list describes advanced MySQL connector configuration properties. The default values for these properties rarely require changes. Therefore, you do not need to specify them in the connector configuration. connect.keep.alive Default value: true A Boolean value that specifies whether a separate thread should be used to ensure that the connection to the MySQL server or cluster is kept alive. converters Default value: No default Enumerates a comma-separated list of the symbolic names of the custom converter instances that the connector can use. For example, boolean . This property is required to enable the connector to use a custom converter. For each converter that you configure for a connector, you must also add a .type property, which specifies the fully-qualified name of the class that implements the converter interface. The .type property uses the following format: <converterSymbolicName> .type For example, If you want to further control the behavior of a configured converter, you can add one or more configuration parameters to pass values to the converter. To associate these additional configuration parameter with a converter, prefix the parameter name with the symbolic name of the converter. For example, to define a selector parameter that specifies the subset of columns that the boolean converter processes, add the following property: custom.metric.tags Default value: No default Defines tags that customize MBean object names by adding metadata that provides contextual information. Specify a comma-separated list of key-value pairs. Each key represents a tag for the MBean object name, and the corresponding value represents a value for the key, for example, k1=v1,k2=v2 The connector appends the specified tags to the base MBean object name. Tags can help you to organize and categorize metrics data. You can define tags to identify particular application instances, environments, regions, versions, and so forth. For more information, see Customized MBean names . database.initial.statements Default value: No default A semicolon separated list of SQL statements to be executed when a JDBC connection, not the connection that is reading the transaction log, to the database is established. To specify a semicolon as a character in a SQL statement and not as a delimiter, use two semicolons, ( ;; ). The connector might establish JDBC connections at its own discretion, so this property is ony for configuring session parameters. It is not for executing DML statements. database.query.timeout.ms Default value: 600000 (10 minutes) Specifies the time, in milliseconds, that the connector waits for a query to complete. Set the value to 0 (zero) to remove the timeout limit. database.ssl.keystore Default value: No default An optional setting that specifies the location of the key store file. A key store file can be used for two-way authentication between the client and the MySQL server. database.ssl.keystore.password Default value: No default The password for the key store file. Specify a password only if the database.ssl.keystore is configured. database.ssl.mode Default value: preferred Specifies whether the connector uses an encrypted connection. The following settings are available: disabled Specifies the use of an unencrypted connection. preferred (Default) The connector establishes an encrypted connection if the server supports secure connections. If the server does not support secure connections, the connector falls back to using an unencrypted connection. required The connector establishes an encrypted connection. If it is unable to establish an encrypted connection, the connector fails. verify_ca The connector behaves as when you set the required option, but it also verifies the server TLS certificate against the configured Certificate Authority (CA) certificates. If the server TLS certificate does not match any valid CA certificates, the connector fails. verify_identity The connector behaves as when you set the verify_ca option, but it also verifies that the server certificate matches the host of the remote connection. database.ssl.truststore Default value: No default The location of the trust store file for the server certificate verification. database.ssl.truststore.password Default value: No default The password for the trust store file. Used to check the integrity of the truststore, and unlock the truststore. enable.time.adjuster Default value: true Boolean value that indicates whether the connector converts a 2-digit year specification to 4 digits. Set the value to false when conversion is fully delegated to the database. MySQL users can insert year values with either 2-digits or 4-digits. 2-digit values are mapped to a year in the range 1970 - 2069. By default, the connector performs the conversion. errors.max.retries Default value: -1 Specifies how the connector responds after an operation that results in a retriable error, such as a connection error. Set one of the following options: -1 No limit. The connector always restarts automatically, and retries the operation, regardless of the number of failures. 0 Disabled. The connector fails immediately, and never retries the operation. User intervention is required to restart the connector. > 0 The connector restarts automatically until it reaches the specified maximum number of retries. After the failure, the connector stops, and user intervention is required to restart it. event.converting.failure.handling.mode Default value: warn Specifies how the connector responds when it cannot convert a table record due to a mismatch between the data type of a column and the type specified by the Debezium internal schema. Set one of the following options: fail An exception reports that conversion failed because the data type of the field did not match the schema type, and indicates that it might be necessary to restart the connector in schema _only_recovery mode to enable a successful conversion. warn The connector writes a null value to the event field for the column that failed conversion, writes a message to the warning log . skip The connector writes a null value to the event field for the column that failed conversion, and writes a message to the debug log. event.processing.failure.handling.mode Default value: fail Specifies how the connector handles failures that occur when processing events, for example, if it encounters a corrupted event. The following settings are available: fail The connector raises an exception that reports the problematic event and its position. The connector then stops. warn The connector does not raise an exception. Instead, it logs the problematic event and its position, and then skips the event. ignore The connector ignores the problematic event, and does not generate a log entry. heartbeat.action.query Default value: No default Specifies a query that the connector executes on the source database when the connector sends a heartbeat message. For example, the following query periodically captures the state of the executed GTID set in the source database. INSERT INTO gtid_history_table (select @gtid_executed) heartbeat.interval.ms Default value: 0 Specifies how frequently the connector sends heartbeat messages to a Kafka topic. By default, the connector does not send heartbeat messages. Heartbeat messages are useful for monitoring whether the connector is receiving change events from the database. Heartbeat messages might help decrease the number of change events that need to be re-sent when a connector restarts. To send heartbeat messages, set this property to a positive integer, which indicates the number of milliseconds between heartbeat messages. incremental.snapshot.allow.schema.changes Default value: false Specifies whether the connector allows schema changes during an incremental snapshot. When the value is set to true , the connector detects schema change during an incremental snapshot, and re-select a current chunk to avoid locking DDLs. Changes to a primary key are not supported. Changing the primary during an incremental snapshot, can lead to incorrect results. A further limitation is that if a schema change affects only the default values of columns, then the change is not detected until the DDL is processed from the binlog stream. This does not affect the values of snapshot events, but the schema of these snapshot events may have outdated defaults. incremental.snapshot.chunk.size Default value: 1024 The maximum number of rows that the connector fetches and reads into memory when it retrieves an incremental snapshot chunk. Increasing the chunk size provides greater efficiency, because the snapshot runs fewer snapshot queries of a greater size. However, larger chunk sizes also require more memory to buffer the snapshot data. Adjust the chunk size to a value that provides the best performance in your environment. incremental.snapshot.watermarking.strategy Default value: insert_insert Specifies the watermarking mechanism that the connector uses during an incremental snapshot to deduplicate events that might be captured by an incremental snapshot and then recaptured after streaming resumes. You can specify one of the following options: insert_insert (default) When you send a signal to initiate an incremental snapshot, for every chunk that Debezium reads during the snapshot, it writes an entry to the signaling data collection to record the signal to open the snapshot window. After the snapshot completes, Debezium inserts a second entry that records the signal to close the window. insert_delete When you send a signal to initiate an incremental snapshot, for every chunk that Debezium reads, it writes a single entry to the signaling data collection to record the signal to open the snapshot window. After the snapshot completes, this entry is removed. No entry is created for the signal to close the snapshot window. Set this option to prevent rapid growth of the signaling data collection. max.batch.size Default value: 2048 Positive integer value that specifies the maximum size of each batch of events that should be processed during each iteration of this connector. max.queue.size Default value: 8192 A positive integer value that specifies the maximum number of records that the blocking queue can hold. When Debezium reads events streamed from the database, it places the events in the blocking queue before it writes them to Kafka. The blocking queue can provide backpressure for reading change events from the database in cases where the connector ingests messages faster than it can write them to Kafka, or when Kafka becomes unavailable. Events that are held in the queue are disregarded when the connector periodically records offsets. Always set max.queue.size to a value that is larger than the value of max.batch.size . max.queue.size.in.bytes Default value: 0 A long integer value that specifies the maximum volume of the blocking queue in bytes. By default, volume limits are not specified for the blocking queue. To specify the number of bytes that the queue can consume, set this property to a positive long value. If max.queue.size is also set, writing to the queue is blocked when the size of the queue reaches the limit specified by either property. For example, if you set max.queue.size=1000 , and max.queue.size.in.bytes=5000 , writing to the queue is blocked after the queue contains 1000 records, or after the volume of the records in the queue reaches 5000 bytes. min.row.count.to.stream.results Default value: 1000 During a snapshot, the connector queries each table for which the connector is configured to capture changes. The connector uses each query result to produce a read event that contains data for all rows in that table. This property determines whether the MySQL connector puts results for a table into memory, which is fast but requires large amounts of memory, or streams the results, which can be slower but work for very large tables. The setting of this property specifies the minimum number of rows a table must contain before the connector streams results. To skip all table size checks and always stream all results during a snapshot, set this property to 0 . notification.enabled.channels Default value: No default List of notification channel names that are enabled for the connector. By default, the following channels are available: sink log jmx poll.interval.ms Default value: 500 (0.5 seconds) Positive integer value that specifies the number of milliseconds the connector waits for new change events to appear before it starts processing a batch of events. provide.transaction.metadata Default value: false Determines whether the connector generates events with transaction boundaries and enriches change event envelopes with transaction metadata. Specify true if you want the connector to do this. For more information, see Transaction metadata . signal.data.collection Default value: No default Fully-qualified name of the data collection that is used to send signals to the connector. Use the following format to specify the collection name: <databaseName> . <tableName> signal.enabled.channels Default value: No default List of the signaling channel names that are enabled for the connector. By default, the following channels are available: source kafka file jmx skipped.operations Default value: t A comma-separated list of operation types that will be skipped during streaming. The operations include: c for inserts/create, u for updates, d for deletes, t for truncates, and none to not skip any operations. By default, truncate operations are skipped. snapshot.delay.ms Default value: No default An interval in milliseconds that the connector should wait before performing a snapshot when the connector starts. If you are starting multiple connectors in a cluster, this property is useful for avoiding snapshot interruptions, which might cause re-balancing of connectors. snapshot.fetch.size Default value: Unset By default, during a snapshot, the connector reads table content in batches of rows. Set this property to specify the maximum number of rows in a batch. Caution To maintain connector performance, it's best to preserve the unset default of this property. This default configuration enables MySQL to stream the result set to Debezium one row at a time. By contrast, if you set this property, performance problems can result, because Debezium attempts to fetch the entire result set into memory at once. snapshot.include.collection.list Default value: All tables specified in the table.include.list . An optional, comma-separated list of regular expressions that match the fully-qualified names ( <databaseName>.<tableName> ) of the tables to include in a snapshot. The specified items must be named in the connector's table.include.list property. This property takes effect only if the connector's snapshot.mode property is set to a value other than never . This property does not affect the behavior of incremental snapshots. To match the name of a table, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the table; it does not match substrings that might be present in a table name. snapshot.lock.timeout.ms Default value: 10000 Positive integer that specifies the maximum amount of time (in milliseconds) to wait to obtain table locks when performing a snapshot. If the connector cannot acquire table locks in this time interval, the snapshot fails. For more information, see snapshot.locking.mode Default value: minimal Specifies whether and for how long the connector holds the global MySQL read lock, which prevents any updates to the database while the connector is performing a snapshot. The following settings are available: minimal The connector holds the global read lock for only the initial phase of the snapshot during which it reads the database schemas and other metadata. During the phase of the snapshot, the connector releases the lock as it selects all rows from each table. To perform the SELECT operation in a consistent fashion, the connector uses a REPEATABLE READ transaction. Although the release of the global read lock permits other MySQL clients to update the database, use of REPEATABLE READ isolation ensures a consistent snapshot, because the connector continues to read the same data for the duration of the transaction. extended Blocks all write operations for the duration of the snapshot. Use this setting if clients submit concurrent operations that are incompatible with the REPEATABLE READ isolation level in MySQL. none Prevents the connector from acquiring any table locks during the snapshot. Although this option is allowed with all snapshot modes, it is safe to use only if no schema changes occur while the snapshot is running. Tables that are defined with the MyISAM engine always acquire a table lock. As a result, such tables are locked even if you set this option. This behavior differs from tables that are defined by the InnoDB engine, which acquire row-level locks. snapshot.max.threads Default value: 1 Specifies the number of threads that the connector uses when performing an initial snapshot. To enable parallel initial snapshots, set the property to a value greater than 1. In a parallel initial snapshot, the connector processes multiple tables concurrently. Important Parallel initial snapshots is a Developer Preview feature only. Developer Preview software is not supported by Red Hat in any way and is not functionally complete or production-ready. Do not use Developer Preview software for production or business-critical workloads. Developer Preview software provides early access to upcoming product software in advance of its possible inclusion in a Red Hat product offering. Customers can use this software to test functionality and provide feedback during the development process. This software is subject to change or removal at any time, and has received limited testing. Red Hat might provide ways to submit feedback on Developer Preview software without an associated SLA. For more information about the support scope of Red Hat Developer Preview software, see Developer Preview Support Scope . snapshot.mode Default value: initial Specifies the criteria for running a snapshot when the connector starts. The following settings are available: always The connector performs a snapshot every time that it starts. The snapshot includes the structure and data of the captured tables. Specify this value to populate topics with a complete representation of the data from the captured tables every time that the connector starts. initial (default) The connector runs a snapshot only when no offsets have been recorded for the logical server name, or if it detects that an earlier snapshot failed to complete. After the snapshot completes, the connector begins to stream event records for subsequent database changes. initial_only The connector runs a snapshot only when no offsets have been recorded for the logical server name. After the snapshot completes, the connector stops. It does not transition to streaming to read change events from the binlog. schema_only Deprecated, see no_data . no_data The connector runs a snapshot that captures only the schema, but not any table data. Set this option if you do not need the topics to contain a consistent snapshot of the data, but you want to capture any schema changes that were applied after the last connector restart. schema_only_recovery Deprecated, see recovery . recovery Set this option to restore a database schema history topic that is lost or corrupted. After a restart, the connector runs a snapshot that rebuilds the topic from the source tables. You can also set the property to periodically prune a database schema history topic that experiences unexpected growth. Warning Do not use this mode to perform a snapshot if schema changes were committed to the database after the last connector shutdown. never When the connector starts, rather than performing a snapshot, it immediately begins to stream event records for subsequent database changes. This option is under consideration for future deprecation, in favor of the no_data option. when_needed After the connector starts, it performs a snapshot only if it detects one of the following circumstances: It cannot detect any topic offsets. A previously recorded offset specifies a binlog position or GTID that is not available on the server. snapshot.query.mode Default value: select_all Specifies how the connector queries data while performing a snapshot. Set one of the following options: select_all (default) The connector uses a select all query to retrieve rows from captured tables, optionally adjusting the columns selected based on the column include and exclude list configurations. This setting enables you to manage snapshot content in a more flexible manner compared to using the snapshot.select.statement.overrides property. snapshot.select.statement.overrides Default value: No default Specifies the table rows to include in a snapshot. Use the property if you want a snapshot to include only a subset of the rows in a table. This property affects snapshots only. It does not apply to events that the connector reads from the log. The property contains a comma-separated list of fully-qualified table names in the form <databaseName>.<tableName> . For example, "snapshot.select.statement.overrides": "inventory.products,customers.orders" For each table in the list, add a further configuration property that specifies the SELECT statement for the connector to run on the table when it takes a snapshot. The specified SELECT statement determines the subset of table rows to include in the snapshot. Use the following format to specify the name of this SELECT statement property: snapshot.select.statement.overrides. <databaseName> . <tableName> For example, snapshot.select.statement.overrides.customers.orders From a customers.orders table that includes the soft-delete column, delete_flag , add the following properties if you want a snapshot to include only those records that are not soft-deleted: In the resulting snapshot, the connector includes only the records for which delete_flag = 0 . snapshot.tables.order.by.row.count Default value: disabled Specifies the order in which the connector processes tables when it performs an initial snapshot. Set one of the following options: descending The connector snapshots tables in order, based on the number of rows from the highest to the lowest. ascending The connector snapshots tables in order, based on the number of rows, from lowest to highest. disabled The connector disregards row count when performing an initial snapshot. streaming.delay.ms Default value: 0 Specifies the time, in milliseconds, that the connector delays the start of the streaming process after it completes a snapshot. Setting a delay interval helps to prevent the connector from restarting snapshots in the event that a failure occurs immediately after the snapshot completes, but before the streaming process begins. Set a delay value that is higher than the value of the offset.flush.interval.ms property that is set for the Kafka Connect worker. table.ignore.builtin Default value: true A Boolean value that specifies whether built-in system tables should be ignored. This applies regardless of the table include and exclude lists. By default, changes that occur to the values in system tables are excluded from capture, and Debezium does not generate events for system table changes. topic.cache.size Default value: 10000 Specifies the number of topic names that can be stored in memory in a bounded concurrent hash map. The connector uses the cache to help determine the topic name that corresponds to a data collection. topic.delimiter Default value: . Specifies the delimiter that the connector inserts between components of the topic name. topic.heartbeat.prefix Default value: __debezium-heartbeat Specifies the name of the topic to which the connector sends heartbeat messages. The topic name takes the following format: topic.heartbeat.prefix . topic.prefix For example, if the topic prefix is fulfillment , the default topic name is __debezium-heartbeat.fulfillment . topic.naming.strategy Default value: io.debezium.schema.DefaultTopicNamingStrategy The name of the TopicNamingStrategy class that the connector uses. The specified strategy determines how the connector names the topics that store event records for data changes, schema changes, transactions, heartbeats, and so forth. topic.transaction Default value: transaction Specifies the name of the topic to which the connector sends transaction metadata messages. The topic name takes the following pattern: topic.prefix . topic.transaction For example, if the topic prefix is fulfillment , the default topic name is fulfillment.transaction . use.nongraceful.disconnect Default value: false A Boolean value that specifies whether the binary log client's keepalive thread sets the SO_LINGER socket option to 0 to immediately close stale TCP connections. Set the value to true if the connector experiences deadlocks in SSLSocketImpl.close . Debezium connector database schema history configuration properties Debezium provides a set of schema.history.internal.* properties that control how the connector interacts with the schema history topic. The following table describes the schema.history.internal properties for configuring the Debezium connector. Table 2.102. Connector database schema history configuration properties Property Default Description schema.history.internal.kafka.topic No default The full name of the Kafka topic where the connector stores the database schema history. schema.history.internal.kafka.bootstrap.servers No default A list of host/port pairs that the connector uses for establishing an initial connection to the Kafka cluster. This connection is used for retrieving the database schema history previously stored by the connector, and for writing each DDL statement read from the source database. Each pair should point to the same Kafka cluster used by the Kafka Connect process. schema.history.internal.kafka.recovery.poll.interval.ms 100 An integer value that specifies the maximum number of milliseconds the connector should wait during startup/recovery while polling for persisted data. The default is 100ms. schema.history.internal.kafka.query.timeout.ms 3000 An integer value that specifies the maximum number of milliseconds the connector should wait while fetching cluster information using Kafka admin client. schema.history.internal.kafka.create.timeout.ms 30000 An integer value that specifies the maximum number of milliseconds the connector should wait while create kafka history topic using Kafka admin client. schema.history.internal.kafka.recovery.attempts 100 The maximum number of times that the connector should try to read persisted history data before the connector recovery fails with an error. The maximum amount of time to wait after receiving no data is recovery.attempts x recovery.poll.interval.ms . schema.history.internal.skip.unparseable.ddl false A Boolean value that specifies whether the connector should ignore malformed or unknown database statements or stop processing so a human can fix the issue. The safe default is false . Skipping should be used only with care as it can lead to data loss or mangling when the binlog is being processed. schema.history.internal.store.only.captured.tables.ddl false A Boolean value that specifies whether the connector records schema structures from all tables in a schema or database, or only from tables that are designated for capture. Specify one of the following values: false (default) During a database snapshot, the connector records the schema data for all non-system tables in the database, including tables that are not designated for capture. It's best to retain the default setting. If you later decide to capture changes from tables that you did not originally designate for capture, the connector can easily begin to capture data from those tables, because their schema structure is already stored in the schema history topic. Debezium requires the schema history of a table so that it can identify the structure that was present at the time that a change event occurred. true During a database snapshot, the connector records the table schemas only for the tables from which Debezium captures change events. If you change the default value, and you later configure the connector to capture data from other tables in the database, the connector lacks the schema information that it requires to capture change events from the tables. schema.history.internal.store.only.captured.databases.ddl true A Boolean value that specifies whether the connector records schema structures from all logical databases in the database instance. Specify one of the following values: true The connector records schema structures only for tables in the logical database and schema from which Debezium captures change events. false The connector records schema structures for all logical databases. Pass-through MySQL connector configuration properties You can set pass-through properties in the connector configuration to customize the behavior of the Apache Kafka producer and consumer. For information about the full range of configuration properties for Kafka producers and consumers, see the Kafka documentation . Pass-through properties for configuring how producer and consumer clients interact with schema history topics Debezium relies on an Apache Kafka producer to write schema changes to database schema history topics. Similarly, it relies on a Kafka consumer to read from database schema history topics when a connector starts. You define the configuration for the Kafka producer and consumer clients by assigning values to a set of pass-through configuration properties that begin with the schema.history.internal.producer.* and schema.history.internal.consumer.* prefixes. The pass-through producer and consumer database schema history properties control a range of behaviors, such as how these clients secure connections with the Kafka broker, as shown in the following example: Debezium strips the prefix from the property name before it passes the property to the Kafka client. For more information about Kafka producer configuration properties and Kafka consumer configuration properties , see the Apache Kafka documentation . Pass-through properties for configuring how the MySQL connector interacts with the Kafka signaling topic Debezium provides a set of signal.* properties that control how the connector interacts with the Kafka signals topic. The following table describes the Kafka signal properties. Table 2.103. Kafka signals configuration properties Property Default Description signal.kafka.topic <topic.prefix>-signal The name of the Kafka topic that the connector monitors for ad hoc signals. Note If automatic topic creation is disabled, you must manually create the required signaling topic. A signaling topic is required to preserve signal ordering. The signaling topic must have a single partition. signal.kafka.groupId kafka-signal The name of the group ID that is used by Kafka consumers. signal.kafka.bootstrap.servers No default A list of the host and port pairs that the connector uses to establish its initial connection to the Kafka cluster. Each pair references the Kafka cluster that is used by the Debezium Kafka Connect process. signal.kafka.poll.timeout.ms 100 An integer value that specifies the maximum number of milliseconds that the connector waits when polling signals. kafka.consumer.offset.commit.enabled false Specifies whether the Kafka consumer writes an offset commit after it reads a message from the signaling topic. The value that you assign to this property determines whether the connector can process requests that the signaling topic receives while the connector is offline. Choose one of the following settings: false When the connector is unavailable, the Kafka consumer does not commit an offset after it reads a signal received by the signaling topic. As a result, if the connector is offline for any interval, it cannot process requests that the signaling topic receives during the downtime. After the connector restarts, it always reads from the last position in the Kafka signaling topic, processing only signals that it receives after the restart. Signals received while the connector is offline are ignored, and are effectively lost. true When a user submits a request to the signaling topic, after the Kafka consumer reads the signal message it commits a topic offset, even if the connector is offline. Choose this option to provide Debezium with information about the last signal message that the consumer read, helping to ensure At-Least-Once delivery. After a connector restarts, it resumes processing from the last recorded offset, responding to signals that users submitted while the connector is offline. Pass-through properties for configuring the Kafka consumer client for the signaling channel The Debezium connector provides for pass-through configuration of the signals Kafka consumer. Pass-through signals properties begin with the prefix signals.consumer.* . For example, the connector passes properties such as signal.consumer.security.protocol=SSL to the Kafka consumer. Debezium strips the prefixes from the properties before it passes the properties to the Kafka signals consumer. Pass-through properties for configuring the MySQL connector sink notification channel The following table describes properties that you can use to configure the Debezium sink notification channel. Table 2.104. Sink notification configuration properties Property Default Description notification.sink.topic.name No default The name of the topic that receives notifications from Debezium. This property is required when you configure the notification.enabled.channels property to include sink as one of the enabled notification channels. Debezium connector pass-through database driver configuration properties The Debezium connector provides for pass-through configuration of the database driver. Pass-through database properties begin with the prefix driver.* . For example, the connector passes properties such as driver.foobar=false to the JDBC URL. Debezium strips the prefixes from the properties before it passes the properties to the database driver. 2.4.7. Monitoring Debezium MySQL connector performance The Debezium MySQL connector provides three types of metrics that are in addition to the built-in support for JMX metrics that Zookeeper, Kafka, and Kafka Connect provide. Snapshot metrics provide information about connector operation while performing a snapshot. Streaming metrics provide information about connector operation when the connector is reading the binlog. Schema history metrics provide information about the status of the connector's schema history. Debezium monitoring documentation provides details for how to expose these metrics by using JMX. 2.4.7.1. Customized names for MySQL connector snapshot and streaming MBean objects Debezium connectors expose metrics via the MBean name for the connector. These metrics, which are specific to each connector instance, provide data about the behavior of the connector's snapshot, streaming, and schema history processes. By default, when you deploy a correctly configured connector, Debezium generates a unique MBean name for each of the different connector metrics. To view the metrics for a connector process, you configure your observability stack to monitor its MBean. But these default MBean names depend on the connector configuration; configuration changes can result in changes to the MBean names. A change to the MBean name breaks the linkage between the connector instance and the MBean, disrupting monitoring activity. In this scenario, you must reconfigure the observability stack to use the new MBean name if you want to resume monitoring. To prevent monitoring disruptions that result from MBean name changes, you can configure custom metrics tags. You configure custom metrics by adding the custom.metric.tags property to the connector configuration. The property accepts key-value pairs in which each key represents a tag for the MBean object name, and the corresponding value represents the value of that tag. For example: k1=v1,k2=v2 . Debezium appends the specified tags to the MBean name of the connector. After you configure the custom.metric.tags property for a connector, you can configure the observability stack to retrieve metrics associated with the specified tags. The observability stack then uses the specified tags, rather than the mutable MBean names to uniquely identify connectors. Later, if Debezium redefines how it constructs MBean names, or if the topic.prefix in the connector configuration changes, metrics collection is uninterrupted, because the metrics scrape task uses the specified tag patterns to identify the connector. A further benefit of using custom tags, is that you can use tags that reflect the architecture of your data pipeline, so that metrics are organized in a way that suits you operational needs. For example, you might specify tags with values that declare the type of connector activity, the application context, or the data source, for example, db1-streaming-for-application-abc . If you specify multiple key-value pairs, all of the specified pairs are appended to the connector's MBean name. The following example illustrates how tags modify the default MBean name. Example 2.31. How custom tags modify the connector MBean name By default, the MySQL connector uses the following MBean name for streaming metrics: If you set the value of custom.metric.tags to database=salesdb-streaming,table=inventory , Debezium generates the following custom MBean name: 2.4.7.2. Monitoring Debezium during snapshots of MySQL databases The MBean is debezium.mysql:type=connector-metrics,context=snapshot,server= <topic.prefix> . Snapshot metrics are not exposed unless a snapshot operation is active, or if a snapshot has occurred since the last connector start. The following table lists the snapshot metrics that are available. Attributes Type Description LastEvent string The last snapshot event that the connector has read. MilliSecondsSinceLastEvent long The number of milliseconds since the connector has read and processed the most recent event. TotalNumberOfEventsSeen long The total number of events that this connector has seen since last started or reset. NumberOfEventsFiltered long The number of events that have been filtered by include/exclude list filtering rules configured on the connector. CapturedTables string[] The list of tables that are captured by the connector. QueueTotalCapacity int The length the queue used to pass events between the snapshotter and the main Kafka Connect loop. QueueRemainingCapacity int The free capacity of the queue used to pass events between the snapshotter and the main Kafka Connect loop. TotalTableCount int The total number of tables that are being included in the snapshot. RemainingTableCount int The number of tables that the snapshot has yet to copy. SnapshotRunning boolean Whether the snapshot was started. SnapshotPaused boolean Whether the snapshot was paused. SnapshotAborted boolean Whether the snapshot was aborted. SnapshotCompleted boolean Whether the snapshot completed. SnapshotDurationInSeconds long The total number of seconds that the snapshot has taken so far, even if not complete. Includes also time when snapshot was paused. SnapshotPausedDurationInSeconds long The total number of seconds that the snapshot was paused. If the snapshot was paused several times, the paused time adds up. RowsScanned Map<String, Long> Map containing the number of rows scanned for each table in the snapshot. Tables are incrementally added to the Map during processing. Updates every 10,000 rows scanned and upon completing a table. MaxQueueSizeInBytes long The maximum buffer of the queue in bytes. This metric is available if max.queue.size.in.bytes is set to a positive long value. CurrentQueueSizeInBytes long The current volume, in bytes, of records in the queue. The connector also provides the following additional snapshot metrics when an incremental snapshot is executed: Attributes Type Description ChunkId string The identifier of the current snapshot chunk. ChunkFrom string The lower bound of the primary key set defining the current chunk. ChunkTo string The upper bound of the primary key set defining the current chunk. TableFrom string The lower bound of the primary key set of the currently snapshotted table. TableTo string The upper bound of the primary key set of the currently snapshotted table. 2.4.7.3. Monitoring Debezium MySQL connector record streaming The Debezium MySQL connector provides three types of metrics that are in addition to the built-in support for JMX metrics that Zookeeper, Kafka, and Kafka Connect provide. Snapshot metrics provide information about connector operation while performing a snapshot. Streaming metrics provide information about connector operation when the connector is reading the binlog. Schema history metrics provide information about the status of the connector's schema history. Debezium monitoring documentation provides details for how to expose these metrics by using JMX. The MBean is debezium.mysql:type=connector-metrics,context=streaming,server= <topic.prefix> . The following table lists the streaming metrics that are available. Attributes Type Description LastEvent string The last streaming event that the connector has read. MilliSecondsSinceLastEvent long The number of milliseconds since the connector has read and processed the most recent event. TotalNumberOfEventsSeen long The total number of data change events reported by the source database since the last connector start, or since a metrics reset. Represents the data change workload for Debezium to process. TotalNumberOfCreateEventsSeen long The total number of create events processed by the connector since its last start or metrics reset. TotalNumberOfUpdateEventsSeen long The total number of update events processed by the connector since its last start or metrics reset. TotalNumberOfDeleteEventsSeen long The total number of delete events processed by the connector since its last start or metrics reset. NumberOfEventsFiltered long The number of events that have been filtered by include/exclude list filtering rules configured on the connector. CapturedTables string[] The list of tables that are captured by the connector. QueueTotalCapacity int The length the queue used to pass events between the streamer and the main Kafka Connect loop. QueueRemainingCapacity int The free capacity of the queue used to pass events between the streamer and the main Kafka Connect loop. Connected boolean Flag that denotes whether the connector is currently connected to the database server. MilliSecondsBehindSource long The number of milliseconds between the last change event's timestamp and the connector processing it. The values will incorporate any differences between the clocks on the machines where the database server and the connector are running. NumberOfCommittedTransactions long The number of processed transactions that were committed. SourceEventPosition Map<String, String> The coordinates of the last received event. LastTransactionId string Transaction identifier of the last processed transaction. MaxQueueSizeInBytes long The maximum buffer of the queue in bytes. This metric is available if max.queue.size.in.bytes is set to a positive long value. CurrentQueueSizeInBytes long The current volume, in bytes, of records in the queue. 2.4.7.4. Monitoring Debezium MySQL connector schema history The MBean is debezium.mysql:type=connector-metrics,context=schema-history,server= <topic.prefix> . The following table lists the schema history metrics that are available. Attributes Type Description Status string One of STOPPED , RECOVERING (recovering history from the storage), RUNNING describing the state of the database schema history. RecoveryStartTime long The time in epoch seconds at what recovery has started. ChangesRecovered long The number of changes that were read during recovery phase. ChangesApplied long the total number of schema changes applied during recovery and runtime. MilliSecondsSinceLast RecoveredChange long The number of milliseconds that elapsed since the last change was recovered from the history store. MilliSecondsSinceLast AppliedChange long The number of milliseconds that elapsed since the last change was applied. LastRecoveredChange string The string representation of the last change recovered from the history store. LastAppliedChange string The string representation of the last applied change. 2.4.8. How Debezium MySQL connectors handle faults and problems Debezium is a distributed system that captures all changes in multiple upstream databases; it never misses or loses an event. When the system is operating normally or being managed carefully then Debezium provides exactly once delivery of every change event record. If a fault does occur, the system does not lose any events. However, while Debezium is recovering from a fault, it might repeat some change events. In these abnormal situations, Debezium, like Kafka, provides at least once delivery of change events. Details are in the following sections: Configuration and startup errors MySQL becomes unavailable Kafka Connect stops gracefully Kafka Connect process crashes Kafka becomes unavailable MySQL purges binlog files Configuration and startup errors In the following situations, the connector fails when trying to start, reports an error or exception in the log, and stops running: The connector's configuration is invalid. The connector cannot successfully connect to the MySQL server by using the specified connection parameters. The connector is attempting to restart at a position in the binlog for which MySQL no longer has the history available. In these cases, the error message has details about the problem and possibly a suggested workaround. After you correct the configuration or address the MySQL problem, restart the connector. MySQL becomes unavailable If your MySQL server becomes unavailable, the Debezium MySQL connector fails with an error and the connector stops. When the server is available again, restart the connector. However, if you are connecting to a highly available MySQL cluster, you can restart the connector immediately. It will connect to a different MySQL server in the cluster, find the location in the server's binlog that represents the last transaction, and begin reading the new server's binlog from that specific location. Kafka Connect stops gracefully When Kafka Connect stops gracefully, there is a short delay while the Debezium MySQL connector tasks are stopped and restarted on new Kafka Connect processes. Kafka Connect process crashes If Kafka Connect crashes, the process stops and any Debezium MySQL connector tasks terminate without their most recently-processed offsets being recorded. In distributed mode, Kafka Connect restarts the connector tasks on other processes. However, the MySQL connector resumes from the last offset recorded by the earlier processes. As a result, the replacement tasks might regenerate some events that were processed before the crash, creating duplicate events. Each change event message includes source-specific information that you can use to identify duplicate events, for example: Event origin MySQL server's event time The binlog file name and position GTIDs, if used Kafka becomes unavailable The Kafka Connect framework records Debezium change events in Kafka by using the Kafka producer API. If the Kafka brokers become unavailable, the Debezium MySQL connector pauses until the connection is reestablished, and the connector then resumes where it left off. MySQL purges binlog files If the Debezium MySQL connector stops for too long, the MySQL server purges older binlog files and the connector's last position may be lost. When the connector is restarted, the MySQL server no longer has the starting point and the connector performs another initial snapshot. If the snapshot is disabled, the connector fails with an error. See snapshots for details about how MySQL connectors perform initial snapshots. 2.5. Debezium Connector for Oracle Debezium's Oracle connector captures and records row-level changes that occur in databases on an Oracle server, including tables that are added while the connector is running. You can configure the connector to emit change events for specific subsets of schemas and tables, or to ignore, mask, or truncate values in specific columns. For information about the Oracle Database versions that are compatible with this connector, see the Debezium Supported Configurations page . Debezium ingests change events from Oracle by using the native LogMiner database package . Information and procedures for using a Debezium Oracle connector are organized as follows: Section 2.5.1, "How Debezium Oracle connectors work" Section 2.5.2, "Descriptions of Debezium Oracle connector data change events" Section 2.5.3, "How Debezium Oracle connectors map data types" Section 2.5.4, "Setting up Oracle to work with Debezium" Custom converters Section 2.5.5, "Deployment of Debezium Oracle connectors" Section 2.5.6, "Descriptions of Debezium Oracle connector configuration properties" Section 2.5.7, "Monitoring Debezium Oracle connector performance" Section 2.5.8, "Oracle connector frequently asked questions" 2.5.1. How Debezium Oracle connectors work To optimally configure and run a Debezium Oracle connector, it is helpful to understand how the connector performs snapshots, streams change events, determines Kafka topic names, uses metadata, and implements event buffering. For more information, see the following topics: Section 2.5.1.1, "How Debezium Oracle connectors perform database snapshots" Section 2.5.1.2, "Ad hoc snapshots" Section 2.5.1.3, "Incremental snapshots" Section 2.5.1.5, "Default names of Kafka topics that receive Debezium Oracle change event records" Section 2.5.1.7, "How Debezium Oracle connectors expose database schema changes" Section 2.5.1.8, "Debezium Oracle connector-generated events that represent transaction boundaries" Section 2.5.1.9, "How the Debezium Oracle connector uses event buffering" 2.5.1.1. How Debezium Oracle connectors perform database snapshots Typically, the redo logs on an Oracle server are configured to not retain the complete history of the database. As a result, the Debezium Oracle connector cannot retrieve the entire history of the database from the logs. To enable the connector to establish a baseline for the current state of the database, the first time that the connector starts, it performs an initial consistent snapshot of the database. Note If the time needed to complete the initial snapshot exceeds the UNDO_RETENTION time that is set for the database (fifteen minutes, by default), an ORA-01555 exception can occur. For more information about the error, and about the steps that you can take to recover from it, see the Frequently asked questions . Important During a table's snapshot, it's possible for Oracle to raise an ORA-01466 exception. This happens when a user modifies the schema of the table or adds, changes, or drops an index or related object associated with the table being snapshot. In the event this happens, the connector will stop and the initial snapshot will need to be taken from the beginning. To remediate the problem, you can configure the snapshot.database.errors.max.retries property with a value greater than 0 so that the specific table's snapshot will restart. While the entire snapshot will not start from the beginning when retrying, the specific table in question will be re-read from the beginning and the table's topic will contain duplicate snapshot events. You can find more information about snapshots in the following sections: Section 2.5.1.2, "Ad hoc snapshots" Section 2.5.1.3, "Incremental snapshots" 2.5.1.1.1. Default workflow that the Oracle connector uses to perform an initial snapshot The following workflow lists the steps that Debezium takes to create a snapshot. These steps describe the process for a snapshot when the snapshot.mode configuration property is set to its default value, which is initial . You can customize the way that the connector creates snapshots by changing the value of the snapshot.mode property. If you configure a different snapshot mode, the connector completes the snapshot by using a modified version of this workflow. When the snapshot mode is set to the default, the connector completes the following tasks to create a snapshot: Establish a connection to the database. Determine the tables to be captured. By default, the connector captures all tables except those with schemas that exclude them from capture . After the snapshot completes, the connector continues to stream data for the specified tables. If you want the connector to capture data only from specific tables you can direct the connector to capture the data for only a subset of tables or table elements by setting properties such as table.include.list or table.exclude.list . Obtain a ROW SHARE MODE lock on each of the captured tables to prevent structural changes from occurring during creation of the snapshot. Debezium holds the locks for only a short time. Read the current system change number (SCN) position from the server's redo log. Capture the structure of all database tables, or all tables that are designated for capture. The connector persists schema information in its internal database schema history topic. The schema history provides information about the structure that is in effect when a change event occurs. Note By default, the connector captures the schema of every table in the database that is in capture mode, including tables that are not configured for capture. If tables are not configured for capture, the initial snapshot captures only their structure; it does not capture any table data. For more information about why snapshots persist schema information for tables that you did not include in the initial snapshot, see Understanding why initial snapshots capture the schema for all tables . Release the locks obtained in Step 3. Other database clients can now write to any previously locked tables. At the SCN position that was read in Step 4, the connector scans the tables that are designated for capture ( SELECT * FROM ... AS OF SCN 123 ). During the scan, the connector completes the following tasks: Confirms that the table was created before the snapshot began. If the table was created after the snapshot began, the connector skips the table. After the snapshot is complete, and the connector transitions to streaming, it emits change events for any tables that were created after the snapshot began. Produces a read event for each row that is captured from a table. All read events contain the same SCN position, which is the SCN position that was obtained in step 4. Emits each read event to the Kafka topic for the source table. Releases data table locks, if applicable. Record the successful completion of the snapshot in the connector offsets. The resulting initial snapshot captures the current state of each row in the captured tables. From this baseline state, the connector captures subsequent changes as they occur. After the snapshot process begins, if the process is interrupted due to connector failure, rebalancing, or other reasons, the process restarts after the connector restarts. After the connector completes the initial snapshot, it continues streaming from the position that it read in Step 3 so that it does not miss any updates. If the connector stops again for any reason, after it restarts, it resumes streaming changes from where it previously left off. Table 2.105. Settings for snapshot.mode connector configuration property Setting Description always Perform snapshot on each connector start. After the snapshot completes, the connector begins to stream event records for subsequent database changes. initial The connector performs a database snapshot as described in the default workflow for creating an initial snapshot . After the snapshot completes, the connector begins to stream event records for subsequent database changes. initial_only The connector performs a database snapshot and stops before streaming any change event records, not allowing any subsequent change events to be captured. schema_only Deprecated, see no_data . no_data The connector captures the structure of all relevant tables, performing all of the steps described in the default snapshot workflow , except that it does not create READ events to represent the data set at the point of the connector's start-up (Step 6). schema_only_recovery Deprecated, see recovery . recovery Set this option to restore a database schema history topic that is lost or corrupted. After a restart, the connector runs a snapshot that rebuilds the topic from the source tables. You can also set the property to periodically prune a database schema history topic that experiences unexpected growth. WARNING: Do not use this mode to perform a snapshot if schema changes were committed to the database after the last connector shutdown. when_needed After the connector starts, it performs a snapshot only if it detects one of the following circumstances: It cannot detect any topic offsets. A previously recorded offset specifies a log position that is not available on the server. For more information, see snapshot.mode in the table of connector configuration properties. 2.5.1.1.2. Description of why initial snapshots capture the schema history for all tables The initial snapshot that a connector runs captures two types of information: Table data Information about INSERT , UPDATE , and DELETE operations in tables that are named in the connector's table.include.list property. Schema data DDL statements that describe the structural changes that are applied to tables. Schema data is persisted to both the internal schema history topic, and to the connector's schema change topic, if one is configured. After you run an initial snapshot, you might notice that the snapshot captures schema information for tables that are not designated for capture. By default, initial snapshots are designed to capture schema information for every table that is present in the database, not only from tables that are designated for capture. Connectors require that the table's schema is present in the schema history topic before they can capture a table. By enabling the initial snapshot to capture schema data for tables that are not part of the original capture set, Debezium prepares the connector to readily capture event data from these tables should that later become necessary. If the initial snapshot does not capture a table's schema, you must add the schema to the history topic before the connector can capture data from the table. In some cases, you might want to limit schema capture in the initial snapshot. This can be useful when you want to reduce the time required to complete a snapshot. Or when Debezium connects to the database instance through a user account that has access to multiple logical databases, but you want the connector to capture changes only from tables in a specific logic database. Additional information Capturing data from tables not captured by the initial snapshot (no schema change) Capturing data from tables not captured by the initial snapshot (schema change) Setting the schema.history.internal.store.only.captured.tables.ddl property to specify the tables from which to capture schema information. Setting the schema.history.internal.store.only.captured.databases.ddl property to specify the logical databases from which to capture schema changes. 2.5.1.1.3. Capturing data from tables not captured by the initial snapshot (no schema change) In some cases, you might want the connector to capture data from a table whose schema was not captured by the initial snapshot. Depending on the connector configuration, the initial snapshot might capture the table schema only for specific tables in the database. If the table schema is not present in the history topic, the connector fails to capture the table, and reports a missing schema error. You might still be able to capture data from the table, but you must perform additional steps to add the table schema. Prerequisites You want to capture data from a table with a schema that the connector did not capture during the initial snapshot. All entries for the table in the transaction log use the same schema. For information about capturing data from a new table that has undergone structural changes, see Section 2.5.1.1.4, "Capturing data from tables not captured by the initial snapshot (schema change)" . Procedure Stop the connector. Remove the internal database schema history topic that is specified by the schema.history.internal.kafka.topic property . In the connector configuration: Set the snapshot.mode to schema_only_recovery . (Optional) Set the value of schema.history.internal.store.only.captured.tables.ddl to false to ensure that in the future the connector can readily capture data for tables that are not currently designated for capture. Connectors can capture data from a table only if the table's schema history is present in the history topic. Add the tables that you want the connector to capture to table.include.list . Restart the connector. The snapshot recovery process rebuilds the schema history based on the current structure of the tables. (Optional) After the snapshot completes, initiate an incremental snapshot on the newly added tables. The incremental snapshot first streams the historical data of the newly added tables, and then resumes reading changes from the redo and archive logs for previously configured tables, including changes that occur while that connector was off-line. (Optional) Reset the snapshot.mode back to schema_only to prevent the connector from initiating recovery after a future restart. 2.5.1.1.4. Capturing data from tables not captured by the initial snapshot (schema change) If a schema change is applied to a table, records that are committed before the schema change have different structures than those that were committed after the change. When Debezium captures data from a table, it reads the schema history to ensure that it applies the correct schema to each event. If the schema is not present in the schema history topic, the connector is unable to capture the table, and an error results. If you want to capture data from a table that was not captured by the initial snapshot, and the schema of the table was modified, you must add the schema to the history topic, if it is not already available. You can add the schema by running a new schema snapshot, or by running an initial snapshot for the table. Prerequisites You want to capture data from a table with a schema that the connector did not capture during the initial snapshot. A schema change was applied to the table so that the records to be captured do not have a uniform structure. Procedure Initial snapshot captured the schema for all tables ( store.only.captured.tables.ddl was set to false ) Edit the table.include.list property to specify the tables that you want to capture. Restart the connector. Initiate an incremental snapshot if you want to capture existing data from the newly added tables. Initial snapshot did not capture the schema for all tables ( store.only.captured.tables.ddl was set to true ) If the initial snapshot did not save the schema of the table that you want to capture, complete one of the following procedures: Procedure 1: Schema snapshot, followed by incremental snapshot In this procedure, the connector first performs a schema snapshot. You can then initiate an incremental snapshot to enable the connector to synchronize data. Stop the connector. Remove the internal database schema history topic that is specified by the schema.history.internal.kafka.topic property . Clear the offsets in the configured Kafka Connect offset.storage.topic . For more information about how to remove offsets, see the Debezium community FAQ . Warning Removing offsets should be performed only by advanced users who have experience in manipulating internal Kafka Connect data. This operation is potentially destructive, and should be performed only as a last resort. Set values for properties in the connector configuration as described in the following steps: Set the value of the snapshot.mode property to schema_only . Edit the table.include.list to add the tables that you want to capture. Restart the connector. Wait for Debezium to capture the schema of the new and existing tables. Data changes that occurred any tables after the connector stopped are not captured. To ensure that no data is lost, initiate an incremental snapshot . Procedure 2: Initial snapshot, followed by optional incremental snapshot In this procedure the connector performs a full initial snapshot of the database. As with any initial snapshot, in a database with many large tables, running an initial snapshot can be a time-consuming operation. After the snapshot completes, you can optionally trigger an incremental snapshot to capture any changes that occur while the connector is off-line. Stop the connector. Remove the internal database schema history topic that is specified by the schema.history.internal.kafka.topic property . Clear the offsets in the configured Kafka Connect offset.storage.topic . For more information about how to remove offsets, see the Debezium community FAQ . Warning Removing offsets should be performed only by advanced users who have experience in manipulating internal Kafka Connect data. This operation is potentially destructive, and should be performed only as a last resort. Edit the table.include.list to add the tables that you want to capture. Set values for properties in the connector configuration as described in the following steps: Set the value of the snapshot.mode property to initial . (Optional) Set schema.history.internal.store.only.captured.tables.ddl to false . Restart the connector. The connector takes a full database snapshot. After the snapshot completes, the connector transitions to streaming. (Optional) To capture any data that changed while the connector was off-line, initiate an incremental snapshot . 2.5.1.2. Ad hoc snapshots By default, a connector runs an initial snapshot operation only after it starts for the first time. Following this initial snapshot, under normal circumstances, the connector does not repeat the snapshot process. Any future change event data that the connector captures comes in through the streaming process only. However, in some situations the data that the connector obtained during the initial snapshot might become stale, lost, or incomplete. To provide a mechanism for recapturing table data, Debezium includes an option to perform ad hoc snapshots. You might want to perform an ad hoc snapshot after any of the following changes occur in your Debezium environment: The connector configuration is modified to capture a different set of tables. Kafka topics are deleted and must be rebuilt. Data corruption occurs due to a configuration error or some other problem. You can re-run a snapshot for a table for which you previously captured a snapshot by initiating a so-called ad-hoc snapshot . Ad hoc snapshots require the use of signaling tables . You initiate an ad hoc snapshot by sending a signal request to the Debezium signaling table. When you initiate an ad hoc snapshot of an existing table, the connector appends content to the topic that already exists for the table. If a previously existing topic was removed, Debezium can create a topic automatically if automatic topic creation is enabled. Ad hoc snapshot signals specify the tables to include in the snapshot. The snapshot can capture the entire contents of the database, or capture only a subset of the tables in the database. Also, the snapshot can capture a subset of the contents of the table(s) in the database. You specify the tables to capture by sending an execute-snapshot message to the signaling table. Set the type of the execute-snapshot signal to incremental or blocking , and provide the names of the tables to include in the snapshot, as described in the following table: Table 2.106. Example of an ad hoc execute-snapshot signal record Field Default Value type incremental Specifies the type of snapshot that you want to run. Currently, you can request incremental or blocking snapshots. data-collections N/A An array that contains regular expressions matching the fully-qualified names of the tables to include in the snapshot. For the Oracle connector, use the following format to specify the fully qualified name of a table: database.schema.table . additional-conditions N/A An optional array that specifies a set of additional conditions that the connector evaluates to determine the subset of records to include in a snapshot. Each additional condition is an object that specifies the criteria for filtering the data that an ad hoc snapshot captures. You can set the following parameters for each additional condition: data-collection The fully-qualified name of the table that the filter applies to. You can apply different filters to each table. filter Specifies column values that must be present in a database record for the snapshot to include it, for example, "color='blue'" . The values that you assign to the filter parameter are the same types of values that you might specify in the WHERE clause of SELECT statements when you set the snapshot.select.statement.overrides property for a blocking snapshot. surrogate-key N/A An optional string that specifies the column name that the connector uses as the primary key of a table during the snapshot process. Triggering an ad hoc incremental snapshot You initiate an ad hoc incremental snapshot by adding an entry with the execute-snapshot signal type to the signaling table, or by sending a signal message to a Kafka signaling topic . After the connector processes the message, it begins the snapshot operation. The snapshot process reads the first and last primary key values and uses those values as the start and end point for each table. Based on the number of entries in the table, and the configured chunk size, Debezium divides the table into chunks, and proceeds to snapshot each chunk, in succession, one at a time. For more information, see Incremental snapshots . Triggering an ad hoc blocking snapshot You initiate an ad hoc blocking snapshot by adding an entry with the execute-snapshot signal type to the signaling table or signaling topic. After the connector processes the message, it begins the snapshot operation. The connector temporarily stops streaming, and then initiates a snapshot of the specified table, following the same process that it uses during an initial snapshot. After the snapshot completes, the connector resumes streaming. For more information, see Blocking snapshots . 2.5.1.3. Incremental snapshots To provide flexibility in managing snapshots, Debezium includes a supplementary snapshot mechanism, known as incremental snapshotting . Incremental snapshots rely on the Debezium mechanism for sending signals to a Debezium connector . In an incremental snapshot, instead of capturing the full state of a database all at once, as in an initial snapshot, Debezium captures each table in phases, in a series of configurable chunks. You can specify the tables that you want the snapshot to capture and the size of each chunk . The chunk size determines the number of rows that the snapshot collects during each fetch operation on the database. The default chunk size for incremental snapshots is 1024 rows. As an incremental snapshot proceeds, Debezium uses watermarks to track its progress, maintaining a record of each table row that it captures. This phased approach to capturing data provides the following advantages over the standard initial snapshot process: You can run incremental snapshots in parallel with streamed data capture, instead of postponing streaming until the snapshot completes. The connector continues to capture near real-time events from the change log throughout the snapshot process, and neither operation blocks the other. If the progress of an incremental snapshot is interrupted, you can resume it without losing any data. After the process resumes, the snapshot begins at the point where it stopped, rather than recapturing the table from the beginning. You can run an incremental snapshot on demand at any time, and repeat the process as needed to adapt to database updates. For example, you might re-run a snapshot after you modify the connector configuration to add a table to its table.include.list property. Incremental snapshot process When you run an incremental snapshot, Debezium sorts each table by primary key and then splits the table into chunks based on the configured chunk size . Working chunk by chunk, it then captures each table row in a chunk. For each row that it captures, the snapshot emits a READ event. That event represents the value of the row when the snapshot for the chunk began. As a snapshot proceeds, it's likely that other processes continue to access the database, potentially modifying table records. To reflect such changes, INSERT , UPDATE , or DELETE operations are committed to the transaction log as per usual. Similarly, the ongoing Debezium streaming process continues to detect these change events and emits corresponding change event records to Kafka. How Debezium resolves collisions among records with the same primary key In some cases, the UPDATE or DELETE events that the streaming process emits are received out of sequence. That is, the streaming process might emit an event that modifies a table row before the snapshot captures the chunk that contains the READ event for that row. When the snapshot eventually emits the corresponding READ event for the row, its value is already superseded. To ensure that incremental snapshot events that arrive out of sequence are processed in the correct logical order, Debezium employs a buffering scheme for resolving collisions. Only after collisions between the snapshot events and the streamed events are resolved does Debezium emit an event record to Kafka. Snapshot window To assist in resolving collisions between late-arriving READ events and streamed events that modify the same table row, Debezium employs a so-called snapshot window . The snapshot window demarcates the interval during which an incremental snapshot captures data for a specified table chunk. Before the snapshot window for a chunk opens, Debezium follows its usual behavior and emits events from the transaction log directly downstream to the target Kafka topic. But from the moment that the snapshot for a particular chunk opens, until it closes, Debezium performs a de-duplication step to resolve collisions between events that have the same primary key.. For each data collection, the Debezium emits two types of events, and stores the records for them both in a single destination Kafka topic. The snapshot records that it captures directly from a table are emitted as READ operations. Meanwhile, as users continue to update records in the data collection, and the transaction log is updated to reflect each commit, Debezium emits UPDATE or DELETE operations for each change. As the snapshot window opens, and Debezium begins processing a snapshot chunk, it delivers snapshot records to a memory buffer. During the snapshot windows, the primary keys of the READ events in the buffer are compared to the primary keys of the incoming streamed events. If no match is found, the streamed event record is sent directly to Kafka. If Debezium detects a match, it discards the buffered READ event, and writes the streamed record to the destination topic, because the streamed event logically supersede the static snapshot event. After the snapshot window for the chunk closes, the buffer contains only READ events for which no related transaction log events exist. Debezium emits these remaining READ events to the table's Kafka topic. The connector repeats the process for each snapshot chunk. Currently, you can use either of the following methods to initiate an incremental snapshot: Send an ad hoc snapshot signal to the signaling table on the source database . Send a message to a configured Kafka signaling topic . Warning The Debezium connector for Oracle does not support schema changes while an incremental snapshot is running. 2.5.1.3.1. Triggering an incremental snapshot To initiate an incremental snapshot, you can send an ad hoc snapshot signal to the signaling table on the source database. You submit snapshot signals as SQL INSERT queries. After Debezium detects the change in the signaling table, it reads the signal, and runs the requested snapshot operation. The query that you submit specifies the tables to include in the snapshot, and, optionally, specifies the type of snapshot operation. Debezium currently supports the incremental and blocking snapshot types. To specify the tables to include in the snapshot, provide a data-collections array that lists the tables, or an array of regular expressions used to match tables, for example, {"data-collections": ["public.MyFirstTable", "public.MySecondTable"]} The data-collections array for an incremental snapshot signal has no default value. If the data-collections array is empty, Debezium interprets the empty array to mean that no action is required, and it does not perform a snapshot. Note If the name of a table that you want to include in a snapshot contains a dot ( . ), a space, or some other non-alphanumeric character, you must escape the table name in double quotes. For example, to include a table that exists in the public schema in the db1 database, and that has the name My.Table , use the following format: "db1.public.\"My.Table\"" . Prerequisites Signaling is enabled . A signaling data collection exists on the source database. The signaling data collection is specified in the signal.data.collection property. Using a source signaling channel to trigger an incremental snapshot Send a SQL query to add the ad hoc incremental snapshot request to the signaling table: INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}'); For example, INSERT INTO db1.myschema.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'execute-snapshot', 3 '{"data-collections": ["db1.schema1.table1", "db1.schema1.table2"], 4 "type":"incremental", 5 "additional-conditions":[{"data-collection": "db1.schema1.table1" ,"filter":"color=\'blue\'"}]}'); 6 The values of the id , type , and data parameters in the command correspond to the fields of the signaling table . The following table describes the parameters in the example: Table 2.107. Descriptions of fields in a SQL command for sending an incremental snapshot signal to the signaling table Item Value Description 1 database.schema.debezium_signal Specifies the fully-qualified name of the signaling table on the source database. 2 ad-hoc-1 The id parameter specifies an arbitrary string that is assigned as the id identifier for the signal request. Use this string to identify logging messages to entries in the signaling table. Debezium does not use this string. Rather, during the snapshot, Debezium generates its own id string as a watermarking signal. 3 execute-snapshot The type parameter specifies the operation that the signal is intended to trigger. 4 data-collections A required component of the data field of a signal that specifies an array of table names or regular expressions to match table names to include in the snapshot. The array lists regular expressions that use the format database.schema.table to match the fully-qualified names of the tables. This format is the same as the one that you use to specify the name of the connector's signaling table . 5 incremental An optional type component of the data field of a signal that specifies the type of snapshot operation to run. Valid values are incremental and blocking . If you do not specify a value, the connector defaults to performing an incremental snapshot. 6 additional-conditions An optional array that specifies a set of additional conditions that the connector evaluates to determine the subset of records to include in a snapshot. Each additional condition is an object with data-collection and filter properties. You can specify different filters for each data collection. * The data-collection property is the fully-qualified name of the data collection that the filter applies to. For more information about the additional-conditions parameter, see Section 2.5.1.3.2, "Running an ad hoc incremental snapshots with additional-conditions " . 2.5.1.3.2. Running an ad hoc incremental snapshots with additional-conditions If you want a snapshot to include only a subset of the content in a table, you can modify the signal request by appending an additional-conditions parameter to the snapshot signal. The SQL query for a typical snapshot takes the following form: SELECT * FROM <tableName> .... By adding an additional-conditions parameter, you append a WHERE condition to the SQL query, as in the following example: SELECT * FROM <data-collection> WHERE <filter> .... The following example shows a SQL query to send an ad hoc incremental snapshot request with an additional condition to the signaling table: INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}'); For example, suppose you have a products table that contains the following columns: id (primary key) color quantity If you want an incremental snapshot of the products table to include only the data items where color=blue , you can use the following SQL statement to trigger the snapshot: INSERT INTO db1.myschema.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["db1.schema1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "db1.schema1.products", "filter": "color=blue"}]}'); The additional-conditions parameter also enables you to pass conditions that are based on more than one column. For example, using the products table from the example, you can submit a query that triggers an incremental snapshot that includes the data of only those items for which color=blue and quantity>10 : INSERT INTO db1.myschema.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["db1.schema1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "db1.schema1.products", "filter": "color=blue AND quantity>10"}]}'); The following example, shows the JSON for an incremental snapshot event that is captured by a connector. Example 2.32. Incremental snapshot event message { "before":null, "after": { "pk":"1", "value":"New data" }, "source": { ... "snapshot":"incremental" 1 }, "op":"r", 2 "ts_ms":"1620393591654", "ts_us":"1620393591654547", "ts_ns":"1620393591654547920", "transaction":null } Table 2.108. Description of fields in an incremental snapshot event message Item Field name Description 1 snapshot Specifies the type of snapshot operation to run. Currently, the only valid options are blocking and incremental . Specifying a type value in the SQL query that you submit to the signaling table is optional. If you do not specify a value, the connector runs an incremental snapshot. 2 op Specifies the event type. The value for snapshot events is r , signifying a READ operation. 2.5.1.3.3. Using the Kafka signaling channel to trigger an incremental snapshot You can send a message to the configured Kafka topic to request the connector to run an ad hoc incremental snapshot. The key of the Kafka message must match the value of the topic.prefix connector configuration option. The value of the message is a JSON object with type and data fields. The signal type is execute-snapshot , and the data field must have the following fields: Table 2.109. Execute snapshot data fields Field Default Value type incremental The type of the snapshot to be executed. Currently Debezium supports the incremental and blocking types. See the section for more details. data-collections N/A An array of comma-separated regular expressions that match the fully-qualified names of tables to include in the snapshot. Specify the names by using the same format as is required for the signal.data.collection configuration option. additional-conditions N/A An optional array of additional conditions that specifies criteria that the connector evaluates to designate a subset of records to include in a snapshot. Each additional condition is an object that specifies the criteria for filtering the data that an ad hoc snapshot captures. You can set the following parameters for each additional condition: data-collection :: The fully-qualified name of the table that the filter applies to. You can apply different filters to each table. filter :: Specifies column values that must be present in a database record for the snapshot to include it, for example, "color='blue'" . The values that you assign to the filter parameter are the same types of values that you might specify in the WHERE clause of SELECT statements when you set the snapshot.select.statement.overrides property for a blocking snapshot. Example 2.33. An execute-snapshot Kafka message Ad hoc incremental snapshots with additional-conditions Debezium uses the additional-conditions field to select a subset of a table's content. Typically, when Debezium runs a snapshot, it runs a SQL query such as: SELECT * FROM <tableName> ... . When the snapshot request includes an additional-conditions property, the data-collection and filter parameters of the property are appended to the SQL query, for example: SELECT * FROM <data-collection> WHERE <filter> ... . For example, given a products table with the columns id (primary key), color , and brand , if you want a snapshot to include only content for which color='blue' , when you request the snapshot, you could add the additional-conditions property to filter the content: Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["db1.schema1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "db1.schema1.products" ,"filter":"color='blue'"}]}}` You can also use the additional-conditions property to pass conditions based on multiple columns. For example, using the same products table as in the example, if you want a snapshot to include only the content from the products table for which color='blue' , and brand='MyBrand' , you could send the following request: Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["db1.schema1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "db1.schema1.products" ,"filter":"color='blue' AND brand='MyBrand'"}]}}` 2.5.1.3.4. Stopping an incremental snapshot In some situations, it might be necessary to stop an incremental snapshot. For example, you might realize that snapshot was not configured correctly, or maybe you want to ensure that resources are available for other database operations. You can stop a snapshot that is already running by sending a signal to the signaling table on the source database. You submit a stop snapshot signal to the signaling table by sending it in a SQL INSERT query. The stop-snapshot signal specifies the type of the snapshot operation as incremental , and optionally specifies the tables that you want to omit from the currently running snapshot. After Debezium detects the change in the signaling table, it reads the signal, and stops the incremental snapshot operation if it's in progress. Additional resources You can also stop an incremental snapshot by sending a JSON message to the Kafka signaling topic . Prerequisites Signaling is enabled . A signaling data collection exists on the source database. The signaling data collection is specified in the signal.data.collection property. Using a source signaling channel to stop an incremental snapshot Send a SQL query to stop the ad hoc incremental snapshot to the signaling table: INSERT INTO <signalTable> (id, type, data) values ( '<id>' , 'stop-snapshot', '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":"incremental"}'); For example, INSERT INTO db1.myschema.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'stop-snapshot', 3 '{"data-collections": ["db1.schema1.table1", "db1.schema1.table2"], 4 "type":"incremental"}'); 5 The values of the id , type , and data parameters in the signal command correspond to the fields of the signaling table . The following table describes the parameters in the example: Table 2.110. Descriptions of fields in a SQL command for sending a stop incremental snapshot signal to the signaling table Item Value Description 1 database.schema.debezium_signal Specifies the fully-qualified name of the signaling table on the source database. 2 ad-hoc-1 The id parameter specifies an arbitrary string that is assigned as the id identifier for the signal request. Use this string to identify logging messages to entries in the signaling table. Debezium does not use this string. 3 stop-snapshot Specifies type parameter specifies the operation that the signal is intended to trigger. 4 data-collections An optional component of the data field of a signal that specifies an array of table names or regular expressions to match table names to remove from the snapshot. The array lists regular expressions which match tables by their fully-qualified names in the format database.schema.table If you omit this component from the data field, the signal stops the entire incremental snapshot that is in progress. 5 incremental A required component of the data field of a signal that specifies the type of snapshot operation that is to be stopped. Currently, the only valid option is incremental . If you do not specify a type value, the signal fails to stop the incremental snapshot. 2.5.1.3.5. Using the Kafka signaling channel to stop an incremental snapshot You can send a signal message to the configured Kafka signaling topic to stop an ad hoc incremental snapshot. The key of the Kafka message must match the value of the topic.prefix connector configuration option. The value of the message is a JSON object with type and data fields. The signal type is stop-snapshot , and the data field must have the following fields: Table 2.111. Execute snapshot data fields Field Default Value type incremental The type of the snapshot to be executed. Currently Debezium supports only the incremental type. See the section for more details. data-collections N/A An optional array of comma-separated regular expressions that match the fully-qualified names of the tables an array of table names or regular expressions to match table names to remove from the snapshot. Specify table names by using the format database.schema.table . The following example shows a typical stop-snapshot Kafka message: Key = `test_connector` Value = `{"type":"stop-snapshot","data": {"data-collections": ["db1.schema1.table1", "db1.schema1.table2"], "type": "INCREMENTAL"}}` 2.5.1.4. Blocking snapshots To provide more flexibility in managing snapshots, Debezium includes a supplementary ad hoc snapshot mechanism, known as a blocking snapshot . Blocking snapshots rely on the Debezium mechanism for sending signals to a Debezium connector . A blocking snapshot behaves just like an initial snapshot , except that you can trigger it at run time. You might want to run a blocking snapshot rather than use the standard initial snapshot process in the following situations: You add a new table and you want to complete the snapshot while the connector is running. You add a large table, and you want the snapshot to complete in less time than is possible with an incremental snapshot. Blocking snapshot process When you run a blocking snapshot, Debezium stops streaming, and then initiates a snapshot of the specified table, following the same process that it uses during an initial snapshot. After the snapshot completes, the streaming is resumed. Configure snapshot You can set the following properties in the data component of a signal: data-collections: to specify which tables must be snapshot additional-conditions: You can specify different filters for different table. The data-collection property is the fully-qualified name of the table for which the filter will be applied. The filter property will have the same value used in the snapshot.select.statement.overrides For example: {"type": "blocking", "data-collections": ["schema1.table1", "schema1.table2"], "additional-conditions": [{"data-collection": "schema1.table1", "filter": "SELECT * FROM [schema1].[table1] WHERE column1 = 0 ORDER BY column2 DESC"}, {"data-collection": "schema1.table2", "filter": "SELECT * FROM [schema1].[table2] WHERE column2 > 0"}]} Possible duplicates A delay might exist between the time that you send the signal to trigger the snapshot, and the time when streaming stops and the snapshot starts. As a result of this delay, after the snapshot completes, the connector might emit some event records that duplicate records captured by the snapshot. 2.5.1.5. Default names of Kafka topics that receive Debezium Oracle change event records By default, the Oracle connector writes change events for all INSERT , UPDATE , and DELETE operations that occur in a table to a single Apache Kafka topic that is specific to that table. The connector uses the following convention to name change event topics: topicPrefix.schemaName.tableName The following list provides definitions for the components of the default name: topicPrefix The topic prefix as specified by the topic.prefix connector configuration property. schemaName The name of the schema in which the operation occurred. tableName The name of the table in which the operation occurred. For example, if fulfillment is the server name, inventory is the schema name, and the database contains tables with the names orders , customers , and products , the Debezium Oracle connector emits events to the following Kafka topics, one for each table in the database: The connector applies similar naming conventions to label its internal database schema history topics, schema change topics , and transaction metadata topics . If the default topic name do not meet your requirements, you can configure custom topic names. To configure custom topic names, you specify regular expressions in the logical topic routing SMT. For more information about using the logical topic routing SMT to customize topic naming, see Topic routing . 2.5.1.6. How Debezium Oracle connectors handle database schema changes When a database client queries a database, the client uses the database's current schema. However, the database schema can be changed at any time, which means that the connector must be able to identify what the schema was at the time each insert, update, or delete operation was recorded. Also, a connector cannot necessarily apply the current schema to every event. If an event is relatively old, it's possible that it was recorded before the current schema was applied. To ensure correct processing of events that occur after a schema change, Oracle includes in the redo log not only the row-level changes that affect the data, but also the DDL statements that are applied to the database. As the connector encounters these DDL statements in the redo log, it parses them and updates an in-memory representation of each table's schema. The connector uses this schema representation to identify the structure of the tables at the time of each insert, update, or delete operation and to produce the appropriate change event. In a separate database schema history Kafka topic, the connector records all DDL statements along with the position in the redo log where each DDL statement appeared. When the connector restarts after either a crash or a graceful stop, it starts reading the redo log from a specific position, that is, from a specific point in time. The connector rebuilds the table structures that existed at this point in time by reading the database schema history Kafka topic and parsing all DDL statements up to the point in the redo log where the connector is starting. This database schema history topic is internal for internal connector use only. Optionally, the connector can also emit schema change events to a different topic that is intended for consumer applications . Additional resources Default names for topics that receive Debezium event records. 2.5.1.7. How Debezium Oracle connectors expose database schema changes You can configure a Debezium Oracle connector to produce schema change events that describe structural changes that are applied to tables in the database. The connector writes schema change events to a Kafka topic named <serverName> , where serverName is the namespace that is specified in the topic.prefix configuration property. Debezium emits a new message to the schema change topic whenever it streams data from a new table, or when the structure of the table is altered. Messages that the connector sends to the schema change topic contain a payload, and, optionally, also contain the schema of the change event message. The schema for the schema change event has the following elements: name The name of the schema change event message. type The type of the change event message. version The version of the schema. The version is an integer that is incremented each time the schema is changed. fields The fields that are included in the change event message. Example: Schema of the Oracle connector schema change topic The following example shows a typical schema in JSON format. { "schema": { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "databaseName" } ], "optional": false, "name": "io.debezium.connector.oracle.SchemaChangeKey", "version": 1 }, "payload": { "databaseName": "inventory" } } The payload of a schema change event message includes the following elements: ddl Provides the SQL CREATE , ALTER , or DROP statement that results in the schema change. databaseName The name of the database to which the statements are applied. The value of databaseName serves as the message key. tableChanges A structured representation of the entire table schema after the schema change. The tableChanges field contains an array that includes entries for each column of the table. Because the structured representation presents data in JSON or Avro format, consumers can easily read messages without first processing them through a DDL parser. Important By default, the connector uses the ALL_TABLES database view to identify the table names to store in the schema history topic. Within that view, the connector can access data only from tables that are available to the user account through which it connects to the database. You can modify settings so that the schema history topic stores a different subset of tables. Use one of the following methods to alter the set of tables that the topic stores: Change the permissions of the account that Debezium uses to access the database so that a different set of tables are visible in the ALL_TABLES view. Set the connector property schema.history.internal.store.only.captured.tables.ddl to true . Important When the connector is configured to capture a table, it stores the history of the table's schema changes not only in the schema change topic, but also in an internal database schema history topic. The internal database schema history topic is for connector use only and it is not intended for direct use by consuming applications. Ensure that applications that require notifications about schema changes consume that information only from the schema change topic. Important Never partition the database schema history topic. For the database schema history topic to function correctly, it must maintain a consistent, global order of the event records that the connector emits to it. To ensure that the topic is not split among partitions, set the partition count for the topic by using one of the following methods: If you create the database schema history topic manually, specify a partition count of 1 . If you use the Apache Kafka broker to create the database schema history topic automatically, the topic is created, set the value of the Kafka num.partitions configuration option to 1 . Example: Message emitted to the Oracle connector schema change topic The following example shows a typical schema change message in JSON format. The message contains a logical representation of the table schema. { "schema": { ... }, "payload": { "source": { "version": "2.7.3.Final", "connector": "oracle", "name": "server1", "ts_ms": 1588252618953, "ts_us": 1588252618953000, "ts_ns": 1588252618953000000, "snapshot": "true", "db": "ORCLPDB1", "schema": "DEBEZIUM", "table": "CUSTOMERS", "txId" : null, "scn" : "1513734", "commit_scn": "1513754", "lcr_position" : null, "rs_id": "001234.00012345.0124", "ssn": 1, "redo_thread": 1, "user_name": "user", "row_id": "AAASgjAAMAAAACnAAA" }, "ts_ms": 1588252618953, 1 "ts_us": 1588252618953987, 2 "ts_ns": 1588252618953987512, 3 "databaseName": "ORCLPDB1", 4 "schemaName": "DEBEZIUM", // "ddl": "CREATE TABLE \"DEBEZIUM\".\"CUSTOMERS\" \n ( \"ID\" NUMBER(9,0) NOT NULL ENABLE, \n \"FIRST_NAME\" VARCHAR2(255), \n \"LAST_NAME" VARCHAR2(255), \n \"EMAIL\" VARCHAR2(255), \n PRIMARY KEY (\"ID\") ENABLE, \n SUPPLEMENTAL LOG DATA (ALL) COLUMNS\n ) SEGMENT CREATION IMMEDIATE \n PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 \n NOCOMPRESS LOGGING\n STORAGE(INITIAL 65536 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645\n PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1\n BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)\n TABLESPACE \"USERS\" ", 5 "tableChanges": [ 6 { "type": "CREATE", 7 "id": "\"ORCLPDB1\".\"DEBEZIUM\".\"CUSTOMERS\"", 8 "table": { 9 "defaultCharsetName": null, "primaryKeyColumnNames": [ 10 "ID" ], "columns": [ 11 { "name": "ID", "jdbcType": 2, "nativeType": null, "typeName": "NUMBER", "typeExpression": "NUMBER", "charsetName": null, "length": 9, "scale": 0, "position": 1, "optional": false, "autoIncremented": false, "generated": false }, { "name": "FIRST_NAME", "jdbcType": 12, "nativeType": null, "typeName": "VARCHAR2", "typeExpression": "VARCHAR2", "charsetName": null, "length": 255, "scale": null, "position": 2, "optional": false, "autoIncremented": false, "generated": false }, { "name": "LAST_NAME", "jdbcType": 12, "nativeType": null, "typeName": "VARCHAR2", "typeExpression": "VARCHAR2", "charsetName": null, "length": 255, "scale": null, "position": 3, "optional": false, "autoIncremented": false, "generated": false }, { "name": "EMAIL", "jdbcType": 12, "nativeType": null, "typeName": "VARCHAR2", "typeExpression": "VARCHAR2", "charsetName": null, "length": 255, "scale": null, "position": 4, "optional": false, "autoIncremented": false, "generated": false } ], "attributes": [ 12 { "customAttribute": "attributeValue" } ] } } ] } } Table 2.112. Descriptions of fields in messages emitted to the schema change topic Item Field name Description 1 ts_ms , ts_us , ts_ns Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms, you can determine the lag between the source database update and Debezium. 2 databaseName schemaName Identifies the database and the schema that contains the change. 3 ddl This field contains the DDL that is responsible for the schema change. 4 tableChanges An array of one or more items that contain the schema changes generated by a DDL command. 5 type Describes the kind of change. The type can be set to one of the following values: CREATE Table created. ALTER Table modified. DROP Table deleted. 6 id Full identifier of the table that was created, altered, or dropped. In the case of a table rename, this identifier is a concatenation of <old> , <new> table names. 7 table Represents table metadata after the applied change. 8 primaryKeyColumnNames List of columns that compose the table's primary key. 9 columns Metadata for each column in the changed table. 10 attributes Custom attribute metadata for each table change. In messages that the connector sends to the schema change topic, the message key is the name of the database that contains the schema change. In the following example, the payload field contains the databaseName key: { "schema": { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "databaseName" } ], "optional": false, "name": "io.debezium.connector.oracle.SchemaChangeKey", "version": 1 }, "payload": { "databaseName": "ORCLPDB1" } } 2.5.1.8. Debezium Oracle connector-generated events that represent transaction boundaries Debezium can generate events that represent transaction metadata boundaries and that enrich data change event messages. Limits on when Debezium receives transaction metadata Debezium registers and receives metadata only for transactions that occur after you deploy the connector. Metadata for transactions that occur before you deploy the connector is not available. Database transactions are represented by a statement block that is enclosed between the BEGIN and END keywords. Debezium generates transaction boundary events for the BEGIN and END delimiters in every transaction. Transaction boundary events contain the following fields: status BEGIN or END . id String representation of the unique transaction identifier. ts_ms The time of a transaction boundary event ( BEGIN or END event) at the data source. If the data source does not provide Debezium with the event time, then the field instead represents the time at which Debezium processes the event. event_count (for END events) Total number of events emmitted by the transaction. data_collections (for END events) An array of pairs of data_collection and event_count elements that indicates the number of events that the connector emits for changes that originate from a data collection. The following example shows a typical transaction boundary message: Example: Oracle connector transaction boundary event { "status": "BEGIN", "id": "5.6.641", "ts_ms": 1486500577125, "event_count": null, "data_collections": null } { "status": "END", "id": "5.6.641", "ts_ms": 1486500577691, "event_count": 2, "data_collections": [ { "data_collection": "ORCLPDB1.DEBEZIUM.CUSTOMER", "event_count": 1 }, { "data_collection": "ORCLPDB1.DEBEZIUM.ORDER", "event_count": 1 } ] } Unless overridden via the topic.transaction option, the connector emits transaction events to the <topic.prefix> .transaction topic. 2.5.1.8.1. How the Debezium Oracle connector enriches change event messages with transaction metadata When transaction metadata is enabled, the data message Envelope is enriched with a new transaction field. This field provides information about every event in the form of a composite of fields: id String representation of unique transaction identifier. total_order The absolute position of the event among all events generated by the transaction. data_collection_order The per-data collection position of the event among all events that were emitted by the transaction. The following example shows a typical transaction event message: { "before": null, "after": { "pk": "2", "aa": "1" }, "source": { ... }, "op": "c", "ts_ms": "1580390884335", "ts_us": "1580390884335741", "ts_ns": "1580390884335741963", "transaction": { "id": "5.6.641", "total_order": "1", "data_collection_order": "1" } } LogMiner Mining Strategies Entries in the Oracle redo logs do not store the original SQL statements that users submit to make DML changes. Instead, a redo entry holds a set of change vectors and a set of object identifiers that represent the tablespace, table, and columns related to these vectors. In other words, redo log entries don't include the names of the schemas, tables, or columns affected by DML changes. The Debezium Oracle connector uses the log.mining.strategy configuration property to control how Oracle LogMiner handles the lookup of the object identifiers in the change vectors. In certain situations, one log mining strategy might prove more reliable than another with regard to schema changes. However, before you choose a log mining strategy, it's important to consider the implications it might have on performance and overhead. Writing the data dictionary to redo logs The default mining strategy is called redo_log_catalog . In this strategy, the database flushes a copy of the data dictionary to the redo logs immediately after each redo log switch. This is the most reliable strategy for tracking schema changes that are interwoven with data changes, because Oracle LogMiner has a way to interpolate between the starting and ending data dictionary states across a series of change vectors. However, the redo_log_catalog mode is also the most expensive, because it requires several key steps to function. First, this mode requires the data dictionary to be flushed to the redo logs after every log switch. Flushing the logs after each switch can quickly consume valuable space in the archive log, and the high volume of archive logs might exceed the number that database administrators prepared for. If you intend to use this mode, coordinate with your database administrators to ensure that the database is configured appropriately. Important If you configure the connector to use the redo_log_catalog mode, do not use multiple Debezium Oracle connectors to capture changes from the same logical database. Using the online catalog directly The strategy mode, online_catalog , works differently from the redo_log_catalog mode. When the strategy is set to online_catalog , the database never flushes the data dictionary to the redo logs. Instead, Oracle LogMiner always uses the most current data dictionary state to perform comparisons. By always using the current dictionary, and eliminating flushing to the redo logs, this strategy requires less overhead, and operates more efficiently. However, these benefits are offset by the inability to parse interwoven schema changes and data changes. As a result, this strategy can sometimes result in event failures. If LogMiner was unable to reconstruct the SQL reliability after a schema change, check the redo logs for evidence. Look for references to tables with names like OBJ# 123456 (where the number is the table's object identifier), or for columns with names like COL1 or COL2 . When you configure the connector to use the online_catalog strategy, take steps to ensure that the table schema and its indices remain static and free from change. If the Debezium connector is configured to use the online_catalog mode, and you must apply a schema change, perform the following steps: Wait for the connector to capture all existing data changes (DML). Perform the schema (DDL) change, and then wait for the connector to capture the change. Resume data changes (DML) on the table. Following this procedure helps to ensure that Oracle LogMiner can safely reconstruct the SQL for all data changes. Query Modes The Debezium Oracle connector integrates with Oracle LogMiner by default. This integration requires a specialized set of steps which includes generating a complex JDBC SQL query to ingest the changes recorded in the transaction logs as change events. The VUSDLOGMNR_CONTENTS view used by the JDBC SQL query does not have any indices to improve the query's performance, and so there are different query modes that can be used that control how the SQL query is generated as a way to improve the query's execution. The log.mining.query.filter.mode connector property can be configured with one of the following to influence how the JDBC SQL query is generated: none (Default) This mode creates a JDBC query that only filters based on the different operation types, such as inserts, updates, or deletes, at the database level. When filtering the data based on the schema, table, or username include/exclude lists, this is done during the processing loop within the connector. This mode is often useful when capturing a small number of tables from a database that is not heavily saturated with changes. The generated query is quite simple, and focuses primarily on reading as quickly as possible with low database overhead. in This mode creates a JDBC query that filters not only operation types at the database level, but also schema, table, and username include/exclude lists. The query's predicates are generated using a SQL in-clause based on the values specified in the include/exclude list configuration properties. This mode is often useful when capturing a large number of tables from a database that is heavily saturated with changes. The generated query is much more complex than the none mode, and focuses on reducing network overhead and performing as much filtering at the database level as possible. Finally, do not specify regular expressions as part of schema and table include/exclude configuration properties. Using regular expressions will cause the connector to not match changes based on these configuration properties, causing changes to be missed. regex This mode creates a JDBC query that filters not only operation types at the database level, but also schema, table, and username include/exclude lists. However, unlike the in mode, this mode generates a SQL query using the Oracle REGEXP_LIKE operator using a conjunction or disjunction depending on whether include or excluded values are specified. This mode is often useful when capturing a variable number of tables that can be identified using a small number of regular expressions. The generated query is much more complex than any other mode, and focuses on reducing network overhead and performing as much filtering at the database level as possible. 2.5.1.9. How the Debezium Oracle connector uses event buffering Oracle writes all changes to the redo logs in the order in which they occur, including changes that are later discarded by a rollback. As a result, concurrent changes from separate transactions are intertwined. When the connector first reads the stream of changes, because it cannot immediately determine which changes are committed or rolled back, it temporarily stores the change events in an internal buffer. After a change is committed, the connector writes the change event from the buffer to Kafka. The connector drops change events that are discarded by a rollback. You can configure the buffering mechanism that the connector uses by setting the property log.mining.buffer.type . Heap The default buffer type is configured using memory . Under the default memory setting, the connector uses the heap memory of the JVM process to allocate and manage buffered event records. If you use the memory buffer setting, be sure that the amount of memory that you allocate to the Java process can accommodate long-running and large transactions in your environment. 2.5.1.10. How the Debezium Oracle connector detects gaps in SCN values When the Debezium Oracle connector is configured to use LogMiner, it collects change events from Oracle by using a start and end range that is based on system change numbers (SCNs). The connector manages this range automatically, increasing or decreasing the range depending on whether the connector is able to stream changes in near real-time, or must process a backlog of changes due to the volume of large or bulk transactions in the database. Under certain circumstances, the Oracle database advances the SCN by an unusually high amount, rather than increasing the SCN value at a constant rate. Such a jump in the SCN value can occur because of the way that a particular integration interacts with the database, or as a result of events such as hot backups. The Debezium Oracle connector relies on the following configuration properties to detect the SCN gap and adjust the mining range. log.mining.scn.gap.detection.gap.size.min Specifies the minimum gap size. log.mining.scn.gap.detection.time.interval.max.ms Specifies the maximum time interval. The connector first compares the difference in the number of changes between the current SCN and the highest SCN in the current mining range. If the difference between the current SCN value and the highest SCN value is greater than the minimum gap size, then the connector has potentially detected a SCN gap. To confirm whether a gap exists, the connector compares the timestamps of the current SCN and the SCN at the end of the mining range. If the difference between the timestamps is less than the maximum time interval, then the existence of an SCN gap is confirmed. When an SCN gap occurs, the Debezium connector automatically uses the current SCN as the end point for the range of the current mining session. This allows the connector to quickly catch up to the real-time events without mining smaller ranges in between that return no changes because the SCN value was increased by an unexpectedly large number. When the connector performs the preceding steps in response to an SCN gap, it ignores the value that is specified by the log.mining.batch.size.max property. After the connector finishes the mining session and catches back up to real-time events, it resumes enforcement of the maximum log mining batch size. Warning SCN gap detection is available only if the large SCN increment occurs while the connector is running and processing near real-time events. 2.5.1.11. How Debezium manages offsets in databases that change infrequently The Debezium Oracle connector tracks system change numbers in the connector offsets so that when the connector is restarted, it can begin where it left off. These offsets are part of each emitted change event; however, when the frequency of database changes are low (every few hours or days), the offsets can become stale and prevent the connector from successfully restarting if the system change number is no longer available in the transaction logs. For connectors that use non-CDB mode to connect to Oracle, you can enable heartbeat.interval.ms to force the connector to emit a heartbeat event at regular intervals so that offsets remain synchronized. For connectors that use CDB mode to connect to Oracle, maintaining synchronization is more complicated. Not only must you set heartbeat.interval.ms , but it's also necessary to set heartbeat.action.query . Specifying both properties is required, because in CDB mode, the connector specifically tracks changes inside the PDB only. A supplementary mechanism is needed to trigger change events from within the pluggable database. At regular intervals, the heartbeat action query causes the connector to insert a new table row, or update an existing row in the pluggable database. Debezium detects the table changes and emits change events for them, ensuring that offsets remain synchronized, even in pluggable databases that process changes infrequently. Note For the connector to use the heartbeat.action.query with tables that are not owned by the connector user account , you must grant the connector user permission to run the necessary INSERT or UPDATE queries on those tables. 2.5.2. Descriptions of Debezium Oracle connector data change events Every data change event that the Oracle connector emits has a key and a value. The structures of the key and value depend on the table from which the change events originate. For information about how Debezium constructs topic names, see Topic names . Warning The Debezium Oracle connector ensures that all Kafka Connect schema names are valid Avro schema names . This means that the logical server name must start with alphabetic characters or an underscore ([a-z,A-Z,_]), and the remaining characters in the logical server name and all characters in the schema and table names must be alphanumeric characters or an underscore ([a-z,A-Z,0-9,\_]). The connector automatically replaces invalid characters with an underscore character. Unexpected naming conflicts can result when the only distinguishing characters between multiple logical server names, schema names, or table names are not valid characters, and those characters are replaced with underscores. Debezium and Kafka Connect are designed around continuous streams of event messages . However, the structure of these events might change over time, which can be difficult for topic consumers to handle. To facilitate the processing of mutable event structures, each event in Kafka Connect is self-contained. Every message key and value has two parts: a schema and payload . The schema describes the structure of the payload, while the payload contains the actual data. Warning Changes that are performed by the SYS or SYSTEM user accounts are not captured by the connector. The following topics contain more details about data change events: Section 2.5.2.1, "About keys in Debezium Oracle connector change events" Section 2.5.2.2, "About values in Debezium Oracle connector change events" 2.5.2.1. About keys in Debezium Oracle connector change events For each changed table, the change event key is structured such that a field exists for each column in the primary key (or unique key constraint) of the table at the time when the event is created. For example, a customers table that is defined in the inventory database schema, might have the following change event key: CREATE TABLE customers ( id NUMBER(9) GENERATED BY DEFAULT ON NULL AS IDENTITY (START WITH 1001) NOT NULL PRIMARY KEY, first_name VARCHAR2(255) NOT NULL, last_name VARCHAR2(255) NOT NULL, email VARCHAR2(255) NOT NULL UNIQUE ); If the value of the <topic.prefix> .transaction configuration property is set to server1 , the JSON representation for every change event that occurs in the customers table in the database features the following key structure: { "schema": { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "ID" } ], "optional": false, "name": "server1.INVENTORY.CUSTOMERS.Key" }, "payload": { "ID": 1004 } } The schema portion of the key contains a Kafka Connect schema that describes the content of the key portion. In the preceding example, the payload value is not optional, the structure is defined by a schema named server1.DEBEZIUM.CUSTOMERS.Key , and there is one required field named id of type int32 . The value of the key's payload field indicates that it is indeed a structure (which in JSON is just an object) with a single id field, whose value is 1004 . Therefore, you can interpret this key as describing the row in the inventory.customers table (output from the connector named server1 ) whose id primary key column had a value of 1004 . 2.5.2.2. About values in Debezium Oracle connector change events The structure of a value in a change event message mirrors the structure of the message key in the change event in the message, and contains both a schema section and a payload section. Payload of a change event value An envelope structure in the payload sections of a change event value contains the following fields: op A mandatory field that contains a string value describing the type of operation. The op field in the payload of an Oracle connector change event value contains one of the following values: c (create or insert), u (update), d (delete), or r (read, which indicates a snapshot). before An optional field that, if present, describes the state of the row before the event occurred. The structure is described by the server1.INVENTORY.CUSTOMERS.Value Kafka Connect schema, which the server1 connector uses for all rows in the inventory.customers table. after An optional field that, if present, contains the state of a row after a change occurs. The structure is described by the same server1.INVENTORY.CUSTOMERS.Value Kafka Connect schema that is used for the before field. source A mandatory field that contains a structure that describes the source metadata for the event. In the case of the Oracle connector, the structure includes the following fields: The Debezium version. The connector name. Whether the event is part of an ongoing snapshot or not. The transaction id (not includes for snapshots). The SCN of the change. A timestamp that indicates when the record in the source database changed (for snapshots, the timestamp indicates when the snapshot occurred). Username who made the change The ROWID associated with the row Tip The commit_scn field is optional and describes the SCN of the transaction commit that the change event participates within. ts_ms An optional field that, if present, contains the time (based on the system clock in the JVM that runs the Kafka Connect task) at which the connector processed the event. Schema of a change event value The schema portion of the event message's value contains a schema that describes the envelope structure of the payload and the nested fields within it. For more information about change event values, see the following topics: create events update events delete events truncate events create events The following example shows the value of a create event value from the customers table that is described in the change event keys example: { "schema": { "type": "struct", "fields": [ { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "ID" }, { "type": "string", "optional": false, "field": "FIRST_NAME" }, { "type": "string", "optional": false, "field": "LAST_NAME" }, { "type": "string", "optional": false, "field": "EMAIL" } ], "optional": true, "name": "server1.DEBEZIUM.CUSTOMERS.Value", "field": "before" }, { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "ID" }, { "type": "string", "optional": false, "field": "FIRST_NAME" }, { "type": "string", "optional": false, "field": "LAST_NAME" }, { "type": "string", "optional": false, "field": "EMAIL" } ], "optional": true, "name": "server1.DEBEZIUM.CUSTOMERS.Value", "field": "after" }, { "type": "struct", "fields": [ { "type": "string", "optional": true, "field": "version" }, { "type": "string", "optional": false, "field": "name" }, { "type": "int64", "optional": true, "field": "ts_ms" }, { "type": "int64", "optional": true, "field": "ts_us" }, { "type": "int64", "optional": true, "field": "ts_ns" }, { "type": "string", "optional": true, "field": "txId" }, { "type": "string", "optional": true, "field": "scn" }, { "type": "string", "optional": true, "field": "commit_scn" }, { "type": "string", "optional": true, "field": "rs_id" }, { "type": "int64", "optional": true, "field": "ssn" }, { "type": "int32", "optional": true, "field": "redo_thread" }, { "type": "string", "optional": true, "field": "user_name" }, { "type": "boolean", "optional": true, "field": "snapshot" }, { "type": "string", "optional": true, "field": "row_id" } ], "optional": false, "name": "io.debezium.connector.oracle.Source", "field": "source" }, { "type": "string", "optional": false, "field": "op" }, { "type": "int64", "optional": true, "field": "ts_ms" }, { "type": "int64", "optional": true, "field": "ts_us" }, { "type": "int64", "optional": true, "field": "ts_ns" } ], "optional": false, "name": "server1.DEBEZIUM.CUSTOMERS.Envelope" }, "payload": { "before": null, "after": { "ID": 1004, "FIRST_NAME": "Anne", "LAST_NAME": "Kretchmar", "EMAIL": "annek@noanswer.org" }, "source": { "version": "2.7.3.Final", "name": "server1", "ts_ms": 1520085154000, "ts_us": 1520085154000000, "ts_ns": 1520085154000000000, "txId": "6.28.807", "scn": "2122185", "commit_scn": "2122185", "rs_id": "001234.00012345.0124", "ssn": 1, "redo_thread": 1, "user_name": "user", "snapshot": false, "row_id": "AAASgjAAMAAAACnAAA" }, "op": "c", "ts_ms": 1532592105975, "ts_us": 1532592105975741, "ts_ns": 1532592105975741582 } } In the preceding example, notice how the event defines the following schema: The envelope ( server1.DEBEZIUM.CUSTOMERS.Envelope ). The source structure ( io.debezium.connector.oracle.Source , which is specific to the Oracle connector and reused across all events). The table-specific schemas for the before and after fields. Tip The names of the schemas for the before and after fields are of the form <logicalName> . <schemaName> . <tableName> .Value , and thus are entirely independent from the schemas for all other tables. As a result, when you use the Avro converter , the Avro schemas for tables in each logical source have their own evolution and history. The payload portion of this event's value , provides information about the event. It describes that a row was created ( op=c ), and shows that the after field value contains the values that were inserted into the ID , FIRST_NAME , LAST_NAME , and EMAIL columns of the row. Tip By default, the JSON representations of events are much larger than the rows that they describe. The larger size is due to the JSON representation including both the schema and payload portions of a message. You can use the Avro Converter to decrease the size of messages that the connector writes to Kafka topics. update events The following example shows an update change event that the connector captures from the same table as the preceding create event. { "schema": { ... }, "payload": { "before": { "ID": 1004, "FIRST_NAME": "Anne", "LAST_NAME": "Kretchmar", "EMAIL": "annek@noanswer.org" }, "after": { "ID": 1004, "FIRST_NAME": "Anne", "LAST_NAME": "Kretchmar", "EMAIL": "anne@example.com" }, "source": { "version": "2.7.3.Final", "name": "server1", "ts_ms": 1520085811000, "ts_us": 1520085811000000, "ts_ns": 1520085811000000000, "txId": "6.9.809", "scn": "2125544", "commit_scn": "2125544", "rs_id": "001234.00012345.0124", "ssn": 1, "redo_thread": 1, "user_name": "user", "snapshot": false, "row_id": "AAASgjAAMAAAACnAAA" }, "op": "u", "ts_ms": 1532592713485, "ts_us": 1532592713485152, "ts_ns": 1532592713485152954, } } The payload has the same structure as the payload of a create (insert) event, but the following values are different: The value of the op field is u , signifying that this row changed because of an update. The before field shows the former state of the row with the values that were present before the update database commit. The after field shows the updated state of the row, with the EMAIL value now set to anne@example.com . The structure of the source field includes the same fields as before, but the values are different, because the connector captured the event from a different position in the redo log. The ts_ms field shows the timestamp that indicates when Debezium processed the event. The payload section reveals several other useful pieces of information. For example, by comparing the before and after structures, we can determine how a row changed as the result of a commit. The source structure provides information about Oracle's record of this change, providing traceability. It also gives us insight into when this event occurred in relation to other events in this topic and in other topics. Did it occur before, after, or as part of the same commit as another event? Note When the columns for a row's primary/unique key are updated, the value of the row's key changes. As a result, Debezium emits three events after such an update: A DELETE event. A tombstone event with the old key for the row. An INSERT event that provides the new key for the row. delete events The following example shows a delete event for the table that is shown in the preceding create and update event examples. The schema portion of the delete event is identical to the schema portion for those events. { "schema": { ... }, "payload": { "before": { "ID": 1004, "FIRST_NAME": "Anne", "LAST_NAME": "Kretchmar", "EMAIL": "anne@example.com" }, "after": null, "source": { "version": "2.7.3.Final", "name": "server1", "ts_ms": 1520085153000, "ts_us": 1520085153000000, "ts_ns": 1520085153000000000, "txId": "6.28.807", "scn": "2122184", "commit_scn": "2122184", "rs_id": "001234.00012345.0124", "ssn": 1, "redo_thread": 1, "user_name": "user", "snapshot": false, "row_id": "AAASgjAAMAAAACnAAA" }, "op": "d", "ts_ms": 1532592105960, "ts_us": 1532592105960854, "ts_ns": 1532592105960854693 } } The payload portion of the event reveals several differences when compared to the payload of a create or update event: The value of the op field is d , signifying that the row was deleted. The before field shows the former state of the row that was deleted with the database commit. The value of the after field is null , signifying that the row no longer exists. The structure of the source field includes many of the keys that exist in create or update events, but the values in the ts_ms , scn , and txId fields are different. The ts_ms shows a timestamp that indicates when Debezium processed this event. The delete event provides consumers with the information that they require to process the removal of this row. The Oracle connector's events are designed to work with Kafka log compaction , which allows for the removal of some older messages as long as at least the most recent message for every key is kept. This allows Kafka to reclaim storage space while ensuring the topic contains a complete dataset and can be used for reloading key-based state. When a row is deleted, the delete event value shown in the preceding example still works with log compaction, because Kafka is able to remove all earlier messages that use the same key. The message value must be set to null to instruct Kafka to remove all messages that share the same key. To make this possible, by default, Debezium's Oracle connector always follows a delete event with a special tombstone event that has the same key but null value. You can change the default behavior by setting the connector property tombstones.on.delete . truncate events A truncate change event signals that a table has been truncated. The message key is null in this case, the message value looks like this: { "schema": { ... }, "payload": { "before": null, "after": null, "source": { 1 "version": "2.7.3.Final", "connector": "oracle", "name": "oracle_server", "ts_ms": 1638974535000, "ts_us": 1638974535000000, "ts_ns": 1638974535000000000, "snapshot": "false", "db": "ORCLPDB1", "sequence": null, "schema": "DEBEZIUM", "table": "TEST_TABLE", "txId": "02000a0037030000", "scn": "13234397", "commit_scn": "13271102", "lcr_position": null, "rs_id": "001234.00012345.0124", "ssn": 1, "redo_thread": 1, "user_name": "user" }, "op": "t", 2 "ts_ms": 1638974558961, 3 "ts_us": 1638974558961987, 4 "ts_ns": 1638974558961987251, 5 "transaction": null } } Table 2.113. Descriptions of truncate event value fields Item Field name Description 1 source Mandatory field that describes the source metadata for the event. In a truncate event value, the source field structure is the same as for create , update , and delete events for the same table, provides this metadata: Debezium version Connector type and name Database and table that contains the new row Schema name If the event was part of a snapshot (always false for truncate events) ID of the transaction in which the operation was performed SCN of the operation Timestamp for when the change was made in the database Username who performed the change 2 op Mandatory string that describes the type of operation. The op field value is t , signifying that this table was truncated. 3 ts_ms , ts_us , ts_ns Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. Because truncate events represent changes made to an entire table, and have no message key, in topics with multiple partitions, there is no guarantee that consumers receive truncate events and change events ( create , update , etc.) for to a table in order. For example, when a consumer reads events from different partitions, it might receive an update event for a table after it receives a truncate event for the same table. Ordering can be guaranteed only if a topic uses a single partition. If you do not want to capture truncate events, use the skipped.operations option to filter them out. 2.5.3. How Debezium Oracle connectors map data types When the Debezium Oracle connector detects a change in the value of a table row, it emits a change event that represents the change. Each change event record is structured in the same way as the original table, with the event record containing a field for each column value. The data type of a table column determines how the connector represents the column's values in change event fields, as shown in the tables in the following sections. For each column in a table, Debezium maps the source data type to a literal type and, and in some cases, a semantic type , in the corresponding event field. Literal types Describe how the value is literally represented, using one of the following Kafka Connect schema types: INT8 , INT16 , INT32 , INT64 , FLOAT32 , FLOAT64 , BOOLEAN , STRING , BYTES , ARRAY , MAP , and STRUCT . Semantic types Describe how the Kafka Connect schema captures the meaning of the field, by using the name of the Kafka Connect schema for the field. If the default data type conversions do not meet your needs, you can create a custom converter for the connector. For some Oracle large object (CLOB, NCLOB, and BLOB) and numeric data types, you can manipulate the way that the connector performs the type mapping by changing default configuration property settings. For more information about how Debezium properties control mappings for these data types, see Binary and Character LOB types and Numeric types . For more information about how the Debezium connector maps Oracle data types, see the following topics: Character types Binary and Character LOB types Numeric types Boolean types Temporal types ROWID types User-defined types Oracle-supplied types Default Values Character types The following table describes how the connector maps basic character types. Table 2.114. Mappings for Oracle basic character types Oracle data type Literal type (schema type) Semantic type (schema name) and Notes CHAR[(M)] STRING n/a NCHAR[(M)] STRING n/a NVARCHAR2[(M)] STRING n/a VARCHAR[(M)] STRING n/a VARCHAR2[(M)] STRING n/a Binary and Character LOB types Use of the BLOB , CLOB , and NCLOB with the Debezium Oracle connector is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview . The following table describes how the connector maps binary and character large object (LOB) data types. Table 2.115. Mappings for Oracle binary and character LOB types Oracle data type Literal type (schema type) Semantic type (schema name) and Notes BFILE n/a This data type is not supported BLOB BYTES Depending on the setting of the binary.handling.mode property in the connector configuration, the connector maps LOB values of this type to one of the following semantic types: Raw bytes (the default) A base64-encoded string A base64-url-safe-encoded string A hex-encoded string CLOB STRING n/a LONG n/a This data type is not supported. LONG RAW n/a This data type is not supported. NCLOB STRING n/a RAW n/a Depending on the setting of the binary.handling.mode property in the connector configuration, the connector maps LOB values of this type to one of the following semantic types: Raw bytes (the default) A base64-encoded string A base64-url-safe-encoded string A hex-encoded string Note Oracle only supplies column values for CLOB , NCLOB , and BLOB data types if they're explicitly set or changed in a SQL statement. As a result, change events never contain the value of an unchanged CLOB , NCLOB , or BLOB column. Instead, they contain placeholders as defined by the connector property, unavailable.value.placeholder . If the value of a CLOB , NCLOB , or BLOB column is updated, the new value is placed in the after element of the corresponding update change event. The before element contains the unavailable value placeholder. Numeric types The following table describes how the Debezium Oracle connector maps numeric types. Note You can modify the way that the connector maps the Oracle DECIMAL , NUMBER , NUMERIC , and REAL data types by changing the value of the connector's decimal.handling.mode configuration property. When the property is set to its default value of precise , the connector maps these Oracle data types to the Kafka Connect org.apache.kafka.connect.data.Decimal logical type, as indicated in the table. When the value of the property is set to double or string , the connector uses alternate mappings for some Oracle data types. For more information, see the Semantic type and Notes column in the following table. Table 2.116. Mappings for Oracle numeric data types Oracle data type Literal type (schema type) Semantic type (schema name) and Notes BINARY_FLOAT FLOAT32 n/a BINARY_DOUBLE FLOAT64 n/a DECIMAL[(P, S)] BYTES / INT8 / INT16 / INT32 / INT64 org.apache.kafka.connect.data.Decimal if using BYTES Handled equivalently to NUMBER (note that S defaults to 0 for DECIMAL ). When the decimal.handling.mode property is set to double , the connector represents DECIMAL values as Java double values with schema type FLOAT64 . When the decimal.handling.mode property is set to string , the connector represents DECIMAL values as their formatted string representation with schema type STRING . DOUBLE PRECISION STRUCT io.debezium.data.VariableScaleDecimal Contains a structure with two fields: scale of type INT32 that contains the scale of the transferred value and value of type BYTES containing the original value in an unscaled form. FLOAT[(P)] STRUCT io.debezium.data.VariableScaleDecimal Contains a structure with two fields: scale of type INT32 that contains the scale of the transferred value and value of type BYTES containing the original value in an unscaled form. INTEGER , INT BYTES org.apache.kafka.connect.data.Decimal INTEGER is mapped in Oracle to NUMBER(38,0) and hence can hold values larger than any of the INT types could store NUMBER[(P[, *])] STRUCT io.debezium.data.VariableScaleDecimal Contains a structure with two fields: scale of type INT32 that contains the scale of the transferred value and value of type BYTES containing the original value in an unscaled form. When the decimal.handling.mode property is set to double , the connector represents NUMBER values as Java double values with schema type FLOAT64 . When the decimal.handling.mode property is set to string , the connector represents NUMBER values as their formatted string representation with schema type STRING . NUMBER(P, S <= 0) INT8 / INT16 / INT32 / INT64 NUMBER columns with a scale of 0 represent integer numbers. A negative scale indicates rounding in Oracle, for example, a scale of -2 causes rounding to hundreds. Depending on the precision and scale, one of the following matching Kafka Connect integer type is chosen: P - S < 3, INT8 P - S < 5, INT16 P - S < 10, INT32 P - S < 19, INT64 P - S >= 19, BYTES ( org.apache.kafka.connect.data.Decimal ) When the decimal.handling.mode property is set to double , the connector represents NUMBER values as Java double values with schema type FLOAT64 . When the decimal.handling.mode property is set to string , the connector represents NUMBER values as their formatted string representation with schema type STRING . NUMBER(P, S > 0) BYTES org.apache.kafka.connect.data.Decimal NUMERIC[(P, S)] BYTES / INT8 / INT16 / INT32 / INT64 org.apache.kafka.connect.data.Decimal if using BYTES Handled equivalently to NUMBER (note that S defaults to 0 for NUMERIC ). When the decimal.handling.mode property is set to double , the connector represents NUMERIC values as Java double values with schema type FLOAT64 . When the decimal.handling.mode property is set to string , the connector represents NUMERIC values as their formatted string representation with schema type STRING . SMALLINT BYTES org.apache.kafka.connect.data.Decimal SMALLINT is mapped in Oracle to NUMBER(38,0) and hence can hold values larger than any of the INT types could store REAL STRUCT io.debezium.data.VariableScaleDecimal Contains a structure with two fields: scale of type INT32 that contains the scale of the transferred value and value of type BYTES containing the original value in an unscaled form. When the decimal.handling.mode property is set to double , the connector represents REAL values as Java double values with schema type FLOAT64 . When the decimal.handling.mode property is set to string , the connector represents REAL values as their formatted string representation with schema type STRING . As mention above, Oracle allows negative scales in NUMBER type. This can cause an issue during conversion to the Avro format when the number is represented as the Decimal . Decimal type includes scale information, but Avro specification allows only positive values for the scale. Depending on the schema registry used, it may result into Avro serialization failure. To avoid this issue, you can use NumberToZeroScaleConverter , which converts sufficiently high numbers (P - S >= 19) with negative scale into Decimal type with zero scale. It can be configured as follows: By default, the number is converted to Decimal type ( zero_scale.decimal.mode=precise ), but for completeness remaining two supported types ( double and string ) are supported as well. Boolean types Oracle does not provide native support for a BOOLEAN data type. However, it is common practice to use other data types with certain semantics to simulate the concept of a logical BOOLEAN data type. To enable you to convert source columns to Boolean data types, Debezium provides a NumberOneToBooleanConverter custom converter that you can use in one of the following ways: Map all NUMBER(1) columns to a BOOLEAN type. Enumerate a subset of columns by using a comma-separated list of regular expressions. To use this type of conversion, you must set the converters configuration property with the selector parameter, as shown in the following example: Temporal types Other than the Oracle INTERVAL , TIMESTAMP WITH TIME ZONE , and TIMESTAMP WITH LOCAL TIME ZONE data types, the way that the connector converts temporal types depends on the value of the time.precision.mode configuration property. When the time.precision.mode configuration property is set to adaptive (the default), then the connector determines the literal and semantic type for the temporal types based on the column's data type definition so that events exactly represent the values in the database: Oracle data type Literal type (schema type) Semantic type (schema name) and Notes DATE INT64 io.debezium.time.Timestamp Represents the number of milliseconds since the UNIX epoch, and does not include timezone information. INTERVAL DAY[(M)] TO SECOND FLOAT64 io.debezium.time.MicroDuration The number of micro seconds for a time interval using the 365.25 / 12.0 formula for days per month average. io.debezium.time.Interval (when interval.handling.mode is set to string ) The string representation of the interval value that follows the pattern P<years>Y<months>M<days>DT<hours>H<minutes>M<seconds>S , for example, P1Y2M3DT4H5M6.78S . INTERVAL YEAR[(M)] TO MONTH FLOAT64 io.debezium.time.MicroDuration The number of micro seconds for a time interval using the 365.25 / 12.0 formula for days per month average. io.debezium.time.Interval (when interval.handling.mode is set to string ) The string representation of the interval value that follows the pattern P<years>Y<months>M<days>DT<hours>H<minutes>M<seconds>S , for example, P1Y2M3DT4H5M6.78S . TIMESTAMP(0 - 3) INT64 io.debezium.time.Timestamp Represents the number of milliseconds since the UNIX epoch, and does not include timezone information. TIMESTAMP, TIMESTAMP(4 - 6) INT64 io.debezium.time.MicroTimestamp Represents the number of microseconds since the UNIX epoch, and does not include timezone information. TIMESTAMP(7 - 9) INT64 io.debezium.time.NanoTimestamp Represents the number of nanoseconds since the UNIX epoch, and does not include timezone information. TIMESTAMP WITH TIME ZONE STRING io.debezium.time.ZonedTimestamp A string representation of a timestamp with timezone information. TIMESTAMP WITH LOCAL TIME ZONE STRING io.debezium.time.ZonedTimestamp A string representation of a timestamp in UTC. When the time.precision.mode configuration property is set to connect , then the connector uses the predefined Kafka Connect logical types. This can be useful when consumers only know about the built-in Kafka Connect logical types and are unable to handle variable-precision time values. Because the level of precision that Oracle supports exceeds the level that the logical types in Kafka Connect support, if you set time.precision.mode to connect , a loss of precision results when the fractional second precision value of a database column is greater than 3: Oracle data type Literal type (schema type) Semantic type (schema name) and Notes DATE INT32 org.apache.kafka.connect.data.Date Represents the number of days since the UNIX epoch. INTERVAL DAY[(M)] TO SECOND FLOAT64 io.debezium.time.MicroDuration The number of micro seconds for a time interval using the 365.25 / 12.0 formula for days per month average. io.debezium.time.Interval (when interval.handling.mode is set to string ) The string representation of the interval value that follows the pattern P<years>Y<months>M<days>DT<hours>H<minutes>M<seconds>S , for example, P1Y2M3DT4H5M6.78S . INTERVAL YEAR[(M)] TO MONTH FLOAT64 io.debezium.time.MicroDuration The number of micro seconds for a time interval using the 365.25 / 12.0 formula for days per month average. io.debezium.time.Interval (when interval.handling.mode is set to string ) The string representation of the interval value that follows the pattern P<years>Y<months>M<days>DT<hours>H<minutes>M<seconds>S , for example, P1Y2M3DT4H5M6.78S . TIMESTAMP(0 - 3) INT64 org.apache.kafka.connect.data.Timestamp Represents the number of milliseconds since the UNIX epoch, and does not include timezone information. TIMESTAMP(4 - 6) INT64 org.apache.kafka.connect.data.Timestamp Represents the number of milliseconds since the UNIX epoch, and does not include timezone information. TIMESTAMP(7 - 9) INT64 org.apache.kafka.connect.data.Timestamp Represents the number of milliseconds since the UNIX epoch, and does not include timezone information. TIMESTAMP WITH TIME ZONE STRING io.debezium.time.ZonedTimestamp A string representation of a timestamp with timezone information. TIMESTAMP WITH LOCAL TIME ZONE STRING io.debezium.time.ZonedTimestamp A string representation of a timestamp in UTC. ROWID types The following table describes how the connector maps ROWID (row address) data types. Table 2.117. Mappings for Oracle ROWID data types Oracle data type Literal type (schema type) Semantic type (schema name) and Notes ROWID STRING n/a UROWID n/a This data type is not supported . XML types Use of the XMLTYPE with the Debezium Oracle connector is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview . The following table describes how the connector maps XMLTYPE data types. Table 2.118. Mappings for Oracle XMLTYPE data types Oracle data type Literal type (schema type) Semantic type (schema name) and Notes XMLTYPE STRING io.debezium.data.Xml User-defined types Oracle enables you to define custom data types to provide flexibility when the built-in data types do not satisfy your requirements. There are a several user-defined types such as Object types, REF data types, Varrays, and Nested Tables. At this time, you cannot use the Debezium Oracle connector with any of these user-defined types. Oracle-supplied types Oracle provides SQL-based interfaces that you can use to define new types when the built-in or ANSI-supported types are insufficient. Oracle offers several commonly used data types to serve a broad array of purposes such as Any or Spatial types. At this time, you cannot use the Debezium Oracle connector with any of these data types. Default Values If a default value is specified for a column in the database schema, the Oracle connector will attempt to propagate this value to the schema of the corresponding Kafka record field. Most common data types are supported, including: Character types ( CHAR , NCHAR , VARCHAR , VARCHAR2 , NVARCHAR , NVARCHAR2 ) Numeric types ( INTEGER , NUMERIC , etc.) Temporal types ( DATE , TIMESTAMP , INTERVAL , etc.) If a temporal type uses a function call such as TO_TIMESTAMP or TO_DATE to represent the default value, the connector will resolve the default value by making an additional database call to evaluate the function. For example, if a DATE column is defined with the default value of TO_DATE('2021-01-02', 'YYYY-MM-DD') , the column's default value will be the number of days since the UNIX epoch for that date or 18629 in this case. If a temporal type uses the SYSDATE constant to represent the default value, the connector will resolve this based on whether the column is defined as NOT NULL or NULL . If the column is nullable, no default value will be set; however, if the column isn't nullable then the default value will be resolved as either 0 (for DATE or TIMESTAMP(n) data types) or 1970-01-01T00:00:00Z (for TIMESTAMP WITH TIME ZONE or TIMESTAMP WITH LOCAL TIME ZONE data types). The default value type will be numeric except if the column is a TIMESTAMP WITH TIME ZONE or TIMESTAMP WITH LOCAL TIME ZONE in which case its emitted as a string. Custom converters By default, the Debezium Oracle connector provides several CustomConverter implementations specific to Oracle data types. These custom converters provide alternative mappings for specific data types based on the connector configuration. To add a CustomConverter to the connector, follow the instructions in the Custom Converters documentation . The Debezium Oracle connector provides the following custom converters: NUMBER(1) to Boolean NUMBER To Zero Scale RAW to String NUMBER(1) to Boolean Beginning with version 23, Oracle database provides a BOOLEAN logical data type. In earlier versions, the database simulates a BOOLEAN type by using a NUMBER(1) data type, constrained with a value of 0 for false, or a value of 1 for true. By default, when Debezium emits change events for source columns that use the NUMBER(1) data type, it converts the data to the INT8 literal type. If the default mapping for NUMBER(1) data types does not meet your needs, you can configure the connector to use the logical BOOL type when it emits these columns by configuring the NumberOneToBooleanConverter , as shown in the following example: Example: NumberOneToBooleanConverter configuration In the preceding example, the selector property is optional. The selector property specifies a regular expression that designates which tables or columns the converter applies to. If you omit the selector property, when Debezium emits an event, every column with the NUMBER(1) data type is converted to a field that uses the logical BOOL type. NUMBER To Zero Scale Oracle supports creating NUMBER based columns with negative scale, that is, NUMBER(-2) . Not all systems can process negative scale values, so these values can result in processing problems in your pipeline. For example, because Apache Avro does not support these values, problems can occur if Debezium converts events to Avro format. Similarly, downstream consumers that do not support these values can also encounter errors. Example configuration In the preceding example, the decimal.mode property specifies how the connector emits decimal values. This property is optional. If you omit the decimal.mode property, the converter defaults to using the PRECISE decimal handling mode. RAW to String Although Oracle recommends against the use of certain data types, such as RAW , legacy systems might continue to use such types. By default, Debezium emits RAW column types as logical BYTES , a type that enables the storage of binary or text-based data. In some cases, RAW columns might store character data as a series of bytes. To facilitate consumption by consumers, you can configure Debezium to use the RawToStringConverter . The RawToStringConverter provides a way to easily target such RAW columns and emit values as strings, rather than bytes. The following example shows how to add the RawToStringConverter to the connector configuration: Example: RawToStringConverter configuration In the preceding example, the selector property enables you to define a regular expression that specifies the tables or columns that the converter processes. If you omit the selector property, the converter maps all RAW column types to logical STRING field types. 2.5.4. Setting up Oracle to work with Debezium The following steps are necessary to set up Oracle for use with the Debezium Oracle connector. These steps assume the use of the multi-tenancy configuration with a container database and at least one pluggable database. If you do not intend to use a multi-tenant configuration, it might be necessary to adjust the following steps. For details about setting up Oracle for use with the Debezium connector, see the following sections: Section 2.5.4.1, "Compatibility of the Debezium Oracle connector with Oracle installation types" Section 2.5.4.2, "Schemas that the Debezium Oracle connector excludes when capturing change events" Section 2.5.4.4, "Preparing Oracle databases for use with Debezium" Section 2.5.4.5, "Resizing Oracle redo logs to accommodate the data dictionary" Section 2.5.4.7, "Creating an Oracle user for the Debezium Oracle connector" Section 2.5.4.8, "Running the connector with an Oracle standby database" 2.5.4.1. Compatibility of the Debezium Oracle connector with Oracle installation types An Oracle database can be installed either as a standalone instance or using Oracle Real Application Cluster (RAC). The Debezium Oracle connector is compatible with both types of installation. 2.5.4.2. Schemas that the Debezium Oracle connector excludes when capturing change events When the Debezium Oracle connector captures tables, it automatically excludes tables from the following schemas: appqossys audsys ctxsys dvsys dbsfwuser dbsnmp qsmadmin_internal lbacsys mdsys ojvmsys olapsys orddata ordsys outln sys system vecsys (Oracle 23+) wmsys xdb To enable the connector to capture changes from a table, the table must use a schema that is not named in the preceding list. 2.5.4.3. Tables that the Debezium Oracle connector excludes when capturing change events When the Debezium Oracle connector captures tables, it automatically excludes tables that match the following rules: Compression Advisor tables matching the pattern CMP[3|4]USD[0-9]+ . Index-organized tables matching the pattern SYS_IOT_OVER_% . Spatial tables matching the patterns MDRT_% , MDRS_% , or MDXT_% . Nested tables To enable the connector to capture a table with a name that matches any of the preceding rules, you must rename the table. 2.5.4.4. Preparing Oracle databases for use with Debezium Configuration needed for Oracle LogMiner Oracle AWS RDS does not allow you to execute the commands above nor does it allow you to log in as sysdba. AWS provides these alternative commands to configure LogMiner. Before executing these commands, ensure that your Oracle AWS RDS instance is enabled for backups. To confirm that Oracle has backups enabled, execute the command below first. The LOG_MODE should say ARCHIVELOG. If it does not, you may need to reboot your Oracle AWS RDS instance. Configuration needed for Oracle AWS RDS LogMiner Once LOG_MODE is set to ARCHIVELOG, execute the commands to complete LogMiner configuration. The first command set the database to archivelogs and the second adds supplemental logging. Configuration needed for Oracle AWS RDS LogMiner To enable Debezium to capture the before state of changed database rows, you must also enable supplemental logging for captured tables or for the entire database. The following example illustrates how to configure supplemental logging for all columns in a single inventory.customers table. Enabling supplemental logging for all table columns increases the volume of the Oracle redo logs. To prevent excessive growth in the size of the logs, apply the preceding configuration selectively. Minimal supplemental logging must be enabled at the database level and can be configured as follows. 2.5.4.5. Resizing Oracle redo logs to accommodate the data dictionary Depending on the database configuration, the size and number of redo logs might not be sufficient to achieve acceptable performance. Before you set up the Debezium Oracle connector, ensure that the capacity of the redo logs is sufficient to support the database. The capacity of the redo logs for a database must be sufficient to store its data dictionary. In general, the size of the data dictionary increases with the number of tables and columns in the database. If the redo log lacks sufficient capacity, both the database and the Debezium connector might experience performance problems. Consult with your database administrator to evaluate whether the database might require increased log capacity. 2.5.4.6. Specifying the archive log destination that the Debezium Oracle connector uses Oracle database administrators can configure up to 31 different destinations for archive logs. Administrators can set parameters for each destination to designate it for a specific use, for example, log shipping for physical standbys, or external storage to allow for extended log retention. Oracle reports details about archive log destinations in the VUSDARCHIVE_DEST_STATUS view. The Debezium Oracle connector only uses destinations that have a status of VALID and a type of LOCAL . If your Oracle environment includes multiple destinations that satisfy that criteria, consult with your Oracle administrator to determine which archive log destination Debezium should use. Procedure To specify the archive log destination that you want Debezium to use, set the log.mining.archive.destination.name property in the connector configuration. For example, suppose that a database is configured with two archive destination paths, /path/one and /path/two , and that the VUSDARCHIVE_DEST_STATUS table associates these paths with destination names that are specified in the column DEST_NAME . If both destinations satisfy the criteria for Debezium - that is, their status is VALID and their type is LOCAL - to configure the connector to use the archive logs that the database writes to /path/two , set the value of log.mining.archive.destination.name to the value in the DEST_NAME column that is associated with /path/two in the VUSDARCHIVE_DEST_STATUS table. For example, if the DEST_NAME is LOG_ARCHIVE_DEST_3 for /path/two , you would configure Debezium as follows: { "log.mining.archive.destination.name": "LOG_ARCHIVE_DEST_3" } Note Do not set the value of log.mining.archive.destination.name to the path that the database uses for the archive logs. Set the property to the name of an archive log destination in the DEST_NAME column for a row in the VUSDARCHIVE_DEST_STATUS table that satisfies your archive log retention policy. Warning If your Oracle environment includes multiple destinations that satisfy that criteria, and you fail to specify the preferred destination, the Debezium Oracle connector selects the destination path at random. Because the retention policy that is configured for each destination might differ, this can lead to errors if the connector selects a path from which the requested log data was deleted. 2.5.4.7. Creating an Oracle user for the Debezium Oracle connector For the Debezium Oracle connector to capture change events, it must run as an Oracle LogMiner user that has specific permissions. The following example shows the SQL for creating an Oracle user account for the connector in a multi-tenant database model. Warning The connector captures database changes that are made by its own Oracle user account. However, it does not capture changes that are made by the SYS or SYSTEM user accounts. Creating the connector's LogMiner user sqlplus sys/top_secret@//localhost:1521/ORCLCDB as sysdba CREATE TABLESPACE logminer_tbs DATAFILE '/opt/oracle/oradata/ORCLCDB/logminer_tbs.dbf' SIZE 25M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED; exit; sqlplus sys/top_secret@//localhost:1521/ORCLPDB1 as sysdba CREATE TABLESPACE logminer_tbs DATAFILE '/opt/oracle/oradata/ORCLCDB/ORCLPDB1/logminer_tbs.dbf' SIZE 25M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED; exit; sqlplus sys/top_secret@//localhost:1521/ORCLCDB as sysdba CREATE USER c##dbzuser IDENTIFIED BY dbz DEFAULT TABLESPACE logminer_tbs QUOTA UNLIMITED ON logminer_tbs CONTAINER=ALL; GRANT CREATE SESSION TO c##dbzuser CONTAINER=ALL; 1 GRANT SET CONTAINER TO c##dbzuser CONTAINER=ALL; 2 GRANT SELECT ON V_USDDATABASE to c##dbzuser CONTAINER=ALL; 3 GRANT FLASHBACK ANY TABLE TO c##dbzuser CONTAINER=ALL; 4 GRANT SELECT ANY TABLE TO c##dbzuser CONTAINER=ALL; 5 GRANT SELECT_CATALOG_ROLE TO c##dbzuser CONTAINER=ALL; 6 GRANT EXECUTE_CATALOG_ROLE TO c##dbzuser CONTAINER=ALL; 7 GRANT SELECT ANY TRANSACTION TO c##dbzuser CONTAINER=ALL; 8 GRANT LOGMINING TO c##dbzuser CONTAINER=ALL; 9 GRANT CREATE TABLE TO c##dbzuser CONTAINER=ALL; 10 GRANT LOCK ANY TABLE TO c##dbzuser CONTAINER=ALL; 11 GRANT CREATE SEQUENCE TO c##dbzuser CONTAINER=ALL; 12 GRANT EXECUTE ON DBMS_LOGMNR TO c##dbzuser CONTAINER=ALL; 13 GRANT EXECUTE ON DBMS_LOGMNR_D TO c##dbzuser CONTAINER=ALL; 14 GRANT SELECT ON V_USDLOG TO c##dbzuser CONTAINER=ALL; 15 GRANT SELECT ON V_USDLOG_HISTORY TO c##dbzuser CONTAINER=ALL; 16 GRANT SELECT ON V_USDLOGMNR_LOGS TO c##dbzuser CONTAINER=ALL; 17 GRANT SELECT ON V_USDLOGMNR_CONTENTS TO c##dbzuser CONTAINER=ALL; 18 GRANT SELECT ON V_USDLOGMNR_PARAMETERS TO c##dbzuser CONTAINER=ALL; 19 GRANT SELECT ON V_USDLOGFILE TO c##dbzuser CONTAINER=ALL; 20 GRANT SELECT ON V_USDARCHIVED_LOG TO c##dbzuser CONTAINER=ALL; 21 GRANT SELECT ON V_USDARCHIVE_DEST_STATUS TO c##dbzuser CONTAINER=ALL; 22 GRANT SELECT ON V_USDTRANSACTION TO c##dbzuser CONTAINER=ALL; 23 GRANT SELECT ON V_USDMYSTAT TO c##dbzuser CONTAINER=ALL; 24 GRANT SELECT ON V_USDSTATNAME TO c##dbzuser CONTAINER=ALL; 25 exit; Table 2.119. Descriptions of permissions / grants Item Role name Description 1 CREATE SESSION Enables the connector to connect to Oracle. 2 SET CONTAINER Enables the connector to switch between pluggable databases. This is only required when the Oracle installation has container database support (CDB) enabled. 3 SELECT ON V_USDDATABASE Enables the connector to read the VUSDDATABASE table. 4 FLASHBACK ANY TABLE Enables the connector to perform Flashback queries, which is how the connector performs the initial snapshot of data. Optionally, rather than granting FLASHBACK permission on all tables, you can grant the FLASHBACK privilege for specific tables only. 5 SELECT ANY TABLE Enables the connector to read any table. Optionally, rather than granting SELECT permission on all tables, you can grant the SELECT privilege for specific tables only. 6 SELECT_CATALOG_ROLE Enables the connector to read the data dictionary, which is needed by Oracle LogMiner sessions. 7 EXECUTE_CATALOG_ROLE Enables the connector to write the data dictionary into the Oracle redo logs, which is needed to track schema changes. 8 SELECT ANY TRANSACTION Enables the snapshot process to perform a Flashback snapshot query against any transaction. When FLASHBACK ANY TABLE is granted, this should also be granted. 9 LOGMINING This role was added in newer versions of Oracle as a way to grant full access to Oracle LogMiner and its packages. On older versions of Oracle that don't have this role, you can ignore this grant. 10 CREATE TABLE Enables the connector to create its flush table in its default tablespace. The flush table allows the connector to explicitly control flushing of the LGWR internal buffers to disk. 11 LOCK ANY TABLE Enables the connector to lock tables during schema snapshot. If snapshot locks are explicitly disabled via configuration, this grant can be safely ignored. 12 CREATE SEQUENCE Enables the connector to create a sequence in its default tablespace. 13 EXECUTE ON DBMS_LOGMNR Enables the connector to run methods in the DBMS_LOGMNR package. This is required to interact with Oracle LogMiner. On newer versions of Oracle this is granted via the LOGMINING role but on older versions, this must be explicitly granted. 14 EXECUTE ON DBMS_LOGMNR_D Enables the connector to run methods in the DBMS_LOGMNR_D package. This is required to interact with Oracle LogMiner. On newer versions of Oracle this is granted via the LOGMINING role but on older versions, this must be explicitly granted. 15 to 25 SELECT ON V_USD... . Enables the connector to read these tables. The connector must be able to read information about the Oracle redo and archive logs, and the current transaction state, to prepare the Oracle LogMiner session. Without these grants, the connector cannot operate. 2.5.4.8. Running the connector with an Oracle standby database A standby database provides a synchronized copy of the primary instance. In the event of a primary database failure, standby databases provide for continuous availability, and disaster recovery. Oracle makes use of both physical and logical standby databases. Physical standbys A physical standby is an exact, block-for-block copy of the primary production database, and its system change number (SCN) values are identical to those of the primary. The Debezium Oracle connector cannot capture change events directly from a physical standby database, because physical standbys do not accept external connections. The connector can capture events from a physical standby only after the standby is converted to the primary database. The connector then connects to the former standby as if it were any primary database. Logical standbys A logical standby contains the same logical data as the primary, but data might be stored in a different physical manner. SCN offsets in a logical standby differ from the offsets in the primary database. You can configure the Debezium Oracle connector to capture changes from a logical standby database . 2.5.4.8.1. Capturing data from an Oracle failover database When you set up a failover database, it is generally best practice to use a physical standby database rather than a logical standby database. A physical standby maintains a more consistent state with the primary database than does a logical standby. Physical standbys contain an exact replica of the primary data, and the system change number (SCN) values of the standby are identical to those of the primary. In a Debezium environment, after the database fails over to physical standby, the presence of consistent SCN values ensure that the connector can find the last processed SCN value. A physical standby is locked in a read-only mode, with managed recovery running to maintain synchronization. When a database is in standby mode, it does not accept external JDBC connections from clients, and it cannot be accessed by external application. After a failure event, to permit Debezium to connect to the former physical standby,a DBA must perform several actions to enable failover to the standby, and promote it the the primary database. The following list identifies some of the key actions: Cancel managed recovery on the standby. Complete the active recovery process. Convert the standby to the primary role. Open the new primary to client read and write operations. After the former physical standby is available for normal use, you can configure the Debezium Oracle connector to connect to it. To enable the connector to capture from the new primary, edit the database hostname in the connector configuration, replacing the hostname of the original primary with the hostname of the new primary. 2.5.4.8.2. Configuring the Debezium Oracle connector to capture events from a logical standby When the Debezium connector for Oracle connects to a primary database, it uses an internal flush table to manage the flush cycles of the Oracle Log Writer Buffer (LGWR) process. The flush process requires that the user account through which the connector accesses the database has permission to create and write to this flush table. However, a logical stand-by database typically permits read-only access, preventing the connector from writing to the database. You can modify the connector configuration to enable the connector to capture events from a logical standby, or the DBA can create a new writable tablespace in which the connector can store the flush table. Important The ability for the Debezium Oracle connector to ingest changes from a read-only logical standby database is a Developer Preview feature. Developer Preview features are not supported by Red Hat in any way and are not functionally complete or production-ready. Do not use Developer Preview software for production or business-critical workloads. Developer Preview software provides early access to upcoming product software in advance of its possible inclusion in a Red Hat product offering. Customers can use this software to test functionality and provide feedback during the development process. This software might not have any documentation, is subject to change or removal at any time, and has received limited testing. Red Hat might provide ways to submit feedback on Developer Preview software without an associated SLA. For more information about the support scope of Red Hat Developer Preview software, see Developer Preview Support Scope . Procedure To enable Debezium to capture events from an Oracle read-only logical standby database, add the following property to the connector configuration, to disable creation and management of the flush table: The preceding setting prevents the database from creating and updating the LOG_MINING_FLUSH table. You can use the internal.log.mining.read.only property with an Oracle Standalone database, or with an Oracle RAC installation. 2.5.5. Deployment of Debezium Oracle connectors You can use either of the following methods to deploy a Debezium Oracle connector: Use Streams for Apache Kafka to automatically create an image that includes the connector plug-in . This is the preferred method. Build a custom Kafka Connect container image from a Dockerfile . Important Due to licensing requirements, the Debezium Oracle connector archive does not include the Oracle JDBC driver that the connector requires to connect to an Oracle database. To enable the connector to access the database, you must add the driver to your connector environment. For more information, see Obtaining the Oracle JDBC driver . Additional resources Section 2.5.6, "Descriptions of Debezium Oracle connector configuration properties" 2.5.5.1. Obtaining the Oracle JDBC driver Due to licensing requirements, the Oracle JDBC driver file that Debezium requires to connect to an Oracle database is not included in the Debezium Oracle connector archive. The driver is available for download from Maven Central. Depending on the deployment method that you use, you retrieve the driver by adding a command to the Kafka Connect custom resource or to the Dockerfile that you use to build the connector image. If you use Streams for Apache Kafka to add the connector to your Kafka Connect image, add the Maven Central location for the driver to builds.plugins.artifact.url in the KafkaConnect custom resource as shown in Section 2.5.5.3, "Using Streams for Apache Kafka to deploy a Debezium Oracle connector" . If you use a Dockerfile to build a container image for the connector, insert a curl command in the Dockerfile to specify the URL for downloading the required driver file from Maven Central. For more information, see Deploying a Debezium Oracle connector by building a custom Kafka Connect container image from a Dockerfile . 2.5.5.2. Debezium Oracle connector deployment using Streams for Apache Kafka Beginning with Debezium 1.7, the preferred method for deploying a Debezium connector is to use Streams for Apache Kafka to build a Kafka Connect container image that includes the connector plug-in. During the deployment process, you create and use the following custom resources (CRs): A KafkaConnect CR that defines your Kafka Connect instance and includes information about the connector artifacts needs to include in the image. A KafkaConnector CR that provides details that include information the connector uses to access the source database. After Streams for Apache Kafka starts the Kafka Connect pod, you start the connector by applying the KafkaConnector CR. In the build specification for the Kafka Connect image, you can specify the connectors that are available to deploy. For each connector plug-in, you can also specify other components that you want to make available for deployment. For example, you can add Apicurio Registry artifacts, or the Debezium scripting component. When Streams for Apache Kafka builds the Kafka Connect image, it downloads the specified artifacts, and incorporates them into the image. The spec.build.output parameter in the KafkaConnect CR specifies where to store the resulting Kafka Connect container image. Container images can be stored in a Docker registry, or in an OpenShift ImageStream. To store images in an ImageStream, you must create the ImageStream before you deploy Kafka Connect. ImageStreams are not created automatically. Note If you use a KafkaConnect resource to create a cluster, afterwards you cannot use the Kafka Connect REST API to create or update connectors. You can still use the REST API to retrieve information. Additional resources Configuring Kafka Connect in Deploying and Managing Streams for Apache Kafka on OpenShift. Building a new container image automatically in Deploying and Managing Streams for Apache Kafka on OpenShift. 2.5.5.3. Using Streams for Apache Kafka to deploy a Debezium Oracle connector With earlier versions of Streams for Apache Kafka, to deploy Debezium connectors on OpenShift, you were required to first build a Kafka Connect image for the connector. The current preferred method for deploying connectors on OpenShift is to use a build configuration in Streams for Apache Kafka to automatically build a Kafka Connect container image that includes the Debezium connector plug-ins that you want to use. During the build process, the Streams for Apache Kafka Operator transforms input parameters in a KafkaConnect custom resource, including Debezium connector definitions, into a Kafka Connect container image. The build downloads the necessary artifacts from the Red Hat Maven repository or another configured HTTP server. The newly created container is pushed to the container registry that is specified in .spec.build.output , and is used to deploy a Kafka Connect cluster. After Streams for Apache Kafka builds the Kafka Connect image, you create KafkaConnector custom resources to start the connectors that are included in the build. Prerequisites You have access to an OpenShift cluster on which the cluster Operator is installed. The Streams for Apache Kafka Operator is running. An Apache Kafka cluster is deployed as documented in Deploying and Managing Streams for Apache Kafka on OpenShift . Kafka Connect is deployed on Streams for Apache Kafka You have a Red Hat build of Debezium license. The OpenShift oc CLI client is installed or you have access to the OpenShift Container Platform web console. Depending on how you intend to store the Kafka Connect build image, you need registry permissions or you must create an ImageStream resource: To store the build image in an image registry, such as Red Hat Quay.io or Docker Hub An account and permissions to create and manage images in the registry. To store the build image as a native OpenShift ImageStream An ImageStream resource is deployed to the cluster for storing new container images. You must explicitly create an ImageStream for the cluster. ImageStreams are not available by default. For more information about ImageStreams, see Managing image streams on OpenShift Container Platform . Procedure Log in to the OpenShift cluster. Create a Debezium KafkaConnect custom resource (CR) for the connector, or modify an existing one. For example, create a KafkaConnect CR with the name dbz-connect.yaml that specifies the metadata.annotations and spec.build properties. The following example shows an excerpt from a dbz-connect.yaml file that describes a KafkaConnect custom resource. Example 2.34. A dbz-connect.yaml file that defines a KafkaConnect custom resource that includes a Debezium connector In the example that follows, the custom resource is configured to download the following artifacts: The Debezium Oracle connector archive. The Red Hat build of Apicurio Registry archive. The Apicurio Registry is an optional component. Add the Apicurio Registry component only if you intend to use Avro serialization with the connector. The Debezium scripting SMT archive and the associated language dependencies that you want to use with the Debezium connector. The SMT archive and language dependencies are optional components. Add these components only if you intend to use the Debezium content-based routing SMT or filter SMT . The Oracle JDBC driver, which is required to connect to Oracle databases, but is not included in the connector archive. apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: debezium-kafka-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: version: 3.6.0 build: 2 output: 3 type: imagestream 4 image: debezium-streams-connect:latest plugins: 5 - name: debezium-connector-oracle artifacts: - type: zip 6 url: https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-oracle/2.7.3.Final-redhat-00001/debezium-connector-oracle-2.7.3.Final-redhat-00001-plugin.zip 7 - type: zip url: https://maven.repository.redhat.com/ga/io/apicurio/apicurio-registry-distro-connect-converter/2.4.4.Final-redhat- <build-number> /apicurio-registry-distro-connect-converter-2.4.4.Final-redhat- <build-number> .zip 8 - type: zip url: https://maven.repository.redhat.com/ga/io/debezium/debezium-scripting/2.7.3.Final-redhat-00001/debezium-scripting-2.7.3.Final-redhat-00001.zip 9 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy/3.0.11/groovy-3.0.11.jar 10 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-jsr223/3.0.11/groovy-jsr223-3.0.11.jar - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-json3.0.11/groovy-json-3.0.11.jar - type: jar 11 url: https://repo1.maven.org/maven2/com/oracle/database/jdbc/ojdbc8/21.6.0.0/ojdbc8-21.6.0.0.jar bootstrapServers: debezium-kafka-cluster-kafka-bootstrap:9093 ... Table 2.120. Descriptions of Kafka Connect configuration settings Item Description 1 Sets the strimzi.io/use-connector-resources annotation to "true" to enable the Cluster Operator to use KafkaConnector resources to configure connectors in this Kafka Connect cluster. 2 The spec.build configuration specifies where to store the build image and lists the plug-ins to include in the image, along with the location of the plug-in artifacts. 3 The build.output specifies the registry in which the newly built image is stored. 4 Specifies the name and image name for the image output. Valid values for output.type are docker to push into a container registry such as Docker Hub or Quay, or imagestream to push the image to an internal OpenShift ImageStream. To use an ImageStream, an ImageStream resource must be deployed to the cluster. For more information about specifying the build.output in the KafkaConnect configuration, see the Streams for Apache Kafka Build schema reference in {NameConfiguringStreamsOpenShift}. 5 The plugins configuration lists all of the connectors that you want to include in the Kafka Connect image. For each entry in the list, specify a plug-in name , and information for about the artifacts that are required to build the connector. Optionally, for each connector plug-in, you can include other components that you want to be available for use with the connector. For example, you can add Service Registry artifacts, or the Debezium scripting component. 6 The value of artifacts.type specifies the file type of the artifact specified in the artifacts.url . Valid types are zip , tgz , or jar . Debezium connector archives are provided in .zip file format. JDBC driver files are in .jar format. The type value must match the type of the file that is referenced in the url field. 7 The value of artifacts.url specifies the address of an HTTP server, such as a Maven repository, that stores the file for the connector artifact. Debezium connector artifacts are available in the Red Hat Maven repository. The OpenShift cluster must have access to the specified server. 8 (Optional) Specifies the artifact type and url for downloading the Apicurio Registry component. Include the Apicurio Registry artifact, only if you want the connector to use Apache Avro to serialize event keys and values with the Red Hat build of Apicurio Registry, instead of using the default JSON converter. 9 (Optional) Specifies the artifact type and url for the Debezium scripting SMT archive to use with the Debezium connector. Include the scripting SMT only if you intend to use the Debezium content-based routing SMT or filter SMT To use the scripting SMT, you must also deploy a JSR 223-compliant scripting implementation, such as groovy. 10 (Optional) Specifies the artifact type and url for the JAR files of a JSR 223-compliant scripting implementation, which is required by the Debezium scripting SMT. Important If you use Streams for Apache Kafka to incorporate the connector plug-in into your Kafka Connect image, for each of the required scripting language components artifacts.url must specify the location of a JAR file, and the value of artifacts.type must also be set to jar . Invalid values cause the connector fails at runtime. To enable use of the Apache Groovy language with the scripting SMT, the custom resource in the example retrieves JAR files for the following libraries: groovy groovy-jsr223 (scripting agent) groovy-json (module for parsing JSON strings) The Debezium scripting SMT also supports the use of the JSR 223 implementation of GraalVM JavaScript. 11 Specifies the location of the Oracle JDBC driver in Maven Central. The required driver is not included in the Debezium Oracle connector archive. Apply the KafkaConnect build specification to the OpenShift cluster by entering the following command: oc create -f dbz-connect.yaml Based on the configuration specified in the custom resource, the Streams Operator prepares a Kafka Connect image to deploy. After the build completes, the Operator pushes the image to the specified registry or ImageStream, and starts the Kafka Connect cluster. The connector artifacts that you listed in the configuration are available in the cluster. Create a KafkaConnector resource to define an instance of each connector that you want to deploy. For example, create the following KafkaConnector CR, and save it as oracle-inventory-connector.yaml Example 2.35. oracle-inventory-connector.yaml file that defines the KafkaConnector custom resource for a Debezium connector apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: labels: strimzi.io/cluster: debezium-kafka-connect-cluster name: inventory-connector-oracle 1 spec: class: io.debezium.connector.oracle.OracleConnector 2 tasksMax: 1 3 config: 4 schema.history.internal.kafka.bootstrap.servers: debezium-kafka-cluster-kafka-bootstrap.debezium.svc.cluster.local:9092 schema.history.internal.kafka.topic: schema-changes.inventory database.hostname: oracle.debezium-oracle.svc.cluster.local 5 database.port: 1521 6 database.user: debezium 7 database.password: dbz 8 database.dbname: mydatabase 9 topic.prefix: inventory-connector-oracle 10 table.include.list: PUBLIC.INVENTORY 11 ... Table 2.121. Descriptions of connector configuration settings Item Description 1 The name of the connector to register with the Kafka Connect cluster. 2 The name of the connector class. 3 The number of tasks that can operate concurrently. 4 The connector's configuration. 5 The address of the host database instance. 6 The port number of the database instance. 7 The name of the account that Debezium uses to connect to the database. 8 The password that Debezium uses to connect to the database user account. 9 The name of the database to capture changes from. 10 The topic prefix for the database instance or cluster. The specified name must be formed only from alphanumeric characters or underscores. Because the topic prefix is used as the prefix for any Kafka topics that receive change events from this connector, the name must be unique among the connectors in the cluster. This namespace is also used in the names of related Kafka Connect schemas, and the namespaces of a corresponding Avro schema if you integrate the connector with the Avro connector . 11 The list of tables from which the connector captures change events. Create the connector resource by running the following command: oc create -n <namespace> -f <kafkaConnector> .yaml For example, oc create -n debezium -f oracle-inventory-connector.yaml The connector is registered to the Kafka Connect cluster and starts to run against the database that is specified by spec.config.database.dbname in the KafkaConnector CR. After the connector pod is ready, Debezium is running. You are now ready to verify the Debezium Oracle deployment . 2.5.5.4. Deploying a Debezium Oracle connector by building a custom Kafka Connect container image from a Dockerfile To deploy a Debezium Oracle connector, you must build a custom Kafka Connect container image that contains the Debezium connector archive, and then push this container image to a container registry. You then need to create the following custom resources (CRs): A KafkaConnect CR that defines your Kafka Connect instance. The image property in the CR specifies the name of the container image that you create to run your Debezium connector. You apply this CR to the OpenShift instance where Red Hat Streams for Apache Kafka is deployed. Streams for Apache Kafka offers operators and images that bring Apache Kafka to OpenShift. A KafkaConnector CR that defines your Debezium Oracle connector. Apply this CR to the same OpenShift instance where you apply the KafkaConnect CR. Prerequisites Oracle Database is running and you completed the steps to set up Oracle to work with a Debezium connector . Streams for Apache Kafka is deployed on OpenShift and is running Apache Kafka and Kafka Connect. For more information, see Deploying and Managing Streams for Apache Kafka on OpenShift Podman or Docker is installed. You have an account and permissions to create and manage containers in the container registry (such as quay.io or docker.io ) to which you plan to add the container that will run your Debezium connector. The Kafka Connect server has access to Maven Central to download the required JDBC driver for Oracle. You can also use a local copy of the driver, or one that is available from a local Maven repository or other HTTP server. For more information, see Obtaining the Oracle JDBC driver . Procedure Create the Debezium Oracle container for Kafka Connect: Create a Dockerfile that uses registry.redhat.io/amq-streams-kafka-35-rhel8:2.5.0 as the base image. For example, from a terminal window, enter the following command: cat <<EOF >debezium-container-for-oracle.yaml 1 FROM registry.redhat.io/amq-streams-kafka-35-rhel8:2.5.0 USER root:root RUN mkdir -p /opt/kafka/plugins/debezium 2 RUN cd /opt/kafka/plugins/debezium/ \ && curl -O https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-oracle/2.7.3.Final-redhat-00001/debezium-connector-oracle-2.7.3.Final-redhat-00001-plugin.zip \ && unzip debezium-connector-oracle-2.7.3.Final-redhat-00001-plugin.zip \ && rm debezium-connector-oracle-2.7.3.Final-redhat-00001-plugin.zip RUN cd /opt/kafka/plugins/debezium/ \ && curl -O https://repo1.maven.org/maven2/com/oracle/ojdbc/ojdbc8/21.1.0.0/ojdbc8-21.1.0.0.jar USER 1001 EOF Item Description 1 You can specify any file name that you want. 2 Specifies the path to your Kafka Connect plug-ins directory. If your Kafka Connect plug-ins directory is in a different location, replace this path with the actual path of your directory. The command creates a Dockerfile with the name debezium-container-for-oracle.yaml in the current directory. Build the container image from the debezium-container-for-oracle.yaml Docker file that you created in the step. From the directory that contains the file, open a terminal window and enter one of the following commands: podman build -t debezium-container-for-oracle:latest . docker build -t debezium-container-for-oracle:latest . The preceding commands build a container image with the name debezium-container-for-oracle . Push your custom image to a container registry, such as quay.io or an internal container registry. The container registry must be available to the OpenShift instance where you want to deploy the image. Enter one of the following commands: podman push <myregistry.io> /debezium-container-for-oracle:latest docker push <myregistry.io> /debezium-container-for-oracle:latest Create a new Debezium Oracle KafkaConnect custom resource (CR). For example, create a KafkaConnect CR with the name dbz-connect.yaml that specifies annotations and image properties. The following example shows an excerpt from a dbz-connect.yaml file that describes a KafkaConnect custom resource. apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: image: debezium-container-for-oracle 2 ... Item Description 1 metadata.annotations indicates to the Cluster Operator that KafkaConnector resources are used to configure connectors in this Kafka Connect cluster. 2 spec.image specifies the name of the image that you created to run your Debezium connector. This property overrides the STRIMZI_DEFAULT_KAFKA_CONNECT_IMAGE variable in the Cluster Operator. Apply the KafkaConnect CR to the OpenShift Kafka Connect environment by entering the following command: oc create -f dbz-connect.yaml The command adds a Kafka Connect instance that specifies the name of the image that you created to run your Debezium connector. Create a KafkaConnector custom resource that configures your Debezium Oracle connector instance. You configure a Debezium Oracle connector in a .yaml file that specifies the configuration properties for the connector. The connector configuration might instruct Debezium to produce events for a subset of the schemas and tables, or it might set properties so that Debezium ignores, masks, or truncates values in specified columns that are sensitive, too large, or not needed. The following example configures a Debezium connector that connects to an Oracle host IP address, on port 1521 . This host has a database named ORCLCDB , and server1 is the server's logical name. Oracle inventory-connector.yaml apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: inventory-connector-oracle 1 labels: strimzi.io/cluster: my-connect-cluster annotations: strimzi.io/use-connector-resources: 'true' spec: class: io.debezium.connector.oracle.OracleConnector 2 config: database.hostname: <oracle_ip_address> 3 database.port: 1521 4 database.user: c##dbzuser 5 database.password: dbz 6 database.dbname: ORCLCDB 7 database.pdb.name : ORCLPDB1, 8 topic.prefix: inventory-connector-oracle 9 schema.history.internal.kafka.bootstrap.servers: kafka:9092 10 schema.history.internal.kafka.topic: schema-changes.inventory 11 Table 2.122. Descriptions of connector configuration settings Item Description 1 The name of our connector when we register it with a Kafka Connect service. 2 The name of this Oracle connector class. 3 The address of the Oracle instance. 4 The port number of the Oracle instance. 5 The name of the Oracle user, as specified in Creating users for the connector . 6 The password for the Oracle user, as specified in Creating users for the connector . 7 The name of the database to capture changes from. 8 The name of the Oracle pluggable database that the connector captures changes from. Used in container database (CDB) installations only. 9 Topic prefix identifies and provides a namespace for the Oracle database server from which the connector captures changes. 10 The list of Kafka brokers that this connector uses to write and recover DDL statements to the database schema history topic. 11 The name of the database schema history topic where the connector writes and recovers DDL statements. This topic is for internal use only and should not be used by consumers. Create your connector instance with Kafka Connect. For example, if you saved your KafkaConnector resource in the inventory-connector.yaml file, you would run the following command: oc apply -f inventory-connector.yaml The preceding command registers inventory-connector and the connector starts to run against the server1 database as defined in the KafkaConnector CR. For the complete list of the configuration properties that you can set for the Debezium Oracle connector, see Oracle connector properties . Results After the connector starts, it performs a consistent snapshot of the Oracle databases that the connector is configured for. The connector then starts generating data change events for row-level operations and streaming the change event records to Kafka topics. 2.5.5.5. Configuration of container databases and non-container-databases Oracle Database supports the following deployment types: Container database (CDB) A database that can contain multiple pluggable databases (PDBs). Database clients connect to each PDB as if it were a standard, non-CDB database. Non-container database (non-CDB) A standard Oracle database, which does not support the creation of pluggable databases. 2.5.5.6. Verifying that the Debezium Oracle connector is running If the connector starts correctly without errors, it creates a topic for each table that the connector is configured to capture. Downstream applications can subscribe to these topics to retrieve information events that occur in the source database. To verify that the connector is running, you perform the following operations from the OpenShift Container Platform web console, or through the OpenShift CLI tool (oc): Verify the connector status. Verify that the connector generates topics. Verify that topics are populated with events for read operations ("op":"r") that the connector generates during the initial snapshot of each table. Prerequisites A Debezium connector is deployed to Streams for Apache Kafka on OpenShift. The OpenShift oc CLI client is installed. You have access to the OpenShift Container Platform web console. Procedure Check the status of the KafkaConnector resource by using one of the following methods: From the OpenShift Container Platform web console: Navigate to Home Search . On the Search page, click Resources to open the Select Resource box, and then type KafkaConnector . From the KafkaConnectors list, click the name of the connector that you want to check, for example inventory-connector-oracle . In the Conditions section, verify that the values in the Type and Status columns are set to Ready and True . From a terminal window: Enter the following command: oc describe KafkaConnector <connector-name> -n <project> For example, oc describe KafkaConnector inventory-connector-oracle -n debezium The command returns status information that is similar to the following output: Example 2.36. KafkaConnector resource status Name: inventory-connector-oracle Namespace: debezium Labels: strimzi.io/cluster=debezium-kafka-connect-cluster Annotations: <none> API Version: kafka.strimzi.io/v1beta2 Kind: KafkaConnector ... Status: Conditions: Last Transition Time: 2021-12-08T17:41:34.897153Z Status: True Type: Ready Connector Status: Connector: State: RUNNING worker_id: 10.131.1.124:8083 Name: inventory-connector-oracle Tasks: Id: 0 State: RUNNING worker_id: 10.131.1.124:8083 Type: source Observed Generation: 1 Tasks Max: 1 Topics: inventory-connector-oracle.inventory inventory-connector-oracle.inventory.addresses inventory-connector-oracle.inventory.customers inventory-connector-oracle.inventory.geom inventory-connector-oracle.inventory.orders inventory-connector-oracle.inventory.products inventory-connector-oracle.inventory.products_on_hand Events: <none> Verify that the connector created Kafka topics: From the OpenShift Container Platform web console. Navigate to Home Search . On the Search page, click Resources to open the Select Resource box, and then type KafkaTopic . From the KafkaTopics list, click the name of the topic that you want to check, for example, inventory-connector-oracle.inventory.orders---ac5e98ac6a5d91e04d8ec0dc9078a1ece439081d . In the Conditions section, verify that the values in the Type and Status columns are set to Ready and True . From a terminal window: Enter the following command: oc get kafkatopics The command returns status information that is similar to the following output: Example 2.37. KafkaTopic resource status Check topic content. From a terminal window, enter the following command: oc exec -n <project> -it <kafka-cluster> -- /opt/kafka/bin/kafka-console-consumer.sh \ > --bootstrap-server localhost:9092 \ > --from-beginning \ > --property print.key=true \ > --topic= <topic-name > For example, oc exec -n debezium -it debezium-kafka-cluster-kafka-0 -- /opt/kafka/bin/kafka-console-consumer.sh \ > --bootstrap-server localhost:9092 \ > --from-beginning \ > --property print.key=true \ > --topic=inventory-connector-oracle.inventory.products_on_hand The format for specifying the topic name is the same as the oc describe command returns in Step 1, for example, inventory-connector-oracle.inventory.addresses . For each event in the topic, the command returns information that is similar to the following output: Example 2.38. Content of a Debezium change event In the preceding example, the payload value shows that the connector snapshot generated a read ( "op" ="r" ) event from the table inventory.products_on_hand . The "before" state of the product_id record is null , indicating that no value exists for the record. The "after" state shows a quantity of 3 for the item with product_id 101 . 2.5.6. Descriptions of Debezium Oracle connector configuration properties The Debezium Oracle connector has numerous configuration properties that you can use to achieve the right connector behavior for your application. Many properties have default values. Information about the properties is organized as follows: Required Debezium Oracle connector configuration properties Database schema history connector configuration properties that control how Debezium processes events that it reads from the database schema history topic. Pass-through Db2 connector configuration properties Pass-through database schema history properties for configuring producer and consumer clients Pass-through Kafka signals configuration properties Pass-through Kafka signals consumer client configuration properties Pass-through sink notification configuration properties Pass-through database driver configuration properties Required Debezium Oracle connector configuration properties The following configuration properties are required unless a default value is available. Property Default Description name No default Unique name for the connector. Attempting to register again with the same name will fail. (This property is required by all Kafka Connect connectors.) connector.class No default The name of the Java class for the connector. Always use a value of io.debezium.connector.oracle.OracleConnector for the Oracle connector. converters No default Enumerates a comma-separated list of the symbolic names of the custom converter instances that the connector can use. For example, boolean . This property is required to enable the connector to use a custom converter. For each converter that you configure for a connector, you must also add a .type property, which specifies the fully-qualified name of the class that implements the converter interface. The .type property uses the following format: <converterSymbolicName> .type For example, If you want to further control the behavior of a configured converter, you can add one or more configuration parameters to pass values to the converter. To associate any additional configuration parameters with a converter, prefix the parameter names with the symbolic name of the converter. For example, to define a selector parameter that specifies the subset of columns that the boolean converter processes, add the following property: tasks.max 1 The maximum number of tasks to create for this connector. The Oracle connector always uses a single task and therefore does not use this value, so the default is always acceptable. database.hostname No default IP address or hostname of the Oracle database server. database.port No default Integer port number of the Oracle database server. database.user No default Name of the Oracle user account that the connector uses to connect to the Oracle database server. database.password No default Password to use when connecting to the Oracle database server. database.dbname No default Name of the database to connect to. In a container database environment, specify the name of the root container database (CDB), not the name of an included pluggable database (PDB). database.url No default Specifies the raw database JDBC URL. Use this property to provide flexibility in defining that database connection. Valid values include raw TNS names and RAC connection strings. database.pdb.name No default Name of the Oracle pluggable database to connect to. Use this property with container database (CDB) installations only. topic.prefix No default Topic prefix that provides a namespace for the Oracle database server from which the connector captures changes. The value that you set is used as a prefix for all Kafka topic names that the connector emits. Specify a topic prefix that is unique among all connectors in your Debezium environment. The following characters are valid: alphanumeric characters, hyphens, dots, and underscores. Warning Do not change the value of this property. If you change the name value, after a restart, instead of continuing to emit events to the original topics, the connector emits subsequent events to topics whose names are based on the new value. The connector is also unable to recover its database schema history topic. database.connection.adapter logminer The adapter implementation that the connector uses when it streams database changes. You can set the following values: logminer (default) The connector uses the native Oracle LogMiner API. snapshot.mode initial Specifies the mode that the connector uses to take snapshots of a captured table. You can set the following values: always The snapshot includes the structure and data of the captured tables. Specify this value to populate topics with a complete representation of the data from the captured tables on each connector start. initial The snapshot includes the structure and data of the captured tables. Specify this value to populate topics with a complete representation of the data from the captured tables. If the snapshot completes successfully, upon connector start snapshot is not executed again. initial_only The snapshot includes the structure and data of the captured tables. The connector performs an initial snapshot and then stops, without processing any subsequent changes. schema_only Deprecated, see no-data no_data The snapshot includes only the structure of captured tables. Specify this value if you want the connector to capture data only for changes that occur after the snapshot. schema_only_recovery Deprecated, see recovery . recovery This is a recovery setting for a connector that has already been capturing changes. When you restart the connector, this setting enables recovery of a corrupted or lost database schema history topic. You might set it periodically to "clean up" a database schema history topic that has been growing unexpectedly. Database schema history topics require infinite retention. Note this mode is only safe to be used when it is guaranteed that no schema changes happened since the point in time the connector was shut down before and the point in time the snapshot is taken. After the snapshot is complete, the connector continues to read change events from the database's redo logs except when snapshot.mode is configured as initial_only . when_needed After the connector starts, it performs a snapshot only if it detects one of the following circumstances: It cannot detect any topic offsets. A previously recorded offset specifies a log position that is not available on the server. For more information, see the table of snapshot.mode options . snapshot.locking.mode shared Controls whether and for how long the connector holds a table lock. Table locks prevent certain types of changes table operations from occurring while the connector performs a snapshot. You can set the following values: shared Enables concurrent access to the table, but prevents any session from acquiring an exclusive table lock. The connector acquires a ROW SHARE level lock while it captures table schema. none Prevents the connector from acquiring any table locks during the snapshot. Use this setting only if no schema changes might occur during the creation of the snapshot. snapshot.query.mode select_all Specifies how the connector queries data while performing a snapshot. Set one of the following options: select_all The connector performs a select all query by default, optionally adjusting the columns selected based on the column include and exclude list configurations. This setting enables you to manage snapshot content in a more flexible manner compared to using the snapshot.select.statement.overrides property. snapshot.include.collection.list All tables specified in the connector's table.include.list property. An optional, comma-separated list of regular expressions that match the fully-qualified names ( <databaseName>. <schemaName> . <tableName> ) of the tables to include in a snapshot. In a multitenant container database (CDB) environment, the regular expression must include the pluggable database (PDB) name , using the format <pdbName> . <schemaName> . <tableName> . To match the name of a table, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the table; it does not match substrings that might be present in a table name. Only POSIX regular expressions are valid. A snapshot can only include tables that are named in the connector's table.include.list property. This property takes effect only if the connector's snapshot.mode property is set to a value other than never . This property does not affect the behavior of incremental snapshots. snapshot.select.statement.overrides No default Specifies the table rows to include in a snapshot. Use the property if you want a snapshot to include only a subset of the rows in a table. This property affects snapshots only. It does not apply to events that the connector reads from the log. The property contains a comma-separated list of fully-qualified table names in the form <schemaName>.<tableName> . For example, "snapshot.select.statement.overrides": "inventory.products,customers.orders" For each table in the list, add a further configuration property that specifies the SELECT statement for the connector to run on the table when it takes a snapshot. The specified SELECT statement determines the subset of table rows to include in the snapshot. Use the following format to specify the name of this SELECT statement property: snapshot.select.statement.overrides. <schemaName> . <tableName> For example, snapshot.select.statement.overrides.customers.orders Example: From a customers.orders table that includes the soft-delete column, delete_flag , add the following properties if you want a snapshot to include only those records that are not soft-deleted: In the resulting snapshot, the connector includes only the records for which delete_flag = 0 . schema.include.list No default An optional, comma-separated list of regular expressions that match names of schemas for which you want to capture changes. Only POSIX regular expressions are valid. Any schema name not included in schema.include.list is excluded from having its changes captured. By default, all non-system schemas have their changes captured. To match the name of a schema, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the schema; it does not match substrings that might be present in a schema name. If you include this property in the configuration, do not also set the schema.exclude.list property. include.schema.comments false Boolean value that specifies whether the connector should parse and publish table and column comments on metadata objects. Enabling this option will bring the implications on memory usage. The number and size of logical schema objects is what largely impacts how much memory is consumed by the Debezium connectors, and adding potentially large string data to each of them can potentially be quite expensive. schema.exclude.list No default An optional, comma-separated list of regular expressions that match names of schemas for which you do not want to capture changes. Only POSIX regular expressions are valid. Any schema whose name is not included in schema.exclude.list has its changes captured, with the exception of system schemas. To match the name of a schema, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the schema; it does not match substrings that might be present in a schema name. If you include this property in the configuration, do not set the`schema.include.list` property. table.include.list No default An optional comma-separated list of regular expressions that match fully-qualified table identifiers for tables to be captured. Only POSIX regular expressions are valid. When this property is set, the connector captures changes only from the specified tables. Each table identifier uses the following format: <schema_name>.<table_name> By default, the connector monitors every non-system table in each captured database. To match the name of a table, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the table; it does not match substrings that might be present in a table name. If you include this property in the configuration, do not also set the table.exclude.list property. table.exclude.list No default An optional comma-separated list of regular expressions that match fully-qualified table identifiers for tables to be excluded from monitoring. Only POSIX regular expressions are valid. The connector captures change events from any table that is not specified in the exclude list. Specify the identifier for each table using the following format: <schemaName>.<tableName> . To match the name of a table, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the table; it does not match substrings that might be present in a table name. If you include this property in the configuration, do not also set the table.include.list property. column.include.list No default An optional, comma-separated list of regular expressions that match the fully-qualified names of columns that want to include in the change event message values. Only POSIX regular expressions are valid. Fully-qualified names for columns use the following format: <Schema_name>.<table_name>.<column_name> The primary key column is always included in an event's key, even if you do not use this property to explicitly include its value. To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column it does not match substrings that might be present in a column name. If you include this property in the configuration, do not also set the column.exclude.list property. column.exclude.list No default An optional, comma-separated list of regular expressions that match the fully-qualified names of columns that you want to exclude from change event message values. Only POSIX regular expressions are valid. Fully-qualified column names use the following format: <schema_name>.<table_name>.<column_name> The primary key column is always included in an event's key, even if you use this property to explicitly exclude its value. To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column it does not match substrings that might be present in a column name. If you include this property in the configuration, do not set the column.include.list property. skip.messages.without.change false Specifies whether to skip publishing messages when there is no change in included columns. This would essentially filter messages if there is no change in columns included as per column.include.list or column.exclude.list properties. column.mask.hash. hashAlgorithm .with.salt. salt ; column.mask.hash.v2. hashAlgorithm .with.salt. salt n/a An optional, comma-separated list of regular expressions that match the fully-qualified names of character-based columns. Fully-qualified names for columns are of the form <schemaName> . <tableName> . <columnName> . To match the name of a column Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. In the resulting change event record, the values for the specified columns are replaced with pseudonyms. A pseudonym consists of the hashed value that results from applying the specified hashAlgorithm and salt . Based on the hash function that is used, referential integrity is maintained, while column values are replaced with pseudonyms. Supported hash functions are described in the MessageDigest section of the Java Cryptography Architecture Standard Algorithm Name Documentation. In the following example, CzQMA0cB5K is a randomly selected salt. If necessary, the pseudonym is automatically shortened to the length of the column. The connector configuration can include multiple properties that specify different hash algorithms and salts. Depending on the hashAlgorithm used, the salt selected, and the actual data set, the resulting data set might not be completely masked. Hashing strategy version 2 should be used to ensure fidelity if the value is being hashed in different places or systems. binary.handling.mode bytes Specifies how binary ( blob ) columns should be represented in change events, including: bytes represents binary data as byte array (default), base64 represents binary data as base64-encoded String, base64-url-safe represents binary data as base64-url-safe-encoded String, hex represents binary data as hex-encoded (base16) String schema.name.adjustment.mode none Specifies how schema names should be adjusted for compatibility with the message converter used by the connector. Possible settings: none does not apply any adjustment. avro replaces the characters that cannot be used in the Avro type name with underscore. avro_unicode replaces the underscore or characters that cannot be used in the Avro type name with corresponding unicode like _uxxxx. Note: _ is an escape sequence like backslash in Java field.name.adjustment.mode none Specifies how field names should be adjusted for compatibility with the message converter used by the connector. Possible settings: none does not apply any adjustment. avro replaces the characters that cannot be used in the Avro type name with underscore. avro_unicode replaces the underscore or characters that cannot be used in the Avro type name with corresponding unicode like _uxxxx. Note: _ is an escape sequence like backslash in Java See Avro naming for more details. decimal.handling.mode precise Specifies how the connector should handle floating point values for NUMBER , DECIMAL and NUMERIC columns. You can set one of the following options: precise (default) Represents values precisely by using java.math.BigDecimal values represented in change events in a binary form. double Represents values by using double values. Using double values is easier, but can result in a loss of precision. string Encodes values as formatted strings. Using the string option is easier to consume, but results in a loss of semantic information about the real type. For more information, see Numeric types . interval.handling.mode numeric Specifies how the connector should handle values for interval columns: numeric represents intervals using approximate number of microseconds. string represents intervals exactly by using the string pattern representation P<years>Y<months>M<days>DT<hours>H<minutes>M<seconds>S . For example: P1Y2M3DT4H5M6.78S . event.processing.failure.handling.mode fail Specifies how the connector should react to exceptions during processing of events. You can set one of the following options: fail Propagates the exception (indicating the offset of the problematic event), causing the connector to stop. warn Causes the problematic event to be skipped. The offset of the problematic event is then logged. skip Causes the problematic event to be skipped. max.batch.size 2048 A positive integer value that specifies the maximum size of each batch of events to process during each iteration of this connector. max.queue.size 8192 Positive integer value that specifies the maximum number of records that the blocking queue can hold. When Debezium reads events streamed from the database, it places the events in the blocking queue before it writes them to Kafka. The blocking queue can provide backpressure for reading change events from the database in cases where the connector ingests messages faster than it can write them to Kafka, or when Kafka becomes unavailable. Events that are held in the queue are disregarded when the connector periodically records offsets. Always set the value of max.queue.size to be larger than the value of max.batch.size . max.queue.size.in.bytes 0 (disabled) A long integer value that specifies the maximum volume of the blocking queue in bytes. By default, volume limits are not specified for the blocking queue. To specify the number of bytes that the queue can consume, set this property to a positive long value. If max.queue.size is also set, writing to the queue is blocked when the size of the queue reaches the limit specified by either property. For example, if you set max.queue.size=1000 , and max.queue.size.in.bytes=5000 , writing to the queue is blocked after the queue contains 1000 records, or after the volume of the records in the queue reaches 5000 bytes. poll.interval.ms 500 (0.5 second) Positive integer value that specifies the number of milliseconds the connector should wait during each iteration for new change events to appear. tombstones.on.delete true Controls whether a delete event is followed by a tombstone event. The following values are possible: true For each delete operation, the connector emits a delete event and a subsequent tombstone event. false For each delete operation, the connector emits only a delete event. After a source record is deleted, a tombstone event (the default behavior) enables Kafka to completely delete all events that share the key of the deleted row in topics that have log compaction enabled. message.key.columns No default A list of expressions that specify the columns that the connector uses to form custom message keys for change event records that it publishes to the Kafka topics for specified tables. By default, Debezium uses the primary key column of a table as the message key for records that it emits. In place of the default, or to specify a key for tables that lack a primary key, you can configure custom message keys based on one or more columns. To establish a custom message key for a table, list the table, followed by the columns to use as the message key. Each list entry takes the following format: <fullyQualifiedTableName> : <keyColumn> , <keyColumn> To base a table key on multiple column names, insert commas between the column names. Each fully-qualified table name is a regular expression in the following format: <schemaName> . <tableName> The property can include entries for multiple tables. Use a semicolon to separate table entries in the list. The following example sets the message key for the tables inventory.customers and purchase.orders : inventory.customers:pk1,pk2;(.*).purchaseorders:pk3,pk4 For the table inventory.customer , the columns pk1 and pk2 are specified as the message key. For the purchaseorders tables in any schema, the columns pk3 and pk4 server as the message key. There is no limit to the number of columns that you use to create custom message keys. However, it's best to use the minimum number that are required to specify a unique key. column.truncate.to. length .chars No default An optional, comma-separated list of regular expressions that match the fully-qualified names of character-based columns. Set this property if you want the connector to mask the values for a set of columns, for example, if they contain sensitive data. Set length to a positive integer to replace data in the specified columns with the number of asterisk ( * ) characters specified by the length in the property name. Set length to 0 (zero) to replace data in the specified columns with an empty string. The fully-qualified name of a column observes the following format: <schemaName> . <tableName> . <columnName> . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. You can specify multiple properties with different lengths in a single configuration. column.mask.with. length .chars No default An optional comma-separated list of regular expressions for masking column names in change event messages by replacing characters with asterisks ( * ). Specify the number of characters to replace in the name of the property, for example, column.mask.with.8.chars . Specify length as a positive integer or zero. Then add regular expressions to the list for each character-based column name where you want to apply a mask. Use the following format to specify fully-qualified column names: <schemaName> . <tableName> . <columnName> . The connector configuration can include multiple properties that specify different lengths. column.propagate.source.type No default An optional, comma-separated list of regular expressions that match the fully-qualified names of columns for which you want the connector to emit extra parameters that represent column metadata. When this property is set, the connector adds the following fields to the schema of event records: __debezium.source.column.type __debezium.source.column.length __debezium.source.column.scale These parameters propagate a column's original type name and length (for variable-width types), respectively. Enabling the connector to emit this extra data can assist in properly sizing specific numeric or character-based columns in sink databases. The fully-qualified name of a column observes one of the following formats: <tableName> . <columnName> , or <schemaName> . <tableName> . <columnName> . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. datatype.propagate.source.type No default An optional, comma-separated list of regular expressions that specify the fully-qualified names of data types that are defined for columns in a database. When this property is set, for columns with matching data types, the connector emits event records that include the following extra fields in their schema: __debezium.source.column.type __debezium.source.column.length __debezium.source.column.scale These parameters propagate a column's original type name and length (for variable-width types), respectively. Enabling the connector to emit this extra data can assist in properly sizing specific numeric or character-based columns in sink databases. The fully-qualified name of a column observes one of the following formats: <tableName> . <typeName> , or <schemaName> . <tableName> . <typeName> . To match the name of a data type, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the data type; the expression does not match substrings that might be present in a type name. For the list of Oracle-specific data type names, see the Oracle data type mappings . heartbeat.interval.ms 0 Specifies, in milliseconds, how frequently the connector sends messages to a heartbeat topic. Use this property to determine whether the connector continues to receive change events from the source database. It can also be useful to set the property in situations where no change events occur in captured tables for an extended period. In such a case, although the connector continues to read the redo log, it emits no change event messages, so that the offset in the Kafka topic remains unchanged. Because the connector does not flush the latest system change number (SCN) that it read from the database, the database might retain the redo log files for longer than necessary. If the connector restarts, the extended retention period could result in the connector redundantly sending some change events. The default value of 0 prevents the connector from sending any heartbeat messages. heartbeat.action.query No default Specifies a query that the connector executes on the source database when the connector sends a heartbeat message. For example: INSERT INTO test_heartbeat_table (text) VALUES ('test_heartbeat') The connector runs the query after it emits a heartbeat message . Set this property and create a heartbeat table to receive the heartbeat messages to resolve situations in which Debezium fails to synchronize offsets on low-traffic databases that are on the same host as a high-traffic database . After the connector inserts records into the configured table, it is able to receive changes from the low-traffic database and acknowledge SCN changes in the database, so that offsets can be synchronized with the broker. snapshot.delay.ms No default Specifies an interval in milliseconds that the connector waits after it starts before it takes a snapshot. Use this property to prevent snapshot interruptions when you start multiple connectors in a cluster, which might cause re-balancing of connectors. streaming.delay.ms 0 Specifies the time, in milliseconds, that the connector delays the start of the streaming process after it completes a snapshot. Setting a delay interval helps to prevent the connector from restarting snapshots in the event that a failure occurs immediately after the snapshot completes, but before the streaming process begins. Set a delay value that is higher than the value of the offset.flush.interval.ms property that is set for the Kafka Connect worker. snapshot.fetch.size 10000 Specifies the maximum number of rows that should be read in one go from each table while taking a snapshot. The connector reads table contents in multiple batches of the specified size. query.fetch.size 10000 Specifies the number of rows that will be fetched for each database round-trip of a given query. Using a value of 0 will use the JDBC driver's default fetch size. provide.transaction.metadata false Set the property to true if you want Debezium to generate events with transaction boundaries and enriches data events envelope with transaction metadata. See Transaction Metadata for additional details. log.mining.strategy redo_log_catalog Specifies the mining strategy that controls how Oracle LogMiner builds and uses a given data dictionary for resolving table and column ids to names. redo_log_catalog :: Writes the data dictionary to the online redo logs causing more archive logs to be generated over time. This also enables tracking DDL changes against captured tables, so if the schema changes frequently this is the ideal choice. online_catalog :: Uses the database's current data dictionary to resolve object ids and does not write any extra information to the online redo logs. This allows LogMiner to mine substantially faster but at the expense that DDL changes cannot be tracked. If the captured table(s) schema changes infrequently or never, this is the ideal choice. hybrid :: Uses a combination of the database's current data dictionary and the Debezium in-memory schema model to resole table and column names seamlessly. This mode performs at the level of the online_catalog LogMiner strategy with the schema tracking resilience of the redo_log_catalog strategy while not incurring the overhead of archive log generation and performance costs of the redo_log_catalog strategy. log.mining.query.filter.mode none Specifies the mining query mode that controls how the Oracle LogMiner query is built. none :: The query is generated without doing any schema, table, or username filtering in the query. in :: The query is generated using a standard SQL in-clause to filter schema, table, and usernames on the database side. The schema, table, and username configuration include/exclude lists should not specify any regular expressions as the query is built using the values directly. regex :: The query is generated using Oracle's REGEXP_LIKE operator to filter schema and table names on the database side, along with usernames using a SQL in-clause. The schema and table configuration include/exclude lists can safely specify regular expressions. log.mining.buffer.type memory The buffer type controls how the connector manages buffering transaction data. memory - Uses the JVM process' heap to buffer all transaction data. Choose this option if you don't expect the connector to process a high number of long-running or large transactions. When this option is active, the buffer state is not persisted across restarts. Following a restart, recreate the buffer from the SCN value of the current offset. log.mining.session.max.ms 0 The maximum number of milliseconds that a LogMiner session can be active before a new session is used. For low volume systems, a LogMiner session may consume too much PGA memory when the same session is used for a long period of time. The default behavior is to only use a new LogMiner session when a log switch is detected. By setting this value to something greater than 0 , this specifies the maximum number of milliseconds a LogMiner session can be active before it gets stopped and started to deallocate and reallocate PGA memory. log.mining.restart.connection false Specifies whether the JDBC connection will be closed and re-opened on log switches or when mining session has reached maximum lifetime threshold. By default, the JDBC connection is not closed across log switches or maximum session lifetimes. This should be enabled if you experience excessive Oracle SGA growth with LogMiner. log.mining.batch.size.min 1000 The minimum SCN interval size that this connector attempts to read from redo/archive logs. Active batch size is also increased/decreased by this amount for tuning connector throughput when needed. log.mining.batch.size.max 100000 The maximum SCN interval size that this connector uses when reading from redo/archive logs. log.mining.batch.size.default 20000 The starting SCN interval size that the connector uses for reading data from redo/archive logs. This also servers as a measure for adjusting batch size - when the difference between current SCN and beginning/end SCN of the batch is bigger than this value, batch size is increased/decreased. log.mining.sleep.time.min.ms 0 The minimum amount of time that the connector sleeps after reading data from redo/archive logs and before starting reading data again. Value is in milliseconds. log.mining.sleep.time.max.ms 3000 The maximum amount of time that the connector ill sleeps after reading data from redo/archive logs and before starting reading data again. Value is in milliseconds. log.mining.sleep.time.default.ms 1000 The starting amount of time that the connector sleeps after reading data from redo/archive logs and before starting reading data again. Value is in milliseconds. log.mining.sleep.time.increment.ms 200 The maximum amount of time up or down that the connector uses to tune the optimal sleep time when reading data from logminer. Value is in milliseconds. log.mining.archive.log.hours 0 The number of hours in the past from SYSDATE to mine archive logs. When the default setting ( 0 ) is used, the connector mines all archive logs. log.mining.archive.log.only.mode false Controls whether or not the connector mines changes from just archive logs or a combination of the online redo logs and archive logs (the default). Redo logs use a circular buffer that can be archived at any point. In environments where online redo logs are archived frequently, this can lead to LogMiner session failures. In contrast to redo logs, archive logs are guaranteed to be reliable. Set this option to true to force the connector to mine archive logs only. After you set the connector to mine only the archive logs, the latency between an operation being committed and the connector emitting an associated change event might increase. The degree of latency depends on how frequently the database is configured to archive online redo logs. log.mining.archive.log.only.scn.poll.interval.ms 10000 The number of milliseconds the connector will sleep in between polling to determine if the starting system change number is in the archive logs. If log.mining.archive.log.only.mode is not enabled, this setting is not used. log.mining.transaction.retention.ms 0 Positive integer value that specifies the number of milliseconds to retain long running transactions between redo log switches. When set to 0 , transactions are retained until a commit or rollback is detected. By default, the LogMiner adapter maintains an in-memory buffer of all running transactions. Because all of the DML operations that are part of a transaction are buffered until a commit or rollback is detected, long-running transactions should be avoided in order to not overflow that buffer. Any transaction that exceeds this configured value is discarded entirely, and the connector does not emit any messages for the operations that were part of the transaction. log.mining.archive.destination.name No default Specifies the configured Oracle archive destination to use when mining archive logs with LogMiner. The default behavior automatically selects the first valid, local configured destination. However, you can use a specific destination can be used by providing the destination name, for example, LOG_ARCHIVE_DEST_5 . log.mining.username.include.list No default List of database users to include from the LogMiner query. It can be useful to set this property if you want the capturing process to include changes from the specified users. log.mining.username.exclude.list No default List of database users to exclude from the LogMiner query. It can be useful to set this property if you want the capturing process to always exclude the changes that specific users make. log.mining.scn.gap.detection.gap.size.min 1000000 Specifies a value that the connector compares to the difference between the current and SCN values to determine whether an SCN gap exists. If the difference between the SCN values is greater than the specified value, and the time difference is smaller than log.mining.scn.gap.detection.time.interval.max.ms then an SCN gap is detected, and the connector uses a mining window larger than the configured maximum batch. log.mining.scn.gap.detection.time.interval.max.ms 20000 Specifies a value, in milliseconds, that the connector compares to the difference between the current and SCN timestamps to determine whether an SCN gap exists. If the difference between the timestamps is less than the specified value, and the SCN delta is greater than log.mining.scn.gap.detection.gap.size.min , then an SCN gap is detected and the connector uses a mining window larger than the configured maximum batch. log.mining.flush.table.name LOG_MINING_FLUSH Specifies the name of the flush table that coordinates flushing the Oracle LogWriter Buffer (LGWR) to the redo logs. This name can be specified using the format <schemaName> . <tableName> or <tableName> . Typically, multiple connectors can use the same flush table. However, if connectors encounter table lock contention errors, use this property to specify a dedicated table for each connector deployment. log.mining.include.redo.sql false Specifies whether the redo log constructed SQL statement is included in source.redo_sql field. lob.enabled false Controls whether or not large object (CLOB or BLOB) column values are emitted in change events. By default, change events have large object columns, but the columns contain no values. There is a certain amount of overhead in processing and managing large object column types and payloads. To capture large object values and serialized them in change events, set this option to true . Note Use of large object data types is a Technology Preview feature. unavailable.value.placeholder __debezium_unavailable_value Specifies the constant that the connector provides to indicate that the original value is unchanged and not provided by the database. rac.nodes No default A comma-separated list of Oracle Real Application Clusters (RAC) node host names or addresses. This field is required to enable compatibility with an Oracle RAC deployment. Specify the list of RAC nodes by using one of the following methods: Specify a value for database.port , and use the specified port value for each address in the rac.nodes list. For example: database.port=1521 rac.nodes=192.168.1.100,192.168.1.101 Specify a value for database.port , and override the default port for one or more entries in the list. The list can include entries that use the default database.port value, and entries that define their own unique port values. For example: database.port=1521 rac.nodes=192.168.1.100,192.168.1.101:1522 If you supply a raw JDBC URL for the database by using the database.url property, instead of defining a value for database.port , each RAC node entry must explicitly specify a port value. skipped.operations t A comma-separated list of the operation types that you want the connector to skip during streaming. You can configure the connector to skip the following types of operations: c (insert/create) u (update) d (delete) t (truncate) By default, only truncate operations are skipped. signal.data.collection No default value Fully-qualified name of the data collection that is used to send signals to the connector. When you use this property with an Oracle pluggable database (PDB), set its value to the name of the root database. Use the following format to specify the collection name: <databaseName> . <schemaName> . <tableName> signal.enabled.channels source List of the signaling channel names that are enabled for the connector. By default, the following channels are available: source kafka file jmx notification.enabled.channels No default List of notification channel names that are enabled for the connector. By default, the following channels are available: sink log jmx incremental.snapshot.chunk.size 1024 The maximum number of rows that the connector fetches and reads into memory during an incremental snapshot chunk. Increasing the chunk size provides greater efficiency, because the snapshot runs fewer snapshot queries of a greater size. However, larger chunk sizes also require more memory to buffer the snapshot data. Adjust the chunk size to a value that provides the best performance in your environment. incremental.snapshot.watermarking.strategy insert_insert Specifies the watermarking mechanism that the connector uses during an incremental snapshot to deduplicate events that might be captured by an incremental snapshot and then recaptured after streaming resumes. You can specify one of the following options: insert_insert When you send a signal to initiate an incremental snapshot, for every chunk that Debezium reads during the snapshot, it writes an entry to the signaling data collection to record the signal to open the snapshot window. After the snapshot completes, Debezium inserts a second entry that records the signal to close the window. insert_delete When you send a signal to initiate an incremental snapshot, for every chunk that Debezium reads, it writes a single entry to the signaling data collection to record the signal to open the snapshot window. After the snapshot completes, this entry is removed. No entry is created for the signal to close the snapshot window. Set this option to prevent rapid growth of the signaling data collection. topic.naming.strategy io.debezium.schema.SchemaTopicNamingStrategy The name of the TopicNamingStrategy class that should be used to determine the topic name for data change, schema change, transaction, heartbeat event etc., defaults to SchemaTopicNamingStrategy . topic.delimiter . Specify the delimiter for topic name, defaults to . . topic.cache.size 10000 The size used for holding the topic names in bounded concurrent hash map. This cache will help to determine the topic name corresponding to a given data collection. topic.heartbeat.prefix __debezium-heartbeat Controls the name of the topic to which the connector sends heartbeat messages. The topic name has this pattern: topic.heartbeat.prefix . topic.prefix For example, if the topic prefix is fulfillment , the default topic name is __debezium-heartbeat.fulfillment . topic.transaction transaction Controls the name of the topic to which the connector sends transaction metadata messages. The topic name has this pattern: topic.prefix . topic.transaction For example, if the topic prefix is fulfillment , the default topic name is fulfillment.transaction . snapshot.max.threads 1 Specifies the number of threads that the connector uses when performing an initial snapshot. To enable parallel initial snapshots, set the property to a value greater than 1. In a parallel initial snapshot, the connector processes multiple tables concurrently. Important Parallel initial snapshots is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope . <oracle-property-snapshot-database-errors-max-retries, snapshot.database.errors.max.retries >> 0 Specifies the number of retry attempts to snapshot a table when a database error occurs. This configuration property currently only retries failures related to ORA-01466 exceptions. By default, no additional retries will be performed. custom.metric.tags No default Defines tags that customize MBean object names by adding metadata that provides contextual information. Specify a comma-separated list of key-value pairs. Each key represents a tag for the MBean object name, and the corresponding value represents a value for the key, for example, k1=v1,k2=v2 The connector appends the specified tags to the base MBean object name. Tags can help you to organize and categorize metrics data. You can define tags to identify particular application instances, environments, regions, versions, and so forth. For more information, see Customized MBean names . errors.max.retries -1 Specifies how the connector responds after an operation that results in a retriable error, such as a connection error. Set one of the following options: -1 No limit. The connector always restarts automatically, and retries the operation, regardless of the number of failures. 0 Disabled. The connector fails immediately, and never retries the operation. User intervention is required to restart the connector. > 0 The connector restarts automatically until it reaches the specified maximum number of retries. After the failure, the connector stops, and user intervention is required to restart it. database.query.timeout.ms 600000 Time to wait for a query to execute, given in milliseconds. Defaults to 600 seconds (600,000 ms); zero means there is no limit. Debezium Oracle connector database schema history configuration properties Debezium provides a set of schema.history.internal.* properties that control how the connector interacts with the schema history topic. The following table describes the schema.history.internal properties for configuring the Debezium connector. Table 2.123. Connector database schema history configuration properties Property Default Description schema.history.internal.kafka.topic No default The full name of the Kafka topic where the connector stores the database schema history. schema.history.internal.kafka.bootstrap.servers No default A list of host/port pairs that the connector uses for establishing an initial connection to the Kafka cluster. This connection is used for retrieving the database schema history previously stored by the connector, and for writing each DDL statement read from the source database. Each pair should point to the same Kafka cluster used by the Kafka Connect process. schema.history.internal.kafka.recovery.poll.interval.ms 100 An integer value that specifies the maximum number of milliseconds the connector should wait during startup/recovery while polling for persisted data. The default is 100ms. schema.history.internal.kafka.query.timeout.ms 3000 An integer value that specifies the maximum number of milliseconds the connector should wait while fetching cluster information using Kafka admin client. schema.history.internal.kafka.create.timeout.ms 30000 An integer value that specifies the maximum number of milliseconds the connector should wait while create kafka history topic using Kafka admin client. schema.history.internal.kafka.recovery.attempts 100 The maximum number of times that the connector should try to read persisted history data before the connector recovery fails with an error. The maximum amount of time to wait after receiving no data is recovery.attempts x recovery.poll.interval.ms . schema.history.internal.skip.unparseable.ddl false A Boolean value that specifies whether the connector should ignore malformed or unknown database statements or stop processing so a human can fix the issue. The safe default is false . Skipping should be used only with care as it can lead to data loss or mangling when the binlog is being processed. schema.history.internal.store.only.captured.tables.ddl false A Boolean value that specifies whether the connector records schema structures from all tables in a schema or database, or only from tables that are designated for capture. Specify one of the following values: false (default) During a database snapshot, the connector records the schema data for all non-system tables in the database, including tables that are not designated for capture. It's best to retain the default setting. If you later decide to capture changes from tables that you did not originally designate for capture, the connector can easily begin to capture data from those tables, because their schema structure is already stored in the schema history topic. Debezium requires the schema history of a table so that it can identify the structure that was present at the time that a change event occurred. true During a database snapshot, the connector records the table schemas only for the tables from which Debezium captures change events. If you change the default value, and you later configure the connector to capture data from other tables in the database, the connector lacks the schema information that it requires to capture change events from the tables. schema.history.internal.store.only.captured.databases.ddl false A Boolean value that specifies whether the connector records schema structures from all logical databases in the database instance. Specify one of the following values: true The connector records schema structures only for tables in the logical database and schema from which Debezium captures change events. false The connector records schema structures for all logical databases. Pass-through Oracle connector configuration properties The connector supports pass-through properties that enable Debezium to specify custom configuration options for fine-tuning the behavior of the Apache Kafka producer and consumer. For information about the full range of configuration properties for Kafka producers and consumers, see the Kafka documentation . Pass-through properties for configuring how producer and consumer clients interact with schema history topics Debezium relies on an Apache Kafka producer to write schema changes to database schema history topics. Similarly, it relies on a Kafka consumer to read from database schema history topics when a connector starts. You define the configuration for the Kafka producer and consumer clients by assigning values to a set of pass-through configuration properties that begin with the schema.history.internal.producer.* and schema.history.internal.consumer.* prefixes. The pass-through producer and consumer database schema history properties control a range of behaviors, such as how these clients secure connections with the Kafka broker, as shown in the following example: Debezium strips the prefix from the property name before it passes the property to the Kafka client. For more information about Kafka producer configuration properties and Kafka consumer configuration properties , see the Apache Kafka documentation . Pass-through properties for configuring how the Oracle connector interacts with the Kafka signaling topic Debezium provides a set of signal.* properties that control how the connector interacts with the Kafka signals topic. The following table describes the Kafka signal properties. Table 2.124. Kafka signals configuration properties Property Default Description signal.kafka.topic <topic.prefix>-signal The name of the Kafka topic that the connector monitors for ad hoc signals. Note If automatic topic creation is disabled, you must manually create the required signaling topic. A signaling topic is required to preserve signal ordering. The signaling topic must have a single partition. signal.kafka.groupId kafka-signal The name of the group ID that is used by Kafka consumers. signal.kafka.bootstrap.servers No default A list of the host and port pairs that the connector uses to establish its initial connection to the Kafka cluster. Each pair references the Kafka cluster that is used by the Debezium Kafka Connect process. signal.kafka.poll.timeout.ms 100 An integer value that specifies the maximum number of milliseconds that the connector waits when polling signals. kafka.consumer.offset.commit.enabled false Specifies whether the Kafka consumer writes an offset commit after it reads a message from the signaling topic. The value that you assign to this property determines whether the connector can process requests that the signaling topic receives while the connector is offline. Choose one of the following settings: false When the connector is unavailable, the Kafka consumer does not commit an offset after it reads a signal received by the signaling topic. As a result, if the connector is offline for any interval, it cannot process requests that the signaling topic receives during the downtime. After the connector restarts, it always reads from the last position in the Kafka signaling topic, processing only signals that it receives after the restart. Signals received while the connector is offline are ignored, and are effectively lost. true When a user submits a request to the signaling topic, after the Kafka consumer reads the signal message it commits a topic offset, even if the connector is offline. Choose this option to provide Debezium with information about the last signal message that the consumer read, helping to ensure At-Least-Once delivery. After a connector restarts, it resumes processing from the last recorded offset, responding to signals that users submitted while the connector is offline. Pass-through properties for configuring the Kafka consumer client for the signaling channel The Debezium connector provides for pass-through configuration of the signals Kafka consumer. Pass-through signals properties begin with the prefix signals.consumer.* . For example, the connector passes properties such as signal.consumer.security.protocol=SSL to the Kafka consumer. Debezium strips the prefixes from the properties before it passes the properties to the Kafka signals consumer. Pass-through properties for configuring the Oracle connector sink notification channel The following table describes properties that you can use to configure the Debezium sink notification channel. Table 2.125. Sink notification configuration properties Property Default Description notification.sink.topic.name No default The name of the topic that receives notifications from Debezium. This property is required when you configure the notification.enabled.channels property to include sink as one of the enabled notification channels. Debezium connector pass-through database driver configuration properties The Debezium connector provides for pass-through configuration of the database driver. Pass-through database properties begin with the prefix driver.* . For example, the connector passes properties such as driver.foobar=false to the JDBC URL. Debezium strips the prefixes from the properties before it passes the properties to the database driver. 2.5.7. Monitoring Debezium Oracle connector performance The Debezium Oracle connector provides three metric types in addition to the built-in support for JMX metrics that Apache Zookeeper, Apache Kafka, and Kafka Connect have. snapshot metrics ; for monitoring the connector when performing snapshots streaming metrics ; for monitoring the connector when processing change events schema history metrics ; for monitoring the status of the connector's schema history Please refer to the monitoring documentation for details of how to expose these metrics via JMX. 2.5.7.1. Customized names for Oracle connector snapshot and streaming MBean objects Debezium connectors expose metrics via the MBean name for the connector. These metrics, which are specific to each connector instance, provide data about the behavior of the connector's snapshot, streaming, and schema history processes. By default, when you deploy a correctly configured connector, Debezium generates a unique MBean name for each of the different connector metrics. To view the metrics for a connector process, you configure your observability stack to monitor its MBean. But these default MBean names depend on the connector configuration; configuration changes can result in changes to the MBean names. A change to the MBean name breaks the linkage between the connector instance and the MBean, disrupting monitoring activity. In this scenario, you must reconfigure the observability stack to use the new MBean name if you want to resume monitoring. To prevent monitoring disruptions that result from MBean name changes, you can configure custom metrics tags. You configure custom metrics by adding the custom.metric.tags property to the connector configuration. The property accepts key-value pairs in which each key represents a tag for the MBean object name, and the corresponding value represents the value of that tag. For example: k1=v1,k2=v2 . Debezium appends the specified tags to the MBean name of the connector. After you configure the custom.metric.tags property for a connector, you can configure the observability stack to retrieve metrics associated with the specified tags. The observability stack then uses the specified tags, rather than the mutable MBean names to uniquely identify connectors. Later, if Debezium redefines how it constructs MBean names, or if the topic.prefix in the connector configuration changes, metrics collection is uninterrupted, because the metrics scrape task uses the specified tag patterns to identify the connector. A further benefit of using custom tags, is that you can use tags that reflect the architecture of your data pipeline, so that metrics are organized in a way that suits you operational needs. For example, you might specify tags with values that declare the type of connector activity, the application context, or the data source, for example, db1-streaming-for-application-abc . If you specify multiple key-value pairs, all of the specified pairs are appended to the connector's MBean name. The following example illustrates how tags modify the default MBean name. Example 2.39. How custom tags modify the connector MBean name By default, the Oracle connector uses the following MBean name for streaming metrics: If you set the value of custom.metric.tags to database=salesdb-streaming,table=inventory , Debezium generates the following custom MBean name: 2.5.7.2. Debezium Oracle connector snapshot metrics The MBean is debezium.oracle:type=connector-metrics,context=snapshot,server= <topic.prefix> . Snapshot metrics are not exposed unless a snapshot operation is active, or if a snapshot has occurred since the last connector start. The following table lists the snapshot metrics that are available. Attributes Type Description LastEvent string The last snapshot event that the connector has read. MilliSecondsSinceLastEvent long The number of milliseconds since the connector has read and processed the most recent event. TotalNumberOfEventsSeen long The total number of events that this connector has seen since last started or reset. NumberOfEventsFiltered long The number of events that have been filtered by include/exclude list filtering rules configured on the connector. CapturedTables string[] The list of tables that are captured by the connector. QueueTotalCapacity int The length the queue used to pass events between the snapshotter and the main Kafka Connect loop. QueueRemainingCapacity int The free capacity of the queue used to pass events between the snapshotter and the main Kafka Connect loop. TotalTableCount int The total number of tables that are being included in the snapshot. RemainingTableCount int The number of tables that the snapshot has yet to copy. SnapshotRunning boolean Whether the snapshot was started. SnapshotPaused boolean Whether the snapshot was paused. SnapshotAborted boolean Whether the snapshot was aborted. SnapshotCompleted boolean Whether the snapshot completed. SnapshotDurationInSeconds long The total number of seconds that the snapshot has taken so far, even if not complete. Includes also time when snapshot was paused. SnapshotPausedDurationInSeconds long The total number of seconds that the snapshot was paused. If the snapshot was paused several times, the paused time adds up. RowsScanned Map<String, Long> Map containing the number of rows scanned for each table in the snapshot. Tables are incrementally added to the Map during processing. Updates every 10,000 rows scanned and upon completing a table. MaxQueueSizeInBytes long The maximum buffer of the queue in bytes. This metric is available if max.queue.size.in.bytes is set to a positive long value. CurrentQueueSizeInBytes long The current volume, in bytes, of records in the queue. The connector also provides the following additional snapshot metrics when an incremental snapshot is executed: Attributes Type Description ChunkId string The identifier of the current snapshot chunk. ChunkFrom string The lower bound of the primary key set defining the current chunk. ChunkTo string The upper bound of the primary key set defining the current chunk. TableFrom string The lower bound of the primary key set of the currently snapshotted table. TableTo string The upper bound of the primary key set of the currently snapshotted table. 2.5.7.3. Debezium Oracle connector streaming metrics The MBean is debezium.oracle:type=connector-metrics,context=streaming,server= <topic.prefix> . The following table lists the streaming metrics that are available. Attributes Type Description LastEvent string The last streaming event that the connector has read. MilliSecondsSinceLastEvent long The number of milliseconds since the connector has read and processed the most recent event. TotalNumberOfEventsSeen long The total number of data change events reported by the source database since the last connector start, or since a metrics reset. Represents the data change workload for Debezium to process. TotalNumberOfCreateEventsSeen long The total number of create events processed by the connector since its last start or metrics reset. TotalNumberOfUpdateEventsSeen long The total number of update events processed by the connector since its last start or metrics reset. TotalNumberOfDeleteEventsSeen long The total number of delete events processed by the connector since its last start or metrics reset. NumberOfEventsFiltered long The number of events that have been filtered by include/exclude list filtering rules configured on the connector. CapturedTables string[] The list of tables that are captured by the connector. QueueTotalCapacity int The length the queue used to pass events between the streamer and the main Kafka Connect loop. QueueRemainingCapacity int The free capacity of the queue used to pass events between the streamer and the main Kafka Connect loop. Connected boolean Flag that denotes whether the connector is currently connected to the database server. MilliSecondsBehindSource long The number of milliseconds between the last change event's timestamp and the connector processing it. The values will incorporate any differences between the clocks on the machines where the database server and the connector are running. NumberOfCommittedTransactions long The number of processed transactions that were committed. SourceEventPosition Map<String, String> The coordinates of the last received event. LastTransactionId string Transaction identifier of the last processed transaction. MaxQueueSizeInBytes long The maximum buffer of the queue in bytes. This metric is available if max.queue.size.in.bytes is set to a positive long value. CurrentQueueSizeInBytes long The current volume, in bytes, of records in the queue. The Debezium Oracle connector also provides the following additional streaming metrics: Table 2.126. Descriptions of additional streaming metrics Attributes Type Description CurrentScn BigInteger The most recent system change number that has been processed. OldestScn BigInteger The oldest system change number in the transaction buffer. OldestScnAgeInMilliseconds long The oldest system change number's age in milliseconds. If the buffer is empty, the value will be 0 . CommittedScn BigInteger The last committed system change number from the transaction buffer. OffsetScn BigInteger The system change number currently written to the connector's offsets. CurrentRedoLogFileName string[] Array of the log files that are currently mined. MinimumMinedLogCount long The minimum number of logs specified for any LogMiner session. MaximumMinedLogCount long The maximum number of logs specified for any LogMiner session. RedoLogStatus string[] Array of the current state for each mined logfile with the format filename | status . SwitchCounter int The number of times the database has performed a log switch for the last day. LastCapturedDmlCount long The number of DML operations observed in the last LogMiner session query. MaxCapturedDmlInBatch long The maximum number of DML operations observed while processing a single LogMiner session query. TotalCapturedDmlCount long The total number of DML operations observed. FetchingQueryCount long The total number of LogMiner session query (aka batches) performed. LastDurationOfFetchQueryInMilliseconds long The duration of the last LogMiner session query's fetch in milliseconds. MaxDurationOfFetchQueryInMilliseconds long The maximum duration of any LogMiner session query's fetch in milliseconds. LastBatchProcessingTimeInMilliseconds long The duration for processing the last LogMiner query batch results in milliseconds. TotalParseTimeInMilliseconds long The time in milliseconds spent parsing DML event SQL statements. LastMiningSessionStartTimeInMilliseconds long The duration in milliseconds to start the last LogMiner session. MaxMiningSessionStartTimeInMilliseconds long The longest duration in milliseconds to start a LogMiner session. TotalMiningSessionStartTimeInMilliseconds long The total duration in milliseconds spent by the connector starting LogMiner sessions. MinBatchProcessingTimeInMilliseconds long The minimum duration in milliseconds spent processing results from a single LogMiner session. MaxBatchProcessingTimeInMilliseconds long The maximum duration in milliseconds spent processing results from a single LogMiner session. TotalProcessingTimeInMilliseconds long The total duration in milliseconds spent processing results from LogMiner sessions. TotalResultSetNextTimeInMilliseconds long The total duration in milliseconds spent by the JDBC driver fetching the row to be processed from the log mining view. TotalProcessedRows long The total number of rows processed from the log mining view across all sessions. BatchSize int The number of entries fetched by the log mining query per database round-trip. MillisecondToSleepBetweenMiningQuery long The number of milliseconds the connector sleeps before fetching another batch of results from the log mining view. MaxBatchProcessingThroughput long The maximum number of rows/second processed from the log mining view. AverageBatchProcessingThroughput long The average number of rows/second processed from the log mining. LastBatchProcessingThroughput long The average number of rows/second processed from the log mining view for the last batch. NetworkConnectionProblemsCounter long The number of connection problems detected. HoursToKeepTransactionInBuffer int The number of hours that transactions are retained by the connector's in-memory buffer without being committed or rolled back before being discarded. For more information, see log.mining.transaction.retention.ms . NumberOfActiveTransactions long The number of current active transactions in the transaction buffer. NumberOfCommittedTransactions long The number of committed transactions in the transaction buffer. NumberOfRolledBackTransactions long The number of rolled back transactions in the transaction buffer. CommitThroughput long The average number of committed transactions per second in the transaction buffer. RegisteredDmlCount long The number of registered DML operations in the transaction buffer. LagFromSourceInMilliseconds long The time difference in milliseconds between when a change occurred in the transaction logs and when its added to the transaction buffer. MaxLagFromSourceInMilliseconds long The maximum time difference in milliseconds between when a change occurred in the transaction logs and when its added to the transaction buffer. MinLagFromSourceInMilliseconds long The minimum time difference in milliseconds between when a change occurred in the transaction logs and when its added to the transaction buffer. AbandonedTransactionIds string[] An array of the most recent abandoned transaction identifiers removed from the transaction buffer due to their age. See log.mining.transaction.retention.ms for details. AbandonedTransactionCount long Current number of entries in the abandoned transactions list. RolledBackTransactionIds string[] An array of the most recent transaction identifiers that have been mined and rolled back in the transaction buffer. LastCommitDurationInMilliseconds long The duration of the last transaction buffer commit operation in milliseconds. MaxCommitDurationInMilliseconds long The duration of the longest transaction buffer commit operation in milliseconds. ErrorCount int The number of errors detected. WarningCount int The number of warnings detected. ScnFreezeCount int The number of times that the system change number was checked for advancement and remains unchanged. A high value can indicate that a long-running transactions is ongoing and is preventing the connector from flushing the most recently processed system change number to the connector's offsets. When conditions are optimal, the value should be close to or equal to 0 . UnparsableDdlCount int The number of DDL records that have been detected but could not be parsed by the DDL parser. This should always be 0 ; however when allowing unparsable DDL to be skipped, this metric can be used to determine if any warnings have been written to the connector logs. MiningSessionUserGlobalAreaMemoryInBytes long The current mining session's user global area (UGA) memory consumption in bytes. MiningSessionUserGlobalAreaMaxMemoryInBytes long The maximum mining session's user global area (UGA) memory consumption in bytes across all mining sessions. MiningSessionProcessGlobalAreaMemoryInBytes long The current mining session's process global area (PGA) memory consumption in bytes. MiningSessionProcessGlobalAreaMaxMemoryInBytes long The maximum mining session's process global area (PGA) memory consumption in bytes across all mining sessions. 2.5.7.4. Debezium Oracle connector schema history metrics The MBean is debezium.oracle:type=connector-metrics,context=schema-history,server= <topic.prefix> . The following table lists the schema history metrics that are available. Attributes Type Description Status string One of STOPPED , RECOVERING (recovering history from the storage), RUNNING describing the state of the database schema history. RecoveryStartTime long The time in epoch seconds at what recovery has started. ChangesRecovered long The number of changes that were read during recovery phase. ChangesApplied long the total number of schema changes applied during recovery and runtime. MilliSecondsSinceLast RecoveredChange long The number of milliseconds that elapsed since the last change was recovered from the history store. MilliSecondsSinceLast AppliedChange long The number of milliseconds that elapsed since the last change was applied. LastRecoveredChange string The string representation of the last change recovered from the history store. LastAppliedChange string The string representation of the last applied change. 2.5.8. Oracle connector frequently asked questions Is Oracle 11g supported? Oracle 11g is not supported; however, we do aim to be backward compatible with Oracle 11g on a best-effort basis. We rely on the community to communicate compatibility concerns with Oracle 11g as well as provide bug fixes when a regression is identified. Isn't Oracle LogMiner deprecated? No, Oracle only deprecated the continuous mining option with Oracle LogMiner in Oracle 12c and removed that option starting with Oracle 19c. The Debezium Oracle connector does not rely on this option to function, and therefore can safely be used with newer versions of Oracle without any impact. How do I change the position in the offsets? The Debezium Oracle connector maintains two critical values in the offsets, a field named scn and another named commit_scn . The scn field is a string that represents the low-watermark starting position the connector used when capturing changes. Find out the name of the topic that contains the connector offsets. This is configured based on the value set as the offset.storage.topic configuration property. Find out the last offset for the connector, the key under which it is stored and identify the partition used to store the offset. This can be done using the kafkacat utility script provided by the Kafka broker installation. An example might look like this: kafkacat -b localhost -C -t my_connect_offsets -f 'Partition(%p) %k %s\n' Partition(11) ["inventory-connector",{"server":"server1"}] {"scn":"324567897", "commit_scn":"324567897: 0x2832343233323:1"} The key for inventory-connector is ["inventory-connector",{"server":"server1"}] , the partition is 11 and the last offset is the contents that follows the key. To move back to a offset the connector should be stopped and the following command has to be issued: echo '["inventory-connector",{"server":"server1"}]|{"scn":"3245675000","commit_scn":"324567500"}' | \ kafkacat -P -b localhost -t my_connect_offsets -K \| -p 11 This writes to partition 11 of the my_connect_offsets topic the given key and offset value. In this example, we are reversing the connector back to SCN 3245675000 rather than 324567897 . What happens if the connector cannot find logs with a given offset SCN? The Debezium connector maintains a low and high -watermark SCN value in the connector offsets. The low-watermark SCN represents the starting position and must exist in the available online redo or archive logs in order for the connector to start successfully. When the connector reports it cannot find this offset SCN, this indicates that the logs that are still available do not contain the SCN and therefore the connector cannot mine changes from where it left off. When this happens, there are two options. The first is to remove the history topic and offsets for the connector and restart the connector, taking a new snapshot as suggested. This will guarantee that no data loss will occur for any topic consumers. The second is to manually manipulate the offsets, advancing the SCN to a position that is available in the redo or archive logs. This will cause changes that occurred between the old SCN value and the newly provided SCN value to be lost and not written to the topics. This is not recommended. What's the difference between the various mining strategies? The Debezium Oracle connector provides three options for log.mining.strategy . The default is redo_in_catalog , and this instructs the connector to write the Oracle data dictionary to the redo logs everytime a log switch is detected. This data dictionary is necessary for Oracle LogMiner to track schema changes effectively when parsing the redo and archive logs. This option will generate more than usual numbers of archive logs but allows tables being captured to be manipulated in real-time without any impact on capturing data changes. This option generally requires more Oracle database memory and will cause the Oracle LogMiner session and process to take slightly longer to start after each log switch. The second option, online_catalog , does not write the data dictionary to the redo logs. Instead, Oracle LogMiner will always use the online data dictionary that contains the current state of the table's structure. This also means that if a table's structure changes and no longer matches the online data dictionary, Oracle LogMiner will be unable to resolve table or column names if the table's structure is changed. This mining strategy option should not be used if the tables being captured are subject to frequent schema changes. It's important that all data changes be lock-stepped with the schema change such that all changes have been captured from the logs for the table, stop the connector, apply the schema change, and restart the connector and resume data changes on the table. This option requires less Oracle database memory and Oracle LogMiner sessions generally start substantially faster since the data dictionary does not need to be loaded or primed by the LogMiner process. The final option, hybrid , combines the strengths of the above two strategies with none of their weaknesses. This strategy harnesses the performance of the online_catalog with the resilience in schema tracking of the redo_in_catalog while also avoiding the overhead and performance costs with the higher than normal archive log generation. This mode utilizes a fallback mode where if LogMiner fails to reconstruct the SQL for a database change, the Debezium connector will rely on the in-memory schema model maintained by the connector to reconstruct the SQL in-flight. The intent is that this mode will eventually transition to the default, and likely only mode of operation in the future. Are there any limitations with the Hybrid mining strategy with LogMiner? Yes, the Hybrid mode for log.mining.strategy is still a work-in-progress strategy, and therefore does not yet support all data types. At this time, this mode cannot reconstruct SQL statements that include operations against CLOB , NCLOB , BLOB , XML , nor JSON data types. So in short, if you enable lob.enabled with a value of true , you will be unable to use the Hybrid strategy and the connector will fail to start as this combination is unsupported. Why does the connector appear to stop capturing changes on AWS? Due to the fixed idle timeout of 350 seconds on the AWS Gateway Load Balancer , JDBC calls that require more than 350 seconds to complete can hang indefinitely. In situations where calls to the Oracle LogMiner API take more than 350 seconds to complete, a timeout can be triggered, causing the AWS Gateway Load Balancer to hang. For example, such timeouts can occur when a LogMiner session that processes large amounts of data runs concurrently with Oracle's periodic checkpointing task. To prevent timeouts from occurring on the AWS Gateway Load Balancer, enable keep-alive packets from the Kafka Connect environment, by performing the following steps as root or a super-user: From a terminal, run the following command: sysctl -w net.ipv4.tcp_keepalive_time=60 Edit /etc/sysctl.conf and set the value of the following variable as shown: net.ipv4.tcp_keepalive_time=60 Reconfigure the Debezium for Oracle connector to use the database.url property rather than database.hostname and add the (ENABLE=broken) Oracle connect string descriptor as shown in the following example: database.url=jdbc:oracle:thin:username/password!@(DESCRIPTION=(ENABLE=broken)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(Host=hostname)(Port=port)))(CONNECT_DATA=(SERVICE_NAME=serviceName))) The preceding steps configure the TCP network stack to send keep-alive packets every 60 seconds. As a result, the AWS Gateway Load Balancer does not timeout when JDBC calls to the LogMiner API take more than 350 seconds to complete, enabling the connector to continue to read changes from the database's transaction logs. What's the cause for ORA-01555 and how to handle it? The Debezium Oracle connector uses flashback queries when the initial snapshot phase executes. A flashback query is a special type of query that relies on the flashback area, maintained by the database's UNDO_RETENTION database parameter, to return the results of a query based on what the contents of the table had at a given time, or in our case at a given SCN. By default, Oracle generally only maintains an undo or flashback area for approximately 15 minutes unless this has been increased or decreased by your database administrator. For configurations that capture large tables, it may take longer than 15 minutes or your configured UNDO_RETENTION to perform the initial snapshot and this will eventually lead to this exception: The first way to deal with this exception is to work with your database administrator and see whether they can increase the UNDO_RETENTION database parameter temporarily. This does not require a restart of the Oracle database, so this can be done online without impacting database availability. However, changing this may still lead to the above exception or a "snapshot too old" exception if the tablespace has inadequate space to store the necessary undo data. The second way to deal with this exception is to not rely on the initial snapshot at all, setting the snapshot.mode to schema_only and then instead relying on incremental snapshots. An incremental snapshot does not rely on a flashback query and therefore isn't subject to ORA-01555 exceptions. What's the cause for ORA-04036 and how to handle it? The Debezium Oracle connector may report an ORA-04036 exception when the database changes occur infrequently. An Oracle LogMiner session is started and re-used until a log switch is detected. The session is re-used as it provides the optimal performance utilization with Oracle LogMiner, but should a long-running mining session occur, this can lead to excessive PGA memory usage, eventually causing an exception like this: This exception can be avoided by specifying how frequent Oracle switches redo logs or how long the Debezium Oracle connector is allowed to re-use the mining session. The Debezium Oracle connector provides a configuration option, log.mining.session.max.ms , which controls how long the current Oracle LogMiner session can be re-used for before being closed and a new session started. This allows the database resources to be kept in-check without exceeding the PGA memory allowed by the database. What's the cause for ORA-01882 and how to handle it? The Debezium Oracle connector may report the following exception when connecting to an Oracle database: This happens when the timezone information cannot be correctly resolved by the JDBC driver. In order to solve this driver related problem, the driver needs to be told to not resolve the timezone details using regions. This can be done by specifying a driver pass through property using driver.oracle.jdbc.timezoneAsRegion=false . What's the cause for ORA-25191 and how to handle it? The Debezium Oracle connector automatically ignores index-organized tables (IOT) as they are not supported by Oracle LogMiner. However, if an ORA-25191 exception is thrown, this could be due to a unique corner case for such a mapping and the additional rules may be necessary to exclude these automatically. An example of an ORA-25191 exception might look like this: If an ORA-25191 exception is thrown, please raise a Jira issue with the details about the table and it's mappings, related to other parent tables, etc. As a workaround, the include/exclude configuration options can be adjusted to prevent the connector from accessing such tables. How to solve SAX feature external-general-entities not supported Debezium 2.4 introduced support for Oracle's XMLTYPE column type and to support this feature, the Oracle xdb and xmlparserv2 dependencies are required. Oracle's xmlparserv2 dependency implements a SAX-based parser and if the runtime finds an uses this implementation rather than the other on the classpath, this error will occur. In order to influence specifically which SAX implementation is used generally, the JVM will need to be started with a specific argument. When the following JVM argument is provided, the Oracle connector will start successfully without this error. -Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl 2.6. Debezium connector for PostgreSQL The Debezium PostgreSQL connector captures row-level changes in the schemas of a PostgreSQL database. For information about the PostgreSQL versions that are compatible with the connector, see the Debezium Supported Configurations page . The first time it connects to a PostgreSQL server or cluster, the connector takes a consistent snapshot of all schemas. After that snapshot is complete, the connector continuously captures row-level changes that insert, update, and delete database content and that were committed to a PostgreSQL database. The connector generates data change event records and streams them to Kafka topics. For each table, the default behavior is that the connector streams all generated events to a separate Kafka topic for that table. Applications and services consume data change event records from that topic. Information and procedures for using a Debezium PostgreSQL connector is organized as follows: Section 2.6.1, "Overview of Debezium PostgreSQL connector" Section 2.6.2, "How Debezium PostgreSQL connectors work" Section 2.6.3, "Descriptions of Debezium PostgreSQL connector data change events" Section 2.6.4, "How Debezium PostgreSQL connectors map data types" Section 2.6.5, "Setting up PostgreSQL to run a Debezium connector" Custom converters Section 2.6.6, "Deployment of Debezium PostgreSQL connectors" Section 2.6.7, "Monitoring Debezium PostgreSQL connector performance" Section 2.6.8, "How Debezium PostgreSQL connectors handle faults and problems" 2.6.1. Overview of Debezium PostgreSQL connector PostgreSQL's logical decoding feature was introduced in version 9.4. It is a mechanism that allows the extraction of the changes that were committed to the transaction log and the processing of these changes in a user-friendly manner with the help of an output plug-in . The output plug-in enables clients to consume the changes. The PostgreSQL connector contains two main parts that work together to read and process database changes: pgoutput is the standard logical decoding output plug-in in PostgreSQL 10+. This is the only supported logical decoding output plug-in in this Debezium release. This plug-in is maintained by the PostgreSQL community, and used by PostgreSQL itself for logical replication . This plug-in is always present so no additional libraries need to be installed. The Debezium connector interprets the raw replication event stream directly into change events. Java code (the actual Kafka Connect connector) that reads the changes produced by the logical decoding output plug-in by using PostgreSQL's streaming replication protocol and the PostgreSQL JDBC driver . The connector produces a change event for every row-level insert, update, and delete operation that was captured and sends change event records for each table in a separate Kafka topic. Client applications read the Kafka topics that correspond to the database tables of interest, and can react to every row-level event they receive from those topics. PostgreSQL normally purges write-ahead log (WAL) segments after some period of time. This means that the connector does not have the complete history of all changes that have been made to the database. Therefore, when the PostgreSQL connector first connects to a particular PostgreSQL database, it starts by performing a consistent snapshot of each of the database schemas. After the connector completes the snapshot, it continues streaming changes from the exact point at which the snapshot was made. This way, the connector starts with a consistent view of all of the data, and does not omit any changes that were made while the snapshot was being taken. The connector is tolerant of failures. As the connector reads changes and produces events, it records the WAL position for each event. If the connector stops for any reason (including communication failures, network problems, or crashes), upon restart the connector continues reading the WAL where it last left off. This includes snapshots. If the connector stops during a snapshot, the connector begins a new snapshot when it restarts. Important The connector relies on and reflects the PostgreSQL logical decoding feature, which has the following limitations: Logical decoding does not support DDL changes. This means that the connector is unable to report DDL change events back to consumers. Logical decoding replication slots are supported on only primary servers. When there is a cluster of PostgreSQL servers, the connector can run on only the active primary server. It cannot run on hot or warm standby replicas. If the primary server fails or is demoted, the connector stops. After the primary server has recovered, you can restart the connector. If a different PostgreSQL server has been promoted to primary , adjust the connector configuration before restarting the connector. Because logical decoding replication slots publish changes during commit - and not post commit - undesirable side-effects can occur. There are two main scenarios when clients can observe inconsistent states. First, publishing uncommitted changes when the master dies before replication completes. Second, publishing changes that cannot be read (i.e., read-after-write consistency) temporarily because they are being replicated. For example, an EmbeddedEngine consumer receives a notification of a row that was created but it cannot be read by a transaction. Additionally, the pgoutput logical decoding output plug-in does not capture values for generated columns, resulting in missing data for these columns in the connector's output. Behavior when things go wrong describes how the connector responds if there is a problem. Important Debezium currently supports databases with UTF-8 character encoding only. With a single byte character encoding, it is not possible to correctly process strings that contain extended ASCII code characters. 2.6.2. How Debezium PostgreSQL connectors work To optimally configure and run a Debezium PostgreSQL connector, it is helpful to understand how the connector performs snapshots, streams change events, determines Kafka topic names, and uses metadata. Details are in the following topics: Section 2.6.2.2, "How Debezium PostgreSQL connectors perform database snapshots" Section 2.6.2.3, "Ad hoc snapshots" Section 2.6.2.4, "Incremental snapshots" Section 2.6.2.6, "How Debezium PostgreSQL connectors stream change event records" Section 2.6.2.7, "Default names of Kafka topics that receive Debezium PostgreSQL change event records" Section 2.6.2.8, "Debezium PostgreSQL connector-generated events that represent transaction boundaries" 2.6.2.1. Security for PostgreSQL connector To use the Debezium connector to stream changes from a PostgreSQL database, the connector must operate with specific privileges in the database. Although one way to grant the necessary privileges is to provide the user with superuser privileges, doing so potentially exposes your PostgreSQL data to unauthorized access. Rather than granting excessive privileges to the Debezium user, it is best to create a dedicated Debezium replication user to which you grant specific privileges. For more information about configuring privileges for the Debezium PostgreSQL user, see Setting up permissions . For more information about PostgreSQL logical replication security, see the PostgreSQL documentation . 2.6.2.2. How Debezium PostgreSQL connectors perform database snapshots Most PostgreSQL servers are configured to not retain the complete history of the database in the WAL segments. This means that the PostgreSQL connector would be unable to see the entire history of the database by reading only the WAL. Consequently, the first time that the connector starts, it performs an initial consistent snapshot of the database. You can find more information about snapshots in the following sections: Section 2.6.2.3, "Ad hoc snapshots" Section 2.6.2.4, "Incremental snapshots" Default workflow behavior of initial snapshots The default behavior for performing a snapshot consists of the following steps. You can change this behavior by setting the snapshot.mode connector configuration property to a value other than initial . Start a transaction with a SERIALIZABLE, READ ONLY, DEFERRABLE isolation level to ensure that subsequent reads in this transaction are against a single consistent version of the data. Any changes to the data due to subsequent INSERT , UPDATE , and DELETE operations by other clients are not visible to this transaction. Read the current position in the server's transaction log. Scan the database tables and schemas, generate a READ event for each row and write that event to the appropriate table-specific Kafka topic. Commit the transaction. Record the successful completion of the snapshot in the connector offsets. If the connector fails, is rebalanced, or stops after Step 1 begins but before Step 5 completes, upon restart the connector begins a new snapshot. After the connector completes its initial snapshot, the PostgreSQL connector continues streaming from the position that it read in Step 2. This ensures that the connector does not miss any updates. If the connector stops again for any reason, upon restart, the connector continues streaming changes from where it previously left off. Table 2.127. Options for the snapshot.mode connector configuration property Option Description always The connector always performs a snapshot when it starts. After the snapshot completes, the connector continues streaming changes from step 3 in the above sequence. This mode is useful in these situations: It is known that some WAL segments have been deleted and are no longer available. After a cluster failure, a new primary has been promoted. The always snapshot mode ensures that the connector does not miss any changes that were made after the new primary had been promoted but before the connector was restarted on the new primary. initial (default) The connector performs a database snapshot when no Kafka offsets topic exists. After the database snapshot completes the Kafka offsets topic is written. If there is a previously stored LSN in the Kafka offsets topic, the connector continues streaming changes from that position. initial_only The connector performs a database snapshot and stops before streaming any change event records. If the connector had started but did not complete a snapshot before stopping, the connector restarts the snapshot process and stops when the snapshot completes. no_data The connector never performs snapshots. When a connector is configured this way, after it starts, it behaves as follows: If there is a previously stored LSN in the Kafka offsets topic, the connector continues streaming changes from that position. If no LSN is stored, the connector starts streaming changes from the point at which the PostgreSQL logical replication slot was created on the server. Use this snapshot mode only when you know that all data of interest is still reflected in the WAL. never Deprecated, see no_data when_needed After the connector starts, it performs a snapshot only if it detects one of the following circumstances: It cannot detect any topic offsets. A previously recorded offset specifies a log position that is not available on the server. 2.6.2.3. Ad hoc snapshots By default, a connector runs an initial snapshot operation only after it starts for the first time. Following this initial snapshot, under normal circumstances, the connector does not repeat the snapshot process. Any future change event data that the connector captures comes in through the streaming process only. However, in some situations the data that the connector obtained during the initial snapshot might become stale, lost, or incomplete. To provide a mechanism for recapturing table data, Debezium includes an option to perform ad hoc snapshots. You might want to perform an ad hoc snapshot after any of the following changes occur in your Debezium environment: The connector configuration is modified to capture a different set of tables. Kafka topics are deleted and must be rebuilt. Data corruption occurs due to a configuration error or some other problem. You can re-run a snapshot for a table for which you previously captured a snapshot by initiating a so-called ad-hoc snapshot . Ad hoc snapshots require the use of signaling tables . You initiate an ad hoc snapshot by sending a signal request to the Debezium signaling table. When you initiate an ad hoc snapshot of an existing table, the connector appends content to the topic that already exists for the table. If a previously existing topic was removed, Debezium can create a topic automatically if automatic topic creation is enabled. Ad hoc snapshot signals specify the tables to include in the snapshot. The snapshot can capture the entire contents of the database, or capture only a subset of the tables in the database. Also, the snapshot can capture a subset of the contents of the table(s) in the database. You specify the tables to capture by sending an execute-snapshot message to the signaling table. Set the type of the execute-snapshot signal to incremental or blocking , and provide the names of the tables to include in the snapshot, as described in the following table: Table 2.128. Example of an ad hoc execute-snapshot signal record Field Default Value type incremental Specifies the type of snapshot that you want to run. Currently, you can request incremental or blocking snapshots. data-collections N/A An array that contains regular expressions matching the fully-qualified names of the tables to include in the snapshot. For the PostgreSQL connector, use the following format to specify the fully qualified name of a table: schema.table . additional-conditions N/A An optional array that specifies a set of additional conditions that the connector evaluates to determine the subset of records to include in a snapshot. Each additional condition is an object that specifies the criteria for filtering the data that an ad hoc snapshot captures. You can set the following parameters for each additional condition: data-collection The fully-qualified name of the table that the filter applies to. You can apply different filters to each table. filter Specifies column values that must be present in a database record for the snapshot to include it, for example, "color='blue'" . The values that you assign to the filter parameter are the same types of values that you might specify in the WHERE clause of SELECT statements when you set the snapshot.select.statement.overrides property for a blocking snapshot. surrogate-key N/A An optional string that specifies the column name that the connector uses as the primary key of a table during the snapshot process. Triggering an ad hoc incremental snapshot You initiate an ad hoc incremental snapshot by adding an entry with the execute-snapshot signal type to the signaling table, or by sending a signal message to a Kafka signaling topic . After the connector processes the message, it begins the snapshot operation. The snapshot process reads the first and last primary key values and uses those values as the start and end point for each table. Based on the number of entries in the table, and the configured chunk size, Debezium divides the table into chunks, and proceeds to snapshot each chunk, in succession, one at a time. For more information, see Incremental snapshots . Triggering an ad hoc blocking snapshot You initiate an ad hoc blocking snapshot by adding an entry with the execute-snapshot signal type to the signaling table or signaling topic. After the connector processes the message, it begins the snapshot operation. The connector temporarily stops streaming, and then initiates a snapshot of the specified table, following the same process that it uses during an initial snapshot. After the snapshot completes, the connector resumes streaming. For more information, see Blocking snapshots . 2.6.2.4. Incremental snapshots To provide flexibility in managing snapshots, Debezium includes a supplementary snapshot mechanism, known as incremental snapshotting . Incremental snapshots rely on the Debezium mechanism for sending signals to a Debezium connector . In an incremental snapshot, instead of capturing the full state of a database all at once, as in an initial snapshot, Debezium captures each table in phases, in a series of configurable chunks. You can specify the tables that you want the snapshot to capture and the size of each chunk . The chunk size determines the number of rows that the snapshot collects during each fetch operation on the database. The default chunk size for incremental snapshots is 1024 rows. As an incremental snapshot proceeds, Debezium uses watermarks to track its progress, maintaining a record of each table row that it captures. This phased approach to capturing data provides the following advantages over the standard initial snapshot process: You can run incremental snapshots in parallel with streamed data capture, instead of postponing streaming until the snapshot completes. The connector continues to capture near real-time events from the change log throughout the snapshot process, and neither operation blocks the other. If the progress of an incremental snapshot is interrupted, you can resume it without losing any data. After the process resumes, the snapshot begins at the point where it stopped, rather than recapturing the table from the beginning. You can run an incremental snapshot on demand at any time, and repeat the process as needed to adapt to database updates. For example, you might re-run a snapshot after you modify the connector configuration to add a table to its table.include.list property. Incremental snapshot process When you run an incremental snapshot, Debezium sorts each table by primary key and then splits the table into chunks based on the configured chunk size . Working chunk by chunk, it then captures each table row in a chunk. For each row that it captures, the snapshot emits a READ event. That event represents the value of the row when the snapshot for the chunk began. As a snapshot proceeds, it's likely that other processes continue to access the database, potentially modifying table records. To reflect such changes, INSERT , UPDATE , or DELETE operations are committed to the transaction log as per usual. Similarly, the ongoing Debezium streaming process continues to detect these change events and emits corresponding change event records to Kafka. How Debezium resolves collisions among records with the same primary key In some cases, the UPDATE or DELETE events that the streaming process emits are received out of sequence. That is, the streaming process might emit an event that modifies a table row before the snapshot captures the chunk that contains the READ event for that row. When the snapshot eventually emits the corresponding READ event for the row, its value is already superseded. To ensure that incremental snapshot events that arrive out of sequence are processed in the correct logical order, Debezium employs a buffering scheme for resolving collisions. Only after collisions between the snapshot events and the streamed events are resolved does Debezium emit an event record to Kafka. Snapshot window To assist in resolving collisions between late-arriving READ events and streamed events that modify the same table row, Debezium employs a so-called snapshot window . The snapshot window demarcates the interval during which an incremental snapshot captures data for a specified table chunk. Before the snapshot window for a chunk opens, Debezium follows its usual behavior and emits events from the transaction log directly downstream to the target Kafka topic. But from the moment that the snapshot for a particular chunk opens, until it closes, Debezium performs a de-duplication step to resolve collisions between events that have the same primary key.. For each data collection, the Debezium emits two types of events, and stores the records for them both in a single destination Kafka topic. The snapshot records that it captures directly from a table are emitted as READ operations. Meanwhile, as users continue to update records in the data collection, and the transaction log is updated to reflect each commit, Debezium emits UPDATE or DELETE operations for each change. As the snapshot window opens, and Debezium begins processing a snapshot chunk, it delivers snapshot records to a memory buffer. During the snapshot windows, the primary keys of the READ events in the buffer are compared to the primary keys of the incoming streamed events. If no match is found, the streamed event record is sent directly to Kafka. If Debezium detects a match, it discards the buffered READ event, and writes the streamed record to the destination topic, because the streamed event logically supersede the static snapshot event. After the snapshot window for the chunk closes, the buffer contains only READ events for which no related transaction log events exist. Debezium emits these remaining READ events to the table's Kafka topic. The connector repeats the process for each snapshot chunk. Currently, you can use either of the following methods to initiate an incremental snapshot: Send an ad hoc snapshot signal to the signaling table on the source database . Send a message to a configured Kafka signaling topic . Warning The Debezium connector for PostgreSQL does not support schema changes while an incremental snapshot is running. If a schema change is performed before the incremental snapshot start but after sending the signal then passthrough config option database.autosave is set to conservative to correctly process the schema change. 2.6.2.4.1. Triggering an incremental snapshot To initiate an incremental snapshot, you can send an ad hoc snapshot signal to the signaling table on the source database. You submit snapshot signals as SQL INSERT queries. After Debezium detects the change in the signaling table, it reads the signal, and runs the requested snapshot operation. The query that you submit specifies the tables to include in the snapshot, and, optionally, specifies the type of snapshot operation. Debezium currently supports the incremental and blocking snapshot types. To specify the tables to include in the snapshot, provide a data-collections array that lists the tables, or an array of regular expressions used to match tables, for example, {"data-collections": ["public.MyFirstTable", "public.MySecondTable"]} The data-collections array for an incremental snapshot signal has no default value. If the data-collections array is empty, Debezium interprets the empty array to mean that no action is required, and it does not perform a snapshot. Note If the name of a table that you want to include in a snapshot contains a dot ( . ), a space, or some other non-alphanumeric character, you must escape the table name in double quotes. For example, to include a table that exists in the public schema and that has the name My.Table , use the following format: "public.\"My.Table\"" . Prerequisites Signaling is enabled . A signaling data collection exists on the source database. The signaling data collection is specified in the signal.data.collection property. Using a source signaling channel to trigger an incremental snapshot Send a SQL query to add the ad hoc incremental snapshot request to the signaling table: INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}'); For example, INSERT INTO myschema.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'execute-snapshot', 3 '{"data-collections": ["schema1.table1", "schema1.table2"], 4 "type":"incremental", 5 "additional-conditions":[{"data-collection": "schema1.table1" ,"filter":"color=\'blue\'"}]}'); 6 The values of the id , type , and data parameters in the command correspond to the fields of the signaling table . The following table describes the parameters in the example: Table 2.129. Descriptions of fields in a SQL command for sending an incremental snapshot signal to the signaling table Item Value Description 1 schema.debezium_signal Specifies the fully-qualified name of the signaling table on the source database. 2 ad-hoc-1 The id parameter specifies an arbitrary string that is assigned as the id identifier for the signal request. Use this string to identify logging messages to entries in the signaling table. Debezium does not use this string. Rather, during the snapshot, Debezium generates its own id string as a watermarking signal. 3 execute-snapshot The type parameter specifies the operation that the signal is intended to trigger. 4 data-collections A required component of the data field of a signal that specifies an array of table names or regular expressions to match table names to include in the snapshot. The array lists regular expressions that use the format schema.table to match the fully-qualified names of the tables. This format is the same as the one that you use to specify the name of the connector's signaling table . 5 incremental An optional type component of the data field of a signal that specifies the type of snapshot operation to run. Valid values are incremental and blocking . If you do not specify a value, the connector defaults to performing an incremental snapshot. 6 additional-conditions An optional array that specifies a set of additional conditions that the connector evaluates to determine the subset of records to include in a snapshot. Each additional condition is an object with data-collection and filter properties. You can specify different filters for each data collection. * The data-collection property is the fully-qualified name of the data collection that the filter applies to. For more information about the additional-conditions parameter, see Section 2.6.2.4.2, "Running an ad hoc incremental snapshots with additional-conditions " . 2.6.2.4.2. Running an ad hoc incremental snapshots with additional-conditions If you want a snapshot to include only a subset of the content in a table, you can modify the signal request by appending an additional-conditions parameter to the snapshot signal. The SQL query for a typical snapshot takes the following form: SELECT * FROM <tableName> .... By adding an additional-conditions parameter, you append a WHERE condition to the SQL query, as in the following example: SELECT * FROM <data-collection> WHERE <filter> .... The following example shows a SQL query to send an ad hoc incremental snapshot request with an additional condition to the signaling table: INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}'); For example, suppose you have a products table that contains the following columns: id (primary key) color quantity If you want an incremental snapshot of the products table to include only the data items where color=blue , you can use the following SQL statement to trigger the snapshot: INSERT INTO myschema.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["schema1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "schema1.products", "filter": "color=blue"}]}'); The additional-conditions parameter also enables you to pass conditions that are based on more than one column. For example, using the products table from the example, you can submit a query that triggers an incremental snapshot that includes the data of only those items for which color=blue and quantity>10 : INSERT INTO myschema.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["schema1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "schema1.products", "filter": "color=blue AND quantity>10"}]}'); The following example, shows the JSON for an incremental snapshot event that is captured by a connector. Example 2.40. Incremental snapshot event message { "before":null, "after": { "pk":"1", "value":"New data" }, "source": { ... "snapshot":"incremental" 1 }, "op":"r", 2 "ts_ms":"1620393591654", "ts_us":"1620393591654547", "ts_ns":"1620393591654547920", "transaction":null } Table 2.130. Description of fields in an incremental snapshot event message Item Field name Description 1 snapshot Specifies the type of snapshot operation to run. Currently, the only valid options are blocking and incremental . Specifying a type value in the SQL query that you submit to the signaling table is optional. If you do not specify a value, the connector runs an incremental snapshot. 2 op Specifies the event type. The value for snapshot events is r , signifying a READ operation. 2.6.2.4.3. Using the Kafka signaling channel to trigger an incremental snapshot You can send a message to the configured Kafka topic to request the connector to run an ad hoc incremental snapshot. The key of the Kafka message must match the value of the topic.prefix connector configuration option. The value of the message is a JSON object with type and data fields. The signal type is execute-snapshot , and the data field must have the following fields: Table 2.131. Execute snapshot data fields Field Default Value type incremental The type of the snapshot to be executed. Currently Debezium supports the incremental and blocking types. See the section for more details. data-collections N/A An array of comma-separated regular expressions that match the fully-qualified names of tables to include in the snapshot. Specify the names by using the same format as is required for the signal.data.collection configuration option. additional-conditions N/A An optional array of additional conditions that specifies criteria that the connector evaluates to designate a subset of records to include in a snapshot. Each additional condition is an object that specifies the criteria for filtering the data that an ad hoc snapshot captures. You can set the following parameters for each additional condition: data-collection :: The fully-qualified name of the table that the filter applies to. You can apply different filters to each table. filter :: Specifies column values that must be present in a database record for the snapshot to include it, for example, "color='blue'" . The values that you assign to the filter parameter are the same types of values that you might specify in the WHERE clause of SELECT statements when you set the snapshot.select.statement.overrides property for a blocking snapshot. Example 2.41. An execute-snapshot Kafka message Ad hoc incremental snapshots with additional-conditions Debezium uses the additional-conditions field to select a subset of a table's content. Typically, when Debezium runs a snapshot, it runs a SQL query such as: SELECT * FROM <tableName> ... . When the snapshot request includes an additional-conditions property, the data-collection and filter parameters of the property are appended to the SQL query, for example: SELECT * FROM <data-collection> WHERE <filter> ... . For example, given a products table with the columns id (primary key), color , and brand , if you want a snapshot to include only content for which color='blue' , when you request the snapshot, you could add the additional-conditions property to filter the content: Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["schema1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "schema1.products" ,"filter":"color='blue'"}]}}` You can also use the additional-conditions property to pass conditions based on multiple columns. For example, using the same products table as in the example, if you want a snapshot to include only the content from the products table for which color='blue' , and brand='MyBrand' , you could send the following request: Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["schema1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "schema1.products" ,"filter":"color='blue' AND brand='MyBrand'"}]}}` 2.6.2.4.4. Stopping an incremental snapshot In some situations, it might be necessary to stop an incremental snapshot. For example, you might realize that snapshot was not configured correctly, or maybe you want to ensure that resources are available for other database operations. You can stop a snapshot that is already running by sending a signal to the signaling table on the source database. You submit a stop snapshot signal to the signaling table by sending it in a SQL INSERT query. The stop-snapshot signal specifies the type of the snapshot operation as incremental , and optionally specifies the tables that you want to omit from the currently running snapshot. After Debezium detects the change in the signaling table, it reads the signal, and stops the incremental snapshot operation if it's in progress. Additional resources You can also stop an incremental snapshot by sending a JSON message to the Kafka signaling topic . Prerequisites Signaling is enabled . A signaling data collection exists on the source database. The signaling data collection is specified in the signal.data.collection property. Using a source signaling channel to stop an incremental snapshot Send a SQL query to stop the ad hoc incremental snapshot to the signaling table: INSERT INTO <signalTable> (id, type, data) values ( '<id>' , 'stop-snapshot', '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":"incremental"}'); For example, INSERT INTO myschema.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'stop-snapshot', 3 '{"data-collections": ["schema1.table1", "schema1.table2"], 4 "type":"incremental"}'); 5 The values of the id , type , and data parameters in the signal command correspond to the fields of the signaling table . The following table describes the parameters in the example: Table 2.132. Descriptions of fields in a SQL command for sending a stop incremental snapshot signal to the signaling table Item Value Description 1 schema.debezium_signal Specifies the fully-qualified name of the signaling table on the source database. 2 ad-hoc-1 The id parameter specifies an arbitrary string that is assigned as the id identifier for the signal request. Use this string to identify logging messages to entries in the signaling table. Debezium does not use this string. 3 stop-snapshot Specifies type parameter specifies the operation that the signal is intended to trigger. 4 data-collections An optional component of the data field of a signal that specifies an array of table names or regular expressions to match table names to remove from the snapshot. The array lists regular expressions which match tables by their fully-qualified names in the format schema.table If you omit this component from the data field, the signal stops the entire incremental snapshot that is in progress. 5 incremental A required component of the data field of a signal that specifies the type of snapshot operation that is to be stopped. Currently, the only valid option is incremental . If you do not specify a type value, the signal fails to stop the incremental snapshot. 2.6.2.4.5. Using the Kafka signaling channel to stop an incremental snapshot You can send a signal message to the configured Kafka signaling topic to stop an ad hoc incremental snapshot. The key of the Kafka message must match the value of the topic.prefix connector configuration option. The value of the message is a JSON object with type and data fields. The signal type is stop-snapshot , and the data field must have the following fields: Table 2.133. Execute snapshot data fields Field Default Value type incremental The type of the snapshot to be executed. Currently Debezium supports only the incremental type. See the section for more details. data-collections N/A An optional array of comma-separated regular expressions that match the fully-qualified names of the tables an array of table names or regular expressions to match table names to remove from the snapshot. Specify table names by using the format schema.table . The following example shows a typical stop-snapshot Kafka message: Key = `test_connector` Value = `{"type":"stop-snapshot","data": {"data-collections": ["schema1.table1", "schema1.table2"], "type": "INCREMENTAL"}}` 2.6.2.5. Blocking snapshots To provide more flexibility in managing snapshots, Debezium includes a supplementary ad hoc snapshot mechanism, known as a blocking snapshot . Blocking snapshots rely on the Debezium mechanism for sending signals to a Debezium connector . A blocking snapshot behaves just like an initial snapshot , except that you can trigger it at run time. You might want to run a blocking snapshot rather than use the standard initial snapshot process in the following situations: You add a new table and you want to complete the snapshot while the connector is running. You add a large table, and you want the snapshot to complete in less time than is possible with an incremental snapshot. Blocking snapshot process When you run a blocking snapshot, Debezium stops streaming, and then initiates a snapshot of the specified table, following the same process that it uses during an initial snapshot. After the snapshot completes, the streaming is resumed. Configure snapshot You can set the following properties in the data component of a signal: data-collections: to specify which tables must be snapshot additional-conditions: You can specify different filters for different table. The data-collection property is the fully-qualified name of the table for which the filter will be applied. The filter property will have the same value used in the snapshot.select.statement.overrides For example: {"type": "blocking", "data-collections": ["schema1.table1", "schema1.table2"], "additional-conditions": [{"data-collection": "schema1.table1", "filter": "SELECT * FROM [schema1].[table1] WHERE column1 = 0 ORDER BY column2 DESC"}, {"data-collection": "schema1.table2", "filter": "SELECT * FROM [schema1].[table2] WHERE column2 > 0"}]} Possible duplicates A delay might exist between the time that you send the signal to trigger the snapshot, and the time when streaming stops and the snapshot starts. As a result of this delay, after the snapshot completes, the connector might emit some event records that duplicate records captured by the snapshot. 2.6.2.6. How Debezium PostgreSQL connectors stream change event records The PostgreSQL connector typically spends the vast majority of its time streaming changes from the PostgreSQL server to which it is connected. This mechanism relies on PostgreSQL's replication protocol . This protocol enables clients to receive changes from the server as they are committed in the server's transaction log at certain positions, which are referred to as Log Sequence Numbers (LSNs). Whenever the server commits a transaction, a separate server process invokes a callback function from the logical decoding plug-in . This function processes the changes from the transaction, converts them to a specific format (Protobuf or JSON in the case of Debezium plug-in) and writes them on an output stream, which can then be consumed by clients. The Debezium PostgreSQL connector acts as a PostgreSQL client. When the connector receives changes it transforms the events into Debezium create , update , or delete events that include the LSN of the event. The PostgreSQL connector forwards these change events in records to the Kafka Connect framework, which is running in the same process. The Kafka Connect process asynchronously writes the change event records in the same order in which they were generated to the appropriate Kafka topic. Periodically, Kafka Connect records the most recent offset in another Kafka topic. The offset indicates source-specific position information that Debezium includes with each event. For the PostgreSQL connector, the LSN recorded in each change event is the offset. When Kafka Connect gracefully shuts down, it stops the connectors, flushes all event records to Kafka, and records the last offset received from each connector. When Kafka Connect restarts, it reads the last recorded offset for each connector, and starts each connector at its last recorded offset. When the connector restarts, it sends a request to the PostgreSQL server to send the events starting just after that position. Note The PostgreSQL connector retrieves schema information as part of the events sent by the logical decoding plug-in. However, the connector does not retrieve information about which columns compose the primary key. The connector obtains this information from the JDBC metadata (side channel). If the primary key definition of a table changes (by adding, removing or renaming primary key columns), there is a tiny period of time when the primary key information from JDBC is not synchronized with the change event that the logical decoding plug-in generates. During this tiny period, a message could be created with an inconsistent key structure. To prevent this inconsistency, update primary key structures as follows: Put the database or an application into a read-only mode. Let Debezium process all remaining events. Stop Debezium. Update the primary key definition in the relevant table. Put the database or the application into read/write mode. Restart Debezium. PostgreSQL 10+ logical decoding support ( pgoutput ) As of PostgreSQL 10+, there is a logical replication stream mode, called pgoutput that is natively supported by PostgreSQL. This means that a Debezium PostgreSQL connector can consume that replication stream without the need for additional plug-ins. This is particularly valuable for environments where installation of plug-ins is not supported or not allowed. For more information, see Setting up PostgreSQL . 2.6.2.7. Default names of Kafka topics that receive Debezium PostgreSQL change event records By default, the PostgreSQL connector writes change events for all INSERT , UPDATE , and DELETE operations that occur in a table to a single Apache Kafka topic that is specific to that table. The connector uses the following convention to name change event topics: topicPrefix.schemaName.tableName The following list provides definitions for the components of the default name: topicPrefix The topic prefix as specified by the topic.prefix configuration property. schemaName The name of the database schema in which the change event occurred. tableName The name of the database table in which the change event occurred. For example, suppose that fulfillment is the logical server name in the configuration for a connector that is capturing changes in a PostgreSQL installation that has a postgres database and an inventory schema that contains four tables: products , products_on_hand , customers , and orders . The connector would stream records to these four Kafka topics: fulfillment.inventory.products fulfillment.inventory.products_on_hand fulfillment.inventory.customers fulfillment.inventory.orders Now suppose that the tables are not part of a specific schema but were created in the default public PostgreSQL schema. The names of the Kafka topics would be: fulfillment.public.products fulfillment.public.products_on_hand fulfillment.public.customers fulfillment.public.orders The connector applies similar naming conventions to label its transaction metadata topics . If the default topic name do not meet your requirements, you can configure custom topic names. To configure custom topic names, you specify regular expressions in the logical topic routing SMT. For more information about using the logical topic routing SMT to customize topic naming, see Topic routing . 2.6.2.8. Debezium PostgreSQL connector-generated events that represent transaction boundaries Debezium can generate events that represent transaction boundaries and that enrich data change event messages. Limits on when Debezium receives transaction metadata Debezium registers and receives metadata only for transactions that occur after you deploy the connector. Metadata for transactions that occur before you deploy the connector is not available. For every transaction BEGIN and END , Debezium generates an event that contains the following fields: status BEGIN or END . id String representation of the unique transaction identifier composed of Postgres transaction ID itself and LSN of given operation separated by colon, i.e. the format is txID:LSN . ts_ms The time of a transaction boundary event ( BEGIN or END event) at the data source. If the data source does not provide Debezium with the event time, then the field instead represents the time at which Debezium processes the event. event_count (for END events) Total number of events emmitted by the transaction. data_collections (for END events) An array of pairs of data_collection and event_count elements that indicates the number of events that the connector emits for changes that originate from a data collection. Example { "status": "BEGIN", "id": "571:53195829", "ts_ms": 1486500577125, "event_count": null, "data_collections": null } { "status": "END", "id": "571:53195832", "ts_ms": 1486500577691, "event_count": 2, "data_collections": [ { "data_collection": "s1.a", "event_count": 1 }, { "data_collection": "s2.a", "event_count": 1 } ] } Unless overridden via the topic.transaction option, transaction events are written to the topic named <topic.prefix> .transaction . Change data event enrichment When transaction metadata is enabled the data message Envelope is enriched with a new transaction field. This field provides information about every event in the form of a composite of fields: id String representation of unique transaction identifier. total_order The absolute position of the event among all events generated by the transaction. data_collection_order The per-data collection position of the event among all events that were emitted by the transaction. Following is an example of a message: { "before": null, "after": { "pk": "2", "aa": "1" }, "source": { ... }, "op": "c", "ts_ms": "1580390884335", "ts_us": "1580390884335451", "ts_ns": "1580390884335451325", "transaction": { "id": "571:53195832", "total_order": "1", "data_collection_order": "1" } } 2.6.3. Descriptions of Debezium PostgreSQL connector data change events The Debezium PostgreSQL connector generates a data change event for each row-level INSERT , UPDATE , and DELETE operation. Each event contains a key and a value. The structure of the key and the value depends on the table that was changed. Debezium and Kafka Connect are designed around continuous streams of event messages . However, the structure of these events may change over time, which can be difficult for consumers to handle. To address this, each event contains the schema for its content or, if you are using a schema registry, a schema ID that a consumer can use to obtain the schema from the registry. This makes each event self-contained. The following skeleton JSON shows the basic four parts of a change event. However, how you configure the Kafka Connect converter that you choose to use in your application determines the representation of these four parts in change events. A schema field is in a change event only when you configure the converter to produce it. Likewise, the event key and event payload are in a change event only if you configure a converter to produce it. If you use the JSON converter and you configure it to produce all four basic change event parts, change events have this structure: { "schema": { 1 ... }, "payload": { 2 ... }, "schema": { 3 ... }, "payload": { 4 ... }, } Table 2.134. Overview of change event basic content Item Field name Description 1 schema The first schema field is part of the event key. It specifies a Kafka Connect schema that describes what is in the event key's payload portion. In other words, the first schema field describes the structure of the primary key, or the unique key if the table does not have a primary key, for the table that was changed. It is possible to override the table's primary key by setting the message.key.columns connector configuration property . In this case, the first schema field describes the structure of the key identified by that property. 2 payload The first payload field is part of the event key. It has the structure described by the schema field and it contains the key for the row that was changed. 3 schema The second schema field is part of the event value. It specifies the Kafka Connect schema that describes what is in the event value's payload portion. In other words, the second schema describes the structure of the row that was changed. Typically, this schema contains nested schemas. 4 payload The second payload field is part of the event value. It has the structure described by the schema field and it contains the actual data for the row that was changed. By default behavior is that the connector streams change event records to topics with names that are the same as the event's originating table . Note Starting with Kafka 0.10, Kafka can optionally record the event key and value with the timestamp at which the message was created (recorded by the producer) or written to the log by Kafka. Warning The PostgreSQL connector ensures that all Kafka Connect schema names adhere to the Avro schema name format . This means that the logical server name must start with a Latin letter or an underscore, that is, a-z, A-Z, or _. Each remaining character in the logical server name and each character in the schema and table names must be a Latin letter, a digit, or an underscore, that is, a-z, A-Z, 0-9, or \_. If there is an invalid character it is replaced with an underscore character. This can lead to unexpected conflicts if the logical server name, a schema name, or a table name contains invalid characters, and the only characters that distinguish names from one another are invalid and thus replaced with underscores. Details are in the following topics: Section 2.6.3.1, "About keys in Debezium PostgreSQL change events" Section 2.6.3.2, "About values in Debezium PostgreSQL change events" 2.6.3.1. About keys in Debezium PostgreSQL change events For a given table, the change event's key has a structure that contains a field for each column in the primary key of the table at the time the event was created. Alternatively, if the table has REPLICA IDENTITY set to FULL or USING INDEX there is a field for each unique key constraint. Consider a customers table defined in the public database schema and the example of a change event key for that table. Example table CREATE TABLE customers ( id SERIAL, first_name VARCHAR(255) NOT NULL, last_name VARCHAR(255) NOT NULL, email VARCHAR(255) NOT NULL, PRIMARY KEY(id) ); Example change event key If the topic.prefix connector configuration property has the value PostgreSQL_server , every change event for the customers table while it has this definition has the same key structure, which in JSON looks like this: { "schema": { 1 "type": "struct", "name": "PostgreSQL_server.public.customers.Key", 2 "optional": false, 3 "fields": [ 4 { "name": "id", "index": "0", "schema": { "type": "INT32", "optional": "false" } } ] }, "payload": { 5 "id": "1" }, } Table 2.135. Description of change event key Item Field name Description 1 schema The schema portion of the key specifies a Kafka Connect schema that describes what is in the key's payload portion. 2 PostgreSQL_server.inventory.customers.Key Name of the schema that defines the structure of the key's payload. This schema describes the structure of the primary key for the table that was changed. Key schema names have the format connector-name . database-name . table-name . Key . In this example: PostgreSQL_server is the name of the connector that generated this event. inventory is the database that contains the table that was changed. customers is the table that was updated. 3 optional Indicates whether the event key must contain a value in its payload field. In this example, a value in the key's payload is required. A value in the key's payload field is optional when a table does not have a primary key. 4 fields Specifies each field that is expected in the payload , including each field's name, index, and schema. 5 payload Contains the key for the row for which this change event was generated. In this example, the key, contains a single id field whose value is 1 . Note Although the column.exclude.list and column.include.list connector configuration properties allow you to capture only a subset of table columns, all columns in a primary or unique key are always included in the event's key. Warning If the table does not have a primary or unique key, then the change event's key is null. The rows in a table without a primary or unique key constraint cannot be uniquely identified. 2.6.3.2. About values in Debezium PostgreSQL change events The value in a change event is a bit more complicated than the key. Like the key, the value has a schema section and a payload section. The schema section contains the schema that describes the Envelope structure of the payload section, including its nested fields. Change events for operations that create, update or delete data all have a value payload with an envelope structure. Consider the same sample table that was used to show an example of a change event key: CREATE TABLE customers ( id SERIAL, first_name VARCHAR(255) NOT NULL, last_name VARCHAR(255) NOT NULL, email VARCHAR(255) NOT NULL, PRIMARY KEY(id) ); The value portion of a change event for a change to this table varies according to the REPLICA IDENTITY setting and the operation that the event is for. Details follow in these sections: Replica identity create events update events Primary key updates delete events Tombstone events Replica identity REPLICA IDENTITY is a PostgreSQL-specific table-level setting that determines the amount of information that is available to the logical decoding plug-in for UPDATE and DELETE events. More specifically, the setting of REPLICA IDENTITY controls what (if any) information is available for the values of the table columns involved, whenever an UPDATE or DELETE event occurs. There are 4 possible values for REPLICA IDENTITY : DEFAULT - The default behavior is that UPDATE and DELETE events contain the values for the primary key columns of a table if that table has a primary key. For an UPDATE event, only the primary key columns with changed values are present. If a table does not have a primary key, the connector does not emit UPDATE or DELETE events for that table. For a table without a primary key, the connector emits only create events. Typically, a table without a primary key is used for appending messages to the end of the table, which means that UPDATE and DELETE events are not useful. NOTHING - Emitted events for UPDATE and DELETE operations do not contain any information about the value of any table column. FULL - Emitted events for UPDATE and DELETE operations contain the values of all columns in the table. INDEX index-name - Emitted events for UPDATE and DELETE operations contain the values of the columns contained in the specified index. UPDATE events also contain the indexed columns with the updated values. create events The following example shows the value portion of a change event that the connector generates for an operation that creates data in the customers table: { "schema": { 1 "type": "struct", "fields": [ { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "id" }, { "type": "string", "optional": false, "field": "first_name" }, { "type": "string", "optional": false, "field": "last_name" }, { "type": "string", "optional": false, "field": "email" } ], "optional": true, "name": "PostgreSQL_server.inventory.customers.Value", 2 "field": "before" }, { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "id" }, { "type": "string", "optional": false, "field": "first_name" }, { "type": "string", "optional": false, "field": "last_name" }, { "type": "string", "optional": false, "field": "email" } ], "optional": true, "name": "PostgreSQL_server.inventory.customers.Value", "field": "after" }, { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "version" }, { "type": "string", "optional": false, "field": "connector" }, { "type": "string", "optional": false, "field": "name" }, { "type": "int64", "optional": false, "field": "ts_ms" }, { "type": "int64", "optional": false, "field": "ts_us" }, { "type": "int64", "optional": false, "field": "ts_ns" }, { "type": "boolean", "optional": true, "default": false, "field": "snapshot" }, { "type": "string", "optional": false, "field": "db" }, { "type": "string", "optional": false, "field": "schema" }, { "type": "string", "optional": false, "field": "table" }, { "type": "int64", "optional": true, "field": "txId" }, { "type": "int64", "optional": true, "field": "lsn" }, { "type": "int64", "optional": true, "field": "xmin" } ], "optional": false, "name": "io.debezium.connector.postgresql.Source", 3 "field": "source" }, { "type": "string", "optional": false, "field": "op" }, { "type": "int64", "optional": true, "field": "ts_ms" }, { "type": "int64", "optional": true, "field": "ts_us" }, { "type": "int64", "optional": true, "field": "ts_ns" } ], "optional": false, "name": "PostgreSQL_server.inventory.customers.Envelope" 4 }, "payload": { 5 "before": null, 6 "after": { 7 "id": 1, "first_name": "Anne", "last_name": "Kretchmar", "email": "annek@noanswer.org" }, "source": { 8 "version": "2.7.3.Final", "connector": "postgresql", "name": "PostgreSQL_server", "ts_ms": 1559033904863, "ts_us": 1559033904863123, "ts_ns": 1559033904863123000, "snapshot": true, "db": "postgres", "sequence": "[\"24023119\",\"24023128\"]", "schema": "public", "table": "customers", "txId": 555, "lsn": 24023128, "xmin": null }, "op": "c", 9 "ts_ms": 1559033904863, 10 "ts_us": 1559033904863841, 11 "ts_ns": 1559033904863841257 12 } } Table 2.136. Descriptions of create event value fields Item Field name Description 1 schema The value's schema, which describes the structure of the value's payload. A change event's value schema is the same in every change event that the connector generates for a particular table. 2 name In the schema section, each name field specifies the schema for a field in the value's payload. PostgreSQL_server.inventory.customers.Value is the schema for the payload's before and after fields. This schema is specific to the customers table. Names of schemas for before and after fields are of the form logicalName . tableName .Value , which ensures that the schema name is unique in the database. This means that when using the Avro converter , the resulting Avro schema for each table in each logical source has its own evolution and history. 3 name io.debezium.connector.postgresql.Source is the schema for the payload's source field. This schema is specific to the PostgreSQL connector. The connector uses it for all events that it generates. 4 name PostgreSQL_server.inventory.customers.Envelope is the schema for the overall structure of the payload, where PostgreSQL_server is the connector name, inventory is the database, and customers is the table. 5 payload The value's actual data. This is the information that the change event is providing. It may appear that the JSON representations of the events are much larger than the rows they describe. This is because the JSON representation must include the schema and the payload portions of the message. However, by using the Avro converter , you can significantly decrease the size of the messages that the connector streams to Kafka topics. 6 before An optional field that specifies the state of the row before the event occurred. When the op field is c for create, as it is in this example, the before field is null since this change event is for new content. Note Whether or not this field is available is dependent on the REPLICA IDENTITY setting for each table. 7 after An optional field that specifies the state of the row after the event occurred. In this example, the after field contains the values of the new row's id , first_name , last_name , and email columns. 8 source Mandatory field that describes the source metadata for the event. This field contains information that you can use to compare this event with other events, with regard to the origin of the events, the order in which the events occurred, and whether events were part of the same transaction. The source metadata includes: Debezium version Connector type and name Database and table that contains the new row Stringified JSON array of additional offset information. The first value is always the last committed LSN, the second value is always the current LSN. Either value may be null . Schema name If the event was part of a snapshot ID of the transaction in which the operation was performed Offset of the operation in the database log Timestamp for when the change was made in the database 9 op Mandatory string that describes the type of operation that caused the connector to generate the event. In this example, c indicates that the operation created a row. Valid values are: c = create u = update d = delete r = read (applies to only snapshots) t = truncate m = message 10 ts_ms , ts_us , ts_ns Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. update events The value of a change event for an update in the sample customers table has the same schema as a create event for that table. Likewise, the event value's payload has the same structure. However, the event value payload contains different values in an update event. Here is an example of a change event value in an event that the connector generates for an update in the customers table: { "schema": { ... }, "payload": { "before": { 1 "id": 1 }, "after": { 2 "id": 1, "first_name": "Anne Marie", "last_name": "Kretchmar", "email": "annek@noanswer.org" }, "source": { 3 "version": "2.7.3.Final", "connector": "postgresql", "name": "PostgreSQL_server", "ts_ms": 1559033904863, "ts_us": 1559033904863769, "ts_ns": 1559033904863769000, "snapshot": false, "db": "postgres", "schema": "public", "table": "customers", "txId": 556, "lsn": 24023128, "xmin": null }, "op": "u", 4 "ts_ms": 1465584025523, 5 "ts_us": 1465584025523514, 6 "ts_ns": 1465584025523514964, 7 } } Table 2.137. Descriptions of update event value fields Item Field name Description 1 before An optional field that contains values that were in the row before the database commit. In this example, only the primary key column, id , is present because the table's REPLICA IDENTITY setting is, by default, DEFAULT . For an update event to contain the values of all columns in the row, you would have to change the customers table by running ALTER TABLE customers REPLICA IDENTITY FULL . 2 after An optional field that specifies the state of the row after the event occurred. In this example, the first_name value is now Anne Marie . 3 source Mandatory field that describes the source metadata for the event. The source field structure has the same fields as in a create event, but some values are different. The source metadata includes: Debezium version Connector type and name Database and table that contains the new row Schema name If the event was part of a snapshot (always false for update events) ID of the transaction in which the operation was performed Offset of the operation in the database log Timestamp for when the change was made in the database 4 op Mandatory string that describes the type of operation. In an update event value, the op field value is u , signifying that this row changed because of an update. 5 ts_ms , ts_us , ts_ns Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. Note Updating the columns for a row's primary/unique key changes the value of the row's key. When a key changes, Debezium outputs three events: a DELETE event and a tombstone event with the old key for the row, followed by an event with the new key for the row. Details are in the section. Primary key updates An UPDATE operation that changes a row's primary key field(s) is known as a primary key change. For a primary key change, in place of sending an UPDATE event record, the connector sends a DELETE event record for the old key and a CREATE event record for the new (updated) key. These events have the usual structure and content, and in addition, each one has a message header related to the primary key change: The DELETE event record has __debezium.newkey as a message header. The value of this header is the new primary key for the updated row. The CREATE event record has __debezium.oldkey as a message header. The value of this header is the (old) primary key that the updated row had. delete events The value in a delete change event has the same schema portion as create and update events for the same table. The payload portion in a delete event for the sample customers table looks like this: { "schema": { ... }, "payload": { "before": { 1 "id": 1 }, "after": null, 2 "source": { 3 "version": "2.7.3.Final", "connector": "postgresql", "name": "PostgreSQL_server", "ts_ms": 1559033904863, "ts_us": 1559033904863852, "ts_ns": 1559033904863852000, "snapshot": false, "db": "postgres", "schema": "public", "table": "customers", "txId": 556, "lsn": 46523128, "xmin": null }, "op": "d", 4 "ts_ms": 1465581902461, 5 "ts_us": 1465581902461496, 6 "ts_ns": 1465581902461496187, 7 } } Table 2.138. Descriptions of delete event value fields Item Field name Description 1 before Optional field that specifies the state of the row before the event occurred. In a delete event value, the before field contains the values that were in the row before it was deleted with the database commit. In this example, the before field contains only the primary key column because the table's REPLICA IDENTITY setting is DEFAULT . 2 after Optional field that specifies the state of the row after the event occurred. In a delete event value, the after field is null , signifying that the row no longer exists. 3 source Mandatory field that describes the source metadata for the event. In a delete event value, the source field structure is the same as for create and update events for the same table. Many source field values are also the same. In a delete event value, the ts_ms and lsn field values, as well as other values, might have changed. But the source field in a delete event value provides the same metadata: Debezium version Connector type and name Database and table that contained the deleted row Schema name If the event was part of a snapshot (always false for delete events) ID of the transaction in which the operation was performed Offset of the operation in the database log Timestamp for when the change was made in the database 4 op Mandatory string that describes the type of operation. The op field value is d , signifying that this row was deleted. 5 ts_ms , ts_us , ts_ns Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. A delete change event record provides a consumer with the information it needs to process the removal of this row. Warning For a consumer to be able to process a delete event generated for a table that does not have a primary key, set the table's REPLICA IDENTITY to FULL . When a table does not have a primary key and the table's REPLICA IDENTITY is set to DEFAULT or NOTHING , a delete event has no before field. PostgreSQL connector events are designed to work with Kafka log compaction . Log compaction enables removal of some older messages as long as at least the most recent message for every key is kept. This lets Kafka reclaim storage space while ensuring that the topic contains a complete data set and can be used for reloading key-based state. Tombstone events When a row is deleted, the delete event value still works with log compaction, because Kafka can remove all earlier messages that have that same key. However, for Kafka to remove all messages that have that same key, the message value must be null . To make this possible, the PostgreSQL connector follows a delete event with a special tombstone event that has the same key but a null value. truncate events A truncate change event signals that a table has been truncated. The message key is null in this case, the message value looks like this: { "schema": { ... }, "payload": { "source": { 1 "version": "2.7.3.Final", "connector": "postgresql", "name": "PostgreSQL_server", "ts_ms": 1559033904863, "ts_us": 1559033904863112, "ts_ns": 1559033904863112000, "snapshot": false, "db": "postgres", "schema": "public", "table": "customers", "txId": 556, "lsn": 46523128, "xmin": null }, "op": "t", 2 "ts_ms": 1559033904961, 3 "ts_us": 1559033904961654, 4 "ts_ns": 1559033904961654789 5 } } Table 2.139. Descriptions of truncate event value fields Item Field name Description 1 source Mandatory field that describes the source metadata for the event. In a truncate event value, the source field structure is the same as for create , update , and delete events for the same table, provides this metadata: Debezium version Connector type and name Database and table that contains the new row Schema name If the event was part of a snapshot (always false for delete events) ID of the transaction in which the operation was performed Offset of the operation in the database log Timestamp for when the change was made in the database 2 op Mandatory string that describes the type of operation. The op field value is t , signifying that this table was truncated. 3 ts_ms , ts_us , ts_ns Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. In case a single TRUNCATE statement applies to multiple tables, one truncate change event record for each truncated table will be emitted. Note that since truncate events represent a change made to an entire table and don't have a message key, unless you're working with topics with a single partition, there are no ordering guarantees for the change events pertaining to a table ( create , update , etc.) and truncate events for that table. For instance a consumer may receive an update event only after a truncate event for that table, when those events are read from different partitions. message events This event type is only supported through the pgoutput plugin on Postgres 14+ ( Postgres Documentation ) A message event signals that a generic logical decoding message has been inserted directly into the WAL typically with the pg_logical_emit_message function. The message key is a Struct with a single field named prefix in this case, carrying the prefix specified when inserting the message. The message value looks like this for transactional messages: { "schema": { ... }, "payload": { "source": { 1 "version": "2.7.3.Final", "connector": "postgresql", "name": "PostgreSQL_server", "ts_ms": 1559033904863, "ts_us": 1559033904863879, "ts_ns": 1559033904863879000, "snapshot": false, "db": "postgres", "schema": "", "table": "", "txId": 556, "lsn": 46523128, "xmin": null }, "op": "m", 2 "ts_ms": 1559033904961, 3 "ts_us": 1559033904961621, 4 "ts_ns": 1559033904961621379, 5 "message": { 6 "prefix": "foo", "content": "Ymfy" } } } Unlike other event types, non-transactional messages will not have any associated BEGIN or END transaction events. The message value looks like this for non-transactional messages: { "schema": { ... }, "payload": { "source": { 1 "version": "2.7.3.Final", "connector": "postgresql", "name": "PostgreSQL_server", "ts_ms": 1559033904863, "ts_us": 1559033904863762, "ts_ns": 1559033904863762000, "snapshot": false, "db": "postgres", "schema": "", "table": "", "lsn": 46523128, "xmin": null }, "op": "m", 2 "ts_ms": 1559033904961, 3 "ts_us": 1559033904961741, 4 "ts_ns": 1559033904961741698, 5 "message": { 6 "prefix": "foo", "content": "Ymfy" } } Table 2.140. Descriptions of message event value fields Item Field name Description 1 source Mandatory field that describes the source metadata for the event. In a message event value, the source field structure will not have table or schema information for any message events and will only have txId if the message event is transactional. Debezium version Connector type and name Database name Schema name (always "" for message events) Table name (always "" for message events) If the event was part of a snapshot (always false for message events) ID of the transaction in which the operation was performed ( null for non-transactional message events) Offset of the operation in the database log Transactional messages: Timestamp for when the message was inserted into the WAL Non-Transactional messages; Timestamp for when the connector encounters the message 2 op Mandatory string that describes the type of operation. The op field value is m , signifying that this is a message event. 3 ts_ms , ts_us , ts_ns Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. For transactional message events, the ts_ms attribute of the source object indicates the time that the change was made in the database for transactional message events. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. For non-transactional message events, the source object's ts_ms indicates time at which the connector encounters the message event, while the payload.ts_ms indicates the time at which the connector processed the event. This difference is due to the fact that the commit timestamp is not present in Postgres's generic logical message format and non-transactional logical messages are not preceded by a BEGIN event (which has timestamp information). 4 message Field that contains the message metadata Prefix (text) Content (byte array that is encoded based on the binary handling mode setting) 2.6.4. How Debezium PostgreSQL connectors map data types The PostgreSQL connector represents changes to rows with events that are structured like the table in which the row exists. The event contains a field for each column value. How that value is represented in the event depends on the PostgreSQL data type of the column. The following sections describe how the connector maps PostgreSQL data types to a literal type and a semantic type in event fields. literal type describes how the value is literally represented using Kafka Connect schema types: INT8 , INT16 , INT32 , INT64 , FLOAT32 , FLOAT64 , BOOLEAN , STRING , BYTES , ARRAY , MAP , and STRUCT . semantic type describes how the Kafka Connect schema captures the meaning of the field using the name of the Kafka Connect schema for the field. If the default data type conversions do not meet your needs, you can create a custom converter for the connector. Details are in the following sections: Basic types Temporal types TIMESTAMP type Decimal types HSTORE type Domain types Network address types PostGIS types Toasted values Basic types The following table describes how the connector maps basic types. Table 2.141. Mappings for PostgreSQL basic data types PostgreSQL data type Literal type (schema type) Semantic type (schema name) and Notes BOOLEAN BOOLEAN n/a BIT(1) BOOLEAN n/a BIT( > 1) BYTES io.debezium.data.Bits The length schema parameter contains an integer that represents the number of bits. The resulting byte[] contains the bits in little-endian form and is sized to contain the specified number of bits. For example, numBytes = n/8 + (n % 8 == 0 ? 0 : 1) where n is the number of bits. BIT VARYING[(M)] BYTES io.debezium.data.Bits The length schema parameter contains an integer that represents the number of bits (2^31 - 1 in case no length is given for the column). The resulting byte[] contains the bits in little-endian form and is sized based on the content. The specified size (M) is stored in the length parameter of the io.debezium.data.Bits type. SMALLINT , SMALLSERIAL INT16 n/a INTEGER , SERIAL INT32 n/a BIGINT , BIGSERIAL , OID INT64 n/a REAL FLOAT32 n/a DOUBLE PRECISION FLOAT64 n/a CHAR[(M)] STRING n/a VARCHAR[(M)] STRING n/a CHARACTER[(M)] STRING n/a CHARACTER VARYING[(M)] STRING n/a TIMESTAMPTZ , TIMESTAMP WITH TIME ZONE STRING io.debezium.time.ZonedTimestamp A string representation of a timestamp with timezone information, where the timezone is GMT. TIMETZ , TIME WITH TIME ZONE STRING io.debezium.time.ZonedTime A string representation of a time value with timezone information, where the timezone is GMT. INTERVAL [P] INT64 io.debezium.time.MicroDuration (default) The approximate number of microseconds for a time interval using the 365.25 / 12.0 formula for days per month average. INTERVAL [P] STRING io.debezium.time.Interval (when interval.handling.mode is set to string ) The string representation of the interval value that follows the pattern P<years>Y<months>M<days>DT<hours>H<minutes>M<seconds>S , for example, P1Y2M3DT4H5M6.78S . BYTEA BYTES or STRING n/a Either the raw bytes (the default), a base64-encoded string, or a base64-url-safe-encoded String, or a hex-encoded string, based on the connector's binary handling mode setting. Debezium only supports Postgres bytea_output configuration of value hex . For more information about PostgreSQL binary data types, see the PostgreSQL documentation . JSON , JSONB STRING io.debezium.data.Json Contains the string representation of a JSON document, array, or scalar. XML STRING io.debezium.data.Xml Contains the string representation of an XML document. UUID STRING io.debezium.data.Uuid Contains the string representation of a PostgreSQL UUID value. POINT STRUCT io.debezium.data.geometry.Point Contains a structure with two FLOAT64 fields, (x,y) . Each field represents the coordinates of a geometric point. LTREE STRING io.debezium.data.Ltree Contains the string representation of a PostgreSQL LTREE value. CITEXT STRING n/a INET STRING n/a INT4RANGE STRING n/a Range of integer. INT8RANGE STRING n/a Range of bigint . NUMRANGE STRING n/a Range of numeric . TSRANGE STRING n/a Contains the string representation of a timestamp range without a time zone. TSTZRANGE STRING n/a Contains the string representation of a timestamp range with the local system time zone. DATERANGE STRING n/a Contains the string representation of a date range. It always has an exclusive upper-bound. ENUM STRING io.debezium.data.Enum Contains the string representation of the PostgreSQL ENUM value. The set of allowed values is maintained in the allowed schema parameter. Temporal types Other than PostgreSQL's TIMESTAMPTZ and TIMETZ data types, which contain time zone information, how temporal types are mapped depends on the value of the time.precision.mode connector configuration property. The following sections describe these mappings: time.precision.mode=adaptive time.precision.mode=adaptive_time_microseconds time.precision.mode=connect time.precision.mode=adaptive When the time.precision.mode property is set to adaptive , the default, the connector determines the literal type and semantic type based on the column's data type definition. This ensures that events exactly represent the values in the database. Table 2.142. Mappings when time.precision.mode is adaptive PostgreSQL data type Literal type (schema type) Semantic type (schema name) and Notes DATE INT32 io.debezium.time.Date Represents the number of days since the epoch. TIME(1) , TIME(2) , TIME(3) INT32 io.debezium.time.Time Represents the number of milliseconds past midnight, and does not include timezone information. TIME(4) , TIME(5) , TIME(6) INT64 io.debezium.time.MicroTime Represents the number of microseconds past midnight, and does not include timezone information. TIMESTAMP(1) , TIMESTAMP(2) , TIMESTAMP(3) INT64 io.debezium.time.Timestamp Represents the number of milliseconds since the epoch, and does not include timezone information. TIMESTAMP(4) , TIMESTAMP(5) , TIMESTAMP(6) , TIMESTAMP INT64 io.debezium.time.MicroTimestamp Represents the number of microseconds since the epoch, and does not include timezone information. time.precision.mode=adaptive_time_microseconds When the time.precision.mode configuration property is set to adaptive_time_microseconds , the connector determines the literal type and semantic type for temporal types based on the column's data type definition. This ensures that events exactly represent the values in the database, except all TIME fields are captured as microseconds. Table 2.143. Mappings when time.precision.mode is adaptive_time_microseconds PostgreSQL data type Literal type (schema type) Semantic type (schema name) and Notes DATE INT32 io.debezium.time.Date Represents the number of days since the epoch. TIME([P]) INT64 io.debezium.time.MicroTime Represents the time value in microseconds and does not include timezone information. PostgreSQL allows precision P to be in the range 0-6 to store up to microsecond precision. TIMESTAMP(1) , TIMESTAMP(2) , TIMESTAMP(3) INT64 io.debezium.time.Timestamp Represents the number of milliseconds past the epoch, and does not include timezone information. TIMESTAMP(4) , TIMESTAMP(5) , TIMESTAMP(6) , TIMESTAMP INT64 io.debezium.time.MicroTimestamp Represents the number of microseconds past the epoch, and does not include timezone information. time.precision.mode=connect When the time.precision.mode configuration property is set to connect , the connector uses Kafka Connect logical types. This may be useful when consumers can handle only the built-in Kafka Connect logical types and are unable to handle variable-precision time values. However, since PostgreSQL supports microsecond precision, the events generated by a connector with the connect time precision mode results in a loss of precision when the database column has a fractional second precision value that is greater than 3. Table 2.144. Mappings when time.precision.mode is connect PostgreSQL data type Literal type (schema type) Semantic type (schema name) and Notes DATE INT32 org.apache.kafka.connect.data.Date Represents the number of days since the epoch. TIME([P]) INT64 org.apache.kafka.connect.data.Time Represents the number of milliseconds since midnight, and does not include timezone information. PostgreSQL allows P to be in the range 0-6 to store up to microsecond precision, though this mode results in a loss of precision when P is greater than 3. TIMESTAMP([P]) INT64 org.apache.kafka.connect.data.Timestamp Represents the number of milliseconds since the epoch, and does not include timezone information. PostgreSQL allows P to be in the range 0-6 to store up to microsecond precision, though this mode results in a loss of precision when P is greater than 3. TIMESTAMP type The TIMESTAMP type represents a timestamp without time zone information. Such columns are converted into an equivalent Kafka Connect value based on UTC. For example, the TIMESTAMP value "2018-06-20 15:13:16.945104" is represented by an io.debezium.time.MicroTimestamp with the value "1529507596945104" when time.precision.mode is not set to connect . The timezone of the JVM running Kafka Connect and Debezium does not affect this conversion. PostgreSQL supports using +/-infinite values in TIMESTAMP columns. These special values are converted to timestamps with value 9223372036825200000 in case of positive infinity or -9223372036832400000 in case of negative infinity. This behavior mimics the standard behavior of the PostgreSQL JDBC driver. For reference, see the org.postgresql.PGStatement interface. Decimal types The setting of the PostgreSQL connector configuration property decimal.handling.mode determines how the connector maps decimal types. When the decimal.handling.mode property is set to precise , the connector uses the Kafka Connect org.apache.kafka.connect.data.Decimal logical type for all DECIMAL , NUMERIC and MONEY columns. This is the default mode. Table 2.145. Mappings when decimal.handling.mode is precise PostgreSQL data type Literal type (schema type) Semantic type (schema name) and Notes NUMERIC[(M[,D])] BYTES org.apache.kafka.connect.data.Decimal The scale schema parameter contains an integer representing how many digits the decimal point was shifted. DECIMAL[(M[,D])] BYTES org.apache.kafka.connect.data.Decimal The scale schema parameter contains an integer representing how many digits the decimal point was shifted. MONEY[(M[,D])] BYTES org.apache.kafka.connect.data.Decimal The scale schema parameter contains an integer representing how many digits the decimal point was shifted. The scale schema parameter is determined by the money.fraction.digits connector configuration property. There is an exception to this rule. When the NUMERIC or DECIMAL types are used without scale constraints, the values coming from the database have a different (variable) scale for each value. In this case, the connector uses io.debezium.data.VariableScaleDecimal , which contains both the value and the scale of the transferred value. Table 2.146. Mappings of DECIMAL and NUMERIC types when there are no scale constraints PostgreSQL data type Literal type (schema type) Semantic type (schema name) and Notes NUMERIC STRUCT io.debezium.data.VariableScaleDecimal Contains a structure with two fields: scale of type INT32 that contains the scale of the transferred value and value of type BYTES containing the original value in an unscaled form. DECIMAL STRUCT io.debezium.data.VariableScaleDecimal Contains a structure with two fields: scale of type INT32 that contains the scale of the transferred value and value of type BYTES containing the original value in an unscaled form. When the decimal.handling.mode property is set to double , the connector represents all DECIMAL , NUMERIC and MONEY values as Java double values and encodes them as shown in the following table. Table 2.147. Mappings when decimal.handling.mode is double PostgreSQL data type Literal type (schema type) Semantic type (schema name) NUMERIC[(M[,D])] FLOAT64 DECIMAL[(M[,D])] FLOAT64 MONEY[(M[,D])] FLOAT64 The last possible setting for the decimal.handling.mode configuration property is string . In this case, the connector represents DECIMAL , NUMERIC and MONEY values as their formatted string representation, and encodes them as shown in the following table. Table 2.148. Mappings when decimal.handling.mode is string PostgreSQL data type Literal type (schema type) Semantic type (schema name) NUMERIC[(M[,D])] STRING DECIMAL[(M[,D])] STRING MONEY[(M[,D])] STRING PostgreSQL supports NaN (not a number) as a special value to be stored in DECIMAL / NUMERIC values when the setting of decimal.handling.mode is string or double . In this case, the connector encodes NaN as either Double.NaN or the string constant NAN . HSTORE type The setting of the PostgreSQL connector configuration property hstore.handling.mode determines how the connector maps HSTORE values. When the hstore.handling.mode property is set to json (the default), the connector represents HSTORE values as string representations of JSON values and encodes them as shown in the following table. When the hstore.handling.mode property is set to map , the connector uses the MAP schema type for HSTORE values. Table 2.149. Mappings for HSTORE data type PostgreSQL data type Literal type (schema type) Semantic type (schema name) and Notes HSTORE STRING io.debezium.data.Json Example: output representation using the JSON converter is {"key" : "val"} HSTORE MAP n/a Example: output representation using the JSON converter is {"key" : "val"} Domain types PostgreSQL supports user-defined types that are based on other underlying types. When such column types are used, Debezium exposes the column's representation based on the full type hierarchy. Important Capturing changes in columns that use PostgreSQL domain types requires special consideration. When a column is defined to contain a domain type that extends one of the default database types and the domain type defines a custom length or scale, the generated schema inherits that defined length or scale. When a column is defined to contain a domain type that extends another domain type that defines a custom length or scale, the generated schema does not inherit the defined length or scale because that information is not available in the PostgreSQL driver's column metadata. Network address types PostgreSQL has data types that can store IPv4, IPv6, and MAC addresses. It is better to use these types instead of plain text types to store network addresses. Network address types offer input error checking and specialized operators and functions. Table 2.150. Mappings for network address types PostgreSQL data type Literal type (schema type) Semantic type (schema name) and Notes INET STRING n/a IPv4 and IPv6 networks CIDR STRING n/a IPv4 and IPv6 hosts and networks MACADDR STRING n/a MAC addresses MACADDR8 STRING n/a MAC addresses in EUI-64 format PostGIS types The PostgreSQL connector supports all PostGIS data types . Table 2.151. Mappings of PostGIS data types PostGIS data type Literal type (schema type) Semantic type (schema name) and Notes GEOMETRY (planar) STRUCT io.debezium.data.geometry.Geometry Contains a structure with two fields: srid (INT32) - Spatial Reference System Identifier that defines what type of geometry object is stored in the structure. wkb (BYTES) - A binary representation of the geometry object encoded in the Well-Known-Binary format. For format details, see Open Geospatial Consortium Simple Features Access specification . GEOGRAPHY (spherical) STRUCT io.debezium.data.geometry.Geography Contains a structure with two fields: srid (INT32) - Spatial Reference System Identifier that defines what type of geography object is stored in the structure. wkb (BYTES) - A binary representation of the geometry object encoded in the Well-Known-Binary format. For format details, see Open Geospatial Consortium Simple Features Access specification . Toasted values PostgreSQL has a hard limit on the page size. This means that values that are larger than around 8 KBs need to be stored by using TOAST storage . This impacts replication messages that are coming from the database. Values that were stored by using the TOAST mechanism and that have not been changed are not included in the message, unless they are part of the table's replica identity. There is no safe way for Debezium to read the missing value out-of-bands directly from the database, as this would potentially lead to race conditions. Consequently, Debezium follows these rules to handle toasted values: Tables with REPLICA IDENTITY FULL - TOAST column values are part of the before and after fields in change events just like any other column. Tables with REPLICA IDENTITY DEFAULT - When receiving an UPDATE event from the database, any unchanged TOAST column value that is not part of the replica identity is not contained in the event. Similarly, when receiving a DELETE event, no TOAST columns, if any, are in the before field. As Debezium cannot safely provide the column value in this case, the connector returns a placeholder value as defined by the connector configuration property, unavailable.value.placeholder . Default values If a default value is specified for a column in the database schema, the PostgreSQL connector will attempt to propagate this value to the Kafka schema whenever possible. Most common data types are supported, including: BOOLEAN Numeric types ( INT , FLOAT , NUMERIC , etc.) Text types ( CHAR , VARCHAR , TEXT , etc.) Temporal types ( DATE , TIME , INTERVAL , TIMESTAMP , TIMESTAMPTZ ) JSON , JSONB , XML UUID Note that for temporal types, parsing of the default value is provided by PostgreSQL libraries; therefore, any string representation which is normally supported by PostgreSQL should also be supported by the connector. In the case that the default value is generated by a function rather than being directly specified in-line, the connector will instead export the equivalent of 0 for the given data type. These values include: FALSE for BOOLEAN 0 with appropriate precision, for numeric types Empty string for text/XML types {} for JSON types 1970-01-01 for DATE , TIMESTAMP , TIMESTAMPTZ types 00:00 for TIME EPOCH for INTERVAL 00000000-0000-0000-0000-000000000000 for UUID This support currently extends only to explicit usage of functions. For example, CURRENT_TIMESTAMP(6) is supported with parentheses, but CURRENT_TIMESTAMP is not. Important Support for the propagation of default values exists primarily to allow for safe schema evolution when using the PostgreSQL connector with a schema registry which enforces compatibility between schema versions. Due to this primary concern, as well as the refresh behaviours of the different plug-ins, the default value present in the Kafka schema is not guaranteed to always be in-sync with the default value in the database schema. Default values may appear 'late' in the Kafka schema, depending on when/how a given plugin triggers refresh of the in-memory schema. Values may never appear/be skipped in the Kafka schema if the default changes multiple times in-between refreshes Default values may appear 'early' in the Kafka schema, if a schema refresh is triggered while the connector has records waiting to be processed. This is due to the column metadata being read from the database at refresh time, rather than being present in the replication message. This may occur if the connector is behind and a refresh occurs, or on connector start if the connector was stopped for a time while updates continued to be written to the source database. This behaviour may be unexpected, but it is still safe. Only the schema definition is affected, while the real values present in the message will remain consistent with what was written to the source database. Custom converters By default, Debezium does not replicate data from columns with custom data types, such as composite types that are created by using SQL CREATE TYPE statements. To replicate columns with custom data types, follow the instructions for creating a custom converter , with a few important caveats: Set the include.unknown.datatypes property in the connector configuration to true . The default false setting causes the custom converter to always return null values. The type of value that is passed to the converter depends on the logical decoding output plug-in that is configured for the replication slot. decoderbufs passes a byte array ( byte[] ) representation of the column data. pgoutput passes a string representation of the column data. 2.6.5. Setting up PostgreSQL to run a Debezium connector This release of Debezium supports only the native pgoutput logical replication stream. To set up PostgreSQL so that it uses the pgoutput plug-in, you must enable a replication slot, and configure a user with sufficient privileges to perform the replication. Details are in the following topics: Section 2.6.5.1, "Configuring a replication slot for the Debezium pgoutput plug-in" Section 2.6.5.2, "Setting up PostgreSQL permissions for the Debezium connector" Section 2.6.5.3, "Setting privileges to enable Debezium to create PostgreSQL publications" Section 2.6.5.4, "Configuring PostgreSQL to allow replication with the Debezium connector host" Section 2.6.5.5, "Configuring PostgreSQL to manage Debezium WAL disk space consumption" Section 2.6.5.6, "Upgrading PostgreSQL databases that Debezium captures from" 2.6.5.1. Configuring a replication slot for the Debezium pgoutput plug-in PostgreSQL's logical decoding uses replication slots. To configure a replication slot, specify the following in the postgresql.conf file: These settings instruct the PostgreSQL server as follows: wal_level - Use logical decoding with the write-ahead log. max_wal_senders - Use a maximum of one separate process for processing WAL changes. max_replication_slots - Allow a maximum of one replication slot to be created for streaming WAL changes. Replication slots are guaranteed to retain all WAL entries that are required for Debezium even during Debezium outages. Consequently, it is important to closely monitor replication slots to avoid: Too much disk consumption Any conditions, such as catalog bloat, that can happen if a replication slot stays unused for too long For more information, see the PostgreSQL documentation for replication slots . Note Familiarity with the mechanics and configuration of the PostgreSQL write-ahead log is helpful for using the Debezium PostgreSQL connector. 2.6.5.2. Setting up PostgreSQL permissions for the Debezium connector Setting up a PostgreSQL server to run a Debezium connector requires a database user that can perform replications. Replication can be performed only by a database user that has appropriate permissions and only for a configured number of hosts. Although, by default, superusers have the necessary REPLICATION and LOGIN roles, as mentioned in Security , it is best not to provide the Debezium replication user with elevated privileges. Instead, create a Debezium user that has the minimum required privileges. Prerequisites PostgreSQL administrative permissions. Procedure To provide a user with replication permissions, define a PostgreSQL role that has at least the REPLICATION and LOGIN permissions, and then grant that role to the user. For example: CREATE ROLE <name> REPLICATION LOGIN; 2.6.5.3. Setting privileges to enable Debezium to create PostgreSQL publications Debezium streams change events for PostgreSQL source tables from publications that are created for the tables. Publications contain a filtered set of change events that are generated from one or more tables. The data in each publication is filtered based on the publication specification. The specification can be created by the PostgreSQL database administrator or by the Debezium connector. To permit the Debezium PostgreSQL connector to create publications and specify the data to replicate to them, the connector must operate with specific privileges in the database. There are several options for determining how publications are created. In general, it is best to manually create publications for the tables that you want to capture, before you set up the connector. However, you can configure your environment in a way that permits Debezium to create publications automatically, and to specify the data that is added to them. Debezium uses include list and exclude list properties to specify how data is inserted in the publication. For more information about the options for enabling Debezium to create publications, see publication.autocreate.mode . For Debezium to create a PostgreSQL publication, it must run as a user that has the following privileges: Replication privileges in the database to add the table to a publication. CREATE privileges on the database to add publications. SELECT privileges on the tables to copy the initial table data. Table owners automatically have SELECT permission for the table. To add tables to a publication, the user must be an owner of the table. But because the source table already exists, you need a mechanism to share ownership with the original owner. To enable shared ownership, you create a PostgreSQL replication group, and then add the existing table owner and the replication user to the group. Procedure Create a replication group. CREATE ROLE <replication_group> ; Add the original owner of the table to the group. GRANT REPLICATION_GROUP TO <original_owner> ; Add the Debezium replication user to the group. GRANT REPLICATION_GROUP TO <replication_user> ; Transfer ownership of the table to <replication_group> . ALTER TABLE <table_name> OWNER TO REPLICATION_GROUP; For Debezium to specify the capture configuration, the value of publication.autocreate.mode must be set to filtered . 2.6.5.4. Configuring PostgreSQL to allow replication with the Debezium connector host To enable Debezium to replicate PostgreSQL data, you must configure the database to permit replication with the host that runs the PostgreSQL connector. To specify the clients that are permitted to replicate with the database, add entries to the PostgreSQL host-based authentication file, pg_hba.conf . For more information about the pg_hba.conf file, see the PostgreSQL documentation. Procedure Add entries to the pg_hba.conf file to specify the Debezium connector hosts that can replicate with the database host. For example, pg_hba.conf file example: Table 2.152. Descriptions of pg_hba.conf settings Item Description 1 Instructs the server to allow replication for <youruser> locally, that is, on the server machine. 2 Instructs the server to allow <youruser> on localhost to receive replication changes using IPV4 . 3 Instructs the server to allow <youruser> on localhost to receive replication changes using IPV6 . Note For more information about network masks, see the PostgreSQL documentation . 2.6.5.5. Configuring PostgreSQL to manage Debezium WAL disk space consumption In certain cases, it is possible for PostgreSQL disk space consumed by WAL files to spike or increase out of usual proportions. There are several possible reasons for this situation: The LSN up to which the connector has received data is available in the confirmed_flush_lsn column of the server's pg_replication_slots view. Data that is older than this LSN is no longer available, and the database is responsible for reclaiming the disk space. Also in the pg_replication_slots view, the restart_lsn column contains the LSN of the oldest WAL that the connector might require. If the value for confirmed_flush_lsn is regularly increasing and the value of restart_lsn lags then the database needs to reclaim the space. The database typically reclaims disk space in batch blocks. This is expected behavior and no action by a user is necessary. There are many updates in a database that is being tracked but only a tiny number of updates are related to the table(s) and schema(s) for which the connector is capturing changes. This situation can be easily solved with periodic heartbeat events. Set the heartbeat.interval.ms connector configuration property. Note For the connector to detect and process events from a heartbeat table, you must add the table to the PostgreSQL publication specified by the publication.name property. If this publication predates your Debezium deployment, the connector uses the publications as defined. If the publication is not already configured to automatically replicate changes FOR ALL TABLES in the database, you must explicitly add the heartbeat table to the publication, for example, ALTER PUBLICATION <publicationName> ADD TABLE <heartbeatTableName> ; The PostgreSQL instance contains multiple databases and one of them is a high-traffic database. Debezium captures changes in another database that is low-traffic in comparison to the other database. Debezium then cannot confirm the LSN as replication slots work per-database and Debezium is not invoked. As WAL is shared by all databases, the amount used tends to grow until an event is emitted by the database for which Debezium is capturing changes. To overcome this, it is necessary to: Enable periodic heartbeat record generation with the heartbeat.interval.ms connector configuration property. Regularly emit change events from the database for which Debezium is capturing changes. A separate process would then periodically update the table by either inserting a new row or repeatedly updating the same row. PostgreSQL then invokes Debezium, which confirms the latest LSN and allows the database to reclaim the WAL space. This task can be automated by means of the heartbeat.action.query connector configuration property. Setting up multiple connectors for same database server Debezium uses replication slots to stream changes from a database. These replication slots maintain the current position in form of a LSN (Log Sequence Number) which is pointer to a location in the WAL being consumed by the Debezium connector. This helps PostgreSQL keep the WAL available until it is processed by Debezium. A single replication slot can exist only for a single consumer or process - as different consumer might have different state and may need data from different position. Since a replication slot can only be used by a single connector, it is essential to create a unique replication slot for each Debezium connector. Although when a connector is not active, Postgres may allow other connector to consume the replication slot - which could be dangerous as it may lead to data loss as a slot will emit each change just once [ See More ]. In addition to replication slot, Debezium uses publication to stream events when using the pgoutput plugin. Similar to replication slot, publication is at database level and is defined for a set of tables. Thus, you'll need a unique publication for each connector, unless the connectors work on same set of tables. For more information about the options for enabling Debezium to create publications, see publication.autocreate.mode See slot.name and publication.name on how to set a unique replication slot name and publication name for each connector. 2.6.5.6. Upgrading PostgreSQL databases that Debezium captures from When you upgrade the PostgreSQL database that Debezium uses, you must take specific steps to protect against data loss and to ensure that Debezium continues to operate. In general, Debezium is resilient to interruptions caused by network failures and other outages. For example, when a database server that a connector monitors stops or crashes, after the connector re-establishes communication with the PostgreSQL server, it continues to read from the last position recorded by the log sequence number (LSN) offset. The connector retrieves information about the last recorded offset from the Kafka Connect offsets topic, and queries the configured PostgreSQL replication slot for a log sequence number (LSN) with the same value. For the connector to start and to capture change events from a PostgreSQL database, a replication slot must be present. However, as part of the PostgreSQL upgrade process, replication slots are removed, and the original slots are not restored after the upgrade completes. As a result, when the connector restarts and requests the last known offset from the replication slot, PostgreSQL cannot return the information. You can create a new replication slot, but you must do more than create a new slot to guard against data loss. A new replication slot can provide the LSNs only for changes the occur after you create the slot; it cannot provide the offsets for events that occurred before the upgrade. When the connector restarts, it first requests the last known offset from the Kafka offsets topic. It then sends a request to the replication slot to return information for the offset retrieved from the offsets topic. But the new replication slot cannot provide the information that the connector needs to resume streaming from the expected position. The connector then skips any existing change events in the log, and only resumes streaming from the most recent position in the log. This can lead to silent data loss: the connector emits no records for the skipped events, and it does not provide any information to indicate that events were skipped. For guidance about how to perform a PostgreSQL database upgrade so that Debezium can continue to capture events while minimizing the risk of data loss, see the following procedure. Procedure Temporarily stop applications that write to the database, or put them into a read-only mode. Back up the database. Temporarily disable write access to the database. Verify that any changes that occurred in the database before you blocked write operations are saved to the write-ahead log (WAL), and that the WAL LSN is reflected on the replication slot. Provide the connector with enough time to capture all event records that are written to the replication slot. This step ensures that all change events that occurred before the downtime are accounted for, and that they are saved to Kafka. Verify that the connector has finished consuming entries from the replication slot by checking the value of the flushed LSN. Shut down the connector gracefully by stopping Kafka Connect. Kafka Connect stops the connectors, flushes all event records to Kafka, and records the last offset received from each connector. Note As an alternative to stopping the entire Kafka Connect cluster, you can stop the connector by deleting it. Do not remove the offset topic, because it might be shared by other Kafka connectors. Later, after you restore write access to the database and you are ready to restart the connector, you must recreate the connector. As a PostgreSQL administrator, drop the replication slot on the primary database server. Do not use the slot.drop.on.stop property to drop the replication slot. This property is for testing only. Stop the database. Perform the upgrade using an approved PostgreSQL upgrade procedure, such as pg_upgrade , or pg_dump and pg_restore . (Optional) Use a standard Kafka tool to remove the connector offsets from the offset storage topic. For an example of how to remove connector offsets, see how to remove connector offsets in the Debezium community FAQ. Restart the database. As a PostgreSQL administrator, create a Debezium logical replication slot on the database. You must create the slot before enabling writes to the database. Otherwise, Debezium cannot capture the changes, resulting in data loss. For information about setting up a replication slot, see Section 2.6.5.1, "Configuring a replication slot for the Debezium pgoutput plug-in" . Verify that the publication that defines the tables for Debezium to capture is still present after the upgrade. If the publication is not available, connect to the database as a PostgreSQL administrator to create a new publication. If it was necessary to create a new publication in the step, update the Debezium connector configuration to add the name of the new publication to the publication.name property. In the connector configuration, rename the connector. In the connector configuration, set slot.name to the name of the Debezium replication slot. Verify that the new replication slot is available. Restore write access to the database and restart any applications that write to the database. In the connector configuration, set the snapshot.mode property to never , and then restart the connector. Note If you were unable to verify that Debezium finished reading all database changes in Step 6, you can configure the connector to perform a new snapshot by setting snapshot.mode=initial . If necessary, you can confirm whether the connector read all changes from the replication slot by checking the contents of a database backup that was taken immediately before the upgrade. Additional resources Configuring replication slots for Debezium . 2.6.6. Deployment of Debezium PostgreSQL connectors You can use either of the following methods to deploy a Debezium PostgreSQL connector: Use Streams for Apache Kafka to automatically create an image that includes the connector plug-in . This is the preferred method. Build a custom Kafka Connect container image from a Dockerfile . Additional resources Section 2.6.6.5, "Descriptions of Debezium PostgreSQL connector configuration properties" 2.6.6.1. PostgreSQL connector deployment using Streams for Apache Kafka Beginning with Debezium 1.7, the preferred method for deploying a Debezium connector is to use Streams for Apache Kafka to build a Kafka Connect container image that includes the connector plug-in. During the deployment process, you create and use the following custom resources (CRs): A KafkaConnect CR that defines your Kafka Connect instance and includes information about the connector artifacts needs to include in the image. A KafkaConnector CR that provides details that include information the connector uses to access the source database. After Streams for Apache Kafka starts the Kafka Connect pod, you start the connector by applying the KafkaConnector CR. In the build specification for the Kafka Connect image, you can specify the connectors that are available to deploy. For each connector plug-in, you can also specify other components that you want to make available for deployment. For example, you can add Apicurio Registry artifacts, or the Debezium scripting component. When Streams for Apache Kafka builds the Kafka Connect image, it downloads the specified artifacts, and incorporates them into the image. The spec.build.output parameter in the KafkaConnect CR specifies where to store the resulting Kafka Connect container image. Container images can be stored in a Docker registry, or in an OpenShift ImageStream. To store images in an ImageStream, you must create the ImageStream before you deploy Kafka Connect. ImageStreams are not created automatically. Note If you use a KafkaConnect resource to create a cluster, afterwards you cannot use the Kafka Connect REST API to create or update connectors. You can still use the REST API to retrieve information. Additional resources Configuring Kafka Connect in Deploying and Managing Streams for Apache Kafka on OpenShift. Building a new container image automatically in Deploying and Managing Streams for Apache Kafka on OpenShift. 2.6.6.2. Using Streams for Apache Kafka to deploy a Debezium PostgreSQL connector With earlier versions of Streams for Apache Kafka, to deploy Debezium connectors on OpenShift, you were required to first build a Kafka Connect image for the connector. The current preferred method for deploying connectors on OpenShift is to use a build configuration in Streams for Apache Kafka to automatically build a Kafka Connect container image that includes the Debezium connector plug-ins that you want to use. During the build process, the Streams for Apache Kafka Operator transforms input parameters in a KafkaConnect custom resource, including Debezium connector definitions, into a Kafka Connect container image. The build downloads the necessary artifacts from the Red Hat Maven repository or another configured HTTP server. The newly created container is pushed to the container registry that is specified in .spec.build.output , and is used to deploy a Kafka Connect cluster. After Streams for Apache Kafka builds the Kafka Connect image, you create KafkaConnector custom resources to start the connectors that are included in the build. Prerequisites You have access to an OpenShift cluster on which the cluster Operator is installed. The Streams for Apache Kafka Operator is running. An Apache Kafka cluster is deployed as documented in Deploying and Managing Streams for Apache Kafka on OpenShift . Kafka Connect is deployed on Streams for Apache Kafka You have a Red Hat build of Debezium license. The OpenShift oc CLI client is installed or you have access to the OpenShift Container Platform web console. Depending on how you intend to store the Kafka Connect build image, you need registry permissions or you must create an ImageStream resource: To store the build image in an image registry, such as Red Hat Quay.io or Docker Hub An account and permissions to create and manage images in the registry. To store the build image as a native OpenShift ImageStream An ImageStream resource is deployed to the cluster for storing new container images. You must explicitly create an ImageStream for the cluster. ImageStreams are not available by default. For more information about ImageStreams, see Managing image streams on OpenShift Container Platform . Procedure Log in to the OpenShift cluster. Create a Debezium KafkaConnect custom resource (CR) for the connector, or modify an existing one. For example, create a KafkaConnect CR with the name dbz-connect.yaml that specifies the metadata.annotations and spec.build properties. The following example shows an excerpt from a dbz-connect.yaml file that describes a KafkaConnect custom resource. Example 2.42. A dbz-connect.yaml file that defines a KafkaConnect custom resource that includes a Debezium connector In the example that follows, the custom resource is configured to download the following artifacts: The Debezium PostgreSQL connector archive. The Red Hat build of Apicurio Registry archive. The Apicurio Registry is an optional component. Add the Apicurio Registry component only if you intend to use Avro serialization with the connector. The Debezium scripting SMT archive and the associated scripting engine that you want to use with the Debezium connector. The SMT archive and scripting language dependencies are optional components. Add these components only if you intend to use the Debezium content-based routing SMT or filter SMT . apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: debezium-kafka-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: version: 3.6.0 build: 2 output: 3 type: imagestream 4 image: debezium-streams-connect:latest plugins: 5 - name: debezium-connector-postgres artifacts: - type: zip 6 url: https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-postgres/2.7.3.Final-redhat-00001/debezium-connector-postgres-2.7.3.Final-redhat-00001-plugin.zip 7 - type: zip url: https://maven.repository.redhat.com/ga/io/apicurio/apicurio-registry-distro-connect-converter/2.4.4.Final-redhat- <build-number> /apicurio-registry-distro-connect-converter-2.4.4.Final-redhat- <build-number> .zip 8 - type: zip url: https://maven.repository.redhat.com/ga/io/debezium/debezium-scripting/2.7.3.Final-redhat-00001/debezium-scripting-2.7.3.Final-redhat-00001.zip 9 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy/3.0.11/groovy-3.0.11.jar 10 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-jsr223/3.0.11/groovy-jsr223-3.0.11.jar - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-json3.0.11/groovy-json-3.0.11.jar bootstrapServers: debezium-kafka-cluster-kafka-bootstrap:9093 ... Table 2.153. Descriptions of Kafka Connect configuration settings Item Description 1 Sets the strimzi.io/use-connector-resources annotation to "true" to enable the Cluster Operator to use KafkaConnector resources to configure connectors in this Kafka Connect cluster. 2 The spec.build configuration specifies where to store the build image and lists the plug-ins to include in the image, along with the location of the plug-in artifacts. 3 The build.output specifies the registry in which the newly built image is stored. 4 Specifies the name and image name for the image output. Valid values for output.type are docker to push into a container registry such as Docker Hub or Quay, or imagestream to push the image to an internal OpenShift ImageStream. To use an ImageStream, an ImageStream resource must be deployed to the cluster. For more information about specifying the build.output in the KafkaConnect configuration, see the Streams for Apache Kafka Build schema reference in {NameConfiguringStreamsOpenShift}. 5 The plugins configuration lists all of the connectors that you want to include in the Kafka Connect image. For each entry in the list, specify a plug-in name , and information for about the artifacts that are required to build the connector. Optionally, for each connector plug-in, you can include other components that you want to be available for use with the connector. For example, you can add Service Registry artifacts, or the Debezium scripting component. 6 The value of artifacts.type specifies the file type of the artifact specified in the artifacts.url . Valid types are zip , tgz , or jar . Debezium connector archives are provided in .zip file format. The type value must match the type of the file that is referenced in the url field. 7 The value of artifacts.url specifies the address of an HTTP server, such as a Maven repository, that stores the file for the connector artifact. Debezium connector artifacts are available in the Red Hat Maven repository. The OpenShift cluster must have access to the specified server. 8 (Optional) Specifies the artifact type and url for downloading the Apicurio Registry component. Include the Apicurio Registry artifact, only if you want the connector to use Apache Avro to serialize event keys and values with the Red Hat build of Apicurio Registry, instead of using the default JSON converter. 9 (Optional) Specifies the artifact type and url for the Debezium scripting SMT archive to use with the Debezium connector. Include the scripting SMT only if you intend to use the Debezium content-based routing SMT or filter SMT To use the scripting SMT, you must also deploy a JSR 223-compliant scripting implementation, such as groovy. 10 (Optional) Specifies the artifact type and url for the JAR files of a JSR 223-compliant scripting implementation, which is required by the Debezium scripting SMT. Important If you use Streams for Apache Kafka to incorporate the connector plug-in into your Kafka Connect image, for each of the required scripting language components artifacts.url must specify the location of a JAR file, and the value of artifacts.type must also be set to jar . Invalid values cause the connector fails at runtime. To enable use of the Apache Groovy language with the scripting SMT, the custom resource in the example retrieves JAR files for the following libraries: groovy groovy-jsr223 (scripting agent) groovy-json (module for parsing JSON strings) As an alternative, the Debezium scripting SMT also supports the use of the JSR 223 implementation of GraalVM JavaScript. Apply the KafkaConnect build specification to the OpenShift cluster by entering the following command: oc create -f dbz-connect.yaml Based on the configuration specified in the custom resource, the Streams Operator prepares a Kafka Connect image to deploy. After the build completes, the Operator pushes the image to the specified registry or ImageStream, and starts the Kafka Connect cluster. The connector artifacts that you listed in the configuration are available in the cluster. Create a KafkaConnector resource to define an instance of each connector that you want to deploy. For example, create the following KafkaConnector CR, and save it as postgresql-inventory-connector.yaml Example 2.43. postgresql-inventory-connector.yaml file that defines the KafkaConnector custom resource for a Debezium connector apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: labels: strimzi.io/cluster: debezium-kafka-connect-cluster name: inventory-connector-postgresql 1 spec: class: io.debezium.connector.postgresql.PostgresConnector 2 tasksMax: 1 3 config: 4 database.hostname: postgresql.debezium-postgresql.svc.cluster.local 5 database.port: 5432 6 database.user: debezium 7 database.password: dbz 8 database.dbname: mydatabase 9 topic.prefix: inventory-connector-postgresql 10 table.include.list: public.inventory 11 ... Table 2.154. Descriptions of connector configuration settings Item Description 1 The name of the connector to register with the Kafka Connect cluster. 2 The name of the connector class. 3 The number of tasks that can operate concurrently. 4 The connector's configuration. 5 The address of the host database instance. 6 The port number of the database instance. 7 The name of the account that Debezium uses to connect to the database. 8 The password that Debezium uses to connect to the database user account. 9 The name of the database to capture changes from. 10 The topic prefix for the database instance or cluster. The specified name must be formed only from alphanumeric characters or underscores. Because the topic prefix is used as the prefix for any Kafka topics that receive change events from this connector, the name must be unique among the connectors in the cluster. This namespace is also used in the names of related Kafka Connect schemas, and the namespaces of a corresponding Avro schema if you integrate the connector with the Avro connector . 11 The list of tables from which the connector captures change events. Create the connector resource by running the following command: oc create -n <namespace> -f <kafkaConnector> .yaml For example, oc create -n debezium -f postgresql-inventory-connector.yaml The connector is registered to the Kafka Connect cluster and starts to run against the database that is specified by spec.config.database.dbname in the KafkaConnector CR. After the connector pod is ready, Debezium is running. You are now ready to verify the Debezium PostgreSQL deployment . 2.6.6.3. Deploying a Debezium PostgreSQL connector by building a custom Kafka Connect container image from a Dockerfile To deploy a Debezium PostgreSQL connector, you need to build a custom Kafka Connect container image that contains the Debezium connector archive and push this container image to a container registry. You then need to create two custom resources (CRs): A KafkaConnect CR that defines your Kafka Connect instance. The image property in the CR specifies the name of the container image that you create to run your Debezium connector. You apply this CR to the OpenShift instance where Red Hat Streams for Apache Kafka is deployed. Streams for Apache Kafka offers operators and images that bring Apache Kafka to OpenShift. A KafkaConnector CR that defines your Debezium PostgreSQL connector. Apply this CR to the same OpenShift instance where you applied the KafkaConnect CR. Prerequisites PostgreSQL is running and you performed the steps to set up PostgreSQL to run a Debezium connector . Streams for Apache Kafka is deployed on OpenShift and is running Apache Kafka and Kafka Connect. For more information, see Deploying and Managing Streams for Apache Kafka on OpenShift . Podman or Docker is installed. You have an account and permissions to create and manage containers in the container registry (such as quay.io or docker.io ) to which you plan to add the container that will run your Debezium connector. Procedure Create the Debezium PostgreSQL container for Kafka Connect: Create a Dockerfile that uses registry.redhat.io/amq-streams-kafka-35-rhel8:2.5.0 as the base image. For example, from a terminal window, enter the following command: cat <<EOF >debezium-container-for-postgresql.yaml 1 FROM registry.redhat.io/amq-streams-kafka-35-rhel8:2.5.0 USER root:root RUN mkdir -p /opt/kafka/plugins/debezium 2 RUN cd /opt/kafka/plugins/debezium/ \ && curl -O https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-postgres/2.7.3.Final-redhat-00001/debezium-connector-postgres-2.7.3.Final-redhat-00001-plugin.zip \ && unzip debezium-connector-postgres-2.7.3.Final-redhat-00001-plugin.zip \ && rm debezium-connector-postgres-2.7.3.Final-redhat-00001-plugin.zip RUN cd /opt/kafka/plugins/debezium/ USER 1001 EOF Item Description 1 You can specify any file name that you want. 2 Specifies the path to your Kafka Connect plug-ins directory. If your Kafka Connect plug-ins directory is in a different location, replace this path with the actual path of your directory. The command creates a Dockerfile with the name debezium-container-for-postgresql.yaml in the current directory. Build the container image from the debezium-container-for-postgresql.yaml Docker file that you created in the step. From the directory that contains the file, open a terminal window and enter one of the following commands: podman build -t debezium-container-for-postgresql:latest . docker build -t debezium-container-for-postgresql:latest . The build command builds a container image with the name debezium-container-for-postgresql . Push your custom image to a container registry such as quay.io or an internal container registry. The container registry must be available to the OpenShift instance where you want to deploy the image. Enter one of the following commands: podman push <myregistry.io> /debezium-container-for-postgresql:latest docker push <myregistry.io> /debezium-container-for-postgresql:latest Create a new Debezium PostgreSQL KafkaConnect custom resource (CR). For example, create a KafkaConnect CR with the name dbz-connect.yaml that specifies annotations and image properties. The following example shows an excerpt from a dbz-connect.yaml file that describes a KafkaConnect custom resource. apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: image: debezium-container-for-postgresql 2 ... Item Description 1 metadata.annotations indicates to the Cluster Operator that KafkaConnector resources are used to configure connectors in this Kafka Connect cluster. 2 spec.image specifies the name of the image that you created to run your Debezium connector. This property overrides the STRIMZI_DEFAULT_KAFKA_CONNECT_IMAGE variable in the Cluster Operator. Apply your KafkaConnect CR to the OpenShift Kafka instance by running the following command: oc create -f dbz-connect.yaml This updates your Kafka Connect environment in OpenShift to add a Kafka Connector instance that specifies the name of the image that you created to run your Debezium connector. Create a KafkaConnector custom resource that configures your Debezium PostgreSQL connector instance. You configure a Debezium PostgreSQL connector in a .yaml file that specifies the configuration properties for the connector. The connector configuration might instruct Debezium to produce events for a subset of the schemas and tables, or it might set properties so that Debezium ignores, masks, or truncates values in specified columns that are sensitive, too large, or not needed. For the complete list of the configuration properties that you can set for the Debezium PostgreSQL connector, see PostgreSQL connector properties . The following example shows an excerpt from a custom resource that configures a Debezium connector that connects to a PostgreSQL server host, 192.168.99.100 , on port 5432 . This host has a database named sampledb , a schema named public , and inventory-connector-postgresql is the server's logical name. PostgreSQL inventory-connector.yaml apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: inventory-connector-postgresql 1 labels: strimzi.io/cluster: my-connect-cluster spec: class: io.debezium.connector.postgresql.PostgresConnector tasksMax: 1 2 config: 3 database.hostname: 192.168.99.100 4 database.port: 5432 database.user: debezium database.password: dbz database.dbname: sampledb topic.prefix: inventory-connector-postgresql 5 schema.include.list: public 6 plugin.name: pgoutput 7 ... Table 2.155. Descriptions of settings in the PostgreSQL inventory-connector.yaml example Item Description 1 The name that is used to register the connector with Kafka Connect. 2 The maximum number of tasks to create for this connector. Because the PostgreSQL connector uses a single connector task read the PostgreSQL server binlog , to ensure proper order and event handling, only one task should operate at a time. The Kafka Connect service uses connectors to start one or more tasks to perform the work, and it automatically distributes the running tasks across the cluster of Kafka Connect services. If any services stop or crash, tasks are redistributed to running services. 3 The connector's configuration. 4 The name of the database host that runs the PostgreSQL server. In this example, the database host name is 192.168.99.100 . 5 A unique topic prefix. The topic prefix is the logical identifier for the PostgreSQL server or cluster of servers. This string is prefixed to the names of all Kafka topics that receive change event records from the connector. 6 The connector captures changes in only the public schema. It is possible to configure the connector to capture changes in only the tables that you choose. For more information, see table.include.list . 7 The name of the PostgreSQL logical decoding plug-in installed on the PostgreSQL server. Although the connector only supports use of the pgoutput plugin, you must explicitly set plugin.name to pgoutput . Create your connector instance with Kafka Connect. For example, if you saved your KafkaConnector resource in the inventory-connector.yaml file, you would run the following command: oc apply -f inventory-connector.yaml This registers inventory-connector and the connector starts to run against the sampledb database as defined in the KafkaConnector CR. Results After the connector starts, it performs a consistent snapshot of the PostgreSQL server databases that the connector is configured for. The connector then starts generating data change events for row-level operations and streaming change event records to Kafka topics. 2.6.6.4. Verifying that the Debezium PostgreSQL connector is running If the connector starts correctly without errors, it creates a topic for each table that the connector is configured to capture. Downstream applications can subscribe to these topics to retrieve information events that occur in the source database. To verify that the connector is running, you perform the following operations from the OpenShift Container Platform web console, or through the OpenShift CLI tool (oc): Verify the connector status. Verify that the connector generates topics. Verify that topics are populated with events for read operations ("op":"r") that the connector generates during the initial snapshot of each table. Prerequisites A Debezium connector is deployed to Streams for Apache Kafka on OpenShift. The OpenShift oc CLI client is installed. You have access to the OpenShift Container Platform web console. Procedure Check the status of the KafkaConnector resource by using one of the following methods: From the OpenShift Container Platform web console: Navigate to Home Search . On the Search page, click Resources to open the Select Resource box, and then type KafkaConnector . From the KafkaConnectors list, click the name of the connector that you want to check, for example inventory-connector-postgresql . In the Conditions section, verify that the values in the Type and Status columns are set to Ready and True . From a terminal window: Enter the following command: oc describe KafkaConnector <connector-name> -n <project> For example, oc describe KafkaConnector inventory-connector-postgresql -n debezium The command returns status information that is similar to the following output: Example 2.44. KafkaConnector resource status Name: inventory-connector-postgresql Namespace: debezium Labels: strimzi.io/cluster=debezium-kafka-connect-cluster Annotations: <none> API Version: kafka.strimzi.io/v1beta2 Kind: KafkaConnector ... Status: Conditions: Last Transition Time: 2021-12-08T17:41:34.897153Z Status: True Type: Ready Connector Status: Connector: State: RUNNING worker_id: 10.131.1.124:8083 Name: inventory-connector-postgresql Tasks: Id: 0 State: RUNNING worker_id: 10.131.1.124:8083 Type: source Observed Generation: 1 Tasks Max: 1 Topics: inventory-connector-postgresql.inventory inventory-connector-postgresql.inventory.addresses inventory-connector-postgresql.inventory.customers inventory-connector-postgresql.inventory.geom inventory-connector-postgresql.inventory.orders inventory-connector-postgresql.inventory.products inventory-connector-postgresql.inventory.products_on_hand Events: <none> Verify that the connector created Kafka topics: From the OpenShift Container Platform web console. Navigate to Home Search . On the Search page, click Resources to open the Select Resource box, and then type KafkaTopic . From the KafkaTopics list, click the name of the topic that you want to check, for example, inventory-connector-postgresql.inventory.orders---ac5e98ac6a5d91e04d8ec0dc9078a1ece439081d . In the Conditions section, verify that the values in the Type and Status columns are set to Ready and True . From a terminal window: Enter the following command: oc get kafkatopics The command returns status information that is similar to the following output: Example 2.45. KafkaTopic resource status Check topic content. From a terminal window, enter the following command: oc exec -n <project> -it <kafka-cluster> -- /opt/kafka/bin/kafka-console-consumer.sh \ > --bootstrap-server localhost:9092 \ > --from-beginning \ > --property print.key=true \ > --topic= <topic-name > For example, oc exec -n debezium -it debezium-kafka-cluster-kafka-0 -- /opt/kafka/bin/kafka-console-consumer.sh \ > --bootstrap-server localhost:9092 \ > --from-beginning \ > --property print.key=true \ > --topic=inventory-connector-postgresql.inventory.products_on_hand The format for specifying the topic name is the same as the oc describe command returns in Step 1, for example, inventory-connector-postgresql.inventory.addresses . For each event in the topic, the command returns information that is similar to the following output: Example 2.46. Content of a Debezium change event In the preceding example, the payload value shows that the connector snapshot generated a read ( "op" ="r" ) event from the table inventory.products_on_hand . The "before" state of the product_id record is null , indicating that no value exists for the record. The "after" state shows a quantity of 3 for the item with product_id 101 . 2.6.6.5. Descriptions of Debezium PostgreSQL connector configuration properties The Debezium PostgreSQL connector has many configuration properties that you can use to achieve the right connector behavior for your application. Many properties have default values. Information about the properties is organized as follows: Required configuration properties Advanced configuration properties Pass-through PostgreSQL connector configuration properties Pass-through Kafka signals configuration properties Pass-through Kafka signals consumer client configuration properties Pass-through sink notification configuration properties Pass-through database driver configuration properties Required Debezium PostgreSQL connector configuration properties The following configuration properties are required unless a default value is available. Table 2.156. Required connector configuration properties Property Default Description name No default Unique name for the connector. Attempting to register again with the same name will fail. This property is required by all Kafka Connect connectors. connector.class No default The name of the Java class for the connector. Always use a value of io.debezium.connector.postgresql.PostgresConnector for the PostgreSQL connector. tasks.max 1 The maximum number of tasks that should be created for this connector. The PostgreSQL connector always uses a single task and therefore does not use this value, so the default is always acceptable. plugin.name decoderbufs The name of the PostgreSQL logical decoding plug-in installed on the PostgreSQL server. The only supported value is pgoutput . You must explicitly set plugin.name to pgoutput . slot.name debezium The name of the PostgreSQL logical decoding slot that was created for streaming changes from a particular plug-in for a particular database/schema. The server uses this slot to stream events to the Debezium connector that you are configuring. Slot names must conform to PostgreSQL replication slot naming rules , which state: "Each replication slot has a name, which can contain lower-case letters, numbers, and the underscore character." slot.drop.on.stop false Whether or not to delete the logical replication slot when the connector stops in a graceful, expected way. The default behavior is that the replication slot remains configured for the connector when the connector stops. When the connector restarts, having the same replication slot enables the connector to start processing where it left off. Set to true in only testing or development environments. Dropping the slot allows the database to discard WAL segments. When the connector restarts it performs a new snapshot or it can continue from a persistent offset in the Kafka Connect offsets topic. publication.name dbz_publication The name of the PostgreSQL publication created for streaming changes when using pgoutput . This publication is created at start-up if it does not already exist and it includes all tables . Debezium then applies its own include/exclude list filtering, if configured, to limit the publication to change events for the specific tables of interest. The connector user must have superuser permissions to create this publication, so it is usually preferable to create the publication before starting the connector for the first time. If the publication already exists, either for all tables or configured with a subset of tables, Debezium uses the publication as it is defined. database.hostname No default IP address or hostname of the PostgreSQL database server. database.port 5432 Integer port number of the PostgreSQL database server. database.user No default Name of the PostgreSQL database user for connecting to the PostgreSQL database server. database.password No default Password to use when connecting to the PostgreSQL database server. database.dbname No default The name of the PostgreSQL database from which to stream the changes. topic.prefix No default Topic prefix that provides a namespace for the particular PostgreSQL database server or cluster in which Debezium is capturing changes. The prefix should be unique across all other connectors, since it is used as a topic name prefix for all Kafka topics that receive records from this connector. Only alphanumeric characters, hyphens, dots and underscores must be used in the database server logical name. Warning Do not change the value of this property. If you change the name value, after a restart, instead of continuing to emit events to the original topics, the connector emits subsequent events to topics whose names are based on the new value. schema.include.list No default An optional, comma-separated list of regular expressions that match names of schemas for which you want to capture changes. Any schema name not included in schema.include.list is excluded from having its changes captured. By default, all non-system schemas have their changes captured. To match the name of a schema, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire identifier for the schema; it does not match substrings that might be present in a schema name. If you include this property in the configuration, do not also set the schema.exclude.list property. schema.exclude.list No default An optional, comma-separated list of regular expressions that match names of schemas for which you do not want to capture changes. Any schema whose name is not included in schema.exclude.list has its changes captured, with the exception of system schemas. To match the name of a schema, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire identifier for the schema; it does not match substrings that might be present in a schema name. If you include this property in the configuration, do not set the schema.include.list property. table.include.list No default An optional, comma-separated list of regular expressions that match fully-qualified table identifiers for tables whose changes you want to capture. When this property is set, the connector captures changes only from the specified tables. Each identifier is of the form schemaName . tableName . By default, the connector captures changes in every non-system table in each schema whose changes are being captured. To match the name of a table, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire identifier for the table; it does not match substrings that might be present in a table name. If you include this property in the configuration, do not also set the table.exclude.list property. table.exclude.list No default An optional, comma-separated list of regular expressions that match fully-qualified table identifiers for tables whose changes you do not want to capture. Each identifier is of the form schemaName . tableName . When this property is set, the connector captures changes from every table that you do not specify. To match the name of a table, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire identifier for the table; it does not match substrings that might be present in a table name. If you include this property in the configuration, do not set the table.include.list property. column.include.list No default An optional, comma-separated list of regular expressions that match the fully-qualified names of columns that should be included in change event record values. Fully-qualified names for columns are of the form schemaName . tableName . columnName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the expression is used to match the entire name string of the column; it does not match substrings that might be present in a column name. If you include this property in the configuration, do not also set the column.exclude.list property. column.exclude.list No default An optional, comma-separated list of regular expressions that match the fully-qualified names of columns that should be excluded from change event record values. Fully-qualified names for columns are of the form schemaName . tableName . columnName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the expression is used to match the entire name string of the column; it does not match substrings that might be present in a column name. If you include this property in the configuration, do not set the column.include.list property. skip.messages.without.change false Specifies whether to skip publishing messages when there is no change in included columns. This would essentially filter messages if there is no change in columns included as per column.include.list or column.exclude.list properties. Note: Only works when REPLICA IDENTITY of the table is set to FULL time.precision.mode adaptive Time, date, and timestamps can be represented with different kinds of precision: adaptive captures the time and timestamp values exactly as in the database using either millisecond, microsecond, or nanosecond precision values based on the database column's type. adaptive_time_microseconds captures the date, datetime and timestamp values exactly as in the database using either millisecond, microsecond, or nanosecond precision values based on the database column's type. An exception is TIME type fields, which are always captured as microseconds. connect always represents time and timestamp values by using Kafka Connect's built-in representations for Time , Date , and Timestamp , which use millisecond precision regardless of the database columns' precision. For more information, see temporal values . decimal.handling.mode precise Specifies how the connector should handle values for DECIMAL and NUMERIC columns: precise represents values by using java.math.BigDecimal to represent values in binary form in change events. double represents values by using double values, which might result in a loss of precision but which is easier to use. string encodes values as formatted strings, which are easy to consume but semantic information about the real type is lost. For more information, see Decimal types . hstore.handling.mode json Specifies how the connector should handle values for hstore columns: map represents values by using MAP . json represents values by using json string . This setting encodes values as formatted strings such as {"key" : "val"} . For more information, see PostgreSQL HSTORE type . interval.handling.mode numeric Specifies how the connector should handle values for interval columns: numeric represents intervals using approximate number of microseconds. string represents intervals exactly by using the string pattern representation P<years>Y<months>M<days>DT<hours>H<minutes>M<seconds>S . For example: P1Y2M3DT4H5M6.78S . For more information, see PostgreSQL basic types . database.sslmode prefer Whether to use an encrypted connection to the PostgreSQL server. Options include: disable uses an unencrypted connection. allow attempts to use an unencrypted connection first and, failing that, a secure (encrypted) connection. prefer attempts to use a secure (encrypted) connection first and, failing that, an unencrypted connection. require uses a secure (encrypted) connection, and fails if one cannot be established. verify-ca behaves like require but also verifies the server TLS certificate against the configured Certificate Authority (CA) certificates, or fails if no valid matching CA certificates are found. verify-full behaves like verify-ca but also verifies that the server certificate matches the host to which the connector is trying to connect. For more information, see the PostgreSQL documentation . database.sslcert No default The path to the file that contains the SSL certificate for the client. For more information, see the PostgreSQL documentation . database.sslkey No default The path to the file that contains the SSL private key of the client. For more information, see the PostgreSQL documentation . database.sslpassword No default The password to access the client private key from the file specified by database.sslkey . For more information, see the PostgreSQL documentation . database.sslrootcert No default The path to the file that contains the root certificate(s) against which the server is validated. For more information, see the PostgreSQL documentation . database.tcpKeepAlive true Enable TCP keep-alive probe to verify that the database connection is still alive. For more information, see the PostgreSQL documentation . tombstones.on.delete true Controls whether a delete event is followed by a tombstone event. true - a delete operation is represented by a delete event and a subsequent tombstone event. false - only a delete event is emitted. After a source record is deleted, emitting a tombstone event (the default behavior) allows Kafka to completely delete all events that pertain to the key of the deleted row in case log compaction is enabled for the topic. column.truncate.to. length .chars n/a An optional, comma-separated list of regular expressions that match the fully-qualified names of character-based columns. Set this property if you want to truncate the data in a set of columns when it exceeds the number of characters specified by the length in the property name. Set length to a positive integer value, for example, column.truncate.to.20.chars . The fully-qualified name of a column observes the following format: <schemaName> . <tableName> . <columnName> . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. You can specify multiple properties with different lengths in a single configuration. column.mask.with. length .chars n/a An optional, comma-separated list of regular expressions that match the fully-qualified names of character-based columns. Set this property if you want the connector to mask the values for a set of columns, for example, if they contain sensitive data. Set length to a positive integer to replace data in the specified columns with the number of asterisk ( * ) characters specified by the length in the property name. Set length to 0 (zero) to replace data in the specified columns with an empty string. The fully-qualified name of a column observes the following format: schemaName . tableName . columnName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. You can specify multiple properties with different lengths in a single configuration. column.mask.hash. hashAlgorithm .with.salt. salt ; column.mask.hash.v2. hashAlgorithm .with.salt. salt n/a An optional, comma-separated list of regular expressions that match the fully-qualified names of character-based columns. Fully-qualified names for columns are of the form <schemaName> . <tableName> . <columnName> . To match the name of a column Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. In the resulting change event record, the values for the specified columns are replaced with pseudonyms. A pseudonym consists of the hashed value that results from applying the specified hashAlgorithm and salt . Based on the hash function that is used, referential integrity is maintained, while column values are replaced with pseudonyms. Supported hash functions are described in the MessageDigest section of the Java Cryptography Architecture Standard Algorithm Name Documentation. In the following example, CzQMA0cB5K is a randomly selected salt. If necessary, the pseudonym is automatically shortened to the length of the column. The connector configuration can include multiple properties that specify different hash algorithms and salts. Depending on the hashAlgorithm used, the salt selected, and the actual data set, the resulting data set might not be completely masked. Hashing strategy version 2 should be used to ensure fidelity if the value is being hashed in different places or systems. column.propagate.source.type n/a An optional, comma-separated list of regular expressions that match the fully-qualified names of columns for which you want the connector to emit extra parameters that represent column metadata. When this property is set, the connector adds the following fields to the schema of event records: __debezium.source.column.type __debezium.source.column.length __debezium.source.column.scale These parameters propagate a column's original type name and length (for variable-width types), respectively. Enabling the connector to emit this extra data can assist in properly sizing specific numeric or character-based columns in sink databases. The fully-qualified name of a column observes one of the following formats: databaseName . tableName . columnName , or databaseName . schemaName . tableName . columnName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. datatype.propagate.source.type n/a An optional, comma-separated list of regular expressions that specify the fully-qualified names of data types that are defined for columns in a database. When this property is set, for columns with matching data types, the connector emits event records that include the following extra fields in their schema: __debezium.source.column.type __debezium.source.column.length __debezium.source.column.scale These parameters propagate a column's original type name and length (for variable-width types), respectively. Enabling the connector to emit this extra data can assist in properly sizing specific numeric or character-based columns in sink databases. The fully-qualified name of a column observes one of the following formats: databaseName . tableName . typeName , or databaseName . schemaName . tableName . typeName . To match the name of a data type, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the data type; the expression does not match substrings that might be present in a type name. For the list of PostgreSQL-specific data type names, see the PostgreSQL data type mappings . message.key.columns empty string A list of expressions that specify the columns that the connector uses to form custom message keys for change event records that it publishes to the Kafka topics for specified tables. By default, Debezium uses the primary key column of a table as the message key for records that it emits. In place of the default, or to specify a key for tables that lack a primary key, you can configure custom message keys based on one or more columns. To establish a custom message key for a table, list the table, followed by the columns to use as the message key. Each list entry takes the following format: <fully-qualified_tableName> : <keyColumn> , <keyColumn> To base a table key on multiple column names, insert commas between the column names. Each fully-qualified table name is a regular expression in the following format: <schemaName> . <tableName> The property can include entries for multiple tables. Use a semicolon to separate table entries in the list. The following example sets the message key for the tables inventory.customers and purchase.orders : inventory.customers:pk1,pk2;(.*).purchaseorders:pk3,pk4 For the table inventory.customer , the columns pk1 and pk2 are specified as the message key. For the purchaseorders tables in any schema, the columns pk3 and pk4 server as the message key. There is no limit to the number of columns that you use to create custom message keys. However, it's best to use the minimum number that are required to specify a unique key. Note that having this property set and REPLICA IDENTITY set to DEFAULT on the tables, will cause the tombstone events to not be created properly if the key columns are not part of the primary key of the table. Setting REPLICA IDENTITY to FULL is the only solution. publication.autocreate.mode all_tables Specifies whether and how the connector creates a publication . This setting applies only when the connector streams changes by using the pgoutput plug-in . Note To create publications, the connector must access PostgreSQL through a database account that has specific permissions. For more information, see Setting privileges to enable Debezium to create PostgreSQL publications . Specify one of the following values: all_tables If a publication exists, the connector uses it. If a publication does not exist, the connector creates a publication for all tables in the database from which the connector captures changes. The connector runs the following SQL command to create a publication: CREATE PUBLICATION < publication_name > FOR ALL TABLES; disabled The connector does not attempt to create a publication. A database administrator or the user configured to perform replications must have created the publication before running the connector. If the connector cannot find the publication, the connector throws an exception and stops. filtered If a publication does not exist, the connector creates one by running a SQL command in the following format: CREATE PUBLICATION < publication_name > FOR TABLE <tbl1, tbl2, tbl3> The resulting publication includes tables that match the current filter configuration, as specified by the schema.include.list , schema.exclude.list , table.include.list , and table.exclude.list connector configuration properties. If the publication exists, the connector updates the publication for tables that match the current filter configuration by running a SQL command in the following format: ALTER PUBLICATION < publication_name > SET TABLE <tbl1, tbl2, tbl3> . no_tables If a publication exists, the connector uses it. If a publication does not exist, the connector creates a publication without specifying any table by running a SQL command in the following format: CREATE PUBLICATION < publication_name >; Set the no_tables option if you want the connector to capture only logical decoding messages, and not capture any other change events, such as those caused by INSERT , UPDATE , and DELETE operations on any table. If you select this option, to prevent the connector from emitting and processing READ events, you can specify names of schemas or tables for which you do not want to capture changes, for example, by using "table.exclude.list": "public.*" or "schema.exclude.list": "public" . replica.identity.autoset.values empty string The setting determines the value for replica identity at table level. This option will overwrite the existing value in database. A comma-separated list of regular expressions that match fully-qualified tables and replica identity value to be used in the table. Each expression must match the pattern '<fully-qualified table name>:<replica identity>', where the table name could be defined as ( SCHEMA_NAME.TABLE_NAME ), and the replica identity values are: DEFAULT - Records the old values of the columns of the primary key, if any. This is the default for non-system tables. INDEX index_name - Records the old values of the columns covered by the named index, that must be unique, not partial, not deferrable, and include only columns marked NOT NULL. If this index is dropped, the behavior is the same as NOTHING. FULL - Records the old values of all columns in the row. NOTHING - Records no information about the old row. This is the default for system tables. For example, binary.handling.mode bytes Specifies how binary ( bytea ) columns should be represented in change events: bytes represents binary data as byte array. base64 represents binary data as base64-encoded strings. base64-url-safe represents binary data as base64-url-safe-encoded strings. hex represents binary data as hex-encoded (base16) strings. schema.name.adjustment.mode none Specifies how schema names should be adjusted for compatibility with the message converter used by the connector. Possible settings: none does not apply any adjustment. avro replaces the characters that cannot be used in the Avro type name with underscore. avro_unicode replaces the underscore or characters that cannot be used in the Avro type name with corresponding unicode like _uxxxx. Note: _ is an escape sequence like backslash in Java field.name.adjustment.mode none Specifies how field names should be adjusted for compatibility with the message converter used by the connector. Possible settings: none does not apply any adjustment. avro replaces the characters that cannot be used in the Avro type name with underscore. avro_unicode replaces the underscore or characters that cannot be used in the Avro type name with corresponding unicode like _uxxxx. Note: _ is an escape sequence like backslash in Java For more information, see Avro naming . money.fraction.digits 2 Specifies how many decimal digits should be used when converting Postgres money type to java.math.BigDecimal , which represents the values in change events. Applicable only when decimal.handling.mode is set to precise . message.prefix.include.list No default An optional, comma-separated list of regular expressions that match the names of the logical decoding message prefixes that you want the connector to capture. By default, the connector captures all logical decoding messages. When this property is set, the connector captures only logical decoding message with the prefixes specified by the property. All other logical decoding messages are excluded. To match the name of a message prefix, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire message prefix string; the expression does not match substrings that might be present in a prefix. If you include this property in the configuration, do not also set the message.prefix.exclude.list property. For information about the structure of message events and about their ordering semantics, see message events . message.prefix.exclude.list No default An optional, comma-separated list of regular expressions that match the names of the logical decoding message prefixes that you do not want the connector to capture. When this property is set, the connector does not capture logical decoding messages that use the specified prefixes. All other messages are captured. To exclude all logical decoding messages, set the value of this property to .* . To match the name of a message prefix, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire message prefix string; the expression does not match substrings that might be present in a prefix. If you include this property in the configuration, do not also set message.prefix.include.list property. For information about the structure of message events and about their ordering semantics, see message events . Advanced Debezium PostgreSQL connector configuration properties The following advanced configuration properties have defaults that work in most situations and therefore rarely need to be specified in the connector's configuration. Table 2.157. Advanced connector configuration properties Property Default Description converters No default Enumerates a comma-separated list of the symbolic names of the custom converter instances that the connector can use. For example, isbn You must set the converters property to enable the connector to use a custom converter. For each converter that you configure for a connector, you must also add a .type property, which specifies the fully-qualified name of the class that implements the converter interface. The .type property uses the following format: <converterSymbolicName> .type For example, If you want to further control the behavior of a configured converter, you can add one or more configuration parameters to pass values to the converter. To associate any additional configuration parameter with a converter, prefix the parameter names with the symbolic name of the converter. For example, snapshot.mode initial Specifies the criteria for performing a snapshot when the connector starts: always The connector performs a snapshot every time that it starts. The snapshot includes the structure and data of the captured tables. Specify this value to populate topics with a complete representation of the data from the captured tables every time that the connector starts. After the snapshot completes, the connector begins to stream event records for subsequent database changes. initial The connector performs a snapshot only when no offsets have been recorded for the logical server name. initial_only The connector performs an initial snapshot and then stops, without processing any subsequent changes. no_data The connector never performs snapshots. When a connector is configured this way, after it starts, it behaves as follows: If there is a previously stored LSN in the Kafka offsets topic, the connector continues streaming changes from that position. If no LSN is stored, the connector starts streaming changes from the point in time when the PostgreSQL logical replication slot was created on the server. Use this snapshot mode only when you know all data of interest is still reflected in the WAL. never Deprecated see no_data . when_needed After the connector starts, it performs a snapshot only if it detects one of the following circumstances: It cannot detect any topic offsets. A previously recorded offset specifies a log position that is not available on the server. For more information, see the table of snapshot.mode options . snapshot.locking.mode none Specifies how the connector holds locks on tables while performing a schema snapshot. Set one of the following options: shared The connector holds a table lock that prevents exclusive table access during the initial portion phase of the snapshot in which database schemas and other metadata are read. After the initial phase, the snapshot no longer requires table locks. none The connector avoids locks entirely. Warning Do not use this mode if schema changes might occur during the snapshot. snapshot.query.mode select_all Specifies how the connector queries data while performing a snapshot. Set one of the following options: select_all The connector performs a select all query by default, optionally adjusting the columns selected based on the column include and exclude list configurations. This setting enables you to manage snapshot content in a more flexible manner compared to using the snapshot.select.statement.overrides property. snapshot.include.collection.list All tables specified in table.include.list An optional, comma-separated list of regular expressions that match the fully-qualified names ( <schemaName>.<tableName> ) of the tables to include in a snapshot. The specified items must be named in the connector's table.include.list property. This property takes effect only if the connector's snapshot.mode property is set to a value other than never . This property does not affect the behavior of incremental snapshots. To match the name of a table, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the table; it does not match substrings that might be present in a table name. snapshot.lock.timeout.ms 10000 Positive integer value that specifies the maximum amount of time (in milliseconds) to wait to obtain table locks when performing a snapshot. If the connector cannot acquire table locks in this time interval, the snapshot fails. How the connector performs snapshots provides details. snapshot.select.statement.overrides No default Specifies the table rows to include in a snapshot. Use the property if you want a snapshot to include only a subset of the rows in a table. This property affects snapshots only. It does not apply to events that the connector reads from the log. The property contains a comma-separated list of fully-qualified table names in the form <schemaName>.<tableName> . For example, "snapshot.select.statement.overrides": "inventory.products,customers.orders" For each table in the list, add a further configuration property that specifies the SELECT statement for the connector to run on the table when it takes a snapshot. The specified SELECT statement determines the subset of table rows to include in the snapshot. Use the following format to specify the name of this SELECT statement property: snapshot.select.statement.overrides. <schemaName> . <tableName> . For example, snapshot.select.statement.overrides.customers.orders . Example: From a customers.orders table that includes the soft-delete column, delete_flag , add the following properties if you want a snapshot to include only those records that are not soft-deleted: In the resulting snapshot, the connector includes only the records for which delete_flag = 0 . event.processing.failure.handling.mode fail Specifies how the connector should react to exceptions during processing of events: fail propagates the exception, indicates the offset of the problematic event, and causes the connector to stop. warn logs the offset of the problematic event, skips that event, and continues processing. skip skips the problematic event and continues processing. max.batch.size 2048 Positive integer value that specifies the maximum size of each batch of events that the connector processes. max.queue.size 8192 Positive integer value that specifies the maximum number of records that the blocking queue can hold. When Debezium reads events streamed from the database, it places the events in the blocking queue before it writes them to Kafka. The blocking queue can provide backpressure for reading change events from the database in cases where the connector ingests messages faster than it can write them to Kafka, or when Kafka becomes unavailable. Events that are held in the queue are disregarded when the connector periodically records offsets. Always set the value of max.queue.size to be larger than the value of max.batch.size . max.queue.size.in.bytes 0 A long integer value that specifies the maximum volume of the blocking queue in bytes. By default, volume limits are not specified for the blocking queue. To specify the number of bytes that the queue can consume, set this property to a positive long value. If max.queue.size is also set, writing to the queue is blocked when the size of the queue reaches the limit specified by either property. For example, if you set max.queue.size=1000 , and max.queue.size.in.bytes=5000 , writing to the queue is blocked after the queue contains 1000 records, or after the volume of the records in the queue reaches 5000 bytes. poll.interval.ms 500 Positive integer value that specifies the number of milliseconds the connector should wait for new change events to appear before it starts processing a batch of events. Defaults to 500 milliseconds. include.unknown.datatypes false Specifies connector behavior when the connector encounters a field whose data type is unknown. The default behavior is that the connector omits the field from the change event and logs a warning. Set this property to true if you want the change event to contain an opaque binary representation of the field. This lets consumers decode the field. You can control the exact representation by setting the binary handling mode property. Note Consumers risk backward compatibility issues when include.unknown.datatypes is set to true . Not only may the database-specific binary representation change between releases, but if the data type is eventually supported by Debezium, the data type will be sent downstream in a logical type, which would require adjustments by consumers. In general, when encountering unsupported data types, create a feature request so that support can be added. database.initial.statements No default A semicolon separated list of SQL statements that the connector executes when it establishes a JDBC connection to the database. To use a semicolon as a character and not as a delimiter, specify two consecutive semicolons, ;; . The connector may establish JDBC connections at its own discretion. Consequently, this property is useful for configuration of session parameters only, and not for executing DML statements. The connector does not execute these statements when it creates a connection for reading the transaction log. status.update.interval.ms 10000 Frequency for sending replication connection status updates to the server, given in milliseconds. The property also controls how frequently the database status is checked to detect a dead connection in case the database was shut down. heartbeat.interval.ms 0 Controls how frequently the connector sends heartbeat messages to a Kafka topic. The default behavior is that the connector does not send heartbeat messages. Heartbeat messages are useful for monitoring whether the connector is receiving change events from the database. Heartbeat messages might help decrease the number of change events that need to be re-sent when a connector restarts. To send heartbeat messages, set this property to a positive integer, which indicates the number of milliseconds between heartbeat messages. Heartbeat messages are needed when there are many updates in a database that is being tracked but only a tiny number of updates are related to the table(s) and schema(s) for which the connector is capturing changes. In this situation, the connector reads from the database transaction log as usual but rarely emits change records to Kafka. This means that no offset updates are committed to Kafka and the connector does not have an opportunity to send the latest retrieved LSN to the database. The database retains WAL files that contain events that have already been processed by the connector. Sending heartbeat messages enables the connector to send the latest retrieved LSN to the database, which allows the database to reclaim disk space being used by no longer needed WAL files. heartbeat.action.query No default Specifies a query that the connector executes on the source database when the connector sends a heartbeat message. This is useful for resolving the situation described in WAL disk space consumption , where capturing changes from a low-traffic database on the same host as a high-traffic database prevents Debezium from processing WAL records and thus acknowledging WAL positions with the database. To address this situation, create a heartbeat table in the low-traffic database, and set this property to a statement that inserts records into that table, for example: INSERT INTO test_heartbeat_table (text) VALUES ('test_heartbeat') This allows the connector to receive changes from the low-traffic database and acknowledge their LSNs, which prevents unbounded WAL growth on the database host. schema.refresh.mode columns_diff Specify the conditions that trigger a refresh of the in-memory schema for a table. columns_diff is the safest mode. It ensures that the in-memory schema stays in sync with the database table's schema at all times. columns_diff_exclude_unchanged_toast instructs the connector to refresh the in-memory schema cache if there is a discrepancy with the schema derived from the incoming message, unless unchanged TOASTable data fully accounts for the discrepancy. This setting can significantly improve connector performance if there are frequently-updated tables that have TOASTed data that are rarely part of updates. However, it is possible for the in-memory schema to become outdated if TOASTable columns are dropped from the table. snapshot.delay.ms No default An interval in milliseconds that the connector should wait before performing a snapshot when the connector starts. If you are starting multiple connectors in a cluster, this property is useful for avoiding snapshot interruptions, which might cause re-balancing of connectors. streaming.delay.ms 0 Specifies the time, in milliseconds, that the connector delays the start of the streaming process after it completes a snapshot. Setting a delay interval helps to prevent the connector from restarting snapshots in the event that a failure occurs immediately after the snapshot completes, but before the streaming process begins. Set a delay value that is higher than the value of the offset.flush.interval.ms property that is set for the Kafka Connect worker. snapshot.fetch.size 10240 During a snapshot, the connector reads table content in batches of rows. This property specifies the maximum number of rows in a batch. slot.stream.params No default Semicolon separated list of parameters to pass to the configured logical decoding plug-in. For example, add-tables=public.table,public.table2;include-lsn=true . slot.max.retries 6 If connecting to a replication slot fails, this is the maximum number of consecutive attempts to connect. slot.retry.delay.ms 10000 (10 seconds) The number of milliseconds to wait between retry attempts when the connector fails to connect to a replication slot. unavailable.value.placeholder __debezium_unavailable_value Specifies the constant that the connector provides to indicate that the original value is a toasted value that is not provided by the database. If the setting of unavailable.value.placeholder starts with the hex: prefix it is expected that the rest of the string represents hexadecimally encoded octets. For more information, see toasted values . provide.transaction.metadata false Determines whether the connector generates events with transaction boundaries and enriches change event envelopes with transaction metadata. Specify true if you want the connector to do this. For more information, see Transaction metadata . flush.lsn.source true Determines whether the connector should commit the LSN of the processed records in the source postgres database so that the WAL logs can be deleted. Specify false if you don't want the connector to do this. Please note that if set to false LSN will not be acknowledged by Debezium and as a result WAL logs will not be cleared which might result in disk space issues. User is expected to handle the acknowledgement of LSN outside Debezium. retriable.restart.connector.wait.ms 10000 (10 seconds) The number of milliseconds to wait before restarting a connector after a retriable error occurs. skipped.operations t A comma-separated list of operation types that will be skipped during streaming. The operations include: c for inserts/create, u for updates, d for deletes, t for truncates, and none to not skip any operations. By default, truncate operations are skipped. signal.data.collection No default value Fully-qualified name of the data collection that is used to send signals to the connector. Use the following format to specify the collection name: <schemaName> . <tableName> signal.enabled.channels source List of the signaling channel names that are enabled for the connector. By default, the following channels are available: source kafka file jmx notification.enabled.channels No default List of notification channel names that are enabled for the connector. By default, the following channels are available: sink log jmx incremental.snapshot.chunk.size 1024 The maximum number of rows that the connector fetches and reads into memory during an incremental snapshot chunk. Increasing the chunk size provides greater efficiency, because the snapshot runs fewer snapshot queries of a greater size. However, larger chunk sizes also require more memory to buffer the snapshot data. Adjust the chunk size to a value that provides the best performance in your environment. incremental.snapshot.watermarking.strategy insert_insert Specifies the watermarking mechanism that the connector uses during an incremental snapshot to deduplicate events that might be captured by an incremental snapshot and then recaptured after streaming resumes. You can specify one of the following options: insert_insert When you send a signal to initiate an incremental snapshot, for every chunk that Debezium reads during the snapshot, it writes an entry to the signaling data collection to record the signal to open the snapshot window. After the snapshot completes, Debezium inserts a second entry to record the closing of the window. insert_delete When you send a signal to initiate an incremental snapshot, for every chunk that Debezium reads, it writes a single entry to the signaling data collection to record the signal to open the snapshot window. After the snapshot completes, this entry is removed. No entry is created for the signal to close the snapshot window. Set this option to prevent rapid growth of the signaling data collection. xmin.fetch.interval.ms 0 How often, in milliseconds, the XMIN will be read from the replication slot. The XMIN value provides the lower bounds of where a new replication slot could start from. The default value of 0 disables tracking XMIN tracking. topic.naming.strategy io.debezium.schema.SchemaTopicNamingStrategy The name of the TopicNamingStrategy class that should be used to determine the topic name for data change, schema change, transaction, heartbeat event etc., defaults to SchemaTopicNamingStrategy . topic.delimiter . Specify the delimiter for topic name, defaults to . . topic.cache.size 10000 The size used for holding the topic names in bounded concurrent hash map. This cache will help to determine the topic name corresponding to a given data collection. topic.heartbeat.prefix __debezium-heartbeat Controls the name of the topic to which the connector sends heartbeat messages. The topic name has this pattern: topic.heartbeat.prefix . topic.prefix For example, if the topic prefix is fulfillment , the default topic name is __debezium-heartbeat.fulfillment . topic.transaction transaction Controls the name of the topic to which the connector sends transaction metadata messages. The topic name has this pattern: topic.prefix . topic.transaction For example, if the topic prefix is fulfillment , the default topic name is fulfillment.transaction . snapshot.max.threads 1 Specifies the number of threads that the connector uses when performing an initial snapshot. To enable parallel initial snapshots, set the property to a value greater than 1. In a parallel initial snapshot, the connector processes multiple tables concurrently. Important Parallel initial snapshots is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope . custom.metric.tags No default Defines tags that customize MBean object names by adding metadata that provides contextual information. Specify a comma-separated list of key-value pairs. Each key represents a tag for the MBean object name, and the corresponding value represents a value for the key, for example, k1=v1,k2=v2 The connector appends the specified tags to the base MBean object name. Tags can help you to organize and categorize metrics data. You can define tags to identify particular application instances, environments, regions, versions, and so forth. For more information, see Customized MBean names . errors.max.retries -1 Specifies how the connector responds after an operation that results in a retriable error, such as a connection error. Set one of the following options: -1 No limit. The connector always restarts automatically, and retries the operation, regardless of the number of failures. 0 Disabled. The connector fails immediately, and never retries the operation. User intervention is required to restart the connector. > 0 The connector restarts automatically until it reaches the specified maximum number of retries. After the failure, the connector stops, and user intervention is required to restart it. database.query.timeout.ms 600000 (10 minutes) Specifies the time, in milliseconds, that the connector waits for a query to complete. Set the value to 0 (zero) to remove the timeout limit. Pass-through PostgreSQL connector configuration properties The connector supports pass-through properties that enable Debezium to specify custom configuration options for fine-tuning the behavior of the Apache Kafka producer and consumer. For information about the full range of configuration properties for Kafka producers and consumers, see the Kafka documentation . Pass-through properties for configuring how the PostgreSQL connector interacts with the Kafka signaling topic Debezium provides a set of signal.* properties that control how the connector interacts with the Kafka signals topic. The following table describes the Kafka signal properties. Table 2.158. Kafka signals configuration properties Property Default Description signal.kafka.topic <topic.prefix>-signal The name of the Kafka topic that the connector monitors for ad hoc signals. Note If automatic topic creation is disabled, you must manually create the required signaling topic. A signaling topic is required to preserve signal ordering. The signaling topic must have a single partition. signal.kafka.groupId kafka-signal The name of the group ID that is used by Kafka consumers. signal.kafka.bootstrap.servers No default A list of the host and port pairs that the connector uses to establish its initial connection to the Kafka cluster. Each pair references the Kafka cluster that is used by the Debezium Kafka Connect process. signal.kafka.poll.timeout.ms 100 An integer value that specifies the maximum number of milliseconds that the connector waits when polling signals. kafka.consumer.offset.commit.enabled false Specifies whether the Kafka consumer writes an offset commit after it reads a message from the signaling topic. The value that you assign to this property determines whether the connector can process requests that the signaling topic receives while the connector is offline. Choose one of the following settings: false When the connector is unavailable, the Kafka consumer does not commit an offset after it reads a signal received by the signaling topic. As a result, if the connector is offline for any interval, it cannot process requests that the signaling topic receives during the downtime. After the connector restarts, it always reads from the last position in the Kafka signaling topic, processing only signals that it receives after the restart. Signals received while the connector is offline are ignored, and are effectively lost. true When a user submits a request to the signaling topic, after the Kafka consumer reads the signal message it commits a topic offset, even if the connector is offline. Choose this option to provide Debezium with information about the last signal message that the consumer read, helping to ensure At-Least-Once delivery. After a connector restarts, it resumes processing from the last recorded offset, responding to signals that users submitted while the connector is offline. Pass-through properties for configuring the Kafka consumer client for the signaling channel The Debezium connector provides for pass-through configuration of the signals Kafka consumer. Pass-through signals properties begin with the prefix signals.consumer.* . For example, the connector passes properties such as signal.consumer.security.protocol=SSL to the Kafka consumer. Debezium strips the prefixes from the properties before it passes the properties to the Kafka signals consumer. Pass-through properties for configuring the PostgreSQL connector sink notification channel The following table describes properties that you can use to configure the Debezium sink notification channel. Table 2.159. Sink notification configuration properties Property Default Description notification.sink.topic.name No default The name of the topic that receives notifications from Debezium. This property is required when you configure the notification.enabled.channels property to include sink as one of the enabled notification channels. Debezium connector pass-through database driver configuration properties The Debezium connector provides for pass-through configuration of the database driver. Pass-through database properties begin with the prefix driver.* . For example, the connector passes properties such as driver.foobar=false to the JDBC URL. Debezium strips the prefixes from the properties before it passes the properties to the database driver. 2.6.7. Monitoring Debezium PostgreSQL connector performance The Debezium PostgreSQL connector provides two types of metrics that are in addition to the built-in support for JMX metrics that Zookeeper, Kafka, and Kafka Connect provide. Snapshot metrics provide information about connector operation while performing a snapshot. Streaming metrics provide information about connector operation when the connector is capturing changes and streaming change event records. Debezium monitoring documentation provides details for how to expose these metrics by using JMX. / Type: concept .Customized MBean names Debezium connectors expose metrics via the MBean name for the connector. These metrics, which are specific to each connector instance, provide data about the behavior of the connector's snapshot, streaming, and schema history processes. By default, when you deploy a correctly configured connector, Debezium generates a unique MBean name for each of the different connector metrics. To view the metrics for a connector process, you configure your observability stack to monitor its MBean. But these default MBean names depend on the connector configuration; configuration changes can result in changes to the MBean names. A change to the MBean name breaks the linkage between the connector instance and the MBean, disrupting monitoring activity. In this scenario, you must reconfigure the observability stack to use the new MBean name if you want to resume monitoring. To prevent monitoring disruptions that result from MBean name changes, you can configure custom metrics tags. You configure custom metrics by adding the custom.metric.tags property to the connector configuration. The property accepts key-value pairs in which each key represents a tag for the MBean object name, and the corresponding value represents the value of that tag. For example: k1=v1,k2=v2 . Debezium appends the specified tags to the MBean name of the connector. After you configure the custom.metric.tags property for a connector, you can configure the observability stack to retrieve metrics associated with the specified tags. The observability stack then uses the specified tags, rather than the mutable MBean names to uniquely identify connectors. Later, if Debezium redefines how it constructs MBean names, or if the topic.prefix in the connector configuration changes, metrics collection is uninterrupted, because the metrics scrape task uses the specified tag patterns to identify the connector. A further benefit of using custom tags, is that you can use tags that reflect the architecture of your data pipeline, so that metrics are organized in a way that suits you operational needs. For example, you might specify tags with values that declare the type of connector activity, the application context, or the data source, for example, db1-streaming-for-application-abc . If you specify multiple key-value pairs, all of the specified pairs are appended to the connector's MBean name. The following example illustrates how tags modify the default MBean name. Example 2.47. How custom tags modify the connector MBean name By default, the PostgreSQL connector uses the following MBean name for streaming metrics: If you set the value of custom.metric.tags to database=salesdb-streaming,table=inventory , Debezium generates the following custom MBean name: 2.6.7.1. Monitoring Debezium during snapshots of PostgreSQL databases The MBean is debezium.postgres:type=connector-metrics,context=snapshot,server= <topic.prefix> . Snapshot metrics are not exposed unless a snapshot operation is active, or if a snapshot has occurred since the last connector start. The following table lists the snapshot metrics that are available. Attributes Type Description LastEvent string The last snapshot event that the connector has read. MilliSecondsSinceLastEvent long The number of milliseconds since the connector has read and processed the most recent event. TotalNumberOfEventsSeen long The total number of events that this connector has seen since last started or reset. NumberOfEventsFiltered long The number of events that have been filtered by include/exclude list filtering rules configured on the connector. CapturedTables string[] The list of tables that are captured by the connector. QueueTotalCapacity int The length the queue used to pass events between the snapshotter and the main Kafka Connect loop. QueueRemainingCapacity int The free capacity of the queue used to pass events between the snapshotter and the main Kafka Connect loop. TotalTableCount int The total number of tables that are being included in the snapshot. RemainingTableCount int The number of tables that the snapshot has yet to copy. SnapshotRunning boolean Whether the snapshot was started. SnapshotPaused boolean Whether the snapshot was paused. SnapshotAborted boolean Whether the snapshot was aborted. SnapshotCompleted boolean Whether the snapshot completed. SnapshotDurationInSeconds long The total number of seconds that the snapshot has taken so far, even if not complete. Includes also time when snapshot was paused. SnapshotPausedDurationInSeconds long The total number of seconds that the snapshot was paused. If the snapshot was paused several times, the paused time adds up. RowsScanned Map<String, Long> Map containing the number of rows scanned for each table in the snapshot. Tables are incrementally added to the Map during processing. Updates every 10,000 rows scanned and upon completing a table. MaxQueueSizeInBytes long The maximum buffer of the queue in bytes. This metric is available if max.queue.size.in.bytes is set to a positive long value. CurrentQueueSizeInBytes long The current volume, in bytes, of records in the queue. The connector also provides the following additional snapshot metrics when an incremental snapshot is executed: Attributes Type Description ChunkId string The identifier of the current snapshot chunk. ChunkFrom string The lower bound of the primary key set defining the current chunk. ChunkTo string The upper bound of the primary key set defining the current chunk. TableFrom string The lower bound of the primary key set of the currently snapshotted table. TableTo string The upper bound of the primary key set of the currently snapshotted table. 2.6.7.2. Monitoring Debezium PostgreSQL connector record streaming The MBean is debezium.postgres:type=connector-metrics,context=streaming,server= <topic.prefix> . The following table lists the streaming metrics that are available. Attributes Type Description LastEvent string The last streaming event that the connector has read. MilliSecondsSinceLastEvent long The number of milliseconds since the connector has read and processed the most recent event. TotalNumberOfEventsSeen long The total number of data change events reported by the source database since the last connector start, or since a metrics reset. Represents the data change workload for Debezium to process. TotalNumberOfCreateEventsSeen long The total number of create events processed by the connector since its last start or metrics reset. TotalNumberOfUpdateEventsSeen long The total number of update events processed by the connector since its last start or metrics reset. TotalNumberOfDeleteEventsSeen long The total number of delete events processed by the connector since its last start or metrics reset. NumberOfEventsFiltered long The number of events that have been filtered by include/exclude list filtering rules configured on the connector. CapturedTables string[] The list of tables that are captured by the connector. QueueTotalCapacity int The length the queue used to pass events between the streamer and the main Kafka Connect loop. QueueRemainingCapacity int The free capacity of the queue used to pass events between the streamer and the main Kafka Connect loop. Connected boolean Flag that denotes whether the connector is currently connected to the database server. MilliSecondsBehindSource long The number of milliseconds between the last change event's timestamp and the connector processing it. The values will incorporate any differences between the clocks on the machines where the database server and the connector are running. NumberOfCommittedTransactions long The number of processed transactions that were committed. SourceEventPosition Map<String, String> The coordinates of the last received event. LastTransactionId string Transaction identifier of the last processed transaction. MaxQueueSizeInBytes long The maximum buffer of the queue in bytes. This metric is available if max.queue.size.in.bytes is set to a positive long value. CurrentQueueSizeInBytes long The current volume, in bytes, of records in the queue. 2.6.8. How Debezium PostgreSQL connectors handle faults and problems Debezium is a distributed system that captures all changes in multiple upstream databases; it never misses or loses an event. When the system is operating normally or being managed carefully then Debezium provides exactly once delivery of every change event record. Important Exactly-once delivery of PostgreSQL change event records is a Developer Preview feature only. Developer Preview software is not supported by Red Hat in any way and is not functionally complete or production-ready. Do not use Developer Preview software for production or business-critical workloads. Developer Preview software provides early access to upcoming product software in advance of its possible inclusion in a Red Hat product offering. Customers can use this software to test functionality and provide feedback during the development process. This software might not have any documentation, is subject to change or removal at any time, and has received limited testing. Red Hat might provide ways to submit feedback on Developer Preview software without an associated SLA. For more information about the support scope of Red Hat Developer Preview software, see Developer Preview Support Scope . If a fault does happen then the system does not lose any events. However, while it is recovering from the fault, it's possible that the connector might emit some duplicate change events. In these abnormal situations, Debezium, like Kafka, provides at least once delivery of change events. Details are in the following sections: Configuration and startup errors PostgreSQL becomes unavailable Cluster failures Kafka Connect process stops gracefully Kafka Connect process crashes Kafka becomes unavailable Connector is stopped for a duration Configuration and startup errors In the following situations, the connector fails when trying to start, reports an error/exception in the log, and stops running: The connector's configuration is invalid. The connector cannot successfully connect to PostgreSQL by using the specified connection parameters. The connector is restarting from a previously-recorded position in the PostgreSQL WAL (by using the LSN) and PostgreSQL no longer has that history available. In these cases, the error message has details about the problem and possibly a suggested workaround. After you correct the configuration or address the PostgreSQL problem, restart the connector. PostgreSQL becomes unavailable When the connector is running, the PostgreSQL server that it is connected to could become unavailable for any number of reasons. If this happens, the connector fails with an error and stops. When the server is available again, restart the connector. The PostgreSQL connector externally stores the last processed offset in the form of a PostgreSQL LSN. After a connector restarts and connects to a server instance, the connector communicates with the server to continue streaming from that particular offset. This offset is available as long as the Debezium replication slot remains intact. Never drop a replication slot on the primary server or you will lose data. For information about failure cases in which a slot has been removed, see the section. Cluster failures As of release 12, PostgreSQL allows logical replication slots only on primary servers . This means that you can point a Debezium PostgreSQL connector to only the active primary server of a database cluster. Also, replication slots themselves are not propagated to replicas. If the primary server goes down, a new primary must be promoted. Note Some managed PostgresSQL services (AWS RDS and GCP CloudSQL for example) implement replication to a standby via disk replication. This means that the replication slot does get replicated and will remain available after a failover. The new primary must have a replication slot that is configured for use by the pgoutput plug-in and the database in which you want to capture changes. Only then can you point the connector to the new server and restart the connector. There are important caveats when failovers occur and you should pause Debezium until you can verify that you have an intact replication slot that has not lost data. After a failover: There must be a process that re-creates the Debezium replication slot before allowing the application to write to the new primary. This is crucial. Without this process, your application can miss change events. You might need to verify that Debezium was able to read all changes in the slot before the old primary failed . One reliable method of recovering and verifying whether any changes were lost is to recover a backup of the failed primary to the point immediately before it failed. While this can be administratively difficult, it allows you to inspect the replication slot for any unconsumed changes. Kafka Connect process stops gracefully Suppose that Kafka Connect is being run in distributed mode and a Kafka Connect process is stopped gracefully. Prior to shutting down that process, Kafka Connect migrates the process's connector tasks to another Kafka Connect process in that group. The new connector tasks start processing exactly where the prior tasks stopped. There is a short delay in processing while the connector tasks are stopped gracefully and restarted on the new processes. Kafka Connect process crashes If the Kafka Connector process stops unexpectedly, any connector tasks it was running terminate without recording their most recently processed offsets. When Kafka Connect is being run in distributed mode, Kafka Connect restarts those connector tasks on other processes. However, PostgreSQL connectors resume from the last offset that was recorded by the earlier processes. This means that the new replacement tasks might generate some of the same change events that were processed just prior to the crash. The number of duplicate events depends on the offset flush period and the volume of data changes just before the crash. Because there is a chance that some events might be duplicated during a recovery from failure, consumers should always anticipate some duplicate events. Debezium changes are idempotent, so a sequence of events always results in the same state. In each change event record, Debezium connectors insert source-specific information about the origin of the event, including the PostgreSQL server's time of the event, the ID of the server transaction, and the position in the write-ahead log where the transaction changes were written. Consumers can keep track of this information, especially the LSN, to determine whether an event is a duplicate. Kafka becomes unavailable As the connector generates change events, the Kafka Connect framework records those events in Kafka by using the Kafka producer API. Periodically, at a frequency that you specify in the Kafka Connect configuration, Kafka Connect records the latest offset that appears in those change events. If the Kafka brokers become unavailable, the Kafka Connect process that is running the connectors repeatedly tries to reconnect to the Kafka brokers. In other words, the connector tasks pause until a connection can be re-established, at which point the connectors resume exactly where they left off. Connector is stopped for a duration If the connector is gracefully stopped, the database can continue to be used. Any changes are recorded in the PostgreSQL WAL. When the connector restarts, it resumes streaming changes where it left off. That is, it generates change event records for all database changes that were made while the connector was stopped. A properly configured Kafka cluster is able to handle massive throughput. Kafka Connect is written according to Kafka best practices, and given enough resources a Kafka Connect connector can also handle very large numbers of database change events. Because of this, after being stopped for a while, when a Debezium connector restarts, it is very likely to catch up with the database changes that were made while it was stopped. How quickly this happens depends on the capabilities and performance of Kafka and the volume of changes being made to the data in PostgreSQL. 2.7. Debezium connector for SQL Server The Debezium SQL Server connector captures row-level changes that occur in the schemas of a SQL Server database. For information about the SQL Server versions that are compatible with this connector, see the Debezium Supported Configurations page . For details about the Debezium SQL Server connector and its use, see the following topics: Section 2.7.1, "Overview of Debezium SQL Server connector" Section 2.7.2, "How Debezium SQL Server connectors work" Section 2.7.2.11, "Descriptions of Debezium SQL Server connector data change events" Section 2.7.2.13, "How Debezium SQL Server connectors map data types" Section 2.7.3, "Setting up SQL Server to run a Debezium connector" Section 2.7.4, "Deployment of Debezium SQL Server connectors" Section 2.7.5, "Refreshing capture tables after a schema change" Section 2.7.6, "Monitoring Debezium SQL Server connector performance" The first time that the Debezium SQL Server connector connects to a SQL Server database or cluster, it takes a consistent snapshot of the schemas in the database. After the initial snapshot is complete, the connector continuously captures row-level changes for INSERT , UPDATE , or DELETE operations that are committed to the SQL Server databases that are enabled for CDC. The connector produces events for each data change operation, and streams them to Kafka topics. The connector streams all of the events for a table to a dedicated Kafka topic. Applications and services can then consume data change event records from that topic. 2.7.1. Overview of Debezium SQL Server connector The Debezium SQL Server connector is based on the change data capture feature that is available in SQL Server 2016 Service Pack 1 (SP1) and later Standard edition or Enterprise edition. The SQL Server capture process monitors designated databases and tables, and stores the changes into specifically created change tables that have stored procedure facades. To enable the Debezium SQL Server connector to capture change event records for database operations, you must first enable change data capture on the SQL Server database. CDC must be enabled on both the database and on each table that you want to capture. After you set up CDC on the source database, the connector can capture row-level INSERT , UPDATE , and DELETE operations that occur in the database. The connector writes event records for each source table to a Kafka topic especially dedicated to that table. One topic exists for each captured table. Client applications read the Kafka topics for the database tables that they follow, and can respond to the row-level events they consume from those topics. The first time that the connector connects to a SQL Server database or cluster, it takes a consistent snapshot of the schemas for all tables for which it is configured to capture changes, and streams this state to Kafka. After the snapshot is complete, the connector continuously captures subsequent row-level changes that occur. By first establishing a consistent view of all of the data, the connector can continue reading without having lost any of the changes that were made while the snapshot was taking place. The Debezium SQL Server connector is tolerant of failures. As the connector reads changes and produces events, it periodically records the position of events in the database log ( LSN / Log Sequence Number ). If the connector stops for any reason (including communication failures, network problems, or crashes), after a restart the connector resumes reading the SQL Server CDC tables from the last point that it read. Note Offsets are committed periodically. They are not committed at the time that a change event occurs. As a result, following an outage, duplicate events might be generated. Fault tolerance also applies to snapshots. That is, if the connector stops during a snapshot, the connector begins a new snapshot when it restarts. 2.7.2. How Debezium SQL Server connectors work To optimally configure and run a Debezium SQL Server connector, it is helpful to understand how the connector performs snapshots, streams change events, determines Kafka topic names, and uses metadata. For details about how the connector works, see the following sections: Section 2.7.2.1, "How Debezium SQL Server connectors perform database snapshots" Section 2.7.2.2, "Ad hoc snapshots" Section 2.7.2.3, "Incremental snapshots" Section 2.7.2.5, "How Debezium SQL Server connectors read change data tables" Section 2.7.2.8, "Default names of Kafka topics that receive Debezium SQL Server change event records" Section 2.7.2.10, "How the Debezium SQL Server connector uses the schema change topic" Section 2.7.2.11, "Descriptions of Debezium SQL Server connector data change events" Section 2.7.2.12, "Debezium SQL Server connector-generated events that represent transaction boundaries" 2.7.2.1. How Debezium SQL Server connectors perform database snapshots SQL Server CDC is not designed to store a complete history of database changes. For the Debezium SQL Server connector to establish a baseline for the current state of the database, it uses a process called snapshotting . The initial snapshot captures the structure and data of the tables in the database. You can find more information about snapshots in the following sections: Section 2.7.2.2, "Ad hoc snapshots" Section 2.7.2.3, "Incremental snapshots" 2.7.2.1.1. Default workflow that the Debezium SQL Server connector uses to perform an initial snapshot The following workflow lists the steps that Debezium takes to create a snapshot. These steps describe the process for a snapshot when the snapshot.mode configuration property is set to its default value, which is initial . You can customize the way that the connector creates snapshots by changing the value of the snapshot.mode property. If you configure a different snapshot mode, the connector completes the snapshot by using a modified version of this workflow. Establish a connection to the database. Determine the tables to be captured. By default, the connector captures all non-system tables. To have the connector capture a subset of tables or table elements, you can set a number of include and exclude properties to filter the data, for example, table.include.list or table.exclude.list . Obtain a lock on the SQL Server tables for which CDC is enabled to prevent structural changes from occurring during creation of the snapshot. The level of the lock is determined by the snapshot.isolation.mode configuration property. Read the maximum log sequence number (LSN) position in the server's transaction log. Capture the structure of all non-system, or all tables that are designated for capture. The connector persists this information in its internal database schema history topic. The schema history provides information about the structure that is in effect when a change event occurs. Note By default, the connector captures the schema of every table in the database that is in capture mode, including tables that are not configured for capture. If tables are not configured for capture, the initial snapshot captures only their structure; it does not capture any table data. For more information about why snapshots persist schema information for tables that you did not include in the initial snapshot, see Understanding why initial snapshots capture the schema for all tables . Release the locks obtained in Step 3, if necessary. Other database clients can now write to any previously locked tables. At the LSN position read in Step 4, the connector scans the tables to be captured. During the scan, the connector completes the following tasks: Confirms that the table was created before the snapshot began. If the table was created after the snapshot began, the connector skips the table. After the snapshot is complete, and the connector transitions to streaming, it emits change events for any tables that were created after the snapshot began. Produces a read event for each row that is captured from a table. All read events contain the same LSN position, which is the LSN position that was obtained in step 4. Emits each read event to the Kafka topic for the table. Records the successful completion of the snapshot in the connector offsets. The resulting initial snapshot captures the current state of each row in the tables that are enabled for CDC. From this baseline state, the connector captures subsequent changes as they occur. After the snapshot process begins, if the process is interrupted due to connector failure, rebalancing, or other reasons, the process restarts after the connector restarts. After the connector completes the initial snapshot, it continues streaming from the position that it read in Step 4 so that it does not miss any updates. If the connector stops again for any reason, after it restarts, it resumes streaming changes from where it previously left off. Table 2.160. Settings for snapshot.mode connector configuration property Setting Description always Perform snapshot on each connector start. After the snapshot completes, the connector begins to stream event records for subsequent database changes. initial The connector performs a database snapshot as described in the default workflow for creating an initial snapshot . After the snapshot completes, the connector begins to stream event records for subsequent database changes. initial_only The connector performs a database snapshot and stops before streaming any change event records, not allowing any subsequent change events to be captured. schema_only Deprecated, see no_data . no_data The connector captures the structure of all relevant tables, performing all the steps described in the default snapshot workflow , except that it does not create READ events to represent the data set at the point of the connector's start-up (Step 7.b). recovery Set this option to restore a database schema history topic that is lost or corrupted. After a restart, the connector runs a snapshot that rebuilds the topic from the source tables. You can also set the property to periodically prune a database schema history topic that experiences unexpected growth. + WARNING: Do not use this mode to perform a snapshot if schema changes were committed to the database after the last connector shutdown. when_needed After the connector starts, it performs a snapshot only if it detects one of the following circumstances: It cannot detect any topic offsets. A previously recorded offset specifies a log position that is not available on the server. For more information, see snapshot.mode in the table of connector configuration properties. 2.7.2.1.2. Description of why initial snapshots capture the schema history for all tables The initial snapshot that a connector runs captures two types of information: Table data Information about INSERT , UPDATE , and DELETE operations in tables that are named in the connector's table.include.list property. Schema data DDL statements that describe the structural changes that are applied to tables. Schema data is persisted to both the internal schema history topic, and to the connector's schema change topic, if one is configured. After you run an initial snapshot, you might notice that the snapshot captures schema information for tables that are not designated for capture. By default, initial snapshots are designed to capture schema information for every table that is present in the database, not only from tables that are designated for capture. Connectors require that the table's schema is present in the schema history topic before they can capture a table. By enabling the initial snapshot to capture schema data for tables that are not part of the original capture set, Debezium prepares the connector to readily capture event data from these tables should that later become necessary. If the initial snapshot does not capture a table's schema, you must add the schema to the history topic before the connector can capture data from the table. In some cases, you might want to limit schema capture in the initial snapshot. This can be useful when you want to reduce the time required to complete a snapshot. Or when Debezium connects to the database instance through a user account that has access to multiple logical databases, but you want the connector to capture changes only from tables in a specific logic database. Additional information Capturing data from tables not captured by the initial snapshot (no schema change) Capturing data from tables not captured by the initial snapshot (schema change) Setting the schema.history.internal.store.only.captured.tables.ddl property to specify the tables from which to capture schema information. Setting the schema.history.internal.store.only.captured.databases.ddl property to specify the logical databases from which to capture schema changes. 2.7.2.1.3. Capturing data from tables not captured by the initial snapshot (no schema change) In some cases, you might want the connector to capture data from a table whose schema was not captured by the initial snapshot. Depending on the connector configuration, the initial snapshot might capture the table schema only for specific tables in the database. If the table schema is not present in the history topic, the connector fails to capture the table, and reports a missing schema error. You might still be able to capture data from the table, but you must perform additional steps to add the table schema. Prerequisites You want to capture data from a table with a schema that the connector did not capture during the initial snapshot. No schema changes were applied to the table between the LSNs of the earliest and latest change table entry that the connector reads. For information about capturing data from a new table that has undergone structural changes, see Section 2.1.2.1.4, "Capturing data from tables not captured by the initial snapshot (schema change)" . Procedure Stop the connector. Remove the internal database schema history topic that is specified by the schema.history.internal.kafka.topic property . Clear the offsets in the configured Kafka Connect offset.storage.topic . For more information about how to remove offsets, see the Debezium community FAQ . Warning Removing offsets should be performed only by advanced users who have experience in manipulating internal Kafka Connect data. This operation is potentially destructive, and should be performed only as a last resort. Apply the following changes to the connector configuration: (Optional) Set the value of schema.history.internal.store.only.captured.tables.ddl to false . This setting causes the snapshot to capture the schema for all tables, and guarantees that, in the future, the connector can reconstruct the schema history for all tables. Note Snapshots that capture the schema for all tables require more time to complete. Add the tables that you want the connector to capture to table.include.list . Set the snapshot.mode to one of the following values: initial When you restart the connector, it takes a full snapshot of the database that captures the table data and table structures. If you select this option, consider setting the value of the schema.history.internal.store.only.captured.tables.ddl property to false to enable the connector to capture the schema of all tables. schema_only When you restart the connector, it takes a snapshot that captures only the table schema. Unlike a full data snapshot, this option does not capture any table data. Use this option if you want to restart the connector more quickly than with a full snapshot. Restart the connector. The connector completes the type of snapshot specified by the snapshot.mode . (Optional) If the connector performed a schema_only snapshot, after the snapshot completes, initiate an incremental snapshot to capture data from the tables that you added. The connector runs the snapshot while it continues to stream real-time changes from the tables. Running an incremental snapshot captures the following data changes: For tables that the connector previously captured, the incremental snapsot captures changes that occur while the connector was down, that is, in the interval between the time that the connector was stopped, and the current restart. For newly added tables, the incremental snapshot captures all existing table rows. 2.7.2.1.4. Capturing data from tables not captured by the initial snapshot (schema change) If a schema change is applied to a table, records that are committed before the schema change have different structures than those that were committed after the change. When Debezium captures data from a table, it reads the schema history to ensure that it applies the correct schema to each event. If the schema is not present in the schema history topic, the connector is unable to capture the table, and an error results. If you want to capture data from a table that was not captured by the initial snapshot, and the schema of the table was modified, you must add the schema to the history topic, if it is not already available. You can add the schema by running a new schema snapshot, or by running an initial snapshot for the table. Prerequisites You want to capture data from a table with a schema that the connector did not capture during the initial snapshot. A schema change was applied to the table so that the records to be captured do not have a uniform structure. Procedure Initial snapshot captured the schema for all tables ( store.only.captured.tables.ddl was set to false ) Edit the table.include.list property to specify the tables that you want to capture. Restart the connector. Initiate an incremental snapshot if you want to capture existing data from the newly added tables. Initial snapshot did not capture the schema for all tables ( store.only.captured.tables.ddl was set to true ) If the initial snapshot did not save the schema of the table that you want to capture, complete one of the following procedures: Procedure 1: Schema snapshot, followed by incremental snapshot In this procedure, the connector first performs a schema snapshot. You can then initiate an incremental snapshot to enable the connector to synchronize data. Stop the connector. Remove the internal database schema history topic that is specified by the schema.history.internal.kafka.topic property . Clear the offsets in the configured Kafka Connect offset.storage.topic . For more information about how to remove offsets, see the Debezium community FAQ . Warning Removing offsets should be performed only by advanced users who have experience in manipulating internal Kafka Connect data. This operation is potentially destructive, and should be performed only as a last resort. Set values for properties in the connector configuration as described in the following steps: Set the value of the snapshot.mode property to schema_only . Edit the table.include.list to add the tables that you want to capture. Restart the connector. Wait for Debezium to capture the schema of the new and existing tables. Data changes that occurred any tables after the connector stopped are not captured. To ensure that no data is lost, initiate an incremental snapshot . Procedure 2: Initial snapshot, followed by optional incremental snapshot In this procedure the connector performs a full initial snapshot of the database. As with any initial snapshot, in a database with many large tables, running an initial snapshot can be a time-consuming operation. After the snapshot completes, you can optionally trigger an incremental snapshot to capture any changes that occur while the connector is off-line. Stop the connector. Remove the internal database schema history topic that is specified by the schema.history.internal.kafka.topic property . Clear the offsets in the configured Kafka Connect offset.storage.topic . For more information about how to remove offsets, see the Debezium community FAQ . Warning Removing offsets should be performed only by advanced users who have experience in manipulating internal Kafka Connect data. This operation is potentially destructive, and should be performed only as a last resort. Edit the table.include.list to add the tables that you want to capture. Set values for properties in the connector configuration as described in the following steps: Set the value of the snapshot.mode property to initial . (Optional) Set schema.history.internal.store.only.captured.tables.ddl to false . Restart the connector. The connector takes a full database snapshot. After the snapshot completes, the connector transitions to streaming. (Optional) To capture any data that changed while the connector was off-line, initiate an incremental snapshot . 2.7.2.2. Ad hoc snapshots By default, a connector runs an initial snapshot operation only after it starts for the first time. Following this initial snapshot, under normal circumstances, the connector does not repeat the snapshot process. Any future change event data that the connector captures comes in through the streaming process only. However, in some situations the data that the connector obtained during the initial snapshot might become stale, lost, or incomplete. To provide a mechanism for recapturing table data, Debezium includes an option to perform ad hoc snapshots. You might want to perform an ad hoc snapshot after any of the following changes occur in your Debezium environment: The connector configuration is modified to capture a different set of tables. Kafka topics are deleted and must be rebuilt. Data corruption occurs due to a configuration error or some other problem. You can re-run a snapshot for a table for which you previously captured a snapshot by initiating a so-called ad-hoc snapshot . Ad hoc snapshots require the use of signaling tables . You initiate an ad hoc snapshot by sending a signal request to the Debezium signaling table. When you initiate an ad hoc snapshot of an existing table, the connector appends content to the topic that already exists for the table. If a previously existing topic was removed, Debezium can create a topic automatically if automatic topic creation is enabled. Ad hoc snapshot signals specify the tables to include in the snapshot. The snapshot can capture the entire contents of the database, or capture only a subset of the tables in the database. Also, the snapshot can capture a subset of the contents of the table(s) in the database. You specify the tables to capture by sending an execute-snapshot message to the signaling table. Set the type of the execute-snapshot signal to incremental or blocking , and provide the names of the tables to include in the snapshot, as described in the following table: Table 2.161. Example of an ad hoc execute-snapshot signal record Field Default Value type incremental Specifies the type of snapshot that you want to run. Currently, you can request incremental or blocking snapshots. data-collections N/A An array that contains regular expressions matching the fully-qualified names of the tables to include in the snapshot. For the SQL Server connector, use the following format to specify the fully qualified name of a table: database.schema.table . additional-conditions N/A An optional array that specifies a set of additional conditions that the connector evaluates to determine the subset of records to include in a snapshot. Each additional condition is an object that specifies the criteria for filtering the data that an ad hoc snapshot captures. You can set the following parameters for each additional condition: data-collection The fully-qualified name of the table that the filter applies to. You can apply different filters to each table. filter Specifies column values that must be present in a database record for the snapshot to include it, for example, "color='blue'" . The values that you assign to the filter parameter are the same types of values that you might specify in the WHERE clause of SELECT statements when you set the snapshot.select.statement.overrides property for a blocking snapshot. surrogate-key N/A An optional string that specifies the column name that the connector uses as the primary key of a table during the snapshot process. Triggering an ad hoc incremental snapshot You initiate an ad hoc incremental snapshot by adding an entry with the execute-snapshot signal type to the signaling table, or by sending a signal message to a Kafka signaling topic . After the connector processes the message, it begins the snapshot operation. The snapshot process reads the first and last primary key values and uses those values as the start and end point for each table. Based on the number of entries in the table, and the configured chunk size, Debezium divides the table into chunks, and proceeds to snapshot each chunk, in succession, one at a time. For more information, see Incremental snapshots . Triggering an ad hoc blocking snapshot You initiate an ad hoc blocking snapshot by adding an entry with the execute-snapshot signal type to the signaling table or signaling topic. After the connector processes the message, it begins the snapshot operation. The connector temporarily stops streaming, and then initiates a snapshot of the specified table, following the same process that it uses during an initial snapshot. After the snapshot completes, the connector resumes streaming. For more information, see Blocking snapshots . 2.7.2.3. Incremental snapshots SQL Server collations Each SQL Server server or database is configured to use a specific collation , which determines how character data is stored, sorted, compared, and displayed. The sorting rules for some collation sets, such as the SQL Server collations (SQL_*) are not compatible with the Unicode sorting algorithm. In some cases, the incompatible sorting rules can lead to lost data when the connector runs an ad hoc snapshot. For example, if SQL Server is configured to send strings as Unicode (that is, the connection property sendStringParametersAsUnicode is set to true ), the connector can skip records during the snapshot. To protect against lost data during an ad hoc snapshot, set the value of the driver.sendStringParametersAsUnicode connection string property to false . For more information about using the sendStringParametersAsUnicode property, see the SQL Server connection properties documentation . To provide flexibility in managing snapshots, Debezium includes a supplementary snapshot mechanism, known as incremental snapshotting . Incremental snapshots rely on the Debezium mechanism for sending signals to a Debezium connector . In an incremental snapshot, instead of capturing the full state of a database all at once, as in an initial snapshot, Debezium captures each table in phases, in a series of configurable chunks. You can specify the tables that you want the snapshot to capture and the size of each chunk . The chunk size determines the number of rows that the snapshot collects during each fetch operation on the database. The default chunk size for incremental snapshots is 1024 rows. As an incremental snapshot proceeds, Debezium uses watermarks to track its progress, maintaining a record of each table row that it captures. This phased approach to capturing data provides the following advantages over the standard initial snapshot process: You can run incremental snapshots in parallel with streamed data capture, instead of postponing streaming until the snapshot completes. The connector continues to capture near real-time events from the change log throughout the snapshot process, and neither operation blocks the other. If the progress of an incremental snapshot is interrupted, you can resume it without losing any data. After the process resumes, the snapshot begins at the point where it stopped, rather than recapturing the table from the beginning. You can run an incremental snapshot on demand at any time, and repeat the process as needed to adapt to database updates. For example, you might re-run a snapshot after you modify the connector configuration to add a table to its table.include.list property. Incremental snapshot process When you run an incremental snapshot, Debezium sorts each table by primary key and then splits the table into chunks based on the configured chunk size . Working chunk by chunk, it then captures each table row in a chunk. For each row that it captures, the snapshot emits a READ event. That event represents the value of the row when the snapshot for the chunk began. As a snapshot proceeds, it's likely that other processes continue to access the database, potentially modifying table records. To reflect such changes, INSERT , UPDATE , or DELETE operations are committed to the transaction log as per usual. Similarly, the ongoing Debezium streaming process continues to detect these change events and emits corresponding change event records to Kafka. How Debezium resolves collisions among records with the same primary key In some cases, the UPDATE or DELETE events that the streaming process emits are received out of sequence. That is, the streaming process might emit an event that modifies a table row before the snapshot captures the chunk that contains the READ event for that row. When the snapshot eventually emits the corresponding READ event for the row, its value is already superseded. To ensure that incremental snapshot events that arrive out of sequence are processed in the correct logical order, Debezium employs a buffering scheme for resolving collisions. Only after collisions between the snapshot events and the streamed events are resolved does Debezium emit an event record to Kafka. Snapshot window To assist in resolving collisions between late-arriving READ events and streamed events that modify the same table row, Debezium employs a so-called snapshot window . The snapshot window demarcates the interval during which an incremental snapshot captures data for a specified table chunk. Before the snapshot window for a chunk opens, Debezium follows its usual behavior and emits events from the transaction log directly downstream to the target Kafka topic. But from the moment that the snapshot for a particular chunk opens, until it closes, Debezium performs a de-duplication step to resolve collisions between events that have the same primary key.. For each data collection, the Debezium emits two types of events, and stores the records for them both in a single destination Kafka topic. The snapshot records that it captures directly from a table are emitted as READ operations. Meanwhile, as users continue to update records in the data collection, and the transaction log is updated to reflect each commit, Debezium emits UPDATE or DELETE operations for each change. As the snapshot window opens, and Debezium begins processing a snapshot chunk, it delivers snapshot records to a memory buffer. During the snapshot windows, the primary keys of the READ events in the buffer are compared to the primary keys of the incoming streamed events. If no match is found, the streamed event record is sent directly to Kafka. If Debezium detects a match, it discards the buffered READ event, and writes the streamed record to the destination topic, because the streamed event logically supersede the static snapshot event. After the snapshot window for the chunk closes, the buffer contains only READ events for which no related transaction log events exist. Debezium emits these remaining READ events to the table's Kafka topic. The connector repeats the process for each snapshot chunk. Currently, you can use either of the following methods to initiate an incremental snapshot: Send an ad hoc snapshot signal to the signaling table on the source database . Send a message to a configured Kafka signaling topic . Warning The Debezium connector for SQL Server does not support schema changes while an incremental snapshot is running. 2.7.2.3.1. Triggering an incremental snapshot To initiate an incremental snapshot, you can send an ad hoc snapshot signal to the signaling table on the source database. You submit snapshot signals as SQL INSERT queries. After Debezium detects the change in the signaling table, it reads the signal, and runs the requested snapshot operation. The query that you submit specifies the tables to include in the snapshot, and, optionally, specifies the type of snapshot operation. Debezium currently supports the incremental and blocking snapshot types. To specify the tables to include in the snapshot, provide a data-collections array that lists the tables, or an array of regular expressions used to match tables, for example, {"data-collections": ["public.MyFirstTable", "public.MySecondTable"]} The data-collections array for an incremental snapshot signal has no default value. If the data-collections array is empty, Debezium interprets the empty array to mean that no action is required, and it does not perform a snapshot. Note If the name of a table that you want to include in a snapshot contains a dot ( . ), a space, or some other non-alphanumeric character, you must escape the table name in double quotes. For example, to include a table that exists in the public schema in the db1 database, and that has the name My.Table , use the following format: "db1.public.\"My.Table\"" . Prerequisites Signaling is enabled . A signaling data collection exists on the source database. The signaling data collection is specified in the signal.data.collection property. Using a source signaling channel to trigger an incremental snapshot Send a SQL query to add the ad hoc incremental snapshot request to the signaling table: INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}'); For example, INSERT INTO db1.myschema.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'execute-snapshot', 3 '{"data-collections": ["db1.schema1.table1", "db1.schema1.table2"], 4 "type":"incremental", 5 "additional-conditions":[{"data-collection": "db1.schema1.table1" ,"filter":"color=\'blue\'"}]}'); 6 The values of the id , type , and data parameters in the command correspond to the fields of the signaling table . The following table describes the parameters in the example: Table 2.162. Descriptions of fields in a SQL command for sending an incremental snapshot signal to the signaling table Item Value Description 1 database.schema.debezium_signal Specifies the fully-qualified name of the signaling table on the source database. 2 ad-hoc-1 The id parameter specifies an arbitrary string that is assigned as the id identifier for the signal request. Use this string to identify logging messages to entries in the signaling table. Debezium does not use this string. Rather, during the snapshot, Debezium generates its own id string as a watermarking signal. 3 execute-snapshot The type parameter specifies the operation that the signal is intended to trigger. 4 data-collections A required component of the data field of a signal that specifies an array of table names or regular expressions to match table names to include in the snapshot. The array lists regular expressions that use the format database.schema.table to match the fully-qualified names of the tables. This format is the same as the one that you use to specify the name of the connector's signaling table . 5 incremental An optional type component of the data field of a signal that specifies the type of snapshot operation to run. Valid values are incremental and blocking . If you do not specify a value, the connector defaults to performing an incremental snapshot. 6 additional-conditions An optional array that specifies a set of additional conditions that the connector evaluates to determine the subset of records to include in a snapshot. Each additional condition is an object with data-collection and filter properties. You can specify different filters for each data collection. * The data-collection property is the fully-qualified name of the data collection that the filter applies to. For more information about the additional-conditions parameter, see Section 2.7.2.3.2, "Running an ad hoc incremental snapshots with additional-conditions " . 2.7.2.3.2. Running an ad hoc incremental snapshots with additional-conditions If you want a snapshot to include only a subset of the content in a table, you can modify the signal request by appending an additional-conditions parameter to the snapshot signal. The SQL query for a typical snapshot takes the following form: SELECT * FROM <tableName> .... By adding an additional-conditions parameter, you append a WHERE condition to the SQL query, as in the following example: SELECT * FROM <data-collection> WHERE <filter> .... The following example shows a SQL query to send an ad hoc incremental snapshot request with an additional condition to the signaling table: INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}'); For example, suppose you have a products table that contains the following columns: id (primary key) color quantity If you want an incremental snapshot of the products table to include only the data items where color=blue , you can use the following SQL statement to trigger the snapshot: INSERT INTO db1.myschema.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["db1.schema1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "db1.schema1.products", "filter": "color=blue"}]}'); The additional-conditions parameter also enables you to pass conditions that are based on more than one column. For example, using the products table from the example, you can submit a query that triggers an incremental snapshot that includes the data of only those items for which color=blue and quantity>10 : INSERT INTO db1.myschema.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["db1.schema1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "db1.schema1.products", "filter": "color=blue AND quantity>10"}]}'); The following example, shows the JSON for an incremental snapshot event that is captured by a connector. Example 2.48. Incremental snapshot event message { "before":null, "after": { "pk":"1", "value":"New data" }, "source": { ... "snapshot":"incremental" 1 }, "op":"r", 2 "ts_ms":"1620393591654", "ts_us":"1620393591654547", "ts_ns":"1620393591654547920", "transaction":null } Table 2.163. Description of fields in an incremental snapshot event message Item Field name Description 1 snapshot Specifies the type of snapshot operation to run. Currently, the only valid options are blocking and incremental . Specifying a type value in the SQL query that you submit to the signaling table is optional. If you do not specify a value, the connector runs an incremental snapshot. 2 op Specifies the event type. The value for snapshot events is r , signifying a READ operation. 2.7.2.3.3. Using the Kafka signaling channel to trigger an incremental snapshot You can send a message to the configured Kafka topic to request the connector to run an ad hoc incremental snapshot. The key of the Kafka message must match the value of the topic.prefix connector configuration option. The value of the message is a JSON object with type and data fields. The signal type is execute-snapshot , and the data field must have the following fields: Table 2.164. Execute snapshot data fields Field Default Value type incremental The type of the snapshot to be executed. Currently Debezium supports the incremental and blocking types. See the section for more details. data-collections N/A An array of comma-separated regular expressions that match the fully-qualified names of tables to include in the snapshot. Specify the names by using the same format as is required for the signal.data.collection configuration option. additional-conditions N/A An optional array of additional conditions that specifies criteria that the connector evaluates to designate a subset of records to include in a snapshot. Each additional condition is an object that specifies the criteria for filtering the data that an ad hoc snapshot captures. You can set the following parameters for each additional condition: data-collection :: The fully-qualified name of the table that the filter applies to. You can apply different filters to each table. filter :: Specifies column values that must be present in a database record for the snapshot to include it, for example, "color='blue'" . The values that you assign to the filter parameter are the same types of values that you might specify in the WHERE clause of SELECT statements when you set the snapshot.select.statement.overrides property for a blocking snapshot. Example 2.49. An execute-snapshot Kafka message Ad hoc incremental snapshots with additional-conditions Debezium uses the additional-conditions field to select a subset of a table's content. Typically, when Debezium runs a snapshot, it runs a SQL query such as: SELECT * FROM <tableName> ... . When the snapshot request includes an additional-conditions property, the data-collection and filter parameters of the property are appended to the SQL query, for example: SELECT * FROM <data-collection> WHERE <filter> ... . For example, given a products table with the columns id (primary key), color , and brand , if you want a snapshot to include only content for which color='blue' , when you request the snapshot, you could add the additional-conditions property to filter the content: Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["db1.schema1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "db1.schema1.products" ,"filter":"color='blue'"}]}}` You can also use the additional-conditions property to pass conditions based on multiple columns. For example, using the same products table as in the example, if you want a snapshot to include only the content from the products table for which color='blue' , and brand='MyBrand' , you could send the following request: Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["db1.schema1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "db1.schema1.products" ,"filter":"color='blue' AND brand='MyBrand'"}]}}` 2.7.2.3.4. Stopping an incremental snapshot In some situations, it might be necessary to stop an incremental snapshot. For example, you might realize that snapshot was not configured correctly, or maybe you want to ensure that resources are available for other database operations. You can stop a snapshot that is already running by sending a signal to the signaling table on the source database. You submit a stop snapshot signal to the signaling table by sending it in a SQL INSERT query. The stop-snapshot signal specifies the type of the snapshot operation as incremental , and optionally specifies the tables that you want to omit from the currently running snapshot. After Debezium detects the change in the signaling table, it reads the signal, and stops the incremental snapshot operation if it's in progress. Additional resources You can also stop an incremental snapshot by sending a JSON message to the Kafka signaling topic . Prerequisites Signaling is enabled . A signaling data collection exists on the source database. The signaling data collection is specified in the signal.data.collection property. Using a source signaling channel to stop an incremental snapshot Send a SQL query to stop the ad hoc incremental snapshot to the signaling table: INSERT INTO <signalTable> (id, type, data) values ( '<id>' , 'stop-snapshot', '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":"incremental"}'); For example, INSERT INTO db1.myschema.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'stop-snapshot', 3 '{"data-collections": ["db1.schema1.table1", "db1.schema1.table2"], 4 "type":"incremental"}'); 5 The values of the id , type , and data parameters in the signal command correspond to the fields of the signaling table . The following table describes the parameters in the example: Table 2.165. Descriptions of fields in a SQL command for sending a stop incremental snapshot signal to the signaling table Item Value Description 1 database.schema.debezium_signal Specifies the fully-qualified name of the signaling table on the source database. 2 ad-hoc-1 The id parameter specifies an arbitrary string that is assigned as the id identifier for the signal request. Use this string to identify logging messages to entries in the signaling table. Debezium does not use this string. 3 stop-snapshot Specifies type parameter specifies the operation that the signal is intended to trigger. 4 data-collections An optional component of the data field of a signal that specifies an array of table names or regular expressions to match table names to remove from the snapshot. The array lists regular expressions which match tables by their fully-qualified names in the format database.schema.table If you omit this component from the data field, the signal stops the entire incremental snapshot that is in progress. 5 incremental A required component of the data field of a signal that specifies the type of snapshot operation that is to be stopped. Currently, the only valid option is incremental . If you do not specify a type value, the signal fails to stop the incremental snapshot. 2.7.2.3.5. Using the Kafka signaling channel to stop an incremental snapshot You can send a signal message to the configured Kafka signaling topic to stop an ad hoc incremental snapshot. The key of the Kafka message must match the value of the topic.prefix connector configuration option. The value of the message is a JSON object with type and data fields. The signal type is stop-snapshot , and the data field must have the following fields: Table 2.166. Execute snapshot data fields Field Default Value type incremental The type of the snapshot to be executed. Currently Debezium supports only the incremental type. See the section for more details. data-collections N/A An optional array of comma-separated regular expressions that match the fully-qualified names of the tables an array of table names or regular expressions to match table names to remove from the snapshot. Specify table names by using the format database.schema.table . The following example shows a typical stop-snapshot Kafka message: Key = `test_connector` Value = `{"type":"stop-snapshot","data": {"data-collections": ["db1.schema1.table1", "db1.schema1.table2"], "type": "INCREMENTAL"}}` 2.7.2.4. Blocking snapshots To provide more flexibility in managing snapshots, Debezium includes a supplementary ad hoc snapshot mechanism, known as a blocking snapshot . Blocking snapshots rely on the Debezium mechanism for sending signals to a Debezium connector . A blocking snapshot behaves just like an initial snapshot , except that you can trigger it at run time. You might want to run a blocking snapshot rather than use the standard initial snapshot process in the following situations: You add a new table and you want to complete the snapshot while the connector is running. You add a large table, and you want the snapshot to complete in less time than is possible with an incremental snapshot. Blocking snapshot process When you run a blocking snapshot, Debezium stops streaming, and then initiates a snapshot of the specified table, following the same process that it uses during an initial snapshot. After the snapshot completes, the streaming is resumed. Configure snapshot You can set the following properties in the data component of a signal: data-collections: to specify which tables must be snapshot additional-conditions: You can specify different filters for different table. The data-collection property is the fully-qualified name of the table for which the filter will be applied. The filter property will have the same value used in the snapshot.select.statement.overrides For example: {"type": "blocking", "data-collections": ["schema1.table1", "schema1.table2"], "additional-conditions": [{"data-collection": "schema1.table1", "filter": "SELECT * FROM [schema1].[table1] WHERE column1 = 0 ORDER BY column2 DESC"}, {"data-collection": "schema1.table2", "filter": "SELECT * FROM [schema1].[table2] WHERE column2 > 0"}]} Possible duplicates A delay might exist between the time that you send the signal to trigger the snapshot, and the time when streaming stops and the snapshot starts. As a result of this delay, after the snapshot completes, the connector might emit some event records that duplicate records captured by the snapshot. 2.7.2.5. How Debezium SQL Server connectors read change data tables When the connector first starts, it takes a structural snapshot of the structure of the captured tables and persists this information to its internal database schema history topic. The connector then identifies a change table for each source table, and completes the following steps. For each change table, the connector read all of the changes that were created between the last stored maximum LSN and the current maximum LSN. The connector sorts the changes that it reads in ascending order, based on the values of their commit LSN and change LSN. This sorting order ensures that the changes are replayed by Debezium in the same order in which they occurred in the database. The connector passes the commit and change LSNs as offsets to Kafka Connect. The connector stores the maximum LSN and restarts the process from Step 1. After a restart, the connector resumes processing from the last offset (commit and change LSNs) that it read. The connector is able to detect whether CDC is enabled or disabled for included source tables and adjust its behavior. 2.7.2.6. No maximum LSN recorded in the database There may be situations when no maximum LSN is recorded in the database because: SQL Server Agent is not running No changes are recorded in the change table yet Database has low activity and the cdc clean up job periodically clears entries from the cdc tables Out of these possibilities, since a running SQL Server Agent is a prerequisite, No 1. is a real problem (while No 2. and 3. are normal). In order to mitigate this issue and differentiate between No 1. and the others, a check for the status of the SQL Server Agent is done through the following query "SELECT CASE WHEN dss.[status]=4 THEN 1 ELSE 0 END AS isRunning FROM [#db].sys.dm_server_services dss WHERE dss.[servicename] LIKE N'SQL Server Agent (%';" . If the SQL Server Agent is not running, an ERROR is written in the log: "No maximum LSN recorded in the database; SQL Server Agent is not running". Important The SQL Server Agent running status query requires VIEW SERVER STATE server permission. If you don't want to grant this permission to the configured user, you can choose to configure your own query through the database.sqlserver.agent.status.query property. You can define a function which returns true or 1 if SQL Server Agent is running (false or 0 otherwise) and safely use High-Level permissions without granting them as explained here What minimum permissions do I need to provide to a user so that it can check the status of SQL Server Agent Service? or here Safely and Easily Use High-Level Permissions Without Granting Them to Anyone: Server-level . The configuration of the query property would look like: database.sqlserver.agent.status.query=SELECT [#db].func_is_sql_server_agent_running() - you need to use [#db] as placeholder for the database name. 2.7.2.7. Limitations of Debezium SQL Server connector SQL Server specifically requires the base object to be a table in order to create a change capture instance. As consequence, capturing changes from indexed views (aka. materialized views) is not supported by SQL Server and hence Debezium SQL Server connector. 2.7.2.8. Default names of Kafka topics that receive Debezium SQL Server change event records By default, the SQL Server connector writes events for all INSERT , UPDATE , and DELETE operations that occur in a table to a single Apache Kafka topic that is specific to that table. The connector uses the following convention to name change event topics: <topicPrefix> . <schemaName> . <tableName> The following list provides definitions for the components of the default name: topicPrefix The logical name of the server, as specified by the topic.prefix configuration property. schemaName The name of the database schema in which the change event occurred. tableName The name of the database table in which the change event occurred. For example, if fulfillment is the logical server name, and dbo is the schema name, and the database contains tables with the names products , products_on_hand , customers , and orders , the connector would stream change event records to the following Kafka topics: fulfillment.testDB.dbo.products fulfillment.testDB.dbo.products_on_hand fulfillment.testDB.dbo.customers fulfillment.testDB.dbo.orders The connector applies similar naming conventions to label its internal database schema history topics, schema change topics , and transaction metadata topics . If the default topic name do not meet your requirements, you can configure custom topic names. To configure custom topic names, you specify regular expressions in the logical topic routing SMT. For more information about using the logical topic routing SMT to customize topic naming, see Topic routing . 2.7.2.9. How Debezium SQL Server connectors handle database schema changes When a database client queries a database, the client uses the database's current schema. However, the database schema can be changed at any time, which means that the connector must be able to identify what the schema was at the time each insert, update, or delete operation was recorded. Also, a connector cannot necessarily apply the current schema to every event. If an event is relatively old, it's possible that it was recorded before the current schema was applied. To ensure correct processing of change events that occur after a schema change, the Debezium SQL Server connector stores a snapshot of the new schema based on the structure in the SQL Server change tables, which mirror the structure of their associated data tables. The connector stores the table schema information, together with the LSN of operations the result in schema changes, in the database schema history Kafka topic. The connector uses the stored schema representation to produce change events that correctly mirror the structure of tables at the time of each insert, update, or delete operation. When the connector restarts after either a crash or a graceful stop, it resumes reading entries in the SQL Server CDC tables from the last position that it read. Based on the schema information that the connector reads from the database schema history topic, the connector applies the table structures that existed at the position where the connector restarts. If you update the schema of a Db2 table that is in capture mode, it's important that you also update the schema of the corresponding change table. You must be a SQL Server database administrator with elevated privileges to update database schema. For more information about updating SQL Server database schema in Debezium environmenbts, see Database schema evolution . The database schema history topic is for internal connector use only. Optionally, the connector can also emit schema change events to a different topic that is intended for consumer applications . Additional resources Default names for topics that receive Debezium event records. 2.7.2.10. How the Debezium SQL Server connector uses the schema change topic For each table for which CDC is enabled, the Debezium SQL Server connector stores a history of the schema change events that are applied to tables in the database. The connector writes schema change events to a Kafka topic named <topicPrefix> , where topicPrefix is the logical server name that is specified in the topic.prefix configuration property. Messages that the connector sends to the schema change topic contain a payload, and, optionally, also contain the schema of the change event message. The schema for the schema change event has the following elements: name The name of the schema change event message. type The type of the change event message. version The version of the schema. The version is an integer that is incremented each time the schema is changed. fields The fields that are included in the change event message. Example: Schema of the SQL Server connector schema change topic The following example shows a typical schema in JSON format. { "schema": { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "databaseName" } ], "optional": false, "name": "io.debezium.connector.sqlserver.SchemaChangeKey", "version": 1 }, "payload": { "databaseName": "inventory" } } The payload of a schema change event message includes the following elements: databaseName The name of the database to which the statements are applied. The value of databaseName serves as the message key. tableChanges A structured representation of the entire table schema after the schema change. The tableChanges field contains an array that includes entries for each column of the table. Because the structured representation presents data in JSON or Avro format, consumers can easily read messages without first processing them through a DDL parser. Important When the connector is configured to capture a table, it stores the history of the table's schema changes not only in the schema change topic, but also in an internal database schema history topic. The internal database schema history topic is for connector use only and it is not intended for direct use by consuming applications. Ensure that applications that require notifications about schema changes consume that information only from the schema change topic. Warning The format of the messages that a connector emits to its schema change topic is in an incubating state and can change without notice. Debezium emits a message to the schema change topic when the following events occur: You enable CDC for a table. You disable CDC for a table. You alter the structure of a table for which CDC is enabled by following the schema evolution procedure . Example: Message emitted to the SQL Server connector schema change topic The following example shows a message in the schema change topic. The message contains a logical representation of the table schema. { "schema": { ... }, "payload": { "source": { "version": "2.7.3.Final", "connector": "sqlserver", "name": "server1", "ts_ms": 0, "snapshot": "true", "db": "testDB", "schema": "dbo", "table": "customers", "change_lsn": null, "commit_lsn": "00000025:00000d98:00a2", "event_serial_no": null }, "ts_ms": 1588252618953, 1 "databaseName": "testDB", 2 "schemaName": "dbo", "ddl": null, 3 "tableChanges": [ 4 { "type": "CREATE", 5 "id": "\"testDB\".\"dbo\".\"customers\"", 6 "table": { 7 "defaultCharsetName": null, "primaryKeyColumnNames": [ 8 "id" ], "columns": [ 9 { "name": "id", "jdbcType": 4, "nativeType": null, "typeName": "int identity", "typeExpression": "int identity", "charsetName": null, "length": 10, "scale": 0, "position": 1, "optional": false, "autoIncremented": false, "generated": false }, { "name": "first_name", "jdbcType": 12, "nativeType": null, "typeName": "varchar", "typeExpression": "varchar", "charsetName": null, "length": 255, "scale": null, "position": 2, "optional": false, "autoIncremented": false, "generated": false }, { "name": "last_name", "jdbcType": 12, "nativeType": null, "typeName": "varchar", "typeExpression": "varchar", "charsetName": null, "length": 255, "scale": null, "position": 3, "optional": false, "autoIncremented": false, "generated": false }, { "name": "email", "jdbcType": 12, "nativeType": null, "typeName": "varchar", "typeExpression": "varchar", "charsetName": null, "length": 255, "scale": null, "position": 4, "optional": false, "autoIncremented": false, "generated": false } ], "attributes": [ 10 { "customAttribute": "attributeValue" } ] } } ] } } Table 2.167. Descriptions of fields in messages emitted to the schema change topic Item Field name Description 1 ts_ms Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms, you can determine the lag between the source database update and Debezium. 2 databaseName schemaName Identifies the database and the schema that contain the change. 3 ddl Always null for the SQL Server connector. For other connectors, this field contains the DDL responsible for the schema change. This DDL is not available to SQL Server connectors. 4 tableChanges An array of one or more items that contain the schema changes generated by a DDL command. 5 type Describes the kind of change. The value is one of the following: CREATE - table created ALTER - table modified DROP - table deleted 6 id Full identifier of the table that was created, altered, or dropped. 7 table Represents table metadata after the applied change. 8 primaryKeyColumnNames List of columns that compose the table's primary key. 9 columns Metadata for each column in the changed table. 10 attributes Custom attribute metadata for each table change. In messages that the connector sends to the schema change topic, the key is the name of the database that contains the schema change. In the following example, the payload field contains the key: { "schema": { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "databaseName" } ], "optional": false, "name": "io.debezium.connector.sqlserver.SchemaChangeKey", "version": 1 }, "payload": { "databaseName": "testDB" } } 2.7.2.11. Descriptions of Debezium SQL Server connector data change events The Debezium SQL Server connector generates a data change event for each row-level INSERT , UPDATE , and DELETE operation. Each event contains a key and a value. The structure of the key and the value depends on the table that was changed. Debezium and Kafka Connect are designed around continuous streams of event messages . However, the structure of these events may change over time, which can be difficult for consumers to handle. To address this, each event contains the schema for its content or, if you are using a schema registry, a schema ID that a consumer can use to obtain the schema from the registry. This makes each event self-contained. The following skeleton JSON shows the basic four parts of a change event. However, how you configure the Kafka Connect converter that you choose to use in your application determines the representation of these four parts in change events. A schema field is in a change event only when you configure the converter to produce it. Likewise, the event key and event payload are in a change event only if you configure a converter to produce it. If you use the JSON converter and you configure it to produce all four basic change event parts, change events have this structure: { "schema": { 1 ... }, "payload": { 2 ... }, "schema": { 3 ... }, "payload": { 4 ... }, } Table 2.168. Overview of change event basic content Item Field name Description 1 schema The first schema field is part of the event key. It specifies a Kafka Connect schema that describes what is in the event key's payload portion. In other words, the first schema field describes the structure of the primary key, or the unique key if the table does not have a primary key, for the table that was changed. It is possible to override the table's primary key by setting the message.key.columns connector configuration property . In this case, the first schema field describes the structure of the key identified by that property. 2 payload The first payload field is part of the event key. It has the structure described by the schema field and it contains the key for the row that was changed. 3 schema The second schema field is part of the event value. It specifies the Kafka Connect schema that describes what is in the event value's payload portion. In other words, the second schema describes the structure of the row that was changed. Typically, this schema contains nested schemas. 4 payload The second payload field is part of the event value. It has the structure described by the schema field and it contains the actual data for the row that was changed. By default, the connector streams change event records to topics with names that are the same as the event's originating table. For more information, see topic names . Warning The SQL Server connector ensures that all Kafka Connect schema names adhere to the Avro schema name format . This means that the logical server name must start with a Latin letter or an underscore, that is, a-z, A-Z, or _. Each remaining character in the logical server name and each character in the database and table names must be a Latin letter, a digit, or an underscore, that is, a-z, A-Z, 0-9, or \_. If there is an invalid character it is replaced with an underscore character. This can lead to unexpected conflicts if the logical server name, a database name, or a table name contains invalid characters, and the only characters that distinguish names from one another are invalid and thus replaced with underscores. For details about change events, see the following topics: Section 2.7.2.11.1, "About keys in Debezium SQL Server change events" Section 2.7.2.11.2, "About values in Debezium SQL Server change events" 2.7.2.11.1. About keys in Debezium SQL Server change events A change event's key contains the schema for the changed table's key and the changed row's actual key. Both the schema and its corresponding payload contain a field for each column in the changed table's primary key (or unique key constraint) at the time the connector created the event. Consider the following customers table, which is followed by an example of a change event key for this table. Example table CREATE TABLE customers ( id INTEGER IDENTITY(1001,1) NOT NULL PRIMARY KEY, first_name VARCHAR(255) NOT NULL, last_name VARCHAR(255) NOT NULL, email VARCHAR(255) NOT NULL UNIQUE ); Example change event key Every change event that captures a change to the customers table has the same event key schema. For as long as the customers table has the definition, every change event that captures a change to the customers table has the following key structure, which in JSON, looks like this: { "schema": { 1 "type": "struct", "fields": [ 2 { "type": "int32", "optional": false, "field": "id" } ], "optional": false, 3 "name": "server1.testDB.dbo.customers.Key" 4 }, "payload": { 5 "id": 1004 } } Table 2.169. Description of change event key Item Field name Description 1 schema The schema portion of the key specifies a Kafka Connect schema that describes what is in the key's payload portion. 2 fields Specifies each field that is expected in the payload , including each field's name, type, and whether it is required. In this example, there is one required field named id of type int32 . 3 optional Indicates whether the event key must contain a value in its payload field. In this example, a value in the key's payload is required. A value in the key's payload field is optional when a table does not have a primary key. 4 server1.dbo.testDB.customers.Key Name of the schema that defines the structure of the key's payload. This schema describes the structure of the primary key for the table that was changed. Key schema names have the format connector-name . database-schema-name . table-name . Key . In this example: server1 is the name of the connector that generated this event. dbo is the database schema for the table that was changed. customers is the table that was updated. 5 payload Contains the key for the row for which this change event was generated. In this example, the key, contains a single id field whose value is 1004 . 2.7.2.11.2. About values in Debezium SQL Server change events The value in a change event is a bit more complicated than the key. Like the key, the value has a schema section and a payload section. The schema section contains the schema that describes the Envelope structure of the payload section, including its nested fields. Change events for operations that create, update or delete data all have a value payload with an envelope structure. Consider the same sample table that was used to show an example of a change event key: CREATE TABLE customers ( id INTEGER IDENTITY(1001,1) NOT NULL PRIMARY KEY, first_name VARCHAR(255) NOT NULL, last_name VARCHAR(255) NOT NULL, email VARCHAR(255) NOT NULL UNIQUE ); The value portion of a change event for a change to this table is described for each event type. create events update events delete events create events The following example shows the value portion of a change event that the connector generates for an operation that creates data in the customers table: { "schema": { 1 "type": "struct", "fields": [ { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "id" }, { "type": "string", "optional": false, "field": "first_name" }, { "type": "string", "optional": false, "field": "last_name" }, { "type": "string", "optional": false, "field": "email" } ], "optional": true, "name": "server1.dbo.testDB.customers.Value", 2 "field": "before" }, { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "id" }, { "type": "string", "optional": false, "field": "first_name" }, { "type": "string", "optional": false, "field": "last_name" }, { "type": "string", "optional": false, "field": "email" } ], "optional": true, "name": "server1.dbo.testDB.customers.Value", "field": "after" }, { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "version" }, { "type": "string", "optional": false, "field": "connector" }, { "type": "string", "optional": false, "field": "name" }, { "type": "int64", "optional": false, "field": "ts_ms" }, { "type": "int64", "optional": false, "field": "ts_us" }, { "type": "int64", "optional": false, "field": "ts_ns" }, { "type": "boolean", "optional": true, "default": false, "field": "snapshot" }, { "type": "string", "optional": false, "field": "db" }, { "type": "string", "optional": false, "field": "schema" }, { "type": "string", "optional": false, "field": "table" }, { "type": "string", "optional": true, "field": "change_lsn" }, { "type": "string", "optional": true, "field": "commit_lsn" }, { "type": "int64", "optional": true, "field": "event_serial_no" } ], "optional": false, "name": "io.debezium.connector.sqlserver.Source", 3 "field": "source" }, { "type": "string", "optional": false, "field": "op" }, { "type": "int64", "optional": true, "field": "ts_ms" }, { "type": "int64", "optional": true, "field": "ts_us" }, { "type": "int64", "optional": true, "field": "ts_ns" } ], "optional": false, "name": "server1.dbo.testDB.customers.Envelope" 4 }, "payload": { 5 "before": null, 6 "after": { 7 "id": 1005, "first_name": "john", "last_name": "doe", "email": "john.doe@example.org" }, "source": { 8 "version": "2.7.3.Final", "connector": "sqlserver", "name": "server1", "ts_ms": 1559729468470, "ts_us": 1559729468470000, "ts_ns": 1559729468470000000, "snapshot": false, "db": "testDB", "schema": "dbo", "table": "customers", "change_lsn": "00000027:00000758:0003", "commit_lsn": "00000027:00000758:0005", "event_serial_no": "1" }, "op": "c", 9 "ts_ms": 1559729471739, 10 "ts_ms": 1559729471739876, 11 "ts_ms": 1559729471739876149 12 } } Table 2.170. Descriptions of create event value fields Item Field name Description 1 schema The value's schema, which describes the structure of the value's payload. A change event's value schema is the same in every change event that the connector generates for a particular table. 2 name In the schema section, each name field specifies the schema for a field in the value's payload. server1.dbo.testDB.customers.Value is the schema for the payload's before and after fields. This schema is specific to the customers table. Names of schemas for before and after fields are of the form logicalName . database-schemaName . tableName .Value , which ensures that the schema name is unique in the database. This means that when using the Avro converter , the resulting Avro schema for each table in each logical source has its own evolution and history. 3 name io.debezium.connector.sqlserver.Source is the schema for the payload's source field. This schema is specific to the SQL Server connector. The connector uses it for all events that it generates. 4 name server1.dbo.testDB.customers.Envelope is the schema for the overall structure of the payload, where server1 is the connector name, dbo is the database schema name, and customers is the table. 5 payload The value's actual data. This is the information that the change event is providing. It may appear that the JSON representations of the events are much larger than the rows they describe. This is because the JSON representation must include the schema and the payload portions of the message. However, by using the Avro converter , you can significantly decrease the size of the messages that the connector streams to Kafka topics. 6 before An optional field that specifies the state of the row before the event occurred. When the op field is c for create, as it is in this example, the before field is null since this change event is for new content. 7 after An optional field that specifies the state of the row after the event occurred. In this example, the after field contains the values of the new row's id , first_name , last_name , and email columns. 8 source Mandatory field that describes the source metadata for the event. This field contains information that you can use to compare this event with other events, with regard to the origin of the events, the order in which the events occurred, and whether events were part of the same transaction. The source metadata includes: Debezium version Connector type and name Database and schema names Timestamp for when the change was made in the database If the event was part of a snapshot Name of the table that contains the new row Server log offsets 9 op Mandatory string that describes the type of operation that caused the connector to generate the event. In this example, c indicates that the operation created a row. Valid values are: c = create u = update d = delete r = read (applies to only snapshots) 10 ts_ms , ts_us , ts_ns Optional field that displays the time at which the connector processed the event. In the event message envelope, the time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time when a change was committed in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. update events The value of a change event for an update in the sample customers table has the same schema as a create event for that table. Likewise, the event value's payload has the same structure. However, the event value payload contains different values in an update event. Here is an example of a change event value in an event that the connector generates for an update in the customers table: { "schema": { ... }, "payload": { "before": { 1 "id": 1005, "first_name": "john", "last_name": "doe", "email": "john.doe@example.org" }, "after": { 2 "id": 1005, "first_name": "john", "last_name": "doe", "email": "noreply@example.org" }, "source": { 3 "version": "2.7.3.Final", "connector": "sqlserver", "name": "server1", "ts_ms": 1559729995937, "ts_us": 1559729995937000, "ts_ns": 1559729995937000000, "snapshot": false, "db": "testDB", "schema": "dbo", "table": "customers", "change_lsn": "00000027:00000ac0:0002", "commit_lsn": "00000027:00000ac0:0007", "event_serial_no": "2" }, "op": "u", 4 "ts_ms": 1559729998706, 5 "ts_us": 1559729998706318, 6 "ts_ns": 1559729998706318547 7 } } Table 2.171. Descriptions of update event value fields Item Field name Description 1 before An optional field that specifies the state of the row before the event occurred. In an update event value, the before field contains a field for each table column and the value that was in that column before the database commit. In this example, the email value is john.doe@example.org. 2 after An optional field that specifies the state of the row after the event occurred. You can compare the before and after structures to determine what the update to this row was. In the example, the email value is now noreply@example.org . 3 source Mandatory field that describes the source metadata for the event. The source field structure has the same fields as in a create event, but some values are different, for example, the sample update event has a different offset. The source metadata includes: Debezium version Connector type and name Database and schema names Timestamp for when the change was made in the database If the event was part of a snapshot Name of the table that contains the new row Server log offsets The event_serial_no field differentiates events that have the same commit and change LSN. Typical situations for when this field has a value other than 1 : update events have the value set to 2 because the update generates two events in the CDC change table of SQL Server ( see the source documentation for details ). The first event contains the old values and the second contains contains new values. The connector uses values in the first event to create the second event. The connector drops the first event. When a primary key is updated SQL Server emits two events. A delete event for the removal of the record with the old primary key value and a create event for the addition of the record with the new primary key. Both operations share the same commit and change LSN and their event numbers are 1 and 2 , respectively. 4 op Mandatory string that describes the type of operation. In an update event value, the op field value is u , signifying that this row changed because of an update. 5 ts_ms , ts_us , ts_ns Optional field that displays the time at which the connector processed the event. In the event message envelope, the time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time when the change was committed to the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. Note Updating the columns for a row's primary/unique key changes the value of the row's key. When a key changes, Debezium outputs three events: a delete event and a tombstone event with the old key for the row, followed by a create event with the new key for the row. delete events The value in a delete change event has the same schema portion as create and update events for the same table. The payload portion in a delete event for the sample customers table looks like this: { "schema": { ... }, }, "payload": { "before": { <> "id": 1005, "first_name": "john", "last_name": "doe", "email": "noreply@example.org" }, "after": null, 1 "source": { 2 "version": "2.7.3.Final", "connector": "sqlserver", "name": "server1", "ts_ms": 1559730445243, "ts_us": 1559730445243000, "ts_ns": 1559730445243000000, "snapshot": false, "db": "testDB", "schema": "dbo", "table": "customers", "change_lsn": "00000027:00000db0:0005", "commit_lsn": "00000027:00000db0:0007", "event_serial_no": "1" }, "op": "d", 3 "ts_ms": 1559730450205, 4 "ts_us": 1559730450205387, 5 "ts_ns": 1559730450205387492 6 } } Table 2.172. Descriptions of delete event value fields Item Field name Description 1 before Optional field that specifies the state of the row before the event occurred. In a delete event value, the before field contains the values that were in the row before it was deleted with the database commit. 2 after Optional field that specifies the state of the row after the event occurred. In a delete event value, the after field is null , signifying that the row no longer exists. 3 source Mandatory field that describes the source metadata for the event. In a delete event value, the source field structure is the same as for create and update events for the same table. Many source field values are also the same. In a delete event value, the ts_ms and pos field values, as well as other values, might have changed. But the source field in a delete event value provides the same metadata: Debezium version Connector type and name Database and schema names Timestamp for when the change was made in the database If the event was part of a snapshot Name of the table that contains the new row Server log offsets 4 op Mandatory string that describes the type of operation. The op field value is d , signifying that this row was deleted. 5 ts_ms , ts_us , ts_ns Optional field that displays the time at which the connector processed the event. In the event message envelope, the time is based on the system clock in the JVM running the Kafka Connect task. In the source object, ts_ms indicates the time that the change was made in the database. By comparing the value for payload.source.ts_ms with the value for payload.ts_ms , you can determine the lag between the source database update and Debezium. SQL Server connector events are designed to work with Kafka log compaction . Log compaction enables removal of some older messages as long as at least the most recent message for every key is kept. This lets Kafka reclaim storage space while ensuring that the topic contains a complete data set and can be used for reloading key-based state. Tombstone events When a row is deleted, the delete event value still works with log compaction, because Kafka can remove all earlier messages that have that same key. However, for Kafka to remove all messages that have that same key, the message value must be null . To make this possible, after Debezium's SQL Server connector emits a delete event, the connector emits a special tombstone event that has the same key but a null value. 2.7.2.12. Debezium SQL Server connector-generated events that represent transaction boundaries Debezium can generate events that represent transaction boundaries and that enrich data change event messages. Limits on when Debezium receives transaction metadata Debezium registers and receives metadata only for transactions that occur after you deploy the connector. Metadata for transactions that occur before you deploy the connector is not available. Database transactions are represented by a statement block that is enclosed between the BEGIN and END keywords. Debezium generates transaction boundary events for the BEGIN and END delimiters in every transaction. Transaction boundary events contain the following fields: status BEGIN or END . id String representation of the unique transaction identifier. ts_ms The time of a transaction boundary event ( BEGIN or END event) at the data source. If the data source does not provide Debezium with the event time, then the field instead represents the time at which Debezium processes the event. event_count (for END events) Total number of events emmitted by the transaction. data_collections (for END events) An array of pairs of data_collection and event_count elements that indicates the number of events that the connector emits for changes that originate from a data collection. Warning There is no way for Debezium to reliably identify when a transaction has ended. The transaction END marker is thus emitted only after the first event of another transaction arrives. This can lead to the delayed delivery of END marker in case of a low-traffic system. The following example shows a typical transaction boundary message: Example: SQL Server connector transaction boundary event { "status": "BEGIN", "id": "00000025:00000d08:0025", "ts_ms": 1486500577125, "event_count": null, "data_collections": null } { "status": "END", "id": "00000025:00000d08:0025", "ts_ms": 1486500577691, "event_count": 2, "data_collections": [ { "data_collection": "testDB.dbo.testDB.tablea", "event_count": 1 }, { "data_collection": "testDB.dbo.testDB.tableb", "event_count": 1 } ] } Unless overridden via the topic.transaction option, transaction events are written to the topic named <topic.prefix> .transaction . 2.7.2.12.1. Change data event enrichment When transaction metadata is enabled, the data message Envelope is enriched with a new transaction field. This field provides information about every event in the form of a composite of fields: id String representation of unique transaction identifier total_order The absolute position of the event among all events generated by the transaction data_collection_order The per-data collection position of the event among all events that were emitted by the transaction The following example shows what a typical message looks like: { "before": null, "after": { "pk": "2", "aa": "1" }, "source": { ... }, "op": "c", "ts_ms": "1580390884335", "ts_us": "1580390884335172", "ts_ns": "1580390884335172574", "transaction": { "id": "00000025:00000d08:0025", "total_order": "1", "data_collection_order": "1" } } 2.7.2.13. How Debezium SQL Server connectors map data types The Debezium SQL Server connector represents changes to table row data by producing events that are structured like the table in which the row exists. Each event contains fields to represent the column values for the row. The way in which an event represents the column values for an operation depends on the SQL data type of the column. In the event, the connector maps the fields for each SQL Server data type to both a literal type and a semantic type . The connector can map SQL Server data types to both literal and semantic types. Literal type Describes how the value is literally represented by using Kafka Connect schema types, namely INT8 , INT16 , INT32 , INT64 , FLOAT32 , FLOAT64 , BOOLEAN , STRING , BYTES , ARRAY , MAP , and STRUCT . Semantic type Describes how the Kafka Connect schema captures the meaning of the field using the name of the Kafka Connect schema for the field. If the default data type conversions do not meet your needs, you can create a custom converter for the connector. For more information about data type mappings, see the following sections: Basic types Temporal values Decimal values Timestamp values Basic types The following table shows how the connector maps basic SQL Server data types. Table 2.173. Data type mappings used by the SQL Server connector SQL Server data type Literal type (schema type) Semantic type (schema name) and Notes BIT BOOLEAN n/a TINYINT INT16 n/a SMALLINT INT16 n/a INT INT32 n/a BIGINT INT64 n/a REAL FLOAT32 n/a FLOAT[(N)] FLOAT64 n/a CHAR[(N)] STRING n/a VARCHAR[(N)] STRING n/a TEXT STRING n/a NCHAR[(N)] STRING n/a NVARCHAR[(N)] STRING n/a NTEXT STRING n/a XML STRING io.debezium.data.Xml Contains the string representation of an XML document DATETIMEOFFSET[(P)] STRING io.debezium.time.ZonedTimestamp A string representation of a timestamp with timezone information, where the timezone is GMT Other data type mappings are described in the following sections. If present, a column's default value is propagated to the corresponding field's Kafka Connect schema. Change messages will contain the field's default value (unless an explicit column value had been given), so there should rarely be the need to obtain the default value from the schema. Temporal values Other than SQL Server's DATETIMEOFFSET data type (which contain time zone information), the other temporal types depend on the value of the time.precision.mode configuration property. When the time.precision.mode configuration property is set to adaptive (the default), then the connector will determine the literal type and semantic type for the temporal types based on the column's data type definition so that events exactly represent the values in the database: SQL Server data type Literal type (schema type) Semantic type (schema name) and Notes DATE INT32 io.debezium.time.Date Represents the number of days since the epoch. TIME(0) , TIME(1) , TIME(2) , TIME(3) INT32 io.debezium.time.Time Represents the number of milliseconds past midnight, and does not include timezone information. TIME(4) , TIME(5) , TIME(6) INT64 io.debezium.time.MicroTime Represents the number of microseconds past midnight, and does not include timezone information. TIME(7) INT64 io.debezium.time.NanoTime Represents the number of nanoseconds past midnight, and does not include timezone information. DATETIME INT64 io.debezium.time.Timestamp Represents the number of milliseconds past the epoch, and does not include timezone information. SMALLDATETIME INT64 io.debezium.time.Timestamp Represents the number of milliseconds past the epoch, and does not include timezone information. DATETIME2(0) , DATETIME2(1) , DATETIME2(2) , DATETIME2(3) INT64 io.debezium.time.Timestamp Represents the number of milliseconds past the epoch, and does not include timezone information. DATETIME2(4) , DATETIME2(5) , DATETIME2(6) INT64 io.debezium.time.MicroTimestamp Represents the number of microseconds past the epoch, and does not include timezone information. DATETIME2(7) INT64 io.debezium.time.NanoTimestamp Represents the number of nanoseconds past the epoch, and does not include timezone information. When the time.precision.mode configuration property is set to connect , then the connector will use the predefined Kafka Connect logical types. This may be useful when consumers only know about the built-in Kafka Connect logical types and are unable to handle variable-precision time values. On the other hand, since SQL Server supports tenth of microsecond precision, the events generated by a connector with the connect time precision mode will result in a loss of precision when the database column has a fractional second precision value greater than 3: SQL Server data type Literal type (schema type) Semantic type (schema name) and Notes DATE INT32 org.apache.kafka.connect.data.Date Represents the number of days since the epoch. TIME([P]) INT64 org.apache.kafka.connect.data.Time Represents the number of milliseconds since midnight, and does not include timezone information. SQL Server allows P to be in the range 0-7 to store up to tenth of a microsecond precision, though this mode results in a loss of precision when P > 3. DATETIME INT64 org.apache.kafka.connect.data.Timestamp Represents the number of milliseconds since the epoch, and does not include timezone information. SMALLDATETIME INT64 org.apache.kafka.connect.data.Timestamp Represents the number of milliseconds past the epoch, and does not include timezone information. DATETIME2 INT64 org.apache.kafka.connect.data.Timestamp Represents the number of milliseconds since the epoch, and does not include timezone information. SQL Server allows P to be in the range 0-7 to store up to tenth of a microsecond precision, though this mode results in a loss of precision when P > 3. Timestamp values The DATETIME , SMALLDATETIME and DATETIME2 types represent a timestamp without time zone information. Such columns are converted into an equivalent Kafka Connect value based on UTC. So for instance the DATETIME2 value "2018-06-20 15:13:16.945104" is represented by a io.debezium.time.MicroTimestamp with the value "1529507596945104". Note that the timezone of the JVM running Kafka Connect and Debezium does not affect this conversion. Decimal values Debezium connectors handle decimals according to the setting of the decimal.handling.mode connector configuration property . decimal.handling.mode=precise Table 2.174. Mappings when decimal.handling.mode=precise SQL Server type Literal type (schema type) Semantic type (schema name) NUMERIC[(P[,S])] BYTES org.apache.kafka.connect.data.Decimal The scale schema parameter contains an integer that represents how many digits the decimal point shifted. DECIMAL[(P[,S])] BYTES org.apache.kafka.connect.data.Decimal The scale schema parameter contains an integer that represents how many digits the decimal point shifted. SMALLMONEY BYTES org.apache.kafka.connect.data.Decimal The scale schema parameter contains an integer that represents how many digits the decimal point shifted. MONEY BYTES org.apache.kafka.connect.data.Decimal The scale schema parameter contains an integer that represents how many digits the decimal point shifted. decimal.handling.mode=double Table 2.175. Mappings when decimal.handling.mode=double SQL Server type Literal type Semantic type NUMERIC[(M[,D])] FLOAT64 n/a DECIMAL[(M[,D])] FLOAT64 n/a SMALLMONEY[(M[,D])] FLOAT64 n/a MONEY[(M[,D])] FLOAT64 n/a decimal.handling.mode=string Table 2.176. Mappings when decimal.handling.mode=string SQL Server type Literal type Semantic type NUMERIC[(M[,D])] STRING n/a DECIMAL[(M[,D])] STRING n/a SMALLMONEY[(M[,D])] STRING n/a MONEY[(M[,D])] STRING n/a 2.7.3. Setting up SQL Server to run a Debezium connector For Debezium to capture change events from SQL Server tables, a SQL Server administrator with the necessary privileges must first run a query to enable CDC on the database. The administrator must then enable CDC for each table that you want Debezium to capture. Note By default, JDBC connections to Microsoft SQL Server are protected by SSL encryption. If SSL is not enabled for a SQL Server database, or if you want to connect to the database without using SSL, you can disable SSL by setting the value of the database.encrypt property in connector configuration to false . For details about setting up SQL Server for use with the Debezium connector, see the following sections: Section 2.7.3.1, "Enabling CDC on the SQL Server database" Section 2.7.3.2, "Enabling CDC on a SQL Server table" Section 2.7.3.3, "Verifying that the user has access to the CDC table" Section 2.7.3.4, "SQL Server on Azure" Section 2.7.3.5, "Effect of SQL Server capture job agent configuration on server load and latency" Section 2.7.3.6, "SQL Server capture job agent configuration parameters" After CDC is applied, it captures all of the INSERT , UPDATE , and DELETE operations that are committed to the tables for which CDC is enabled. The Debezium connector can then capture these events and emit them to Kafka topics. 2.7.3.1. Enabling CDC on the SQL Server database Before you can enable CDC for a table, you must enable it for the SQL Server database. A SQL Server administrator enables CDC by running a system stored procedure. System stored procedures can be run by using SQL Server Management Studio, or by using Transact-SQL. Prerequisites You are a member of the sysadmin fixed server role for the SQL Server. You are a db_owner of the database. The SQL Server Agent is running. Note The SQL Server CDC feature processes changes that occur in user-created tables only. You cannot enable CDC on the SQL Server master database. Procedure From the View menu in SQL Server Management Studio, click Template Explorer . In the Template Browser , expand SQL Server Templates . Expand Change Data Capture > Configuration and then click Enable Database for CDC . In the template, replace the database name in the USE statement with the name of the database that you want to enable for CDC. Run the stored procedure sys.sp_cdc_enable_db to enable the database for CDC. After the database is enabled for CDC, a schema with the name cdc is created, along with a CDC user, metadata tables, and other system objects. The following example shows how to enable CDC for the database MyDB : Example: Enabling a SQL Server database for the CDC template USE MyDB GO EXEC sys.sp_cdc_enable_db GO 2.7.3.2. Enabling CDC on a SQL Server table A SQL Server administrator must enable change data capture on the source tables that you want to Debezium to capture. The database must already be enabled for CDC. To enable CDC on a table, a SQL Server administrator runs the stored procedure sys.sp_cdc_enable_table for the table. The stored procedures can be run by using SQL Server Management Studio, or by using Transact-SQL. SQL Server CDC must be enabled for every table that you want to capture. Prerequisites CDC is enabled on the SQL Server database. The SQL Server Agent is running. You are a member of the db_owner fixed database role for the database. Procedure From the View menu in SQL Server Management Studio, click Template Explorer . In the Template Browser , expand SQL Server Templates . Expand Change Data Capture > Configuration , and then click Enable Table Specifying Filegroup Option . In the template, replace the table name in the USE statement with the name of the table that you want to capture. Run the stored procedure sys.sp_cdc_enable_table . The following example shows how to enable CDC for the table MyTable : Example: Enabling CDC for a SQL Server table USE MyDB GO EXEC sys.sp_cdc_enable_table @source_schema = N'dbo', @source_name = N'MyTable', //<.> @role_name = N'MyRole', //<.> @filegroup_name = N'MyDB_CT',//<.> @supports_net_changes = 0 GO <.> Specifies the name of the table that you want to capture. <.> Specifies a role MyRole to which you can add users to whom you want to grant SELECT permission on the captured columns of the source table. Users in the sysadmin or db_owner role also have access to the specified change tables. Set the value of @role_name to NULL , to allow only members in the sysadmin or db_owner to have full access to captured information. <.> Specifies the filegroup where SQL Server places the change table for the captured table. The named filegroup must already exist. It is best not to locate change tables in the same filegroup that you use for source tables. 2.7.3.3. Verifying that the user has access to the CDC table A SQL Server administrator can run a system stored procedure to query a database or table to retrieve its CDC configuration information. The stored procedures can be run by using SQL Server Management Studio, or by using Transact-SQL. Prerequisites You have SELECT permission on all of the captured columns of the capture instance. Members of the db_owner database role can view information for all of the defined capture instances. You have membership in any gating roles that are defined for the table information that the query includes. Procedure From the View menu in SQL Server Management Studio, click Object Explorer . From the Object Explorer, expand Databases , and then expand your database object, for example, MyDB . Expand Programmability > Stored Procedures > System Stored Procedures . Run the sys.sp_cdc_help_change_data_capture stored procedure to query the table. Queries should not return empty results. The following example runs the stored procedure sys.sp_cdc_help_change_data_capture on the database MyDB : Example: Querying a table for CDC configuration information USE MyDB; GO EXEC sys.sp_cdc_help_change_data_capture GO The query returns configuration information for each table in the database that is enabled for CDC and that contains change data that the caller is authorized to access. If the result is empty, verify that the user has privileges to access both the capture instance and the CDC tables. 2.7.3.4. SQL Server on Azure The Debezium SQL Server connector can be used with SQL Server on Azure. Refer to this example for configuring CDC for SQL Server on Azure and using it with Debezium. 2.7.3.5. Effect of SQL Server capture job agent configuration on server load and latency When a database administrator enables change data capture for a source table, the capture job agent begins to run. The agent reads new change event records from the transaction log and replicates the event records to a change data table. Between the time that a change is committed in the source table, and the time that the change appears in the corresponding change table, there is always a small latency interval. This latency interval represents a gap between when changes occur in the source table and when they become available for Debezium to stream to Apache Kafka. Ideally, for applications that must respond quickly to changes in data, you want to maintain close synchronization between the source and change tables. You might imagine that running the capture agent to continuously process change events as rapidly as possible might result in increased throughput and reduced latency - populating change tables with new event records as soon as possible after the events occur, in near real time. However, this is not necessarily the case. There is a performance penalty to pay in the pursuit of more immediate synchronization. Each time that the capture job agent queries the database for new event records, it increases the CPU load on the database host. The additional load on the server can have a negative effect on overall database performance, and potentially reduce transaction efficiency, especially during times of peak database use. It's important to monitor database metrics so that you know if the database reaches the point where the server can no longer support the capture agent's level of activity. If you notice performance problems, there are SQL Server capture agent settings that you can modify to help balance the overall CPU load on the database host with a tolerable degree of latency. 2.7.3.6. SQL Server capture job agent configuration parameters On SQL Server, parameters that control the behavior of the capture job agent are defined in the SQL Server table msdb.dbo.cdc_jobs . If you experience performance issues while running the capture job agent, adjust capture jobs settings to reduce CPU load by running the sys.sp_cdc_change_job stored procedure and supplying new values. Note Specific guidance about how to configure SQL Server capture job agent parameters is beyond the scope of this documentation. The following parameters are the most significant for modifying capture agent behavior for use with the Debezium SQL Server connector: pollinginterval Specifies the number of seconds that the capture agent waits between log scan cycles. A higher value reduces the load on the database host and increases latency. A value of 0 specifies no wait between scans. The default value is 5 . maxtrans Specifies the maximum number of transactions to process during each log scan cycle. After the capture job processes the specified number of transactions, it pauses for the length of time that the pollinginterval specifies before the scan begins. A lower value reduces the load on the database host and increases latency. The default value is 500 . maxscans Specifies a limit on the number of scan cycles that the capture job can attempt in capturing the full contents of the database transaction log. If the continuous parameter is set to 1 , the job pauses for the length of time that the pollinginterval specifies before it resumes scanning. A lower values reduces the load on the database host and increases latency. The default value is 10 . Additional resources For more information about capture agent parameters, see the SQL Server documentation. 2.7.4. Deployment of Debezium SQL Server connectors You can use either of the following methods to deploy a Debezium SQL Server connector: Use Streams for Apache Kafka to automatically create an image that includes the connector plug-in . This is the preferred method. Build a custom Kafka Connect container image from a Dockerfile . Additional resources Section 2.7.4.4, "Descriptions of Debezium SQL Server connector configuration properties" 2.7.4.1. SQL Server connector deployment using Streams for Apache Kafka Beginning with Debezium 1.7, the preferred method for deploying a Debezium connector is to use Streams for Apache Kafka to build a Kafka Connect container image that includes the connector plug-in. During the deployment process, you create and use the following custom resources (CRs): A KafkaConnect CR that defines your Kafka Connect instance and includes information about the connector artifacts needs to include in the image. A KafkaConnector CR that provides details that include information the connector uses to access the source database. After Streams for Apache Kafka starts the Kafka Connect pod, you start the connector by applying the KafkaConnector CR. In the build specification for the Kafka Connect image, you can specify the connectors that are available to deploy. For each connector plug-in, you can also specify other components that you want to make available for deployment. For example, you can add Apicurio Registry artifacts, or the Debezium scripting component. When Streams for Apache Kafka builds the Kafka Connect image, it downloads the specified artifacts, and incorporates them into the image. The spec.build.output parameter in the KafkaConnect CR specifies where to store the resulting Kafka Connect container image. Container images can be stored in a Docker registry, or in an OpenShift ImageStream. To store images in an ImageStream, you must create the ImageStream before you deploy Kafka Connect. ImageStreams are not created automatically. Note If you use a KafkaConnect resource to create a cluster, afterwards you cannot use the Kafka Connect REST API to create or update connectors. You can still use the REST API to retrieve information. Additional resources Configuring Kafka Connect in Deploying and Managing Streams for Apache Kafka on OpenShift. Building a new container image automatically in Deploying and Managing Streams for Apache Kafka on OpenShift. 2.7.4.2. Using Streams for Apache Kafka to deploy a Debezium SQL Server connector With earlier versions of Streams for Apache Kafka, to deploy Debezium connectors on OpenShift, you were required to first build a Kafka Connect image for the connector. The current preferred method for deploying connectors on OpenShift is to use a build configuration in Streams for Apache Kafka to automatically build a Kafka Connect container image that includes the Debezium connector plug-ins that you want to use. During the build process, the Streams for Apache Kafka Operator transforms input parameters in a KafkaConnect custom resource, including Debezium connector definitions, into a Kafka Connect container image. The build downloads the necessary artifacts from the Red Hat Maven repository or another configured HTTP server. The newly created container is pushed to the container registry that is specified in .spec.build.output , and is used to deploy a Kafka Connect cluster. After Streams for Apache Kafka builds the Kafka Connect image, you create KafkaConnector custom resources to start the connectors that are included in the build. Prerequisites You have access to an OpenShift cluster on which the cluster Operator is installed. The Streams for Apache Kafka Operator is running. An Apache Kafka cluster is deployed as documented in Deploying and Managing Streams for Apache Kafka on OpenShift . Kafka Connect is deployed on Streams for Apache Kafka You have a Red Hat build of Debezium license. The OpenShift oc CLI client is installed or you have access to the OpenShift Container Platform web console. Depending on how you intend to store the Kafka Connect build image, you need registry permissions or you must create an ImageStream resource: To store the build image in an image registry, such as Red Hat Quay.io or Docker Hub An account and permissions to create and manage images in the registry. To store the build image as a native OpenShift ImageStream An ImageStream resource is deployed to the cluster for storing new container images. You must explicitly create an ImageStream for the cluster. ImageStreams are not available by default. For more information about ImageStreams, see Managing image streams in the OpenShift Container Platform documentation. Procedure Log in to the OpenShift cluster. Create a Debezium KafkaConnect custom resource (CR) for the connector, or modify an existing one. For example, create a KafkaConnect CR with the name dbz-connect.yaml that specifies the metadata.annotations and spec.build properties. The following example shows an excerpt from a dbz-connect.yaml file that describes a KafkaConnect custom resource. Example 2.50. A dbz-connect.yaml file that defines a KafkaConnect custom resource that includes a Debezium connector In the example that follows, the custom resource is configured to download the following artifacts: The Debezium SQL Server connector archive. The Red Hat build of Apicurio Registry archive. The Apicurio Registry is an optional component. Add the Apicurio Registry component only if you intend to use Avro serialization with the connector. The Debezium scripting SMT archive and the associated scripting engine that you want to use with the Debezium connector. The SMT archive and scripting language dependencies are optional components. Add these components only if you intend to use the Debezium content-based routing SMT or filter SMT . apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: debezium-kafka-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: version: 3.6.0 build: 2 output: 3 type: imagestream 4 image: debezium-streams-connect:latest plugins: 5 - name: debezium-connector-sqlserver artifacts: - type: zip 6 url: https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-sqlserver/2.7.3.Final-redhat-00001/debezium-connector-sqlserver-2.7.3.Final-redhat-00001-plugin.zip 7 - type: zip url: https://maven.repository.redhat.com/ga/io/apicurio/apicurio-registry-distro-connect-converter/2.4.4.Final-redhat- <build-number> /apicurio-registry-distro-connect-converter-2.4.4.Final-redhat- <build-number> .zip 8 - type: zip url: https://maven.repository.redhat.com/ga/io/debezium/debezium-scripting/2.7.3.Final-redhat-00001/debezium-scripting-2.7.3.Final-redhat-00001.zip 9 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy/3.0.11/groovy-3.0.11.jar 10 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-jsr223/3.0.11/groovy-jsr223-3.0.11.jar - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-json3.0.11/groovy-json-3.0.11.jar bootstrapServers: debezium-kafka-cluster-kafka-bootstrap:9093 ... Table 2.177. Descriptions of Kafka Connect configuration settings Item Description 1 Sets the strimzi.io/use-connector-resources annotation to "true" to enable the Cluster Operator to use KafkaConnector resources to configure connectors in this Kafka Connect cluster. 2 The spec.build configuration specifies where to store the build image and lists the plug-ins to include in the image, along with the location of the plug-in artifacts. 3 The build.output specifies the registry in which the newly built image is stored. 4 Specifies the name and image name for the image output. Valid values for output.type are docker to push into a container registry such as Docker Hub or Quay, or imagestream to push the image to an internal OpenShift ImageStream. To use an ImageStream, an ImageStream resource must be deployed to the cluster. For more information about specifying the build.output in the KafkaConnect configuration, see the Streams for Apache Kafka Build schema reference in {NameConfiguringStreamsOpenShift}. 5 The plugins configuration lists all of the connectors that you want to include in the Kafka Connect image. For each entry in the list, specify a plug-in name , and information for about the artifacts that are required to build the connector. Optionally, for each connector plug-in, you can include other components that you want to be available for use with the connector. For example, you can add Service Registry artifacts, or the Debezium scripting component. 6 The value of artifacts.type specifies the file type of the artifact specified in the artifacts.url . Valid types are zip , tgz , or jar . Debezium connector archives are provided in .zip file format. The type value must match the type of the file that is referenced in the url field. 7 The value of artifacts.url specifies the address of an HTTP server, such as a Maven repository, that stores the file for the connector artifact. Debezium connector artifacts are available in the Red Hat Maven repository. The OpenShift cluster must have access to the specified server. 8 (Optional) Specifies the artifact type and url for downloading the Apicurio Registry component. Include the Apicurio Registry artifact, only if you want the connector to use Apache Avro to serialize event keys and values with the Red Hat build of Apicurio Registry, instead of using the default JSON converter. 9 (Optional) Specifies the artifact type and url for the Debezium scripting SMT archive to use with the Debezium connector. Include the scripting SMT only if you intend to use the Debezium content-based routing SMT or filter SMT To use the scripting SMT, you must also deploy a JSR 223-compliant scripting implementation, such as groovy. 10 (Optional) Specifies the artifact type and url for the JAR files of a JSR 223-compliant scripting implementation, which is required by the Debezium scripting SMT. Important If you use Streams for Apache Kafka to incorporate the connector plug-in into your Kafka Connect image, for each of the required scripting language components artifacts.url must specify the location of a JAR file, and the value of artifacts.type must also be set to jar . Invalid values cause the connector fails at runtime. To enable use of the Apache Groovy language with the scripting SMT, the custom resource in the example retrieves JAR files for the following libraries: groovy groovy-jsr223 (scripting agent) groovy-json (module for parsing JSON strings) As an alternative, the Debezium scripting SMT also supports the use of the JSR 223 implementation of GraalVM JavaScript. Apply the KafkaConnect build specification to the OpenShift cluster by entering the following command: oc create -f dbz-connect.yaml Based on the configuration specified in the custom resource, the Streams Operator prepares a Kafka Connect image to deploy. After the build completes, the Operator pushes the image to the specified registry or ImageStream, and starts the Kafka Connect cluster. The connector artifacts that you listed in the configuration are available in the cluster. Create a KafkaConnector resource to define an instance of each connector that you want to deploy. For example, create the following KafkaConnector CR, and save it as sqlserver-inventory-connector.yaml Example 2.51. sqlserver-inventory-connector.yaml file that defines the KafkaConnector custom resource for a Debezium connector apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: labels: strimzi.io/cluster: debezium-kafka-connect-cluster name: inventory-connector-sqlserver 1 spec: class: io.debezium.connector.sqlserver.SqlServerConnector 2 tasksMax: 1 3 config: 4 schema.history.internal.kafka.bootstrap.servers: debezium-kafka-cluster-kafka-bootstrap.debezium.svc.cluster.local:9092 schema.history.internal.kafka.topic: schema-changes.inventory database.hostname: sqlserver.debezium-sqlserver.svc.cluster.local 5 database.port: 1433 6 database.user: debezium 7 database.password: dbz 8 topic.prefix: inventory-connector-sqlserver 9 table.include.list: dbo.customers 10 ... Table 2.178. Descriptions of connector configuration settings Item Description 1 The name of the connector to register with the Kafka Connect cluster. 2 The name of the connector class. 3 The number of tasks that can operate concurrently. 4 The connector's configuration. 5 The address of the host database instance. 6 The port number of the database instance. 7 The name of the account that Debezium uses to connect to the database. 8 The password that Debezium uses to connect to the database user account. 9 The topic prefix for the database instance or cluster. The specified name must be formed only from alphanumeric characters or underscores. Because the topic prefix is used as the prefix for any Kafka topics that receive change events from this connector, the name must be unique among the connectors in the cluster. This namespace is also used in the names of related Kafka Connect schemas, and the namespaces of a corresponding Avro schema if you integrate the connector with the Avro connector . 10 The list of tables from which the connector captures change events. Create the connector resource by running the following command: oc create -n <namespace> -f <kafkaConnector> .yaml For example, oc create -n debezium -f sqlserver-inventory-connector.yaml The connector is registered to the Kafka Connect cluster and starts to run against the database that is specified by spec.config.database.dbname in the KafkaConnector CR. After the connector pod is ready, Debezium is running. You are now ready to verify the Debezium SQL Server deployment . 2.7.4.3. Deploying a Debezium SQL Server connector by building a custom Kafka Connect container image from a Dockerfile To deploy a Debezium SQL Server connector, you must build a custom Kafka Connect container image that contains the Debezium connector archive, and then push this container image to a container registry. You then need to create the following custom resources (CRs): A KafkaConnect CR that defines your Kafka Connect instance. The image property in the CR specifies the name of the container image that you create to run your Debezium connector. You apply this CR to the OpenShift instance where Red Hat Streams for Apache Kafka is deployed. Streams for Apache Kafka offers operators and images that bring Apache Kafka to OpenShift. A KafkaConnector CR that defines your Debezium SQL Server connector. Apply this CR to the same OpenShift instance where you apply the KafkaConnect CR. Prerequisites SQL Server is running and you completed the steps to set up SQL Server to work with a Debezium connector . Streams for Apache Kafka is deployed on OpenShift and is running Apache Kafka and Kafka Connect. For more information, see Deploying and Managing Streams for Apache Kafka on OpenShift Podman or Docker is installed. You have an account and permissions to create and manage containers in the container registry (such as quay.io or docker.io ) to which you plan to add the container that will run your Debezium connector. Procedure Create the Debezium SQL Server container for Kafka Connect: Create a Dockerfile that uses registry.redhat.io/amq-streams-kafka-35-rhel8:2.5.0 as the base image. For example, from a terminal window, enter the following command: cat <<EOF >debezium-container-for-sqlserver.yaml 1 FROM registry.redhat.io/amq-streams-kafka-35-rhel8:2.5.0 USER root:root RUN mkdir -p /opt/kafka/plugins/debezium 2 RUN cd /opt/kafka/plugins/debezium/ \ && curl -O https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-sqlserver/2.7.3.Final-redhat-00001/debezium-connector-sqlserver-2.7.3.Final-redhat-00001-plugin.zip \ && unzip debezium-connector-sqlserver-2.7.3.Final-redhat-00001-plugin.zip \ && rm debezium-connector-sqlserver-2.7.3.Final-redhat-00001-plugin.zip RUN cd /opt/kafka/plugins/debezium/ USER 1001 EOF Item Description 1 You can specify any file name that you want. 2 Specifies the path to your Kafka Connect plug-ins directory. If your Kafka Connect plug-ins directory is in a different location, replace this path with the actual path of your directory. The command creates a Dockerfile with the name debezium-container-for-sqlserver.yaml in the current directory. Build the container image from the debezium-container-for-sqlserver.yaml Docker file that you created in the step. From the directory that contains the file, open a terminal window and enter one of the following commands: podman build -t debezium-container-for-sqlserver:latest . docker build -t debezium-container-for-sqlserver:latest . The preceding commands build a container image with the name debezium-container-for-sqlserver . Push your custom image to a container registry, such as quay.io or an internal container registry. The container registry must be available to the OpenShift instance where you want to deploy the image. Enter one of the following commands: podman push <myregistry.io> /debezium-container-for-sqlserver:latest docker push <myregistry.io> /debezium-container-for-sqlserver:latest Create a new Debezium SQL Server KafkaConnect custom resource (CR). For example, create a KafkaConnect CR with the name dbz-connect.yaml that specifies annotations and image properties. The following example shows an excerpt from a dbz-connect.yaml file that describes a KafkaConnect custom resource. apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: #... image: debezium-container-for-sqlserver 2 ... Item Description 1 metadata.annotations indicates to the Cluster Operator that KafkaConnector resources are used to configure connectors in this Kafka Connect cluster. 2 spec.image specifies the name of the image that you created to run your Debezium connector. This property overrides the STRIMZI_DEFAULT_KAFKA_CONNECT_IMAGE variable in the Cluster Operator. Apply the KafkaConnect CR to the OpenShift Kafka Connect environment by entering the following command: oc create -f dbz-connect.yaml The command adds a Kafka Connect instance that specifies the name of the image that you created to run your Debezium connector. Create a KafkaConnector custom resource that configures your Debezium SQL Server connector instance. You configure a Debezium SQL Server connector in a .yaml file that specifies the configuration properties for the connector. The connector configuration might instruct Debezium to produce events for a subset of the schemas and tables, or it might set properties so that Debezium ignores, masks, or truncates values in specified columns that are sensitive, too large, or not needed. The following example configures a Debezium connector that connects to a SQL server host, 192.168.99.100 , on port 1433 . This host has a database named testDB , a table with the name customers , and inventory-connector-sqlserver is the server's logical name. SQL Server inventory-connector.yaml apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: inventory-connector-sqlserver 1 labels: strimzi.io/cluster: my-connect-cluster annotations: strimzi.io/use-connector-resources: 'true' spec: class: io.debezium.connector.sqlserver.SqlServerConnector 2 config: database.hostname: 192.168.99.100 3 database.port: 1433 4 database.user: debezium 5 database.password: dbz 6 topic.prefix: inventory-connector-sqlserver 7 table.include.list: dbo.customers 8 schema.history.internal.kafka.bootstrap.servers: my-cluster-kafka-bootstrap:9092 9 schema.history.internal.kafka.topic: schemahistory.fullfillment 10 database.ssl.truststore: path/to/trust-store 11 database.ssl.truststore.password: password-for-trust-store 12 Table 2.179. Descriptions of connector configuration settings Item Description 1 The name of our connector when we register it with a Kafka Connect service. 2 The name of this SQL Server connector class. 3 The address of the SQL Server instance. 4 The port number of the SQL Server instance. 5 The name of the SQL Server user. 6 The password for the SQL Server user. 7 The topic prefix for the SQL Server instance/cluster, which forms a namespace and is used in all the names of the Kafka topics to which the connector writes, the Kafka Connect schema names, and the namespaces of the corresponding Avro schema when the Avro converter is used. 8 The connector captures changes from the dbo.customers table only. 9 The list of Kafka brokers that this connector will use to write and recover DDL statements to the database schema history topic. 10 The name of the database schema history topic where the connector will write and recover DDL statements. This topic is for internal use only and should not be used by consumers. 11 The path to the SSL truststore that stores the server's signer certificates. This property is required unless database encryption is disabled ( database.encrypt=false ). 12 The SSL truststore password. This property is required unless database encryption is disabled ( database.encrypt=false ). Create your connector instance with Kafka Connect. For example, if you saved your KafkaConnector resource in the inventory-connector.yaml file, you would run the following command: oc apply -f inventory-connector.yaml The preceding command registers inventory-connector and the connector starts to run against the testDB database as defined in the KafkaConnector CR. Verifying that the Debezium SQL Server connector is running If the connector starts correctly without errors, it creates a topic for each table that the connector is configured to capture. Downstream applications can subscribe to these topics to retrieve information events that occur in the source database. To verify that the connector is running, you perform the following operations from the OpenShift Container Platform web console, or through the OpenShift CLI tool (oc): Verify the connector status. Verify that the connector generates topics. Verify that topics are populated with events for read operations ("op":"r") that the connector generates during the initial snapshot of each table. Prerequisites A Debezium connector is deployed to Streams for Apache Kafka on OpenShift. The OpenShift oc CLI client is installed. You have access to the OpenShift Container Platform web console. Procedure Check the status of the KafkaConnector resource by using one of the following methods: From the OpenShift Container Platform web console: Navigate to Home Search . On the Search page, click Resources to open the Select Resource box, and then type KafkaConnector . From the KafkaConnectors list, click the name of the connector that you want to check, for example inventory-connector-sqlserver . In the Conditions section, verify that the values in the Type and Status columns are set to Ready and True . From a terminal window: Enter the following command: oc describe KafkaConnector <connector-name> -n <project> For example, oc describe KafkaConnector inventory-connector-sqlserver -n debezium The command returns status information that is similar to the following output: Example 2.52. KafkaConnector resource status Name: inventory-connector-sqlserver Namespace: debezium Labels: strimzi.io/cluster=debezium-kafka-connect-cluster Annotations: <none> API Version: kafka.strimzi.io/v1beta2 Kind: KafkaConnector ... Status: Conditions: Last Transition Time: 2021-12-08T17:41:34.897153Z Status: True Type: Ready Connector Status: Connector: State: RUNNING worker_id: 10.131.1.124:8083 Name: inventory-connector-sqlserver Tasks: Id: 0 State: RUNNING worker_id: 10.131.1.124:8083 Type: source Observed Generation: 1 Tasks Max: 1 Topics: inventory-connector-sqlserver.inventory inventory-connector-sqlserver.inventory.addresses inventory-connector-sqlserver.inventory.customers inventory-connector-sqlserver.inventory.geom inventory-connector-sqlserver.inventory.orders inventory-connector-sqlserver.inventory.products inventory-connector-sqlserver.inventory.products_on_hand Events: <none> Verify that the connector created Kafka topics: From the OpenShift Container Platform web console. Navigate to Home Search . On the Search page, click Resources to open the Select Resource box, and then type KafkaTopic . From the KafkaTopics list, click the name of the topic that you want to check, for example, inventory-connector-sqlserver.inventory.orders---ac5e98ac6a5d91e04d8ec0dc9078a1ece439081d . In the Conditions section, verify that the values in the Type and Status columns are set to Ready and True . From a terminal window: Enter the following command: oc get kafkatopics The command returns status information that is similar to the following output: Example 2.53. KafkaTopic resource status Check topic content. From a terminal window, enter the following command: oc exec -n <project> -it <kafka-cluster> -- /opt/kafka/bin/kafka-console-consumer.sh \ > --bootstrap-server localhost:9092 \ > --from-beginning \ > --property print.key=true \ > --topic= <topic-name > For example, oc exec -n debezium -it debezium-kafka-cluster-kafka-0 -- /opt/kafka/bin/kafka-console-consumer.sh \ > --bootstrap-server localhost:9092 \ > --from-beginning \ > --property print.key=true \ > --topic=inventory-connector-sqlserver.inventory.products_on_hand The format for specifying the topic name is the same as the oc describe command returns in Step 1, for example, inventory-connector-sqlserver.inventory.addresses . For each event in the topic, the command returns information that is similar to the following output: Example 2.54. Content of a Debezium change event In the preceding example, the payload value shows that the connector snapshot generated a read ( "op" ="r" ) event from the table inventory.products_on_hand . The "before" state of the product_id record is null , indicating that no value exists for the record. The "after" state shows a quantity of 3 for the item with product_id 101 . For the complete list of the configuration properties that you can set for the Debezium SQL Server connector, see SQL Server connector properties . Results When the connector starts, it performs a consistent snapshot of the SQL Server databases that the connector is configured for. The connector then starts generating data change events for row-level operations and streaming the change event records to Kafka topics. 2.7.4.4. Descriptions of Debezium SQL Server connector configuration properties The Debezium SQL Server connector has numerous configuration properties that you can use to achieve the right connector behavior for your application. Many properties have default values. Information about the properties is organized as follows: Required connector configuration properties Advanced connector configuration properties Database schema history connector configuration properties that control how Debezium processes events that it reads from the database schema history topic. Pass-through SQL Server connector configuration properties Pass-through database schema history properties for configuring producer and consumer clients Pass-through Kafka signals configuration properties Pass-through Kafka signals consumer client configuration properties Pass-through sink notification configuration properties Pass-through database driver configuration properties Required Debezium SQL Server connector configuration properties The following configuration properties are required unless a default value is available. Property Default Description name No default Unique name for the connector. Attempting to register again with the same name will fail. (This property is required by all Kafka Connect connectors.) connector.class No default The name of the Java class for the connector. Always use a value of io.debezium.connector.sqlserver.SqlServerConnector for the SQL Server connector. tasks.max 1 Specifies the maximum number of tasks that the connector can use to capture data from the database instance. database.hostname No default IP address or hostname of the SQL Server database server. database.port 1433 Integer port number of the SQL Server database server. If both database.port and database.instance are specified, database.instance is ignored. See JDBC driver for SQL server documentation for more details. database.user No default Username to use when connecting to the SQL Server database server. Can be omitted when using Kerberos authentication, which can be configured using pass-through properties . database.password No default Password to use when connecting to the SQL Server database server. database.instance No default Specifies the instance name of the SQL Server named instance . If both database.port and database.instance are specified, database.instance is ignored. See JDBC driver for SQL server documentation for more details. topic.prefix No default Topic prefix that provides a namespace for the SQL Server database server that you want Debezium to capture. The prefix should be unique across all other connectors, since it is used as the prefix for all Kafka topic names that receive records from this connector. Only alphanumeric characters, hyphens, dots and underscores must be used in the database server logical name. Warning Do not change the value of this property. If you change the name value, after a restart, instead of continuing to emit events to the original topics, the connector emits subsequent events to topics whose names are based on the new value. The connector is also unable to recover its database schema history topic. schema.include.list No default An optional, comma-separated list of regular expressions that match names of schemas for which you want to capture changes. Any schema name not included in schema.include.list is excluded from having its changes captured. By default, the connector captures changes for all non-system schemas. To match the name of a schema, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the schema; it does not match substrings that might be present in a schema name. If you include this property in the configuration, do not also set the schema.exclude.list property. schema.exclude.list No default An optional, comma-separated list of regular expressions that match names of schemas for which you do not want to capture changes. Any schema whose name is not included in schema.exclude.list has its changes captured, with the exception of system schemas. To match the name of a schema, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the schema; it does not match substrings that might be present in a schema name. If you include this property in the configuration, do not set the schema.include.list property. table.include.list No default An optional comma-separated list of regular expressions that match fully-qualified table identifiers for tables that you want Debezium to capture. By default, the connector captures all non-system tables for the designated schemas. When this property is set, the connector captures changes only from the specified tables. Each identifier is of the form schemaName . tableName . To match the name of a table, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the table; it does not match substrings that might be present in a table name. If you include this property in the configuration, do not also set the table.exclude.list property. table.exclude.list No default An optional comma-separated list of regular expressions that match fully-qualified table identifiers for the tables that you want to exclude from being captured. Debezium captures all tables that are not included in table.exclude.list . Each identifier is of the form schemaName . tableName . To match the name of a table, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the table; it does not match substrings that might be present in a table name. If you include this property in the configuration, do not also set the table.include.list property. column.include.list empty string An optional comma-separated list of regular expressions that match the fully-qualified names of columns that should be included in the change event message values. Fully-qualified names for columns are of the form schemaName . tableName . columnName . Note Each change event record that Debezium emits for a table includes an event key that contains fields for each column in the table's primary key or unique key. To ensure that event keys are generated correctly, if you set this property, be sure to explicitly list the primary key columns of any captured tables. To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; it does not match substrings that might be present in a column name. If you include this property in the configuration, do not also set the column.exclude.list property. column.exclude.list empty string An optional comma-separated list of regular expressions that match the fully-qualified names of columns that should be excluded from change event message values. Fully-qualified names for columns are of the form schemaName . tableName . columnName . Note that primary key columns are always included in the event's key, also if excluded from the value. To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; it does not match substrings that might be present in a column name. If you include this property in the configuration, do not also set the column.include.list property. skip.messages.without.change false Specifies whether to skip publishing messages when there is no change in included columns. This would essentially filter messages if there is no change in columns included as per column.include.list or column.exclude.list properties. column.mask.hash. hashAlgorithm .with.salt. salt ; column.mask.hash.v2. hashAlgorithm .with.salt. salt n/a An optional, comma-separated list of regular expressions that match the fully-qualified names of character-based columns. Fully-qualified names for columns are of the form `<schemaName> . <tableName> . <columnName>`. To match the name of a column Debezium applies the regular expression that you specify as an _anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. In the resulting change event record, the values for the specified columns are replaced with pseudonyms. A pseudonym consists of the hashed value that results from applying the specified hashAlgorithm and salt . Based on the hash function that is used, referential integrity is maintained, while column values are replaced with pseudonyms. Supported hash functions are described in the MessageDigest section of the Java Cryptography Architecture Standard Algorithm Name Documentation. In the following example, CzQMA0cB5K is a randomly selected salt. If necessary, the pseudonym is automatically shortened to the length of the column. The connector configuration can include multiple properties that specify different hash algorithms and salts. Depending on the hashAlgorithm used, the salt selected, and the actual data set, the resulting data set might not be completely masked. Hashing strategy version 2 should be used to ensure fidelity if the value is being hashed in different places or systems. time.precision.mode adaptive Time, date, and timestamps can be represented with different kinds of precision, including: adaptive (the default) captures the time and timestamp values exactly as in the database using either millisecond, microsecond, or nanosecond precision values based on the database column's type; or connect always represents time and timestamp values using Kafka Connect's built-in representations for Time, Date, and Timestamp, which uses millisecond precision regardless of the database columns' precision. For more information, see temporal values . decimal.handling.mode precise Specifies how the connector should handle values for DECIMAL and NUMERIC columns: precise (the default) represents them precisely using java.math.BigDecimal values represented in change events in a binary form. double represents them using double values, which may result in a loss of precision but is easier to use. string encodes values as formatted strings, which is easy to consume but semantic information about the real type is lost. include.schema.changes true Boolean value that specifies whether the connector should publish changes in the database schema to a Kafka topic with the same name as the database server ID. Each schema change is recorded with a key that contains the database name and a value that is a JSON structure that describes the schema update. This is independent of how the connector internally records database schema history. The default is true . tombstones.on.delete true Controls whether a delete event is followed by a tombstone event. true - a delete operation is represented by a delete event and a subsequent tombstone event. false - only a delete event is emitted. After a source record is deleted, emitting a tombstone event (the default behavior) allows Kafka to completely delete all events that pertain to the key of the deleted row in case log compaction is enabled for the topic. column.truncate.to. length .chars n/a An optional, comma-separated list of regular expressions that match the fully-qualified names of character-based columns. Set this property if you want to truncate the data in a set of columns when it exceeds the number of characters specified by the length in the property name. Set length to a positive integer value, for example, column.truncate.to.20.chars . The fully-qualified name of a column observes the following format: <schemaName> . <tableName> . <columnName> . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. You can specify multiple properties with different lengths in a single configuration. column.mask.with. length .chars n/a Fully-qualified names for columns are of the form schemaName . tableName . columnName . An optional, comma-separated list of regular expressions that match the fully-qualified names of character-based columns. Set this property if you want the connector to mask the values for a set of columns, for example, if they contain sensitive data. Set length to a positive integer to replace data in the specified columns with the number of asterisk ( * ) characters specified by the length in the property name. Set length to 0 (zero) to replace data in the specified columns with an empty string. The fully-qualified name of a column observes the following format: schemaName . tableName . columnName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. You can specify multiple properties with different lengths in a single configuration. column.propagate.source.type n/a An optional, comma-separated list of regular expressions that match the fully-qualified names of columns for which you want the connector to emit extra parameters that represent column metadata. When this property is set, the connector adds the following fields to the schema of event records: __debezium.source.column.type __debezium.source.column.length __debezium.source.column.scale These parameters propagate a column's original type name and length (for variable-width types), respectively. Enabling the connector to emit this extra data can assist in properly sizing specific numeric or character-based columns in sink databases. The fully-qualified name of a column observes the following format: schemaName . tableName . columnName . To match the name of a column, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the column; the expression does not match substrings that might be present in a column name. datatype.propagate.source.type n/a An optional, comma-separated list of regular expressions that specify the fully-qualified names of data types that are defined for columns in a database. When this property is set, for columns with matching data types, the connector emits event records that include the following extra fields in their schema: __debezium.source.column.type __debezium.source.column.length __debezium.source.column.scale These parameters propagate a column's original type name and length (for variable-width types), respectively. Enabling the connector to emit this extra data can assist in properly sizing specific numeric or character-based columns in sink databases. The fully-qualified name of a column observes the following format: schemaName . tableName . typeName . To match the name of a data type, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the data type; the expression does not match substrings that might be present in a type name. For the list of SQL Server-specific data type names, see the SQL Server data type mappings . message.key.columns n/a A list of expressions that specify the columns that the connector uses to form custom message keys for change event records that it publishes to the Kafka topics for specified tables. By default, Debezium uses the primary key column of a table as the message key for records that it emits. In place of the default, or to specify a key for tables that lack a primary key, you can configure custom message keys based on one or more columns. To establish a custom message key for a table, list the table, followed by the columns to use as the message key. Each list entry takes the following format: <fully-qualified_tableName> : <keyColumn> , <keyColumn> To base a table key on multiple column names, insert commas between the column names. Each fully-qualified table name is a regular expression in the following format: <schemaName> . <tableName> The property can include entries for multiple tables. Use a semicolon to separate table entries in the list. The following example sets the message key for the tables inventory.customers and purchase.orders : inventory.customers:pk1,pk2;(.*).purchaseorders:pk3,pk4 For the table inventory.customer , the columns pk1 and pk2 are specified as the message key. For the purchaseorders tables in any schema, the columns pk3 and pk4 server as the message key. There is no limit to the number of columns that you use to create custom message keys. However, it's best to use the minimum number that are required to specify a unique key. binary.handling.mode bytes Specifies how binary ( binary , varbinary ) columns should be represented in change events, including: bytes represents binary data as byte array (default), base64 represents binary data as base64-encoded String, base64-url-safe represents binary data as base64-url-safe-encoded String, hex represents binary data as hex-encoded (base16) String schema.name.adjustment.mode none Specifies how schema names should be adjusted for compatibility with the message converter used by the connector. Possible settings: none does not apply any adjustment. avro replaces the characters that cannot be used in the Avro type name with underscore. avro_unicode replaces the underscore or characters that cannot be used in the Avro type name with corresponding unicode like _uxxxx. Note: _ is an escape sequence like backslash in Java field.name.adjustment.mode none Specifies how field names should be adjusted for compatibility with the message converter used by the connector. Possible settings: none does not apply any adjustment. avro replaces the characters that cannot be used in the Avro type name with underscore. avro_unicode replaces the underscore or characters that cannot be used in the Avro type name with corresponding unicode like _uxxxx. Note: _ is an escape sequence like backslash in Java For more information, see Avro naming . Advanced SQL Server connector configuration properties The following advanced configuration properties have good defaults that will work in most situations and therefore rarely need to be specified in the connector's configuration. Property Default Description converters No default Enumerates a comma-separated list of the symbolic names of the custom converter instances that the connector can use. For example, isbn You must set the converters property to enable the connector to use a custom converter. For each converter that you configure for a connector, you must also add a .type property, which specifies the fully-qualified name of the class that implements the converter interface. The .type property uses the following format: <converterSymbolicName> .type For example, If you want to further control the behavior of a configured converter, you can add one or more configuration parameters to pass values to the converter. To associate any additional configuration parameter with a converter, prefix the parameter names with the symbolic name of the converter. For example, snapshot.mode initial A mode for taking an initial snapshot of the structure and optionally data of captured tables. Once the snapshot is complete, the connector will continue reading change events from the database's redo logs. The following values are supported: always Perform snapshot on each connector start. After the snapshot completes, the connector begins to stream event records for subsequent database changes. initial The connector performs a database snapshot as described in the default workflow for creating an initial snapshot . After the snapshot completes, the connector begins to stream event records for subsequent database changes. initial_only The connector performs a database snapshot and stops before streaming any change event records, not allowing any subsequent change events to be captured. schema_only Deprecated, see no_data . no_data The connector captures the structure of all relevant tables, performing all the steps described in the default snapshot workflow , except that it does not create READ events to represent the data set at the point of the connector's start-up (Step 7.b). recovery Set this option to restore a database schema history topic that is lost or corrupted. After a restart, the connector runs a snapshot that rebuilds the topic from the source tables. You can also set the property to periodically prune a database schema history topic that experiences unexpected growth. Warning Do not use this mode to perform a snapshot if schema changes were committed to the database after the last connector shutdown. when_needed After the connector starts, it performs a snapshot only if it detects one of the following circumstances: It cannot detect any topic offsets. A previously recorded offset specifies a log position that is not available on the server. snapshot.locking.mode exclusive Controls whether and for how long the connector holds a table lock. Table locks prevent certain types of changes table operations from occurring while the connector performs a snapshot. You can set the following values: exclusive Controls how the connector holds locks on tables while performing the schema snapshot when snapshot.isolation.mode is REPEATABLE_READ or EXCLUSIVE . The connector will hold a table lock for exclusive table access for just the initial portion of the snapshot while the database schemas and other metadata are being read. The remaining work in a snapshot involves selecting all rows from each table, and this is done using a flashback query that requires no locks. However, in some cases it may be desirable to avoid locks entirely which can be done by specifying none . This mode is only safe to use if no schema changes are happening while the snapshot is taken. none Prevents the connector from acquiring any table locks during the snapshot. Use this setting only if no schema changes might occur during the creation of the snapshot. snapshot.query.mode select_all Specifies how the connector queries data while performing a snapshot. Set one of the following options: select_all The connector performs a select all query by default, optionally adjusting the columns selected based on the column include and exclude list configurations. This setting enables you to manage snapshot content in a more flexible manner compared to using the snapshot.select.statement.overrides property. snapshot.include.collection.list All tables specified in table.include.list An optional, comma-separated list of regular expressions that match the fully-qualified names ( <dbName> . <schemaName> . <tableName> ) of the tables to include in a snapshot. The specified items must be named in the connector's table.include.list property. This property takes effect only if the connector's snapshot.mode property is set to a value other than never . This property does not affect the behavior of incremental snapshots. To match the name of a table, Debezium applies the regular expression that you specify as an anchored regular expression. That is, the specified expression is matched against the entire name string of the table; it does not match substrings that might be present in a table name. snapshot.isolation.mode repeatable_read Mode to control which transaction isolation level is used and how long the connector locks tables that are designated for capture. The following values are supported: read_uncommitted read_committed repeatable_read snapshot exclusive ( exclusive mode uses repeatable read isolation level, however, it takes the exclusive lock on all tables to be read). The snapshot , read_committed and read_uncommitted modes do not prevent other transactions from updating table rows during initial snapshot. The exclusive and repeatable_read modes do prevent concurrent updates. Mode choice also affects data consistency. Only exclusive and snapshot modes guarantee full consistency, that is, initial snapshot and streaming logs constitute a linear history. In case of repeatable_read and read_committed modes, it might happen that, for instance, a record added appears twice - once in initial snapshot and once in streaming phase. Nonetheless, that consistency level should do for data mirroring. For read_uncommitted there are no data consistency guarantees at all (some data might be lost or corrupted). event.processing.failure.handling.mode fail Specifies how the connector should react to exceptions during processing of events. fail will propagate the exception (indicating the offset of the problematic event), causing the connector to stop. warn will cause the problematic event to be skipped and the offset of the problematic event to be logged. skip will cause the problematic event to be skipped. poll.interval.ms 500 Positive integer value that specifies the number of milliseconds the connector should wait during each iteration for new change events to appear. Defaults to 500 milliseconds, or 0.5 second. max.queue.size 8192 Positive integer value that specifies the maximum number of records that the blocking queue can hold. When Debezium reads events streamed from the database, it places the events in the blocking queue before it writes them to Kafka. The blocking queue can provide backpressure for reading change events from the database in cases where the connector ingests messages faster than it can write them to Kafka, or when Kafka becomes unavailable. Events that are held in the queue are disregarded when the connector periodically records offsets. Always set the value of max.queue.size to be larger than the value of max.batch.size . max.queue.size.in.bytes 0 A long integer value that specifies the maximum volume of the blocking queue in bytes. By default, volume limits are not specified for the blocking queue. To specify the number of bytes that the queue can consume, set this property to a positive long value. If max.queue.size is also set, writing to the queue is blocked when the size of the queue reaches the limit specified by either property. For example, if you set max.queue.size=1000 , and max.queue.size.in.bytes=5000 , writing to the queue is blocked after the queue contains 1000 records, or after the volume of the records in the queue reaches 5000 bytes. max.batch.size 2048 Positive integer value that specifies the maximum size of each batch of events that should be processed during each iteration of this connector. heartbeat.interval.ms 0 Controls how frequently heartbeat messages are sent. This property contains an interval in milliseconds that defines how frequently the connector sends messages to a heartbeat topic. The property can be used to confirm whether the connector is still receiving change events from the database. You also should leverage heartbeat messages in cases where only records in non-captured tables are changed for a longer period of time. In such situation the connector would proceed to read the log from the database but never emit any change messages into Kafka, which in turn means that no offset updates are committed to Kafka. This may result in more change events to be re-sent after a connector restart. Set this parameter to 0 to not send heartbeat messages at all. Disabled by default. heartbeat.action.query No default Specifies a query that the connector executes on the source database when the connector sends a heartbeat message. This is useful for keeping offsets from becoming stale when capturing changes from a low-traffic database. Create a heartbeat table in the low-traffic database, and set this property to a statement that inserts records into that table, for example: INSERT INTO test_heartbeat_table (text) VALUES ('test_heartbeat') This allows the connector to receive changes from the low-traffic database and acknowledge their LSNs, which prevents offsets from become stale. snapshot.delay.ms No default An interval in milli-seconds that the connector should wait before taking a snapshot after starting up; Can be used to avoid snapshot interruptions when starting multiple connectors in a cluster, which may cause re-balancing of connectors. streaming.delay.ms 0 Specifies the time, in milliseconds, that the connector delays the start of the streaming process after it completes a snapshot. Setting a delay interval helps to prevent the connector from restarting snapshots in the event that a failure occurs immediately after the snapshot completes, but before the streaming process begins. Set a delay value that is higher than the value of the offset.flush.interval.ms property that is set for the Kafka Connect worker. snapshot.fetch.size 2000 Specifies the maximum number of rows that should be read in one go from each table while taking a snapshot. The connector will read the table contents in multiple batches of this size. Defaults to 2000. query.fetch.size No default Specifies the number of rows that will be fetched for each database round-trip of a given query. Defaults to the JDBC driver's default fetch size. snapshot.lock.timeout.ms 10000 An integer value that specifies the maximum amount of time (in milliseconds) to wait to obtain table locks when performing a snapshot. If table locks cannot be acquired in this time interval, the snapshot will fail (also see snapshots ). When set to 0 the connector will fail immediately when it cannot obtain the lock. Value -1 indicates infinite waiting. snapshot.select.statement.overrides No default Specifies the table rows to include in a snapshot. Use the property if you want a snapshot to include only a subset of the rows in a table. This property affects snapshots only. It does not apply to events that the connector reads from the log. The property contains a comma-separated list of fully-qualified table names in the form <schemaName>.<tableName> . For example, "snapshot.select.statement.overrides": "inventory.products,customers.orders" For each table in the list, add a further configuration property that specifies the SELECT statement for the connector to run on the table when it takes a snapshot. The specified SELECT statement determines the subset of table rows to include in the snapshot. Use the following format to specify the name of this SELECT statement property: snapshot.select.statement.overrides. <schemaName> . <tableName> . For example, snapshot.select.statement.overrides.customers.orders . Example: From a customers.orders table that includes the soft-delete column, delete_flag , add the following properties if you want a snapshot to include only those records that are not soft-deleted: In the resulting snapshot, the connector includes only the records for which delete_flag = 0 . provide.transaction.metadata false When set to true Debezium generates events with transaction boundaries and enriches data events envelope with transaction metadata. retriable.restart.connector.wait.ms 10000 (10 seconds) The number of milli-seconds to wait before restarting a connector after a retriable error occurs. skipped.operations t A comma-separated list of operation types that will be skipped during streaming. The operations include: c for inserts/create, u for updates, d for deletes, t for truncates, and none to not skip any operations. By default, truncate operations are skipped (not emitted by this connector). signal.data.collection No default value Fully-qualified name of the data collection that is used to send signals to the connector. Use the following format to specify the collection name: <databaseName> . <schemaName> . <tableName> signal.enabled.channels source List of the signaling channel names that are enabled for the connector. By default, the following channels are available: source kafka file jmx notification.enabled.channels No default List of notification channel names that are enabled for the connector. By default, the following channels are available: sink log jmx incremental.snapshot.allow.schema.changes false Allow schema changes during an incremental snapshot. When enabled the connector will detect schema change during an incremental snapshot and re-select a current chunk to avoid locking DDLs. Note that changes to a primary key are not supported and can cause incorrect results if performed during an incremental snapshot. Another limitation is that if a schema change affects only columns' default values, then the change won't be detected until the DDL is processed from the transaction log stream. This doesn't affect the snapshot events' values, but the schema of snapshot events may have outdated defaults. incremental.snapshot.chunk.size 1024 The maximum number of rows that the connector fetches and reads into memory during an incremental snapshot chunk. Increasing the chunk size provides greater efficiency, because the snapshot runs fewer snapshot queries of a greater size. However, larger chunk sizes also require more memory to buffer the snapshot data. Adjust the chunk size to a value that provides the best performance in your environment. incremental.snapshot.watermarking.strategy insert_insert Specifies the watermarking mechanism that the connector uses during an incremental snapshot to deduplicate events that might be captured by an incremental snapshot and then recaptured after streaming resumes. You can specify one of the following options: insert_insert When you send a signal to initiate an incremental snapshot, for every chunk that Debezium reads during the snapshot, it writes an entry to the signaling data collection to record the signal to open the snapshot window. After the snapshot completes, Debezium inserts a second entry that records the signal to close the window. insert_delete When you send a signal to initiate an incremental snapshot, for every chunk that Debezium reads, it writes a single entry to the signaling data collection to record the signal to open the snapshot window. After the snapshot completes, this entry is removed. No entry is created for the signal to close the snapshot window. Set this option to prevent rapid growth of the signaling data collection. max.iteration.transactions 500 Specifies the maximum number of transactions per iteration to be used to reduce the memory footprint when streaming changes from multiple tables in a database. When set to 0 , the connector uses the current maximum LSN as the range to fetch changes from. When set to a value greater than zero, the connector uses the n-th LSN specified by this setting as the range to fetch changes from. Defaults to 500. incremental.snapshot.option.recompile false Uses OPTION(RECOMPILE) query option to all SELECT statements used during an incremental snapshot. This can help to solve parameter sniffing issues that may occur but can cause increased CPU load on the source database, depending on the frequency of query execution. topic.naming.strategy io.debezium.schema.SchemaTopicNamingStrategy The name of the TopicNamingStrategy class that should be used to determine the topic name for data change, schema change, transaction, heartbeat event etc., defaults to SchemaTopicNamingStrategy . topic.delimiter . Specify the delimiter for topic name, defaults to . . topic.cache.size 10000 The size used for holding the topic names in bounded concurrent hash map. This cache will help to determine the topic name corresponding to a given data collection. topic.heartbeat.prefix __debezium-heartbeat Controls the name of the topic to which the connector sends heartbeat messages. The topic name has this pattern: topic.heartbeat.prefix . topic.prefix For example, if the topic prefix is fulfillment , the default topic name is __debezium-heartbeat.fulfillment . topic.transaction transaction Controls the name of the topic to which the connector sends transaction metadata messages. The topic name has this pattern: topic.prefix . topic.transaction For example, if the topic prefix is fulfillment , the default topic name is fulfillment.transaction . For more information, see Transaction Metadata . snapshot.max.threads 1 Specifies the number of threads that the connector uses when performing an initial snapshot. To enable parallel initial snapshots, set the property to a value greater than 1. In a parallel initial snapshot, the connector processes multiple tables concurrently. Important Parallel initial snapshots is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope . custom.metric.tags No default Defines tags that customize MBean object names by adding metadata that provides contextual information. Specify a comma-separated list of key-value pairs. Each key represents a tag for the MBean object name, and the corresponding value represents a value for the key, for example, k1=v1,k2=v2 The connector appends the specified tags to the base MBean object name. Tags can help you to organize and categorize metrics data. You can define tags to identify particular application instances, environments, regions, versions, and so forth. For more information, see Customized MBean names . errors.max.retries -1 Specifies how the connector responds after an operation that results in a retriable error, such as a connection error. Set one of the following options: -1 No limit. The connector always restarts automatically, and retries the operation, regardless of the number of failures. 0 Disabled. The connector fails immediately, and never retries the operation. User intervention is required to restart the connector. > 0 The connector restarts automatically until it reaches the specified maximum number of retries. After the failure, the connector stops, and user intervention is required to restart it. data.query.mode function Controls how the connector queries CDC data. The following modes are supported: function : The data is queried by calling cdc.[fn_cdc_get_all_changes_#] function. This is the default mode. direct : Makes the connector to query change tables directly. Switching to direct mode and creating an index on (__USDstart_lsn ASC, __USDseqval ASC, __USDoperation ASC) columns for each change table significantly speeds up querying CDC data. database.query.timeout.ms 600000 (10 minutes) Specifies the time, in milliseconds, that the connector waits for a query to complete. Set the value to 0 (zero) to remove the timeout limit. Debezium SQL Server connector database schema history configuration properties Debezium provides a set of schema.history.internal.* properties that control how the connector interacts with the schema history topic. The following table describes the schema.history.internal properties for configuring the Debezium connector. Table 2.180. Connector database schema history configuration properties Property Default Description schema.history.internal.kafka.topic No default The full name of the Kafka topic where the connector stores the database schema history. schema.history.internal.kafka.bootstrap.servers No default A list of host/port pairs that the connector uses for establishing an initial connection to the Kafka cluster. This connection is used for retrieving the database schema history previously stored by the connector, and for writing each DDL statement read from the source database. Each pair should point to the same Kafka cluster used by the Kafka Connect process. schema.history.internal.kafka.recovery.poll.interval.ms 100 An integer value that specifies the maximum number of milliseconds the connector should wait during startup/recovery while polling for persisted data. The default is 100ms. schema.history.internal.kafka.query.timeout.ms 3000 An integer value that specifies the maximum number of milliseconds the connector should wait while fetching cluster information using Kafka admin client. schema.history.internal.kafka.create.timeout.ms 30000 An integer value that specifies the maximum number of milliseconds the connector should wait while create kafka history topic using Kafka admin client. schema.history.internal.kafka.recovery.attempts 100 The maximum number of times that the connector should try to read persisted history data before the connector recovery fails with an error. The maximum amount of time to wait after receiving no data is recovery.attempts x recovery.poll.interval.ms . schema.history.internal.skip.unparseable.ddl false A Boolean value that specifies whether the connector should ignore malformed or unknown database statements or stop processing so a human can fix the issue. The safe default is false . Skipping should be used only with care as it can lead to data loss or mangling when the binlog is being processed. schema.history.internal.store.only.captured.tables.ddl false A Boolean value that specifies whether the connector records schema structures from all tables in a schema or database, or only from tables that are designated for capture. Specify one of the following values: false (default) During a database snapshot, the connector records the schema data for all non-system tables in the database, including tables that are not designated for capture. It's best to retain the default setting. If you later decide to capture changes from tables that you did not originally designate for capture, the connector can easily begin to capture data from those tables, because their schema structure is already stored in the schema history topic. Debezium requires the schema history of a table so that it can identify the structure that was present at the time that a change event occurred. true During a database snapshot, the connector records the table schemas only for the tables from which Debezium captures change events. If you change the default value, and you later configure the connector to capture data from other tables in the database, the connector lacks the schema information that it requires to capture change events from the tables. schema.history.internal.store.only.captured.databases.ddl false A Boolean value that specifies whether the connector records schema structures from all logical databases in the database instance. Specify one of the following values: true The connector records schema structures only for tables in the logical database and schema from which Debezium captures change events. false The connector records schema structures for all logical databases. Pass-through SQL Server connector configuration properties The connector supports pass-through properties that enable Debezium to specify custom configuration options for fine-tuning the behavior of the Apache Kafka producer and consumer. For information about the full range of configuration properties for Kafka producers and consumers, see the Kafka documentation . Pass-through properties for configuring how producer and consumer clients interact with schema history topics Debezium relies on an Apache Kafka producer to write schema changes to database schema history topics. Similarly, it relies on a Kafka consumer to read from database schema history topics when a connector starts. You define the configuration for the Kafka producer and consumer clients by assigning values to a set of pass-through configuration properties that begin with the schema.history.internal.producer.* and schema.history.internal.consumer.* prefixes. The pass-through producer and consumer database schema history properties control a range of behaviors, such as how these clients secure connections with the Kafka broker, as shown in the following example: Debezium strips the prefix from the property name before it passes the property to the Kafka client. For more information about Kafka producer configuration properties and Kafka consumer configuration properties , see the Apache Kafka documentation . Pass-through properties for configuring how the SQL Server connector interacts with the Kafka signaling topic Debezium provides a set of signal.* properties that control how the connector interacts with the Kafka signals topic. The following table describes the Kafka signal properties. Table 2.181. Kafka signals configuration properties Property Default Description signal.kafka.topic <topic.prefix>-signal The name of the Kafka topic that the connector monitors for ad hoc signals. Note If automatic topic creation is disabled, you must manually create the required signaling topic. A signaling topic is required to preserve signal ordering. The signaling topic must have a single partition. signal.kafka.groupId kafka-signal The name of the group ID that is used by Kafka consumers. signal.kafka.bootstrap.servers No default A list of the host and port pairs that the connector uses to establish its initial connection to the Kafka cluster. Each pair references the Kafka cluster that is used by the Debezium Kafka Connect process. signal.kafka.poll.timeout.ms 100 An integer value that specifies the maximum number of milliseconds that the connector waits when polling signals. kafka.consumer.offset.commit.enabled false Specifies whether the Kafka consumer writes an offset commit after it reads a message from the signaling topic. The value that you assign to this property determines whether the connector can process requests that the signaling topic receives while the connector is offline. Choose one of the following settings: false When the connector is unavailable, the Kafka consumer does not commit an offset after it reads a signal received by the signaling topic. As a result, if the connector is offline for any interval, it cannot process requests that the signaling topic receives during the downtime. After the connector restarts, it always reads from the last position in the Kafka signaling topic, processing only signals that it receives after the restart. Signals received while the connector is offline are ignored, and are effectively lost. true When a user submits a request to the signaling topic, after the Kafka consumer reads the signal message it commits a topic offset, even if the connector is offline. Choose this option to provide Debezium with information about the last signal message that the consumer read, helping to ensure At-Least-Once delivery. After a connector restarts, it resumes processing from the last recorded offset, responding to signals that users submitted while the connector is offline. Pass-through properties for configuring the Kafka consumer client for the signaling channel The Debezium connector provides for pass-through configuration of the signals Kafka consumer. Pass-through signals properties begin with the prefix signals.consumer.* . For example, the connector passes properties such as signal.consumer.security.protocol=SSL to the Kafka consumer. Debezium strips the prefixes from the properties before it passes the properties to the Kafka signals consumer. Pass-through properties for configuring the SQL Server connector sink notification channel The following table describes properties that you can use to configure the Debezium sink notification channel. Table 2.182. Sink notification configuration properties Property Default Description notification.sink.topic.name No default The name of the topic that receives notifications from Debezium. This property is required when you configure the notification.enabled.channels property to include sink as one of the enabled notification channels. Debezium connector pass-through database driver configuration properties The Debezium connector provides for pass-through configuration of the database driver. Pass-through database properties begin with the prefix driver.* . For example, the connector passes properties such as driver.foobar=false to the JDBC URL. Debezium strips the prefixes from the properties before it passes the properties to the database driver. 2.7.5. Refreshing capture tables after a schema change When change data capture is enabled for a SQL Server table, as changes occur in the table, event records are persisted to a capture table on the server. If you introduce a change in the structure of the source table change, for example, by adding a new column, that change is not dynamically reflected in the change table. For as long as the capture table continues to use the outdated schema, the Debezium connector is unable to emit data change events for the table correctly. You must intervene to refresh the capture table to enable the connector to resume processing change events. Because of the way that CDC is implemented in SQL Server, you cannot use Debezium to update capture tables. To refresh capture tables, one must be a SQL Server database operator with elevated privileges. As a Debezium user, you must coordinate tasks with the SQL Server database operator to complete the schema refresh and restore streaming to Kafka topics. You can use one of the following methods to update capture tables after a schema change: Offline schema updates require you to stop the Debezium connector before you can update capture tables. Online schema updates can update capture tables while the Debezium connector is running. There are advantages and disadvantages to using each type of procedure. Warning Whether you use the online or offline update method, you must complete the entire schema update process before you apply subsequent schema updates on the same source table. The best practice is to execute all DDLs in a single batch so the procedure can be run only once. Note Some schema changes are not supported on source tables that have CDC enabled. For example, if CDC is enabled on a table, SQL Server does not allow you to change the schema of the table if you renamed one of its columns or changed the column type. Note After you change a column in a source table from NULL to NOT NULL or vice versa, the SQL Server connector cannot correctly capture the changed information until after you create a new capture instance. If you do not create a new capture table after a change to the column designation, change event records that the connector emits do not correctly indicate whether the column is optional. That is, columns that were previously defined as optional (or NULL ) continue to be, despite now being defined as NOT NULL . Similarly, columns that had been defined as required ( NOT NULL ), retain that designation, although they are now defined as NULL . Note After you rename a table using sp_rename function, it will continue to emit changes under the old source table name until the connector is restarted. Upon restart of the connector, it will emit changes under the new source table name. 2.7.5.1. Running an offline update after a schema change Offline schema updates provide the safest method for updating capture tables. However, offline updates might not be feasible for use with applications that require high-availability. Prerequisites An update was committed to the schema of a SQL Server table that has CDC enabled. You are a SQL Server database operator with elevated privileges. Procedure Suspend the application that updates the database. Wait for the Debezium connector to stream all unstreamed change event records. Stop the Debezium connector. Apply all changes to the source table schema. Create a new capture table for the update source table using sys.sp_cdc_enable_table procedure with a unique value for parameter @capture_instance . Resume the application that you suspended in Step 1. Start the Debezium connector. After the Debezium connector starts streaming from the new capture table, drop the old capture table by running the stored procedure sys.sp_cdc_disable_table with the parameter @capture_instance set to the old capture instance name. 2.7.5.2. Running an online update after a schema change The procedure for completing an online schema updates is simpler than the procedure for running an offline schema update, and you can complete it without requiring any downtime in application and data processing. However, with online schema updates, a potential processing gap can occur after you update the schema in the source database, but before you create the new capture instance. During that interval, change events continue to be captured by the old instance of the change table, and the change data that is saved to the old table retains the structure of the earlier schema. So, for example, if you added a new column to a source table, change events that are produced before the new capture table is ready, do not contain a field for the new column. If your application does not tolerate such a transition period, it is best to use the offline schema update procedure. Prerequisites An update was committed to the schema of a SQL Server table that has CDC enabled. You are a SQL Server database operator with elevated privileges. Procedure Apply all changes to the source table schema. Create a new capture table for the update source table by running the sys.sp_cdc_enable_table stored procedure with a unique value for the parameter @capture_instance . When Debezium starts streaming from the new capture table, you can drop the old capture table by running the sys.sp_cdc_disable_table stored procedure with the parameter @capture_instance set to the old capture instance name. Example: Running an online schema update after a database schema change The following example shows how to complete an online schema update in the change table after the column phone_number is added to the customers source table. Modify the schema of the customers source table by running the following query to add the phone_number field: ALTER TABLE customers ADD phone_number VARCHAR(32); Create the new capture instance by running the sys.sp_cdc_enable_table stored procedure. EXEC sys.sp_cdc_enable_table @source_schema = 'dbo', @source_name = 'customers', @role_name = NULL, @supports_net_changes = 0, @capture_instance = 'dbo_customers_v2'; GO Insert new data into the customers table by running the following query: INSERT INTO customers(first_name,last_name,email,phone_number) VALUES ('John','Doe','john.doe@example.com', '+1-555-123456'); GO The Kafka Connect log reports on configuration updates through entries similar to the following message: connect_1 | 2019-01-17 10:11:14,924 INFO || Multiple capture instances present for the same table: Capture instance "dbo_customers" [sourceTableId=testDB.dbo.customers, changeTableId=testDB.cdc.dbo_customers_CT, startLsn=00000024:00000d98:0036, changeTableObjectId=1525580473, stopLsn=00000025:00000ef8:0048] and Capture instance "dbo_customers_v2" [sourceTableId=testDB.dbo.customers, changeTableId=testDB.cdc.dbo_customers_v2_CT, startLsn=00000025:00000ef8:0048, changeTableObjectId=1749581271, stopLsn=NULL] [io.debezium.connector.sqlserver.SqlServerStreamingChangeEventSource] connect_1 | 2019-01-17 10:11:14,924 INFO || Schema will be changed for ChangeTable [captureInstance=dbo_customers_v2, sourceTableId=testDB.dbo.customers, changeTableId=testDB.cdc.dbo_customers_v2_CT, startLsn=00000025:00000ef8:0048, changeTableObjectId=1749581271, stopLsn=NULL] [io.debezium.connector.sqlserver.SqlServerStreamingChangeEventSource] ... connect_1 | 2019-01-17 10:11:33,719 INFO || Migrating schema to ChangeTable [captureInstance=dbo_customers_v2, sourceTableId=testDB.dbo.customers, changeTableId=testDB.cdc.dbo_customers_v2_CT, startLsn=00000025:00000ef8:0048, changeTableObjectId=1749581271, stopLsn=NULL] [io.debezium.connector.sqlserver.SqlServerStreamingChangeEventSource] Eventually, the phone_number field is added to the schema and its value appears in messages written to the Kafka topic. ... { "type": "string", "optional": true, "field": "phone_number" } ... "after": { "id": 1005, "first_name": "John", "last_name": "Doe", "email": "john.doe@example.com", "phone_number": "+1-555-123456" }, Drop the old capture instance by running the sys.sp_cdc_disable_table stored procedure. EXEC sys.sp_cdc_disable_table @source_schema = 'dbo', @source_name = 'dbo_customers', @capture_instance = 'dbo_customers'; GO 2.7.6. Monitoring Debezium SQL Server connector performance The Debezium SQL Server connector provides three types of metrics that are in addition to the built-in support for JMX metrics that Zookeeper, Kafka, and Kafka Connect provide. The connector provides the following metrics: Snapshot metrics for monitoring the connector when performing snapshots. Streaming metrics for monitoring the connector when reading CDC table data. Schema history metrics for monitoring the status of the connector's schema history. For information about how to expose the preceding metrics through JMX, see the Debezium monitoring documentation . 2.7.6.1. Customized names for SQL Server connector snapshot and streaming MBean objects Debezium connectors expose metrics via the MBean name for the connector. These metrics, which are specific to each connector instance, provide data about the behavior of the connector's snapshot, streaming, and schema history processes. By default, when you deploy a correctly configured connector, Debezium generates a unique MBean name for each of the different connector metrics. To view the metrics for a connector process, you configure your observability stack to monitor its MBean. But these default MBean names depend on the connector configuration; configuration changes can result in changes to the MBean names. A change to the MBean name breaks the linkage between the connector instance and the MBean, disrupting monitoring activity. In this scenario, you must reconfigure the observability stack to use the new MBean name if you want to resume monitoring. To prevent monitoring disruptions that result from MBean name changes, you can configure custom metrics tags. You configure custom metrics by adding the custom.metric.tags property to the connector configuration. The property accepts key-value pairs in which each key represents a tag for the MBean object name, and the corresponding value represents the value of that tag. For example: k1=v1,k2=v2 . Debezium appends the specified tags to the MBean name of the connector. After you configure the custom.metric.tags property for a connector, you can configure the observability stack to retrieve metrics associated with the specified tags. The observability stack then uses the specified tags, rather than the mutable MBean names to uniquely identify connectors. Later, if Debezium redefines how it constructs MBean names, or if the topic.prefix in the connector configuration changes, metrics collection is uninterrupted, because the metrics scrape task uses the specified tag patterns to identify the connector. A further benefit of using custom tags, is that you can use tags that reflect the architecture of your data pipeline, so that metrics are organized in a way that suits you operational needs. For example, you might specify tags with values that declare the type of connector activity, the application context, or the data source, for example, db1-streaming-for-application-abc . If you specify multiple key-value pairs, all of the specified pairs are appended to the connector's MBean name. The following example illustrates how tags modify the default MBean name. Example 2.55. How custom tags modify the connector MBean name By default, the SQL Server connector uses the following MBean name for streaming metrics: If you set the value of custom.metric.tags to database=salesdb-streaming,table=inventory , Debezium generates the following custom MBean name: 2.7.6.2. Debezium SQL Server connector snapshot metrics The MBean is debezium.sql_server:type=connector-metrics,server= <topic.prefix> ,task= <task.id> ,context=snapshot . Snapshot metrics are not exposed unless a snapshot operation is active, or if a snapshot has occurred since the last connector start. The following table lists the snapshot metrics that are available. Attributes Type Description LastEvent string The last snapshot event that the connector has read. MilliSecondsSinceLastEvent long The number of milliseconds since the connector has read and processed the most recent event. TotalNumberOfEventsSeen long The total number of events that this connector has seen since last started or reset. NumberOfEventsFiltered long The number of events that have been filtered by include/exclude list filtering rules configured on the connector. CapturedTables string[] The list of tables that are captured by the connector. QueueTotalCapacity int The length the queue used to pass events between the snapshotter and the main Kafka Connect loop. QueueRemainingCapacity int The free capacity of the queue used to pass events between the snapshotter and the main Kafka Connect loop. TotalTableCount int The total number of tables that are being included in the snapshot. RemainingTableCount int The number of tables that the snapshot has yet to copy. SnapshotRunning boolean Whether the snapshot was started. SnapshotPaused boolean Whether the snapshot was paused. SnapshotAborted boolean Whether the snapshot was aborted. SnapshotCompleted boolean Whether the snapshot completed. SnapshotDurationInSeconds long The total number of seconds that the snapshot has taken so far, even if not complete. Includes also time when snapshot was paused. SnapshotPausedDurationInSeconds long The total number of seconds that the snapshot was paused. If the snapshot was paused several times, the paused time adds up. RowsScanned Map<String, Long> Map containing the number of rows scanned for each table in the snapshot. Tables are incrementally added to the Map during processing. Updates every 10,000 rows scanned and upon completing a table. MaxQueueSizeInBytes long The maximum buffer of the queue in bytes. This metric is available if max.queue.size.in.bytes is set to a positive long value. CurrentQueueSizeInBytes long The current volume, in bytes, of records in the queue. The connector also provides the following additional snapshot metrics when an incremental snapshot is executed: Attributes Type Description ChunkId string The identifier of the current snapshot chunk. ChunkFrom string The lower bound of the primary key set defining the current chunk. ChunkTo string The upper bound of the primary key set defining the current chunk. TableFrom string The lower bound of the primary key set of the currently snapshotted table. TableTo string The upper bound of the primary key set of the currently snapshotted table. 2.7.6.3. Debezium SQL Server connector streaming metrics The MBean is debezium.sql_server:type=connector-metrics,server= <topic.prefix> ,task= <task.id> ,context=streaming . The following table lists the streaming metrics that are available. Attributes Type Description LastEvent string The last streaming event that the connector has read. MilliSecondsSinceLastEvent long The number of milliseconds since the connector has read and processed the most recent event. TotalNumberOfEventsSeen long The total number of data change events reported by the source database since the last connector start, or since a metrics reset. Represents the data change workload for Debezium to process. TotalNumberOfCreateEventsSeen long The total number of create events processed by the connector since its last start or metrics reset. TotalNumberOfUpdateEventsSeen long The total number of update events processed by the connector since its last start or metrics reset. TotalNumberOfDeleteEventsSeen long The total number of delete events processed by the connector since its last start or metrics reset. NumberOfEventsFiltered long The number of events that have been filtered by include/exclude list filtering rules configured on the connector. CapturedTables string[] The list of tables that are captured by the connector. QueueTotalCapacity int The length the queue used to pass events between the streamer and the main Kafka Connect loop. QueueRemainingCapacity int The free capacity of the queue used to pass events between the streamer and the main Kafka Connect loop. Connected boolean Flag that denotes whether the connector is currently connected to the database server. MilliSecondsBehindSource long The number of milliseconds between the last change event's timestamp and the connector processing it. The values will incorporate any differences between the clocks on the machines where the database server and the connector are running. NumberOfCommittedTransactions long The number of processed transactions that were committed. SourceEventPosition Map<String, String> The coordinates of the last received event. LastTransactionId string Transaction identifier of the last processed transaction. MaxQueueSizeInBytes long The maximum buffer of the queue in bytes. This metric is available if max.queue.size.in.bytes is set to a positive long value. CurrentQueueSizeInBytes long The current volume, in bytes, of records in the queue. 2.7.6.4. Debezium SQL Server connector schema history metrics The MBean is debezium.sql_server:type=connector-metrics,context=schema-history,server= <topic.prefix> . The following table lists the schema history metrics that are available. Attributes Type Description Status string One of STOPPED , RECOVERING (recovering history from the storage), RUNNING describing the state of the database schema history. RecoveryStartTime long The time in epoch seconds at what recovery has started. ChangesRecovered long The number of changes that were read during recovery phase. ChangesApplied long the total number of schema changes applied during recovery and runtime. MilliSecondsSinceLast RecoveredChange long The number of milliseconds that elapsed since the last change was recovered from the history store. MilliSecondsSinceLast AppliedChange long The number of milliseconds that elapsed since the last change was applied. LastRecoveredChange string The string representation of the last change recovered from the history store. LastAppliedChange string The string representation of the last applied change.

Commands:
INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}');
INSERT INTO myschema.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'execute-snapshot', 3 '{"data-collections": ["schema1.table1", "schema1.table2"], 4 "type":"incremental", 5 "additional-conditions":[{"data-collection": "schema1.table1" ,"filter":"color=\'blue\'"}]}'); 6
SELECT * FROM <tableName> .
SELECT * FROM <data-collection> WHERE <filter> .
INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}');
INSERT INTO myschema.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["schema1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "schema1.products", "filter": "color=blue"}]}');
INSERT INTO myschema.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["schema1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "schema1.products", "filter": "color=blue AND quantity>10"}]}');
{ "before":null, "after": { "pk":"1", "value":"New data" }, "source": { "snapshot":"incremental" 1 }, "op":"r", 2 "ts_ms":"1620393591654", "ts_us":"1620393591654547", "ts_ns":"1620393591654547920", "transaction":null }
Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["{collection-container}.table1", "{collection-container}.table2"], "type": "INCREMENTAL"}}`
Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["schema1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "schema1.products" ,"filter":"color='blue'"}]}}`
Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["schema1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "schema1.products" ,"filter":"color='blue' AND brand='MyBrand'"}]}}`
INSERT INTO <signalTable> (id, type, data) values ( '<id>' , 'stop-snapshot', '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":"incremental"}');
INSERT INTO myschema.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'stop-snapshot', 3 '{"data-collections": ["schema1.table1", "schema1.table2"], 4 "type":"incremental"}'); 5
Key = `test_connector` Value = `{"type":"stop-snapshot","data": {"data-collections": ["schema1.table1", "schema1.table2"], "type": "INCREMENTAL"}}`
{"type": "blocking", "data-collections": ["schema1.table1", "schema1.table2"], "additional-conditions": [{"data-collection": "schema1.table1", "filter": "SELECT * FROM [schema1].[table1] WHERE column1 = 0 ORDER BY column2 DESC"}, {"data-collection": "schema1.table2", "filter": "SELECT * FROM [schema1].[table2] WHERE column2 > 0"}]}
{ "schema": { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "databaseName" } ], "optional": false, "name": "io.debezium.connector.db2.SchemaChangeKey", "version": 1 }, "payload": { "databaseName": "inventory" } }
{ "schema": { }, "payload": { "source": { "version": "2.7.3.Final", "connector": "db2", "name": "db2", "ts_ms": 0, "snapshot": "true", "db": "testdb", "schema": "DB2INST1", "table": "CUSTOMERS", "change_lsn": null, "commit_lsn": "00000025:00000d98:00a2", "event_serial_no": null }, "ts_ms": 1588252618953, 1 "databaseName": "TESTDB", 2 "schemaName": "DB2INST1", "ddl": null, 3 "tableChanges": [ 4 { "type": "CREATE", 5 "id": "\"DB2INST1\".\"CUSTOMERS\"", 6 "table": { 7 "defaultCharsetName": null, "primaryKeyColumnNames": [ 8 "ID" ], "columns": [ 9 { "name": "ID", "jdbcType": 4, "nativeType": null, "typeName": "int identity", "typeExpression": "int identity", "charsetName": null, "length": 10, "scale": 0, "position": 1, "optional": false, "autoIncremented": false, "generated": false }, { "name": "FIRST_NAME", "jdbcType": 12, "nativeType": null, "typeName": "varchar", "typeExpression": "varchar", "charsetName": null, "length": 255, "scale": null, "position": 2, "optional": false, "autoIncremented": false, "generated": false }, { "name": "LAST_NAME", "jdbcType": 12, "nativeType": null, "typeName": "varchar", "typeExpression": "varchar", "charsetName": null, "length": 255, "scale": null, "position": 3, "optional": false, "autoIncremented": false, "generated": false }, { "name": "EMAIL", "jdbcType": 12, "nativeType": null, "typeName": "varchar", "typeExpression": "varchar", "charsetName": null, "length": 255, "scale": null, "position": 4, "optional": false, "autoIncremented": false, "generated": false } ], "attributes": [ 10 { "customAttribute": "attributeValue" } ] } } ] } }
{ "schema": { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "databaseName" } ], "optional": false, "name": "io.debezium.connector.db2.SchemaChangeKey", "version": 1 }, "payload": { "databaseName": "TESTDB" } }
{ "status": "BEGIN", "id": "00000025:00000d08:0025", "ts_ms": 1486500577125, "event_count": null, "data_collections": null } { "status": "END", "id": "00000025:00000d08:0025", "ts_ms": 1486500577691, "event_count": 2, "data_collections": [ { "data_collection": "testDB.dbo.tablea", "event_count": 1 }, { "data_collection": "testDB.dbo.tableb", "event_count": 1 } ] }
{ "before": null, "after": { "pk": "2", "aa": "1" }, "source": { }, "op": "c", "ts_ms": "1580390884335", "ts_us": "1580390884335875", "ts_ns": "1580390884335875412", "transaction": { "id": "00000025:00000d08:0025", "total_order": "1", "data_collection_order": "1" } }
{ "schema": { 1 }, "payload": { 2 }, "schema": { 3 }, "payload": { 4 }, }
CREATE TABLE customers ( ID INTEGER IDENTITY(1001,1) NOT NULL PRIMARY KEY, FIRST_NAME VARCHAR(255) NOT NULL, LAST_NAME VARCHAR(255) NOT NULL, EMAIL VARCHAR(255) NOT NULL UNIQUE );
{ "schema": { 1 "type": "struct", "fields": [ 2 { "type": "int32", "optional": false, "field": "ID" } ], "optional": false, 3 "name": "mydatabase.MYSCHEMA.CUSTOMERS.Key" 4 }, "payload": { 5 "ID": 1004 } }
CREATE TABLE customers ( ID INTEGER IDENTITY(1001,1) NOT NULL PRIMARY KEY, FIRST_NAME VARCHAR(255) NOT NULL, LAST_NAME VARCHAR(255) NOT NULL, EMAIL VARCHAR(255) NOT NULL UNIQUE );
{ "schema": { 1 "type": "struct", "fields": [ { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "ID" }, { "type": "string", "optional": false, "field": "FIRST_NAME" }, { "type": "string", "optional": false, "field": "LAST_NAME" }, { "type": "string", "optional": false, "field": "EMAIL" } ], "optional": true, "name": "mydatabase.MYSCHEMA.CUSTOMERS.Value", 2 "field": "before" }, { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "ID" }, { "type": "string", "optional": false, "field": "FIRST_NAME" }, { "type": "string", "optional": false, "field": "LAST_NAME" }, { "type": "string", "optional": false, "field": "EMAIL" } ], "optional": true, "name": "mydatabase.MYSCHEMA.CUSTOMERS.Value", "field": "after" }, { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "version" }, { "type": "string", "optional": false, "field": "connector" }, { "type": "string", "optional": false, "field": "name" }, { "type": "int64", "optional": false, "field": "ts_ms" }, { "type": "int64", "optional": false, "field": "ts_us" }, { "type": "int64", "optional": false, "field": "ts_ns" }, { "type": "boolean", "optional": true, "default": false, "field": "snapshot" }, { "type": "string", "optional": false, "field": "db" }, { "type": "string", "optional": false, "field": "schema" }, { "type": "string", "optional": false, "field": "table" }, { "type": "string", "optional": true, "field": "change_lsn" }, { "type": "string", "optional": true, "field": "commit_lsn" }, ], "optional": false, "name": "io.debezium.connector.db2.Source", 3 "field": "source" }, { "type": "string", "optional": false, "field": "op" }, { "type": "int64", "optional": true, "field": "ts_ms" }, { "type": "int64", "optional": true, "field": "ts_us" }, { "type": "int64", "optional": true, "field": "ts_ns" } ], "optional": false, "name": "mydatabase.MYSCHEMA.CUSTOMERS.Envelope" 4 }, "payload": { 5 "before": null, 6 "after": { 7 "ID": 1005, "FIRST_NAME": "john", "LAST_NAME": "doe", "EMAIL": "john.doe@example.org" }, "source": { 8 "version": "2.7.3.Final", "connector": "db2", "name": "myconnector", "ts_ms": 1559729468470, "ts_us": 1559729468470476, "ts_ns": 1559729468470476000, "snapshot": false, "db": "mydatabase", "schema": "MYSCHEMA", "table": "CUSTOMERS", "change_lsn": "00000027:00000758:0003", "commit_lsn": "00000027:00000758:0005", }, "op": "c", 9 "ts_ms": 1559729471739, 10 "ts_us": 1559729471739762, 11 "ts_ns": 1559729471739762314 12 } }
{ "schema": { ... }, "payload": { "before": { 1 "ID": 1005, "FIRST_NAME": "john", "LAST_NAME": "doe", "EMAIL": "john.doe@example.org" }, "after": { 2 "ID": 1005, "FIRST_NAME": "john", "LAST_NAME": "doe", "EMAIL": "noreply@example.org" }, "source": { 3 "version": "2.7.3.Final", "connector": "db2", "name": "myconnector", "ts_ms": 1559729995937, "ts_us": 1559729995937497, "ts_ns": 1559729995937497000, "snapshot": false, "db": "mydatabase", "schema": "MYSCHEMA", "table": "CUSTOMERS", "change_lsn": "00000027:00000ac0:0002", "commit_lsn": "00000027:00000ac0:0007", }, "op": "u", 4 "ts_ms": 1559729998706, 5 "ts_us": 1559729998706647, 6 "ts_ns": 1559729998706647825 7 } }
{ "schema": { ... }, }, "payload": { "before": { 1 "ID": 1005, "FIRST_NAME": "john", "LAST_NAME": "doe", "EMAIL": "noreply@example.org" }, "after": null, 2 "source": { 3 "version": "2.7.3.Final", "connector": "db2", "name": "myconnector", "ts_ms": 1559730445243, "ts_us": 1559730445243482, "ts_ns": 1559730445243482000, "snapshot": false, "db": "mydatabase", "schema": "MYSCHEMA", "table": "CUSTOMERS", "change_lsn": "00000027:00000db0:0005", "commit_lsn": "00000027:00000db0:0007" }, "op": "d", 4 "ts_ms": 1559730450205, 5 "ts_us": 1559730450205521, 6 "ts_ns": 1559730450205521475 7 } }
cd USDHOME/asncdctools/src
bldrtn asncdc
db2 start db DB_NAME
cd USDHOME/sqllib/bnd
db2 connect to DB_NAME db2 bind db2schema.bnd blocking all grant public sqlerror continue
db2 backup db DB_NAME to BACK_UP_LOCATION
db2 restart db DB_NAME
db2 connect to DB_NAME
cp USDHOME/asncdctools/src/asncdc USDHOME/sqllib/function
chmod 777 USDHOME/sqllib/function
db2 -tvmf USDHOME/asncdctools/src/asncdc_UDF.sql
db2 -tvmf USDHOME/asncdctools/src/asncdctables.sql
db2 -tvmf USDHOME/asncdctools/src/asncdcaddremove.sql
VALUES ASNCDC.ASNCDCSERVICES('start','asncdc');
db2 "VALUES ASNCDC.ASNCDCSERVICES('start','asncdc');"
/database/config/db2inst1/sqllib/bin/asncap capture_schema=asncdc capture_server=SAMPLE &
CALL ASNCDC.ADDTABLE('MYSCHEMA', 'MYTABLE');
VALUES ASNCDC.ASNCDCSERVICES('reinit','asncdc');
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: debezium-kafka-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: version: 3.6.0 build: 2 output: 3 type: imagestream 4 image: debezium-streams-connect:latest plugins: 5 - name: debezium-connector-db2 artifacts: - type: zip 6 url: https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-db2/2.7.3.Final-redhat-00001/debezium-connector-db2-2.7.3.Final-redhat-00001-plugin.zip 7 - type: zip url: https://maven.repository.redhat.com/ga/io/apicurio/apicurio-registry-distro-connect-converter/2.4.4.Final-redhat- <build-number> /apicurio-registry-distro-connect-converter-2.4.4.Final-redhat- <build-number> .zip 8 - type: zip url: https://maven.repository.redhat.com/ga/io/debezium/debezium-scripting/2.7.3.Final-redhat-00001/debezium-scripting-2.7.3.Final-redhat-00001.zip 9 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy/3.0.11/groovy-3.0.11.jar 10 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-jsr223/3.0.11/groovy-jsr223-3.0.11.jar - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-json3.0.11/groovy-json-3.0.11.jar - type: jar 11 url: https://repo1.maven.org/maven2/com/ibm/db2/jcc/11.5.0.0/jcc-11.5.0.0.jar bootstrapServers: debezium-kafka-cluster-kafka-bootstrap:9093
create -f dbz-connect.yaml
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: labels: strimzi.io/cluster: debezium-kafka-connect-cluster name: inventory-connector-db2 1 spec: class: io.debezium.connector.db2.Db2ConnectorConnector 2 tasksMax: 1 3 config: 4 schema.history.internal.kafka.bootstrap.servers: debezium-kafka-cluster-kafka-bootstrap.debezium.svc.cluster.local:9092 schema.history.internal.kafka.topic: schema-changes.inventory database.hostname: db2.debezium-db2.svc.cluster.local 5 database.port: 50000 6 database.user: debezium 7 database.password: dbz 8 database.dbname: mydatabase 9 topic.prefix: inventory-connector-db2 10 table.include.list: public.inventory 11
create -n <namespace> -f <kafkaConnector> .yaml
create -n debezium -f db2-inventory-connector.yaml
cat <<EOF >debezium-container-for-db2.yaml 1 FROM registry.redhat.io/amq-streams-kafka-35-rhel8:2.5.0 USER root:root RUN mkdir -p /opt/kafka/plugins/debezium 2 RUN cd /opt/kafka/plugins/debezium/ && curl -O https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-db2/2.7.3.Final-redhat-00001/debezium-connector-db2-2.7.3.Final-redhat-00001-plugin.zip && unzip debezium-connector-db2-2.7.3.Final-redhat-00001-plugin.zip && rm debezium-connector-db2-2.7.3.Final-redhat-00001-plugin.zip RUN cd /opt/kafka/plugins/debezium/ && curl -O https://repo1.maven.org/maven2/com/ibm/db2/jcc/11.5.0.0/jcc-11.5.0.0.jar USER 1001 EOF
build -t debezium-container-for-db2:latest .
docker build -t debezium-container-for-db2:latest .
push <myregistry.io> /debezium-container-for-db2:latest
docker push <myregistry.io> /debezium-container-for-db2:latest
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: # image: debezium-container-for-db2 2
create -f dbz-connect.yaml
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: inventory-connector-db2 1 labels: strimzi.io/cluster: my-connect-cluster annotations: strimzi.io/use-connector-resources: 'true' spec: class: io.debezium.connector.db2.Db2Connector 2 tasksMax: 1 3 config: 4 database.hostname: 192.168.99.100 5 database.port: 50000 6 database.user: db2inst1 7 database.password: Password! 8 database.dbname: mydatabase 9 topic.prefix: inventory-connector-db2 10 table.include.list: public.inventory 11
apply -f inventory-connector.yaml
describe KafkaConnector <connector-name> -n <project>
describe KafkaConnector inventory-connector-db2 -n debezium
Name: inventory-connector-db2 Namespace: debezium Labels: strimzi.io/cluster=debezium-kafka-connect-cluster Annotations: <none> API Version: kafka.strimzi.io/v1beta2 Kind: KafkaConnector Status: Conditions: Last Transition Time: 2021-12-08T17:41:34.897153Z Status: True Type: Ready Connector Status: Connector: State: RUNNING worker_id: 10.131.1.124:8083 Name: inventory-connector-db2 Tasks: Id: 0 State: RUNNING worker_id: 10.131.1.124:8083 Type: source Observed Generation: 1 Tasks Max: 1 Topics: inventory-connector-db2.inventory inventory-connector-db2.inventory.addresses inventory-connector-db2.inventory.customers inventory-connector-db2.inventory.geom inventory-connector-db2.inventory.orders inventory-connector-db2.inventory.products inventory-connector-db2.inventory.products_on_hand Events: <none>
get kafkatopics
NAME CLUSTER PARTITIONS REPLICATION FACTOR READY connect-cluster-configs debezium-kafka-cluster 1 1 True connect-cluster-offsets debezium-kafka-cluster 25 1 True connect-cluster-status debezium-kafka-cluster 5 1 True consumer-offsets---84e7a678d08f4bd226872e5cdd4eb527fadc1c6a debezium-kafka-cluster 50 1 True inventory-connector-db2--a96f69b23d6118ff415f772679da623fbbb99421 debezium-kafka-cluster 1 1 True inventory-connector-db2.inventory.addresses---1b6beaf7b2eb57d177d92be90ca2b210c9a56480 debezium-kafka-cluster 1 1 True inventory-connector-db2.inventory.customers---9931e04ec92ecc0924f4406af3fdace7545c483b debezium-kafka-cluster 1 1 True inventory-connector-db2.inventory.geom---9f7e136091f071bf49ca59bf99e86c713ee58dd5 debezium-kafka-cluster 1 1 True inventory-connector-db2.inventory.orders---ac5e98ac6a5d91e04d8ec0dc9078a1ece439081d debezium-kafka-cluster 1 1 True inventory-connector-db2.inventory.products---df0746db116844cee2297fab611c21b56f82dcef debezium-kafka-cluster 1 1 True inventory-connector-db2.inventory.products_on_hand---8649e0f17ffcc9212e266e31a7aeea4585e5c6b5 debezium-kafka-cluster 1 1 True schema-changes.inventory debezium-kafka-cluster 1 1 True strimzi-store-topic---effb8e3e057afce1ecf67c3f5d8e4e3ff177fc55 debezium-kafka-cluster 1 1 True strimzi-topic-operator-kstreams-topic-store-changelog---b75e702040b99be8a9263134de3507fc0cc4017b debezium-kafka-cluster 1 1 True
exec -n <project> -it <kafka-cluster> -- /opt/kafka/bin/kafka-console-consumer.sh > --bootstrap-server localhost:9092 > --from-beginning > --property print.key=true > --topic= <topic-name >
exec -n debezium -it debezium-kafka-cluster-kafka-0 -- /opt/kafka/bin/kafka-console-consumer.sh > --bootstrap-server localhost:9092 > --from-beginning > --property print.key=true > --topic=inventory-connector-db2.inventory.products_on_hand
{"schema":{"type":"struct","fields":[{"type":"int32","optional":false,"field":"product_id"}],"optional":false,"name":"inventory-connector-db2.inventory.products_on_hand.Key"},"payload":{"product_id":101}} {"schema":{"type":"struct","fields":[{"type":"struct","fields":[{"type":"int32","optional":false,"field":"product_id"},{"type":"int32","optional":false,"field":"quantity"}],"optional":true,"name":"inventory-connector-db2.inventory.products_on_hand.Value","field":"before"},{"type":"struct","fields":[{"type":"int32","optional":false,"field":"product_id"},{"type":"int32","optional":false,"field":"quantity"}],"optional":true,"name":"inventory-connector-db2.inventory.products_on_hand.Value","field":"after"},{"type":"struct","fields":[{"type":"string","optional":false,"field":"version"},{"type":"string","optional":false,"field":"connector"},{"type":"string","optional":false,"field":"name"},{"type":"int64","optional":false,"field":"ts_ms"},{"type":"int64","optional":false,"field":"ts_us"},{"type":"int64","optional":false,"field":"ts_ns"},{"type":"string","optional":true,"name":"io.debezium.data.Enum","version":1,"parameters":{"allowed":"true,last,false"},"default":"false","field":"snapshot"},{"type":"string","optional":false,"field":"db"},{"type":"string","optional":true,"field":"sequence"},{"type":"string","optional":true,"field":"table"},{"type":"int64","optional":false,"field":"server_id"},{"type":"string","optional":true,"field":"gtid"},{"type":"string","optional":false,"field":"file"},{"type":"int64","optional":false,"field":"pos"},{"type":"int32","optional":false,"field":"row"},{"type":"int64","optional":true,"field":"thread"},{"type":"string","optional":true,"field":"query"}],"optional":false,"name":"io.debezium.connector.db2.Source","field":"source"},{"type":"string","optional":false,"field":"op"},{"type":"int64","optional":true,"field":"ts_ms"},{"type":"int64","optional":true,"field":"ts_us"},{"type":"int64","optional":true,"field":"ts_ns"},{"type":"struct","fields":[{"type":"string","optional":false,"field":"id"},{"type":"int64","optional":false,"field":"total_order"},{"type":"int64","optional":false,"field":"data_collection_order"}],"optional":true,"field":"transaction"}],"optional":false,"name": "inventory-connector-db2.inventory.products_on_hand.Envelope" }, "payload" :{ "before" : null , "after" :{ "product_id":101,"quantity":3 },"source":{"version":"2.7.3.Final-redhat-00001","connector":"db2","name":"inventory-connector-db2","ts_ms":1638985247805,"ts_us":1638985247805000000,"ts_ns":1638985247805000000,"snapshot":"true","db":"inventory","sequence":null,"table":"products_on_hand","server_id":0,"gtid":null,"file":"db2-bin.000003","pos":156,"row":0,"thread":null,"query":null}, "op" : "r" ,"ts_ms":1638985247805,"ts_us":1638985247805102,"ts_ns":1638985247805102588,"transaction":null}}
column.mask.hash.SHA-256.with.salt.CzQMA0cB5K = inventory.orders.customerName, inventory.shipment.customerName
isbn.type: io.debezium.test.IsbnConverter
isbn.schema.name: io.debezium.db2.type.Isbn
"snapshot.select.statement.overrides": "customer.orders", "snapshot.select.statement.overrides.customer.orders": "SELECT * FROM customers.orders WHERE delete_flag = 0 ORDER BY id DESC"
schema.history.internal.producer.security.protocol=SSL schema.history.internal.producer.ssl.keystore.location=/var/private/ssl/kafka.server.keystore.jks schema.history.internal.producer.ssl.keystore.password=test1234 schema.history.internal.producer.ssl.truststore.location=/var/private/ssl/kafka.server.truststore.jks schema.history.internal.producer.ssl.truststore.password=test1234 schema.history.internal.producer.ssl.key.password=test1234 schema.history.internal.consumer.security.protocol=SSL schema.history.internal.consumer.ssl.keystore.location=/var/private/ssl/kafka.server.keystore.jks schema.history.internal.consumer.ssl.keystore.password=test1234 schema.history.internal.consumer.ssl.truststore.location=/var/private/ssl/kafka.server.truststore.jks schema.history.internal.consumer.ssl.truststore.password=test1234 schema.history.internal.consumer.ssl.key.password=test1234
debezium.db2:type=connector-metrics,context=streaming,server= <topic.prefix>
debezium.db2:type=connector-metrics,context=streaming,server= <topic.prefix> ,database=salesdb-streaming,table=inventory
{ "schema": { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "databaseName" } ], "optional": false, "name": "io.debezium.connector.mariadb.SchemaChangeKey", "version": 1 }, "payload": { "databaseName": "inventory" } }
{ "schema": { }, "payload": { "source": { 1 "version": "2.7.3.Final", "connector": "mariadb", "name": "mariadb", "ts_ms": 1651535750218, 2 "ts_us": 1651535750218000, 3 "ts_ns": 1651535750218000000, 4 "snapshot": "false", "db": "inventory", "sequence": null, "table": "customers", "server_id": 223344, "gtid": null, "file": "mariadb-bin.000003", "pos": 570, "row": 0, "thread": null, "query": null }, "databaseName": "inventory", 5 "schemaName": null, "ddl": "ALTER TABLE customers ADD middle_name varchar(255) AFTER first_name", 6 "tableChanges": [ 7 { "type": "ALTER", 8 "id": "\"inventory\".\"customers\"", 9 "table": { 10 "defaultCharsetName": "utf8mb4", "primaryKeyColumnNames": [ 11 "id" ], "columns": [ 12 { "name": "id", "jdbcType": 4, "nativeType": null, "typeName": "INT", "typeExpression": "INT", "charsetName": null, "length": null, "scale": null, "position": 1, "optional": false, "autoIncremented": true, "generated": true }, { "name": "first_name", "jdbcType": 12, "nativeType": null, "typeName": "VARCHAR", "typeExpression": "VARCHAR", "charsetName": "utf8mb4", "length": 255, "scale": null, "position": 2, "optional": false, "autoIncremented": false, "generated": false }, { "name": "middle_name", "jdbcType": 12, "nativeType": null, "typeName": "VARCHAR", "typeExpression": "VARCHAR", "charsetName": "utf8mb4", "length": 255, "scale": null, "position": 3, "optional": true, "autoIncremented": false, "generated": false }, { "name": "last_name", "jdbcType": 12, "nativeType": null, "typeName": "VARCHAR", "typeExpression": "VARCHAR", "charsetName": "utf8mb4", "length": 255, "scale": null, "position": 4, "optional": false, "autoIncremented": false, "generated": false }, { "name": "email", "jdbcType": 12, "nativeType": null, "typeName": "VARCHAR", "typeExpression": "VARCHAR", "charsetName": "utf8mb4", "length": 255, "scale": null, "position": 5, "optional": false, "autoIncremented": false, "generated": false } ], "attributes": [ 13 { "customAttribute": "attributeValue" } ] } } ] } }
INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}');
INSERT INTO db1.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'execute-snapshot', 3 '{"data-collections": ["db1.table1", "db1.table2"], 4 "type":"incremental", 5 "additional-conditions":[{"data-collection": "db1.table1" ,"filter":"color=\'blue\'"}]}'); 6
SELECT * FROM <tableName> .
SELECT * FROM <data-collection> WHERE <filter> .
INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}');
INSERT INTO db1.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["db1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "db1.products", "filter": "color=blue"}]}');
INSERT INTO db1.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["db1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "db1.products", "filter": "color=blue AND quantity>10"}]}');
{ "before":null, "after": { "pk":"1", "value":"New data" }, "source": { "snapshot":"incremental" 1 }, "op":"r", 2 "ts_ms":"1620393591654", "ts_us":"1620393591654547", "ts_ns":"1620393591654547920", "transaction":null }
Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["{collection-container}.table1", "{collection-container}.table2"], "type": "INCREMENTAL"}}`
Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["db1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "db1.products" ,"filter":"color='blue'"}]}}`
Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["db1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "db1.products" ,"filter":"color='blue' AND brand='MyBrand'"}]}}`
INSERT INTO <signalTable> (id, type, data) values ( '<id>' , 'stop-snapshot', '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":"incremental"}');
INSERT INTO db1.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'stop-snapshot', 3 '{"data-collections": ["db1.table1", "db1.table2"], 4 "type":"incremental"}'); 5
Key = `test_connector` Value = `{"type":"stop-snapshot","data": {"data-collections": ["db1.table1", "db1.table2"], "type": "INCREMENTAL"}}`
{"type": "blocking", "data-collections": ["schema1.table1", "schema1.table2"], "additional-conditions": [{"data-collection": "schema1.table1", "filter": "SELECT * FROM [schema1].[table1] WHERE column1 = 0 ORDER BY column2 DESC"}, {"data-collection": "schema1.table2", "filter": "SELECT * FROM [schema1].[table2] WHERE column2 > 0"}]}
fulfillment.inventory.orders fulfillment.inventory.customers fulfillment.inventory.products
{ "status": "BEGIN", "id": "0e4d5dcd-a33b-11ea-80f1-02010a22a99e:10", "ts_ms": 1486500577125, "event_count": null, "data_collections": null } { "status": "END", "id": "0e4d5dcd-a33b-11ea-80f1-02010a22a99e:10", "ts_ms": 1486500577691, "event_count": 2, "data_collections": [ { "data_collection": "s1.a", "event_count": 1 }, { "data_collection": "s2.a", "event_count": 1 } ] }
{ "before": null, "after": { "pk": "2", "aa": "1" }, "source": { }, "op": "c", "ts_ms": "1580390884335", "ts_us": "1580390884335472", "ts_ns": "1580390884335472987", "transaction": { "id": "0e4d5dcd-a33b-11ea-80f1-02010a22a99e:10", "total_order": "1", "data_collection_order": "1" } }
{ "schema": { 1 }, "payload": { 2 }, "schema": { 3 }, "payload": { 4 }, }
CREATE TABLE customers ( id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY, first_name VARCHAR(255) NOT NULL, last_name VARCHAR(255) NOT NULL, email VARCHAR(255) NOT NULL UNIQUE KEY ) AUTO_INCREMENT=1001;
{ "schema": { 1 "type": "struct", "name": "mariadb-server-1.inventory.customers.Key", 2 "optional": false, 3 "fields": [ 4 { "field": "id", "type": "int32", "optional": false } ] }, "payload": { 5 "id": 1001 } }
CREATE TABLE customers ( id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY, first_name VARCHAR(255) NOT NULL, last_name VARCHAR(255) NOT NULL, email VARCHAR(255) NOT NULL UNIQUE KEY ) AUTO_INCREMENT=1001;
{ "schema": { 1 "type": "struct", "fields": [ { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "id" }, { "type": "string", "optional": false, "field": "first_name" }, { "type": "string", "optional": false, "field": "last_name" }, { "type": "string", "optional": false, "field": "email" } ], "optional": true, "name": "mariadb-server-1.inventory.customers.Value", 2 "field": "before" }, { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "id" }, { "type": "string", "optional": false, "field": "first_name" }, { "type": "string", "optional": false, "field": "last_name" }, { "type": "string", "optional": false, "field": "email" } ], "optional": true, "name": "mariadb-server-1.inventory.customers.Value", "field": "after" }, { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "version" }, { "type": "string", "optional": false, "field": "connector" }, { "type": "string", "optional": false, "field": "name" }, { "type": "int64", "optional": false, "field": "ts_ms" }, { "type": "int64", "optional": false, "field": "ts_us" }, { "type": "int64", "optional": false, "field": "ts_ns" }, { "type": "boolean", "optional": true, "default": false, "field": "snapshot" }, { "type": "string", "optional": false, "field": "db" }, { "type": "string", "optional": true, "field": "table" }, { "type": "int64", "optional": false, "field": "server_id" }, { "type": "string", "optional": true, "field": "gtid" }, { "type": "string", "optional": false, "field": "file" }, { "type": "int64", "optional": false, "field": "pos" }, { "type": "int32", "optional": false, "field": "row" }, { "type": "int64", "optional": true, "field": "thread" }, { "type": "string", "optional": true, "field": "query" } ], "optional": false, "name": "io.debezium.connector.mariadb.Source", 3 "field": "source" }, { "type": "string", "optional": false, "field": "op" }, { "type": "int64", "optional": true, "field": "ts_ms" }, { "type": "int64", "optional": true, "field": "ts_us" }, { "type": "int64", "optional": true, "field": "ts_ns" } ], "optional": false, "name": "mariadb-server-1.inventory.customers.Envelope" 4 }, "payload": { 5 "op": "c", 6 "ts_ms": 1465491411815, 7 "ts_us": 1465491411815437, 8 "ts_ns": 1465491411815437158, 9 "before": null, 10 "after": { 11 "id": 1004, "first_name": "Anne", "last_name": "Kretchmar", "email": "annek@noanswer.org" }, "source": { 12 "version": "2.7.3.Final", "connector": "mariadb", "name": "mariadb-server-1", "ts_ms": 0, "ts_us": 0, "ts_ns": 0, "snapshot": false, "db": "inventory", "table": "customers", "server_id": 0, "gtid": null, "file": "mariadb-bin.000003", "pos": 154, "row": 0, "thread": 7, "query": "INSERT INTO customers (first_name, last_name, email) VALUES ('Anne', 'Kretchmar', 'annek@noanswer.org')" } } }
{ "schema": { ... }, "payload": { "before": { 1 "id": 1004, "first_name": "Anne", "last_name": "Kretchmar", "email": "annek@noanswer.org" }, "after": { 2 "id": 1004, "first_name": "Anne Marie", "last_name": "Kretchmar", "email": "annek@noanswer.org" }, "source": { 3 "version": "2.7.3.Final", "name": "mariadb-server-1", "connector": "mariadb", "name": "mariadb-server-1", "ts_ms": 1465581029100, "ts_ms": 1465581029100000, "ts_ms": 1465581029100000000, "snapshot": false, "db": "inventory", "table": "customers", "server_id": 223344, "gtid": null, "file": "mariadb-bin.000003", "pos": 484, "row": 0, "thread": 7, "query": "UPDATE customers SET first_name='Anne Marie' WHERE id=1004" }, "op": "u", 4 "ts_ms": 1465581029523, 5 "ts_ms": 1465581029523758, 6 "ts_ms": 1465581029523758914 7 } }
{ "schema": { ... }, "payload": { "before": { 1 "id": 1004, "first_name": "Anne Marie", "last_name": "Kretchmar", "email": "annek@noanswer.org" }, "after": null, 2 "source": { 3 "version": "2.7.3.Final", "connector": "mariadb", "name": "mariadb-server-1", "ts_ms": 1465581902300, "ts_us": 1465581902300000, "ts_ns": 1465581902300000000, "snapshot": false, "db": "inventory", "table": "customers", "server_id": 223344, "gtid": null, "file": "mariadb-bin.000003", "pos": 805, "row": 0, "thread": 7, "query": "DELETE FROM customers WHERE id=1004" }, "op": "d", 4 "ts_ms": 1465581902461, 5 "ts_us": 1465581902461842, 6 "ts_ns": 1465581902461842579 7 } }
{ "schema": { ... }, "payload": { "source": { 1 "version": "2.7.3.Final", "name": "mariadb-server-1", "connector": "mariadb", "name": "mariadb-server-1", "ts_ms": 1465581029100, "ts_us": 1465581029100000, "ts_ns": 1465581029100000000, "snapshot": false, "db": "inventory", "table": "customers", "server_id": 223344, "gtid": null, "file": "mariadb-bin.000003", "pos": 484, "row": 0, "thread": 7, "query": "UPDATE customers SET first_name='Anne Marie' WHERE id=1004" }, "op": "t", 2 "ts_ms": 1465581029523, 3 "ts_us": 1465581029523468, 4 "ts_ns": 1465581029523468471 5 } }
converters=boolean boolean.type=io.debezium.connector.binlog.converters.TinyIntOneToBooleanConverter boolean.selector=db1.table1.*, db1.table2.column1
converters=boolean boolean.type=io.debezium.connector.binlog.converters.TinyIntOneToBooleanConverter boolean.length.checker=false boolean.selector=db1.table1.*, db1.table2.column1
converters=tinyint-one-to-boolean tinyint-one-to-boolean.type=io.debezium.connector.binlog.converters.TinyIntOneToBooleanConverter tinyint-one-to-boolean.selector=.*.MY_TABLE.DATA tinyint-one-to-boolean.length.checker=false
converters=jdbc-sink jdbc-sink.type=io.debezium.connector.binlog.converters.JdbcSinkDataTypesConverter jdbc-sink.selector.boolean=.*.MY_TABLE.BOOL_COL jdbc-sink.selector.real=.*.MY_TABLE.REAL_COL jdbc-sink.selector.string=.*.MY_TABLE.STRING_COL jdbc-sink.treat.real.as.double=true
mariadb> CREATE USER 'user'@'localhost' IDENTIFIED BY 'password';
mariadb> GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'user' IDENTIFIED BY 'password';
mariadb> FLUSH PRIVILEGES;
server-id = 223344 # Querying variable is called server_id, e.g. SELECT variable_value FROM information_schema.global_variables WHERE variable_name='server_id'; log_bin = mariadb-bin binlog_format = ROW binlog_row_image = FULL binlog_expire_logs_seconds = 864000
mariadb> interactive_timeout=<duration-in-seconds>
mariadb> wait_timeout=<duration-in-seconds>
mariadb> binlog_annotate_row_events=ON
mariadb> show global variables where variable_name = 'binlog_row_value_options';
+--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | binlog_row_value_options | | +--------------------------+-------+
mariadb> set @@global.binlog_row_value_options="" ;
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: debezium-kafka-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: version: 3.6.0 build: 2 output: 3 type: imagestream 4 image: debezium-streams-connect:latest plugins: 5 - name: debezium-connector-mariadb artifacts: - type: zip 6 url: https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-mariadb/2.7.3.Final-redhat-00001/debezium-connector-mariadb-2.7.3.Final-redhat-00001-plugin.zip 7 - type: zip url: https://maven.repository.redhat.com/ga/io/apicurio/apicurio-registry-distro-connect-converter/2.4.4.Final-redhat- <build-number> /apicurio-registry-distro-connect-converter-2.4.4.Final-redhat- <build-number> .zip 8 - type: zip url: https://maven.repository.redhat.com/ga/io/debezium/debezium-scripting/2.7.3.Final-redhat-00001/debezium-scripting-2.7.3.Final-redhat-00001.zip 9 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy/3.0.11/groovy-3.0.11.jar 10 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-jsr223/3.0.11/groovy-jsr223-3.0.11.jar - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-json3.0.11/groovy-json-3.0.11.jar bootstrapServers: debezium-kafka-cluster-kafka-bootstrap:9093
create -f dbz-connect.yaml
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: labels: strimzi.io/cluster: debezium-kafka-connect-cluster name: inventory-connector-mariadb 1 spec: class: io.debezium.connector.mariadb.MariaDbConnector 2 tasksMax: 1 3 config: 4 schema.history.internal.kafka.bootstrap.servers: debezium-kafka-cluster-kafka-bootstrap.debezium.svc.cluster.local:9092 schema.history.internal.kafka.topic: schema-changes.inventory database.hostname: mariadb.debezium-mariadb.svc.cluster.local 5 database.port: 3306 6 database.user: debezium 7 database.password: dbz 8 database.server.id: 184054 9 topic.prefix: inventory-connector-mariadb 10 table.include.list: inventory.* 11
create -n <namespace> -f <kafkaConnector> .yaml
create -n debezium -f mariadb-inventory-connector.yaml
cat <<EOF >debezium-container-for-mariadb.yaml 1 FROM registry.redhat.io/amq-streams-kafka-35-rhel8:2.5.0 USER root:root RUN mkdir -p /opt/kafka/plugins/debezium 2 RUN cd /opt/kafka/plugins/debezium/ && curl -O https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-mariadb/2.7.3.Final-redhat-00001/debezium-connector-mariadb-2.7.3.Final-redhat-00001-plugin.zip && unzip debezium-connector-mariadb-2.7.3.Final-redhat-00001-plugin.zip && rm debezium-connector-mariadb-2.7.3.Final-redhat-00001-plugin.zip RUN cd /opt/kafka/plugins/debezium/ USER 1001 EOF
build -t debezium-container-for-mariadb:latest .
docker build -t debezium-container-for-mariadb:latest .
push <myregistry.io> /debezium-container-for-mariadb:latest
docker push <myregistry.io> /debezium-container-for-mariadb:latest
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: # image: debezium-container-for-mariadb 2
create -f dbz-connect.yaml
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: inventory-connector-mariadb 1 labels: strimzi.io/cluster: my-connect-cluster spec: class: io.debezium.connector.mariadb.MariaDbConnector tasksMax: 1 2 config: 3 database.hostname: mariadb 4 database.port: 3306 database.user: debezium database.password: dbz database.server.id: 184054 5 topic.prefix: inventory-connector-mariadb 6 table.include.list: inventory 7 schema.history.internal.kafka.bootstrap.servers: my-cluster-kafka-bootstrap:9092 8 schema.history.internal.kafka.topic: schema-changes.inventory 9
apply -f inventory-connector.yaml
describe KafkaConnector <connector-name> -n <project>
describe KafkaConnector inventory-connector-mariadb -n debezium
Name: inventory-connector-mariadb Namespace: debezium Labels: strimzi.io/cluster=debezium-kafka-connect-cluster Annotations: <none> API Version: kafka.strimzi.io/v1beta2 Kind: KafkaConnector Status: Conditions: Last Transition Time: 2021-12-08T17:41:34.897153Z Status: True Type: Ready Connector Status: Connector: State: RUNNING worker_id: 10.131.1.124:8083 Name: inventory-connector-mariadb Tasks: Id: 0 State: RUNNING worker_id: 10.131.1.124:8083 Type: source Observed Generation: 1 Tasks Max: 1 Topics: inventory-connector-mariadb.inventory inventory-connector-mariadb.inventory.addresses inventory-connector-mariadb.inventory.customers inventory-connector-mariadb.inventory.geom inventory-connector-mariadb.inventory.orders inventory-connector-mariadb.inventory.products inventory-connector-mariadb.inventory.products_on_hand Events: <none>
get kafkatopics
NAME CLUSTER PARTITIONS REPLICATION FACTOR READY connect-cluster-configs debezium-kafka-cluster 1 1 True connect-cluster-offsets debezium-kafka-cluster 25 1 True connect-cluster-status debezium-kafka-cluster 5 1 True consumer-offsets---84e7a678d08f4bd226872e5cdd4eb527fadc1c6a debezium-kafka-cluster 50 1 True inventory-connector-mariadb--a96f69b23d6118ff415f772679da623fbbb99421 debezium-kafka-cluster 1 1 True inventory-connector-mariadb.inventory.addresses---1b6beaf7b2eb57d177d92be90ca2b210c9a56480 debezium-kafka-cluster 1 1 True inventory-connector-mariadb.inventory.customers---9931e04ec92ecc0924f4406af3fdace7545c483b debezium-kafka-cluster 1 1 True inventory-connector-mariadb.inventory.geom---9f7e136091f071bf49ca59bf99e86c713ee58dd5 debezium-kafka-cluster 1 1 True inventory-connector-mariadb.inventory.orders---ac5e98ac6a5d91e04d8ec0dc9078a1ece439081d debezium-kafka-cluster 1 1 True inventory-connector-mariadb.inventory.products---df0746db116844cee2297fab611c21b56f82dcef debezium-kafka-cluster 1 1 True inventory-connector-mariadb.inventory.products_on_hand---8649e0f17ffcc9212e266e31a7aeea4585e5c6b5 debezium-kafka-cluster 1 1 True schema-changes.inventory debezium-kafka-cluster 1 1 True strimzi-store-topic---effb8e3e057afce1ecf67c3f5d8e4e3ff177fc55 debezium-kafka-cluster 1 1 True strimzi-topic-operator-kstreams-topic-store-changelog---b75e702040b99be8a9263134de3507fc0cc4017b debezium-kafka-cluster 1 1 True
exec -n <project> -it <kafka-cluster> -- /opt/kafka/bin/kafka-console-consumer.sh > --bootstrap-server localhost:9092 > --from-beginning > --property print.key=true > --topic= <topic-name >
exec -n debezium -it debezium-kafka-cluster-kafka-0 -- /opt/kafka/bin/kafka-console-consumer.sh > --bootstrap-server localhost:9092 > --from-beginning > --property print.key=true > --topic=inventory-connector-mariadb.inventory.products_on_hand
{"schema":{"type":"struct","fields":[{"type":"int32","optional":false,"field":"product_id"}],"optional":false,"name":"inventory-connector-mariadb.inventory.products_on_hand.Key"},"payload":{"product_id":101}} {"schema":{"type":"struct","fields":[{"type":"struct","fields":[{"type":"int32","optional":false,"field":"product_id"},{"type":"int32","optional":false,"field":"quantity"}],"optional":true,"name":"inventory-connector-mariadb.inventory.products_on_hand.Value","field":"before"},{"type":"struct","fields":[{"type":"int32","optional":false,"field":"product_id"},{"type":"int32","optional":false,"field":"quantity"}],"optional":true,"name":"inventory-connector-mariadb.inventory.products_on_hand.Value","field":"after"},{"type":"struct","fields":[{"type":"string","optional":false,"field":"version"},{"type":"string","optional":false,"field":"connector"},{"type":"string","optional":false,"field":"name"},{"type":"int64","optional":false,"field":"ts_ms"},{"type":"int64","optional":false,"field":"ts_us"},{"type":"int64","optional":false,"field":"ts_ns"},{"type":"string","optional":true,"name":"io.debezium.data.Enum","version":1,"parameters":{"allowed":"true,last,false"},"default":"false","field":"snapshot"},{"type":"string","optional":false,"field":"db"},{"type":"string","optional":true,"field":"sequence"},{"type":"string","optional":true,"field":"table"},{"type":"int64","optional":false,"field":"server_id"},{"type":"string","optional":true,"field":"gtid"},{"type":"string","optional":false,"field":"file"},{"type":"int64","optional":false,"field":"pos"},{"type":"int32","optional":false,"field":"row"},{"type":"int64","optional":true,"field":"thread"},{"type":"string","optional":true,"field":"query"}],"optional":false,"name":"io.debezium.connector.mariadb.Source","field":"source"},{"type":"string","optional":false,"field":"op"},{"type":"int64","optional":true,"field":"ts_ms"},{"type":"int64","optional":true,"field":"ts_us"},{"type":"int64","optional":true,"field":"ts_ns"},{"type":"struct","fields":[{"type":"string","optional":false,"field":"id"},{"type":"int64","optional":false,"field":"total_order"},{"type":"int64","optional":false,"field":"data_collection_order"}],"optional":true,"field":"transaction"}],"optional":false,"name": "inventory-connector-mariadb.inventory.products_on_hand.Envelope" }, "payload" :{ "before" : null , "after" :{ "product_id":101,"quantity":3 },"source":{"version":"2.7.3.Final-redhat-00001","connector":"mariadb","name":"inventory-connector-mariadb","ts_ms":1638985247805,"ts_us":1638985247805000000,"ts_ns":1638985247805000000,"snapshot":"true","db":"inventory","sequence":null,"table":"products_on_hand","server_id":0,"gtid":null,"file":"mariadb-bin.000003","pos":156,"row":0,"thread":null,"query":null}, "op" : "r" ,"ts_ms":1638985247805,"ts_us":1638985247805102,"ts_ns":1638985247805102588,"transaction":null}}
column.mask.hash.SHA-256.with.salt.CzQMA0cB5K = inventory.orders.customerName, inventory.shipment.customerName
`_` is an escape sequence, similar to a backslash in Java
boolean.type: io.debezium.connector.binlog.converters.TinyIntOneToBooleanConverter
boolean.selector=db1.table1.*, db1.table2.column1
"snapshot.select.statement.overrides": "customer.orders", "snapshot.select.statement.overrides.customer.orders": "SELECT * FROM [customers].[orders] WHERE delete_flag = 0 ORDER BY id DESC"
schema.history.internal.producer.security.protocol=SSL schema.history.internal.producer.ssl.keystore.location=/var/private/ssl/kafka.server.keystore.jks schema.history.internal.producer.ssl.keystore.password=test1234 schema.history.internal.producer.ssl.truststore.location=/var/private/ssl/kafka.server.truststore.jks schema.history.internal.producer.ssl.truststore.password=test1234 schema.history.internal.producer.ssl.key.password=test1234 schema.history.internal.consumer.security.protocol=SSL schema.history.internal.consumer.ssl.keystore.location=/var/private/ssl/kafka.server.keystore.jks schema.history.internal.consumer.ssl.keystore.password=test1234 schema.history.internal.consumer.ssl.truststore.location=/var/private/ssl/kafka.server.truststore.jks schema.history.internal.consumer.ssl.truststore.password=test1234 schema.history.internal.consumer.ssl.key.password=test1234
debezium.mariadb:type=connector-metrics,context=streaming,server= <topic.prefix>
debezium.mariadb:type=connector-metrics,context=streaming,server= <topic.prefix> ,database=salesdb-streaming,table=inventory
<signalDataCollection> .insert({" id" : _<idNumber> ,"type" : <snapshotType> , "data" : {"data-collections" [" <collectionName> ", " <collectionName> "],"type": <snapshotType> , "additional-conditions" : [{"data-collections" : " <collectionName> ", "filter" : " <additional-condition> "}] }});
db.debeziumSignal.insert({ 1 "type" : "execute-snapshot", 2 3 "data" : { "data-collections" ["\"public\".\"Collection1\"", "\"public\".\"Collection2\""], 4 "type": "incremental"} 5 "additional-conditions":[{"data-collection": "schema1.table1" ,"filter":"color=\'blue\'"}]}'); 6 });
{ "before":null, "after": { "pk":"1", "value":"New data" }, "source": { "snapshot":"incremental" 1 }, "op":"r", 2 "ts_ms":"1620393591654", "ts_us":"1620393591654962", "ts_ns":"1620393591654962147", "transaction":null }
Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["{collection-container}.table1", "{collection-container}.table2"], "type": "INCREMENTAL"}}`
Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["db1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "db1.products" ,"filter":"color='blue'"}]}}`
Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["db1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "db1.products" ,"filter":"color='blue' AND brand='MyBrand'"}]}}`
<signalDataCollection> .insert({" id" : _<idNumber> ,"type" : "stop-snapshot", "data" : {"data-collections" [" <collectionName> ", " <collectionName> "],"type": "incremental"}});
db.debeziumSignal.insert({ 1 "type" : "stop-snapshot", 2 3 "data" : { "data-collections" ["\"public\".\"Collection1\"", "\"public\".\"Collection2\""], 4 "type": "incremental"} 5 });
Key = `test_connector` Value = `{"type":"stop-snapshot","data": {"data-collections": ["db1.table1", "db1.table2"], "type": "INCREMENTAL"}}`
{"type": "blocking", "data-collections": ["schema1.table1", "schema1.table2"], "additional-conditions": [{"data-collection": "schema1.table1", "filter": "SELECT * FROM [schema1].[table1] WHERE column1 = 0 ORDER BY column2 DESC"}, {"data-collection": "schema1.table2", "filter": "SELECT * FROM [schema1].[table2] WHERE column2 > 0"}]}
{ "status": "BEGIN", "id": "1462833718356672513", "event_count": null, "data_collections": null } { "status": "END", "id": "1462833718356672513", "event_count": 2, "data_collections": [ { "data_collection": "rs0.testDB.collectiona", "event_count": 1 }, { "data_collection": "rs0.testDB.collectionb", "event_count": 1 } ] }
{ "after": "{\"_id\" : {\"USDnumberLong\" : \"1004\"},\"first_name\" : \"Anne\",\"last_name\" : \"Kretchmar\",\"email\" : \"annek@noanswer.org\"}", "source": { }, "op": "c", "ts_ms": "1580390884335", "ts_us": "1580390884335486", "ts_ns": "1580390884335486281", "transaction": { "id": "1462833718356672513", "total_order": "1", "data_collection_order": "1" } }
{ "schema": { 1 }, "payload": { 2 }, "schema": { 3 }, "payload": { 4 }, }
_id: 1004
first_name: Anne
last_name: Kretchmar
email: annek@noanswer.org
{ "schema": { 1 "type": "struct", "name": "fulfillment.inventory.customers.Key", 2 "optional": false, 3 "fields": [ 4 { "field": "id", "type": "string", "optional": false } ] }, "payload": { 5 "id": "1004" } }
_id: 1004
first_name: Anne
last_name: Kretchmar
email: annek@noanswer.org
{ "schema": { 1 "type": "struct", "fields": [ { "type": "string", "optional": true, "name": "io.debezium.data.Json", 2 "version": 1, "field": "after" }, { "type": "string", "optional": true, "name": "io.debezium.data.Json", "version": 1, "field": "patch" }, { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "version" }, { "type": "string", "optional": false, "field": "connector" }, { "type": "string", "optional": false, "field": "name" }, { "type": "int64", "optional": false, "field": "ts_ms" }, { "type": "int64", "optional": false, "field": "ts_us" }, { "type": "int64", "optional": false, "field": "ts_ns" }, { "type": "boolean", "optional": true, "default": false, "field": "snapshot" }, { "type": "string", "optional": false, "field": "db" }, { "type": "string", "optional": false, "field": "rs" }, { "type": "string", "optional": false, "field": "collection" }, { "type": "int32", "optional": false, "field": "ord" }, { "type": "int64", "optional": true, "field": "h" } ], "optional": false, "name": "io.debezium.connector.mongo.Source", 3 "field": "source" }, { "type": "string", "optional": true, "field": "op" }, { "type": "int64", "optional": true, "field": "ts_ms" }, { "type": "int64", "optional": true, "field": "ts_us" }, { "type": "int64", "optional": true, "field": "ts_ns" } ], "optional": false, "name": "dbserver1.inventory.customers.Envelope" 4 }, "payload": { 5 "after": "{\"_id\" : {\"USDnumberLong\" : \"1004\"},\"first_name\" : \"Anne\",\"last_name\" : \"Kretchmar\",\"email\" : \"annek@noanswer.org\"}", 6 "source": { 7 "version": "2.7.3.Final", "connector": "mongodb", "name": "fulfillment", "ts_ms": 1558965508000, "ts_ms": 1558965508000000, "ts_ms": 1558965508000000000, "snapshot": false, "db": "inventory", "rs": "rs0", "collection": "customers", "ord": 31, "h": 1546547425148721999 }, "op": "c", 8 "ts_ms": 1558965515240, 9 "ts_us": 1558965515240142, 10 "ts_ns": 1558965515240142879, 11 } }
{ "schema": { ... }, "payload": { "op": "u", 1 "ts_ms": 1465491461815, 2 "ts_us": 1465491461815698, 3 "ts_ns": 1465491461815698142, 4 "before":"{\"_id\": {\"USDnumberLong\": \"1004\"},\"first_name\": \"unknown\",\"last_name\": \"Kretchmar\",\"email\": \"annek@noanswer.org\"}", 5 "after":"{\"_id\": {\"USDnumberLong\": \"1004\"},\"first_name\": \"Anne Marie\",\"last_name\": \"Kretchmar\",\"email\": \"annek@noanswer.org\"}", 6 "updateDescription": { "removedFields": null, "updatedFields": "{\"first_name\": \"Anne Marie\"}", 7 "truncatedArrays": null }, "source": { 8 "version": "2.7.3.Final", "connector": "mongodb", "name": "fulfillment", "ts_ms": 1558965508000, "ts_us": 1558965508000000, "ts_ns": 1558965508000000000, "snapshot": false, "db": "inventory", "rs": "rs0", "collection": "customers", "ord": 1, "h": null, "tord": null, "stxnid": null, "lsid":"{\"id\": {\"USDbinary\": \"FA7YEzXgQXSX9OxmzllH2w==\",\"USDtype\": \"04\"},\"uid\": {\"USDbinary\": \"47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=\",\"USDtype\": \"00\"}}", "txnNumber":1 } } }
{ "schema": { ... }, "payload": { "op": "d", 1 "ts_ms": 1465495462115, 2 "ts_us": 1465495462115748, 3 "ts_ns": 1465495462115748263, 4 "before":"{\"_id\": {\"USDnumberLong\": \"1004\"},\"first_name\": \"Anne Marie\",\"last_name\": \"Kretchmar\",\"email\": \"annek@noanswer.org\"}", 5 "source": { 6 "version": "2.7.3.Final", "connector": "mongodb", "name": "fulfillment", "ts_ms": 1558965508000, "ts_us": 1558965508000000, "ts_ns": 1558965508000000000, "snapshot": true, "db": "inventory", "rs": "rs0", "collection": "customers", "ord": 6, "h": 1546547425148721999 } } }
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: debezium-kafka-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: version: 3.6.0 build: 2 output: 3 type: imagestream 4 image: debezium-streams-connect:latest plugins: 5 - name: debezium-connector-mongodb artifacts: - type: zip 6 url: https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-mongodb/2.7.3.Final-redhat-00001/debezium-connector-mongodb-2.7.3.Final-redhat-00001-plugin.zip 7 - type: zip url: https://maven.repository.redhat.com/ga/io/apicurio/apicurio-registry-distro-connect-converter/2.4.4.Final-redhat- <build-number> /apicurio-registry-distro-connect-converter-2.4.4.Final-redhat- <build-number> .zip 8 - type: zip url: https://maven.repository.redhat.com/ga/io/debezium/debezium-scripting/2.7.3.Final-redhat-00001/debezium-scripting-2.7.3.Final-redhat-00001.zip 9 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy/3.0.11/groovy-3.0.11.jar 10 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-jsr223/3.0.11/groovy-jsr223-3.0.11.jar - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-json3.0.11/groovy-json-3.0.11.jar bootstrapServers: debezium-kafka-cluster-kafka-bootstrap:9093
create -f dbz-connect.yaml
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: labels: strimzi.io/cluster: debezium-kafka-connect-cluster name: inventory-connector-mongodb 1 spec: class: io.debezium.connector.mongodb.MongoDbConnector 2 tasksMax: 1 3 config: 4 mongodb.hosts: rs0/192.168.99.100:27017 5 mongodb.user: debezium 6 mongodb.password: dbz 7 topic.prefix: inventory-connector-mongodb 8 collection.include.list: inventory[.]* 9
create -n <namespace> -f <kafkaConnector> .yaml
create -n debezium -f mongodb-inventory-connector.yaml
cat <<EOF >debezium-container-for-mongodb.yaml 1 FROM registry.redhat.io/amq-streams-kafka-35-rhel8:2.5.0 USER root:root RUN mkdir -p /opt/kafka/plugins/debezium 2 RUN cd /opt/kafka/plugins/debezium/ && curl -O https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-mongodb/2.7.3.Final-redhat-00001/debezium-connector-mongodb-2.7.3.Final-redhat-00001-plugin.zip && unzip debezium-connector-mongodb-2.7.3.Final-redhat-00001-plugin.zip && rm debezium-connector-mongodb-2.7.3.Final-redhat-00001-plugin.zip RUN cd /opt/kafka/plugins/debezium/ USER 1001 EOF
build -t debezium-container-for-mongodb:latest .
docker build -t debezium-container-for-mongodb:latest .
push <myregistry.io> /debezium-container-for-mongodb:latest
docker push <myregistry.io> /debezium-container-for-mongodb:latest
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: # image: debezium-container-for-mongodb 2
create -f dbz-connect.yaml
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: inventory-connector-mongodb 1 labels: strimzi.io/cluster: my-connect-cluster spec: class: io.debezium.connector.mongodb.MongoDbConnector 2 config: mongodb.connection.string: mongodb://192.168.99.100:27017/?replicaSet=rs0 3 topic.prefix: inventory-connector-mongodb 4 collection.include.list: inventory[.]* 5
apply -f inventory-connector.yaml
describe KafkaConnector <connector-name> -n <project>
describe KafkaConnector inventory-connector-mongodb -n debezium
Name: inventory-connector-mongodb Namespace: debezium Labels: strimzi.io/cluster=debezium-kafka-connect-cluster Annotations: <none> API Version: kafka.strimzi.io/v1beta2 Kind: KafkaConnector Status: Conditions: Last Transition Time: 2021-12-08T17:41:34.897153Z Status: True Type: Ready Connector Status: Connector: State: RUNNING worker_id: 10.131.1.124:8083 Name: inventory-connector-mongodb Tasks: Id: 0 State: RUNNING worker_id: 10.131.1.124:8083 Type: source Observed Generation: 1 Tasks Max: 1 Topics: inventory-connector-mongodb.inventory inventory-connector-mongodb.inventory.addresses inventory-connector-mongodb.inventory.customers inventory-connector-mongodb.inventory.geom inventory-connector-mongodb.inventory.orders inventory-connector-mongodb.inventory.products inventory-connector-mongodb.inventory.products_on_hand Events: <none>
get kafkatopics
NAME CLUSTER PARTITIONS REPLICATION FACTOR READY connect-cluster-configs debezium-kafka-cluster 1 1 True connect-cluster-offsets debezium-kafka-cluster 25 1 True connect-cluster-status debezium-kafka-cluster 5 1 True consumer-offsets---84e7a678d08f4bd226872e5cdd4eb527fadc1c6a debezium-kafka-cluster 50 1 True inventory-connector-mongodb--a96f69b23d6118ff415f772679da623fbbb99421 debezium-kafka-cluster 1 1 True inventory-connector-mongodb.inventory.addresses---1b6beaf7b2eb57d177d92be90ca2b210c9a56480 debezium-kafka-cluster 1 1 True inventory-connector-mongodb.inventory.customers---9931e04ec92ecc0924f4406af3fdace7545c483b debezium-kafka-cluster 1 1 True inventory-connector-mongodb.inventory.geom---9f7e136091f071bf49ca59bf99e86c713ee58dd5 debezium-kafka-cluster 1 1 True inventory-connector-mongodb.inventory.orders---ac5e98ac6a5d91e04d8ec0dc9078a1ece439081d debezium-kafka-cluster 1 1 True inventory-connector-mongodb.inventory.products---df0746db116844cee2297fab611c21b56f82dcef debezium-kafka-cluster 1 1 True inventory-connector-mongodb.inventory.products_on_hand---8649e0f17ffcc9212e266e31a7aeea4585e5c6b5 debezium-kafka-cluster 1 1 True schema-changes.inventory debezium-kafka-cluster 1 1 True strimzi-store-topic---effb8e3e057afce1ecf67c3f5d8e4e3ff177fc55 debezium-kafka-cluster 1 1 True strimzi-topic-operator-kstreams-topic-store-changelog---b75e702040b99be8a9263134de3507fc0cc4017b debezium-kafka-cluster 1 1 True
exec -n <project> -it <kafka-cluster> -- /opt/kafka/bin/kafka-console-consumer.sh > --bootstrap-server localhost:9092 > --from-beginning > --property print.key=true > --topic= <topic-name >
exec -n debezium -it debezium-kafka-cluster-kafka-0 -- /opt/kafka/bin/kafka-console-consumer.sh > --bootstrap-server localhost:9092 > --from-beginning > --property print.key=true > --topic=inventory-connector-mongodb.inventory.products_on_hand
{"schema":{"type":"struct","fields":[{"type":"int32","optional":false,"field":"product_id"}],"optional":false,"name":"inventory-connector-mongodb.inventory.products_on_hand.Key"},"payload":{"product_id":101}} {"schema":{"type":"struct","fields":[{"type":"struct","fields":[{"type":"int32","optional":false,"field":"product_id"},{"type":"int32","optional":false,"field":"quantity"}],"optional":true,"name":"inventory-connector-mongodb.inventory.products_on_hand.Value","field":"before"},{"type":"struct","fields":[{"type":"int32","optional":false,"field":"product_id"},{"type":"int32","optional":false,"field":"quantity"}],"optional":true,"name":"inventory-connector-mongodb.inventory.products_on_hand.Value","field":"after"},{"type":"struct","fields":[{"type":"string","optional":false,"field":"version"},{"type":"string","optional":false,"field":"connector"},{"type":"string","optional":false,"field":"name"},{"type":"int64","optional":false,"field":"ts_ms"},{"type":"int64","optional":false,"field":"ts_us"},{"type":"int64","optional":false,"field":"ts_ns"},{"type":"string","optional":true,"name":"io.debezium.data.Enum","version":1,"parameters":{"allowed":"true,last,false"},"default":"false","field":"snapshot"},{"type":"string","optional":false,"field":"db"},{"type":"string","optional":true,"field":"sequence"},{"type":"string","optional":true,"field":"table"},{"type":"int64","optional":false,"field":"server_id"},{"type":"string","optional":true,"field":"gtid"},{"type":"string","optional":false,"field":"file"},{"type":"int64","optional":false,"field":"pos"},{"type":"int32","optional":false,"field":"row"},{"type":"int64","optional":true,"field":"thread"},{"type":"string","optional":true,"field":"query"}],"optional":false,"name":"io.debezium.connector.mongodb.Source","field":"source"},{"type":"string","optional":false,"field":"op"},{"type":"int64","optional":true,"field":"ts_ms"},{"type":"int64","optional":true,"field":"ts_us"},{"type":"int64","optional":true,"field":"ts_ns"},{"type":"struct","fields":[{"type":"string","optional":false,"field":"id"},{"type":"int64","optional":false,"field":"total_order"},{"type":"int64","optional":false,"field":"data_collection_order"}],"optional":true,"field":"transaction"}],"optional":false,"name": "inventory-connector-mongodb.inventory.products_on_hand.Envelope" }, "payload" :{ "before" : null , "after" :{ "product_id":101,"quantity":3 },"source":{"version":"2.7.3.Final-redhat-00001","connector":"mongodb","name":"inventory-connector-mongodb","ts_ms":1638985247805,"ts_us":1638985247805000000,"ts_ns":1638985247805000000,"snapshot":"true","db":"inventory","sequence":null,"table":"products_on_hand","server_id":0,"gtid":null,"file":"mongodb-bin.000003","pos":156,"row":0,"thread":null,"query":null}, "op" : "r" ,"ts_ms":1638985247805,"ts_us":1638985247805102,"ts_ns":1638985247805102588,"transaction":null}}
debezium.mongodb:type=connector-metrics,context=streaming,server= <topic.prefix>
debezium.mongodb:type=connector-metrics,context=streaming,server= <topic.prefix> ,database=salesdb-streaming,table=inventory
Command failed with error 286 (ChangeStreamHistoryLost): 'PlanExecutor error during aggregation :: caused by :: Resume of change stream was not possible, as the resume point may no longer be in the oplog
{ "schema": { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "databaseName" } ], "optional": false, "name": "io.debezium.connector.mysql.SchemaChangeKey", "version": 1 }, "payload": { "databaseName": "inventory" } }
{ "schema": { }, "payload": { "source": { 1 "version": "2.7.3.Final", "connector": "mysql", "name": "mysql", "ts_ms": 1651535750218, 2 "ts_us": 1651535750218000, 3 "ts_ns": 1651535750218000000, 4 "snapshot": "false", "db": "inventory", "sequence": null, "table": "customers", "server_id": 223344, "gtid": null, "file": "mysql-bin.000003", "pos": 570, "row": 0, "thread": null, "query": null }, "databaseName": "inventory", 5 "schemaName": null, "ddl": "ALTER TABLE customers ADD middle_name varchar(255) AFTER first_name", 6 "tableChanges": [ 7 { "type": "ALTER", 8 "id": "\"inventory\".\"customers\"", 9 "table": { 10 "defaultCharsetName": "utf8mb4", "primaryKeyColumnNames": [ 11 "id" ], "columns": [ 12 { "name": "id", "jdbcType": 4, "nativeType": null, "typeName": "INT", "typeExpression": "INT", "charsetName": null, "length": null, "scale": null, "position": 1, "optional": false, "autoIncremented": true, "generated": true }, { "name": "first_name", "jdbcType": 12, "nativeType": null, "typeName": "VARCHAR", "typeExpression": "VARCHAR", "charsetName": "utf8mb4", "length": 255, "scale": null, "position": 2, "optional": false, "autoIncremented": false, "generated": false }, { "name": "middle_name", "jdbcType": 12, "nativeType": null, "typeName": "VARCHAR", "typeExpression": "VARCHAR", "charsetName": "utf8mb4", "length": 255, "scale": null, "position": 3, "optional": true, "autoIncremented": false, "generated": false }, { "name": "last_name", "jdbcType": 12, "nativeType": null, "typeName": "VARCHAR", "typeExpression": "VARCHAR", "charsetName": "utf8mb4", "length": 255, "scale": null, "position": 4, "optional": false, "autoIncremented": false, "generated": false }, { "name": "email", "jdbcType": 12, "nativeType": null, "typeName": "VARCHAR", "typeExpression": "VARCHAR", "charsetName": "utf8mb4", "length": 255, "scale": null, "position": 5, "optional": false, "autoIncremented": false, "generated": false } ], "attributes": [ 13 { "customAttribute": "attributeValue" } ] } } ] } }
INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}');
INSERT INTO db1.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'execute-snapshot', 3 '{"data-collections": ["db1.table1", "db1.table2"], 4 "type":"incremental", 5 "additional-conditions":[{"data-collection": "db1.table1" ,"filter":"color=\'blue\'"}]}'); 6
SELECT * FROM <tableName> .
SELECT * FROM <data-collection> WHERE <filter> .
INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}');
INSERT INTO db1.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["db1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "db1.products", "filter": "color=blue"}]}');
INSERT INTO db1.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["db1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "db1.products", "filter": "color=blue AND quantity>10"}]}');
{ "before":null, "after": { "pk":"1", "value":"New data" }, "source": { "snapshot":"incremental" 1 }, "op":"r", 2 "ts_ms":"1620393591654", "ts_us":"1620393591654547", "ts_ns":"1620393591654547920", "transaction":null }
Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["{collection-container}.table1", "{collection-container}.table2"], "type": "INCREMENTAL"}}`
Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["db1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "db1.products" ,"filter":"color='blue'"}]}}`
Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["db1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "db1.products" ,"filter":"color='blue' AND brand='MyBrand'"}]}}`
INSERT INTO <signalTable> (id, type, data) values ( '<id>' , 'stop-snapshot', '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":"incremental"}');
INSERT INTO db1.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'stop-snapshot', 3 '{"data-collections": ["db1.table1", "db1.table2"], 4 "type":"incremental"}'); 5
Key = `test_connector` Value = `{"type":"stop-snapshot","data": {"data-collections": ["db1.table1", "db1.table2"], "type": "INCREMENTAL"}}`
{"type": "blocking", "data-collections": ["schema1.table1", "schema1.table2"], "additional-conditions": [{"data-collection": "schema1.table1", "filter": "SELECT * FROM [schema1].[table1] WHERE column1 = 0 ORDER BY column2 DESC"}, {"data-collection": "schema1.table2", "filter": "SELECT * FROM [schema1].[table2] WHERE column2 > 0"}]}
fulfillment.inventory.orders fulfillment.inventory.customers fulfillment.inventory.products
{ "status": "BEGIN", "id": "0e4d5dcd-a33b-11ea-80f1-02010a22a99e:10", "ts_ms": 1486500577125, "event_count": null, "data_collections": null } { "status": "END", "id": "0e4d5dcd-a33b-11ea-80f1-02010a22a99e:10", "ts_ms": 1486500577691, "event_count": 2, "data_collections": [ { "data_collection": "s1.a", "event_count": 1 }, { "data_collection": "s2.a", "event_count": 1 } ] }
{ "before": null, "after": { "pk": "2", "aa": "1" }, "source": { }, "op": "c", "ts_ms": "1580390884335", "ts_us": "1580390884335472", "ts_ns": "1580390884335472987", "transaction": { "id": "0e4d5dcd-a33b-11ea-80f1-02010a22a99e:10", "total_order": "1", "data_collection_order": "1" } }
{ "schema": { 1 }, "payload": { 2 }, "schema": { 3 }, "payload": { 4 }, }
CREATE TABLE customers ( id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY, first_name VARCHAR(255) NOT NULL, last_name VARCHAR(255) NOT NULL, email VARCHAR(255) NOT NULL UNIQUE KEY ) AUTO_INCREMENT=1001;
{ "schema": { 1 "type": "struct", "name": "mysql-server-1.inventory.customers.Key", 2 "optional": false, 3 "fields": [ 4 { "field": "id", "type": "int32", "optional": false } ] }, "payload": { 5 "id": 1001 } }
CREATE TABLE customers ( id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY, first_name VARCHAR(255) NOT NULL, last_name VARCHAR(255) NOT NULL, email VARCHAR(255) NOT NULL UNIQUE KEY ) AUTO_INCREMENT=1001;
{ "schema": { 1 "type": "struct", "fields": [ { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "id" }, { "type": "string", "optional": false, "field": "first_name" }, { "type": "string", "optional": false, "field": "last_name" }, { "type": "string", "optional": false, "field": "email" } ], "optional": true, "name": "mysql-server-1.inventory.customers.Value", 2 "field": "before" }, { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "id" }, { "type": "string", "optional": false, "field": "first_name" }, { "type": "string", "optional": false, "field": "last_name" }, { "type": "string", "optional": false, "field": "email" } ], "optional": true, "name": "mysql-server-1.inventory.customers.Value", "field": "after" }, { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "version" }, { "type": "string", "optional": false, "field": "connector" }, { "type": "string", "optional": false, "field": "name" }, { "type": "int64", "optional": false, "field": "ts_ms" }, { "type": "int64", "optional": false, "field": "ts_us" }, { "type": "int64", "optional": false, "field": "ts_ns" }, { "type": "boolean", "optional": true, "default": false, "field": "snapshot" }, { "type": "string", "optional": false, "field": "db" }, { "type": "string", "optional": true, "field": "table" }, { "type": "int64", "optional": false, "field": "server_id" }, { "type": "string", "optional": true, "field": "gtid" }, { "type": "string", "optional": false, "field": "file" }, { "type": "int64", "optional": false, "field": "pos" }, { "type": "int32", "optional": false, "field": "row" }, { "type": "int64", "optional": true, "field": "thread" }, { "type": "string", "optional": true, "field": "query" } ], "optional": false, "name": "io.debezium.connector.mysql.Source", 3 "field": "source" }, { "type": "string", "optional": false, "field": "op" }, { "type": "int64", "optional": true, "field": "ts_ms" }, { "type": "int64", "optional": true, "field": "ts_us" }, { "type": "int64", "optional": true, "field": "ts_ns" } ], "optional": false, "name": "mysql-server-1.inventory.customers.Envelope" 4 }, "payload": { 5 "op": "c", 6 "ts_ms": 1465491411815, 7 "ts_us": 1465491411815437, 8 "ts_ns": 1465491411815437158, 9 "before": null, 10 "after": { 11 "id": 1004, "first_name": "Anne", "last_name": "Kretchmar", "email": "annek@noanswer.org" }, "source": { 12 "version": "2.7.3.Final", "connector": "mysql", "name": "mysql-server-1", "ts_ms": 0, "ts_us": 0, "ts_ns": 0, "snapshot": false, "db": "inventory", "table": "customers", "server_id": 0, "gtid": null, "file": "mysql-bin.000003", "pos": 154, "row": 0, "thread": 7, "query": "INSERT INTO customers (first_name, last_name, email) VALUES ('Anne', 'Kretchmar', 'annek@noanswer.org')" } } }
{ "schema": { ... }, "payload": { "before": { 1 "id": 1004, "first_name": "Anne", "last_name": "Kretchmar", "email": "annek@noanswer.org" }, "after": { 2 "id": 1004, "first_name": "Anne Marie", "last_name": "Kretchmar", "email": "annek@noanswer.org" }, "source": { 3 "version": "2.7.3.Final", "name": "mysql-server-1", "connector": "mysql", "name": "mysql-server-1", "ts_ms": 1465581029100, "ts_ms": 1465581029100000, "ts_ms": 1465581029100000000, "snapshot": false, "db": "inventory", "table": "customers", "server_id": 223344, "gtid": null, "file": "mysql-bin.000003", "pos": 484, "row": 0, "thread": 7, "query": "UPDATE customers SET first_name='Anne Marie' WHERE id=1004" }, "op": "u", 4 "ts_ms": 1465581029523, 5 "ts_ms": 1465581029523758, 6 "ts_ms": 1465581029523758914 7 } }
{ "schema": { ... }, "payload": { "before": { 1 "id": 1004, "first_name": "Anne Marie", "last_name": "Kretchmar", "email": "annek@noanswer.org" }, "after": null, 2 "source": { 3 "version": "2.7.3.Final", "connector": "mysql", "name": "mysql-server-1", "ts_ms": 1465581902300, "ts_us": 1465581902300000, "ts_ns": 1465581902300000000, "snapshot": false, "db": "inventory", "table": "customers", "server_id": 223344, "gtid": null, "file": "mysql-bin.000003", "pos": 805, "row": 0, "thread": 7, "query": "DELETE FROM customers WHERE id=1004" }, "op": "d", 4 "ts_ms": 1465581902461, 5 "ts_us": 1465581902461842, 6 "ts_ns": 1465581902461842579 7 } }
{ "schema": { ... }, "payload": { "source": { 1 "version": "2.7.3.Final", "name": "mysql-server-1", "connector": "mysql", "name": "mysql-server-1", "ts_ms": 1465581029100, "ts_us": 1465581029100000, "ts_ns": 1465581029100000000, "snapshot": false, "db": "inventory", "table": "customers", "server_id": 223344, "gtid": null, "file": "mysql-bin.000003", "pos": 484, "row": 0, "thread": 7, "query": "UPDATE customers SET first_name='Anne Marie' WHERE id=1004" }, "op": "t", 2 "ts_ms": 1465581029523, 3 "ts_us": 1465581029523468, 4 "ts_ns": 1465581029523468471 5 } }
converters=boolean boolean.type=io.debezium.connector.binlog.converters.TinyIntOneToBooleanConverter boolean.selector=db1.table1.*, db1.table2.column1
converters=boolean boolean.type=io.debezium.connector.binlog.converters.TinyIntOneToBooleanConverter boolean.length.checker=false boolean.selector=db1.table1.*, db1.table2.column1
converters=tinyint-one-to-boolean tinyint-one-to-boolean.type=io.debezium.connector.binlog.converters.TinyIntOneToBooleanConverter tinyint-one-to-boolean.selector=.*.MY_TABLE.DATA tinyint-one-to-boolean.length.checker=false
converters=jdbc-sink jdbc-sink.type=io.debezium.connector.binlog.converters.JdbcSinkDataTypesConverter jdbc-sink.selector.boolean=.*.MY_TABLE.BOOL_COL jdbc-sink.selector.real=.*.MY_TABLE.REAL_COL jdbc-sink.selector.string=.*.MY_TABLE.STRING_COL jdbc-sink.treat.real.as.double=true
mysql> CREATE USER 'user'@'localhost' IDENTIFIED BY 'password';
mysql> GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'user' IDENTIFIED BY 'password';
mysql> FLUSH PRIVILEGES;
server-id = 223344 # Querying variable is called server_id, e.g. SELECT variable_value FROM information_schema.global_variables WHERE variable_name='server_id'; log_bin = mysql-bin binlog_format = ROW binlog_row_image = FULL binlog_expire_logs_seconds = 864000
mysql> gtid_mode=ON
mysql> enforce_gtid_consistency=ON
mysql> show global variables like '%GTID%';
+--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | enforce_gtid_consistency | ON | | gtid_mode | ON | +--------------------------+-------+
mysql> interactive_timeout=<duration-in-seconds>
mysql> wait_timeout=<duration-in-seconds>
mysql> binlog_rows_query_log_events=ON
mysql> show global variables where variable_name = 'binlog_row_value_options';
+--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | binlog_row_value_options | | +--------------------------+-------+
mysql> set @@global.binlog_row_value_options="" ;
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: debezium-kafka-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: version: 3.6.0 build: 2 output: 3 type: imagestream 4 image: debezium-streams-connect:latest plugins: 5 - name: debezium-connector-mysql artifacts: - type: zip 6 url: https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-mysql/2.7.3.Final-redhat-00001/debezium-connector-mysql-2.7.3.Final-redhat-00001-plugin.zip 7 - type: zip url: https://maven.repository.redhat.com/ga/io/apicurio/apicurio-registry-distro-connect-converter/2.4.4.Final-redhat- <build-number> /apicurio-registry-distro-connect-converter-2.4.4.Final-redhat- <build-number> .zip 8 - type: zip url: https://maven.repository.redhat.com/ga/io/debezium/debezium-scripting/2.7.3.Final-redhat-00001/debezium-scripting-2.7.3.Final-redhat-00001.zip 9 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy/3.0.11/groovy-3.0.11.jar 10 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-jsr223/3.0.11/groovy-jsr223-3.0.11.jar - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-json3.0.11/groovy-json-3.0.11.jar bootstrapServers: debezium-kafka-cluster-kafka-bootstrap:9093
create -f dbz-connect.yaml
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: labels: strimzi.io/cluster: debezium-kafka-connect-cluster name: inventory-connector-mysql 1 spec: class: io.debezium.connector.mysql.MySqlConnector 2 tasksMax: 1 3 config: 4 schema.history.internal.kafka.bootstrap.servers: debezium-kafka-cluster-kafka-bootstrap.debezium.svc.cluster.local:9092 schema.history.internal.kafka.topic: schema-changes.inventory database.hostname: mysql.debezium-mysql.svc.cluster.local 5 database.port: 3306 6 database.user: debezium 7 database.password: dbz 8 database.server.id: 184054 9 topic.prefix: inventory-connector-mysql 10 table.include.list: inventory.* 11
create -n <namespace> -f <kafkaConnector> .yaml
create -n debezium -f mysql-inventory-connector.yaml
cat <<EOF >debezium-container-for-mysql.yaml 1 FROM registry.redhat.io/amq-streams-kafka-35-rhel8:2.5.0 USER root:root RUN mkdir -p /opt/kafka/plugins/debezium 2 RUN cd /opt/kafka/plugins/debezium/ && curl -O https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-mysql/2.7.3.Final-redhat-00001/debezium-connector-mysql-2.7.3.Final-redhat-00001-plugin.zip && unzip debezium-connector-mysql-2.7.3.Final-redhat-00001-plugin.zip && rm debezium-connector-mysql-2.7.3.Final-redhat-00001-plugin.zip RUN cd /opt/kafka/plugins/debezium/ USER 1001 EOF
build -t debezium-container-for-mysql:latest .
docker build -t debezium-container-for-mysql:latest .
push <myregistry.io> /debezium-container-for-mysql:latest
docker push <myregistry.io> /debezium-container-for-mysql:latest
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: # image: debezium-container-for-mysql 2
create -f dbz-connect.yaml
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: inventory-connector-mysql 1 labels: strimzi.io/cluster: my-connect-cluster spec: class: io.debezium.connector.mysql.MariaDbConnector tasksMax: 1 2 config: 3 database.hostname: mysql 4 database.port: 3306 database.user: debezium database.password: dbz database.server.id: 184054 5 topic.prefix: inventory-connector-mysql 6 table.include.list: inventory 7 schema.history.internal.kafka.bootstrap.servers: my-cluster-kafka-bootstrap:9092 8 schema.history.internal.kafka.topic: schema-changes.inventory 9
apply -f inventory-connector.yaml
describe KafkaConnector <connector-name> -n <project>
describe KafkaConnector inventory-connector-mysql -n debezium
Name: inventory-connector-mysql Namespace: debezium Labels: strimzi.io/cluster=debezium-kafka-connect-cluster Annotations: <none> API Version: kafka.strimzi.io/v1beta2 Kind: KafkaConnector Status: Conditions: Last Transition Time: 2021-12-08T17:41:34.897153Z Status: True Type: Ready Connector Status: Connector: State: RUNNING worker_id: 10.131.1.124:8083 Name: inventory-connector-mysql Tasks: Id: 0 State: RUNNING worker_id: 10.131.1.124:8083 Type: source Observed Generation: 1 Tasks Max: 1 Topics: inventory-connector-mysql.inventory inventory-connector-mysql.inventory.addresses inventory-connector-mysql.inventory.customers inventory-connector-mysql.inventory.geom inventory-connector-mysql.inventory.orders inventory-connector-mysql.inventory.products inventory-connector-mysql.inventory.products_on_hand Events: <none>
get kafkatopics
NAME CLUSTER PARTITIONS REPLICATION FACTOR READY connect-cluster-configs debezium-kafka-cluster 1 1 True connect-cluster-offsets debezium-kafka-cluster 25 1 True connect-cluster-status debezium-kafka-cluster 5 1 True consumer-offsets---84e7a678d08f4bd226872e5cdd4eb527fadc1c6a debezium-kafka-cluster 50 1 True inventory-connector-mysql--a96f69b23d6118ff415f772679da623fbbb99421 debezium-kafka-cluster 1 1 True inventory-connector-mysql.inventory.addresses---1b6beaf7b2eb57d177d92be90ca2b210c9a56480 debezium-kafka-cluster 1 1 True inventory-connector-mysql.inventory.customers---9931e04ec92ecc0924f4406af3fdace7545c483b debezium-kafka-cluster 1 1 True inventory-connector-mysql.inventory.geom---9f7e136091f071bf49ca59bf99e86c713ee58dd5 debezium-kafka-cluster 1 1 True inventory-connector-mysql.inventory.orders---ac5e98ac6a5d91e04d8ec0dc9078a1ece439081d debezium-kafka-cluster 1 1 True inventory-connector-mysql.inventory.products---df0746db116844cee2297fab611c21b56f82dcef debezium-kafka-cluster 1 1 True inventory-connector-mysql.inventory.products_on_hand---8649e0f17ffcc9212e266e31a7aeea4585e5c6b5 debezium-kafka-cluster 1 1 True schema-changes.inventory debezium-kafka-cluster 1 1 True strimzi-store-topic---effb8e3e057afce1ecf67c3f5d8e4e3ff177fc55 debezium-kafka-cluster 1 1 True strimzi-topic-operator-kstreams-topic-store-changelog---b75e702040b99be8a9263134de3507fc0cc4017b debezium-kafka-cluster 1 1 True
exec -n <project> -it <kafka-cluster> -- /opt/kafka/bin/kafka-console-consumer.sh > --bootstrap-server localhost:9092 > --from-beginning > --property print.key=true > --topic= <topic-name >
exec -n debezium -it debezium-kafka-cluster-kafka-0 -- /opt/kafka/bin/kafka-console-consumer.sh > --bootstrap-server localhost:9092 > --from-beginning > --property print.key=true > --topic=inventory-connector-mysql.inventory.products_on_hand
{"schema":{"type":"struct","fields":[{"type":"int32","optional":false,"field":"product_id"}],"optional":false,"name":"inventory-connector-mysql.inventory.products_on_hand.Key"},"payload":{"product_id":101}} {"schema":{"type":"struct","fields":[{"type":"struct","fields":[{"type":"int32","optional":false,"field":"product_id"},{"type":"int32","optional":false,"field":"quantity"}],"optional":true,"name":"inventory-connector-mysql.inventory.products_on_hand.Value","field":"before"},{"type":"struct","fields":[{"type":"int32","optional":false,"field":"product_id"},{"type":"int32","optional":false,"field":"quantity"}],"optional":true,"name":"inventory-connector-mysql.inventory.products_on_hand.Value","field":"after"},{"type":"struct","fields":[{"type":"string","optional":false,"field":"version"},{"type":"string","optional":false,"field":"connector"},{"type":"string","optional":false,"field":"name"},{"type":"int64","optional":false,"field":"ts_ms"},{"type":"int64","optional":false,"field":"ts_us"},{"type":"int64","optional":false,"field":"ts_ns"},{"type":"string","optional":true,"name":"io.debezium.data.Enum","version":1,"parameters":{"allowed":"true,last,false"},"default":"false","field":"snapshot"},{"type":"string","optional":false,"field":"db"},{"type":"string","optional":true,"field":"sequence"},{"type":"string","optional":true,"field":"table"},{"type":"int64","optional":false,"field":"server_id"},{"type":"string","optional":true,"field":"gtid"},{"type":"string","optional":false,"field":"file"},{"type":"int64","optional":false,"field":"pos"},{"type":"int32","optional":false,"field":"row"},{"type":"int64","optional":true,"field":"thread"},{"type":"string","optional":true,"field":"query"}],"optional":false,"name":"io.debezium.connector.mysql.Source","field":"source"},{"type":"string","optional":false,"field":"op"},{"type":"int64","optional":true,"field":"ts_ms"},{"type":"int64","optional":true,"field":"ts_us"},{"type":"int64","optional":true,"field":"ts_ns"},{"type":"struct","fields":[{"type":"string","optional":false,"field":"id"},{"type":"int64","optional":false,"field":"total_order"},{"type":"int64","optional":false,"field":"data_collection_order"}],"optional":true,"field":"transaction"}],"optional":false,"name": "inventory-connector-mysql.inventory.products_on_hand.Envelope" }, "payload" :{ "before" : null , "after" :{ "product_id":101,"quantity":3 },"source":{"version":"2.7.3.Final-redhat-00001","connector":"mysql","name":"inventory-connector-mysql","ts_ms":1638985247805,"ts_us":1638985247805000000,"ts_ns":1638985247805000000,"snapshot":"true","db":"inventory","sequence":null,"table":"products_on_hand","server_id":0,"gtid":null,"file":"mysql-bin.000003","pos":156,"row":0,"thread":null,"query":null}, "op" : "r" ,"ts_ms":1638985247805,"ts_us":1638985247805102,"ts_ns":1638985247805102588,"transaction":null}}
column.mask.hash.SHA-256.with.salt.CzQMA0cB5K = inventory.orders.customerName, inventory.shipment.customerName
`_` is an escape sequence, similar to a backslash in Java
boolean.type: io.debezium.connector.binlog.converters.TinyIntOneToBooleanConverter
boolean.selector=db1.table1.*, db1.table2.column1
"snapshot.select.statement.overrides": "customer.orders", "snapshot.select.statement.overrides.customer.orders": "SELECT * FROM [customers].[orders] WHERE delete_flag = 0 ORDER BY id DESC"
schema.history.internal.producer.security.protocol=SSL schema.history.internal.producer.ssl.keystore.location=/var/private/ssl/kafka.server.keystore.jks schema.history.internal.producer.ssl.keystore.password=test1234 schema.history.internal.producer.ssl.truststore.location=/var/private/ssl/kafka.server.truststore.jks schema.history.internal.producer.ssl.truststore.password=test1234 schema.history.internal.producer.ssl.key.password=test1234 schema.history.internal.consumer.security.protocol=SSL schema.history.internal.consumer.ssl.keystore.location=/var/private/ssl/kafka.server.keystore.jks schema.history.internal.consumer.ssl.keystore.password=test1234 schema.history.internal.consumer.ssl.truststore.location=/var/private/ssl/kafka.server.truststore.jks schema.history.internal.consumer.ssl.truststore.password=test1234 schema.history.internal.consumer.ssl.key.password=test1234
debezium.mysql:type=connector-metrics,context=streaming,server= <topic.prefix>
debezium.mysql:type=connector-metrics,context=streaming,server= <topic.prefix> ,database=salesdb-streaming,table=inventory
INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}');
INSERT INTO db1.myschema.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'execute-snapshot', 3 '{"data-collections": ["db1.schema1.table1", "db1.schema1.table2"], 4 "type":"incremental", 5 "additional-conditions":[{"data-collection": "db1.schema1.table1" ,"filter":"color=\'blue\'"}]}'); 6
SELECT * FROM <tableName> .
SELECT * FROM <data-collection> WHERE <filter> .
INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}');
INSERT INTO db1.myschema.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["db1.schema1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "db1.schema1.products", "filter": "color=blue"}]}');
INSERT INTO db1.myschema.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["db1.schema1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "db1.schema1.products", "filter": "color=blue AND quantity>10"}]}');
{ "before":null, "after": { "pk":"1", "value":"New data" }, "source": { "snapshot":"incremental" 1 }, "op":"r", 2 "ts_ms":"1620393591654", "ts_us":"1620393591654547", "ts_ns":"1620393591654547920", "transaction":null }
Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["{collection-container}.table1", "{collection-container}.table2"], "type": "INCREMENTAL"}}`
Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["db1.schema1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "db1.schema1.products" ,"filter":"color='blue'"}]}}`
Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["db1.schema1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "db1.schema1.products" ,"filter":"color='blue' AND brand='MyBrand'"}]}}`
INSERT INTO <signalTable> (id, type, data) values ( '<id>' , 'stop-snapshot', '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":"incremental"}');
INSERT INTO db1.myschema.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'stop-snapshot', 3 '{"data-collections": ["db1.schema1.table1", "db1.schema1.table2"], 4 "type":"incremental"}'); 5
Key = `test_connector` Value = `{"type":"stop-snapshot","data": {"data-collections": ["db1.schema1.table1", "db1.schema1.table2"], "type": "INCREMENTAL"}}`
{"type": "blocking", "data-collections": ["schema1.table1", "schema1.table2"], "additional-conditions": [{"data-collection": "schema1.table1", "filter": "SELECT * FROM [schema1].[table1] WHERE column1 = 0 ORDER BY column2 DESC"}, {"data-collection": "schema1.table2", "filter": "SELECT * FROM [schema1].[table2] WHERE column2 > 0"}]}
fulfillment.inventory.orders fulfillment.inventory.customers fulfillment.inventory.products
{ "schema": { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "databaseName" } ], "optional": false, "name": "io.debezium.connector.oracle.SchemaChangeKey", "version": 1 }, "payload": { "databaseName": "inventory" } }
{ "schema": { }, "payload": { "source": { "version": "2.7.3.Final", "connector": "oracle", "name": "server1", "ts_ms": 1588252618953, "ts_us": 1588252618953000, "ts_ns": 1588252618953000000, "snapshot": "true", "db": "ORCLPDB1", "schema": "DEBEZIUM", "table": "CUSTOMERS", "txId" : null, "scn" : "1513734", "commit_scn": "1513754", "lcr_position" : null, "rs_id": "001234.00012345.0124", "ssn": 1, "redo_thread": 1, "user_name": "user", "row_id": "AAASgjAAMAAAACnAAA" }, "ts_ms": 1588252618953, 1 "ts_us": 1588252618953987, 2 "ts_ns": 1588252618953987512, 3 "databaseName": "ORCLPDB1", 4 "schemaName": "DEBEZIUM", // "ddl": "CREATE TABLE \"DEBEZIUM\".\"CUSTOMERS\" \n ( \"ID\" NUMBER(9,0) NOT NULL ENABLE, \n \"FIRST_NAME\" VARCHAR2(255), \n \"LAST_NAME" VARCHAR2(255), \n \"EMAIL\" VARCHAR2(255), \n PRIMARY KEY (\"ID\") ENABLE, \n SUPPLEMENTAL LOG DATA (ALL) COLUMNS\n ) SEGMENT CREATION IMMEDIATE \n PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 \n NOCOMPRESS LOGGING\n STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645\n PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1\n BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)\n TABLESPACE \"USERS\" ", 5 "tableChanges": [ 6 { "type": "CREATE", 7 "id": "\"ORCLPDB1\".\"DEBEZIUM\".\"CUSTOMERS\"", 8 "table": { 9 "defaultCharsetName": null, "primaryKeyColumnNames": [ 10 "ID" ], "columns": [ 11 { "name": "ID", "jdbcType": 2, "nativeType": null, "typeName": "NUMBER", "typeExpression": "NUMBER", "charsetName": null, "length": 9, "scale": 0, "position": 1, "optional": false, "autoIncremented": false, "generated": false }, { "name": "FIRST_NAME", "jdbcType": 12, "nativeType": null, "typeName": "VARCHAR2", "typeExpression": "VARCHAR2", "charsetName": null, "length": 255, "scale": null, "position": 2, "optional": false, "autoIncremented": false, "generated": false }, { "name": "LAST_NAME", "jdbcType": 12, "nativeType": null, "typeName": "VARCHAR2", "typeExpression": "VARCHAR2", "charsetName": null, "length": 255, "scale": null, "position": 3, "optional": false, "autoIncremented": false, "generated": false }, { "name": "EMAIL", "jdbcType": 12, "nativeType": null, "typeName": "VARCHAR2", "typeExpression": "VARCHAR2", "charsetName": null, "length": 255, "scale": null, "position": 4, "optional": false, "autoIncremented": false, "generated": false } ], "attributes": [ 12 { "customAttribute": "attributeValue" } ] } } ] } }
{ "schema": { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "databaseName" } ], "optional": false, "name": "io.debezium.connector.oracle.SchemaChangeKey", "version": 1 }, "payload": { "databaseName": "ORCLPDB1" } }
{ "status": "BEGIN", "id": "5.6.641", "ts_ms": 1486500577125, "event_count": null, "data_collections": null } { "status": "END", "id": "5.6.641", "ts_ms": 1486500577691, "event_count": 2, "data_collections": [ { "data_collection": "ORCLPDB1.DEBEZIUM.CUSTOMER", "event_count": 1 }, { "data_collection": "ORCLPDB1.DEBEZIUM.ORDER", "event_count": 1 } ] }
{ "before": null, "after": { "pk": "2", "aa": "1" }, "source": { }, "op": "c", "ts_ms": "1580390884335", "ts_us": "1580390884335741", "ts_ns": "1580390884335741963", "transaction": { "id": "5.6.641", "total_order": "1", "data_collection_order": "1" } }
CREATE TABLE customers ( id NUMBER(9) GENERATED BY DEFAULT ON NULL AS IDENTITY (START WITH 1001) NOT NULL PRIMARY KEY, first_name VARCHAR2(255) NOT NULL, last_name VARCHAR2(255) NOT NULL, email VARCHAR2(255) NOT NULL UNIQUE );
{ "schema": { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "ID" } ], "optional": false, "name": "server1.INVENTORY.CUSTOMERS.Key" }, "payload": { "ID": 1004 } }
{ "schema": { "type": "struct", "fields": [ { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "ID" }, { "type": "string", "optional": false, "field": "FIRST_NAME" }, { "type": "string", "optional": false, "field": "LAST_NAME" }, { "type": "string", "optional": false, "field": "EMAIL" } ], "optional": true, "name": "server1.DEBEZIUM.CUSTOMERS.Value", "field": "before" }, { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "ID" }, { "type": "string", "optional": false, "field": "FIRST_NAME" }, { "type": "string", "optional": false, "field": "LAST_NAME" }, { "type": "string", "optional": false, "field": "EMAIL" } ], "optional": true, "name": "server1.DEBEZIUM.CUSTOMERS.Value", "field": "after" }, { "type": "struct", "fields": [ { "type": "string", "optional": true, "field": "version" }, { "type": "string", "optional": false, "field": "name" }, { "type": "int64", "optional": true, "field": "ts_ms" }, { "type": "int64", "optional": true, "field": "ts_us" }, { "type": "int64", "optional": true, "field": "ts_ns" }, { "type": "string", "optional": true, "field": "txId" }, { "type": "string", "optional": true, "field": "scn" }, { "type": "string", "optional": true, "field": "commit_scn" }, { "type": "string", "optional": true, "field": "rs_id" }, { "type": "int64", "optional": true, "field": "ssn" }, { "type": "int32", "optional": true, "field": "redo_thread" }, { "type": "string", "optional": true, "field": "user_name" }, { "type": "boolean", "optional": true, "field": "snapshot" }, { "type": "string", "optional": true, "field": "row_id" } ], "optional": false, "name": "io.debezium.connector.oracle.Source", "field": "source" }, { "type": "string", "optional": false, "field": "op" }, { "type": "int64", "optional": true, "field": "ts_ms" }, { "type": "int64", "optional": true, "field": "ts_us" }, { "type": "int64", "optional": true, "field": "ts_ns" } ], "optional": false, "name": "server1.DEBEZIUM.CUSTOMERS.Envelope" }, "payload": { "before": null, "after": { "ID": 1004, "FIRST_NAME": "Anne", "LAST_NAME": "Kretchmar", "EMAIL": "annek@noanswer.org" }, "source": { "version": "2.7.3.Final", "name": "server1", "ts_ms": 1520085154000, "ts_us": 1520085154000000, "ts_ns": 1520085154000000000, "txId": "6.28.807", "scn": "2122185", "commit_scn": "2122185", "rs_id": "001234.00012345.0124", "ssn": 1, "redo_thread": 1, "user_name": "user", "snapshot": false, "row_id": "AAASgjAAMAAAACnAAA" }, "op": "c", "ts_ms": 1532592105975, "ts_us": 1532592105975741, "ts_ns": 1532592105975741582 } }
{ "schema": { ... }, "payload": { "before": { "ID": 1004, "FIRST_NAME": "Anne", "LAST_NAME": "Kretchmar", "EMAIL": "annek@noanswer.org" }, "after": { "ID": 1004, "FIRST_NAME": "Anne", "LAST_NAME": "Kretchmar", "EMAIL": "anne@example.com" }, "source": { "version": "2.7.3.Final", "name": "server1", "ts_ms": 1520085811000, "ts_us": 1520085811000000, "ts_ns": 1520085811000000000, "txId": "6.9.809", "scn": "2125544", "commit_scn": "2125544", "rs_id": "001234.00012345.0124", "ssn": 1, "redo_thread": 1, "user_name": "user", "snapshot": false, "row_id": "AAASgjAAMAAAACnAAA" }, "op": "u", "ts_ms": 1532592713485, "ts_us": 1532592713485152, "ts_ns": 1532592713485152954, } }
{ "schema": { ... }, "payload": { "before": { "ID": 1004, "FIRST_NAME": "Anne", "LAST_NAME": "Kretchmar", "EMAIL": "anne@example.com" }, "after": null, "source": { "version": "2.7.3.Final", "name": "server1", "ts_ms": 1520085153000, "ts_us": 1520085153000000, "ts_ns": 1520085153000000000, "txId": "6.28.807", "scn": "2122184", "commit_scn": "2122184", "rs_id": "001234.00012345.0124", "ssn": 1, "redo_thread": 1, "user_name": "user", "snapshot": false, "row_id": "AAASgjAAMAAAACnAAA" }, "op": "d", "ts_ms": 1532592105960, "ts_us": 1532592105960854, "ts_ns": 1532592105960854693 } }
{ "schema": { ... }, "payload": { "before": null, "after": null, "source": { 1 "version": "2.7.3.Final", "connector": "oracle", "name": "oracle_server", "ts_ms": 1638974535000, "ts_us": 1638974535000000, "ts_ns": 1638974535000000000, "snapshot": "false", "db": "ORCLPDB1", "sequence": null, "schema": "DEBEZIUM", "table": "TEST_TABLE", "txId": "02000a0037030000", "scn": "13234397", "commit_scn": "13271102", "lcr_position": null, "rs_id": "001234.00012345.0124", "ssn": 1, "redo_thread": 1, "user_name": "user" }, "op": "t", 2 "ts_ms": 1638974558961, 3 "ts_us": 1638974558961987, 4 "ts_ns": 1638974558961987251, 5 "transaction": null } }
converters=zero_scale zero_scale.type=io.debezium.connector.oracle.converters.NumberToZeroScaleConverter zero_scale.decimal.mode=precise
converters=boolean boolean.type=io.debezium.connector.oracle.converters.NumberOneToBooleanConverter boolean.selector=.*MYTABLE.FLAG,.*.IS_ARCHIVED
converters=number-to-boolean number-to-boolean.type=io.debezium.connector.oracle.converters.NumberOneToBooleanConverter number-to-boolean.selector=.*.MY_TABLE.DATA
converters=number-zero-scale number-zero-scale.type=io.debezium.connector.oracle.converters.NumberToZeroScaleConverter number-zero-scale.decimal.mode=precise
converters=raw-to-string raw-to-string.type=io.debezium.connector.oracle.converters.RawToStringConverter raw-to-string.selector=.*.MY_TABLE.DATA
ORACLE_SID=ORACLCDB dbz_oracle sqlplus /nolog CONNECT sys/top_secret AS SYSDBA alter system set db_recovery_file_dest_size = 10G; alter system set db_recovery_file_dest = '/opt/oracle/oradata/recovery_area' scope=spfile; shutdown immediate startup mount alter database archivelog; alter database open; -- Should now "Database log mode: Archive Mode" archive log list exit;
SQL> SELECT LOG_MODE FROM VUSDDATABASE; LOG_MODE ------------ ARCHIVELOG
exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24); exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD');
ALTER TABLE inventory.customers ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
log.mining.archive.destination.name: LOG_ARCHIVE_DEST_3
sqlplus sys/top_secret@//localhost:1521/ORCLCDB as sysdba CREATE TABLESPACE logminer_tbs DATAFILE '/opt/oracle/oradata/ORCLCDB/logminer_tbs.dbf' SIZE 25M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED; exit; sqlplus sys/top_secret@//localhost:1521/ORCLPDB1 as sysdba CREATE TABLESPACE logminer_tbs DATAFILE '/opt/oracle/oradata/ORCLCDB/ORCLPDB1/logminer_tbs.dbf' SIZE 25M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED; exit; sqlplus sys/top_secret@//localhost:1521/ORCLCDB as sysdba CREATE USER c##dbzuser IDENTIFIED BY dbz DEFAULT TABLESPACE logminer_tbs QUOTA UNLIMITED ON logminer_tbs CONTAINER=ALL; GRANT CREATE SESSION TO c##dbzuser CONTAINER=ALL; 1 GRANT SET CONTAINER TO c##dbzuser CONTAINER=ALL; 2 GRANT SELECT ON V_USDDATABASE to c##dbzuser CONTAINER=ALL; 3 GRANT FLASHBACK ANY TABLE TO c##dbzuser CONTAINER=ALL; 4 GRANT SELECT ANY TABLE TO c##dbzuser CONTAINER=ALL; 5 GRANT SELECT_CATALOG_ROLE TO c##dbzuser CONTAINER=ALL; 6 GRANT EXECUTE_CATALOG_ROLE TO c##dbzuser CONTAINER=ALL; 7 GRANT SELECT ANY TRANSACTION TO c##dbzuser CONTAINER=ALL; 8 GRANT LOGMINING TO c##dbzuser CONTAINER=ALL; 9 GRANT CREATE TABLE TO c##dbzuser CONTAINER=ALL; 10 GRANT LOCK ANY TABLE TO c##dbzuser CONTAINER=ALL; 11 GRANT CREATE SEQUENCE TO c##dbzuser CONTAINER=ALL; 12 GRANT EXECUTE ON DBMS_LOGMNR TO c##dbzuser CONTAINER=ALL; 13 GRANT EXECUTE ON DBMS_LOGMNR_D TO c##dbzuser CONTAINER=ALL; 14 GRANT SELECT ON V_USDLOG TO c##dbzuser CONTAINER=ALL; 15 GRANT SELECT ON V_USDLOG_HISTORY TO c##dbzuser CONTAINER=ALL; 16 GRANT SELECT ON V_USDLOGMNR_LOGS TO c##dbzuser CONTAINER=ALL; 17 GRANT SELECT ON V_USDLOGMNR_CONTENTS TO c##dbzuser CONTAINER=ALL; 18 GRANT SELECT ON V_USDLOGMNR_PARAMETERS TO c##dbzuser CONTAINER=ALL; 19 GRANT SELECT ON V_USDLOGFILE TO c##dbzuser CONTAINER=ALL; 20 GRANT SELECT ON V_USDARCHIVED_LOG TO c##dbzuser CONTAINER=ALL; 21 GRANT SELECT ON V_USDARCHIVE_DEST_STATUS TO c##dbzuser CONTAINER=ALL; 22 GRANT SELECT ON V_USDTRANSACTION TO c##dbzuser CONTAINER=ALL; 23 GRANT SELECT ON V_USDMYSTAT TO c##dbzuser CONTAINER=ALL; 24 GRANT SELECT ON V_USDSTATNAME TO c##dbzuser CONTAINER=ALL; 25 exit;
internal.log.mining.read.only=true
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: debezium-kafka-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: version: 3.6.0 build: 2 output: 3 type: imagestream 4 image: debezium-streams-connect:latest plugins: 5 - name: debezium-connector-oracle artifacts: - type: zip 6 url: https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-oracle/2.7.3.Final-redhat-00001/debezium-connector-oracle-2.7.3.Final-redhat-00001-plugin.zip 7 - type: zip url: https://maven.repository.redhat.com/ga/io/apicurio/apicurio-registry-distro-connect-converter/2.4.4.Final-redhat- <build-number> /apicurio-registry-distro-connect-converter-2.4.4.Final-redhat- <build-number> .zip 8 - type: zip url: https://maven.repository.redhat.com/ga/io/debezium/debezium-scripting/2.7.3.Final-redhat-00001/debezium-scripting-2.7.3.Final-redhat-00001.zip 9 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy/3.0.11/groovy-3.0.11.jar 10 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-jsr223/3.0.11/groovy-jsr223-3.0.11.jar - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-json3.0.11/groovy-json-3.0.11.jar - type: jar 11 url: https://repo1.maven.org/maven2/com/oracle/database/jdbc/ojdbc8/21.6.0.0/ojdbc8-21.6.0.0.jar bootstrapServers: debezium-kafka-cluster-kafka-bootstrap:9093
create -f dbz-connect.yaml
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: labels: strimzi.io/cluster: debezium-kafka-connect-cluster name: inventory-connector-oracle 1 spec: class: io.debezium.connector.oracle.OracleConnector 2 tasksMax: 1 3 config: 4 schema.history.internal.kafka.bootstrap.servers: debezium-kafka-cluster-kafka-bootstrap.debezium.svc.cluster.local:9092 schema.history.internal.kafka.topic: schema-changes.inventory database.hostname: oracle.debezium-oracle.svc.cluster.local 5 database.port: 1521 6 database.user: debezium 7 database.password: dbz 8 database.dbname: mydatabase 9 topic.prefix: inventory-connector-oracle 10 table.include.list: PUBLIC.INVENTORY 11
create -n <namespace> -f <kafkaConnector> .yaml
create -n debezium -f oracle-inventory-connector.yaml
cat <<EOF >debezium-container-for-oracle.yaml 1 FROM registry.redhat.io/amq-streams-kafka-35-rhel8:2.5.0 USER root:root RUN mkdir -p /opt/kafka/plugins/debezium 2 RUN cd /opt/kafka/plugins/debezium/ && curl -O https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-oracle/2.7.3.Final-redhat-00001/debezium-connector-oracle-2.7.3.Final-redhat-00001-plugin.zip && unzip debezium-connector-oracle-2.7.3.Final-redhat-00001-plugin.zip && rm debezium-connector-oracle-2.7.3.Final-redhat-00001-plugin.zip RUN cd /opt/kafka/plugins/debezium/ && curl -O https://repo1.maven.org/maven2/com/oracle/ojdbc/ojdbc8/21.1.0.0/ojdbc8-21.1.0.0.jar USER 1001 EOF
build -t debezium-container-for-oracle:latest .
docker build -t debezium-container-for-oracle:latest .
push <myregistry.io> /debezium-container-for-oracle:latest
docker push <myregistry.io> /debezium-container-for-oracle:latest
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: image: debezium-container-for-oracle 2
create -f dbz-connect.yaml
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: inventory-connector-oracle 1 labels: strimzi.io/cluster: my-connect-cluster annotations: strimzi.io/use-connector-resources: 'true' spec: class: io.debezium.connector.oracle.OracleConnector 2 config: database.hostname: <oracle_ip_address> 3 database.port: 1521 4 database.user: c##dbzuser 5 database.password: dbz 6 database.dbname: ORCLCDB 7 database.pdb.name : ORCLPDB1, 8 topic.prefix: inventory-connector-oracle 9 schema.history.internal.kafka.bootstrap.servers: kafka:9092 10 schema.history.internal.kafka.topic: schema-changes.inventory 11
apply -f inventory-connector.yaml
describe KafkaConnector <connector-name> -n <project>
describe KafkaConnector inventory-connector-oracle -n debezium
Name: inventory-connector-oracle Namespace: debezium Labels: strimzi.io/cluster=debezium-kafka-connect-cluster Annotations: <none> API Version: kafka.strimzi.io/v1beta2 Kind: KafkaConnector Status: Conditions: Last Transition Time: 2021-12-08T17:41:34.897153Z Status: True Type: Ready Connector Status: Connector: State: RUNNING worker_id: 10.131.1.124:8083 Name: inventory-connector-oracle Tasks: Id: 0 State: RUNNING worker_id: 10.131.1.124:8083 Type: source Observed Generation: 1 Tasks Max: 1 Topics: inventory-connector-oracle.inventory inventory-connector-oracle.inventory.addresses inventory-connector-oracle.inventory.customers inventory-connector-oracle.inventory.geom inventory-connector-oracle.inventory.orders inventory-connector-oracle.inventory.products inventory-connector-oracle.inventory.products_on_hand Events: <none>
get kafkatopics
NAME CLUSTER PARTITIONS REPLICATION FACTOR READY connect-cluster-configs debezium-kafka-cluster 1 1 True connect-cluster-offsets debezium-kafka-cluster 25 1 True connect-cluster-status debezium-kafka-cluster 5 1 True consumer-offsets---84e7a678d08f4bd226872e5cdd4eb527fadc1c6a debezium-kafka-cluster 50 1 True inventory-connector-oracle--a96f69b23d6118ff415f772679da623fbbb99421 debezium-kafka-cluster 1 1 True inventory-connector-oracle.inventory.addresses---1b6beaf7b2eb57d177d92be90ca2b210c9a56480 debezium-kafka-cluster 1 1 True inventory-connector-oracle.inventory.customers---9931e04ec92ecc0924f4406af3fdace7545c483b debezium-kafka-cluster 1 1 True inventory-connector-oracle.inventory.geom---9f7e136091f071bf49ca59bf99e86c713ee58dd5 debezium-kafka-cluster 1 1 True inventory-connector-oracle.inventory.orders---ac5e98ac6a5d91e04d8ec0dc9078a1ece439081d debezium-kafka-cluster 1 1 True inventory-connector-oracle.inventory.products---df0746db116844cee2297fab611c21b56f82dcef debezium-kafka-cluster 1 1 True inventory-connector-oracle.inventory.products_on_hand---8649e0f17ffcc9212e266e31a7aeea4585e5c6b5 debezium-kafka-cluster 1 1 True schema-changes.inventory debezium-kafka-cluster 1 1 True strimzi-store-topic---effb8e3e057afce1ecf67c3f5d8e4e3ff177fc55 debezium-kafka-cluster 1 1 True strimzi-topic-operator-kstreams-topic-store-changelog---b75e702040b99be8a9263134de3507fc0cc4017b debezium-kafka-cluster 1 1 True
exec -n <project> -it <kafka-cluster> -- /opt/kafka/bin/kafka-console-consumer.sh > --bootstrap-server localhost:9092 > --from-beginning > --property print.key=true > --topic= <topic-name >
exec -n debezium -it debezium-kafka-cluster-kafka-0 -- /opt/kafka/bin/kafka-console-consumer.sh > --bootstrap-server localhost:9092 > --from-beginning > --property print.key=true > --topic=inventory-connector-oracle.inventory.products_on_hand
{"schema":{"type":"struct","fields":[{"type":"int32","optional":false,"field":"product_id"}],"optional":false,"name":"inventory-connector-oracle.inventory.products_on_hand.Key"},"payload":{"product_id":101}} {"schema":{"type":"struct","fields":[{"type":"struct","fields":[{"type":"int32","optional":false,"field":"product_id"},{"type":"int32","optional":false,"field":"quantity"}],"optional":true,"name":"inventory-connector-oracle.inventory.products_on_hand.Value","field":"before"},{"type":"struct","fields":[{"type":"int32","optional":false,"field":"product_id"},{"type":"int32","optional":false,"field":"quantity"}],"optional":true,"name":"inventory-connector-oracle.inventory.products_on_hand.Value","field":"after"},{"type":"struct","fields":[{"type":"string","optional":false,"field":"version"},{"type":"string","optional":false,"field":"connector"},{"type":"string","optional":false,"field":"name"},{"type":"int64","optional":false,"field":"ts_ms"},{"type":"int64","optional":false,"field":"ts_us"},{"type":"int64","optional":false,"field":"ts_ns"},{"type":"string","optional":true,"name":"io.debezium.data.Enum","version":1,"parameters":{"allowed":"true,last,false"},"default":"false","field":"snapshot"},{"type":"string","optional":false,"field":"db"},{"type":"string","optional":true,"field":"sequence"},{"type":"string","optional":true,"field":"table"},{"type":"int64","optional":false,"field":"server_id"},{"type":"string","optional":true,"field":"gtid"},{"type":"string","optional":false,"field":"file"},{"type":"int64","optional":false,"field":"pos"},{"type":"int32","optional":false,"field":"row"},{"type":"int64","optional":true,"field":"thread"},{"type":"string","optional":true,"field":"query"}],"optional":false,"name":"io.debezium.connector.oracle.Source","field":"source"},{"type":"string","optional":false,"field":"op"},{"type":"int64","optional":true,"field":"ts_ms"},{"type":"int64","optional":true,"field":"ts_us"},{"type":"int64","optional":true,"field":"ts_ns"},{"type":"struct","fields":[{"type":"string","optional":false,"field":"id"},{"type":"int64","optional":false,"field":"total_order"},{"type":"int64","optional":false,"field":"data_collection_order"}],"optional":true,"field":"transaction"}],"optional":false,"name": "inventory-connector-oracle.inventory.products_on_hand.Envelope" }, "payload" :{ "before" : null , "after" :{ "product_id":101,"quantity":3 },"source":{"version":"2.7.3.Final-redhat-00001","connector":"oracle","name":"inventory-connector-oracle","ts_ms":1638985247805,"ts_us":1638985247805000000,"ts_ns":1638985247805000000,"snapshot":"true","db":"inventory","sequence":null,"table":"products_on_hand","server_id":0,"gtid":null,"file":"oracle-bin.000003","pos":156,"row":0,"thread":null,"query":null}, "op" : "r" ,"ts_ms":1638985247805,"ts_us":1638985247805102,"ts_ns":1638985247805102588,"transaction":null}}
boolean.type: io.debezium.connector.oracle.converters.NumberOneToBooleanConverter
boolean.selector: .*MYTABLE.FLAG,.*.IS_ARCHIVED
"snapshot.select.statement.overrides": "customer.orders", "snapshot.select.statement.overrides.customer.orders": "SELECT * FROM customers.orders WHERE delete_flag = 0 ORDER BY id DESC"
column.mask.hash.SHA-256.with.salt.CzQMA0cB5K = inventory.orders.customerName, inventory.shipment.customerName
database.port=1521 rac.nodes=192.168.1.100,192.168.1.101
database.port=1521 rac.nodes=192.168.1.100,192.168.1.101:1522
schema.history.internal.producer.security.protocol=SSL schema.history.internal.producer.ssl.keystore.location=/var/private/ssl/kafka.server.keystore.jks schema.history.internal.producer.ssl.keystore.password=test1234 schema.history.internal.producer.ssl.truststore.location=/var/private/ssl/kafka.server.truststore.jks schema.history.internal.producer.ssl.truststore.password=test1234 schema.history.internal.producer.ssl.key.password=test1234 schema.history.internal.consumer.security.protocol=SSL schema.history.internal.consumer.ssl.keystore.location=/var/private/ssl/kafka.server.keystore.jks schema.history.internal.consumer.ssl.keystore.password=test1234 schema.history.internal.consumer.ssl.truststore.location=/var/private/ssl/kafka.server.truststore.jks schema.history.internal.consumer.ssl.truststore.password=test1234 schema.history.internal.consumer.ssl.key.password=test1234
debezium.oracle:type=connector-metrics,context=streaming,server= <topic.prefix>
debezium.oracle:type=connector-metrics,context=streaming,server= <topic.prefix> ,database=salesdb-streaming,table=inventory
kafkacat -b localhost -C -t my_connect_offsets -f 'Partition(%p) %k %s\n' Partition(11) ["inventory-connector",{"server":"server1"}] {"scn":"324567897", "commit_scn":"324567897: 0x2832343233323:1"}
echo '["inventory-connector",{"server":"server1"}]|{"scn":"3245675000","commit_scn":"324567500"}' | kafkacat -P -b localhost -t my_connect_offsets -K \| -p 11
sysctl -w net.ipv4.tcp_keepalive_time=60
net.ipv4.tcp_keepalive_time=60
database.url=jdbc:oracle:thin:username/password!@(DESCRIPTION=(ENABLE=broken)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(Host=hostname)(Port=port)))(CONNECT_DATA=(SERVICE_NAME=serviceName)))
ORA-01555: snapshot too old: rollback segment number 12345 with name "_SYSSMU11_1234567890USD" too small
ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT
ORA-01882: timezone region not found
ORA-25191: cannot reference overflow table of an index-organized table
-Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl
INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}');
INSERT INTO myschema.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'execute-snapshot', 3 '{"data-collections": ["schema1.table1", "schema1.table2"], 4 "type":"incremental", 5 "additional-conditions":[{"data-collection": "schema1.table1" ,"filter":"color=\'blue\'"}]}'); 6
SELECT * FROM <tableName> .
SELECT * FROM <data-collection> WHERE <filter> .
INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}');
INSERT INTO myschema.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["schema1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "schema1.products", "filter": "color=blue"}]}');
INSERT INTO myschema.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["schema1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "schema1.products", "filter": "color=blue AND quantity>10"}]}');
{ "before":null, "after": { "pk":"1", "value":"New data" }, "source": { "snapshot":"incremental" 1 }, "op":"r", 2 "ts_ms":"1620393591654", "ts_us":"1620393591654547", "ts_ns":"1620393591654547920", "transaction":null }
Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["{collection-container}.table1", "{collection-container}.table2"], "type": "INCREMENTAL"}}`
Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["schema1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "schema1.products" ,"filter":"color='blue'"}]}}`
Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["schema1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "schema1.products" ,"filter":"color='blue' AND brand='MyBrand'"}]}}`
INSERT INTO <signalTable> (id, type, data) values ( '<id>' , 'stop-snapshot', '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":"incremental"}');
INSERT INTO myschema.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'stop-snapshot', 3 '{"data-collections": ["schema1.table1", "schema1.table2"], 4 "type":"incremental"}'); 5
Key = `test_connector` Value = `{"type":"stop-snapshot","data": {"data-collections": ["schema1.table1", "schema1.table2"], "type": "INCREMENTAL"}}`
{"type": "blocking", "data-collections": ["schema1.table1", "schema1.table2"], "additional-conditions": [{"data-collection": "schema1.table1", "filter": "SELECT * FROM [schema1].[table1] WHERE column1 = 0 ORDER BY column2 DESC"}, {"data-collection": "schema1.table2", "filter": "SELECT * FROM [schema1].[table2] WHERE column2 > 0"}]}
{ "status": "BEGIN", "id": "571:53195829", "ts_ms": 1486500577125, "event_count": null, "data_collections": null } { "status": "END", "id": "571:53195832", "ts_ms": 1486500577691, "event_count": 2, "data_collections": [ { "data_collection": "s1.a", "event_count": 1 }, { "data_collection": "s2.a", "event_count": 1 } ] }
{ "before": null, "after": { "pk": "2", "aa": "1" }, "source": { }, "op": "c", "ts_ms": "1580390884335", "ts_us": "1580390884335451", "ts_ns": "1580390884335451325", "transaction": { "id": "571:53195832", "total_order": "1", "data_collection_order": "1" } }
{ "schema": { 1 }, "payload": { 2 }, "schema": { 3 }, "payload": { 4 }, }
CREATE TABLE customers ( id SERIAL, first_name VARCHAR(255) NOT NULL, last_name VARCHAR(255) NOT NULL, email VARCHAR(255) NOT NULL, PRIMARY KEY(id) );
{ "schema": { 1 "type": "struct", "name": "PostgreSQL_server.public.customers.Key", 2 "optional": false, 3 "fields": [ 4 { "name": "id", "index": "0", "schema": { "type": "INT32", "optional": "false" } } ] }, "payload": { 5 "id": "1" }, }
CREATE TABLE customers ( id SERIAL, first_name VARCHAR(255) NOT NULL, last_name VARCHAR(255) NOT NULL, email VARCHAR(255) NOT NULL, PRIMARY KEY(id) );
{ "schema": { 1 "type": "struct", "fields": [ { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "id" }, { "type": "string", "optional": false, "field": "first_name" }, { "type": "string", "optional": false, "field": "last_name" }, { "type": "string", "optional": false, "field": "email" } ], "optional": true, "name": "PostgreSQL_server.inventory.customers.Value", 2 "field": "before" }, { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "id" }, { "type": "string", "optional": false, "field": "first_name" }, { "type": "string", "optional": false, "field": "last_name" }, { "type": "string", "optional": false, "field": "email" } ], "optional": true, "name": "PostgreSQL_server.inventory.customers.Value", "field": "after" }, { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "version" }, { "type": "string", "optional": false, "field": "connector" }, { "type": "string", "optional": false, "field": "name" }, { "type": "int64", "optional": false, "field": "ts_ms" }, { "type": "int64", "optional": false, "field": "ts_us" }, { "type": "int64", "optional": false, "field": "ts_ns" }, { "type": "boolean", "optional": true, "default": false, "field": "snapshot" }, { "type": "string", "optional": false, "field": "db" }, { "type": "string", "optional": false, "field": "schema" }, { "type": "string", "optional": false, "field": "table" }, { "type": "int64", "optional": true, "field": "txId" }, { "type": "int64", "optional": true, "field": "lsn" }, { "type": "int64", "optional": true, "field": "xmin" } ], "optional": false, "name": "io.debezium.connector.postgresql.Source", 3 "field": "source" }, { "type": "string", "optional": false, "field": "op" }, { "type": "int64", "optional": true, "field": "ts_ms" }, { "type": "int64", "optional": true, "field": "ts_us" }, { "type": "int64", "optional": true, "field": "ts_ns" } ], "optional": false, "name": "PostgreSQL_server.inventory.customers.Envelope" 4 }, "payload": { 5 "before": null, 6 "after": { 7 "id": 1, "first_name": "Anne", "last_name": "Kretchmar", "email": "annek@noanswer.org" }, "source": { 8 "version": "2.7.3.Final", "connector": "postgresql", "name": "PostgreSQL_server", "ts_ms": 1559033904863, "ts_us": 1559033904863123, "ts_ns": 1559033904863123000, "snapshot": true, "db": "postgres", "sequence": "[\"24023119\",\"24023128\"]", "schema": "public", "table": "customers", "txId": 555, "lsn": 24023128, "xmin": null }, "op": "c", 9 "ts_ms": 1559033904863, 10 "ts_us": 1559033904863841, 11 "ts_ns": 1559033904863841257 12 } }
{ "schema": { ... }, "payload": { "before": { 1 "id": 1 }, "after": { 2 "id": 1, "first_name": "Anne Marie", "last_name": "Kretchmar", "email": "annek@noanswer.org" }, "source": { 3 "version": "2.7.3.Final", "connector": "postgresql", "name": "PostgreSQL_server", "ts_ms": 1559033904863, "ts_us": 1559033904863769, "ts_ns": 1559033904863769000, "snapshot": false, "db": "postgres", "schema": "public", "table": "customers", "txId": 556, "lsn": 24023128, "xmin": null }, "op": "u", 4 "ts_ms": 1465584025523, 5 "ts_us": 1465584025523514, 6 "ts_ns": 1465584025523514964, 7 } }
{ "schema": { ... }, "payload": { "before": { 1 "id": 1 }, "after": null, 2 "source": { 3 "version": "2.7.3.Final", "connector": "postgresql", "name": "PostgreSQL_server", "ts_ms": 1559033904863, "ts_us": 1559033904863852, "ts_ns": 1559033904863852000, "snapshot": false, "db": "postgres", "schema": "public", "table": "customers", "txId": 556, "lsn": 46523128, "xmin": null }, "op": "d", 4 "ts_ms": 1465581902461, 5 "ts_us": 1465581902461496, 6 "ts_ns": 1465581902461496187, 7 } }
{ "schema": { ... }, "payload": { "source": { 1 "version": "2.7.3.Final", "connector": "postgresql", "name": "PostgreSQL_server", "ts_ms": 1559033904863, "ts_us": 1559033904863112, "ts_ns": 1559033904863112000, "snapshot": false, "db": "postgres", "schema": "public", "table": "customers", "txId": 556, "lsn": 46523128, "xmin": null }, "op": "t", 2 "ts_ms": 1559033904961, 3 "ts_us": 1559033904961654, 4 "ts_ns": 1559033904961654789 5 } }
{ "schema": { ... }, "payload": { "source": { 1 "version": "2.7.3.Final", "connector": "postgresql", "name": "PostgreSQL_server", "ts_ms": 1559033904863, "ts_us": 1559033904863879, "ts_ns": 1559033904863879000, "snapshot": false, "db": "postgres", "schema": "", "table": "", "txId": 556, "lsn": 46523128, "xmin": null }, "op": "m", 2 "ts_ms": 1559033904961, 3 "ts_us": 1559033904961621, 4 "ts_ns": 1559033904961621379, 5 "message": { 6 "prefix": "foo", "content": "Ymfy" } } }
{ "schema": { ... }, "payload": { "source": { 1 "version": "2.7.3.Final", "connector": "postgresql", "name": "PostgreSQL_server", "ts_ms": 1559033904863, "ts_us": 1559033904863762, "ts_ns": 1559033904863762000, "snapshot": false, "db": "postgres", "schema": "", "table": "", "lsn": 46523128, "xmin": null }, "op": "m", 2 "ts_ms": 1559033904961, 3 "ts_us": 1559033904961741, 4 "ts_ns": 1559033904961741698, 5 "message": { 6 "prefix": "foo", "content": "Ymfy" } }
wal_level=logical max_wal_senders=1 max_replication_slots=1
CREATE ROLE <name> REPLICATION LOGIN;
CREATE ROLE <replication_group> ;
GRANT REPLICATION_GROUP TO <original_owner> ;
GRANT REPLICATION_GROUP TO <replication_user> ;
ALTER TABLE <table_name> OWNER TO REPLICATION_GROUP;
local replication <youruser> trust 1 host replication <youruser> 127.0.0.1/32 trust 2 host replication <youruser> ::1/128 trust 3
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: debezium-kafka-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: version: 3.6.0 build: 2 output: 3 type: imagestream 4 image: debezium-streams-connect:latest plugins: 5 - name: debezium-connector-postgres artifacts: - type: zip 6 url: https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-postgres/2.7.3.Final-redhat-00001/debezium-connector-postgres-2.7.3.Final-redhat-00001-plugin.zip 7 - type: zip url: https://maven.repository.redhat.com/ga/io/apicurio/apicurio-registry-distro-connect-converter/2.4.4.Final-redhat- <build-number> /apicurio-registry-distro-connect-converter-2.4.4.Final-redhat- <build-number> .zip 8 - type: zip url: https://maven.repository.redhat.com/ga/io/debezium/debezium-scripting/2.7.3.Final-redhat-00001/debezium-scripting-2.7.3.Final-redhat-00001.zip 9 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy/3.0.11/groovy-3.0.11.jar 10 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-jsr223/3.0.11/groovy-jsr223-3.0.11.jar - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-json3.0.11/groovy-json-3.0.11.jar bootstrapServers: debezium-kafka-cluster-kafka-bootstrap:9093
create -f dbz-connect.yaml
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: labels: strimzi.io/cluster: debezium-kafka-connect-cluster name: inventory-connector-postgresql 1 spec: class: io.debezium.connector.postgresql.PostgresConnector 2 tasksMax: 1 3 config: 4 database.hostname: postgresql.debezium-postgresql.svc.cluster.local 5 database.port: 5432 6 database.user: debezium 7 database.password: dbz 8 database.dbname: mydatabase 9 topic.prefix: inventory-connector-postgresql 10 table.include.list: public.inventory 11
create -n <namespace> -f <kafkaConnector> .yaml
create -n debezium -f postgresql-inventory-connector.yaml
cat <<EOF >debezium-container-for-postgresql.yaml 1 FROM registry.redhat.io/amq-streams-kafka-35-rhel8:2.5.0 USER root:root RUN mkdir -p /opt/kafka/plugins/debezium 2 RUN cd /opt/kafka/plugins/debezium/ && curl -O https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-postgres/2.7.3.Final-redhat-00001/debezium-connector-postgres-2.7.3.Final-redhat-00001-plugin.zip && unzip debezium-connector-postgres-2.7.3.Final-redhat-00001-plugin.zip && rm debezium-connector-postgres-2.7.3.Final-redhat-00001-plugin.zip RUN cd /opt/kafka/plugins/debezium/ USER 1001 EOF
build -t debezium-container-for-postgresql:latest .
docker build -t debezium-container-for-postgresql:latest .
push <myregistry.io> /debezium-container-for-postgresql:latest
docker push <myregistry.io> /debezium-container-for-postgresql:latest
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: image: debezium-container-for-postgresql 2
create -f dbz-connect.yaml
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: inventory-connector-postgresql 1 labels: strimzi.io/cluster: my-connect-cluster spec: class: io.debezium.connector.postgresql.PostgresConnector tasksMax: 1 2 config: 3 database.hostname: 192.168.99.100 4 database.port: 5432 database.user: debezium database.password: dbz database.dbname: sampledb topic.prefix: inventory-connector-postgresql 5 schema.include.list: public 6 plugin.name: pgoutput 7
apply -f inventory-connector.yaml
describe KafkaConnector <connector-name> -n <project>
describe KafkaConnector inventory-connector-postgresql -n debezium
Name: inventory-connector-postgresql Namespace: debezium Labels: strimzi.io/cluster=debezium-kafka-connect-cluster Annotations: <none> API Version: kafka.strimzi.io/v1beta2 Kind: KafkaConnector Status: Conditions: Last Transition Time: 2021-12-08T17:41:34.897153Z Status: True Type: Ready Connector Status: Connector: State: RUNNING worker_id: 10.131.1.124:8083 Name: inventory-connector-postgresql Tasks: Id: 0 State: RUNNING worker_id: 10.131.1.124:8083 Type: source Observed Generation: 1 Tasks Max: 1 Topics: inventory-connector-postgresql.inventory inventory-connector-postgresql.inventory.addresses inventory-connector-postgresql.inventory.customers inventory-connector-postgresql.inventory.geom inventory-connector-postgresql.inventory.orders inventory-connector-postgresql.inventory.products inventory-connector-postgresql.inventory.products_on_hand Events: <none>
get kafkatopics
NAME CLUSTER PARTITIONS REPLICATION FACTOR READY connect-cluster-configs debezium-kafka-cluster 1 1 True connect-cluster-offsets debezium-kafka-cluster 25 1 True connect-cluster-status debezium-kafka-cluster 5 1 True consumer-offsets---84e7a678d08f4bd226872e5cdd4eb527fadc1c6a debezium-kafka-cluster 50 1 True inventory-connector-postgresql--a96f69b23d6118ff415f772679da623fbbb99421 debezium-kafka-cluster 1 1 True inventory-connector-postgresql.inventory.addresses---1b6beaf7b2eb57d177d92be90ca2b210c9a56480 debezium-kafka-cluster 1 1 True inventory-connector-postgresql.inventory.customers---9931e04ec92ecc0924f4406af3fdace7545c483b debezium-kafka-cluster 1 1 True inventory-connector-postgresql.inventory.geom---9f7e136091f071bf49ca59bf99e86c713ee58dd5 debezium-kafka-cluster 1 1 True inventory-connector-postgresql.inventory.orders---ac5e98ac6a5d91e04d8ec0dc9078a1ece439081d debezium-kafka-cluster 1 1 True inventory-connector-postgresql.inventory.products---df0746db116844cee2297fab611c21b56f82dcef debezium-kafka-cluster 1 1 True inventory-connector-postgresql.inventory.products_on_hand---8649e0f17ffcc9212e266e31a7aeea4585e5c6b5 debezium-kafka-cluster 1 1 True schema-changes.inventory debezium-kafka-cluster 1 1 True strimzi-store-topic---effb8e3e057afce1ecf67c3f5d8e4e3ff177fc55 debezium-kafka-cluster 1 1 True strimzi-topic-operator-kstreams-topic-store-changelog---b75e702040b99be8a9263134de3507fc0cc4017b debezium-kafka-cluster 1 1 True
exec -n <project> -it <kafka-cluster> -- /opt/kafka/bin/kafka-console-consumer.sh > --bootstrap-server localhost:9092 > --from-beginning > --property print.key=true > --topic= <topic-name >
exec -n debezium -it debezium-kafka-cluster-kafka-0 -- /opt/kafka/bin/kafka-console-consumer.sh > --bootstrap-server localhost:9092 > --from-beginning > --property print.key=true > --topic=inventory-connector-postgresql.inventory.products_on_hand
{"schema":{"type":"struct","fields":[{"type":"int32","optional":false,"field":"product_id"}],"optional":false,"name":"inventory-connector-postgresql.inventory.products_on_hand.Key"},"payload":{"product_id":101}} {"schema":{"type":"struct","fields":[{"type":"struct","fields":[{"type":"int32","optional":false,"field":"product_id"},{"type":"int32","optional":false,"field":"quantity"}],"optional":true,"name":"inventory-connector-postgresql.inventory.products_on_hand.Value","field":"before"},{"type":"struct","fields":[{"type":"int32","optional":false,"field":"product_id"},{"type":"int32","optional":false,"field":"quantity"}],"optional":true,"name":"inventory-connector-postgresql.inventory.products_on_hand.Value","field":"after"},{"type":"struct","fields":[{"type":"string","optional":false,"field":"version"},{"type":"string","optional":false,"field":"connector"},{"type":"string","optional":false,"field":"name"},{"type":"int64","optional":false,"field":"ts_ms"},{"type":"int64","optional":false,"field":"ts_us"},{"type":"int64","optional":false,"field":"ts_ns"},{"type":"string","optional":true,"name":"io.debezium.data.Enum","version":1,"parameters":{"allowed":"true,last,false"},"default":"false","field":"snapshot"},{"type":"string","optional":false,"field":"db"},{"type":"string","optional":true,"field":"sequence"},{"type":"string","optional":true,"field":"table"},{"type":"int64","optional":false,"field":"server_id"},{"type":"string","optional":true,"field":"gtid"},{"type":"string","optional":false,"field":"file"},{"type":"int64","optional":false,"field":"pos"},{"type":"int32","optional":false,"field":"row"},{"type":"int64","optional":true,"field":"thread"},{"type":"string","optional":true,"field":"query"}],"optional":false,"name":"io.debezium.connector.postgresql.Source","field":"source"},{"type":"string","optional":false,"field":"op"},{"type":"int64","optional":true,"field":"ts_ms"},{"type":"int64","optional":true,"field":"ts_us"},{"type":"int64","optional":true,"field":"ts_ns"},{"type":"struct","fields":[{"type":"string","optional":false,"field":"id"},{"type":"int64","optional":false,"field":"total_order"},{"type":"int64","optional":false,"field":"data_collection_order"}],"optional":true,"field":"transaction"}],"optional":false,"name": "inventory-connector-postgresql.inventory.products_on_hand.Envelope" }, "payload" :{ "before" : null , "after" :{ "product_id":101,"quantity":3 },"source":{"version":"2.7.3.Final-redhat-00001","connector":"postgresql","name":"inventory-connector-postgresql","ts_ms":1638985247805,"ts_us":1638985247805000000,"ts_ns":1638985247805000000,"snapshot":"true","db":"inventory","sequence":null,"table":"products_on_hand","server_id":0,"gtid":null,"file":"postgresql-bin.000003","pos":156,"row":0,"thread":null,"query":null}, "op" : "r" ,"ts_ms":1638985247805,"ts_us":1638985247805102,"ts_ns":1638985247805102588,"transaction":null}}
column.mask.hash.SHA-256.with.salt.CzQMA0cB5K = inventory.orders.customerName, inventory.shipment.customerName
schema1.*:FULL,schema2.table2:NOTHING,schema2.table3:INDEX idx_name
isbn.type: io.debezium.test.IsbnConverter
isbn.schema.name: io.debezium.postgresql.type.Isbn
"snapshot.select.statement.overrides": "customer.orders", "snapshot.select.statement.overrides.customer.orders": "SELECT * FROM customers.orders WHERE delete_flag = 0 ORDER BY id DESC"
debezium.postgresql:type=connector-metrics,context=streaming,server= <topic.prefix>
debezium.postgresql:type=connector-metrics,context=streaming,server= <topic.prefix> ,database=salesdb-streaming,table=inventory
INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}');
INSERT INTO db1.myschema.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'execute-snapshot', 3 '{"data-collections": ["db1.schema1.table1", "db1.schema1.table2"], 4 "type":"incremental", 5 "additional-conditions":[{"data-collection": "db1.schema1.table1" ,"filter":"color=\'blue\'"}]}'); 6
SELECT * FROM <tableName> .
SELECT * FROM <data-collection> WHERE <filter> .
INSERT INTO <signalTable> (id, type, data) VALUES ( '<id>' , '<snapshotType>' , '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":" <snapshotType> ","additional-conditions":[{"data-collection": " <fullyQualfiedTableName> ", "filter": " <additional-condition> "}]}');
INSERT INTO db1.myschema.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["db1.schema1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "db1.schema1.products", "filter": "color=blue"}]}');
INSERT INTO db1.myschema.debezium_signal (id, type, data) VALUES('ad-hoc-1', 'execute-snapshot', '{"data-collections": ["db1.schema1.products"],"type":"incremental", "additional-conditions":[{"data-collection": "db1.schema1.products", "filter": "color=blue AND quantity>10"}]}');
{ "before":null, "after": { "pk":"1", "value":"New data" }, "source": { "snapshot":"incremental" 1 }, "op":"r", 2 "ts_ms":"1620393591654", "ts_us":"1620393591654547", "ts_ns":"1620393591654547920", "transaction":null }
Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["{collection-container}.table1", "{collection-container}.table2"], "type": "INCREMENTAL"}}`
Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["db1.schema1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "db1.schema1.products" ,"filter":"color='blue'"}]}}`
Key = `test_connector` Value = `{"type":"execute-snapshot","data": {"data-collections": ["db1.schema1.products"], "type": "INCREMENTAL", "additional-conditions": [{"data-collection": "db1.schema1.products" ,"filter":"color='blue' AND brand='MyBrand'"}]}}`
INSERT INTO <signalTable> (id, type, data) values ( '<id>' , 'stop-snapshot', '{"data-collections": [" <fullyQualfiedTableName> "," <fullyQualfiedTableName> "],"type":"incremental"}');
INSERT INTO db1.myschema.debezium_signal (id, type, data) 1 values ('ad-hoc-1', 2 'stop-snapshot', 3 '{"data-collections": ["db1.schema1.table1", "db1.schema1.table2"], 4 "type":"incremental"}'); 5
Key = `test_connector` Value = `{"type":"stop-snapshot","data": {"data-collections": ["db1.schema1.table1", "db1.schema1.table2"], "type": "INCREMENTAL"}}`
{"type": "blocking", "data-collections": ["schema1.table1", "schema1.table2"], "additional-conditions": [{"data-collection": "schema1.table1", "filter": "SELECT * FROM [schema1].[table1] WHERE column1 = 0 ORDER BY column2 DESC"}, {"data-collection": "schema1.table2", "filter": "SELECT * FROM [schema1].[table2] WHERE column2 > 0"}]}
{ "schema": { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "databaseName" } ], "optional": false, "name": "io.debezium.connector.sqlserver.SchemaChangeKey", "version": 1 }, "payload": { "databaseName": "inventory" } }
{ "schema": { }, "payload": { "source": { "version": "2.7.3.Final", "connector": "sqlserver", "name": "server1", "ts_ms": 0, "snapshot": "true", "db": "testDB", "schema": "dbo", "table": "customers", "change_lsn": null, "commit_lsn": "00000025:00000d98:00a2", "event_serial_no": null }, "ts_ms": 1588252618953, 1 "databaseName": "testDB", 2 "schemaName": "dbo", "ddl": null, 3 "tableChanges": [ 4 { "type": "CREATE", 5 "id": "\"testDB\".\"dbo\".\"customers\"", 6 "table": { 7 "defaultCharsetName": null, "primaryKeyColumnNames": [ 8 "id" ], "columns": [ 9 { "name": "id", "jdbcType": 4, "nativeType": null, "typeName": "int identity", "typeExpression": "int identity", "charsetName": null, "length": 10, "scale": 0, "position": 1, "optional": false, "autoIncremented": false, "generated": false }, { "name": "first_name", "jdbcType": 12, "nativeType": null, "typeName": "varchar", "typeExpression": "varchar", "charsetName": null, "length": 255, "scale": null, "position": 2, "optional": false, "autoIncremented": false, "generated": false }, { "name": "last_name", "jdbcType": 12, "nativeType": null, "typeName": "varchar", "typeExpression": "varchar", "charsetName": null, "length": 255, "scale": null, "position": 3, "optional": false, "autoIncremented": false, "generated": false }, { "name": "email", "jdbcType": 12, "nativeType": null, "typeName": "varchar", "typeExpression": "varchar", "charsetName": null, "length": 255, "scale": null, "position": 4, "optional": false, "autoIncremented": false, "generated": false } ], "attributes": [ 10 { "customAttribute": "attributeValue" } ] } } ] } }
{ "schema": { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "databaseName" } ], "optional": false, "name": "io.debezium.connector.sqlserver.SchemaChangeKey", "version": 1 }, "payload": { "databaseName": "testDB" } }
{ "schema": { 1 }, "payload": { 2 }, "schema": { 3 }, "payload": { 4 }, }
CREATE TABLE customers ( id INTEGER IDENTITY(1001,1) NOT NULL PRIMARY KEY, first_name VARCHAR(255) NOT NULL, last_name VARCHAR(255) NOT NULL, email VARCHAR(255) NOT NULL UNIQUE );
{ "schema": { 1 "type": "struct", "fields": [ 2 { "type": "int32", "optional": false, "field": "id" } ], "optional": false, 3 "name": "server1.testDB.dbo.customers.Key" 4 }, "payload": { 5 "id": 1004 } }
CREATE TABLE customers ( id INTEGER IDENTITY(1001,1) NOT NULL PRIMARY KEY, first_name VARCHAR(255) NOT NULL, last_name VARCHAR(255) NOT NULL, email VARCHAR(255) NOT NULL UNIQUE );
{ "schema": { 1 "type": "struct", "fields": [ { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "id" }, { "type": "string", "optional": false, "field": "first_name" }, { "type": "string", "optional": false, "field": "last_name" }, { "type": "string", "optional": false, "field": "email" } ], "optional": true, "name": "server1.dbo.testDB.customers.Value", 2 "field": "before" }, { "type": "struct", "fields": [ { "type": "int32", "optional": false, "field": "id" }, { "type": "string", "optional": false, "field": "first_name" }, { "type": "string", "optional": false, "field": "last_name" }, { "type": "string", "optional": false, "field": "email" } ], "optional": true, "name": "server1.dbo.testDB.customers.Value", "field": "after" }, { "type": "struct", "fields": [ { "type": "string", "optional": false, "field": "version" }, { "type": "string", "optional": false, "field": "connector" }, { "type": "string", "optional": false, "field": "name" }, { "type": "int64", "optional": false, "field": "ts_ms" }, { "type": "int64", "optional": false, "field": "ts_us" }, { "type": "int64", "optional": false, "field": "ts_ns" }, { "type": "boolean", "optional": true, "default": false, "field": "snapshot" }, { "type": "string", "optional": false, "field": "db" }, { "type": "string", "optional": false, "field": "schema" }, { "type": "string", "optional": false, "field": "table" }, { "type": "string", "optional": true, "field": "change_lsn" }, { "type": "string", "optional": true, "field": "commit_lsn" }, { "type": "int64", "optional": true, "field": "event_serial_no" } ], "optional": false, "name": "io.debezium.connector.sqlserver.Source", 3 "field": "source" }, { "type": "string", "optional": false, "field": "op" }, { "type": "int64", "optional": true, "field": "ts_ms" }, { "type": "int64", "optional": true, "field": "ts_us" }, { "type": "int64", "optional": true, "field": "ts_ns" } ], "optional": false, "name": "server1.dbo.testDB.customers.Envelope" 4 }, "payload": { 5 "before": null, 6 "after": { 7 "id": 1005, "first_name": "john", "last_name": "doe", "email": "john.doe@example.org" }, "source": { 8 "version": "2.7.3.Final", "connector": "sqlserver", "name": "server1", "ts_ms": 1559729468470, "ts_us": 1559729468470000, "ts_ns": 1559729468470000000, "snapshot": false, "db": "testDB", "schema": "dbo", "table": "customers", "change_lsn": "00000027:00000758:0003", "commit_lsn": "00000027:00000758:0005", "event_serial_no": "1" }, "op": "c", 9 "ts_ms": 1559729471739, 10 "ts_ms": 1559729471739876, 11 "ts_ms": 1559729471739876149 12 } }
{ "schema": { ... }, "payload": { "before": { 1 "id": 1005, "first_name": "john", "last_name": "doe", "email": "john.doe@example.org" }, "after": { 2 "id": 1005, "first_name": "john", "last_name": "doe", "email": "noreply@example.org" }, "source": { 3 "version": "2.7.3.Final", "connector": "sqlserver", "name": "server1", "ts_ms": 1559729995937, "ts_us": 1559729995937000, "ts_ns": 1559729995937000000, "snapshot": false, "db": "testDB", "schema": "dbo", "table": "customers", "change_lsn": "00000027:00000ac0:0002", "commit_lsn": "00000027:00000ac0:0007", "event_serial_no": "2" }, "op": "u", 4 "ts_ms": 1559729998706, 5 "ts_us": 1559729998706318, 6 "ts_ns": 1559729998706318547 7 } }
{ "schema": { ... }, }, "payload": { "before": { <> "id": 1005, "first_name": "john", "last_name": "doe", "email": "noreply@example.org" }, "after": null, 1 "source": { 2 "version": "2.7.3.Final", "connector": "sqlserver", "name": "server1", "ts_ms": 1559730445243, "ts_us": 1559730445243000, "ts_ns": 1559730445243000000, "snapshot": false, "db": "testDB", "schema": "dbo", "table": "customers", "change_lsn": "00000027:00000db0:0005", "commit_lsn": "00000027:00000db0:0007", "event_serial_no": "1" }, "op": "d", 3 "ts_ms": 1559730450205, 4 "ts_us": 1559730450205387, 5 "ts_ns": 1559730450205387492 6 } }
{ "status": "BEGIN", "id": "00000025:00000d08:0025", "ts_ms": 1486500577125, "event_count": null, "data_collections": null } { "status": "END", "id": "00000025:00000d08:0025", "ts_ms": 1486500577691, "event_count": 2, "data_collections": [ { "data_collection": "testDB.dbo.testDB.tablea", "event_count": 1 }, { "data_collection": "testDB.dbo.testDB.tableb", "event_count": 1 } ] }
{ "before": null, "after": { "pk": "2", "aa": "1" }, "source": { }, "op": "c", "ts_ms": "1580390884335", "ts_us": "1580390884335172", "ts_ns": "1580390884335172574", "transaction": { "id": "00000025:00000d08:0025", "total_order": "1", "data_collection_order": "1" } }
USE MyDB GO EXEC sys.sp_cdc_enable_db GO
USE MyDB GO EXEC sys.sp_cdc_enable_table @source_schema = N'dbo', @source_name = N'MyTable', //<.> @role_name = N'MyRole', //<.> @filegroup_name = N'MyDB_CT',//<.> @supports_net_changes = 0 GO
USE MyDB; GO EXEC sys.sp_cdc_help_change_data_capture GO
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: debezium-kafka-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: version: 3.6.0 build: 2 output: 3 type: imagestream 4 image: debezium-streams-connect:latest plugins: 5 - name: debezium-connector-sqlserver artifacts: - type: zip 6 url: https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-sqlserver/2.7.3.Final-redhat-00001/debezium-connector-sqlserver-2.7.3.Final-redhat-00001-plugin.zip 7 - type: zip url: https://maven.repository.redhat.com/ga/io/apicurio/apicurio-registry-distro-connect-converter/2.4.4.Final-redhat- <build-number> /apicurio-registry-distro-connect-converter-2.4.4.Final-redhat- <build-number> .zip 8 - type: zip url: https://maven.repository.redhat.com/ga/io/debezium/debezium-scripting/2.7.3.Final-redhat-00001/debezium-scripting-2.7.3.Final-redhat-00001.zip 9 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy/3.0.11/groovy-3.0.11.jar 10 - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-jsr223/3.0.11/groovy-jsr223-3.0.11.jar - type: jar url: https://repo1.maven.org/maven2/org/apache/groovy/groovy-json3.0.11/groovy-json-3.0.11.jar bootstrapServers: debezium-kafka-cluster-kafka-bootstrap:9093
create -f dbz-connect.yaml
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: labels: strimzi.io/cluster: debezium-kafka-connect-cluster name: inventory-connector-sqlserver 1 spec: class: io.debezium.connector.sqlserver.SqlServerConnector 2 tasksMax: 1 3 config: 4 schema.history.internal.kafka.bootstrap.servers: debezium-kafka-cluster-kafka-bootstrap.debezium.svc.cluster.local:9092 schema.history.internal.kafka.topic: schema-changes.inventory database.hostname: sqlserver.debezium-sqlserver.svc.cluster.local 5 database.port: 1433 6 database.user: debezium 7 database.password: dbz 8 topic.prefix: inventory-connector-sqlserver 9 table.include.list: dbo.customers 10
create -n <namespace> -f <kafkaConnector> .yaml
create -n debezium -f sqlserver-inventory-connector.yaml
cat <<EOF >debezium-container-for-sqlserver.yaml 1 FROM registry.redhat.io/amq-streams-kafka-35-rhel8:2.5.0 USER root:root RUN mkdir -p /opt/kafka/plugins/debezium 2 RUN cd /opt/kafka/plugins/debezium/ && curl -O https://maven.repository.redhat.com/ga/io/debezium/debezium-connector-sqlserver/2.7.3.Final-redhat-00001/debezium-connector-sqlserver-2.7.3.Final-redhat-00001-plugin.zip && unzip debezium-connector-sqlserver-2.7.3.Final-redhat-00001-plugin.zip && rm debezium-connector-sqlserver-2.7.3.Final-redhat-00001-plugin.zip RUN cd /opt/kafka/plugins/debezium/ USER 1001 EOF
build -t debezium-container-for-sqlserver:latest .
docker build -t debezium-container-for-sqlserver:latest .
push <myregistry.io> /debezium-container-for-sqlserver:latest
docker push <myregistry.io> /debezium-container-for-sqlserver:latest
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect-cluster annotations: strimzi.io/use-connector-resources: "true" 1 spec: # image: debezium-container-for-sqlserver 2
create -f dbz-connect.yaml
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: inventory-connector-sqlserver 1 labels: strimzi.io/cluster: my-connect-cluster annotations: strimzi.io/use-connector-resources: 'true' spec: class: io.debezium.connector.sqlserver.SqlServerConnector 2 config: database.hostname: 192.168.99.100 3 database.port: 1433 4 database.user: debezium 5 database.password: dbz 6 topic.prefix: inventory-connector-sqlserver 7 table.include.list: dbo.customers 8 schema.history.internal.kafka.bootstrap.servers: my-cluster-kafka-bootstrap:9092 9 schema.history.internal.kafka.topic: schemahistory.fullfillment 10 database.ssl.truststore: path/to/trust-store 11 database.ssl.truststore.password: password-for-trust-store 12
apply -f inventory-connector.yaml
describe KafkaConnector <connector-name> -n <project>
describe KafkaConnector inventory-connector-sqlserver -n debezium
Name: inventory-connector-sqlserver Namespace: debezium Labels: strimzi.io/cluster=debezium-kafka-connect-cluster Annotations: <none> API Version: kafka.strimzi.io/v1beta2 Kind: KafkaConnector Status: Conditions: Last Transition Time: 2021-12-08T17:41:34.897153Z Status: True Type: Ready Connector Status: Connector: State: RUNNING worker_id: 10.131.1.124:8083 Name: inventory-connector-sqlserver Tasks: Id: 0 State: RUNNING worker_id: 10.131.1.124:8083 Type: source Observed Generation: 1 Tasks Max: 1 Topics: inventory-connector-sqlserver.inventory inventory-connector-sqlserver.inventory.addresses inventory-connector-sqlserver.inventory.customers inventory-connector-sqlserver.inventory.geom inventory-connector-sqlserver.inventory.orders inventory-connector-sqlserver.inventory.products inventory-connector-sqlserver.inventory.products_on_hand Events: <none>
get kafkatopics
NAME CLUSTER PARTITIONS REPLICATION FACTOR READY connect-cluster-configs debezium-kafka-cluster 1 1 True connect-cluster-offsets debezium-kafka-cluster 25 1 True connect-cluster-status debezium-kafka-cluster 5 1 True consumer-offsets---84e7a678d08f4bd226872e5cdd4eb527fadc1c6a debezium-kafka-cluster 50 1 True inventory-connector-sqlserver--a96f69b23d6118ff415f772679da623fbbb99421 debezium-kafka-cluster 1 1 True inventory-connector-sqlserver.inventory.addresses---1b6beaf7b2eb57d177d92be90ca2b210c9a56480 debezium-kafka-cluster 1 1 True inventory-connector-sqlserver.inventory.customers---9931e04ec92ecc0924f4406af3fdace7545c483b debezium-kafka-cluster 1 1 True inventory-connector-sqlserver.inventory.geom---9f7e136091f071bf49ca59bf99e86c713ee58dd5 debezium-kafka-cluster 1 1 True inventory-connector-sqlserver.inventory.orders---ac5e98ac6a5d91e04d8ec0dc9078a1ece439081d debezium-kafka-cluster 1 1 True inventory-connector-sqlserver.inventory.products---df0746db116844cee2297fab611c21b56f82dcef debezium-kafka-cluster 1 1 True inventory-connector-sqlserver.inventory.products_on_hand---8649e0f17ffcc9212e266e31a7aeea4585e5c6b5 debezium-kafka-cluster 1 1 True schema-changes.inventory debezium-kafka-cluster 1 1 True strimzi-store-topic---effb8e3e057afce1ecf67c3f5d8e4e3ff177fc55 debezium-kafka-cluster 1 1 True strimzi-topic-operator-kstreams-topic-store-changelog---b75e702040b99be8a9263134de3507fc0cc4017b debezium-kafka-cluster 1 1 True
exec -n <project> -it <kafka-cluster> -- /opt/kafka/bin/kafka-console-consumer.sh > --bootstrap-server localhost:9092 > --from-beginning > --property print.key=true > --topic= <topic-name >
exec -n debezium -it debezium-kafka-cluster-kafka-0 -- /opt/kafka/bin/kafka-console-consumer.sh > --bootstrap-server localhost:9092 > --from-beginning > --property print.key=true > --topic=inventory-connector-sqlserver.inventory.products_on_hand
{"schema":{"type":"struct","fields":[{"type":"int32","optional":false,"field":"product_id"}],"optional":false,"name":"inventory-connector-sqlserver.inventory.products_on_hand.Key"},"payload":{"product_id":101}} {"schema":{"type":"struct","fields":[{"type":"struct","fields":[{"type":"int32","optional":false,"field":"product_id"},{"type":"int32","optional":false,"field":"quantity"}],"optional":true,"name":"inventory-connector-sqlserver.inventory.products_on_hand.Value","field":"before"},{"type":"struct","fields":[{"type":"int32","optional":false,"field":"product_id"},{"type":"int32","optional":false,"field":"quantity"}],"optional":true,"name":"inventory-connector-sqlserver.inventory.products_on_hand.Value","field":"after"},{"type":"struct","fields":[{"type":"string","optional":false,"field":"version"},{"type":"string","optional":false,"field":"connector"},{"type":"string","optional":false,"field":"name"},{"type":"int64","optional":false,"field":"ts_ms"},{"type":"int64","optional":false,"field":"ts_us"},{"type":"int64","optional":false,"field":"ts_ns"},{"type":"string","optional":true,"name":"io.debezium.data.Enum","version":1,"parameters":{"allowed":"true,last,false"},"default":"false","field":"snapshot"},{"type":"string","optional":false,"field":"db"},{"type":"string","optional":true,"field":"sequence"},{"type":"string","optional":true,"field":"table"},{"type":"int64","optional":false,"field":"server_id"},{"type":"string","optional":true,"field":"gtid"},{"type":"string","optional":false,"field":"file"},{"type":"int64","optional":false,"field":"pos"},{"type":"int32","optional":false,"field":"row"},{"type":"int64","optional":true,"field":"thread"},{"type":"string","optional":true,"field":"query"}],"optional":false,"name":"io.debezium.connector.sqlserver.Source","field":"source"},{"type":"string","optional":false,"field":"op"},{"type":"int64","optional":true,"field":"ts_ms"},{"type":"int64","optional":true,"field":"ts_us"},{"type":"int64","optional":true,"field":"ts_ns"},{"type":"struct","fields":[{"type":"string","optional":false,"field":"id"},{"type":"int64","optional":false,"field":"total_order"},{"type":"int64","optional":false,"field":"data_collection_order"}],"optional":true,"field":"transaction"}],"optional":false,"name": "inventory-connector-sqlserver.inventory.products_on_hand.Envelope" }, "payload" :{ "before" : null , "after" :{ "product_id":101,"quantity":3 },"source":{"version":"2.7.3.Final-redhat-00001","connector":"sqlserver","name":"inventory-connector-sqlserver","ts_ms":1638985247805,"ts_us":1638985247805000000,"ts_ns":1638985247805000000,"snapshot":"true","db":"inventory","sequence":null,"table":"products_on_hand","server_id":0,"gtid":null,"file":"sqlserver-bin.000003","pos":156,"row":0,"thread":null,"query":null}, "op" : "r" ,"ts_ms":1638985247805,"ts_us":1638985247805102,"ts_ns":1638985247805102588,"transaction":null}}
column.mask.hash.SHA-256.with.salt.CzQMA0cB5K = inventory.orders.customerName, inventory.shipment.customerName
isbn.type: io.debezium.test.IsbnConverter
isbn.schema.name: io.debezium.sqlserver.type.Isbn
"snapshot.select.statement.overrides": "customer.orders", "snapshot.select.statement.overrides.customer.orders": "SELECT * FROM customers.orders WHERE delete_flag = 0 ORDER BY id DESC"
schema.history.internal.producer.security.protocol=SSL schema.history.internal.producer.ssl.keystore.location=/var/private/ssl/kafka.server.keystore.jks schema.history.internal.producer.ssl.keystore.password=test1234 schema.history.internal.producer.ssl.truststore.location=/var/private/ssl/kafka.server.truststore.jks schema.history.internal.producer.ssl.truststore.password=test1234 schema.history.internal.producer.ssl.key.password=test1234 schema.history.internal.consumer.security.protocol=SSL schema.history.internal.consumer.ssl.keystore.location=/var/private/ssl/kafka.server.keystore.jks schema.history.internal.consumer.ssl.keystore.password=test1234 schema.history.internal.consumer.ssl.truststore.location=/var/private/ssl/kafka.server.truststore.jks schema.history.internal.consumer.ssl.truststore.password=test1234 schema.history.internal.consumer.ssl.key.password=test1234
ALTER TABLE customers ADD phone_number VARCHAR(32);
EXEC sys.sp_cdc_enable_table @source_schema = 'dbo', @source_name = 'customers', @role_name = NULL, @supports_net_changes = 0, @capture_instance = 'dbo_customers_v2'; GO
INSERT INTO customers(first_name,last_name,email,phone_number) VALUES ('John','Doe','john.doe@example.com', '+1-555-123456'); GO
connect_1 | 2019-01-17 10:11:14,924 INFO || Multiple capture instances present for the same table: Capture instance "dbo_customers" [sourceTableId=testDB.dbo.customers, changeTableId=testDB.cdc.dbo_customers_CT, startLsn=00000024:00000d98:0036, changeTableObjectId=1525580473, stopLsn=00000025:00000ef8:0048] and Capture instance "dbo_customers_v2" [sourceTableId=testDB.dbo.customers, changeTableId=testDB.cdc.dbo_customers_v2_CT, startLsn=00000025:00000ef8:0048, changeTableObjectId=1749581271, stopLsn=NULL] [io.debezium.connector.sqlserver.SqlServerStreamingChangeEventSource] connect_1 | 2019-01-17 10:11:14,924 INFO || Schema will be changed for ChangeTable [captureInstance=dbo_customers_v2, sourceTableId=testDB.dbo.customers, changeTableId=testDB.cdc.dbo_customers_v2_CT, startLsn=00000025:00000ef8:0048, changeTableObjectId=1749581271, stopLsn=NULL] [io.debezium.connector.sqlserver.SqlServerStreamingChangeEventSource] connect_1 | 2019-01-17 10:11:33,719 INFO || Migrating schema to ChangeTable [captureInstance=dbo_customers_v2, sourceTableId=testDB.dbo.customers, changeTableId=testDB.cdc.dbo_customers_v2_CT, startLsn=00000025:00000ef8:0048, changeTableObjectId=1749581271, stopLsn=NULL] [io.debezium.connector.sqlserver.SqlServerStreamingChangeEventSource]
{ "type": "string", "optional": true, "field": "phone_number" } "after": { "id": 1005, "first_name": "John", "last_name": "Doe", "email": "john.doe@example.com", "phone_number": "+1-555-123456" },
EXEC sys.sp_cdc_disable_table @source_schema = 'dbo', @source_name = 'dbo_customers', @capture_instance = 'dbo_customers'; GO
debezium.sqlserver:type=connector-metrics,context=streaming,server= <topic.prefix>
debezium.sqlserver:type=connector-metrics,context=streaming,server= <topic.prefix> ,database=salesdb-streaming,table=inventory