Shulou(Shulou.com)05/31 Report--

This article introduces what is the principle of replication set cluster in MongoDB. The content is very detailed. Interested friends can use it for reference. I hope it will be helpful to you.

Introduction to replication set

A replication set (also known as a replica) in MongoDB is a set of mongod processes that maintain the same dataset. Replica sets provide redundancy and high availability and are the basis for all production deployments. To put it simply, a replica set consists of a cluster of multiple MongoDB, in which there is a master node (Primary) and N replica nodes (Secondary), which have the same database. If the master MongoDB server or MongoDB instance download machine is followed, other replica servers can continue to provide services to achieve high availability and reliability of data.

Replicate the cluster architecture

Introduction to terminology:

The term type describes that the Primary master node is responsible for the read and write operations of the entire cluster, including the logs of all change operations. The Secondary backup node synchronizes all the data of the primary server and is responsible for the read requests of the cluster. The master server downtime can be called the primary node Arbiter arbitrator only votes after the primary node downtime, does not participate in the election, different steps of the primary node data

This architecture consists of one Primary node and two Secondary nodes

1) the Primary node is the master node, and all write or change operations can only be performed from the Primary node (all members in the replication set can receive read operations, but by default, the application directs its read operations to the master member), and all changes and write operations on the master node will be recorded in the oplog log.

2) two Secondary nodes replicate the oplog log of the Primary node and execute the records in the oplog log asynchronously to achieve data consistency with the Primary node.

3) the main function of oplog is to record the write operation of the master node and act as the replication source.

4) if the Primary node has no reason after the download machine, the replication cluster will select one of the two Secondary to upgrade to the Primary node through the voting mechanism.

Voting mechanism

Heartbeat check is maintained between MongoDB nodes, and the primary node election is triggered by the heartbeat.

Heartbeat check MongoDB replication set members send heartbeats and process response information to all members except themselves, so each node maintains the status information of all other nodes seen by that node, and the node determines whether a new Primary needs to be updated based on its own cluster status. In implementation, two asynchronous processes deal with heartbeat response and timeout respectively. Each replication set member runs heartbeat threads of all nodes in the replication set in the background, triggering the status detection process in the following cases:

Initiate a replacement election when the Secondary node weight (Priority) is higher than the Primary node

When the Secondary node discovers that there is no Primary in the cluster, it initiates an election

When the Primary node cannot access most of its members, it will actively downgrade, and the demotion operation will disconnect the connection, terminate the user request, etc.

The heartbeat detection results of replica set members change, such as a node is dead or a new node is added, and initiate a revote election rule

The status detection process is not performed for more than 4 seconds, and a replacement election is initiated.

The node that initiates the election needs to make some condition judgment first. There are N standby nodes maintaining the primary node, and all the nodes in the standby node may be elected as the primary node. Before becoming the primary node, each standby node will check whether its own and global conditions are met. The detection conditions are as follows:

1. Do you see whether Majority is online in the replication set?

two。 Whether its own Priority is greater than 0

3. Not an arbiter in itself

4. Its own opTime cannot lag more than 10 seconds behind the latest node.

5. The cluster programs stored by themselves are up-to-date according to the information.

If all conditions are met, add yourself to the standby list of the primary node, otherwise, remove yourself from the list

Self-detection

The MongoDB election requires a majority of votes to pass. If there are no nodes to vote against, and the number of votes obtained exceeds the total number of nodes entitled to vote, it can become a Primary. Or move on to the next round of elections. To avoid falling into an infinite repeat election, MongoDB recommends that the number of members of the replication set is odd, and when the Secondary is even, you can add an Arbiter node.

During the election process, the replica set has no master node and all members are read-only

The election process is very complicated, and it usually takes about 5 seconds to elect.

If the newly selected master node dies immediately, it will take at least 30 seconds to re-select the master.

