MongoDB replica sets

Document directory

• 1. Preparation Information Processing (each node can be the same or different)
• 2. Start the mongod instance
• 3. Configure and initialize the replica set
• 4. view the replica set status
• 1. read/write splitting
• 2. automatic failover
• 3. Add nodes
• 4. Reduce nodes

MongoDB supports multiple machinesAchieve failover and redundancy through asynchronous replication. Only one of multiple machines is used for write operations at the same time. This situation guarantees data consistency for MongoDB. Machines that assume the primary role can distribute read operations to slave. MongoDB is available in two ways:

1. Master-slave master-slave Replication: You only need to add the-master parameter when a service is started, and add the-slave and-source parameters to the other service to implement synchronization. This solution is no longer recommended in the latest MongoDB version.
2. Replica sets replica set: MongoDB 1.6 has developed the new replica set function, which is more powerful than the previous replication function,Added automatic failover and Automatic Repair of member nodesThe data in each database is completely consistent, greatly reducing the maintenance success. Auto Shard has clearly stated that replication Paris is not supported. We recommend that you use replica set and replica set be fully automatic during failover.

 

1. Deploy replica sets

There are currently three servers. The information is as follows:

• Replica set1: 192.168.8.204: 28010
• Replica set2: 192.168.8.205: 28010
• Replica set3: 192.168.8.206: 28010

To simplify the operation, you can configure the nodes in the same way.

1. Preparation Information Processing (each node can be the same or different)

$ Mkdir-P/data/DB/RS1/data/DB/log/data/DB/Key # create the required directory
$ Echo "this is RS1 super secret key">/data/DB/key/RS1 # generate the replica set key file
$ Chmod 600/data/DB/key/RS1 # adjust the key file to the read-only permission of the current user

2. Start the mongod instance

Each node executes the following command to start the mongod instance:

$bin/mongod --replSet rs1 --port 28010 --keyFile /data/db/key/rs1  --dbpath /data/db/rs1 --logpath /data/db/log/rs1.log --logappend --fork

3. Configure and initialize the replica set

$ Bin/Mongo -- Port 28010
> Config_rs1 = {_ ID: 'rs1', members :[
{_ ID: 204, host: '192. 168.204: 100', Priority: 1 },
{_ ID: 205, host: '192. 168.8.205: 100 '},
{_ ID: 206, host: '192. 168.8.206: 100'}]}
> Rs. Initiate (config_rs1) // initialize the configuration

4. view the replica set status

> Rs. Status ()
{
"Set": "RS1 ",
"Date": isodate ("2012-03-01t09: 49: 57z "),
"Mystate": 1,
"Members ":[
{
"_ Id": 204,
& Quot; Name & quot;: & quot; 192.168.8.204: 28010 & quot ",
"Health": 1, // 1 indicates normal; 0 indicates exception
"State": 1, // 1 indicates primary; 2 indicates secondary;
"Statestr": "primary", // indicates that this machine is the master database
"Optime ":{
"T": 1338457763000,
"I": 1
},
"Optimedate": isodate ("2012-03-01t09: 49: 23z "),
"Self": True
},
{
"_ Id": 205,
"Name": "192.168.8.205: 28010 ",
"Health": 1,
"State": 2,
"Statestr": "secondary ",
"Uptime": 23,
"Optime ":{
"T": 1338457763000,
"I": 1
},
"Optimedate": isodate ("2012-03-01t09: 49: 23z "),
"Lastheartbeat": isodate ("2012-03-01t09: 49: 56z ")
},
{
"_ Id": 2,
"Name": "192.168.8.20six: 28010 ",
"Health": 1,
"State": 2,
"Statestr": "secondary ",
"Uptime": 23,
"Optime ":{
"T": 1338457763000,
"I": 1
},
"Optimedate": isodate ("2012-03-01t09: 49: 23z "),
"Lastheartbeat": isodate ("2012-03-01t09: 49: 56z ")
}
],
"OK": 1
}

You can also check whether the current node is a master node:

PRIMARY>rs.isMaster()

Ii. oplog

