MongoDB Replica Set

MongoDB's current high-availability architecture is mainly master-slave, replication sets, and shards, pure master-slave technology is almost eliminated, the overall stability and reliability of the replication set is better than the master and slave, so now more will use the replica set. In the following practice, we will implement the replication set through a multi-instance approach. And will resolve the difficulties encountered during the construction process.

I. BASIC ENVIRONMENT and planning

Operating system: CentOS 6.7

MongoDB version: 3.4.5

Instance deployment scenario:

Host IP	Data Catalog	Log file	Port
127.0.0.1	/data/mongodb/data/m17	/data/mongodb/logs/mongo17.txt	28017
127.0.0.1	/data/mongodb/data/m18	/data/mongodb/logs/mongo18.txt	28018
127.0.0.1	/data/mongodb/data/m19	Data/mongodb/logs/mongo19.txt	28019

Because of the deployment on the same host, there is no need to consider firewall configuration and management. Most production environments have professional hardware firewalls (Cisco, Huawei) and other manufacturers of hardware firewall equipment, some of the public cloud is also a number of firewall products, so iptables in the production environment should be able to play a icing on the cake, in the whole process does not consider this piece.

Second, the principle and optimization of the replica set

2.1 Replica Set principle

650) this.width=650; "src=" Https://s1.51cto.com/wyfs02/M01/9B/4B/wKioL1lg-nLBlKdhAABzj7Wi8sQ743.png "title=" Mongodb1.png "alt=" Wkiol1lg-nlblkdhaabzj7wi8sq743.png "/>

Replica set (Replica set) is a master-slave cluster with automatic fault recovery capability. The most obvious difference between master-slave structure and replica set is that the replica set has no fixed primary node, and when the node fails, it can elect a new master node, which greatly improves the stability of the data storage in the whole system. The whole cluster elects a master node, and when the primary node fails, it elects another node as the primary node.

650) this.width=650; "src=" Https://s1.51cto.com/wyfs02/M02/9B/4B/wKiom1lg-nLC4iSWAACbwDcoIiY760.png "title=" Mongo3.png "alt=" Wkiom1lg-nlc4iswaacbwdcoiiy760.png "/>

A replica set will always have an active node (Primary) and one or more backup nodes (secondary), and a replica set can also have a role of arbiter (arbiter), which does not hold data . The quorum node uses minimal resources and does not require hardware devices, cannot deploy arbiter in the same dataset node, can be deployed on other application servers or monitoring servers , or can be deployed in a separate virtual machine. To ensure that there are an odd number of voting members (including primary) in the replication set, the quorum node needs to be added as a vote, otherwise primary will not automatically switch primary when it is not running.

  in earlier versions such as MongoDB2.6, copy set data nodes participating in the elections The can only have 7 of the data nodes of a replica set to 12 by changing the data node properties, but the remaining 5 non-voting member (Non-voting members) , Non-voting members are copy a backup copy of the centralized data, not voting, but can be voted on or become the master node. when our replication set exceeds 11, can use the traditional master and slave methods without limitation.

650) this.width=650; "src=" Https://s4.51cto.com/wyfs02/M02/9B/4B/wKioL1lg-nOTqbTKAAB70IgeqGw358.png "title=" Mongodb2.png "alt=" Wkiol1lg-notqbtkaab70igeqgw358.png "/>

650) this.width=650; "src=" Https://s4.51cto.com/wyfs02/M02/9B/4B/wKiom1lg-nPB9TQ7AABoZzk5PcE206.png "title=" Mongodb4.png "alt=" Wkiom1lg-npb9tq7aabozzk5pce206.png "/>

2.2 Features of the copy set

Features of replication sets

• Data Consistency enables multiple processes/servers to maintain the same asynchronous synchronization (affected by disk, network, data size) in some way

• The Master is the only 1 master capable of reading and writing, the rest can only be read, while the master is not fixed, unlike MySQL with a dual-master architecture,

• most principles cluster survival node is less than or equal to One-second when the cluster is not writable and readable only

• secondary node does not support write MySQL readonly from the library is not valid for accounts with super privileges

• Automatic disaster tolerance compared to traditional master-slave replica sets

• Does not support the ability to sync only a subset of libraries from MySQL

• Replication between replica sets is done through oplog logs . Backup node by querying this collection, you can know what needs to be replicated

• Oplog is a fixed collection in the local library in the node, and by default Oplog the 5%.oplog with the size of the free disk is capped collection, so when the Oplog space is fully occupied, Overwrites the log that was originally written.

