redis4.0.1主从配置及Sentinel配置自动Failover

﹏ヽ暗。殇╰゛Y 2024-02-18 14:25 6阅读 0赞

一、单机版  
1、前提条件  
yum install gcc-c++

2、安装redis

wget http://download.redis.io/releases/redis-4.0.1.tar.gz

tar -xf redis-4.0.1.tar.gz  
cd redis-xxxx  
make  
make install  
  
3、测试Redis是否安装成功  
后台启动redis  
./redis-server redis.conf

***注：分别在每台机器上安装以上过程***

4、 **redis主从复制**

#### **1)概述说明**    ####

A）[Redis][]的复制功能是支持多个[数据库][Link 1]之间的数据同步。一类是主数据库（master）一类是从数据库（slave），主数据库可以进行读写操作，当发生写操作的时候自动将数据同步到从数据库，而从数据库一般是只读的，并接收主数据库同步过来的数据，一个主数据库可以有多个从数据库，而一个从数据库只能有一个主数据库。

B）通过[redis][Redis]的复制功能可以很好的实现数据库的读写分离，提高服务器的负载能力。主数据库主要进行写操作，而从数据库负责读操作。

**2)主从复制过程**

主从复制过程：见下图

![20160503192249524][]

**3)过程：**

1：当一个从数据库启动时，会向主数据库发送sync命令，

2：主数据库接收到sync命令后会开始在后台保存快照（执行rdb操作），并将保存期间接收到的命令缓存起来

3：当快照完成后，redis会将快照文件和所有缓存的命令发送给从数据库。

4：从数据库收到后，会载入快照文件并执行收到的缓存的命令。

注意：redis2.8之前的版本：当主从数据库同步的时候从数据库因为网络原因断开重连后会重新执行上述操作，不支持断点续传。

redis2.8之后支持断点续传。

**4)配置图说明整个过程**

*  1)Redis主从结构支持一主多从

主节点：192.168.1.220

从节点：192.168.1.221

从节点：192.168.1.222

注意：所有从节点的配置都一样

*  redis服务器上各自存在一个Sentinel，监控本机redis的运行情况，并通知给闭路环上其它的redis节点；
 *  当master发生异常（例如：宕机和断电等）导致不可运行时，Sentinel将通知给其它节点，而剩余节点上的Sentinel将重新选举出新的master，而原来的master重新恢复正常后，则一直扮演slave角色；  
    
 *  规定整个架构体系中，master提供读写服务，而slave只提供读取服务。

![Center][]

**5）实现过程**

5.1、编辑master(220)的配置文件

vi /etc/redis/redis.conf

\# 开启守护模式 daemonize yes

\# 指定数据存储目录 dir /home/data/redis

\# 每秒一次aof写 appendfsync everysec

\# 打开aof持久化 appendonly yes

5.2、编辑slave(221和222上)的配置文件

Slave redis.conf  
\# 指定所属的主机  
slaveof 192.168.1.220 6379  
\# 指定从机"只读"

slave-read-only yes

启动所有主从上的redis;

redis-server redis.conf &

5.3、编辑Sentinel文件

注：所有节点上都需要配置

\# 将sentinel配置文件拷贝到/etc/redis目录后编辑  
cp /usr/local/redis/sentinel.conf /etc/redis/sentinel.conf  
vi /etc/redis/sentinel.conf  
\# sentinel通讯端口  
port 26379  
\# sentinel需要监控的master/slaver信息，格式为sentinel monitor <mastername> <masterIP> <masterPort> <quorum>  
\# 其中<quorum>应该小于集群中slave的个数，当失效的节点数超过了<quorum>,则认为整个体系结构失效  
sentinel monitor redisMaster 192.168.1.220 6379 2  
\# master被当前sentinel实例认定为失效的间隔时间，格式为sentinel down-after-milliseconds <mastername> <milliseconds>  
sentinel down-after-milliseconds redisMaster 10000  
\# 当新master产时，同时进行“slaveof”到新master并进行同步复制的slave个数  
\# 在salve执行salveof同步时，将会终止客户端请求。  
\# 此值较大,意味着“集群”终止客户端请求的时间总和和较大。  
\# 此值较小,意味着“集群”在故障转移期间，多个salve向客户端提供服务时仍然使用旧数据。  
sentinel parallel-syncs redisMaster 1  
\# failover过期时间。当failover开始后，在此时间内仍然没有触发任何failover操作，当前sentinel将会认为此次failoer失败。  
sentinel failover-timeout redisMaster 60000  
完成后，将此配置文件拷贝到其它节点的相同目录下。  
  
5.4、启动所有主从上的sentinel  
  
前提是它们各自的server已成功启动  
cd /usr/local/redis/src  
./redis-sentinel /etc/redis/sentinel.conf

