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

Replication set introduction replication cluster architecture voting mechanism replication cluster member description priority 0 replica set member arbitration node architecture replication set cluster environment deployment environment description pre-preparation environment configuration file start MongoDB instance configuration replication set replication set common commands modify priority replication test create account user permissions in replication set add permission recognition to replication set cluster Introduction to Certificate add Security Authentication configuration keyfile File Operation Authentication Verification client Verification reference 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

Cymbal

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.

Cymbal

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 examination

MongoDB replication set members send heartbeats to all members except themselves and process the response information, so each node maintains the status information of all other nodes seen by the node, and the node determines whether it needs to update the new Primary according to 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:

A replacement election is initiated when the Secondary node weight (Priority) is higher than that of the Primary node; when the Secondary node finds that there is no Primary in the cluster, it initiates the election; when the Primary node cannot access most of the members, the downgrade operation disconnects the connection and terminates the user request; the heartbeat detection result of the replica set member changes, 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.

Election initiation

The node initiating the election first needs to make some condition judgment. 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:

Whether to see whether there is a Majority online Priority greater than 0 in the replication set, not arbiter itself opTime cannot lag behind the cluster programs stored by the latest node for more than 10 seconds according to the latest 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. In the election process, the replica set has no master node, and all members are read-only. The election process is very complicated, and it 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

Assuming that the number of voting members in the replica set is N, then most of them are N + 1. When the number of surviving members in the replica set is less than most, 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 replication 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 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.

Arbiter

The 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.

Priority0

The 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)

Vote0

In 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.

Hidden

The 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.

Delayed

The 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

Cymbal

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

Cymbal

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.

Cymbal

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/

Replication set cluster environment deployment 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 closed or whether the policy is open

4) whether the environment is consistent

[root@MongoDB] # lsb_release-aLSB 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-noarchDistributor ID: CentOSDescription: CentOS Linux release 7.6.1810 (Core) Release: 7.6 .1810Codename: Core [root@MongoDB ~] # hostname-I10.211.55.12 192.168.0.100 fdb2:2c26:f4e4:0:21c:42ff:fedf:4d85 preliminary preparation # create user group useradd mongodecho 'abcdef' | passwd-- number of stdin mongod# downloads MongoDBwget https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-rhel70-4.2.0.tgz# add file openings and mongod user process connections cat > > / etc/security / limits.conf / sys/kernel/mm/transparent_hugepage/enabledecho never > / sys/kernel/mm/transparent_hugepage/defrag# boot automatically modify cat > > / etc/rc.local / sys/kernel/mm/transparent_hugepage/enabledfiif test-f / sys/kernel/mm/transparent_hugepage/defrag Then echo never > / sys/kernel/mm/transparent_hugepage/defragfiEOF 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/mongodbtar xf mongodb-linux-x86_64-rhel70-4.2.0.tgzcp-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, 2host: specify the IP address and port to join the replication set member. We specified bindIp as 10.211.55.12 in the configuration file, so 127.0.0.1 cannot be written here. It must be written as the address specified by bind_Ip: priority: specify priority 0-100. The node with the highest priority is the Primary node, and the priority is optional. If it is not specified, the default is 1arbiterOnly: whether to enable the arbitration node true/falsers.initiate (config): initialize the replication set configuration

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

Cymbal

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) add a node to the replication set

Before adding a node, 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: 4096MBlog 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, 120 units in s. This strength cannot select itself as the PRIMARY role within 120 seconds, and it will re-occupy the PRIMARY node after 120 seconds because of its own higher priority.

Abcops_repl:PRIMARY > rs.stepDown

9) allow queries on Secondary nodes

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 = 33abcops_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 () # parse the above parameters 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-3rs.reconfig (config): synchronize the modified data to the configuration and 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 replication test

1) insert data

# Connect the current Primary node / usr/local/mongodb/bin/mongo-- host 10.211.55.12-- port 270 enter the abcops database Insert the following data in JSON format abcops_repl:PRIMARY > use abcopsabcops_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 27017abcops_repl:SECONDARY > rs.slaveOk () # running replica node can query abcops_repl:SECONDARY > show dbs # to view the current node's database abcops 0.000GBadmin 0.000GBconfig 0.000GBlocal 0.000GBabcops_repl:SECONDARY > use abcops # abcops database has been synchronized from the primary node to this switched to db Abcopsabcops_repl:SECONDARY > db.getCollectionNames () # the following three consecutive commands are to view documents entered into the abcops library ["documents"] abcops_repl:SECONDARY > show collectionsdocumentsabcops_repl:SECONDARY > show tablesdocumentsabcops_repl:SECONDARY > db.documents.find () # View the contents of the document {"_ id": ObjectId ("5d78863768fbf9eac4704232") "name": "xuweiliang", "age": 25, "Job": "DevOps"} create an account in the replica set

1) Connect to the primary node and create a user

For the users, permissions and roles created below, please refer to the user rights description below

/ usr/local/mongodb/bin/mongo-- host 10.211.55.12-- port 27018abcops_repl:PRIMARY > use adminabcops_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 > description of permissions in show users users 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 For example, (index creation, deletion, viewing statistics access system.profile) userAdmin allows users to write to the system.users collection, you can find the specified data to create, delete and manage the user clusterAdmin is only available in the admin database, the administrative rights that give the user all shard and replication set related functions readAnyDatabase is only available in the admin database, and the read permission readWriteAnyDatabase of all databases is only available in the admin database. Give users read and write permissions for all databases userWriteAnyDatabase is only available in admin databases, userAdmin permissions for all databases dbAdminAnyDatabase is only available in admin databases, dbAdmin permissions for all databases are available only in admin databases, and super administrators add permission authentication for replication set clusters

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/bashfor 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, and no permissions can be assigned to group and other members, otherwise the instance cannot be started

#! / bin/bashfor i in 27017 27018 27019 do chmod 400 / usr/local/mongodb/$i/conf/keyfiledone

4) restart all instances

#! / bin/bashfor 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.confdone 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 123456abcops_repl:PRIMARY > show dbsabcops 0.000GBadmin 0.000GBconfig 0.000GBlocal 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 adminabcops_repl:PRIMARY > db.auth ('abcops','123456') # authentication username and password. If authentication succeeds, return 1, otherwise return 01abcops_repl:PRIMARY > show dbs abcops 0.000GBadmin 0.000GBconfig 0.000GBlocal 0.000GBabcops_repl:PRIMARY > dbadmin

3) verify in the repository

The standby database can only be queried. Do not do any operations on the standby database.

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

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

Cymbal

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

Cymbal

reference

Thank you,

Https://docs.mongodb.com/manual/core/replica-set-members/

Http://docs.mongodb.org/manual/tutorial/force-member-to-be-primary/

Https://www.mongodb.org.cn/manual/replication/

Https://blog.csdn.net/wentyoon/article/details/78986174

Https://www.jianshu.com/p/55e2dafaccd0

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.