Apsaradb for MongoDB-master-slave replication on the fifth day

From this article, we will mainly discuss the deployment technology of mongodb.

We know that SQL server can achieve read/write separation, dual-machine hot backup and cluster deployment, and of course mongodb can also achieve this. In actual applications, we do not want the database to adopt single-point deployment,

How bad it would be if a database goes down or is damaged.

 

I. Master-slave Replication

1: first look at the model Diagram

2: From the above figure, we can analyze the advantages of this architecture as follows:

<1> data backup.

<2> data recovery.

<3> read/write splitting.

 

3: Let's practice it one by one.

In practical applications, we must deploy multiple servers. We can practice it on one machine only when we are too lazy to install virtual machines.

Step 1: place the mongodb folder on disk D and disk E, and simulate the folder on multiple servers.

Step 2: Start mongodb on the d disk and specify the database as the master database. In fact, the command is very simple:> mongodb -- dbpath = 'xxx' -- master,

The default port is 27017.

Step 3: In the same way, start mongodb on the edisk and specify the database as a slave database. The command is also very simple. Of course, we need to change the port, for example, 8888.

Source indicates the address of the primary database.

> Mongod -- dbpath = xxxx -- port = 8888 -- slave -- source = 127.0.0.1: 27017

Step 4: In the red area, we find a statement such as "applied 1 operations", and the occurrence time is 10 s, which means that every 10 s of the slave Database

The data is synchronized to the primary database. The synchronization is based on the "OpLog" log of the primary database. You can find the "sync_pullOpLog" in the red area in the figure.

Next we need to perform a test. We are surprised to find that the data has been updated synchronously.

 

4: If I want to add a slave database, but I don't want to specify it at startup, but later, can I do anything about mongodb? The answer is yes.

Our master database or slave database has a set called local, which is mainly used to store internal replication information.

Well, let's try again. I copied another mongodb running program on drive F. There are many cmd windows. Don't mess up.

Looking at the above log, it prompts that there is no primary database. It doesn't matter. One day, we find that we will subsidize it later. Haha, open another cmd window, and the statement is

Add a host address in sources and synchronize the data to 127.0.0.1: 5555 ....

 

5: read/write splitting

This method is implemented in a larger architecture. In mongodb, it is actually very simple. By default, the slave database does not support data reading, but it doesn't matter,

In the driver, we provided a "slaveOkay" to show that we can read the slave database to reduce the performance pressure of the master database. This is not demonstrated here.

 

Ii. Replica set

This is also a very good master-slave cluster, but there are two differences with the above cluster.

<1>: the cluster does not have a specific primary database.

<2>: If a primary database goes down, a secondary database is elected as the top node of the primary database in the cluster. This provides the automatic fault recovery function, which is awesome.

Let's try it now. First, close all the cmd windows and clear all the files in the database.

 

Step 1: Now that we want to create a cluster, we have to get a cluster name. Here we will get our company name shopex, -- replSet to let the server know that there are other databases under shopex,

Open the mongodb program in disk D. The port is 2222. The port 3333 is another database server in the shopex cluster.

 

Step 2: Since 3333 is another database server, don't worry. Open it now. Here we will open the mongodb program for the edisk.

 

Step 3: OK. Check the Red Area of the above log. It seems that we haven't finished it yet. Yes, the log information tells us to initialize the "Replica set". Now that the log says so, I will

In this way, you can connect to any server, but you must enter the admin set.

 

Step 4: After enabling the master database, we need to see who can become the master database server. We can see that port 2222 has become the master database server.

 

Step 5: we know that there is an arbitration server in SQL server, so there are also some in mongodb. Like SQL server, arbitration only participates in voting. Here we

Use mongodb of disk F as the arbitration server and specify any server port in the shopex cluster. In this example, 2222 is specified.

 

Then we can append rs. addArb () in the admin set.

After the append, we use rs. status () to check the server status in the cluster. In the figure, we can clearly see who is the master, slave, or arbitration.

 

Doesn't the cluster have automatic fault recovery? Then we can try it. Press Ctrl + C on the cmd server on port 2222 to KKO the server, and we will immediately find that

On the slave server of port 3333, you can use rs. status () again to check the status of servers in the cluster.