Most definitions assume that the number of voting members in the replication set is N, then most of them are N + 1. When the number of surviving members in the replication set is not enough, the whole replication set will not be able to elect Primary, and the replication set will not be able to provide write services and will be in a read-only state. According to the above architecture, for example, three MongoDB, one Primary, and two Secondary. After the master node is dead, only two Secondary can vote. According to the formula, we calculate "2max 2 + 1 = 2", that is, if the majority is equal to 2, but when the number of surviving members in the replica set is less than the majority, our majority is 2, and the cluster members are 2, so the two cluster members will initiate an election voting mechanism. If the conditions of both Secondary nodes are met, the member of the node will be elected as the Primary node first.

Number of voting members majority tolerated invalidation 110220321431532642743

Copy cluster member description

Secondary normally, the Seconary of the replication set participates in the Primary election (or it may be selected as Primary itself) and synchronizes the most recently written data from the Primary to ensure that the same data is stored as the Primary. Secondary can provide read service, increase the ability of Secondary node to provide read service of replication set, and improve the availability of replication set at the same time. In addition, Mongodb supports flexible configuration of Secondary nodes of replication sets to meet the needs of a variety of scenarios.

The Arbiter Arbiter node only participates in voting, cannot be selected as Primary, and does not synchronize data from Primary. For example, if you deploy a replication set with 2 nodes and 1 Primary,1 and Secondary, and any node is down, the replication set will not be able to provide services (Primary cannot be selected). In this case, you can add an Arbiter node to the replication set. Even if the node is down, you can still select Primary. Arbiter itself does not store data and is a very lightweight service. When the members of the replication set are even, it is best to add an Arbiter node to improve the availability of the replication set.

The Priority0 Priority0 node has an election priority of 0 and will not be elected as Primary. For example, if you deploy a replica set across data center An and B, and you want to specify that the Primary must be in computer room A, you can set the replica set member Priority of computer room B to 0, so that Primary must be a member of computer room A. (note: if deployed in this way, it is best to deploy "most" nodes in computer room A, otherwise the Primary may not be selected when the network is partitioned)

In Vote0 Mongodb 3.0, the maximum number of replica set members is 50, the maximum number of members voting in the Primary election is 7, and the vote property of other members (Vote0) must be set to 0, that is, do not vote.

The Hidden Hidden node cannot be selected as primary (Priority is 0) and is not visible to Driver. Because the Hidden node will not accept the Driver request, you can use the Hidden node to do some data backup and offline computing tasks, which will not affect the service of the replication set.

The Delayed Delayed node must be a Hidden node and its data lags behind Primary for a period of time (configurable, for example, 1 hour). Because the data of Delayed node lags behind Primary for a period of time, when incorrect or invalid data is written into Primary, it can be recovered to the previous time point through the data of Delayed node.

Priority is 0 replication set members

This architecture consists of one Primary node and two Secondary nodes

1) this architecture consists of a Primary master node and two Secondary backup nodes, which is based on the principle of the master-slave replication architecture. The two Secondary nodes also agree with the Primary master node through oplog logs.

2) the difference is that if the instance priority priority of the Secondary standby node on the Data Center2 node is 0, it will not participate in the election and will not become a Primary node. Configure it with a priority of 0, mainly to prevent it from becoming the primary node, which is particularly useful in multi-data center deployments.

3) priority values range from 0 to 100 (0 means not participating in the election). In a replication cluster, the high priority node becomes the primary node. If we have three nodes in the original cluster, the priority of the master node is 2, and the priority of the other two slave nodes is 1, when we add a new MongoDB instance to the cluster and set its priority to 4, the instance will automatically snatch the Primary to the local machine after joining the cluster.

Arbitration node architecture

In the figure above, three members form a replication cluster

A master library: responsible for all write and change operations of the entire cluster

A slave library: agree with master node data through oplog logs

An Airbiter node, in the election, only votes, cannot become the main database, and does not copy any data of Primary, so this architecture can only provide a completed copy Secondary,Arbiter only needs very few resources, at the cost of limited redundancy and fault tolerance. When the Primary node fails, Aribiter will head the votes to Secondary, making it a Primary node. If the Primary node fails again, the cluster will not be available, and the Arbiter node does not store any data.

