As a loyal MongoDB fan, I have the honor to accompany MongoDB's growth all the way. Currently, MongoDB 4.2 version has been released, MongoDB 4.2 version
There are many and complete information on the establishment of sharded clusters on the Internet. However, there is still a big difference from the version of MongoDB 3.6 or lower, such as version 3.4. There are relatively few comparisons between the establishment of sharded clusters on the Internet, such as 4.2 and 3.4. Here are some differences between deploying MongoDB 3.4 and MongoDB 4.2 by yourself. The deployment process of my MongoDB 4.2 sharded cluster is not an official standard. I just used some differences in sharded cluster deployment between different versions for reference only.
1. Configuration information
Regarding the configuration of MongoDB3.4 and MongoDB4.2 deploying sharded clusters, I use 3 machines to deploy two data shards and one configuration replica set.
Three mongos processes. The role distribution of each machine is as follows (I thought that the three hosts of MongoDB were cloned through VMs, and I did not modify the host names.
Deployment of slice clusters):
192.168.192.153 centos7 mongodb1 #firstset primary,secondset secondary,config selectself
192.168.192.154 mongodb2 #firstset ARBITER,secondset primary,config selectself
192.168.192.155 mongodb3 #firstset secondary,secondset ARBITER,config selectself
2. Installation directory planning
Note: The relevant folder path needs to be created in advance and set permissions, otherwise the mongd process will not be able to start
--basedir same
--3.4
/home/mongo/mongodb3.4
--4.2
/home/mongo/mongodb4.2
--mongodb1
mkdir -p /opt/mongo/data/repset1
mkdir -p /opt/mongo/logs/firstset/
mkdir -p /opt/mongo/data/repset2
mkdir -p /opt/mongo/logs/secondset/
mkdir -p /opt/mongo/data/config/
mkdir -p /opt/mongo/logs/config/
mkdir -p /opt/mongo/logs/mongos/
--mongodb2
mkdir -p /opt/mongo/data/arbiter1
mkdir -p /opt/mongo/logs/arbiter1
mkdir -p /opt/mongo/data/repset2
mkdir -p /opt/mongo/logs/secondset/
mkdir -p /opt/mongo/data/config/
mkdir -p /opt/mongo/logs/config/
mkdir -p /opt/mongo/logs/mongos/
--mongodb3
mkdir -p /opt/mongo/data/repset1
mkdir -p /opt/mongo/logs/firstset/
mkdir -p /opt/mongo/data/arbiter2
mkdir -p /opt/mongo/logs/aribter2/
mkdir -p /opt/mongo/data/config/
mkdir -p /opt/mongo/logs/config/
mkdir -p /opt/mongo/logs/mongos/
3. The three replica sets of the MongoDB sharded cluster start the mongod instance
Note: In order to facilitate comparison, I use the least parameters here, and directly list the parameters used in the command line
--3.4
#mongodb1
mongod --dbpath /opt/mongo/data/repset1 --port 10001 --replSet firstset --oplogSize 512 --rest --fork --logpath /opt/mongo/logs/firstset/firstset.log --logappend --nojournal --directoryperdb
mongod --configsvr --dbpath /opt/mongo/data/config --replSet csvr--port 20001 --fork --logpath /opt/mongo/logs/config/config.log --logappend
mongod --dbpath /opt/mongo/data/repset2 --port 30001 --replSet secondset --oplogSize 512 --rest --fork --logpath /opt/mongo/logs/secondset/secondset.log --logappend --nojournal --directoryperdb
#mongodb2
mongod --dbpath /opt/mongo/data/repset1 --port 10001 --replSet firstset --oplogSize 512 --rest --fork --logpath /opt/mongo/logs/firstset/firstset.log --logappend --nojournal --directoryperdb
mongod --configsvr --dbpath /opt/mongo/data/config --replSet csvr--port 20001 --fork --logpath /opt/mongo/logs/config/config.log --logappend
mongod --dbpath /opt/mongo/data/repset2 --port 30001 --replSet secondset --oplogSize 512 --rest --fork --logpath /opt/mongo/logs/secondset/secondset.log --logappend --nojournal --directoryperdb
#mongodb3
mongod --dbpath /opt/mongo/data/arbiter1 --port 10001 --replSet firstset --oplogSize 512 --rest --fork --logpath /opt/mongo/logs/dns_aribter1/aribter1.log --logappend --nojournal --directoryperdb
mongod --configsvr --dbpath /opt/mongo/data/config --replSet csvr --port 20001 --fork --logpath /opt/mongo/logs/config/config.log --logappend
mongod --dbpath /opt/mongo/data/arbiter2 --port 30001 --replSet secondset --oplogSize 512 --rest --fork --logpath /opt/mongo/logs/aribter2/aribter2.log --logappend --nojournal --directoryperdb
--4.2
#mongodb1
mongod --dbpath /opt/mongo/data/repset1 --port 10001 --shardsvr --replSet firstset --oplogSize 512 --bind_ip 0.0.0.0 --fork --logpath /opt/mongo/logs/firstset/firstset.log --logappend --journal --directoryperdb
mongod --dbpath /opt/mongo/data/repset2 --port 30001 --replSet secondset --oplogSize 512 --shardsvr --fork --bind_ip 0.0.0.0 --logpath /opt/mongo/logs/secondset/secondset.log --logappend --journal --directoryperdb
mongod --configsvr --dbpath /opt/mongo/data/config --replSet csvr --port 20001 --bind_ip 0.0.0.0 --fork --logpath /opt/mongo/logs/config/config.log --logappend
#mongodb2
mongod --dbpath /opt/mongo/data/arbiter1 --port 10001 --shardsvr --replSet firstset --oplogSize 512 --bind_ip 0.0.0.0 --fork --logpath /opt/mongo/logs/arbiter1/arbiter1.log --logappend --journal --directoryperdb
mongod --dbpath /opt/mongo/data/repset2 --port 30001 --replSet secondset --oplogSize 512 --shardsvr --fork --bind_ip 0.0.0.0 --logpath /opt/mongo/logs/secondset/secondset.log --logappend --journal --directoryperdb
mongod --configsvr --dbpath /opt/mongo/data/config --replSet csvr --port 20001 --bind_ip 0.0.0.0 --fork --logpath /opt/mongo/logs/config/config.log --logappend
#mongodb3
mongod --dbpath /opt/mongo/data/repset1 --port 10001 --shardsvr --replSet firstset --oplogSize 512 --bind_ip 0.0.0.0 --fork --logpath /opt/mongo/logs/firstset/firstset.log --logappend --journal --directoryperdb
mongod --dbpath /opt/mongo/data/arbiter2 --port 30001 --replSet secondset --oplogSize 512 --shardsvr --fork --bind_ip 0.0.0.0 --logpath /opt/mongo/logs/aribter2/aribter2.log --logappend --journal --directoryperdb
mongod --configsvr --dbpath /opt/mongo/data/config --replSet csvr --port 20001 --bind_ip 0.0.0.0 --fork --logpath /opt/mongo/logs/config/config.log --logappend
Through the start parameters of the mongod instance of 3.4 and 4.2, it is found that:
a, 3.4--rest has been abandoned in 4.2, 4.2 will prompt that the parameter is not recognized
b, 3.4 can not open the journal log, but if you start with the replSet parameter in 4.2, you must open the journal log, that is, use the parameter --journal
c. 3.4 does not require the mongod process to start using --bind_ip to bind the IP, but the 4.2 mongod process must specify --bind_ip to limit the ip that mongod connects to.
Otherwise, the 4.2 mongd process will reject all connection requests initiated by IP except 127.0.0.1 after it is started
d. 4.2 Cluster replica set fragmentation The cluster requires the use of the --shardsvr parameter, otherwise, an error will be reported when the mongos process registers the replica set fragmentation and the mongod must be prompted
Specify the --shardsvr parameter
4. Two replica set initialization and configuration library replica set initialization
--Shard 1 replica set, 3.4 can initialize the shard 1 replica set at any node, but 4.2 shard 1 replica set initialization cannot be done at the arbitration node, otherwise an error will be reported
It is prompted that the node where it is located is not eligible for election, and which node in the cluster will initialize the replica set of 4.2 shard 1 and which node will become the primary node. The priority parameter and _id do not work.
use.
#The master node 1 of the replica set data of the shard 1 planned in the three nodes, namely mongodb1
mongo --port 10001
config={_id:"firstset",members:[]}
config.members.push({_id:0,host:"192.168.192.153:10001",priority:1})
config.members.push({_id:2,host:"192.168.192.154:10001",arbiterOnly:true})
config.members.push({_id:1,host:"192.168.192.155:10001",priority:2})
rs.initiate(config);
--Shard 2 replica set, 3.4 can initialize the shard 1 replica set at any node, but 4.2 shard 2 replica set initialization cannot be done at the arbitration node, otherwise an error will be reported
It is prompted that the node where it is located is not eligible for election, and the node in the cluster where the 4.2 shard 2 replica set is initialized, and which node will become the master node, the priority parameter and _id do not work
use.
#The shard 2 replica set data master node 2 planned in the three nodes, namely mongodb2
mongo --port 30001
config={_id:"secondset",members:[]}
config.members.push({_id:0,host:"192.168.192.153:30001",priority:1})
config.members.push({_id:1,host:"192.168.192.154:30001",priority:2})
config.members.push({_id:2,host:"192.168.192.155:30001",arbiterOnly:true})
rs.initiate(config);
--There is no difference between configuration library replica set 3.4 and 4.2, the master node of the replica set will be automatically elected within the replica set
#Cluster any node
mongo --port 20001
rs.initiate( {
_id : "csvr",
configsvr: true,
members: [
{ _id: 0, host: "192.168.192.153:20001" },
{ _id: 1, host: "192.168.192.154:20001" },
{ _id: 2, host: "192.168.192.155:20001" }
]
});
5. Start the mongos process of three nodes
--3.4
mongos --configdb 192.168.192.153:20001,192.168.192.154:20001,192.168.192.155:20001 --port 27017 --fork --logpath /opt/mongo/logs/mongos/mongos.log --logappend
--4.2
mongos --configdb csvr/192.168.192.154:20001,192.168.192.153:20001,192.168.192.155:20001 --bind_ip 0.0.0.0 --port 27017 --fork --logpath /opt/mongo/logs/mongos/mongos.log --logappend
The difference between the start of mongos 3.4 and 4.2 is the parameter --bind_ip, 3.4 does not specify --bind_id does not limit the connection request of the mongos process, but 3.4 will refuse
Requests for IP other than the IP specified by 127.0.0.1 and --bind_ip
6. Registration of sharded cluster
--There is no difference between 3.4 and 4.2
#Cluster three nodes can be any node
mongo --port 27017
use admin
db.runCommand( { addShard : "firstset/192.168.192.153:10001,192.168.192.154:10001,192.168.192.155:10001" } )
db.runCommand( { addShard : "secondset/192.168.192.153:30001,192.168.192.154:30001,192.168.192.155:30001" })
7. Set up the shard library and collection
mongo --port 27017
use admin
sh.enableSharding("testdb");
db.runCommand({"shardcollection":"testdb.test_collection","key":{"name":1}});
--Insert data in batches
var arr = [];
for(var i=0;i<2000000;i++){
var uid = i;
var name = "mongodb"+i;
arr.push({"id":uid,"name":name});
}
db.users.insertMany(arr);
8. Other differences found
a. 3.4 When sh.status() is used, the data distribution of the shard collection of the shard library will be automatically displayed in detail, but the parameter verbose needs to be specified in 4.2
b, 3.4 rs.slaveOk() should be executed when viewing the replica data of the replica set, 4.2 rs.secondaryOk() should be executed when viewing the replica data of the replica set;
Regarding the differences between mongodb 3.4 and 4.2 in other uses or features, please experiment and discover it slowly~~