anchor.diff:  |Default
   |Description
   
  -|`max.batch.size` 
  +|`max.batch.size`
   |`2048`
   |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 2048, and should always be larger than the maximum queue size specified in the `max.queue.size` property.
   
  -|`max.queue.size` 
  +|`max.queue.size`
   |`1024`
   |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 1024.
   
  -|`poll.interval.ms` 
  +|`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 1000 milliseconds, or 1 second.
   
  -|`connect.backoff.initial.delay.ms` 
  +|`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` 
  +|`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` 
  +|`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.
   
  -|`mongodb.members.auto.discover` 
  +|`mongodb.members.auto.discover`
   |`true`
   |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 (`true`), or whether the address(es) in `mongodb.hosts` should be used as is (`false`). The default is `true` and should be used in all cases except where MongoDB is link:#mongodb-replicaset[fronted by a proxy].
   
  
positive.code: 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_; and 
  * one or more _routers_ (also called `mongos`) to which clients connect and that routes requests to the appropriate shards
  
  To use the Debezium 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.
  
negative.code: 
  [TIP]
  ====
  Try to avoid task reassignment and reconfigurations while the connector is performing an intial sync of any replica sets. The connector does log messages with the progress of the initial sync. For utmost control, run a separate cluster of Kafka Connect for each connector.
  ====
  
  [[tailing-the-oplog]]
  