There are other node members in the cluster, but we use less, so it is not mentioned in this article. You can consult the official document: https://docs.mongodb.com/manual/core/replica-set-members/

Deployment of replication set cluster environment

Environment description

This time, multiple instances of one device are used. If you are going to deploy on multiple devices, you need to consider the following: 1) whether the clock is consistent; 2) whether the network is unobstructed; 3) whether the SElinux is off or whether the policy is open; 4) whether the environment is consistent.

[root@MongoDB] # lsb_release-a LSB Version:: core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch Distributor ID: CentOS Description: CentOS Linux release 7.6.1810 (Core) Release 7.6.1810 Codename: Core [root@MongoDB ~] # hostname-I 10.211.55.12 192.168.0.100 fdb2:2c26:f4e4:0:21c:42ff:fedf:4d85

Preparation in advance

# create user group useradd mongod echo 'abcdef' | passwd-- stdin mongod # download MongoDB wget https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-rhel70-4.2.0.tgz # number of file openings added and number of mongod user process connections cat > > / etc/security/limits.conf / sys/kernel/mm/transparent_hugepage/enabled echo never > / sys/kernel/mm/transparent_hugepage/defrag # automatically modify when booting Cat > > / etc/rc.local / sys/kernel/mm/transparent_hugepage/enabled fi if test-f / sys/kernel/mm/transparent_hugepage/defrag Then echo never > / sys/kernel/mm/transparent_hugepage/defrag fi EOF after this step is completed # it is officially stated that MongoDB needs the dependent yum install libcurl openssl-y # of the following two libraries to extract and copy the program files to the bin directory mkdir / usr/local/mongodb tar xf mongodb-linux-x86_64-rhel70-4.2.0.tgz cp-rf mongodb-linux-x86_64-rhel70-4.2.0/bin/ / usr/local/ Mongodb/ chown-Rf mongod.mongod / usr/local/moongodb/ # add Program Environment cat > > / etc/profile mongod.conf use admin > config= {_ id:'abcops_repl' Members: [{_ id: 0, host: '10.211.55.12 id:' 10.211.55.12 host: '10.211.55.12 host 27018}, {_ priorityl1}, {_ id: 2, host:' 10.211.55.12 purge 27019 precept arbiterOnlylane true} ]} > rs.initiate (config) # above parameters resolve use admin: enter admin database config: configure replication set _ id:'abcops_repl': specify replication set group name Consistent with the replSetName parameter in the configuration file members: specified function, cannot change _ id: set the ID number of the group member, which can be customized. Here, 0,1,2 host: specify the IP address and port to join the replication set member. We specify the bindIp as 10.211.55.12 in the configuration file. You cannot write 127.0.0.1 here. You must write the address priority specified by bind_Ip: specify priority 0-100. the highest priority is Primary node, and the priority is optional. If you do not specify, default is 1 arbiterOnly: whether to enable arbitration node true/false rs.initiate (config): initialize replication set configuration

The above parameters are shown below, which can be used as a reference.

The picture starts with SECONDARY, which represents that the replica set cluster is electing Primary nodes for about 5 seconds. After the election is successful according to the election mechanism, the SECONDARY status of the primary node becomes PRIMARY.

Copy set common commands

1) check who is the primary node

Abcops_repl:PRIMARY > db.isMaster ()

2) View the configuration of the members in the current replication set cluster

Abcops_repl:PRIMARY > rs.conf ()

3) View the status of replication set cluster members

Abcops_repl:PRIMARY > rs.status ()

4) before adding a node to a replication set, the name of the replSetName replication set in the configuration of the instance must be the same as that of the cluster

Abcops_repl:PRIMARY > rs.add ("10.211.55.12 purl 27020")

5) add arbitration node

