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

What this article shares with you is about the establishment of MONGODB replication set and the addition of nodes. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

It is not difficult for MONGODB to copy collections and add slave nodes, but the easier some things are, the more likely they are to go wrong. For some recent reasons, the company's MONGODB needs to add a slave node, and the hidden does not vote for use by third parties.

First of all, it is emphasized that any operation must be verified first. Let's do a complete experiment from the construction of a test replication cluster to the addition of a node.

The test consists of three machines, 244, 245, 246

In order to operate the addition of nodes, first use 244245 nodes as the initial cluster of MONGODB. In fact, there are many posts installed on the network. Summarize some of the following questions.

1 use the root account to operate the database. Do not use ROOT as the account to operate the database in any database

2 it is recommended that you do not use the RPM package when installing. In fact, this is the same thing in other databases. PG,MYSQL, it is not recommended that you use the RPM package to install.

3 the procedure of installing a cluster is one more than that of installing a stand-alone machine, that is, you need to add account information to the first MONGODB, and you need to add an account with root permission, and this primary (which may or may not be), when adding an account, the stand-alone mode when needed.

4 the permission to generate keyfile file files is 600 and the contents of keyfile files in all clusters are consistent when needed

For example, the following error is actually an error message that the node of MONGODB cannot join because there is a problem with the content of keyfile.

After the correct keyfile is generated, the cluster is initialized to OK

Next, we need to do an in-depth experiment.

1 add a new node, and there are several cases of adding a new node

1.1 in the cluster of added nodes, there is no data (only less time-tight links for locking, unlocking and copying than the second way)

1.2 A cluster that adds nodes already has a large amount of data

Let's first discuss the case of 1.2. If my current cluster already has a large amount of data, whether it is necessary to copy the data directly to the nodes that need to be added, this is recommended after adding nodes. Generally speaking, we need to lock the copied database first, then copy the data, and unlock the database after the copy is completed.

In general, in order to avoid affecting the business (generally speaking, we already have one master and two slaves), we find a slave library and lock the database (that is, we are no longer accepting new data).

Operation steps

1 Log in to the slave library, and rs.slaveOk () runs this command to ensure that subsequent commands can be performed in the slave library.

2 We copy the data under the data directory to the node that needs to be added, and the node to be added should not be started at this time

Unfortunately, the data I copied during the test was copied to the primary library (intentionally, of course), while the primary library did not block your copy data and overwrite the data. While copying, the mongo service stopped directly, and the mongodb error was reported the next time.

And the system suggests that version 4.03 may fix this problem, but the current error cannot be remedied, so be sure to see the location when copying the data.

In order for OK to continue this experiment, we will empty the data of the main database that has been destroyed in mongodb, restart the damaged server here, and then check rs.status () again.

You can see that the master library has become the original slave library.

This is also a reminder that the important libraries of MONGODB must run in the replication set, and even if the master library is destroyed, after emptying the data, and starting the mongo service again, the destroyed nodes will be automatically added back to the original replication set and work as slave nodes.

This time continue the previous experiment.

We stop writing from the library again, start copying data to the new slave library, then complete the copy, unlock the write restrictions on the slave library, and then start the second slave library.

Started successfully

Then we start to add new nodes.

Rs.add ({host: "10.50.132.246 27027"})

Added successfully

But what we are asking now is that the newly added nodes are hidden and cannot be elected or elected.

1 cfg_rs = rs.conf ()

We copy the information that already exists in the system to the variable.

2 cfg_rs

Check whether the variable is correct

three

Cfg_rs.members [2] .votes = 0

Cfg_rs.members [2] .priority = 0

We will set up the nodes that need to be changed

Rs.reconfig (cfg_rs)

When the overall task is over, let's see if our current settings are in effect.

The OK setup has been completed, and node 2 has successfully configured the node with hidden, no-votes, priority = 0.

This is what the establishment of MONGODB replication sets and the addition of nodes are like. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.