Reputation: 14239
What is the reasoning behind only making change streams available on replica sets?
Upvotes: 21
Views: 13964
Reputation: 21805
My environment was Windows and the following steps helped me:
"C:\Program Files\MongoDB\Server\4.2\bin\mongod.cfg"
Add the following code to the mongod.cfg
and options, that you need. More information: Mongo replication Options
replication:
replSetName: "rs0"
Restart MongoDB process:
Windows->Task Manager->Services->MongoDB [run restart]
Run in the console mongo 127.0.0.1:27017
rs.initiate()
As a result you are lucky to have something like the following:
> rs.initiate()
"info2" : "no configuration specified. Using a default configuration for the set",
"me" : "127.0.0.1:27017",
"ok" : 1,
"$clusterTime" : {
"clusterTime" : Timestamp(1584218777, 1),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
},
"operationTime" : Timestamp(1584218777, 1)
}
rs0:SECONDARY>
Upvotes: 12
Reputation: 13785
Change streams implementation is based on the oplog, which is only available on replica sets. Another reason is that a replica set contains a superset of the features of a standalone node, and is the recommended MongoDB deployment for production applications. Hence, it makes sense to implement the change stream feature based on the recommended production deployment topology.
Another major reason is that change streams will output documents that will not be rolled back in a replica set setting (see Rollbacks During Replica Set Failover), so the use of majority read concern is a requirement.
Note that change streams are also available in a sharded cluster, and also a single-node replica set (i.e. a replica set with only one member, although this setup is generally not recommended).
The high-level description of change streams is available in the Change Streams page
The design of change streams is outlined in SERVER-13932.
Upvotes: 24