Abcops_repl:PRIMARY > rs.addArb ("10.211.55.12 purl 27020")

6) remove a node from the replication set

Abcops_repl:PRIMARY > rs.remove ("10.211.55.12 purl 27020")

7) check oplog log time and size

Abcops_repl:PRIMARY > rs.printReplicationInfo () configured oplog size: 4096MB log length start to end: 2422secs (0.67hrs) oplog first event time: Wed Sep 11 2019 12:22:13 GMT+0800 (CST) oplog last event time: Wed Sep 11 2019 13:02:35 GMT+0800 (CST) now: Wed Sep 11 2019 13:02:37 GMT+0800 (CST)

8) downgrade the server. This operation can only be performed on PRIMARY. By executing the rs.stepDown command, the current primary server is actively downgraded to a standby node, which is 120 units per second. This strength cannot select itself as the PRIMARY role within 120 seconds. After 120 seconds, it will reoccupy the PRIMARY node because of its high priority.

Abcops_repl:PRIMARY > rs.stepDown

9) allow queries on the Secondary node and operate on the replica node

Rs.slaveOk ()

10) View current connection

Db.getMongo ()

Modify priority

Modify the priority of 27018 to 3 to exceed the priority of 27017 instances to win the PRIMARY role. This operation needs to be performed on PRIMARY.

Abcops_repl:PRIMARY > config=rs.conf () abcops_repl:PRIMARY > config.members [1] .priority = 3 3 abcops_repl:PRIMARY > rs.reconfig (config) {"ok": 1, "$clusterTime": {"clusterTime": Timestamp (1568179129, 1), "signature": {"hash": BinData (0, "AAAAAAAAAAAAAAAAAAAAAAAAAAA=") "keyId": NumberLong (0)}}, "operationTime": Timestamp (1568179129, 1)} abcops_repl:PRIMARY > rs.conf () abcops_repl:SECONDARY > db.isMaster () # the above parameters parse config=rs.conf (): read the existing configuration into the variable to store config.members [1] .priority = 3: modify the value in the variable 1 refers to the order in which the nodes are seen in the execution of rs.conf (), not the ID number. The order seen by rs.conf () is sorted from 0, and the sorting of the three replica sets is 0-3 rs.reconfig (config): synchronize the modified data to the configuration to make the changes take effect rs.conf (): check the current configuration, you can see the priority oh db.isMaster (): see who is the Primary node

Copy test

1) insert data

# Connect the current Primary node / usr/local/mongodb/bin/mongo-- host 10.211.55.12-- port 27018 # enter the abcops database Insert the following data in JSON format abcops_repl:PRIMARY > use abcops abcops_repl:PRIMARY > db.documents.insert in the documents document ({name: "xuweiliang", age: 25, Job: "DevOps"}) # View the data in the documents document abcops_repl:PRIMARY > db.documents.find () {"_ id": ObjectId ("5d78863768fbf9eac4704232"), "name": "xuweiliang", "age": 25 "Job": "DevOps"} # View replication node status abcops_repl:PRIMARY > rs.printSlaveReplicationInfo () source: 10.211.55.12 abcops_repl:PRIMARY 27017 syncedTo: Wed Sep 11 2019 13:30:42 GMT+0800 (CST) 0 secs (0 hrs) behind the primary

2) Log in to the Secondary node to view

/ usr/local/mongodb/bin/mongo-- host 10.211.55.12-- port 27017 abcops_repl:SECONDARY > rs.slaveOk () # run the replica node to query abcops_repl:SECONDARY > show dbs # to view the database of the current node abcops 0.000GB admin 0.000GB config 0.000GB local 0.000GB abcops_repl:SECONDARY > use abcops # abcops database has been slave to the master node Synchronize to this switched to db abcops abcops_repl:SECONDARY > db.getCollectionNames () # the following three consecutive commands are to view the document entered into the abcops library ["documents"] abcops_repl:SECONDARY > show collections documents abcops_repl:SECONDARY > show tables documents abcops_repl:SECONDARY > db.documents.find () # View the contents of the document {"_ id": ObjectId ("5d78863768fbf9eac4704232") "name": "xuweiliang", "age": 25, "Job": "DevOps"}

