Change Streams Production Recommendations

If you drop or rename a collection or database with change streamsopened against it, the change stream cursors close when they advance tothat point in the oplog. Change stream cursors with the fullDocument :updateLookup option may return null for the lookup document.

Attempting to resume a change stream against a dropped collection results inan error. Any data changes that occurred on the collection between the lastevent the change stream captured and the collection drop event are lost.

Change stream response documents must adhere to the 16MB BSON document limit.Depending on the size of documents in the collection against which you open achange stream, notifications may fail if the resulting notification documentexceeds the 16MB limit. For example, update operations on change streamsconfigured to return the full updated document, or insert/replace operationswith a document that is at or just below the limit.

Replica Sets

For replica sets with arbiter members, change streams may remainidle if enough data-bearing members are unavailable such that operations cannotbe majority committed.

For example, consider a 3-member replica set with two data-bearing nodes andan arbiter. If the secondary goes down, such as due to failure or an upgrade,writes cannot be majority committed. The change stream remains open, but doesnot send any notifications.

In this scenario, the application can catch up to all operations that occurredduring the downtime so long as the last operation the application received isstill in the oplog of the replica set.

If significant downtime is estimated, such as for an upgrade or a significantdisaster, consider increasing the size of the oplog such that operations areretained for a duration of time greater than the estimated downtime.Use rs.printReplicationInfo() to retrieve information on theoplog status, including the size of the oplog and the time range of operations.

Sharded Clusters

Change streams provide a total ordering of changes across shards by utilizinga global logical clock. MongoDB guarantees the order of changes are preservedand change stream notifications can be safely interpreted in the orderreceived. For example, a change stream cursor opened against a 3-shard shardedcluster returns change notifications respecting the total order of thosechanges across all three shards.

To guarantee total ordering of changes, for each change notification themongos checks with each shard to see if the shard has seen morerecent changes. Sharded clusters with one or more shards that have little orno activity for the collection, or are “cold”, can negatively affect theresponse time of the change stream as the mongos must still checkwith those cold shards to guarantee total ordering of changes. This effect maybe more apparent with geographically distributed shards, or workloads wherethe majority of operations occur on a subset of shards in the cluster.

If a sharded collection has high levels of activity, the mongosmay not be able to keep up with the changes across all of the shards.Consider utilizing notification filters for these types of collections.For example, passing a $match pipeline configured to filteronly insert operations.

For sharded collections, update operations with multi : true may cause any change streams opened against that collectionto send notifications for orphaned documents.

From the moment an unsharded collection is sharded until the time the changestream catches up to the first chunk migration, the documentKey in thechange stream notification document only includes the _id of the document,not the full shard key.