6）测试  
  
6.1、在任意一个节点上查看主从机的复制信息  
  
cd /usr/local/redis/src  
  
1）查看Master节点信息：  
  
./redis-cli -h 192.168.1.220 -p 6379 info Replication  
\# Replication  
role:master  
connected\_slaves:2  
slave0:ip=192.168.1.221,port=6379,state=online,offset=128948,lag=1  
slave1:ip=192.168.1.222,port=6379,state=online,offset=128948,lag=0  
master\_replid:5028bb58ea35368581727adcdba72163a8e70670  
master\_replid2:98859319bdef11765e0ec74d61abc2d7be43340b  
master\_repl\_offset:128948  
second\_repl\_offset:125275  
repl\_backlog\_active:1  
repl\_backlog\_size:1048576  
repl\_backlog\_first\_byte\_offset:81109  
repl\_backlog\_histlen:47840  
从上图可看出，此时220的角色为master，有两个slave（221和222）被连接成功。此时打开master的sentinel.conf，在末尾可看到如下自动写入的内容：  
\# Generated by CONFIG REWRITE  
sentinel leader-epoch mymaster 0  
sentinel monitor redismaster 192.168.1.220 6379 2  
sentinel config-epoch redismaster 0  
sentinel leader-epoch redismaster 0  
sentinel known-slave redismaster 192.168.1.222 6379  
sentinel known-slave redismaster 192.168.1.221 6379  
sentinel known-sentinel redismaster 192.168.1.222 26379 370a40a8d49ebce870eb59444a5a24f26cfbf315  
sentinel known-sentinel redismaster 192.168.1.221 26379 4cc596d8e9cf2e370718adf16d1034ab8cf32192  
sentinel current-epoch 0  
  
2）查看Slave节点信息：  
  
./redis-cli -h 192.168.1.221 -p 6379 info Replication  
此时221（或222，将命令行的ip换为222）的角色为slave，它们所属的master为220。此时打开slave的sentinel.conf，在末尾可看到如下自动写入的内容：  
root@node-2:/root\#redis-cli -h 192.168.1.221 -p 6379 info replication  
\# Replication  
role:slave  
master\_host:192.168.1.220  
master\_port:6379  
master\_link\_status:up  
master\_last\_io\_seconds\_ago:1  
master\_sync\_in\_progress:0  
slave\_repl\_offset:954319  
slave\_priority:100  
slave\_read\_only:1  
connected\_slaves:0  
master\_replid:3e435dc0968df07f64bb40b6beac6e6ec0df0b32  
master\_replid2:0000000000000000000000000000000000000000  
master\_repl\_offset:954319  
second\_repl\_offset:-1  
repl\_backlog\_active:1  
repl\_backlog\_size:1048576  
repl\_backlog\_first\_byte\_offset:342831  
repl\_backlog\_histlen:611489  
root@node-2:/root\#  
  
  
3）客户端连接到master后，set一条测试数据  
  
root@node-1:/root\#redis-cli -h 192.168.1.220 -p 6379  
192.168.1.220:6379> set name 1000;  
OK  
4）连接到任意一个节点上后，通过get命令可以获取数据  
  
 root@node-2:/root\#redis-cli -h 192.168.1.222  
192.168.1.222:6379> get name  
"1000;"  
  
5）在任意一个slave上执行诸如set这样的写入操作时，将得到如下示例的错误信息：

root@node-2:/root\#redis-cli -h 192.168.1.222  
192.168.1.222:6379> get name  
"1000;"  
192.168.1.222:6379> set a 10  
(error) READONLY You can't write against a read only slave.  
  
6）关掉任意一个slave节点，所有节点的sentinel都可以检测到，出现如下示例信息：

root@node-2:/root\#redis-cli -h 192.168.1.222  
192.168.1.222:6379> get name  
"1000;"  
192.168.1.222:6379> set a 10  
(error) READONLY You can't write against a read only slave.  
192.168.1.222:6379> shutdown  
从上图可看出221被sentinel检测到已处于关闭状态，此时再来查看剩余节点的主从信息，它们的角色不会发生变化，只是master上的connected\_slaves变为了1

root@node-1:/root\#redis-cli -h 192.168.1.220 -p 6379 info replication  
\# Replication  
role:master  
connected\_slaves:1  
slave0:ip=192.168.1.221,port=6379,state=online,offset=1068437,lag=1  
master\_replid:3e435dc0968df07f64bb40b6beac6e6ec0df0b32  
master\_replid2:0000000000000000000000000000000000000000  
master\_repl\_offset:1068581  
second\_repl\_offset:-1  
repl\_backlog\_active:1  
repl\_backlog\_size:1048576  
repl\_backlog\_first\_byte\_offset:342376  
repl\_backlog\_histlen:726206  
root@node-1:/root\#

