Definition
New in version 4.4.
getDefaultRWConcernThe
getDefaultRWConcernadministrative command retrieves the global default read or write concern settings.For sharded clusters, issue the
getDefaultRWConcernon amongos.
getDefaultRWConcernmust be run against theadmindatabase.getDefaultRWConcernhas the following form:db.adminCommand( { getDefaultRWConcern : 1 , inMemory: <boolean>, comment: <any> } ) getDefaultRWConcernhas the following fields:FieldTypeDescriptionint
Set to
1.boolean
Optional.
Set to
trueto return the in-memory cached copy of the global default read or write concern settings. The instance uses the in-memory copy when applying the global defaults to an operation.Set to
falseto return the on-disk copy of the deployment's global default read or write concern. Defaults tofalse.commentany
Optional. A user-provided comment to attach to this command. Once set, this comment appears alongside records of this command in the following locations:
mongod log messages, in the
attr.command.cursor.commentfield.Database profiler output, in the
command.commentfield.currentOpoutput, in thecommand.commentfield.
A comment can be any valid BSON type (string, integer, object, array, etc).
New in version 4.4.
getDefaultRWConcernoutput includes the following fields.FieldTypeDescriptionobjectThe global default read concern configuration. If this field is absent, the deployment has no global default read concern settings.
objectThe global default write concern configuration. If this field is absent, the deployment has no global default write concern settings.
Timestamp
The operation timestamp of when any global default read or write concern setting was last modified. Present if a default has ever been set for the cluster.
Date
The wall clock date when an administrator last set the global default read or write concern. This value is informational and should not be used for any recency comparisons.
Date
Behavior
Note
Requires featureCompatibilityVersion 4.4+
Each mongod in the replica set or sharded cluster
must have featureCompatibilityVersion set to
at least 4.4 to use getDefaultRWConcern. If you
downgrade your deployment's featureCompatibilityVersion from 4.4 to 4.2, all cluster-wide read and write
concern defaults are lost, but mongos instances may
continue applying the defaults for up to 30 seconds.
Replica Sets
You can issue getDefaultRWConcern against any data-bearing
member of the replica set (i.e. not against an arbiter).
A secondary can return a 'stale' version of the global default settings if it has not yet replicated the latest changes from the primary.
Sharded Clusters
Issue the setDefaultRWConcern against a
mongos in the cluster.
Each mongos periodically refreshes its local copy of the
global default settings. A mongos can return a 'stale'
version of the global default settings if it has not yet refreshed
its local copy after a recent update to the global default settings
or if it fetched its settings from a lagged
config server secondary.
The global default settings do not propagate to the individual shards.
You cannot run getDefaultRWConcern against a shard.
Access Control
For replica sets or sharded clusters enforcing
Authentication, getDefaultRWConcern requires
that the authenticated user have the
getDefaultRWConcern privilege action.
The clusterManager or clusterMonitor built-in
roles provides the required privileges to run
getDefaultRWConcern.
Example
The following operation retrieves the currently configured
global default read and write concern for the mongod.
db.adminCommand({ "getDefaultRWConcern": 1 })
The operation returns output similar to the following:
{ "defaultWriteConcern" : { "w" : "majority" }, "defaultReadConcern" : { "level" : "majority" }, "updateOpTime" : Timestamp(1586290895, 1), "updateWallClockTime" : ISODate("2020-04-07T20:21:41.849Z"), "localUpdateWallClockTime" : ISODate("2020-04-07T20:21:41.862Z"), "ok" : 1, "$clusterTime" : { ... } "operationTime" : Timestamp(1586290925, 1) }