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

The node of the MongoDB replication set is elected as the primary node.

The principle of replication: replication is based on the operation log oplog, which is equivalent to the binary log of MySQL, and only records changes. Replication the process of synchronizing and applying the oplog logs of a master node to other slave nodes

The principle of election: the node type is divided into standard node, passive node and arbitration node.

(1) only standard nodes may be selected as primary nodes and have the right to vote. The passive node has a complete copy and cannot become an active node and has the right to vote. Arbitration nodes do not copy data, can not become active nodes, only the right to vote.

(2) the difference between the standard node and the passive node: the high priority value is the standard node, and the low value is the passive node.

(3) the election rule is that the person with the highest number of votes wins, and priority is a value with a priority of 0-1000, which is equivalent to an additional increase of 0-1000 votes. Election result: the person with the highest number of votes wins: if the number of votes is the same, the newcomer wins.

The following is the structure diagram of the election between the nodes of the MongoDB replication set.

Next, I will use several experiments to verify the election principle of replication sets.

First, create four nodes with ports of 27017, 27018, 27019, 27019, 27020, with 27017 and 27018 as standard nodes, 27019 as passive nodes and 27020 as arbitration nodes.

1 create the data storage path and log storage path of three nodes, of which 27017 is the default node, so there is no need to create

2 make changes to the configuration file of 27017, change the accessible address to all, open the replication set module, and set the replication set name to kgcrs

3 copy the configuration file of the first instance as the configuration file of the remaining three instances respectively, and then modify them one by one after completion

4 modify the configuration file of the second instance, in which you need to define the storage path of the data and the log file, and then change the port to 27018

4 then change the configuration file of the third instance, and also modify the file path to change the port to 27019

5 the fourth instance changes the port to 27020

6 Open these four instances

7 View the ports of these four instances

Second, verify the election principle of replication sets.

(1) configure the priority of replication sets

1 enter the first instance, configure the replication set of four nodes, and set up two standard nodes, one passive node and one arbitration node

2 after the replication set is configured, it can be initialized.

3 looking at the status of the replication set after initialization, you can see that 27017 becomes the active node, 27018 and 27019 become the slave node, and the last 27020 is the arbitration node.

(2) simulate node failure

1 shut down the active node

2 when you enter another standard node, you can find that the second standard node becomes the active node.

3 then I shut down the second standard node

4 enter the passive node to view, you can find that the role has not been switched, it is still from the node

5 then I opened the two standard nodes again

6 enter the first standard node to view, you can find that it has become an active node

Conclusion: if the primary node fails, another standard node will be elected as the new primary node, and if all standard nodes fail, the passive node will not become the primary node.

Three MongoDB replication set management

(1) configuration allows data to be read on the slave node

The slave node of the default MongoDB replication set cannot read data, and you can use the rs.slaveOK () command to allow data to be read from the slave node.

1 does not display information when viewing the database from the node

2 after executing rs.slaveOK (), you can view it again and display it.

(2) View replication status information

You can use the rs.printReplicationInfo () and rs.printSlaveReplicationInfo () commands to view the replication set status

Here rs.printReplicationInfo () can check the size of the log file, and rs.printSlaveReplicationInfo () will show which nodes will copy the data. You can see that there is no arbitration node here, because the arbitration node will not copy the data.

(3) change the oplog size

Oplog, short for operations log, is stored in the local database. The new operation in oplog automatically replaces the old operation to ensure that the oplog does not exceed the default size. By default, the oplog size consumes 5% of the available disk space for 64-bit instances

During MongoDB replication, the master node applies business operations to the database, then records these operations to oplog, replicates the oplog from the node, and then applies these modifications. These operations are asynchronous. If the operation of the slave node has been far behind by the master node, and the oplog is not finished in the slave node, the oplog may already roll around. If the slave node cannot keep up with the synchronization, the replication will stop. The slave node needs to resynchronize the slave node. In order to avoid this situation, try to ensure that the oplog of the master node is large enough to store operation records for a long time.

You can call the db.runCommand command to change the size of the oplog

1 here I am doing the operation on the slave node, and finally change the node to the master node

First check the size of the current log, which is shown here as 990m

2 turn off the node, remove it from the replication set and make it a single instance before you can operate

3 make changes to the configuration file of this node

4 modify the port number of this node, and then comment out the replication set module

5 after the file changes are completed, you can start the instance.

6 first make an integrity backup of the log file of the instance

7 then delete the original oplog under the local data of the instance

8 then re-create an oplog with its own size

9 close the node again because we still have to add this instance to the replication set

10 configure the main configuration file again, change the port to the original 27018, open the replication set module, and finally write down the size of oplog

11 start the instance again after the file configuration is complete

12 entering this instance, you can see that it has been added to the replication set, the role is from, and the oplog size is 2048m.

(4) deploy certified replication

The following demonstrates how to deploy a MongoDB replication set with user authentication

1 create a root user in the active node with a password of 123

2 turn on the password authentication module in the configuration files of the four instances, and the authentication type is file authentication, and write down the path of the password file, and restart the four instances after the file configuration is completed.

3 create four password files according to the path specified in the configuration file, with permissions set to 600

4 looking at the database information and the status of the replication set without input verification, you can see that the information we want will not be displayed.

5 you can view it by entering validation under admin database

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.