MongoDB Replica Set Configuration and Data Migration Actual

Basic concepts

A replica set of MongoDB is the MongoDB master-slave cluster with automatic recovery capabilities.Since MongoDB's master-slave replication capability does not support high availability, it has been obsolete since version 3.2 and replaced by a replica set.A replica set always has one active node (Primary) and several Secondary nodes, as well as an optional Arbiter node to implement failover in HA.

Dead work

Prepare three servers (or virtual machines), and install all Ubuntu 16.04
For example:

The configuration process is very simple, you can see that there are two nodes, 0 and 1, in the replica set member, when the master and slave servers are ready to work, and any changes in server 0 (Primary) data will be synchronized to server 1 (Secondary).However, at this time, the replica set only provides the function of data backup and cannot be highly available.To achieve this, you need to configure an Arbiter node

Configure Arbiter

When the Primary node fails, the arbitrator votes in the election of the participating replica set to determine which replica becomes the Primary node.A quorum node will not become a Primary node without saving data.

Arbitrators are not usually deployed on servers with large disk space, so to minimize default data creation, modify the configuration:

You can see the status display: Server 0 is Primary, Server 1 is Secondary, Server 2 is Arbiter.
Now that the highly available replica set is configured, Arbiter monitors the operation of the Primary node, and if server 0 goes down, the Arbiter node of the arbitrator initiates an election and eventually selects one of the multiple Secondaries as the Primary node.If there is only one Secondary node in the architecture we are testing, then Server 1 will become Primary.When Server 0 resumes working, it will be run as Secondary.

Replica Priority
Replica sets promote Secondary to Primary when the Primary node fails, but in many cases Secondary is just a standby node and we don't want it to run as a Primary node for a long time.So to do this, we change the priority of the copy.

If run on a non-Prmiary, such as Arbiter, the following error will be reported:

{
"ok" : 0,
"errmsg" : "replSetReconfig should only be run on PRIMARY, but my state is ARBITER; use the \"force\" argument to override",
"code" : 10107,
"codeName" : "NotMaster"
}

By doing this, Server 0 takes precedence over Server 1, and when Server 0 recovers from a failure, it becomes a Primary node again to serve.

data migration

Before configuring a replica set, you may already have a separate MongoDB instance that stores some data, and you need to migrate the data from the original instance to the new replica set.(You can also initially configure an original single instance as a Primary node of a replica set and then add a new replica to synchronize the data, which is outside the scope of this article)

Log in to the server where the original instance is located and export the data: