A master-slave configuration
About master-slave configuration process, we here do not specifically explained in detail, look at this article, it is good:
https://www.cnblogs.com/ysocean/p/9143118.html
Second, the principle of master-slave replication
This is our main problem, we look at
Redis copy function into synchronization (sync) and the propagation of commands (command propagate) two operations.
①, legacy synchronization
When issuing a command from the node SLAVEOF require replication master server from the server, the command to complete transmitted SYNC from the master server. The command execution steps:
1, transmits SYNC command from the server to the master server
2, received a master's SYNC command execution BGSAVE command to generate a RDB files in the background, and use a buffer to record all write commands executed from the beginning
3, when the primary server BGSAVE command is completed, the main server sends the generated command BGSAVE file to the RDB, RDB file from the server receives from the server, and the server updates the status file status record RDB.
4, the master server to all buffers from the write command is also sent to the server, execute a command from the server.
②, command spread
When the synchronization is completed, the master server will be the appropriate modification commands, this time will not match the state of the primary server and from the server.
In order to get the main server and from the server to maintain a consistent state, the master server needs to perform command operations spread from the server, the master will write their own commands sent from the server to execute. From the server after executing the corresponding command from the main server to maintain a consistent state.
Summary: Through the synchronization and command communications function, can ensure a good master from the same characteristics.
However, we consider a problem if the server during a sync master, suddenly disconnected, but this time the primary server for a number of write operations, this time to recover from the server, if we conduct synchronized, then it must be the main RDB generate a new file server, and then to be loaded from the server, so even though it can ensure consistency, but in fact the main server before disconnecting from the state is consistent, inconsistent is disconnected from the server, and the server performs some of the main write command, the write command to restore what connection can not just disconnect from the server, rather than the entire RDB snapshot of it?
Synchronous operation is actually a time-consuming operation, the main server need to generate a document by BGSAVE RDB command, and then need to send the file to the server, after receiving the file from the server, then the file is loaded, and the loading period, from the server is unable to process other commands.
To solve this problem, Redis from after version 2.8, use the new synchronization command PSYNC instead SYNC command. Part Resync command for the post-treatment efficiency of replication reconnection. That is when the master server from the server to reconnect after the break, only the primary server is disconnected after the write command sent from the server, just received from the server and execute the write command to remain consistent from the master.
Third, the main disadvantage of replication from
Although the master copy from the master node to solve the problem of single point of failure, but because all writes are on the Master node operation, and then synchronized to Slave node, then the synchronization will be a certain delay, when the system very busy time delay problem will be more serious, and will increase as the slave node rather more severe.