setDefaultRWConcern
On this page
Definition
New in version 4.4.
setDefaultRWConcern
The
setDefaultRWConcern
administrative command sets the global default read or write concern configuration for a replica set or sharded cluster.setDefaultRWConcern
must be run against theadmin
database.For replica sets, issue the
setDefaultRWConcern
command on the primarymongod
.For sharded clusters, issue the
setDefaultRWConcern
on amongos
.
setDefaultRWConcern
has the following form:db.adminCommand( { setDefaultRWConcern : 1, defaultReadConcern: { <read concern> }, defaultWriteConcern: { <write concern> }, writeConcern: { <write concern> }, comment: <any> } ) setDefaultRWConcern
has the following fields:FieldTypeDescriptionint
Set to
1
.object
Document containing the global read concern configuration. Specify a valid read concern object.
setDefaultRWConcern
supports the following subset of level:To unset the currently configured default read concern, specify an empty document
{}
.setDefaultRWConcern
only supports thelevels
read concern setting. You cannot specify any other read concern setting in the default read concern.
Omit this document to leave the current global read concern unmodified. If omitted,
setDefaultRWConcern
must specify defaultWriteConcern.object
Document containing the global default write concern configuration.
For the write concern w setting,
setDefaultRWConcern
supports all write concern values exceptw : 0
.For the write concern wtimeout setting,
setDefaultRWConcern
defaults to0
if the setting is omitted. Operations block until the requested write concern is met. If specifying a global defaultwtimeout
, ensure the value is large enough to allow write operations to achieve the requested write concern.To unset the currently configured write concern, specify an empty document
{}
.
Omit this document to leave the current global write concern unmodified. If omitted,
setDefaultRWConcern
must specify defaultReadConcern.objectOptional. A document that specifies the write concern to be used by the
setDefaultRWConcern
command itself.If omitted,
setDefaultRWConcern
uses the previously set global default write concern if one was configured.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.
setDefaultRWConcern
returns an object that contains the
currently configured global default read and write concern. See
getDefaultRWConcern
for more complete documentation on
the returned fields.
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 setDefaultRWConcern
.
MongoDB only applies the global default read or write concern to operations which do not explicitly specify a read or write concern.
If MongoDB applies the global default read or write concern to an operation, that operation behaves as if that read or write concern were explicitly specified by the issuing client.
Replica Sets
Issue setDefaultRWConcern
against the replica set
primary. The primary replicates the new global default settings
to the remaining members of the replica set. Secondaries which have
not yet replicated the updated global default settings continue
using their local 'stale' copy of the defaults.
Issue the setDefaultRWConcern
command with a
writeConcern of
w : "majority"
to ensure the command only
returns after the changes have propagated to a majority of replica set
members.
Sharded Clusters
Issue the setDefaultRWConcern
against a
mongos
in the cluster. The mongos
persists
the updated settings to the config server replica set (CSRS). Each mongos
periodically
issues a getDefaultRWConcern
against the CSRS to refresh
their local copy of the global settings. A mongos
uses
its local 'stale' copy of the global defaults during the time period
between refreshes.
Issue the setDefaultRWConcern
command with a
writeConcern of
w : "majority"
to ensure the command only
returns after the changes have propagated to a majority of CSRS members.
When an application issues an operation against the
mongos
without explicitly specifying a read or
write concern setting, the mongos
applies the
corresponding global default setting.
The global default settings do not propagate to the individual shards.
You cannot run setDefaultRWConcern
against a shard.
Important
setDefaultRWConcern
requires
featureCompatibilityVersion 4.4+
. 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.
Sharding Administrative Commands Override Write Concern Settings
Sharding administrative commands that perform write operations on the
config server, such as the
enableSharding
or addShard
commands, have
specific behavior with global default write concern settings:
The commands use
"majority"
regardless of the configured global default write concern.The commands use a minimum wtimeout of
60000
. The commands only use the global default write concernwtimeout
if it is greater than60000
.
Access Control
For replica sets or sharded clusters enforcing
Authentication, setDefaultRWConcern
requires
that the authenticated user have the
setDefaultRWConcern
privilege action.
The clusterManager
built-in role provides the required
privileges to run setDefaultRWConcern
.
Example
Set Global Default Write Concern
The following operation sets the global write concern to the following:
db.adminCommand({ "setDefaultRWConcern" : 1, "defaultWriteConcern" : { "w" : "majority" } })
The operation returns a document similar to the following:
{ "defaultWriteConcern" : { "w" : "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) }
Set Global Default Read Concern
The following operation sets the global read concern to
"majority"
:
db.adminCommand({ "setDefaultRWConcern" : 1, "defaultReadConcern" : { "level" : "majority" } })
The operation returns a document similar to the following:
{ "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) }
Set Global Default Read and Write Concern
The following operation sets the global default read and write concern to the following:
w: "majority"
write concernlevel: "majority"
read concern.
db.adminCommand({ "setDefaultRWConcern" : 1, "defaultWriteConcern" : { "w" : "majority" }, "defaultReadConcern" : { "level" : "majority" } })
The operation returns a document similar to the following:
"defaultWriteConcern" : { "w" : "majority" }, "defaultReadConcern" : { "level" : "majority" }
Unset Global Default Read and Write Concern
Consider a deployment with the following default read and write concern:
{ "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) }
The following operation unsets the global default read and write concern settings:
db.adminCommand({ "setDefaultRWConcern" : 1, "defaultReadConcern" : {}, "defaultWriteConcern" : {} })
The operation returns a document similar to the following:
{ "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) }