On this page本页内容
db.
watch
(pipeline, options)¶For replica sets and sharded clusters only
New in version 4.0:Requires featureCompatibilityVersion
(fCV) set to "4.0"
or greater. For more information on fCV, see setFeatureCompatibilityVersion
.
Opens a change stream cursor for a database to report on all its non-system
collections.
pipeline |
array | Aggregation pipeline consisting of one or more of the following aggregation stages:
Specify a pipeline to filter/modify the change events output. Starting in MongoDB 4.2, change streams will throw an exception if the change stream aggregation pipeline modifies an event’s _id field. |
options |
document |
You must pass an empty array |
The options
document can contain the following fields and values:
resumeAfter |
document |
Each change stream event document includes a resume token as the
|
startAfter |
document |
Each change stream event document includes a resume token as the
|
fullDocument |
string |
Set |
batchSize |
int |
Has the same functionality as |
maxAwaitTimeMS |
int |
Defaults to |
collation |
document |
If omitted, defaults to |
startAtOperationTime |
Timestamp |
|
Returns: | A cursor over the change event documents. See Change Events for examples of change event documents. |
---|
See also参阅
db.watch()
is available for replica sets and sharded clusters:
db.watch()
on any data-bearing member.db.watch()
on a mongos
instance.You can only use db.watch()
with the Wired Tiger storage engine.
majority
Support¶Starting in MongoDB 4.2, change streams are available regardless of the "majority"
read concern support; that is, read concern majority
support can be either enabled (default) or disabled to use change streams.
In MongoDB 4.0 and earlier, change streams are available only if "majority"
read concern support is enabled (default).
db.watch()
on the admin
, local
, or config
database.db.watch()
only notifies on data changes that have persisted to a majority of data-bearing members.db.watch()
for a database that does not exist. However, once the database is created and you drop the database, the change stream cursor closes.Unlike the MongoDB drivers, the mongo
shell does not automatically attempt to resume a change stream cursor after an error. The MongoDB drivers make one
attempt to automatically resume a change stream cursor after certain errors.
db.watch()
uses information stored in the oplog to produce the change event description and generate a resume token associated to that operation. If the operation identified by the resume token passed to the resumeAfter
or startAfter
option has already dropped off the oplog, db.watch()
cannot resume the change stream.
See Resume a Change Stream for more information on resuming a change stream.
Note
resumeAfter
to resume a change stream after an invalidate event (for example, a collection drop or rename) closes the stream. Starting in MongoDB 4.2, you can use startAfter to start a new change stream after an invalidate event.Resume Token
The resume token _data
type depends on the MongoDB versions and, in some cases, the feature compatibility version (fcv) at the time of the change stream’s opening/resumption (i.e. a change in fcv value does not affect the resume tokens for already opened change streams):
MongoDB Version | Feature Compatibility Version | Resume Token _data Type |
---|---|---|
MongoDB 4.2 and later | “4.2” or “4.0” | Hex-encoded string (v1 ) |
MongoDB 4.0.7 and later | “4.0” or “3.6” | Hex-encoded string (v1 ) |
MongoDB 4.0.6 and earlier | “4.0” | Hex-encoded string (v0 ) |
MongoDB 4.0.6 and earlier | “3.6” | BinData |
MongoDB 3.6 | “3.6” | BinData |
With hex-encoded string resume tokens, you can compare and sort the resume tokens.
Regardless of the fcv value, a 4.0 deployment can use either BinData resume tokens or hex string resume tokens to resume a change stream. As such, a 4.0 deployment can use a resume token from a change stream opened on a collection from a 3.6 deployment.
New resume token formats introduced in a MongoDB version cannot be consumed by earlier MongoDB versions.
By default, the change stream cursor returns specific field changes/deltas for update operations. You can also configure the change stream to look up and return the current majority-committed version of the changed document. Depending on other write operations that may have occurred between the update and the lookup, the returned document may differ significantly from the document at the time of the update.
Depending on the number of changes applied during the update operation and the size of the full document, there is a risk that the size of the change event document for an update operation is greater than the 16MB BSON document limit. If this occurs, the server closes the change stream cursor and returns an error.
When running with access control, the user must have the find
and changeStream
privilege actions on the database resource. That is, a user must have a role that grants the following privilege:
The built-in read
role provides the appropriate privileges.
The following operation in the mongo
shell opens a change stream cursor on the hr
database. The returned cursor reports on data changes to all the non-system
collections in that database.
Iterate the cursor to check for new events. Use the cursor.isExhausted()
method to ensure the loop only exits if the change stream cursor is closed and there are no objects remaining in the latest batch:
For complete documentation on change stream output, see Change Events.