Docs Home → Develop Applications → MongoDB Manual
getDefaultRWConcern![](/docs/v4.4/assets/link.svg)
On this page
Definition![](/docs/v4.4/assets/link.svg)
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
.
getDefaultRWConcern
must be run against theadmin
database.getDefaultRWConcern
has the following form:db.adminCommand( { getDefaultRWConcern : 1 , inMemory: <boolean>, comment: <any> } ) getDefaultRWConcern
has the following fields:FieldTypeDescriptionintSet to
1
.booleanOptional.
Set to
true
to 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
false
to return the on-disk copy of the deployment's global default read or write concern. Defaults tofalse
.comment
anyOptional. 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.comment
field.Database profiler output, in the
command.comment
field.currentOp
output, in thecommand.comment
field.
A comment can be any valid BSON type (string, integer, object, array, etc).
New in version 4.4.
getDefaultRWConcern
output includes the following fields.FieldTypeDescriptionobject
The global default read concern configuration. If this field is absent, the deployment has no global default read concern settings.
object
The global default write concern configuration. If this field is absent, the deployment has no global default write concern settings.
TimestampThe 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.
DateThe 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
Tip
See also:
Behavior![](/docs/v4.4/assets/link.svg)
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![](/docs/v4.4/assets/link.svg)
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![](/docs/v4.4/assets/link.svg)
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![](/docs/v4.4/assets/link.svg)
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![](/docs/v4.4/assets/link.svg)
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) }