Start multiple Redis instances on a Linux machine: Learning the Master-slave function of Redis __linux

Installing the Redis on a Linux machine is very easy, not to be introduced here. Since I have only one machine to learn from the master-slave copy function, I need to start multiple Redis instances on a single machine. We need to copy the default redis.conf file, and then modify the corresponding settings on it, to ensure that multiple Redis instances do not appear to share data.

#拷贝一份新的配置文件
>cp redis.conf redis6001.conf

#vi修改对应的配置项
>vi redis6001.conf

#主要修改下面3个配置项就可以了
pidfile:/var/run/redis_6380.pid
port 6001
Rdbfile:dump6001.rdb

We can then redis-server specify a new configuration file so that a new Redis instance can be started.

Redis-server redis6001.conf

How to configure a from the server is very simple, such as we in 6001 and 6002 ports to start 2 Redis instances, want to let 6001 as master,6002 as slave, then we only need to configure the following in redis6002.conf:

slaveof 127.0.0.1 6001

Starting with Redis2.6, read-only mode is supported from the server, and the mode is the default mode from the server. Read-only mode is controlled by the slave-read-only option in the redis.conf file. Read-only from the server will refuse to execute any write commands, so it does not appear that the data was accidentally written to the server because of an error in the operation.

If slave cannot connect to master because of a network failure, then we can configure whether slave will continue to provide services through Slave-serve-stale-data configuration.

Starting with Redis2.8, to ensure data security, you can configure the primary server to execute write commands only if there are at least N currently connected from the server. However, because Redis uses asynchronous replication, the write data sent by the primary server is not necessarily received from the server, so the likelihood of data loss is still present. If there are at least min-slaves-to-write from the server, and these servers have a delay value of less than min-slaves-max-lag seconds, the primary server performs the write operation requested by the client. You can consider this feature as a conditional relaxed version of C in CAP theory: Although it does not guarantee the persistence of write operations, at least the window that loses data is strictly limited to the specified number of seconds. On the other hand, if the condition does not reach the conditions specified by Min-slaves-to-write and Min-slaves-max-lag, the write operation is not performed, and the primary server returns an error to the client requesting the write operation.

Whether it's the initial connection or reconnection, a SYNC command will be sent from the server to the primary server when a server is set up. The primary server receiving the SYNC command starts executing the Bgsave and saves all newly executed write commands to a buffer during the execution of the save operation. When Bgsave executes, the master server sends the. rdb file from the server to receive the. rdb file from the server, and loads the data from the file into memory. The master server then sends all the content accumulated in the Write command buffer to the server in the format of the Redis command protocol. Even if there are multiple simultaneous send sync from the server to the primary server, the primary server can handle all of the synchronization requests from the server by simply executing the bgsave command once. Automatic reconnection can be made from the server when the connection between the master and slave servers is disconnected, before the Redis version 2.8, the reconnection from the server will always perform a full resynchronization operation, but starting from the Redis 2.8 version, the server can To choose whether to perform a full or partial resynchronization (partial resynchronization) based on the situation of the primary server.