The composition of the MongoDB replica set

1>, synchronization: Replication is used to back up data between multiple servers.The replication functionality of MongoDB is implemented using the log Oplog, the operations log contains each write operation of the master node.Oplog is a fixed collection in the local database of the master node。 The backup node can know the operation that needs to be replicated by querying this collection. Each backup node maintains its own oplog, recording every operation that replicates data from the master node so that each member can be used as a synchronization source for other members. The backup node obtains the actions that need to be performed from the currently used synchronization source, then performs these operations on its own dataset, and then writes these operations to its own oplog. If an operation fails, the backup node stops copying data from the current synchronization source. If a backup node hangs for some reason, when it restarts, it automatically starts the synchronization from the last action in Oplog, because the process of copying the data before writing to Oplog, the backup node may perform a copy operation on the data that has already been synchronized. MongoDB will perform the same operation in Oplog multiple times, the same as the effect that is performed only once. Since Oplog is a fixed set, its size is fixed and he can only save a specific number of operations logs. To,Initializing synchronization: When a member of a replica set is started, it checks its state to determine whether it can be synchronized from a member. If not, it will attempt to replicate the full data from another member of the replica, which is the initialization of synchronization (intiial syncing), with the following steps: (1) First, select a member as the synchronization source, Create an identifier for yourself in local.me, delete all existing databases, and start synchronizing in a completely new state. Note: In this process, all existing data is deleted and should be initialized only if you do not need to keep the existing data. (2) Clone (cloing), copy all records of the synchronization source to local. (3) Enter the first step of Oplog synchronization, all operations in the cloning process will be recorded in the Oplog. If a document has been moved during the cloning process, it may be omitted, causing it to be cloned, and for such a document to be re-cloned. (4) The second step of the Oplog synchronization process is used to record the actions in the first Oplog synchronization. (5) Create an index, the previous steps of the local data and the master node at a certain time the data set exactly, you can start to create the index, if the collection is larger, or to create more indexes, this process can be time-consuming. (6) If the current node's data is still far behind the synchronization source, then the last step of the Oplog synchronization process is to synchronize all operations during the creation of the index to prevent the member from becoming a backup node. From the point of view of operation, initializing synchronization is very simple: start MongoDB with an empty data directory. However, more often than not, you may need to recover from a backup instead of initializing it, and it is much faster to recover from a backup than to use MongoDB to replicate all of the data. ,working with stale data: If the backup node lags far behind the current operation of the synchronization source, the backup node is stale. When a backup node is stale, it looks at the other members in the replica set, and if a member's Oplog is sufficiently detailed to handle the dropped operations, it is synchronized from that member. If the oplog of any of the members has no reference value, then the copy operation on the member is aborted and the member needs to be fully synchronized (or recovered from the most recent backup). To avoid the appearance of stale backup nodes, it is important that the primary node use a larger oplog to save enough operational logs.

2>, Heartbeat: Each member needs to know the status of the other Members: which is the primary node? which can be used as a synchronization source? Which one's dead? To maintain the latest view of the collection, each member sends a heartbeat request (heartbeat request) to other members every two seconds. The heartbeat request has a very small amount of information to check the status of each member . Member State: Each member tells its current state to other members through the heartbeat. *startup: The member was in this state when it was first started. In this state, MongoDB tries to load the member's replica set configuration, and after the configuration is loaded successfully, it enters the STARTUP2 state. *STARTUP2: The entire initialization synchronization process is in this state, but if it is on a regular member, this state will only last for a few seconds, in which case MongoDB creates several threads to handle replication and elections, and then switches to the recovering state. *recovering: This state indicates that the member is functioning normally, but the read request cannot be processed temporarily. At startup, members need to check to make sure they are in a valid state before they can process a read request. During the restart process, each member undergoes a recovering state before becoming a backup node. Members may also enter the recovering state when dealing with very time-consuming operations. When a member disconnects from other members, it also enters the recovering state. *arbiter: In normal operation, the arbiter should always be in the arbiter state. *down: If a functioning member becomes unreachable, he is in the down state. If a member is reported as down, it may still be in a healthy state, and the reason for the unreachable may be a network problem. *unknown: If one member cannot reach any other member, the other member cannot know what state it is in and will report it as a UNKNOWN state. *removed: When a member is moved out of the replica set, it is in this state, and if the removed member is re-added to the replica set, it returns to the "normal" state. *rollback: If a member is in the midst of a data rollback, it is in the ROLLBACK state. At the end of the rollback process, the server transitions to the recovering state and then becomes the backup node. *fatal: If a member has an irreversible error and no longer tries to return to normal, it is in the FATAL state.

3>, election: When a member is unable to reach the master node, it will apply to be elected as the primary node, and the member wishing to be elected as the primary node will send notifications to all members it can reach. If the member gets a "majority" in the replica set, it will be successful and would be converted to the primary node state. If the "majority" requirement is not reached, then the election fails, it is still in the backup node state and can then be re-applied to be elected as the primary node. The master node remains in the primary state until it is no longer satisfied with the "majority" requirement or hangs up, and the replica set is reconfigured to cause the master node to abdicate. If the primary node is unavailable, 2 seconds (the heartbeat interval is 2 seconds) a member will find the problem, and the election will start immediately, and the process will take only a few milliseconds. If a network problem, or a server overload causes a slow response, may trigger an election, in which case the heartbeat will time out after a maximum of 20 seconds, and if the election is tied, each member will have to wait 30 seconds to start the next election.

The composition of the MongoDB replica set