MongoDB Quorum node Understanding as well as Memcached,zookeeper,redis, fail-back scenario thinking.

In the case of a replica set deployment we add one or more quorum nodes, the quorum node is not used to back up the data, because it is responsible for the election of the main node, so the hardware is not too high requirements, you can deploy it on a separate server, the server can be a listener server, can also be deployed on the virtual machine, But a little bit. The quorum node must not be able to back up data. Both the quorum node and the annotation point can participate in the election, and the election object is the individual non-voting member, which is the slave node that needs to back up the data.

Graph column

This reminds me of the election plan in the zookeeper cluster that I've known before, and it's different from MongoDB.

Zookeeper employs an election algorithm called leader election. In the whole cluster running process, there is only one leader, the other is follower, if the zookeeper cluster in the process of leader the problem, the system will use this algorithm to re-select a leader. Therefore, the above mappings must be configured to ensure that each node is connected to each other.

When the zookeeper cluster is started, a leader will be selected first, and in the leader election process, a node that satisfies the election can become leader.

For memcached, which does not provide a distributed solution, we can use a proxy server for distributed deployment. And Magent is a memcached proxy server, but it does not exist what leader,secondary, all command portals are magent this proxy server, when a node is done, and the request data can not be found, it will be taken from the backup node. When let's use zookeeper to manage memcached distributed clusters.

For Redis when the slave server is set up, slave establishes a connection to master and then sends the Sync command. Whether the connection was first synchronized or after a disconnected connection, master initiates a background process, saves the database snapshot to a file, and the master master process starts collecting new write commands and caches them. After the background process finishes writing the file, master sends the file to Slave,slave to save the file to disk, and then loads it into the memory recovery database snapshot to slave. The master then forwards the cached command to slave. and subsequent master commands are sent to the slave by the connection that was started to be established. Commands that synchronize data from master to slave and commands sent from the client use the same protocol format. Slave can automatically reestablish a connection when master and slave are disconnected. If master receives multiple slave simultaneous connection commands at the same time, it will only use the START process to write database mirroring and then send it to all slave. In the case of master failure, we can recover by persisting the data, and for salve, it will reconnect with master and then write all of the inside from the snapshot to slave. This recovery must be very slow.

MongoDB Quorum node Understanding as well as Memcached,zookeeper,redis, fail-back scenario thinking.