MongoDB replica set and how it works

First, the principle of work

1. The MongoDB 2.6 version starts with the recommended replica set, which is no longer recommended for master-slave replication.

2. The replica set requires at least 3, can be 3 copies of all the replica set, you can also let one of them do the quorum.

3. Only 1 hosts in the replica set can write, and the rest can only be read.

4. Replication between replica sets is realistic through Oplog logs. Backup nodes by querying this collection, you can know what operations need to be replicated.

5. Oplog is a fixed collection in the local library in the node, by default Oplog the 5%.oplog that is the size of the free disk is capped collection, so when the Oplog space is full, the originally written log is overwritten.

6. Change the size of the Oplog document directly to the size of the local disk space. You can set the Oplogsize parameter in the configuration file to specify the size of the Oplog document, for example, oplogsize=1024 units default to M Each local document has a disk space of 2G, set less than 2G, and the initialization is still 2G in size, such as oplogsize=1024 above, but the local.01 size created is still 2G.

7. If the backup node is unfortunately hung up, the copy operation may be repeated when the replication process is preceded by writing the data and then writing Oplog. But MongoDB has considered the problem during the design process. When the same operation executes multiple times in Oplog, it is executed only once.

8. Initialize the work.

A) The backup finds a synchronous master node, and then creates an identifier in local.me. During the start of synchronization, all databases (version: 2.6.7) of the standby node need to be emptied.

b) Copy the data to the backup node through the operation record in the Oplog.

c) Start creating indexes when fully synchronizing.

9. If the synchronization speed of the standby node is far from the data written by Oplog of the master node, and the Oplog of the master node is overwritten. This way, you may not be able to synchronize the overwritten data (this is not resolved temporarily, only by backing up the primary node's data and then re-synchronizing).

10. Each member of the heartbeat to see the status of other nodes, every 2 seconds there is a heartbeat detection.

11. When the primary node is down, each node chooses the next master node by election.

Second, installation method

1. The MONGDB service is installed on 3 machines respectively.

192.168.10.21:27017 (prepared)

192.168.10.26:27017 (prepared)

192.168.10.27:27018 (Master)

2. Set the password Authentication file.

You can use Grub-md5-crypt to generate encrypted files.

Put the generated ciphertext into a file. and 3 machines must have the same cipher.

This puts the ciphertext into the Mongod_key file in the MongoDB home directory.

3.3 MONGO to set the login rights of their admin library respectively.

This specific method can be omitted.

4. Configure the mongo.conf file.

192.168.10.27 (Master) configuration file

192.168.10.21 (prepared) configuration file

192.168.10.26 (prepared) configuration file

5. Turn off the firewall for each machine

/etc/init.d/iptables stop

6. Start MongoDB on each machine

7. Initialize on the host, which machine is usually initialized, which machine is the main one. However, you can also use weights to control which one is the primary.

config_repl={_id: ' Alex ', members:[

{_id:0,host: ' 192.168.10.27:27018 ', priority:10},

{_id:1,host: ' 192.168.10.26:27017 ', priority:9},

{_id:2,host: ' 192.168.10.21:27017 ', Priority:9}]}

The greater the priority here, the Master is which one

Then execute rs.initiate (CONFIG_REPL);

The replica set is configured to complete.

You can view the status of individual nodes with Rs.status ().

In my understanding, to see where the repository is synced to the main library can be seen through optime

8. After setting the replica set, the standby node defaults to unreadable data, but Rs.slaveok () can be set.

But only valid for the current session.

If you use the program to connect, to achieve read and write separation. For example, Java has the appropriate methods and parameters to achieve this

9. Switch Master-standby. (192.168.10.26 promotion mainly)

Rs.conf () # View Configuration

Perform:

Cfg=rs.conf ();

Cfg.members[1] = 11 # Change the host priority of ID 1 to 11

Rs.reconfig (CFG)

10. View the synchronization status.

The 9th step above makes the 192.168.10.26 upgrade to become the master.

Db.printslavereplicationinfo ();

Re-execute

Use local

Db.oplog.rs.find ();

You can view the statements that are synchronized.

{"TS": Timestamp (1448257041, 1), "H": Numberlong (" -1393509695161116878"), "V": 2, "OP": "I", "ns": "Bbbb.test1", "O" : {"_id": ObjectId ("5652a6116894d5b1bcd83dd2"), "a": 111}}

The meanings are explained as follows:

The timestamp of the ts:8 byte, represented by a 4-byte UNIX timestamp + 4-byte self-increment count. This value is important, when the new primary is elected (e.g. Master down), the secondary of the largest TS is chosen as the
operation type of the new primary op:1 byte
i:insert
u:update
D : delete
c:db cmd
DB: Declares the current database (where NS is set to = + database name + '. ')
N:no op, which is an empty operation, is periodically performed to ensure that the time
-sensitive ns: The namespace O: operation is the
corresponding document, that is, the contents of the current operation (such as the field and value to update when the update operation)
O2: The Where condition when an update operation is performed, only if the property is available at update