Program options
Mongodb's three clustering methods: Replica Set / Sharding / Master-Slaver.
-
Replica Set
In fact, in simple terms, the cluster contains multiple copies of data to ensure that the primary node fails, and the standby node can continue to provide data services. The premise is that the data needs to be consistent with the primary node.
Mongodb(M) represents the master node, Mongodb(S) represents the standby node, and Mongodb(A) represents the arbitration node. The active and standby nodes store data, and the arbitration node does not store data. The client connects to the primary node and the standby node at the same time, and does not connect to the arbitration node.
By default, the master node provides all additions, deletions, and changes services, and the standby node does not provide any services. However, the standby node can be set to provide query services, which can reduce the pressure on the primary node. When the client performs data query, the request is automatically transferred to the standby node. This setting is called Read Preference Modes, and the Java client provides a simple configuration method that does not need to operate directly on the database.
The arbitration node is a special kind of node that does not store data itself. Its main function is to decide which standby node will be promoted to the primary node after the primary node hangs up, so the client does not need to connect to this node. Although there is only one standby node, an arbitration node is still required to upgrade the standby node level. At first, I didn’t believe that there must be an arbitration node, but if I tried without an arbitration node, the primary node is connected to the standby node or the standby node, so we still need it.
-
Sharding
Similar to Replica Set, an arbitration node is required, but Sharding also requires configuration nodes and routing nodes. As far as the three cluster construction methods are concerned, this is the most complicated. The deployment diagram is as follows:
-
Master-Slaver
This is the simplest cluster construction, but it can't be regarded as a cluster to be precise, it can only be said to be active and standby. And the official has not recommended this method.
-
Overview
Master-SlaverOfficials no longer recommend this approach. Do not use!ShardingToo complicated, considering the project situation, do not adopt!Replica SetClustering, high availability, and deployment are also simple. In this case, the following describes the deployment of this situation!
Replica SetDeploy based on
-
Prepare
Since it is deployed on the local virtual machine, only one machine (10.211.55.10) is used, and 4 ports are opened (master: 27017, slave: 27018, 27019, arbiter: 27020)
-
Configuration file (please refer to Appendix 1 for the specific attribute explanation of the mongodb configuration file)
-
master
# master.conf dbpath=/opt/mongodb/data/master logpath=/opt/mongodb/logs/master.log pidfilepath=/opt/mongodb/logs/master.pid directoryperdb=true logappend=true replSet=ynzw bind_ip=10.211.55.10 port=27017 oplogSize=10000 fork=true noprealloc=true -
slaver1
# slaver1.conf dbpath=/opt/mongodb/data/slaver1 logpath=/opt/mongodb/logs/slaver1.log pidfilepath=/opt/mongodb/logs/slaver1.pid directoryperdb=true logappend=true replSet=ynzw bind_ip=10.211.55.10 port=27018 oplogSize=10000 fork=true noprealloc=true -
slaver2
# slaver2.conf dbpath=/opt/mongodb/data/slaver2 logpath=/opt/mongodb/logs/slaver2.log pidfilepath=/opt/mongodb/logs/slaver2.pid directoryperdb=true logappend=true replSet=ynzw bind_ip=10.211.55.10 port=27019 oplogSize=10000 fork=true noprealloc=true -
arbiter
# arbiter.conf dbpath=/opt/mongodb/data/arbiter logpath=/opt/mongodb/logs/arbiter.log pidfilepath=/opt/mongodb/logs/arbiter.pid directoryperdb=true logappend=true replSet=ynzw bind_ip=10.211.55.10 port=27020 oplogSize=10000 fork=true noprealloc=true
-
-
Start 4 nodes
/opt/mongodb/bin/mongod -f /opt/mongodb/conf/master.conf /opt/mongodb/bin/mongod -f /opt/mongodb/conf/slaver1.conf /opt/mongodb/bin/mongod -f /opt/mongodb/conf/slaver2.conf /opt/mongodb/bin/mongod -f /opt/mongodb/conf/arbiter.conf -
Configure active, standby, and arbiter nodes
-
The client connects to any node mongodb in the master and slave
/opt/mongodb/bin/mongo 10.211.55.10:27017 -
start configuration
> use admin > cfg = { _id: "ynzw", members: [ { _id: 0, host: '10.211.55.10:27017', priority: 3 }, { _id: 1, host: '10.211.55.10:27018', priority: 2 }, { _id: 2, host: '10.211.55.10:27019', priority: 1 }, { _id: 3, host: '10.211.55.10:27020', arbiterOnly: true } ] }; > rs.initiate(cfg)cfg can be any name, of course, it is best not to be a keyword of mongodb, conf, config can be. The outermost _id represents the name of the replica set, and members contain the addresses and priorities of all nodes. The one with the highest priority becomes the master node, which is 10.211.55.10:27017 here. It is important to note that for the arbiter node, a special configuration is required - arbiterOnly:true. This must not be missed, otherwise the active-standby mode will not take effect.
-
test
The effective time of the configuration will be longer or shorter according to different machine configurations. If the configuration is good, it will take effect within ten seconds, and some configurations will take a minute or two. If it takes effect, executing the rs.status() command will see the following information:
ynzw:SECONDARY> rs.status() { "set" : "ynzw", "date" : ISODate("2017-05-26T06:47:32.069Z"), "myState" : 1, "term" : NumberLong(8), "heartbeatIntervalMillis" : NumberLong(2000), "members" : [ { "_id" : 0, "name" : "10.211.55.10:27017", "health" : 1, "state" : 1, "stateStr" : "PRIMARY", "uptime" : 24, "optime" : { "ts" : Timestamp(1495781239, 2), "t" : NumberLong(8) }, "optimeDate" : ISODate("2017-05-26T06:47:19Z"), "electionTime" : Timestamp(1495781239, 1), "electionDate" : ISODate("2017-05-26T06:47:19Z"), "configVersion" : 1, "self" : true }, { "_id" : 1, "name" : "10.211.55.10:27018", "health" : 1, "state" : 2, "stateStr" : "SECONDARY", "uptime" : 18, "optime" : { "ts" : Timestamp(1495781239, 2), "t" : NumberLong(8) }, "optimeDate" : ISODate("2017-05-26T06:47:19Z"), "lastHeartbeat" : ISODate("2017-05-26T06:47:31.424Z"), "lastHeartbeatRecv" : ISODate("2017-05-26T06:47:31.247Z"), "pingMs" : NumberLong(0), "syncingTo" : "10.211.55.10:27017", "configVersion" : 1 }, { "_id" : 2, "name" : "10.211.55.10:27019", "health" : 1, "state" : 2, "stateStr" : "SECONDARY", "uptime" : 18, "optime" : { "ts" : Timestamp(1495781239, 2), "t" : NumberLong(8) }, "optimeDate" : ISODate("2017-05-26T06:47:19Z"), "lastHeartbeat" : ISODate("2017-05-26T06:47:31.424Z"), "lastHeartbeatRecv" : ISODate("2017-05-26T06:47:31.734Z"), "pingMs" : NumberLong(0), "syncingTo" : "10.211.55.10:27018", "configVersion" : 1 }, { "_id" : 3, "name" : "10.211.55.10:27020", "health" : 1, "state" : 7, "stateStr" : "ARBITER", "uptime" : 18, "lastHeartbeat" : ISODate("2017-05-26T06:47:31.424Z"), "lastHeartbeatRecv" : ISODate("2017-05-26T06:47:30.437Z"), "pingMs" : NumberLong(0), "configVersion" : 1 } ], "ok" : 1 } ynzw:PRIMARY>If the configuration is in effect, it will contain the following information:
"stateStr" : "RECOVERING"
-
Client connection
-
Use
spring-data-mongodb+mongo-java-driverto operate mongodb -
10.211.55.10:27017,10.211.55.10:27018,10.211.55.10:27019are master and slave nodes. Since the arbitration node does not store data, no connection is required. -
code
List<ServerAddress> servers = new ArrayList<>(addresses.size()); for (String address : addresses) { String host = address.split(":")[0]; Integer port = Integer.valueOf(address.split(":")[1]); servers.add(new ServerAddress(host, port)); } MongoClient client = new MongoClient(servers); MongoDatabase db = client.getDatabase(mongoName);
appendix
-
mongodb configuration file specific attribute explanation
dbpath：数据存放目录 logpath：日志存放路径 pidfilepath：进程文件，方便停止mongodb directoryperdb：为每一个数据库按照数据库名建立文件夹存放 logappend：以追加的方式记录日志 replSet：replica set的名字 bind_ip：mongodb所绑定的ip地址 port：mongodb进程所使用的端口号，默认为27017 oplogSize：mongodb操作日志文件的最大大小。单位为Mb，默认为硬盘剩余空间的5% fork：以后台方式运行进程 noprealloc：不预先分配存储