anchor.diff:  === Connector is stopped for a duration
   
   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 reading the oplog 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 an initial sync.
  +When the connector is restarted, it will resume reading the oplog 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 https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines[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.
  
positive.code: When the MongoDB connector stops, it records the last oplog position that it processed, so that upon restart it simply begins reading the oplog 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 an initial sync, and then proceed to tail the oplog.
  
  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 tail the oplog, so when the replica set undergoes an election and a different node becomes primary, the connector will immediately stop tailing the oplog, connect to the new primary, and start tailing the oplog using the new primary node.
  
negative.code: 
  See the link:#mongodb-connector-properties[complete list of connector properties] that can be specified in these configurations.
  
  This configuration can be sent via POST to a running Kafka Connect service, which will then record the configuration and start up the one connector task that will connect to the MongoDB replica set or sharded cluster, assign tasks for each replica set, perform a snapshot if necessary, read the oplog, and record events to Kafka topics.
  
  [[mongodb-connector-monitoring]]
  === Monitoring
  
  Kafka, Zookeeper, and Kafka Connect all have built-in support for JMX metrics.
  The MongoDB connector also publishes a number of metrics about the connector's activities that can be monitored through JMX.
  The connector has two types of metrics.
  Snapshot metrics help you monitor the snapshot activity and are available when the connector is performing a snapshot.
  Streaming metrics help you monitor the progress and activity while the connector reads CDC collection changes.
  
  [[monitoring-snapshots]]
  [[snapshot-metrics]]
  ==== Snapshot Metrics
  
  ===== *MBean: debezium.mongodb:type=connector-metrics,context=snapshot,server=_<mongodb.name>_*
  
  [cols="30%a,10%a,60%a",options="header"]
  |=======================
  |Attribute Name
  |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 whitelist or blacklist filtering rules configured on the connector.
  
  |`MonitoredTables`
  |`string[]`
  |The list of collections that are monitored by the connector.
  
  |`QueueTotalCapcity`
  |`int`
  |The length of the queue used to pass events between the snapshotter and the main Kafka Connect loop.
  
  |`QueueRemainingCapcity`
  |`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 collections that are being included in the snapshot.
  
  |`RemainingTableCount`
  |`int`
  |The number of collections that the snapshot has yet to copy.
  
  |`SnapshotRunning`
  |`boolean`
  |Whether the snapshot was started.
  
  |`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.
  
  |`RowsScanned`
  |`Map<String, Long>`
  |Map containing the number of documents exported for each collection in the snapshot. Collections are incrementally added to the Map during processing. Updates every 10,000 documents scanned and upon completing a collection.
  
  |=======================
  
  
  [[monitoring-streaming]]
  [[streaming-metrics]]
  ==== Streaming Metrics
  
  ===== *MBean: debezium.sql_server:type=connector-metrics,context=streaming,server=_<mongodb.name>_*
  
  [cols="30%a,10%a,60%a",options="header"]
  |=======================
  |Attribute Name
  |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 last started or reset.
  
  |`NumberOfEventsFiltered`
  |`long`
  |The number of events that have been filtered by whitelist or blacklist filtering rules configured on the connector.
  
  |`MonitoredTables`
  |`string[]`
  |The list of collections that are monitored by the connector.
  
  |`QueueTotalCapcity`
  |`int`
  |The length of the queue used to pass events between the streamer and the main Kafka Connect loop.
  
  |`QueueRemainingCapcity`
  |`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 mongodb.
  
  |`MilliSecondsBehindSource`
  |`long`
  |The number of milliseconds between the last change event's timestamp and the connector processing it. The values will incorporate any differences between the clocks on the machines where the database server and the connector are running.
  
  |`NumberOfCommittedTransactions`
  |`long`
  |The number of processed transactions that were committed.
  
  |`SourceEventPosition`
  |`map<string, string>`
  |The coordinates of the last received event.
  
  |`LastTransactionId`
  |`string`
  |Transaction identifier of the last processed transaction.
  
  |=======================
  
  [[mongodb-connector-properties]]
  === Connector properties
  