Change Streams Production Recommendations
If you drop or rename a collection or database with change streams opened against it, the change stream cursors close when they advance to that 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 in an error. Any data changes that occurred on the collection between the last event 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 a change stream, notifications may fail if the resulting notification document exceeds the 16MB limit. For example, update operations on change streams configured to return the full updated document, or insert/replace operations with a document that is at or just below the limit.
For replica sets with arbiter members, change streams may remain idle if enough data-bearing members are unavailable such that operations cannot be majority committed.
For example, consider a 3-member replica set with two data-bearing nodes and an 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 does not send any notifications.
In this scenario, the application can catch up to all operations that occurred during the downtime so long as the last operation the application received is still in the oplog of the replica set.
If significant downtime is estimated, such as for an upgrade or a significant disaster, consider increasing the size of the oplog such that operations are retained for a duration of time greater than the estimated downtime. Use
rs.printReplicationInfo() to retrieve information on the oplog status, including the size of the oplog and the time range of operations.