Redis cluster _ 1. redis master-slave configuration, redis cluster _ 1. redis

Redis cluster _ 1. redis master-slave configuration, redis cluster _ 1. redis

Master-Slave Redis configuration (Master-Slave)

I. Redis Replication features:
1): one Master can synchronize multiple Slave instances.
2): not only can the Master synchronize multiple Slave, but also can synchronize other Slave, which can form a graphical structure and share the synchronization pressure of the Master.
3): Redis Replication uses asynchronous Replication. Starting from 2.8, Slave periodically initiates an Ack to check the replication stream processing progress.
4): Replication completes Data Synchronization in non-blocking mode on the Master Server. Even if multiple Master-Slave instances are synchronized at the same time, the Master Server can still provide query or modification
5): Replication also completes Data Synchronization in a non-blocking manner on the Slave Server. During synchronization, the Slave Server can provide data query, but the returned data is the data before synchronization. It can also be configured that when the Master and Slave lose contact, the Slave will return an error message from the client.
6): the Slave Server can provide the read-only operation service for the client, but the write service must still be completed by the Master, which can load the read operation pressure of the Master, data redundancy is provided at the same time of partial pressure, and Slave can be added for read-only operations to improve scalability.
7): You can modify the redis. config configuration file of the Master Server to submit the persistent operation to the Slave Server for operation.
Note: Slave is read-only and can only read data, but cannot write data.


Ii. How Redis Replication works:
1): After Slave is started, it will take the initiative to issue a SYNC command whether it is the first connection or re-connect to the Master.
2) After the Master receives the SYNC command, it will execute BGSAVE (the background storage process), that is, it will save data to the disk (rdb snapshot file) in the background ), collect all newly received commands for writing and modifying datasets and store them in the buffer zone (non-Query Class)
3) after the Master saves data to the snapshot file in the background, the entire database file will be transmitted to the Slave.
4) after the Slave receives the database file, it clears the memory and loads the file to the memory to complete a full synchronization.
5): The Master will then send the commands previously collected to the buffer zone and the new modification commands to Slave in sequence.
6): After Slave receives the data, it executes the data modification command locally to achieve final data synchronization.
7): After that, the Master and Slave will continue to synchronize commands in asynchronous mode, so as to ensure data synchronization from time to time.
8): If the connection between the Master and Slave is disconnected, the Slave can automatically reconnect to the Master. Based on different versions, the synchronization method after disconnection is also different:
Before 2.8: After the reconnection is successful, a full synchronization operation will be automatically executed.
After 2.8: Some synchronization operations are performed after the reconnection is successful.

Partial synchronization:
Starting from 2.8, when the connection between the Master and Slave is disconnected and reconnected, they can use continuous replication to replace the full re-synchronization operation. PSYNC is used for some re-synchronization operations. This command is available in Versions later than 2.8, and only the SYNC command is used in the past. As long as the Slave version is 2.8 or later, Slave will decide whether to use PSYNC or SYNC Based on the Master version.

Some synchronization works as follows:
1): The Master creates a memory buffer (in-memory backlog) for the sent replication stream and records the recently sent replication stream commands.
2): a replication offset and the current Master ID (Master run id) are recorded between the Master and Slave)
3) when the network is disconnected, Slave will reconnect and request the Master to continue executing the original replication process.
4) if the MasterID before the Slave network interruption is the same as the current MasterID, and the data specified by the offset of the Slave record from the disconnection time to the current time is still saved in the Master's replication stream buffer, the Master will send the missing data to the Slave, after the Server Load balancer instance is executed, the copy operation can continue.
5): otherwise, Slave will perform the full re-synchronization operation.

Iii. Configuration:

System Environment: CentOS 6.5 mini
Software Version: redis-2.8.19

IP Address:
Node 1: 192.168.100.211
Node 2: 192.168.100.212
Node 3: 192.168.100.213

1: Specify the Slave (configured on the Slave node)
# Vi/main/redis. conf
Slaveof 192.168.100.211 6379
# Note: if this line exists, it indicates Slave. If it is not, it indicates Master. Here, the IP address is the Master IP address, and the subsequent port number is also the Master port number.


2: Set the authentication password (three nodes)
Can be set or not set
# Vi/main/redis. conf
Masterauth 1234567890
Requrequirepass 1234567890
# Note: if the Master has set a password through requirepass, Slave needs to configure the password through masterauth.

The configuration is complete.

Iv. test:
1: view the data on the command line interface (three nodes ):
#/Main/redis/src/redis-cli
127.0.0.1: 6379> info replication

Node 1 is shown as follows (master ):
# Replication
Role: master
Connected_slaves: 2
Slave0: ip = 192.168.100.212, port = 6379, state = online, offset = 41663, lag = 1
Slave1: ip = 192.168.100.213, port = 6379, state = online, offset = 41663, lag = 1
Master_repl_offset: 41963
Repl_backlog_active: 1
Repl_backlog_size: 1048576
Repl_backlog_first_byte_offset: 2
Repl_backlog_histlen: 41962

Node 2 is shown as follows (slave1 ):
# Replication
Role: slave
Master_host: 192.168.100.211
Master_port: 6379
Master_link_status: up
Master_last_io_seconds_ago: 0
Master_sync_in_progress: 0
Slave_repl_offset: 41520
Slave_priority: 100
Slave_read_only: 1
Connected_slaves: 0
Master_repl_offset: 0
Repl_backlog_active: 0
Repl_backlog_size: 1048576
Repl_backlog_first_byte_offset: 0
Repl_backlog_histlen: 0

Node 3 is shown as follows (slave2 ):
# Replication
Role: slave
Master_host: 192.168.100.211
Master_port: 6379
Master_link_status: up
Master_last_io_seconds_ago: 0
Master_sync_in_progress: 0
Slave_repl_offset: 42106
Slave_priority: 100
Slave_read_only: 1
Connected_slaves: 0
Master_repl_offset: 0
Repl_backlog_active: 0
Repl_backlog_size: 1048576
Repl_backlog_first_byte_offset: 0
Repl_backlog_histlen: 0

2: Data Testing
Master
#/Main/redis/src/redis-cli-a 1234567890 set hello doiido

Slave1
#/Main/redis/src/redis-cli-a 1234567890 get hello
"Doiido"

Slave2
#/Main/redis/src/redis-cli-a 1234567890 get hello
"Doiido"

Slave2
#/Main/redis/src/redis-cli-a 1234567890 set hello2 doiido2
(Error) READONLY You can't write against a read only slave.

From the above operations, we can see that after data is written from the Master, the Slave will synchronize data, but the Slave cannot write data.

Here, the master-slave configuration of Redis is complete, but it will not automatically switch at this time. Sentinel configuration is required for automatic failover.