-
Type:
Bug
-
Resolution: Works as Designed
-
Priority:
Major - P3
-
None
-
Affects Version/s: 4.2.1
-
Component/s: Querying
-
None
-
ALL
-
Repl 2020-01-27
In a 3-node replica set with server 4.2.1 and featureCompatibilityVersion 4.2, I tried turning off majority read concern in my client and got:
Exception in thread "QueueChangeStreamListener-1" com.mongodb.MongoCommandException: Command failed with error 72 (InvalidOptions): ' $changeStream cannot run with a readConcern other than 'majority', or in a multi-document transaction. Current readConcern: { readConcern: { level: "local" } }' on server xxx:27017. The full response is { "operationTime" : { "$timestamp" : { "t" : 1575327297, "i" : 13 } }, "ok" : 0.0, "errmsg" : "$changeStream cannot run with a readConcern other than 'majority' , or in a multi-document transaction. Current readConcern: { readConcern: { level: \"local\" } }", "code" : 72, "codeName" : "InvalidOptions", "$clusterTime" : { "clusterTime" : { "$timestamp" : { "t" : 1575327297, "i" : 13 } }, "signature" : { "hash" : { "$binary" : "IRojwuY5C67DDcA8FXympzLzMxE=", "$type" : "00" }, "keyId" : { "$numberLong" : "6730051918464286727" } } } }
The docs say:
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).
That makes me think change streams should work in a cluster that has majority read concern enabled, but where the client chooses not to use it.