Chapter 4. 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.
Information and procedures for using a Debezium MongoDB connector is organized as follows:
- Section 4.1, “Overview of Debezium MongoDB connector”
- Section 4.2, “How Debezium MongoDB connectors work”
- Section 4.3, “Descriptions of Debezium MongoDB connector data change events”
- Section 4.4, “Setting up MongoDB to work with a Debezium connector”
- Section 4.5, “Deployment of Debezium MongoDB connectors”
- Section 4.6, “Monitoring Debezium MongoDB connector performance”
- Section 4.7, “How Debezium MongoDB connectors handle faults and problems”
4.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.
The MongoDB connector uses this same replication mechanism, though it does not actually become a member of the replica set. Just like MongoDB secondaries, however, the connector always reads the oplog of the replica set’s primary. And, when the connector sees a replica set for the first time, it looks at the oplog to get the last recorded transaction and then performs a snapshot of the primary’s databases and collections. When all the data is copied, the connector then starts streaming changes from the position it read earlier from the oplog. Operations in the MongoDB oplog are idempotent, so no matter how many times the operations are applied, they result in the same end state.
As the MongoDB connector processes changes, it periodically records the position in the oplog where the event originated. When the MongoDB connector stops, it records the last oplog position that it processed, so that upon restart it simply begins streaming from that position. In other words, the connector can be stopped, upgraded or maintained, and restarted some time later, and it will pick up exactly where it left off without losing a single event. Of course, MongoDB’s oplogs are usually capped at a maximum size, which means that the connector should not be stopped for too long, or else some of the operations in the oplog might be purged before the connector has a chance to read them. In this case, upon restart the connector will detect the missing oplog operations, perform a snapshot, and then proceed with streaming the 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. Likewise, if connector experiences any problems communicating with the replica set primary, it will try to reconnect (using exponential backoff so as to not overwhelm the network or replica set) and continue 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 to automatically handle communication failures.
Additional resources
4.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.
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:
- Section 4.2.1, “MongoDB topologies supported by Debezium connectors”
- Section 4.2.2, “How Debezium MongoDB connectors use logical names for replica sets and sharded clusters”
- Section 4.2.3, “How Debezium MongoDB connectors perform snapshots”
- Section 4.2.4, “How the Debezium MongoDB connector streams change event records”
- Section 4.2.5, “Default names of Kafka topics that receive Debezium MongoDB change event records”
- Section 4.2.6, “How event keys control topic partitioning for the Debezium MongoDB connector”
- Section 4.2.7, “Debezium MongoDB connector-generated events that represent transaction boundaries”
4.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, provide the addresses of one or more replica set servers as seed addresses through the connector’s
mongodb.hostsproperty. The connector will use these seeds to connect to the replica set, and then once connected will get from the replica set the complete set of members and which member is primary. The connector will start a task to connect to the primary and capture the changes from the primary’s oplog. When the replica set elects a new primary, the task will automatically switch over to the new primary.NoteWhen MongoDB is fronted by a proxy (such as with Docker on OS X or Windows), then when a client connects to the replica set and discovers the members, the MongoDB client will exclude the proxy as a valid member and will attempt and fail to connect directly to the members rather than go through the proxy.
In such a case, set the connector’s optional
mongodb.members.auto.discoverconfiguration property tofalseto instruct the connector to forgo membership discovery and instead simply use the first seed address (specified via themongodb.hostsproperty) as the primary node. This may work, but still make cause issues when election occurs.
- 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 shardsTo use the MongoDB connector with a sharded cluster, configure the connector with the host addresses of the configuration server replica set. When the connector connects to this replica set, it discovers that it is acting as the configuration server for a sharded cluster, discovers the information about each replica set used as a shard in the cluster, and will then start up a separate task to capture the changes from each replica set. If new shards are added to the cluster or existing shards removed, the connector will automatically adjust its tasks accordingly.
- 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.
MongoDB does not recommend running a standalone server in production. For more information, see the MongoDB documentation.
4.2.2. How Debezium MongoDB connectors use logical names for replica sets and sharded clusters
The connector configuration property mongodb.name 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 oplog position of each replica set.
Assign a unique logical name to each MongoDB connector. The name should meaningfully describe the source MongoDB system. It’s best to assign logical names that begin with an alphabetic or underscore character and that include only alphanumeric or underscore characters.
4.2.3. How Debezium MongoDB connectors perform snapshots
When a task starts up using 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 will then proceed 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 will record a separate read event for each document it sees, and that read event will contain 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 will also include a flag that denotes 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.
Try to avoid task reassignment and reconfiguration while the connector is performing a snapshot of any replica sets. The connector does log messages with the progress of the snapshot. For utmost control, run a separate cluster of Kafka Connect for each connector.
4.2.4. 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 connects to the replica set’s primary node and start 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.
Under normal operating conditions, Kafka consumers read every message exactly once. However, if an error occurs, Kafka guarantees only that consumers see every message at least once. Therefore, your consumers need to anticipate seeing messages more than once.
As mentioned above, 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.
4.2.5. 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 mongodb.name 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.
4.2.6. 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.
4.2.7. Debezium MongoDB connector-generated events that represent transaction boundaries
Debezium can generate events that represents transaction metadata boundaries and enrich change data event messages. For every transaction BEGIN and END, Debezium generates an event that contains the following fields:
status-
BEGINorEND id- String representation of unique transaction identifier.
event_count(forENDevents)- Total number of events emitted by the transaction.
data_collections(forENDevents)-
An array of pairs of
data_collectionandevent_countthat 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
}
]
}
The transaction events are written to the topic named <database.server.name>.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:
{
"before": null,
"after": {
"pk": "2",
"aa": "1"
},
"source": {
...
},
"op": "c",
"ts_ms": "1580390884335",
"transaction": {
"id": "1462833718356672513",
"total_order": "1",
"data_collection_order": "1"
}
}4.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
...
},
}| Item | Field name | Description |
|---|---|---|
| 1 |
|
The first |
| 2 |
|
The first |
| 3 |
|
The second |
| 4 |
|
The second |
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.
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:
4.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"
}
}| Item | Field name | Description |
|---|---|---|
| 1 |
|
The schema portion of the key specifies a Kafka Connect schema that describes what is in the key’s |
| 2 |
|
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.
|
| 3 |
|
Indicates whether the event key must contain a value in its |
| 4 |
|
Specifies each field that is expected in the |
| 5 |
|
Contains the key for the document for which this change event was generated. In this example, the key contains a single |
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.
| Type | MongoDB _id Value | Key’s payload |
|---|---|---|
| Integer | 1234 |
|
| Float | 12.34 |
|
| String | "1234" |
|
| Document |
|
|
| ObjectId |
|
|
| Binary |
|
|
4.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": "string",
"optional": true,
"name": "io.debezium.data.Json",
"version": 1,
"field": "filter"
},
{
"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
"patch": null,
"source": { 7
"version": "1.5.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
}
}| Item | Field name | Description |
|---|---|---|
| 1 |
| 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 |
|
In the |
| 3 |
|
|
| 4 |
|
|
| 5 |
|
The value’s actual data. This is the information that the change event is providing. |
| 6 |
|
An optional field that specifies the state of the document after the event occurred. In this example, the |
| 7 |
| 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:
|
| 8 |
|
Mandatory string that describes the type of operation that caused the connector to generate the event. In this example,
|
| 9 |
|
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. |
update events
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 does not have an after value. Instead, it has these two fields:
-
patchis a string field that contains the JSON representation of the idempotent update operation -
filteris a string field that contains the JSON representation of the selection criteria for the update. Thefilterstring can include multiple shard key fields for sharded collections.
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
"patch": "{\"$set\":{\"first_name\":\"Anne Marie\"}}", 3
"filter": "{\"_id\" : {\"$numberLong\" : \"1004\"}}", 4
"source": { 5
"version": "1.5.4.Final",
"connector": "mongodb",
"name": "fulfillment",
"ts_ms": 1558965508000,
"snapshot": true,
"db": "inventory",
"rs": "rs0",
"collection": "customers",
"ord": 6,
"h": 1546547425148721999
}
}
}| Item | Field name | Description |
|---|---|---|
| 1 |
|
Mandatory string that describes the type of operation that caused the connector to generate the event. In this example, |
| 2 |
|
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. |
| 3 |
|
Contains the JSON string representation of the actual MongoDB idempotent change to the document. In this example, the update changed the |
| 4 |
| Contains the JSON string representation of the MongoDB selection criteria that was used to identify the document to be updated. |
| 5 |
| 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:
|
In a Debezium change event, MongoDB provides the content of the patch field. The format of this field depends on the version of the MongoDB database. Consequently, be prepared for potential changes to the format when you upgrade to a newer MongoDB database version. Examples in this document were obtained from MongoDB 3.4, In your application, event formats might be different.
In MongoDB’s oplog, update events do not contain the before or after states of the changed document. Consequently, it is not possible for a Debezium connector to provide this information. However, a Debezium connector provides a document’s starting state in create and read events. Downstream consumers of the stream can reconstruct document state by keeping the latest state for each document and comparing the state in a new event with the saved state. Debezium connector’s are not able to keep this state.
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 patch 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
"filter": "{\"_id\" : {\"$numberLong\" : \"1004\"}}", 3
"source": { 4
"version": "1.5.4.Final",
"connector": "mongodb",
"name": "fulfillment",
"ts_ms": 1558965508000,
"snapshot": true,
"db": "inventory",
"rs": "rs0",
"collection": "customers",
"ord": 6,
"h": 1546547425148721999
}
}
}| Item | Field name | Description |
|---|---|---|
| 1 |
|
Mandatory string that describes the type of operation. The |
| 2 |
|
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. |
| 3 |
| Contains the JSON string representation of the MongoDB selection criteria that was used to identify the document to be deleted. |
| 4 |
| 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:
|
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.
4.4. Setting up MongoDB to work with a Debezium connector
The MongoDB connector uses MongoDB’s oplog 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.
4.5. Deployment of Debezium MongoDB connectors
To deploy a Debezium MongoDB connector, add the connector files to Kafka Connect, create a custom container to run the connector, and add the connector configuration to your container. Details are in the following topics:
4.5.1. Deploying Debezium MongoDB connectors
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
KafkaConnectCR that defines your Kafka Connect instance. Theimageproperty 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
KafkaConnectorCR that defines your Debezium MongoDB connector. Apply this CR to the same OpenShift instance where you apply theKafkaConnectCR.
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.ioordocker.io) to which you plan to add the container that will run your Debezium connector.
Procedure
Create the Debezium MongoDB container for Kafka Connect:
- Download the Debezium MongoDB connector archive.
Extract the Debezium MongoDB connector archive to create a directory structure for the connector plug-in, for example:
./my-plugins/ ├── debezium-connector-mongodb │ ├── ...
Create a Docker file that uses
registry.redhat.io/amq7/amq-streams-kafka-28-rhel8:1.8.0as the base image. For example, from a terminal window, enter the following, replacingmy-pluginswith the name of your plug-ins directory:cat <<EOF >debezium-container-for-mongodb.yaml 1 FROM registry.redhat.io/amq7/amq-streams-kafka-28-rhel8:1.8.0 USER root:root COPY ./<my-plugins>/ /opt/kafka/plugins/ 2 USER 1001 EOF
The command creates a Docker file with the name
debezium-container-for-mongodb.yamlin the current directory.Build the container image from the
debezium-container-for-mongodb.yamlDocker 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.ioor 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:latestdocker push <myregistry.io>/debezium-container-for-mongodb:latestCreate a new Debezium MongoDB
KafkaConnectcustom resource (CR). For example, create aKafkaConnectCR with the namedbz-connect.yamlthat specifiesannotationsandimageproperties as shown in the following example: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- 1
metadata.annotationsindicates to the Cluster Operator thatKafkaConnectorresources are used to configure connectors in this Kafka Connect cluster.- 2
spec.imagespecifies the name of the image that you created to run your Debezium connector. This property overrides theSTRIMZI_DEFAULT_KAFKA_CONNECT_IMAGEvariable in the Cluster Operator.
Apply the
KafkaConnectCR 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
KafkaConnectorcustom resource that configures your Debezium MongoDB connector instance.You configure a Debezium MongoDB connector in a
.yamlfile 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
rs0at port27017on192.168.99.100, and captures changes that occur in theinventorycollection.fullfillmentis the logical name of the replica set.MongoDB
inventory-connector.yamlapiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: inventory-connector 1 labels: strimzi.io/cluster: my-connect-cluster spec: class: io.debezium.connector.mongodb.MongoDbConnector 2 config: mongodb.hosts: rs0/192.168.99.100:27017 3 mongodb.name: fulfillment 4 collection.include.list: inventory[.]* 5- 1
- The name that is used to register the connector with Kafka Connect.
- 2
- The name of the MongoDB connector class.
- 3
- The host addresses to use to connect to the MongoDB replica set.
- 4
- The logical name of the MongoDB replica set, 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
- 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
KafkaConnectorresource in theinventory-connector.yamlfile, you would run the following command:oc apply -f inventory-connector.yaml
The preceding command registers
inventory-connectorand the connector starts to run against theinventorycollection as defined in theKafkaConnectorCR.Verify that the connector was created and has started:
Display the Kafka Connect log output to verify that the connector was created and has started to capture changes in the specified database:
oc logs $(oc get pods -o name -l strimzi.io/cluster=my-connect-cluster)
Review the log output to verify that Debezium performs the initial snapshot. The log displays output that is similar to the following messages:
... INFO Starting snapshot for ... ... INFO Snapshot is using user 'debezium' ...
If the connector starts correctly without errors, it creates a topic for each collection from which the connector captures changes. For the CR in the preceding example, there would be a topic for the collection specified in the
collection.include.listproperty. Downstream applications can subscribe to the topics that the connector creates.Verify that the connector created topics by running the following command:
oc get kafkatopics
For the complete list of the configuration properties that you can set for the Debezium MongoDB connector, see MongoDB connector configuration properties.
Results
When the connector starts, it completes the following actions:
- Performs a consistent snapshot of the collections in your MongoDB replica sets.
- Reads the oplogs for the replica sets.
- Produces change events for every inserted, updated, and deleted document.
- Streams change event records to Kafka topics.
4.5.2. Description of Debezium Db2 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.
| Property | Default | Description |
|---|---|---|
| Unique name for the connector. Attempting to register again with the same name will fail. (This property is required by all Kafka Connect connectors.) | ||
|
The name of the Java class for the connector. Always use a value of | ||
|
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. If | ||
| 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. Only alphanumeric characters and underscores should be used. | ||
| Name of the database user to be used when connecting to MongoDB. This is required only when MongoDB is configured to use authentication. | ||
| Password to be used when connecting to MongoDB. This is required only when MongoDB is configured to use authentication. | ||
|
|
Database (authentication source) containing MongoDB credentials. This is required only when MongoDB is configured to use authentication with another authentication database than | |
|
| Connector will use SSL to connect to MongoDB instances. | |
|
|
When SSL is enabled this setting controls whether strict hostname checking is disabled during connection phase. If | |
| empty string |
An optional comma-separated list of regular expressions that match database names to be monitored; any database name not included in | |
| empty string |
An optional comma-separated list of regular expressions that match database names to be excluded from monitoring; any database name not included in | |
| empty string |
An optional comma-separated list of regular expressions that match fully-qualified namespaces for MongoDB collections to be monitored; any collection not included in | |
| empty string |
An optional comma-separated list of regular expressions that match fully-qualified namespaces for MongoDB collections to be excluded from monitoring; any collection not included in | |
|
| Specifies the criteria for running a snapshot upon startup of the connector. The default is initial, and specifies the connector reads a snapshot when either no offset is found or if the oplog no longer contains the previous offset. The never option specifies that the connector should never use snapshots, instead the connector should proceed to tail the log. | |
|
All collections specified in |
An optional, comma-separated list of regular expressions that match names of schemas specified in | |
| 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. | |
| 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. | |
|
| The maximum number of tasks that should be created for this connector. The MongoDB connector will attempt to use a separate task for each replica set, so the default is acceptable when using the connector with a single MongoDB replica set. When using the connector with a MongoDB sharded cluster, we recommend specifying a value that is equal to or more than the number of shards in the cluster, so that the work for each replica set can be distributed by Kafka Connect. | |
|
| 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. | |
|
|
Controls whether a delete event is followed by a tombstone event. | |
|
An interval in milliseconds that the connector should wait before taking a snapshot after starting up; | ||
|
|
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. |
The following advanced configuration properties have good defaults that will work in most situations and therefore rarely need to be specified in the connector’s configuration.
| Property | Default | Description |
|---|---|---|
|
|
Positive integer value that specifies the maximum size of the blocking queue into which change events read from the database log are placed before they are written to Kafka. This queue can provide backpressure to the oplog reader when, for example, writes to Kafka are slower or if Kafka is not available. Events that appear in the queue are not included in the offsets periodically recorded by this connector. Defaults to 8192, and should always be larger than the maximum batch size specified in the | |
|
| 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. | |
|
| Long value for the maximum size in bytes of the blocking queue. The feature is disabled by default, it will be active if it’s set with a positive long value. | |
|
| Positive integer value that specifies the number of milliseconds the connector should wait during each iteration for new change events to appear. Defaults to 1000 milliseconds, or 1 second. | |
|
| 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). | |
|
| 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). | |
|
|
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 | |
|
|
Boolean value that specifies whether the addresses in 'mongodb.hosts' are seeds that should be used to discover all members of the cluster or replica set ( | |
|
|
Controls how frequently heartbeat messages are sent.
Set this parameter to | |
|
|
Controls the naming of the topic to which heartbeat messages are sent. | |
|
| Whether field names are sanitized to adhere to Avro naming requirements. | |
|
comma-separated list of oplog operations that will be skipped during streaming. The operations include: | ||
| 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: | ||
|
|
When set to See Transaction Metadata for additional details. | |
| 10000 (10 seconds) | The number of milliseconds to wait before restarting a connector after a retriable error occurs. | |
|
| The interval in which the connector polls for new, removed, or changed replica sets. | |
| 10000 (10 seconds) | The number of milliseconds the driver will wait before a new connection attempt is aborted. | |
| 0 |
The number of milliseconds before a send/receive on the socket can take before a timeout occurs. A value of | |
| 30000 (30 seconds) | The number of milliseconds the driver will wait to select a server before it times out and throws an error. |
4.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.
4.6.1. Monitoring Debezium during MongoDB snapshots
The MBean is debezium.mongodb:type=connector-metrics,context=snapshot,server=<mongodb.name>.
| Attributes | Type | Description |
|---|---|---|
|
| The last snapshot event that the connector has read. | |
|
| The number of milliseconds since the connector has read and processed the most recent event. | |
|
| The total number of events that this connector has seen since last started or reset. | |
|
| The number of events that have been filtered by include/exclude list filtering rules configured on the connector. | |
|
| The list of tables that are monitored by the connector. | |
|
| The length the queue used to pass events between the snapshotter and the main Kafka Connect loop. | |
|
| The free capacity of the queue used to pass events between the snapshotter and the main Kafka Connect loop. | |
|
| The total number of tables that are being included in the snapshot. | |
|
| The number of tables that the snapshot has yet to copy. | |
|
| Whether the snapshot was started. | |
|
| Whether the snapshot was aborted. | |
|
| Whether the snapshot completed. | |
|
| The total number of seconds that the snapshot has taken so far, even if not complete. | |
|
| 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. | |
|
|
The maximum buffer of the queue in bytes. It will be enabled if | |
|
| The current data of records in the queue in bytes. |
The Debezium MongoDB connector also provides the following custom snapshot metrics:
| Attribute | Type | Description |
|---|---|---|
|
|
| Number of database disconnects. |
4.6.2. Monitoring Debezium MongoDB connector record streaming
The MBean is debezium.sql_server:type=connector-metrics,context=streaming,server=<mongodb.name>.
| Attributes | Type | Description |
|---|---|---|
|
| The last streaming event that the connector has read. | |
|
| The number of milliseconds since the connector has read and processed the most recent event. | |
|
| The total number of events that this connector has seen since last started or reset. | |
|
| The number of events that have been filtered by include/exclude list filtering rules configured on the connector. | |
|
| The list of tables that are monitored by the connector. | |
|
| The length the queue used to pass events between the streamer and the main Kafka Connect loop. | |
|
| The free capacity of the queue used to pass events between the streamer and the main Kafka Connect loop. | |
|
| Flag that denotes whether the connector is currently connected to the database server. | |
|
| 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. | |
|
| The number of processed transactions that were committed. | |
|
| The coordinates of the last received event. | |
|
| Transaction identifier of the last processed transaction. | |
|
| The maximum buffer of the queue in bytes. | |
|
| The current data of records in the queue in bytes. |
The Debezium MongoDB connector also provides the following custom streaming metrics:
| Attribute | Type | Description |
|---|---|---|
|
|
| Number of database disconnects. |
|
|
| Number of primary node elections. |
4.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.
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.
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.
Connector is stopped for a long interval
If the connector is gracefully stopped, the replica sets can continue to be used and any new changes are recorded in MongoDB’s oplog. When the connector is restarted, it will resume streaming changes for each replica set where it last left off, recording change events for all of the changes that were made while the connector was stopped. If the connector is stopped long enough such that MongoDB purges from its oplog some operations that the connector has not read, then upon startup the connector will perform a snapshot.
A properly configured Kafka cluster is capable of massive throughput. Kafka Connect is written with Kafka best practices, and given enough resources will also be able to handle very large numbers of database change events. Because of this, when a connector has been restarted after a while, it is very likely to catch up with the database, though how quickly will depend upon the capabilities and performance of Kafka and the volume of changes being made to the data in MongoDB.
If the connector remains stopped for long enough, MongoDB might purge older oplog files and the connector’s last position may be lost. In this case, when the connector configured with initial snapshot mode (the default) is finally restarted, the MongoDB server will no longer have the starting point and the connector will fail with an error.
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.
