anchor.diff:  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.
   
  -MongoDB connector supports two distinct modes of capturing the changes controlled by the xref:mongodb-property-capture-mode[`capture.mode`] option:
  -
  -* oplog based
  -* change streams based
  -
  -'''
  -
  -=== Oplog capture mode (legacy)
  -
  -The {prodname} MongoDB connector uses the same replication mechanism as described above, though it does not actually become a member of the replica set.
  -Just like MongoDB secondaries, however, the connector always reads the oplog of the replica set's primary.
  -And, when the connector sees a replica set for the first time, it looks at the oplog to get the last recorded transaction and then performs a snapshot of the primary's databases and collections.
  -When all the data is copied, the connector then starts streaming changes from the position it read earlier from the oplog. Operations in the MongoDB oplog are https://docs.mongodb.com/manual/core/replica-set-oplog/[idempotent], so no matter how many times the operations are applied, they result in the same end state.
  -
  -The disadvantage of this mode is that only _insert_ change events will contain the full document, whereas _update_ events only contain a representation of changed fields (i.e. unmodified fields cannot be obtained from an _update_ event), and _delete_ events contain no representation of the deleted document apart from its key.
  -
  -This mode should be considered as the legacy one.
  -It is not supported on MongoDB 5 and the user is strongly advised to not use it for MongoDB 4.x server.
  -
  -=== Change Stream mode
  +=== Change Stream
   
   The {prodname} MongoDB connector uses a similar replication mechanism to the one described above, though it does not actually become a member of the replica set.
   The main difference is that the connector does not read the oplog directly, but delegates capturing and decoding the oplog to MongoDB's https://docs.mongodb.com/manual/changeStreams/[Change Streams] feature.
  
positive.code: The {prodname} connector watches the stream and delivers the changes downstream.
  And, when the connector sees a replica set for the first time, it looks at the oplog to get the last recorded transaction and then performs a snapshot of the primary's databases and collections.
  When all the data is copied, the connector then creates a change stream from the position it read earlier from the oplog.
  
  This is the recommended mode starting with MongoDB 4.x.
  
  [WARNING]
  ====
  Both capture modes use different values stored in offsets that allow them to resume streaming from the last position seen after a connector restart.
  Thus it is not possible to switch from the change streams mode to the oplog mode.
  To prevent any inadvertent capture mode changes, the connector has a built-in safety check.
  
  When the connector is started it checks the stored offsets.
  If the original capture mode was oplog-based and the new mode is change streams based, then it will try to migrate to change streams.
  If the original capture mode was change streams based, it will keep using change streams, also if the new mode is oplog-based, and a warning about this will be emitted to the logs.
  ====
  
  As the MongoDB connector processes changes, it periodically records the position in the oplog/stream where the event originated.
  When the connector stops, it records the last oplog/stream position that it processed, so that upon restart it simply begins streaming from that position.
  
negative.code: * Names of the collection and database that contain the new document.
  * If the event was part of a snapshot.
  * Timestamp for when the change was made in the database and ordinal of the event within the timestamp.
  * Unique identifier of the MongoDB operation (the `h` field in the oplog event).
  * Unique identifiers of the MongoDB session `lsid` and transaction number `txnNumber` in case the change was executed inside a transaction (change streams capture mode only).
  
  |8
  