Chapter 5. 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:

5.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.

5.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

5.2. How Debezium MongoDB connectors work

An overview of the MongoDB topologies that the connector supports is useful for planning your application.

When a MongoDB connector is configured and deployed, it starts by connecting to the MongoDB servers at the seed addresses, and determines the details about each of the available replica sets. Since each replica set has its own independent oplog, the connector will try to use a separate task for each replica set. The connector can limit the maximum number of tasks it will use, and if not enough tasks are available the connector will assign multiple replica sets to each task, although the task will still use a separate thread for each replica set.

Note

When running the connector against a sharded cluster, use a value of tasks.max that is greater than the number of replica sets. This will allow the connector to create one task for each replica set, and will let Kafka Connect coordinate, distribute, and manage the tasks across all of the available worker processes.

The following topics provide details about how the Debezium MongoDB connector works:

5.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.

Warning

Due to changes in the way that the connector manages database connections, this release of Debezium no longer supports use of the mongodb.members.auto.discover property to prevent the connector from performing membership discovery.

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.

Warning

The mongodb.connection.string property replaces the deprecated mongodb.hosts property that was used to provide earlier versions of the connector with the host address of the configuration server replica. In the current release, use mongodb.connection.string to provide the connector with the addresses of MongoDB routers, also known as mongos.

Note

When the connector connects to sharded cluster, it discovers the information about each replica set that represents a shard in the cluster. The connector uses a separate task to capture changes from each shard. As shards are added or removed from the cluster, the connector dynamically adjusts the numbers of tasks to compensate for the change.

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.

5.2.2. 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.

5.2.3. 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:

5.2.4. 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. The following changes in a database might be cause for performing an ad hoc snapshot:

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, and provide the names of the collections to include in the snapshot, as described in the following table:

Table 5.1. Example of an ad hoc execute-snapshot signal record
Field	Default	Value
`type`	`incremental`	Specifies the type of snapshot that you want to run. Setting the type is optional. Currently, you can request only `incremental` snapshots.
`data-collections`	N/A	An array that contains regular expressions matching the fully-qualified names of the collection to be snapshotted. The format of the names is the same as for the `signal.data.collection` configuration option.
`additional-condition`	N/A	An optional string, which specifies a condition based on the column(s) of the collection(s), to capture a subset of the contents of the collection(s).
`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 snapshot

You initiate an ad hoc snapshot by adding an entry with the execute-snapshot signal type to the signaling collection. 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.

Currently, the execute-snapshot action type triggers incremental snapshots only. For more information, see Incremental snapshots.

5.2.5. 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 windows 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.

Warning

Incremental snapshots requires the primary key to be stably ordered. However, String may not guarantees stable ordering as encodings and special characters can lead to unexpected behaviour (Mongo sort String). Please consider using other types for the primary key when performing incremental snapshots.

Incremental snapshots for sharded clusters

Incremental snapshots for sharded clusters is a Technology Preview feature for the Debezium MongoDB connector. Technology Preview features are not supported with Red Hat production service-level agreements (SLAs) and might not be functionally complete; therefore, Red Hat does not recommend implementing any Technology Preview features in production environments. This Technology Preview feature provides early access to upcoming product innovations, enabling you to test functionality and provide feedback during the development process. For more information about support scope, see Technology Preview Features Support Scope.

To use incremental snapshots with sharded MongoDB clusters, you must set specific values for the following properties:

Set mongodb.connection.mode to sharded.
Set incremental.snapshot.chunk.size to a value that is high enough to compensate for the increased complexity of change stream pipelines.

5.2.5.1. Triggering an incremental snapshot

Currently, the only way to initiate an incremental snapshot is to 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 kind of snapshot operation. Currently, the only valid option for snapshots operations is the default value, incremental.

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>}});

For example,

db.debeziumSignal.insert({ 1
"type" : "execute-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 command correspond to the fields of the signaling collection.

The following table describes the parameters in the example:

Table 5.2. 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 kind of snapshot operation to run. Currently, the only valid option is the default value, `incremental`. If you do not specify a value, the connector runs an incremental snapshot.

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",
    "transaction":null
}

Item	Field name	Description
1	`snapshot`	Specifies the type of snapshot operation to run. Currently, the only valid option is the default value, `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.

