- Replication >
- Replica Set Tutorials >
- Replica Set Maintenance Tutorials >
- Configure Replica Set Tag Sets
Configure Replica Set Tag Sets¶
On this page
Tag sets let you customize write concern and read
preferences for a replica set. MongoDB
stores tag sets in the replica set configuration object, which is the
document returned by rs.conf()
, in the
members[n].tags
embedded document.
This section introduces the configuration of tag sets. For an
overview on tag sets and their use, see
w: <tag set>
and
Tag Sets.
Differences Between Read Preferences and Write Concerns¶
Custom read preferences and write concerns evaluate tags sets in different ways:
- Read preferences consider the value of a tag when selecting a member to read from.
- Write concerns do not use the value of a tag to select a member except to consider whether or not the value is unique.
For example, a tag set for a read operation may resemble the following document:
To fulfill such a read operation, a member would need to have both of these tags. Any of the following tag sets would satisfy this requirement:
The following tag sets would not be able to fulfill this query:
Add Tag Sets to a Replica Set¶
Given the following replica set configuration:
You could add tag sets to the members of this replica set
with the following command sequence in the mongo
shell:
After this operation the output of rs.conf()
would
resemble the following:
Important
In tag sets, all tag values must be strings.
Custom Multi-Datacenter Write Concerns¶
Given a five member replica set with members in two data centers:
- a facility
VA
taggeddc_va
- a facility
GTO
taggeddc_gto
Create a custom write concern to require confirmation from two
data centers using replica set tags, using the following sequence
of operations in the mongo
shell:
Create a replica set configuration JavaScript object
conf
:Add tags to the replica set members reflecting their locations:
Create a custom
settings.getLastErrorModes
setting to ensure that the write operation will propagate to at least one member of each facility:Reconfigure the replica set using the modified
conf
configuration object:
To ensure that a write operation propagates to at least one member of
the set in both data centers, use the MultipleDC
write concern
mode as follows:
Alternatively, if you want to ensure that each write operation
propagates to at least 2 racks in each facility, reconfigure the
replica set as follows in the mongo
shell:
Create a replica set configuration object
conf
:Redefine the
settings.getLastErrorModes
value to require two different values of bothdc_va
anddc_gto
:Reconfigure the replica set using the modified
conf
configuration object:
Now, the following write operation will only return after the write operation propagates to at least two different racks in the each facility:
Configure Tag Sets for Workload Isolation of Read and Write Operations¶
Given a replica set with tag sets that reflect:
- data center facility,
- physical rack location of instance, and
- storage system (i.e. disk) type.
Where each member of the set has a tag set that resembles one of the following: [1]
To target a read operation to a member of the replica set with a
disk type of ssd
, you could use the following tag set:
However, to create comparable write concern modes, you would specify a
different set of
settings.getLastErrorModes
configuration. Consider the following sequence of operations in
the mongo
shell:
Create a replica set configuration object
conf
:Redefine the
settings.getLastErrorModes
value to configure two write concern modes:Reconfigure the replica set using the modified
conf
configuration object:
Now you can specify the MultipleDC
write concern mode, as in the
following, to ensure that a write operation propagates to
each data center.
Additionally, you can specify the ssd
write concern mode to ensure that a write operation propagates
to at least one instance with an SSD.
[1] | Since read preferences and write concerns use the value of fields in tag sets differently, larger deployments may have some redundancy. |