Wechat official number: 51 code farm website :www.51manong.com 51 code Farm website, programmer community learning punch card website group learning and common progress [1] 51 code Farm website, let programmers stick to learning easier [1]
Master/slave replication of Redis
Conceptual interpretation of master-slave replication
Persistence ensures that data will not be lost even if the Redis service is restarted. After the Redis service is restarted, persistent data will be restored to memory. However, when the hard disk of the Redis server is damaged, data may be lost.
1.Redis uses asynchronous replication. Starting with Redis 2.8, the slave server reports the progress of the replication stream to the master server once per second.
2. A primary server can have multiple secondary servers.
3. A REDis can be both master and slave. Not only the master server can have a slave server, but also the slave server can have its own slave server.
4. Replication does not block the primary server: the primary server can continue processing command requests even if one or more secondary servers are performing initial synchronization.
5. Replication also does not block the slave server: as long as it is set up in the redis.conf file, the slave server can use older versions of the data set to process command queries even when the slave server is synchronizing for the first time
Realize the benefits of master-slave replication
After the master-slave replication is implemented, on the one hand, data reading and writing can be separated to reduce the pressure on the master server, and on the other hand, data backup can be realized. Replication can be used to keep the primary server from persisting: simply turn off persistence on the primary server and leave it to the secondary server
Redis secondary server read-only feature
Starting with Redis 2.6, the slave server supports read-only mode, which is the default mode for the slave server.
The read-only mode is controlled by the slave-read-only option in the redis. Conf file. This mode can also be enabled or disabled by using the CONFIG SET parameter value command.
1slave-read-only yes
Copy the codeRead-only slave servers refuse to execute any write commands, so there is no chance of accidentally writing data to the slave server by mistake.
1127.0. 01.:6380> set hlx 890
2(error) READONLY You can't write against a read only slave.
Copy the codeEven if the slave server is read-only, administrative commands such as DEBUG and CONFIG can still be used, so we should not expose the server to the Internet or any untrusted network. However, using the command renaming option in redis.conf, we can improve the security of read-only slave servers by disabling certain commands.
Why make a slave writable, you might wonder, since the write data on the slave server can be overwritten by resynchronization data and can be lost when the slave server restarts?
The reason is that some temporary data, which is not important, can still be saved on the slave server. For example, clients can save information about primary reachability on secondary servers to implement a failover strategy.
Implement master/slave replication of Redis
Suppose there are three instances of Redis. Instance A is the master server, and instance B and C are the slave servers that implement A. Their corresponding ports are 6379/6380/6381 respectively
1The primary serverAPort 6379ip: 192.168.232.128
2From the serverBPort 6380ip: 192.168.232.128
3From the serverCPort 6381ip: 192.168.232.128
Copy the code1. Make two copies of redis.conf6380 redis.conf6381.
1[erayt@ERAYT-01 bin]$ ls
2appendonly.aof redis-benchmark redis-check-dump redis.conf redis.conf6381 redis-server
3log-redis.log redis-check-aof redis-cli redis.conf6380 redis-sentinel
Copy the code2. The primary REDis does not need to be configured. The secondary redis configuration is modified as follows:
1# slaveof <masterip> <masterport>
2slaveof 127. 0. 01. 6379
Copy the codeThe IP address of the primary server corresponding to the secondary server is 192.168.232.128, and the port number is 6379.
3. Start three Redis instances and access the monitoring console of the three instances respectively
1[erayt@ERAYT-01 bin]$ ./redis-server redis.conf
2[erayt@ERAYT-01 bin]$ ./redis-server redis.conf6380
3[erayt@ERAYT-01 bin]$ ./redis-server redis.conf6381
Copy the codeAccess the monitor console for three instances
1[erayt@ERAYT-01 bin]$ ./redis-cli -p 6379
2[erayt@ERAYT-01 bin]$ ./redis-cli -p 6380
3[erayt@ERAYT-01 bin]$ ./redis-cli -p 6381
Copy the code4. Run the INFO replication command to check the status of the current instance
Primary server A 6379
1127.0.0.1:6379 > INFO replication
2# Replication
3role:master
4connected_slaves:2
5Slave0: IP = 127.0.0.1 port = 6380, state = online, offset = 491, lag = 0
6Slave1: IP = 127.0.0.1 port = 6381, state = online, offset = 491, lag = 0
7master_repl_offset:491
8repl_backlog_active:1
9repl_backlog_size:1048576
10repl_backlog_first_byte_offset:2
11repl_backlog_histlen:490
Copy the codeFrom server B 6380
1127. 0. 01.: 6380> INFO replication
2# Replication
3role:slave
4master_host: 127.0.0.1
5master_port: 6379
6master_link_status:up
7master_last_io_seconds_ago: 1.
8master_sync_in_progress: 0
9slave_repl_offset: 631
10slave_priority: 100
11slave_read_only: 1.
12connected_slaves: 0
13master_repl_offset: 0
14repl_backlog_active: 0
15repl_backlog_size: 1048576
16repl_backlog_first_byte_offset: 0
17repl_backlog_histlen: 0
18127. 0. 01.: 6380>
Copy the codeSlave server C 6381
1127. 0. 01.: 6381> INFO replication
2# Replication
3role:slave
4master_host: 127.0.0.1
5master_port: 6379
6master_link_status:up
7master_last_io_seconds_ago6:
8master_sync_in_progress: 0
9slave_repl_offset: 701
10slave_priority: 100
11slave_read_only: 1.
12connected_slaves: 0
13master_repl_offset: 0
14repl_backlog_active: 0
15repl_backlog_size: 1048576
16repl_backlog_first_byte_offset: 0
17repl_backlog_histlen: 0
18127. 0. 01.: 6381>
Copy the code5. The host stores information and check whether the secondary node obtains it
1127. 0. 01.: 6379> set hlx manong
2OK
3
4127. 0. 01.: 6380> get hlx
5"manong"
Copy the codeData is synchronized between the master and slave servers
Redis some concepts of master-slave replication
1. Master run ID (MASTER run ID). Each time redis is started, an ID will be assigned and rUNID will change after the restart.
1[erayt@ERAYT-01 bin]$ ./redis-cli -p 6379 info server | grep run
2run_id:c8d4ed4955c8242d6608127d4c6e5a93251cfd36
Copy the code2. Replication offset: Specifies the offset of the data requested from the master
1[erayt@ERAYT-01 bin]$ ./redis-cli -p 6379 info replication | grep offset
2Slave0: IP = 127.0.0.1 port = 6380, state = online, offset = 7940, lag = 0
3Slave1: IP = 127.0.0.1 port = 6381, state = online, offset = 7940, lag = 0
4master_repl_offset:7940
5repl_backlog_first_byte_offset:2
Copy the code(3) Repl_backlog_size: specifies the size of the replication buffer. The default value is 1M. For partial replication, if offset is within the range, partial replication is started. You can modify this size for a better replication mechanism.
Principle of Redis full copy
1. When establishing a secondary server, the secondary server sends a SYNC command to the primary server, whether for the first time or for a new connection.
2. The master server receiving SYNC will start BGSAVE and save all newly executed write commands to a buffer during the save operation.
3. When the BGSAVE operation is complete, the master server sends the.rdb file to the slave server, which receives the.rdb file and loads the data into memory.
4. After that, the master server sends all the contents accumulated in the write command buffer to the slave server in the format of Redis command protocol.
Even if multiple slave servers are sending SYNC to the master server at the same time, the master server only needs to execute the BGSAVE command once to process all of these slave synchronization requests.
The slave server can be automatically reconnected when the connection between the primary and secondary servers is disconnected. Before Redis 2.8, the slave server that is reconnected after disconnection always performs a full resynchronization operation. However, starting with Redis 2.8, The secondary server can perform partial resynchronization or full resynchronization based on the conditions of the primary server.
Partial resynchronization
Starting with Redis 2.8, after a temporary network connection failure, the primary and secondary servers can attempt to continue the original replication process without performing a full resynchronization operation.
This feature requires the master server to create an in-memory backlog for the replication streams being sent, with a replication offset and a master run ID recorded between the master and all slave servers. When a network disconnection occurs, the secondary server reconnects and requests the primary server to continue the original replication process:
If record the primary server ID from the server and the current of the main server to connect the same ID, and offset specified by the data from the server record is still preserved in the main server replication stream buffer, then the primary server will send from the server when the bolt missing portion of the data, then copy the work can continue. Otherwise, a full resynchronization operation is performed on the slave server.
This partial resynchronization feature in Redis 2.8 uses a new PSYNC master_run_id offset internal command, whereas previous versions of Redis 2.8 only had SYNC. As long as the slave server is Redis 2.8 or above, it will decide whether to use PSYNC master_run_id offset or SYNC based on the master server version:
If the primary server is Redis 2.8 or later, the secondary server uses the PSYNC master_run_id offset command for synchronization. If the primary server is a version prior to Redis 2.8, the secondary server uses the SYNC command for synchronization.
Redis learning documentation website
Recommend a redis website: http://redisdoc.com/topic/