5.2.5.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 5.3. 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 next 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-condition`	N/A	An optional string that specifies a condition that the connector evaluates to designate a subset of columns to include in a snapshot.

An example of the execute-snapshot Kafka message:

Key = `test_connector`

Value = `{"type":"execute-snapshot","data": {"data-collections": ["schema1.table1", "schema1.table2"], "type": "INCREMENTAL"}}`

Ad hoc incremental snapshots with additional-condition

Debezium uses the additional-condition 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-condition, the additional-condition is appended to the SQL query, for example:

SELECT * FROM <tableName> WHERE <additional-condition> ….

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 append an additional-condition statement to filter the content:

Key = `test_connector`

Value = `{"type":"execute-snapshot","data": {"data-collections": ["schema1.products"], "type": "INCREMENTAL", "additional-condition":"color='blue'"}}`

You can use the additional-condition statement to pass conditions based on multiple columns. For example, using the same products collection as in the previous 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": ["schema1.products"], "type": "INCREMENTAL", "additional-condition":"color='blue' AND brand='MyBrand'"}}`

5.2.5.3. Stopping an incremental snapshot

You can also stop an incremental snapshot by sending a signal to the collection on the source database. You submit a stop snapshot signal by inserting a document into the to the signaling collection. After Debezium detects the change in the signaling collection, it reads the signal, and stops the incremental snapshot operation if it’s in progress.

The query that you submit specifies the snapshot operation of incremental, and, optionally, the collections of the current running snapshot to be removed.

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 5.4. 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 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. If this component of the `data` field is omitted, 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 kind 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.

5.2.5.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 5.5. 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 next 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 to include in the snapshot. Specify the names by using the same format as is required for the signal.data.collection configuration option.

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"}}`

5.2.6. 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.

5.2.7. 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.

5.2.8. 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.

5.2.9. 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.

5.2.10. 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\" : {\"$numberLong\" : \"1004\"},\"first_name\" : \"Anne\",\"last_name\" : \"Kretchmar\",\"email\" : \"annek@noanswer.org\"}",
  "source": {
...
  },
  "op": "c",
  "ts_ms": "1580390884335",
  "transaction": {
    "id": "1462833718356672513",
    "total_order": "1",
    "data_collection_order": "1"
  }
}

5.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 5.6. 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 previous `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 previous `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:

5.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 previous 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 5.7. 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 5.8. 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" : "{\"$oid\" : \"596e275826f08b2730779e1f\"}" }`
Binary	`BinData("a2Fma2E=",0)`	`{ "id" : "{\"$binary\" : \"a2Fma2E=\", \"$type\" : \"00\"}" }`

5.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

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": "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"
        }
      ],
      "optional": false,
      "name": "dbserver1.inventory.customers.Envelope" 4
      },
    "payload": { 5
      "after": "{\"_id\" : {\"$numberLong\" : \"1004\"},\"first_name\" : \"Anne\",\"last_name\" : \"Kretchmar\",\"email\" : \"annek@noanswer.org\"}", 6
      "source": { 7
        "version": "2.3.4.Final",
        "connector": "mongodb",
        "name": "fulfillment",
        "ts_ms": 1558965508000,
        "snapshot": false,
        "db": "inventory",
        "rs": "rs0",
        "collection": "customers",
        "ord": 31,
        "h": 1546547425148721999
      },
      "op": "c", 8
      "ts_ms": 1558965515240 9
    }
  }

Table 5.9. 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.

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
      "before":"{\"_id\": {\"$numberLong\": \"1004\"},\"first_name\": \"unknown\",\"last_name\": \"Kretchmar\",\"email\": \"annek@noanswer.org\"}", 3
      "after":"{\"_id\": {\"$numberLong\": \"1004\"},\"first_name\": \"Anne Marie\",\"last_name\": \"Kretchmar\",\"email\": \"annek@noanswer.org\"}", 4
      "updateDescription": {
        "removedFields": null,
        "updatedFields": "{\"first_name\": \"Anne Marie\"}", 5
        "truncatedArrays": null
      },
      "source": { 6
        "version": "2.3.4.Final",
        "connector": "mongodb",
        "name": "fulfillment",
        "ts_ms": 1558965508000,
        "snapshot": false,
        "db": "inventory",
        "rs": "rs0",
        "collection": "customers",
        "ord": 1,
        "h": null,
        "tord": null,
        "stxnid": null,
        "lsid":"{\"id\": {\"$binary\": \"FA7YEzXgQXSX9OxmzllH2w==\",\"$type\": \"04\"},\"uid\": {\"$binary\": \"47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=\",\"$type\": \"00\"}}",
        "txnNumber":1
      }
    }
  }

Table 5.10. 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`	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 an `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
      "before":"{\"_id\": {\"$numberLong\": \"1004\"},\"first_name\": \"Anne Marie\",\"last_name\": \"Kretchmar\",\"email\": \"annek@noanswer.org\"}",3
      "source": { 4
        "version": "2.3.4.Final",
        "connector": "mongodb",
        "name": "fulfillment",
        "ts_ms": 1558965508000,
        "snapshot": true,
        "db": "inventory",
        "rs": "rs0",
        "collection": "customers",
        "ord": 6,
        "h": 1546547425148721999
      }
    }
  }

Table 5.11. 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`	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 an `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.

5.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.

5.5. Deployment of Debezium MongoDB connectors

You can use either of the following methods to deploy a Debezium MongoDB connector:

Use AMQ Streams 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 5.5.5, “Descriptions of Debezium MongoDB connector configuration properties”

5.5.1. MongoDB connector deployment using AMQ Streams

Beginning with Debezium 1.7, the preferred method for deploying a Debezium connector is to use AMQ Streams 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 AMQ Streams 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 Service Registry artifacts, or the Debezium scripting component. When AMQ Streams 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 Using AMQ Streams on OpenShift.
Creating a new container image automatically using AMQ Streams in Deploying and Managing AMQ Streams on OpenShift.

5.5.2. Using AMQ Streams to deploy a Debezium MongoDB connector

With earlier versions of AMQ Streams, 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 AMQ Streams 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 AMQ Streams 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 AMQ Streams 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 AMQ Streams Operator is running.
An Apache Kafka cluster is deployed as documented in Deploying and Upgrading AMQ Streams on OpenShift.
Kafka Connect is deployed on AMQ Streams
You have a Red Hat Integration 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

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 5.1. 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 Service Registry archive. The Service Registry is an optional component. Add the Service 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.5.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.3.4.Final-redhat-00001/debezium-connector-mongodb-2.3.4.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.3.4.Final-redhat-00001/debezium-scripting-2.3.4.Final-redhat-00001.zip 9
          - type: jar
            url: https://repo1.maven.org/maven2/org/codehaus/groovy/groovy/3.0.11/groovy-3.0.11.jar  10
          - type: jar
            url: https://repo1.maven.org/maven2/org/codehaus/groovy/groovy-jsr223/3.0.11/groovy-jsr223-3.0.11.jar
          - type: jar
            url: https://repo1.maven.org/maven2/org/codehaus/groovy/groovy-json3.0.11/groovy-json-3.0.11.jar

  bootstrapServers: debezium-kafka-cluster-kafka-bootstrap:9093

  ...

Table 5.12. 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 AMQ Streams Build schema reference in Configuring AMQ Streams on OpenShift.
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 Service Registry component. Include the Service Registry artifact, only if you want the connector to use Apache Avro to serialize event keys and values with the Service 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 AMQ Streams 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 5.2. 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 5.13. 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 {context}-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.

5.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 AMQ Streams is deployed. AMQ Streams 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.
AMQ Streams is deployed on OpenShift and is running Apache Kafka and Kafka Connect. For more information, see Deploying and Upgrading AMQ Streams 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.3.4.Final-redhat-00001/debezium-connector-mongodb-2.3.4.Final-redhat-00001-plugin.zip \
&& unzip debezium-connector-mongodb-2.3.4.Final-redhat-00001-plugin.zip \
&& rm debezium-connector-mongodb-2.3.4.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 previous 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
```
1 1 1 1 1 1 1 1 1 1 1 1 1
The name that is used to register the connector with Kafka Connect.
2 2 2 2 2 2 2 2 2 2 2 2 2
The name of the MongoDB connector class.
3 3 3 3 3 3 3 3 3 3
The host addresses to use to connect to the MongoDB replica set.
4 4 4 4 4 4 4 4 4 4
The logical name of the MongoDB replica set, which forms a namespace for generated events 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.
5 5 5 5 5 5 5 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.

5.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 AMQ Streams 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:
1. Navigate to Home Search.
2. On the Search page, click Resources to open the Select Resource box, and then type KafkaConnector.
3. From the KafkaConnectors list, click the name of the connector that you want to check, for example inventory-connector-mongodb.
4. 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 5.3. 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.
1. Navigate to Home Search.
2. On the Search page, click Resources to open the Select Resource box, and then type KafkaTopic.
3. From the KafkaTopics list, click the name of the topic that you want to check, for example, inventory-connector-mongodb.inventory.orders---ac5e98ac6a5d91e04d8ec0dc9078a1ece439081d.
4. 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 5.4. KafkaTopic resource status

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

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 5.5. Content of a Debezium change event

