anchor.diff:  ====
   
   [[mongodb-sharded-cluster]]
  -=== MongoDB sharded cluster
  -
  +MongoDB sharded cluster::
   A https://docs.mongodb.com/manual/sharding/[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, 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]]
  -=== MongoDB standalone server
  -
  +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 https://docs.mongodb.com/manual/core/replica-set-architectures/[does not recommend] running a standalone server in production.
  -====
  -
  -[[how-the-mongodb-connector-works]]
  -== How the MongoDB connector works
  -
  -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.
  -====
  -
  +MongoDB does not recommend running a standalone server in production.
  +For more information, see the https://docs.mongodb.com/manual/core/replica-set-architectures/[MongoDB documentation].
  +====
  +
  +// Type: concept
  +// Title: How {prodname} MongoDB connectors use logical names for replica sets and sharded clusters
  +// ModuleID: how-debezium-mongodb-connectors-use-logical-names-for-replica-sets-and-sharded-clusters
   [[mongodb-logical-connector-name]]
   === Logical connector name
   
  
positive.code: * <<mongodb-delete-events,_delete_ events>>
  
  [id="mongodb-create-events"]
  ==== _create_ events
  
  The following example shows the value portion of a change event that the connector generates for an operation that creates data in the `customers` collection:
  
  
negative.code: You can set up Kafka to {link-kafka-docs}.html#basic_ops_add_topic[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.
  
  // Type: concept
  // ModuleID: how-event-keys-control-topic-partitioning-for-the-debezium-mongodb-connector
  // Title: How event keys control topic partitioning for the {prodname} MongoDB connector
  [[mongodb-partitions]]
  === Partitions
  
  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.
  
  
  // Type: concept
  // ModuleID: debezium-mongodb-connector-generated-events-that-represent-transaction-boundaries
  // Title: {prodname} MongoDB connector-generated events that represent transaction boundaries
  [[mongodb-transaction-metadata]]
  === Transaction Metadata
  
  {prodname} can generate events that represents transaction metadata boundaries and enrich change data event messages.
  For every transaction `BEGIN` and `END`, {prodname} 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:
  
  [source,json,indent=0,subs="+attributes"]
  ----
  {
    "status": "BEGIN",
    "id": "1462833718356672513",
    "event_count": null,
    "data_collections": null
  }
  
  {
    "status": "END",
    "id": "1462833718356672513",
    "event_count": 2,
    "data_collections": [
      {
        "data_collection": "rs0.testDB.tablea",
        "event_count": 1
      },
      {
        "data_collection": "rs0.testDB.tableb",
        "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:
  
  [source,json,indent=0,subs="+attributes"]
  ----
  {
    "before": null,
    "after": {
      "pk": "2",
      "aa": "1"
    },
    "source": {
  ...
    },
    "op": "c",
    "ts_ms": "1580390884335",
    "transaction": {
      "id": "1462833718356672513",
      "total_order": "1",
      "data_collection_order": "1"
    }
  }
  ----
  
  // Type: assembly
  // ModuleID: descriptions-of-debezium-mongodb-connector-data-change-events
  // Title: Descriptions of {prodname} MongoDB connector data change events
  [[mongodb-events]]
  == Data change events
  
  The {prodname} 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.
  
  