Phần 11 Add an Arbiter to Replica Set
Phần 11 Add an Arbiter to Replica Set
Arbiter chỉ làm trọng tài như etcd. Không lưu trữ dữ liệu DB.
In some circumstances (such as you have a primary and a secondary but cost constraints prohibit adding another secondary), you may choose to add a mongod instance to a replica set as an arbiter to vote in elections.
Arbiters are mongod instances that are part of a replica set but do not hold data (i.e. do not provide data redundancy). They can, however, participate in elections.
Arbiters have minimal resource requirements and do not require dedicated hardware. You can deploy an arbiter on an application server or a monitoring host.
IMPORTANT
Do not run an arbiter on systems that also host the primary or the secondary members of the replica set.
WARNING
Avoid deploying more than one arbiter per replica set.
See also: Concerns with Multiple Arbiters
Considerations
Read Concern majority and Three-Member PSA
WARNING
For 3-Member Primary-Secondary-Arbiter Architecture
If you have a three-member replica set with a primary-secondary-arbiter (PSA) architecture or a sharded cluster with a three-member PSA shards, the cache pressure will increase if any data bearing node is down and support for "majority" read concern is enabled.
To prevent the storage cache pressure from immobilizing a deployment with a three-member primary-secondary-arbiter (PSA) architecture, you can disable read concern "majority" starting in MongoDB 4.0.3 (and 3.6.1+). For more information, see Disable Read Concern Majority.
Replica Set Protocol Version
NOTE
For the following MongoDB versions, pv1 increases the likelihood of w:1 rollbacks compared to pv0 (no longer supported in MongoDB 4.0+) for replica sets with arbiters:
MongoDB 3.4.1
MongoDB 3.4.0
MongoDB 3.2.11 or earlier
See Replica Set Protocol Version.
Arbiter
An arbiter does not store data, but until the arbiter's mongod process is added to the replica set, the arbiter will act like any other mongod process and start up with a set of data files and with a full-sized journal.
IP Binding
Starting in MongoDB 3.6, MongoDB binaries, mongod and mongos, bind to localhost by default. If the net.ipv6 configuration file setting or the --ipv6 command line option is set for the binary, the binary additionally binds to the localhost IPv6 address.
Previously, starting from MongoDB 2.6, only the binaries from the official MongoDB RPM (Red Hat, CentOS, Fedora Linux, and derivatives) and DEB (Debian, Ubuntu, and derivatives) packages bind to localhost by default.
When bound only to the localhost, these MongoDB 3.6 binaries can only accept connections from clients (including the mongo shell, other members in your deployment for replica sets and sharded clusters) that are running on the same machine. Remote clients cannot connect to the binaries bound only to localhost.
To override and bind to other ip addresses, you can use the net.bindIp configuration file setting or the --bind_ip command-line option to specify a list of hostnames or ip addresses.
WARNING
Before binding to a non-localhost (e.g. publicly accessible) IP address, ensure you have secured your cluster from unauthorized access. For a complete list of security recommendations, see Security Checklist. At minimum, consider enabling authentication and hardening network infrastructure.
For example, the following mongod instance binds to both the localhost and the hostname My-Example-Associated-Hostname, which is associated with the ip address 198.51.100.1:
mongod --bind_ip localhost,My-Example-Associated-Hostname |
In order to connect to this instance, remote clients must specify the hostname or its associated ip address 198.51.100.1:
mongo --host My-Example-Associated-Hostname |
|
mongo --host 198.51.100.1 |
TIP
When possible, use a logical DNS hostname instead of an ip address, particularly when configuring replica set members or sharded cluster members. The use of logical DNS hostnames avoids configuration changes due to ip address changes.
Add an Arbiter
WARNING
Avoid deploying more than one arbiter per replica set.
See also: Concerns with Multiple Arbiters
TIP
When possible, use a logical DNS hostname instead of an ip address, particularly when configuring replica set members or sharded cluster members. The use of logical DNS hostnames avoids configuration changes due to ip address changes.
Create a data directory (e.g. storage.dbPath) for the arbiter. The mongod instance uses the directory for configuration data. The directory will not hold the data set. For example, create the /var/lib/mongodb/arb directory:
mkdir /var/lib/mongodb/arb |
Start the arbiter, specifying the data directory and the name of the replica set to join. The following starts an arbiter using the /var/lib/mongodb/arb as the dbPath and rs for the replica set name:
WARNING
Before binding to a non-localhost (e.g. publicly accessible) IP address, ensure you have secured your cluster from unauthorized access. For a complete list of security recommendations, see Security Checklist. At minimum, consider enabling authentication and hardening network infrastructure.
mongod --port 27017 --dbpath /var/lib/mongodb/arb --replSet rs --bind_ip localhost,<hostname(s)|ip address(es)> |
Connect to the primary and add the arbiter to the replica set. Use the rs.addArb() method, as in the following example which assumes that m1.example.net is the hostname associated with the specified ip address for the arbiter:
rs.addArb("m1.example.net:27017") |
This operation adds the arbiter running on port 27017 on the m1.example.net host.
https://docs.mongodb.com/v4.4/tutorial/add-replica-set-arbiter/
