getDefaultRWConcern
Definition
New in version 4.4.
getDefaultRWConcern
The
getDefaultRWConcern
administrative command retrieves the global default read or write concern settings.For sharded clusters, issue the
getDefaultRWConcern
on amongos
.
Syntax
The command has the following form:
db.adminCommand( { getDefaultRWConcern: 1 , inMemory: <boolean>, comment: <any> } )
Command Fields
The command has the following fields:
Field | Type | Description |
---|---|---|
int | Set to | |
boolean | Optional. Set to Set to | |
comment | any | Optional. A user-provided comment to attach to this command. Once set, this comment appears alongside records of this command in the following locations:
A comment can be any valid BSON type (string, integer, object, array, etc). New in version 4.4. |
Output
The output includes the following fields:
Field | Type | Description |
---|---|---|
object | The global default write concern configuration. If this field is absent, the deployment has no global default write concern settings. | |
object | The global default read concern configuration. If this field is absent, the deployment has no global default read concern settings. | |
String | The source of the default write concern. By
default, the value is | |
String | The source of the default read concern. By
default, the value is | |
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" }, "defaultWriteConcernSource" : "global", "defaultReadConcernSource" : "global", "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) }