What a master-slave replication is .Redis
After the host data and updated according to the configuration policies, self-synchronization to the standby machine master / slave mechanism, Master mainly to write, read-mostly the Slave.
.Redis from two replicate master can do
Separate read and write
Disaster Recovery
III. How to use
1. dispensed from the main unworthy
2. From the Library Configuration: slaveof main library main library ip port ( if the current server is a slave server has a master server, then execute SLAVEOF host port will stop the current server synchronization server former team, and clear the old data set , turned to the new primary server for synchronization )
After a time from the main library and the library off, you need to reconnect, unless the configuration file into the Redis.conf
Use info replication command to view the current situation Redis instances (including the main library or from the library, if it is the main library, there are a few from the library, from the library listening port number .......)
3. Common applications:
3.1 When the master is closed, then all the slave master will be on standby, when the master is restarted, it will automatically connect these slave on the master
3.2 When the master of a slave from the library after hang up, does not affect the main library master and slave of the rest from using the library, but when restarting the hang of this, will no longer be master of this from the library, and It is to restore the master identity.
3.3 can be a slave of the next Master slave, slave slaves can also accept other connections and synchronization request, then the slave as the slave chain next master, the master can effectively reduce the pressure, but this will be delayed , we can not guarantee data consistency.
3.4 When the primary service hang up at this time for normal use, in a choice from a library server as the primary server is first executed SLAVEOF no one that the slave server shutdown replication and restore their master server identity ( original synchronizing data obtained set are not discarded ), and then the other and its subordinate server to establish master-slave relationship.
.Replication four principles:
- Copy the full amount: for the first copy or partial copy of the other can not, will have to send all the data to the main library from the library, this is a very heavy-duty operation.
- Incremental Copy: to copy, etc. after network outage, only the main library will send a write operation performed during the interruption to the library, more efficient replication than the full amount. Note that, if the interruption time is too long, leading to the main library is not completely save interrupted write operations performed during (see explanation below on the backlog copy buffer), partial reproduction can not be performed, only the total amount of copy.
4.1 full amount of replication
(1) can not be copied from the node determination section, transmits a request to copy the whole amount of the master node; or copied from the request transmitting section of the node, but can not be part of the master node is determined to copy, then the amount of full replication;
(2) the master node receives the command to copy the full amount, do bgsave ( bgsave command asynchronously in the background memory data stored in the database into the disk, a new child is returned immediately after execution OK BGSAVE command, and then Redis fork out process , the parent process to continue processing client requests, the child process is responsible for saving the data to disk, and then exit ), RDB file generated in the background, and use a buffer (called the copy buffer) records are now started from all write command
After bgsave execution (3) the master node is completed, the file will be sent to the RDB node; clear their old data from the first node, and then load the file RDB received database update execution state to the database bgsave master node.
(4) The master node will copy all of the aforementioned write command buffer is sent to the slave node, write command, the database status update to the latest state of the master node from node to perform these
(5) If you turn AOF from the node, it will trigger the execution bgrewriteaof, thus ensuring AOF files are updated to the latest state of the master node.
4.2 Incremental Replication
Since the total amount of the low copy large amounts of data efficiently master node, so start portion provided Redis2.8 copy, the data processing network for synchronizing interrupts.
Partially achieved copied depends on three important concepts:
(1) Copy offset
The master node and slave node maintaining a copy each offset (offset), is represented by the master node to the slave node number of bytes transferred ; master node to each node N bytes of data from propagating, offset master node increases N; each time the master node N bytes of data transmitted from a node is received, the node increases offset from N.
offset for determining the state of the database from the master node is consistent: if both the same offset, it conforms; if offset is different, inconsistent, this time from the node can identify the missing portion of the data in accordance with two offset. For example, if the master node 1000 is offset, it is offset from the node 500, then the need to copy the offset portion is transmitted to the slave node data of 501-1000. The offset position data stored 501-1000, is to copy the backlog buffer to introduce the following.
(2) Copy the backlog buffer
Replication backlog buffer is maintained by the master node, fixed length, first-out (FIFO) queue, the default size of 1MB; master node started to create a slave node as its effect is the most recently transmitted data from the backup master node to node. Note that regardless of the master node has one or more slave nodes, only need a copy backlog buffer.
In order propagation stage, except the master node to the slave node transmits a write command, will send a copy to the buffer backlog, the write command as a backup; storing the write command, the buffer backlog copy of which is also stored in addition to each copying bytes corresponding to the offset (offset). Because the replication backlog is FIFO buffer and fixed-length, so save it is to write the most recently executed command master node; the time of the earlier write command buffer will be squeezed out.
由于该缓冲区长度固定且有限，因此可以备份的写命令也有限，当主从节点offset的差距过大超过缓冲区长度时，将无法执行部分复制，只能执行全量复制。反过来说，为了提高网络中断时部分复制执行的概率，可以根据需要增大复制积压缓冲区的大小(通过配置repl-backlog-size)；例如如果网络中断的平均时间是60s，而主节点平均每秒产生的写命令(特定协议格式)所占的字节数为100KB，则复制积压缓冲区的平均需求为6MB，保险起见，可以设置为12MB，来保证绝大多数断线情况都可以使用部分复制。
从节点将offset发送给主节点后，主节点根据offset和缓冲区大小决定能否执行部分复制：
- 如果offset偏移量之后的数据，仍然都在复制积压缓冲区里，则执行部分复制；
- 如果offset偏移量之后的数据已不在复制积压缓冲区中（数据已被挤出），则执行全量复制。
（3）服务器运行ID(runid)
每个Redis节点(无论主从)，在启动时都会自动生成一个随机ID(每次启动都不一样)，由40个随机的十六进制字符组成；runid用来唯一识别一个Redis节点。通过info Server命令，可以查看节点的runid：
主从节点初次复制时，主节点将自己的runid发送给从节点，从节点将这个runid保存起来；当断线重连时，从节点会将这个runid发送给主节点；主节点根据runid判断能否进行部分复制：
- 如果从节点保存的runid与主节点现在的runid相同，说明主从节点之前同步过，主节点会继续尝试使用部分复制(到底能不能部分复制还要看offset和复制积压缓冲区的情况)；
- 如果从节点保存的runid与主节点现在的runid不同，说明从节点在断线前同步的Redis节点并不是当前的主节点，只能进行全量复制。
具体的细节请看下面这篇博文：https://www.cnblogs.com/kismetv/p/9236731.html（大佬就是大佬，整理的是真的详细）