MongoDB's replica set architecture stores write operations through a log, which is called "oplog ". Oplog. RS is a capped collection with a fixed length. It exists in the "local" database and is used to record the replica sets operation log. By default, for 64-bit MongoDB, oplog is relatively large and can reach 5% disk space. The oplog size can be changed by the parameter "-- oplogsize" of mongod. Example:

rs1:PRIMARY>use local
rs1:PRIMARY> show collections
oplog.rs
system.replset
rs1:PRIMARY> db.oplog.rs.find()
{ "ts" : { "t" : 1338457763000, "i" : 1 }, "h" : NumberLong(0), "op" : "n", "ns" : "", "o" : { "msg" :"initiating set" } }
{ "ts" : { "t" : 1338459114000, "i" : 1 }, "h" : NumberLong("5493127699725549585"), "op" : "i","ns" : "test.c1",
           "o" : { "_id" : ObjectId("4fc743e9aea289af709ac6b5"), "age" : 29, "name" :"Tony" } }

Field description:

• TS: The timestamp of an operation.
• OP: operation type, as follows: I: Insert D: delete U: Update
• NS: namespace, that is, the collection name of the operation
• O: Document Content

View the oplog metadata of the master:

> rs.printReplicationInfo()

View the synchronization status of slave:

> rs.printSlaveReplicationInfo()

View Master/Slave configuration information:

> Rs. conf () // or db. system. replset. Find ()

Iii. Management and Maintenance of replica set1. read/write splitting

Insert data into the master database and query data from the slave database so that the slave database has read-only permissions. The following operations must be performed on the slave node:

> DB. getmongo (). setslaveok () // enable the slave database to read

2. automatic failover

The replica set is better than the traditional master-slave, that is, it can automatically perform failover. If we stop a member of The replica set, then the remaining Members will automatically elect a member as the master database.

3. Add nodes

MongoDB replica sets not only provideHigh AvailabilityIt also providesServer Load balancerSolution, increasing or decreasing replica sets nodes is very common in practical applications. For example, when the application's read pressure surges, the environment of the three nodes cannot meet the requirements, in this case, you need to add some nodes to evenly distribute the pressure. When the application is under pressure, you can reduce some nodes to reduce the cost of hardware resources. In short, this is a long-term and continuous task. Add a node.Use oplog to add nodes, One isAdd nodes through database snapshots (-- fastsync) and oplog.

3.1 add nodes through oplog

Add a replica set node. Configure and start the node as shown in the preceding steps. Next, add the newly added node 192.168.8.207: 28010 to the replica set.

RS1: Primary> Rs. Add ({_ ID: 207, host: "192.168.8.207: 28010 "})
Rs1.primary> Rs. Status () // you can view the status to know that the process of adding a node is as follows:

1. Initialize: Node status "status": 6, "errmsg": "still initializing"
2. SameStep: node status "status": 3, "errmsg": "Initial sync need a member to be primary or secondary to do our initial sync"
3. Initialization synchronization completed: Node status "status": 3, "errmsg": "Initial sync done"
4. Node added: Node status "status": 2

3.2 Add a node to the database snapshot + oplog

Directly adding nodes through oplog is simple and requires no manual intervention. However, oplog is a capped collection and uses a loop to process logs. Therefore, you can use oplog to add nodes, data inconsistency may occur because the information stored in the log may have been refreshed. But it doesn't matter. We can add nodes by combining database snapshots (-- fastsync) with oplog. the operation process in this way is, first, take the physical file of a replica set member as the initialization data, and then use the oplog to catch up with the remaining parts, and finally achieve data consistency.

1. Obtains the physical file of a replica set member as the initialization data.
2. As described above, add the new replica set node 192.168.8.207: 28010, and add the option "-- fastsync" to the instance.
3. Use oplog to add nodes to verify data consistency

 

4. Reduce nodes

Run the following command to delete a replica set node:

rs1:PRIMARY> rs.remove("192.168.8.206:28010")
rs1:PRIMARY&> rs.remove("192.168.8.207:28010")
rs1:PRIMARY> rs.status()