17312:X 18 Aug 13:57:14.238 \# WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.  
17312:X 18 Aug 13:57:14.238 \# Sentinel ID is 370a40a8d49ebce870eb59444a5a24f26cfbf315  
17312:X 18 Aug 13:57:14.238 \# +monitor master redismaster 192.168.1.220 6379 quorum 2  
17312:X 18 Aug 13:57:14.238 \# +monitor master mymaster 127.0.0.1 6379 quorum 2  
17312:X 18 Aug 13:57:24.262 \# +sdown master mymaster 127.0.0.1 6379  
17312:X 18 Aug 13:57:44.279 \# +sdown sentinel fc14ecf5463a0cf7141bf276333c8d4b7df1350d 192.168.1.220 26379 @ redismaster 192.168.1.220 6379  
17312:X 18 Aug 13:57:44.279 \# +sdown sentinel 4cc596d8e9cf2e370718adf16d1034ab8cf32192 192.168.1.221 26379 @ redismaster 192.168.1.220 6379  
17312:X 18 Aug 14:06:11.139 \# +sdown slave 192.168.1.215:6379 192.168.1.222 6379 @ redismaster 192.168.1.220 6379  
7）重启被关闭的slave节点，所有节点的sentinel都可以检测到，可看出221又被sentinel检测到已处于可用状态，此时再来查看节点的主从信息，它们的角色仍然不会发生变化，master上的connected\_slaves又变为了2  
./redis-cli -h 192.168.1.220 -p 6379 info Replication  
\# Replication  
role:master  
connected\_slaves:2  
slave0:ip=192.168.1.221,port=6379,state=online,offset=128948,lag=1  
slave1:ip=192.168.1.222,port=6379,state=online,offset=128948,lag=0  
master\_replid:5028bb58ea35368581727adcdba72163a8e70670  
master\_replid2:98859319bdef11765e0ec74d61abc2d7be43340b  
master\_repl\_offset:128948  
second\_repl\_offset:125275  
repl\_backlog\_active:1  
repl\_backlog\_size:1048576  
repl\_backlog\_first\_byte\_offset:81109  
repl\_backlog\_histlen:47840  
8）关掉220master节点，待所有节点的sentinel都检测到后，再来查看两个Slave节点的主从信息，发现其中一个节点的角色通过选举后会成为master：  
./redis-cli -h 192.168.1.221 -p 6379 info Replication  
\# Replication  
role:master  
connected\_slaves:1  
slave1:ip=192.168.1.222,port=6379,state=online,offset=128948,lag=0  
master\_replid:5028bb58ea35368581727adcdba72163a8e70670  
master\_repl\_offset:128948  
second\_repl\_offset:125275  
repl\_backlog\_active:1  
repl\_backlog\_size:1048576  
repl\_backlog\_first\_byte\_offset:81109  
repl\_backlog\_histlen:47840  
从上图的最后一行监控信息可看出，222此时被选举为master，此时打开的222的redis.conf文件，slaveof配置项已被自动删除了。而221和220的redis.conf文件中slaveof配置项的值被自动修改为192.168.31.222 6379。  
在这个新master上执行诸如set这样的写入操作将被成功执行  
  
set name daniele\_222  
  
9）重启220，待所有节点的sentinel都检测到后，再来查看所有节点的主从信息，此时222的master角色不会被重新抢占，而220角色会从原来的master变为了slave  
./redis-cli -h 192.168.1.221 -p 6379 info Replication  
\# Replication  
role:master  
connected\_slaves:2  
slave0:ip=192.168.1.220,port=6379,state=online,offset=128948,lag=1  
slave1:ip=192.168.1.222,port=6379,state=online,offset=128948,lag=0  
master\_replid:5028bb58ea35368581727adcdba72163a8e70670  
master\_replid2:98859319bdef11765e0ec74d61abc2d7be43340b  
master\_repl\_offset:128948  
second\_repl\_offset:125275  
repl\_backlog\_active:1  
repl\_backlog\_size:1048576  
repl\_backlog\_first\_byte\_offset:81109  
repl\_backlog\_histlen:47840

此时执行get name得到的值为daniele\_222，而不是原来的daniele\_220，因为220重启后会自动从新的master中同步数据。此时打开220的redis.conf文件，会在末尾找到如下信息：

slaveof 192.168.1.222 6379

[Redis]: http://lib.csdn.net/base/redis
[Link 1]: http://lib.csdn.net/base/mysql
[20160503192249524]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/fe2fdaa8c82a4e8f96011906252073f2.png
[Center]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/21a33e85c2c744d8bc31b5dc8d1b49c3.png