Three architectures using MongoDB Replica Sets)

Document directory

• 1. Add an arbiter to the original Master/Slave Mechanism
• 2. One Primary is used for writing, multiple Secondary is used for reading and one Secondary is used for backup
• 3. Classic MongoDB configuration. The upper layer is Auto-Sharding, and each Sharding node is a Replica set.

Original article: http://blog.nosqlfan.com/html/1750.html

In addition to the common Master/Slave Mode, the replication mechanism of MongoDB is more powerful than the Replica Sets mode that supports automatic failover. Compared with the auto-sharding mechanism, Replica Sets are relatively stable.

As a large user of MongoDB, Foursquare (4sq for short) has a wealth of experience in using MongoDB. Below is an article on 4sq, which describes several architecture methods of the Replica Sets mechanism in 4sq.

Original article: Fun with MongoDB replica sets

1. Add an arbiter to the original Master/Slave Mechanism

4sq has some MongoDB architecture of Master/Slave in the early stage. However, this mode cannot implement automatic failover and must be manually switched in the event of a fault. After the appearance of Replica Sets, this structure is migrated to Replica Sets of three machines: one Primary, one Secondary, and one Arbiter.

Migration Process:

Modify the configurations of Master and slave, add the following items, and restart MongoDB.

ReplSet = auxdb
Fastsync = true
Rest = true

Fastsync allows you to use the original data file for restart, And the restart will be very fast. Then, use rs. add and rs. addArb on Primary to add Secondary and Arbiter. This is done.

2. One Primary is used for writing, multiple Secondary is used for reading and one Secondary is used for backup

In applications with multiple writes and fewer reads, 4sq mainly uses Replica Sets to implement read/write splitting. By specifying slaveOk during connection, the read operation is placed on Secondary, and the Primary only performs write operations. At the same time, specify a Secondary with priority of 0 and hidden of true for backup (after this setting, this machine is invisible in reading and writing and won't be elected as Primary)

3. Classic MongoDB configuration. The upper layer is Auto-Sharding, and each Sharding node is a Replica set.

Although 4sq has suffered losses, it is obvious that they have learned the lesson and are more reasonable and careful about using Auto-Sharding, an attractive feature.

Note:

The functional performance of parts is not small, and other cluster methods cannot solve the expansion problem. The client is still well balanced.