anchor.diff:  
   [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. 
  +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]]
  
positive.code:         "rs": "rs0",
          "ns": "inventory.customers"
          sec" : 1465495462,
          "ord" : 6, 
          "h" : -7633416138502997855
        }
      }
  
negative.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.
  