{"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":"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":"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.3.4.Final-redhat-00001","connector":"mongodb","name":"inventory-connector-mongodb","ts_ms":1638985247805,"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,"transaction":null}}

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 previous value exists for the record. The "after" state shows a quantity of 3 for the item with product_id 101.

5.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:

The following configuration properties are required unless a default value is available.

Table 5.14. Required Debezium MongoDB 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.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 previous versions of the MongoDB connector. Note Connectors that capture changes from a sharded MongoDB cluster use this connection string only during the initial shard discovery process when `mongodb.connection.mode` is set to `replica_set`. After the initial discovery process, connection strings are generated for each individual shard.
`mongodb.connection.mode`	`replica_set`	Specifies the strategy that the connector uses when it connects to a `sharded` MongoDB cluster. Set this property to one of the following values: `replica_set` The connector establishes individual connections to the replica set for each shard. `sharded` The connector establishes a single connection to the database, based on the value of the `mongodb-connection-string`.+ Note The `replica_set` options allows the connector to distribute shard processing across multiple connector tasks. However, in this configuration, the connector bypasses the MongoDB router when it connects to individual shards, which is not recommended by MongoDB. Warning Switching between connection modes invalidates stored offsets, which triggers a new snapshot.
`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.user`	No default	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	Password to be used when connecting to MongoDB. This is required only when MongoDB is configured to use authentication.
`mongodb.authsource`	`admin`	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.
`database.include.list`	empty string	An optional comma-separated list of regular expressions 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 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.exclude.list`	empty string	An optional comma-separated list of regular expressions 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 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 set the `database.include.list` property.
`collection.include.list`	empty string	An optional comma-separated list of regular expressions 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 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. 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 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 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. If you include this property in the configuration, do not set the `collection.include.list` property.
`snapshot.mode`	`initial`	Specifies the criteria for performing a snapshot when the connector starts. Set the property to one of the following values: `initial` When the connector starts, if it does not detect a value in its offsets topic, it performs a snapshot of the database. `never` When the connector starts, it skips the snapshot process and immediately begins to stream change events for operations that the database records to the oplog.
`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. 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. `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.
`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.
`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 next field replacement is applied to the result of the previous field replacement in the list, so keep this in mind when renaming multiple fields that are in the same path.
`tasks.max`	`1`	Specifies the maximum number of tasks that the connector uses to connect to a sharded cluster. When you use the connector with a single MongoDB replica set, the default value is acceptable. But when a cluster contains multiple shards, to enable Kafka Connect to distribute the work for each replica set, specify a value that is equal to or greater than the number of shards in the cluster. The MongoDB connector can then use a separate task to connect to the replica set for each shard in the cluster. Note This property has an effect only when the connector is connected to a sharded MongoDB cluster and the `mongodb.connection.mode` property is set to `replica_set`. When the `mongodb.connection.mode` is set to `sharded`, or if the connector is connected to an unsharded MongoDB replica set deployment, the connector ignores this setting, and defaults to using only a single task.
`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.
`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.
`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.
`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.
`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.
`mongodb.hosts`	No default	The comma-separated list of hostname and port pairs (in the form 'host' or 'host:port') of the MongoDB servers in the replica set. The list can contain a single hostname and port pair. Note This property is deprecated and should be replaced by `+mongodb.connection.string`.

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 5.15. Debezium MongoDB connector advanced configuration properties
Property	Default	Description
`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.
`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.
`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 snapshots is a Technology Preview feature for the Debezium MongoDB connector.
`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`.
`errors.max.retries`	`-1`	The maximum number of retries on retriable errors (e.g. connection errors) before failing (-1 = no limit, 0 = disabled, > 0 = num of retries).

Debezium connector Kafka signals configuration properties

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 5.16. 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 host/port pairs that the connector uses for establishing an 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.

Debezium connector pass-through signals Kafka consumer client configuration properties

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.

Debezium connector sink notifications configuration properties

The following table describes the notification properties.

Table 5.17. 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.

5.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.

5.6.1. 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 shapshot 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.

5.6.2. 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 events that this connector has seen since the last start or metrics reset.
`TotalNumberOfCreateEventsSeen`	`long`	The total number of create events that this connector has seen since the last start or metrics reset.
`TotalNumberOfUpdateEventsSeen`	`long`	The total number of update events that this connector has seen since the last start or metrics reset.
`TotalNumberOfDeleteEventsSeen`	`long`	The total number of delete events that this connector has seen since the 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 incoporate 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.

5.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

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

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 previous 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 previous 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.

Chapter 5. Debezium connector for MongoDB

5.1. Overview of Debezium MongoDB connector

5.1.1. Description of how the MongoDB connector uses change streams to capture event records

5.2. How Debezium MongoDB connectors work

5.2.1. MongoDB topologies supported by Debezium connectors

5.2.2. How Debezium MongoDB connectors use logical names for replica sets and sharded clusters

5.2.3. How Debezium MongoDB connectors perform snapshots

5.2.4. Ad hoc snapshots

5.2.5. Incremental snapshots

5.2.5.1. Triggering an incremental snapshot

5.2.5.2. Using the Kafka signaling channel to trigger an incremental snapshot

5.2.5.3. Stopping an incremental snapshot

5.2.5.4. Using the Kafka signaling channel to stop an incremental snapshot

5.2.6. How the Debezium MongoDB connector streams change event records

5.2.7. MongoDB support for populating the `before` field in Debezium change event

5.2.8. Default names of Kafka topics that receive Debezium MongoDB change event records

5.2.9. How event keys control topic partitioning for the Debezium MongoDB connector

5.2.10. Debezium MongoDB connector-generated events that represent transaction boundaries

5.3. Descriptions of Debezium MongoDB connector data change events

5.3.1. About keys in Debezium MongoDB change events

5.3.2. About values in Debezium MongoDB change events

5.4. Setting up MongoDB to work with a Debezium connector

5.5. Deployment of Debezium MongoDB connectors

5.5.1. MongoDB connector deployment using AMQ Streams

5.5.2. Using AMQ Streams to deploy a Debezium MongoDB connector

5.5.3. Deploying a Debezium MongoDB connector by building a custom Kafka Connect container image from a Dockerfile

5.5.4. Verifying that the Debezium MongoDB connector is running

5.5.5. Descriptions of Debezium MongoDB connector configuration properties

5.6. Monitoring Debezium MongoDB connector performance

5.6.1. Monitoring Debezium during MongoDB snapshots

5.6.2. Monitoring Debezium MongoDB connector record streaming

5.7. How Debezium MongoDB connectors handle faults and problems

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

Making open source more inclusive

About Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links

Chapter 5. Debezium connector for MongoDB

5.1. Overview of Debezium MongoDB connector

5.1.1. Description of how the MongoDB connector uses change streams to capture event records

5.2. How Debezium MongoDB connectors work

5.2.1. MongoDB topologies supported by Debezium connectors

5.2.2. How Debezium MongoDB connectors use logical names for replica sets and sharded clusters

5.2.3. How Debezium MongoDB connectors perform snapshots

5.2.4. Ad hoc snapshots

5.2.5. Incremental snapshots

5.2.5.1. Triggering an incremental snapshot

5.2.5.2. Using the Kafka signaling channel to trigger an incremental snapshot

5.2.5.3. Stopping an incremental snapshot

5.2.5.4. Using the Kafka signaling channel to stop an incremental snapshot

5.2.6. How the Debezium MongoDB connector streams change event records

5.2.7. MongoDB support for populating the before field in Debezium change event

5.2.8. Default names of Kafka topics that receive Debezium MongoDB change event records

5.2.9. How event keys control topic partitioning for the Debezium MongoDB connector

5.2.10. Debezium MongoDB connector-generated events that represent transaction boundaries

5.3. Descriptions of Debezium MongoDB connector data change events

5.3.1. About keys in Debezium MongoDB change events

5.3.2. About values in Debezium MongoDB change events

5.4. Setting up MongoDB to work with a Debezium connector

5.5. Deployment of Debezium MongoDB connectors

5.5.1. MongoDB connector deployment using AMQ Streams

5.5.2. Using AMQ Streams to deploy a Debezium MongoDB connector

5.5.3. Deploying a Debezium MongoDB connector by building a custom Kafka Connect container image from a Dockerfile

5.5.4. Verifying that the Debezium MongoDB connector is running

5.5.5. Descriptions of Debezium MongoDB connector configuration properties

5.6. Monitoring Debezium MongoDB connector performance

5.6.1. Monitoring Debezium during MongoDB snapshots

5.6.2. Monitoring Debezium MongoDB connector record streaming

5.7. How Debezium MongoDB connectors handle faults and problems

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

Making open source more inclusive

About Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links

5.2.7. MongoDB support for populating the `before` field in Debezium change event