Create an account in a replication set

/ usr/local/mongodb/bin/mongo-- host 10.211.55.12-- port 27018 abcops_repl:PRIMARY > use admin abcops_repl:PRIMARY > db.createUser ({user:'abcops', pwd:'123456', roles: [{role: "root", db: "admin"}]}) Successfully added user: {"user": "abcops" "roles": [{"role": "root", "db": "admin"}]} # View all created user information abcops_repl:PRIMARY > show users

Description of permissions in the user

Permission description Read allows users to read specified database readWrite allows users to read and write specified database dbAdmin allows users to specify management functions in the specified database, such as (index creation, deletion, viewing statistics access system.profile) userAdmin allows users to write to the system.users collection, you can find specified data to create, delete and manage users clusterAdmin is only available in the admin database Administrative permissions readAnyDatabase for all sharding and replication set related functions are available only in admin databases, read permissions for all databases readWriteAnyDatabase are available only in admin databases, read and write permissions for all databases userWriteAnyDatabase are available only in admin databases, userAdmin permissions dbAdminAnyDatabase for all databases are available only in admin databases, and dbAdmin permissions for all databases are available only in admin databases Super Admin

Add permission authentication to a replication set cluster

In the replica set, we use keyfile files for permission authentication, and all members in the replica set must use the same keyfile.

Add a security authentication configuration

All three instances must be configured.

Cat > > / usr/local/mongodb/27017/conf/mongod.conf > / usr/local/mongodb/27018/conf/mongod.conf > / usr/local/mongodb/27019/conf/mongod.conf. / keyfile

2) copy the keyfile file to another instance

#! / bin/bash for i in 27017 27018 27019 do\ cp / home/mongod/keyfile / usr/local/mongodb/$i/conf/ done

3) modify keyfile permissions keyfile file permissions must be X00, no permissions can be assigned to group and other members, otherwise the instance cannot be started

#! / bin/bash for i in 27017 27018 27019 do chmod 400 / usr/local/mongodb/$i/conf/keyfile done

4) restart all instances

#! / bin/bash for i in 27017 27018 27019 do / usr/local/mongodb/bin/mongod-- shutdown-f / usr/local/mongodb/$i/conf/mongod.conf sleep 3s / usr/local/mongodb/bin/mongod-f / usr/local/mongodb/$i/conf/mongod.conf done

Authentication verification

Login authentication can specify a user name and password when connecting, or you can connect to the database before authentication

1) log in to the specified user password

/ usr/local/mongodb/bin/mongo-- host 10.211.55.12-- port 27018-- username abcops-p 123456 abcops_repl:PRIMARY > show dbs abcops 0.000GB admin 0.000GB config 0.000GB local 0.000GB

2) Log in first, then verify

Abcops_repl:PRIMARY > use admin # must be switched to the admin library before you can verify switched to db admin abcops_repl:PRIMARY > db.auth ('abcops','123456') # authentication username and password. If authentication succeeds, return 1, otherwise return 0 1 abcops_repl:PRIMARY > show dbs abcops 0.000GB admin 0.000GB config 0.000GB local 0.000GB abcops_repl:PRIMARY > db admin

/ usr/local/mongodb/bin/mongo-- host 10.211.55.12-- port 27017 abcops_repl:SECONDARY > rs.slaveOk () abcops_repl:SECONDARY > use admin switched to db admin abcops_repl:SECONDARY > db.auth ('abcops','123456') 1

Client authentication

We can find a SQL management tool to connect to the library

You can see the abcops library I created, a document and three fields

So much for sharing the principle of replication set cluster in MongoDB. I hope the above content can be helpful to everyone and learn more knowledge. If you think the article is good, you can share it for more people to see.

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.