MongoDB Learning note ~mongo cluster and replica set

Some concepts

For MONGO in data disaster recovery, the recommended pattern is to use replica set mode, which has an external primary server primary, and N replica server secondary (n>=1, when n=1, need to have an arbiter server arbiter when n> 1 o'clock does not require arbiter), they were previously synchronized through the internal mechanism, and when primary hung, it will be through the internal heartbeat mechanism, the election of a secondary to become a primary, and the outside world (Route) to communicate.

Industry standard

On the standard, our replica sets recommend using odd Servers (3,5,7,9), but after my testing, as long as more than two servers are available, for both the route Server and config server we have 3 servers, so that after one of them hangs, Can be routed from the other two, and the configuration information is not used much, but only when the router starts to pick up the information from the configuration machine.

Replica set replica set

The Replica set uses n mongod nodes to build a highly available scheme with automatic fault tolerance (auto-failover) and automatic recovery (auto-recovery). You can also use the replica set to achieve read and write separation, by specifying at the time of connection or specifying Slaveok in the main library, by secondary to share the pressure of reading, primary only assume the write operation, the replica node in secondary set is not readable by default , we can be configured to implement its read and write function (State:1 can read and write, State:2 cannot read and write), if you do not want secondary never become primary, you can use priority:0, that is, its priority is 0, then it will never become the primary node.

Secondary read-write configuration: State:1 can read and write, State:2 cannot read and write

Quorum configuration for secondary: arbiteronly:true

Secondary priority configuration (possibility of becoming primary): Priority:3, the higher the number, the greater the priority

Secondary not let it vote: votes:0;

I'm going to design a cluster myself.

The above diagram is just a logical architecture diagram of a cluster, and the actual physical architecture is not the same (that is, the deployment of each server and the relationship between servers), for two pieces of the cluster, the physical architecture may require 4 servers, 2 for the replica set of primary, Responsible for external read and write and storage S and C (s refers to the routing service, c refers to the configuration service), 2 units for replica set of secondary and arbiter (arbitration), and put them on the way to deploy, similar to

In fact, the above architecture diagram is just a description, specifically, we have to go to the actual configuration, to operate, only the real operation, to have the power to speak! Oh!

MongoDB Learning note ~mongo cluster and replica set