MongoDB Copy (one Master + Quorum) environment deployment record

The MongoDB replica set is a master-slave cluster with failover. is the evolution from the existing master-slave mode, which increases automatic failover and node member auto-recovery.
There is no fixed primary node in the MongoDB replica set mode, and a primary node is automatically elected between multiple service nodes after startup. The main node is called primary, and one or more slave nodes are called secondaries.
Primary nodes are basically master nodes, except that primary nodes may be different servers at different times. If the current primary node fails, the remaining nodes in the replication set will attempt to select a
The new primary node.

The benefits of MongoDB replica set mode:

• Everything is automated. First of all, the replication set pattern itself does a lot of administrative work, automatically manages the slave nodes, ensuring that the data is not inconsistent.
• After the primary node is hung, the servers in the cluster are automatically judged and failed over, and the new master node is elected.
• A replica set cluster supports 1-7 servers, and each server data in one replication set remains fully consistent.

In a MongoDB replication Chi group, each server has the following states:

• Primary master node, one replica set and only one server is in the Primary state, only the master node can provide read and write services to the outside. If the primary node is hung, the replica sets will vote for a standby node to become the new master node.
• Secondary the standby node, the replica set allows for multiple secondary, and the data for each standby node is fully synchronized with the data of the primary node. In Recovering recovery, when a server in a replication set hangs or falls out of line, the data cannot be synchronized, the data is replicated from other members after the service is restored, and the node is back in standby state after the data is synchronized.
• Arbiter the quorum node, the node can not exist separately, if configured as the quorum node, it is mainly responsible for monitoring the other node state in the replica set, vote to elect the master node. The node will not be used to hold data. If there is no quorum node, the polling work will be done by all nodes together.
• Down invalid node, which is in this state when the server hangs or falls off the line. The read request from the node of the replica set is also the value of setting slaveok at each driver layer.

As described above, replication in MongoDB can synchronize data across multiple servers. Replication provides redundancy and increases the high availability of data, preventing the possibility of individual nodes from losing data, or the ability to read and write separations to improve client-side operational performance. The MongoDB instance of each node in the replication set has the same copy of the DataSet. The master node can receive client-side all write operations logged to the log, and the operations log records from the library copy master are applied to its database. A client can have only one primary node, and if the primary node is unavailable (unable to connect within 10 seconds), a member node is selected as the primary node in the replication set.

The basic structure of MongoDB Master + Arbitration is as follows:

The following is a brief introduction to the deployment process for the MongoDB replica set:

MongoDB Copy (one Master + Quorum) environment deployment record