• Changing the size of the Oplog document directly alters the size of the local disk space. You can set the Oplogsize parameter in the configuration file to specify the size of the Oplog document, for example, oplogsize=1024 units default to M Each local document has a disk space of 2G, set less than 2G, and the initialization is still 2G in size, such as oplogsize=1024 above, but the local.01 size created is still 2G.

• If the backup node is unfortunately hung up, the copy operation may be repeated when the replication process is preceded by writing the data and then writing Oplog. But MongoDB has considered this problem during the design process. When the same operation executes multiple times in Oplog, it is executed only once.

• If the synchronization speed of the standby node is far from the data written by Oplog of the master node, and the Oplog of the master node is overwritten. This way, you may not be able to synchronize the overwritten data ( this is not resolved temporarily, only by backing up the primary node's data and then re-synchronizing ).

• Each member has a heartbeat to see the status of the other nodes, and a heartbeat is detected every 2 seconds.

• When the primary node goes down, each node chooses the next primary node by election

2.3 Implementation steps for a replica set

1. Planning ports, data directories, log directories, etc. can be customized to the configuration file;

2. Prepare validation for security needs (auth validation and keyfile validation)

   auth validation differs from keyfile validation:Auth is more of a standalone or single-instance verification, one of the most common security hardening methods of MongoDB, enabling authentication, enabling management of different libraries and users, The KeyFile is primarily used for authentication between clusters of different examples, with the following characteristics

   KeyFile Features:

Base 64 encoding set only identifies [A-Z-a-z +/] content, ( legendary no specific test )

Length preferably less than 1000byte

Permission issues allow the maximum permissions to be 600 so you need to be aware of the owner and the owning group in the installation, configuration, startup, and so on.

Error Resolution: Mongod-f CONF/29017.CNF #启动about to fork child process, waiting until server was ready for connections.forked Pro  Cess:2681error:child process failed, exited with error number 1 viewing log: 2017-06-01t00:10:39.307+0800 I CONTROL [main] * * * * * * SERVER restarted *****2017-06-01t00:10:39.490+0800 I ACCESS [main] permissions On/datamongo/key/.keyfile is too open

Discovery permissions are too large to start properly, change the permissions for KeyFile to 600 resolution.

The following contents of a Space, tab, and line break in a keyfile file can be equated

This name Docker Thisnamedocker

Recommended methods for generating keyfile

OpenSSL rand-base N (bytes)

[[email protected] log]# openssl   rand  -base64    78znripfguw==[[email protected] log]# openssl   rand  -base64    10IAcXv1pLK67/qw==[[email protected] log]# openssl   rand   -base64   12LhhGR4GPk0dlTsLz[[email protected] log]# openssl    rand  -base64    512vgc2wexhxefk3f1p1fnsnjcsp/ wwng3bugoccgllupvlsszgra73pml4ju+35uwf45wamitz2emip2wg6qdqld3n2odhz6zf49vtpoal8pok6hfvvq+kr6fuewi6vrcufa/ xnnucr69wijilrkqigfjze3n+j3qexzbwfx28zobleoyjuseiqfp3fod+xiifewenflvaknuflts13ad9g3pornxvfsyqf1ah8rf1y+ i9vbihdhynmpnbxtfk+sh+e8mg4ih2/ffsvlsn4fdysz3znd2tfogk9jhk6zdqo+drm0yf6wl4cxmahhkwdbpsfayjmis3sltwloshwqt4q+ xtao4jsynt4bo9mf8tyib4zz2s6xiejuv+fbelygjoavz6f39bhu0qeuwnl8wmhb8ycxanzry/a9ofp3zaaegz6fuh6zzje3t5oe2ib+ Ef3vqzrsf/0bbg3hm5e6zitip9+hf4c1+ltq5bmdlakioevc3kafq0q34jlfxjc4/maxaserqcvznlwb+3zxybjippqxloevetoxoggmdkzaurz5+g8iihpeoizo5iugt4wwgki2ktnmu1l+wpqhpdudw2/ Hpvgdd5ahwedyu7mc1ofacvg53abxca2qi5g3iu1lvi12fdvsjrfo7bmm34rkxigfuaih4kqump+unllso=[[email protected]  log]# openssl   rand  -base64    512 >.keyfile [[email protected] log]#

The "=" number in the file generated according to the above content recognition method is not recognized, and special handling is required.

3. Start the replica set

At startup, we can give mongd with a lot of parameters, but this is more troublesome, each start to develop a lot of parameters, we recommend that we write configuration files;

#MOngoDB  config port=27017                           #启动监听端口dbpath =/data/mongodb/data /m17      #数据存储目录logpath =/data/mongodb/logs/mongo17.txt   # Log file directory logappend=true                  #日志以追加的方式写入pidfilepath =/datamongo/data/m17/27017.pid  fork=true                        # Open oplogsize=1024               after running    #初始化oplog的大小为1024M  replSet=BOOL                      #副本集名称为BOOL    Important parameters   must be unified keyfile=/ datamongo/key/.keyfile     #keyFile验证文件的位置setParameter =enablelocalhostauthbypass=1   #避免在没有创建用户之前的   Permission issues for authentication 

Setparameter=enablelocalhostauthbypass=1 Characteristics of this parameter setting

• In a MongoDB instance, no user is allowed to take effect

• Allow only native (localhost) logins and cannot use IP logins (including 127.0.0.1)

• Expires when the instance is created with the first user created

• The first user created by an instance must belong to the Admin library and the user must have permission to create another user

4. Initialize the replica set

Randomly enter one of the services, enter the Admin library to initialize it,

Use Adminvar conf= ({_id: "BOOL", members:[{"_id": 0,host: "127.0.0.1:27017", priority:1},{"_id": 0,host: " 127.0.0.1:27018 ", priority:2},{" _id ": 0,host:" 127.0.0.1:27019 ", Priority:3}]}) rs.initiate (conf) execution OK

Attention:

priority is an optional parameter that determines the precedence of the node in the replica set as the primary node, the higher the number, the higher the priority, and the reasonable use of this parameter when there is a performance difference between our different hosts. When you don't want a node to never be a primary node, you can set the priority parameter to 0

Attachment:

Init script

#/bin/bash############################### #describtion ######################## #date  2017-07-08#author   peng#mail:[email protected]host_ip=127.0.0.1data_dir=/data/mongodb/data/logs_dir=/data/ mongodb/logs/mongod_path= /home/mongodb/mongodb/mongodb-3.4.5/bin/na=db2mkdir  -p  ${ Data_dir}m17     ${data_dir}m18   ${data_dir}m19  ${logs_dir }${mongod_path}mongod   --dbpath ${data_dir}m17 --logpath  ${logs_dir}logs1    --port  28017 --smallfiles  --replset ${na} --fork${ Mongod_path}mongod   --dbpath ${data_dir}m18 --logpath  ${logs_dir}logs2    --port  28018 --smallfiles  --replset ${na} --fork${ Mongod_path}mongod   --dbpath ${data_dir}m19 --logpath  ${logs_dir}logs3    --port  28019 --smallfiles  --replset ${na} --fork${mongod_path}mongo --port 28017   <<eofuse adminvar db2config={_id: "DB2", Members:[{_id:0,host: "${HOST_IP}:28017"},{_ Id:1,host: "${host_ip}:28018"},{_id:2,host: "${host_ip}:28019"}]}rs.initiate (db2config);

Precautions:

After we have set up keyfile authentication in our replica set, after we initialize the Priamary node, we want to look at the libraries and find that the permissions are not enough, then we consider creating the user

 mongo   127.0.0.1:29017/adminMongoDB shell version v3.4.5connecting  To: mongodb://127.0.0.1:29017/adminmongodb server version: 3.4.5bool:primary> show   dbs2017-06-01t01:27:04.487+0800 e query    [thread1] error:  listDatabases failed:{         "OK"  : 0,          "ErrMsg"  :  "not authorized on admin to  execute command { listdatabases: 1.0 } ",          "Code"  : 13,         "codename"  :  " Unauthorized "} :[email protected]/mongo/shell/utils.js:25:13[email protected]/mongo/shell/ Mongo.js:62:1[email protected]/mongo/shell/utils.js:769:19[email protected]/mongo/shell/utils.js : 659:15@ (SHELLHELP2): 1:1 Then we can create aUser, multiple test   copy sets when the users are not created, the Setparameter=enablelocalhostauthbypass=1 parameter comments are restarted, directly to the Admin library to create the user Db.createuser (...   {user: "Root",...   pwd: "123123",...  roles:[... {role: "Root", DB: "admin"}...   ]...   }... ) successfully added user: {          "User"  :  "root",         "roles"  :  [                {                           "Role"  :  "root",                          "DB"  :  " Admin "                }         ]} 

Reference documents

http://blog.csdn.net/leftfist/article/details/39583585

http://blog.csdn.net/kk185800961/article/details/45791903

This article from "adhere to the Dream" blog, reproduced please contact the author!

MongoDB Replica Set