anchor.diff:  
   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 https://docs.mongodb.com/manual/core/replica-set-sync/[initial sync] 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 initial sync.
  +When a new server is added to a replica set, that server first performs an https://docs.mongodb.com/manual/core/replica-set-sync/[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.
  
positive.code: You should give each MongoDB connector a unique logical name that meaningfully describes the source MongoDB system.
  We recommend logical names begin with an alphabetic or underscore character, and remaining characters that are alphanumeric or underscore.
  
  [[initial-sync]]
  === Initial sync
  
  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 in the replica sets oplog where the connector previously stopped reading.
  If an offset can be found and it is still in the oplog, then the task immediately proceeds with link:#tailing-the-oplog[tailing the oplog], 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 an _initial sync_.
  This process starts by recording the current position of the oplog and recording that as the offset (along with a flag that denotes an initial sync has been started).
  The task will then proceed to copy each collection, spawning as many threads as possible (up to the value of the `initial.sync.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 an initial sync.
  
  This initial sync will continue until it has copied all collections that match the connector's filters.
  If the connector is stopped before the tasks' initial syncs are completed, upon restart the connector begins the initial sync again.
  
  [NOTE]
  ====
  Try to avoid task reassignment and reconfiguration 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]]
  
negative.code: === Example configuration
  
  To use the connector to produce change events for a particular MongoDB replica set or sharded cluster, create a configuration file in JSON.
  When the connector starts, it will perform a snapshot of the collections in your MongoDB replica sets and start reading the replica sets' oplogs, producing events for every inserted, updated, and deleted row.
  Optionally filter out collections that are not needed.
  
  Here is an example of the configuration for a MongoDB connector that monitors a MongoDB replica set `rs0` at port 27017 on 192.168.99.100, which we logically name `fullfillment`:
  