Shulou(Shulou.com)06/03 Report--

Replication Set is the core component of MongoDB. Compared with the Master-Slave architecture adopted in earlier versions, replica set has many natural advantages, including automatic failure recovery, multi-server deployment, read and write behavior control, etc. This article describes the most basic part of a replica set, which is the replica set Member. It is divided into two parts: the role and transformation of members, the status and transformation of members.

First of all, the role of members can be divided into three categories: Primary, Secondary and Arbiter. The first two are regular roles, which each replica set normally has, and the Arbiter is a special role that contains no user data and is only active at election time. Among them, Secondary can be subdivided into many familiar ones, as described below.

MongoDB is similar to Raft in distributed architecture, with Leader called Primary and Follower called Secondary, but there is no candidate role defined in MongoDB. Primary is the primary node of the replication set. It is the only node with permission to accept client write requests. All insert and update operations will be recorded in oplog. Primary is also the target node of all read requests by default. Secondary copies oplog records of Primary (or other Secondary) and plays them back locally to keep them consistent with Primary data. It can be set to allow clients to read, but Secondary does not allow reading by default. The slaveok parameter needs to be set.

Arbiter is different from the above two roles. It does not contain copies of user data. The purpose of adding Arbiter to the replica set is only to select the master operation. An Arbiter is usually added (and only can be added) to a replica set with an even number of nodes, so that a majority is achieved in an election and a split vote is avoided. As follows:

When a Primary is dropped or demoted for some reason, a Secondary can be elected to become a new Primary, and the original Primary can be restored and rejoined to the replica set to become a Secondary. Arbiter cannot be Primary because it contains no user data. This is the interconversion relationship between them. Primary, Secondary, and Arbitrator should be deployed independently on different network nodes, and for cloud environments, they should not be located on the same host to ensure data security and election independence.

There is only one Primary in a replication set, and in some special scenarios, there may be no Primary. Arbiter is not required in clusters. Therefore, the most common role in a cluster is Secondary, usually no less than 2. Different Secondary can have different properties and be in different states. Secondary attributes have the following categories:

Election-related attributes:

1. Whether it can be selected as Primary. This attribute is controlled by priority. The higher the priority, the more likely it is to become Primary. Usually, Primary always copies the member with the highest priority in the set. Secondary with priority 0 cannot be selected as Primary. This feature is generally used for cross-room deployment to avoid switching to another room after failover.

2, whether there is voting rights, MongoDB replica set can have as many as 50 members, but only 7 members are allowed to vote, this attribute is controlled by votes, votes 0 members do not have voting rights, but can veto the election, can also become Primary (can be understood as unable to vote for, can vote against and initiate elections, because the right to be elected is controlled by priority). Starting with MongoDB version 3.0, it is not allowed to set the votes of members to be greater than 1.

Client-related properties:

1. Whether the client is visible, this parameter is controlled by hidden, hidden is true means invisible, the client cannot read data from the node, mongos will not interact with it; because invisible to the client, it must not be elected as Primary, so its priority attribute must be 0; the node is generally used for backup purposes.

Attributes related to data latency:

1. slaveDelay is used to control the replication delay relationship between the Secondary node and the Primary node. For example, slaveDelay is 3600, which means that its data lags behind the Primary node by 1 hour. The delay judgment is determined by the information in the oplog. This attribute is typically used as an online historical backup to roll back errors caused by human operations, including accidental deletion of databases or collections; this attribute potentially requires a priority attribute of 0 and a hidden attribute of true;

It can be seen that compared with MySQL Replication, MongoDB Replication Set members have more types and attributes. Of course, the main reason is that MySQL is still Master-Slave replication, so there is no need for election-related attributes or roles. MySQL has a similar slaveDelay feature. in addition, that formal release of MySQL Group Replication, which is still in the lab, will shock the database community.

After talking about types and attributes, let's take a look at member states. There are no more or no less. MongoDB has a total of 10 states, which are officially divided into 3 categories. Core States are attributes corresponding to three member types (PRIMARY/SECONDARY/ARBITER), and there are 7 attributes, which are divided into Other States and Error States.

In chronological order, the other states are STARTUP, STARTUP2, and RECOVERING. Each replica set member enters the STARTUP state after mongod starts, loads the replica set configuration for the member, and then enters the STARTUP2 state. If the member needs initial sync, it stays in that state for a long time until all data and indexes are synchronized. Then enter the RECOVERING state, in which members cannot accept read requests from clients and cannot be elected as Primary, but can vote.

The error states are as follows: If a member has joined a replica set but has not synchronized state information, it will be marked as UNKNOWN by other replica set members; if the member can no longer synchronize state information through heartbeat, that is, lost contact, it will be marked as DOWN by other members;REMOVED means that the member has been moved out of the replica set; when the member is in the rollback process, the state is ROLLBACK, which may appear when the old primary rejoins the replica set and is used to rollback operations on it that have not synchronized to other Secondary; The FATAL status indicates that the member has encountered an unrecoverable error that must be handled manually.

In addition to vote and priority, voting behavior is also affected by the status of members. Only PRIMARY, SECONDARY, RECOVERING, ARBITER and ROLLBACK are allowed to vote.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.