MongoDB Arbiter

1. Overview

Arbiters are mongod instances that are part of a replica set but do not hold data (i.e. do not provide data redundancy). 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. 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.

• Do not run an arbiter on systems that also host the primary or the secondary members of the replica set.
• In general, avoid deploying more than one arbiter per replica set.

2. Replica Set Members

A replica set in MongoDB is a group of mongod processes that provide redundancy and high availability. The members of a replica set are:

2.1 Primary

The primary receives all write operations. The primary is the only member of the replica set that receives write operations. MongoDB applies to write operations on the primary and then records the operations on the primary’s oplog. Secondary members replicate this log and apply the operations to their data sets.

All members of the replica set can accept read operations. However, by default, an application directs its read operations to the primary member. See Read Preference for details on changing the default read behavior.

The replica set can have at most one primary. If the current primary becomes unavailable, an election determines the new primary. See Replica Set Elections for more details.

2.2 Secondaries

Secondaries replicate operations from the primary to maintain an identical data set. Secondaries may have additional configurations for special usage profiles. For example, secondaries may be non-voting or priority 0.

The minimum recommended configuration for a replica set is a three-member replica set with three data-bearing members: one primary and two secondary members. In some circumstances (such as you have a primary and a secondary but cost constraints prohibit adding another secondary), you may choose to include an arbiter. An arbiter participates in elections but does not hold data (i.e. does not provide data redundancy).

A replica set can have up to 50 members but only 7 voting members.

A secondary maintains a copy of the primary’s data set. To replicate data, a secondary applies operations from the primary’s oplog to its own data set in an asynchronous process. A replica set can have one or more secondaries.

Although clients cannot write data to secondaries, clients can read data from secondary members. See Read Preference for more information on how clients direct read operations to replica sets.

A secondary can become a primary. If the current primary becomes unavailable, the replica set holds an election to choose which of the secondaries becomes the new primary.

You can configure a secondary member for a specific purpose. You can configure a secondary to:

• Prevent it from becoming a primary in an election, which allows it to reside in a secondary data center or to serve as a cold standby.
• Prevent applications from reading from it, which allows it to run applications that require separation from normal traffic.
• Keep a running “historical” snapshot for use in recovery from certain errors, such as unintentionally deleted databases.

2.2.1 Priority 0 Replica Set Members

A priority 0 member is a member that cannot become primary and cannot trigger elections. Priority 0 members can acknowledge write operations issued with write concern of w : <number>. For "majority" write concern, the priority 0 member must also be a voting member (i.e. members[n].votes is greater than 0) to acknowledge the write. Non-voting replica set members (i.e. members[n].votes is 0) cannot contribute to acknowledging write operations with "majority" write concern.

For example, in the following diagram, one data center hosts the primary and a secondary. A second data center hosts a secondary with priority 0. Only the members in data center 1 can become primary.

2.3 Arbiter

In some circumstances (such as you have a primary and a secondary but cost constraints prohibit adding another secondary), you may choose to add an arbiter to your replica set. An arbiter does not have a copy of data set and cannot become a primary. However, an arbiter participates in elections for primary. An arbiter has exactly 1 election vote.

 

3. Security

3.1 Authentication

When running with authorization, arbiters exchange credentials with other members of the set to authenticate. MongoDB encrypts the authentication process, and the MongoDB authentication exchange is cryptographically secure.

Because arbiters do not store data, they do not possess the internal table of user and role mappings used for authentication. Thus, the only way to log on to an arbiter with authorization active is to use the localhost exception.

3.1.1 Localhost Exception

The localhost exception allows you to enable access control and then create the first user in the system. With the localhost exception, after you enable access control, connect to the localhost interface and create the first user in the admin database. The first user must have privileges to create other users, such as a user with the userAdmin or userAdminAnyDatabase role. Connections using the localhost exception only have access to create the first user on the admin database.

Changed in version 3.4: MongoDB 3.4 extended the localhost exception to permit execution of the db.createRole() method. This method allows users authorizing via LDAP to create a role inside of MongoDB that maps to a role defined in LDAP. See LDAP Authorization for more information.

The localhost exception applies only when there are no users created in the MongoDB instance.

In the case of a sharded cluster, the localhost exception applies to each shard individually as well as to the cluster as a whole. Once you create a sharded cluster and add a user administrator through the mongos instance, you must still prevent unauthorized access to the individual shards. Follow one of the following steps for each shard in your cluster:

• Create an administrative user, or
• Disable the localhost exception at startup. To disable the localhost exception, set the enableLocalhostAuthBypass parameter to 0.

3.2 Communication

The only communication between arbiters and other set members are: votes during elections, heartbeats, and configuration data. These exchanges are not encrypted.

However, if your MongoDB deployment uses TLS/SSL, MongoDB will encrypt all communication between replica set members. See Configure mongod and mongos for TLS/SSL for more information.

As with all MongoDB components, run arbiters in trusted network environments.

4. Three Member Replica Sets

4.1 Primary with a Secondary and an Arbiter (PSA)

• One primary.
• One secondary member. The secondary can become primary in an election.
• One arbiter. The arbiter only votes in elections.

Since the arbiter does not hold a copy of the data, these deployments provide only one complete copy of the data. Arbiters require fewer resources, but at the expense of more limited redundancy and fault tolerance.

However, a deployment with a primary, secondary, and an arbiter ensures that a replica set remains available if the primary or the secondary is unavailable. If the primary is unavailable, the replica set will elect the secondary to be primary.

4.2 Primary with Two Secondary Members (PSS)

• One primary.
• Two secondary members. Both secondaries can become the primary in an election.

These deployments provide two complete copies of the data set at all times in addition to the primary. These replica sets provide additional fault tolerance and high availability. If the primary is unavailable, the replica set elects a secondary to be primary and continues normal operation. The old primary rejoins the set when available.

6. Reference

https://docs.mongodb.com/manual/core/replica-set-arbiter/

https://kayjayworld.tistory.com/6

https://docs.mongodb.com/manual/tutorial/add-replica-set-arbiter/

https://docs.mongodb.com/manual/core/replica-set-architecture-three-members/

https://docs.mongodb.com/manual/tutorial/convert-secondary-into-arbiter/

https://docs.mongodb.com/manual/core/replica-set-members/

https://m.blog.naver.com/PostView.nhn?blogId=dlghks44&logNo=221314300059&proxyReferer=http:%2F%2F203.233.19.54%2Ftm%2F%3Fa%3DCR%26b%3DWIN%26c%3D799003017892%26d%3D10003%26e%3D2052%26f%3DbS5ibG9nLm5hdmVyLmNvbS9kbGdoa3M0NC8yMjEzMTQzMDAwNTk%3D%26g%3D1586502673647%26h%3D1586502672462%26y%3D0%26z%3D0%26x%3D1%26w%3D2015-10-26%26in%3D2052_1611_00020392%26id%3D20200410