- 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
sub-document.
This section introduces the configuration of tag sets. For an overview on tag sets and their use, see Replica Set Write Concern 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
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
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 concern 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
getLastErrorModes
configuration. Consider the following sequence of operations in
the mongo
shell:
Create a replica set configuration object
conf
:Redefine the
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 operation, 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. |