MongoDB cluster technology: replica set & amp; sharding, mongodb Cluster

MongoDB database cluster technology: replica set & sharding, mongodb cluster
MongoDB replica set MongoDB replica set is the process of synchronizing data on multiple servers, replication provides redundant backup of data, and stores data copies on multiple servers, improving data availability and ensuring data security. It also allows data to be recovered from hardware failures and service interruptions.
Mongodb requires at least two nodes for replication. One is the master node, which is responsible for processing client requests, and the rest are slave nodes, which are responsible for copying the data on the master node. The master node records all operations on it, the slave node periodically polls the master node for these operations, and Perform these operations on your own copy of the data to ensure that the data of the slave node is consistent with the master node.

In such a data redundancy system, the master node and all slave nodes form a replica set. The replica set of mongodb has the following characteristics: a cluster of N nodes
Any node can be the master node
All write operations are on the master node
Automatic failover
Automatic recovery

mongodb replica set settings The start of the replica set and the operation of the slave node to join the replica set can only be completed on the master node, but the master node can be transferred to other slave nodes at any time;
The basic steps for starting a replica set system are as follows: When the mongod service is started on the master node, you can use --replSet to start the replica set and specify the replica set name;
Connect to the master node and initialize a new replica set;
Start the mongod service of each slave node. At the same time, these slave nodes also create and must initialize the replica set, using the same replica set id;
Add these slave nodes to the master node replica set at the master node;

The following demonstrates 3 mongodb to create a replica set system 1) The master node starts the mongod service:
?

# Start the mongodb service and set the replica set rs0
$ mongod --port 27017 --dbpath "/ var / run / mongodb / data" --replSet rs0
2) 2 slave nodes start mongod service?
$ mongod --port 27017 --dbpath "/ var / run / mongodb / data" --replSet rs0
3) Connect to the master node mongodb to initialize and configure the replica set?
$ mongo
> rs.initiate ()??? # start a new replica set
> rs.add ("233.76.45.12:27107")? # Join the slave node, which is the mongod service on port 27107 of the host 233.76.45.12
> rs.add ("45.76.45.18:27107")?? # Join the slave node, which is the mongod service on port 27107 of the host 45.76.45.18

At this point, a replica system has been completed, all operations are directly directed to the master node, and the actual operations are provided by the entire replica set cluster. The default is to read from the master node; deleting nodes from the replica set is as follows:?
> rs.remove ("45.76.45.18:27107")? # remove the slave node on 45.76.45.18:27107

Viewing Replica Set Information You can use the following command to see information about the entire replica set:
?
> rs.conf ()??? # View the configuration of the replica set
> rs.status ()?? # View replica set status
> rs.isMaster ()? # See if the host node is the replica set master

Set the read-write strategy of the slave node The read-write strategy of the slave node can be set:?
rs.getMongo (). setReadPref (STRATEGY)
The policy parameters are as follows: Primary???????????-Read from the master node;
secondary???????--read from the slave;
nearest???????????-Read from the node with the lowest network latency;
primaryPreferred???-Basically read from the master node. When the master node is unavailable, read from the slave node. secondaryPreferred?-Basically read from the slave node.



MongoDB sharding There is another cluster in Mongodb, which is the sharding technology, which can meet the demand for a large amount of MongoDB data. When MongoDB stores a large amount of data, one machine may not be enough to store data, or it may not be sufficient to provide Accepted read and write throughput. At this time, the database system can store and process more data by splitting data on multiple machines.



In the above typical sharding model, there are the following three roles: Shard: used to store actual data blocks. In the actual production environment, a shard server role can be assumed by several machine groups and a replica set to prevent the host from a single point of failure ;
Config Server: a mongod instance that stores the entire ClusterMetadata, including chunk information;
Routers: front-end routing, from which clients access, and make the entire cluster look like a single database, and front-end applications can be used transparently;

Example of creating a mongodb sharding system The following creates a mongodb sharding system using 1 Router, 1 Config Server, and 2 Shards, and their ports are as follows:?
Reouter: 23.23.23.23: 27017
Config Server: 23.23.23.24:27017
Shard 1: 23.23.23.25: 27017
Shard 2: 23.23.23.26: 27017

1) Start Shard Server?
Start shard server 1 and shard server 2 respectively;
$ mongod --port 27017 --dbpath / var / run / mongodb / shard / --fork
2) Start Config Sevrer
?
$ mongod --port 27017?-dbpath / var / run / mongodb / shard / --fork
3) Start Router Server and bind Config Server and Shard Server
?
$ mongod --port 27017 --fork --logpath = / var / run / mongo / route.log --configdb 23.23.23.24:27017 --chunkSize 500
※ Here you need to set the configdb parameter, which is used to set the desired config server, chunkSize is used to set the chunk size, the unit is MB, the default is 200MB; login to Router mongodb for further settings
?
# Login to router mongodb
$ mongo
> use admin
?
# Add shard shard
> db.runCommand ({addShard ("23.23.23.25:27017")})
> db.runCommand ({addShard ("23.23.23.26:27017")})
?
# Enable sharding, and set the database name for shard storage. The following is testdb
> db.runCommand ({enablesharding: "testdb"})
?
# Set the fragmentation form of the collection. The following uses hash mode for testdb.students collection and range mode for testdb.address.
> db.runCommand ({shardCollection: "testdb.students", key: {_ id: "hashed"}})
> db.runCommand ({shardCollection: "testdb.address", key: {name: 1}})

After the program connects to this sharding system, it only needs to connect to the Router Server (23.23.23.23: 27017). The sharding process is transparent to the application;