一、 主从复制

1. 主从复制简介

redis的主从复制,使用的是异步复制,主服务器可以有多个从服务器,从服务器也可以再接从服务器。复制功能不会阻塞主服务器,如果在配置文件redis.conf中进行相应的设置,复制功能也不会阻塞从服务器。在从服务器删除旧版本数据集并载入新版本数据集的那段时间内,连接请求会被阻塞。
复制功能可以单纯地用于数据冗余,也可以通过让多个从服务器处理只读命令请求来做到读写分离。
可以通过复制功能来让主服务器免于执行持久化操作:只要关闭主服务器的持久化功能,然后由从服务器去执行持久化操作即可。

2. 主从复制的安全性

当配置Redis复制功能时,强烈建议打开主服务器的持久化功能。否则的话要避免主服务器宕机后被自动拉起。
考一下以下会导致主从服务器数据全部丢失的例子:

  1. 假设节点A为主服务器,并且关闭了持久化。并且节点B和节点C从节点A复制数据
  2. 节点A崩溃,然后由自动拉起服务重启了节点A.由于节点A的持久化被关闭了,所以重启之后没有任何数据
  3. 节点B和节点C将从节点A复制数据,但是A的数据是空的,于是就把自身保存的数据副本删除。
  4. 无论何时,数据安全都是极其重要的,所以应该禁止主服务器关闭持久化的同时自动拉起。

3. 主从复制的原理

图片说明

文件说明

  1. 第一步:无论是初次连接还是重新连接,当建立一个从服务器时,从服务器都将向主服务器发送一个SYNC命令。
  2. 第二步:接到SYNC命令的主服务器将开始执行BGSAVE创建rdb文件,并在保存操作执行期间,将所有新执行的写入命令都保存到一个缓冲区里面。
  3. 第三步:当BGSAVE执行完毕后,主服务器将执行保存操作所得的.rdb文件发送给从服务器,从服务器接收这个.rdb文件,并将文件中的数据载入到内存中。
  4. 第四步:之后主服务器会以Redis命令协议的格式,将写命令缓冲区中积累的所有内容都发送给从服务器。

多从和重连

即使有多个从服务器同时向主服务器发送SYNC,主服务器也只需执行一次BGSAVE命令,就可以处理所有这些从服务器的同步请求。
从服务器可以在主从服务器之间的连接断开时进行自动重连,从服务器可以根据主服务器的情况来选择执行完整重同步[2.8以前]还是部分重同步[2.8以后]

4. 主从数据一致性保证

1
2
min-slaves-to-write 1
min-slaves-max-lag 2

运作原理:
从服务器以每秒一次的频率 PING 主服务器一次, 并报告复制流的处理情况。主服务器会记录各个从服务器最后一次向它发送 PING 的时间。
用户可以通过配置, 指定网络延迟的最大值 min-slaves-max-lag ,以及执行写操作所需的至少从服务器数量 min-slaves-to-write 。
如果至少有 min-slaves-to-write 个从服务器,并且这些服务器的延迟值都少于 min-slaves-max-lag秒,那么主服务器就会执行客户端请求的写操作。
可以将这个特性看作 CAP 理论中的 C 的条件放宽版本: 尽管不能保证写操作的持久性,但起码丢失数据的窗口会被严格限制在指定的秒数中。
另一方面, 如果条件达不到 min-slaves-to-write 和 min-slaves-max-lag 所指定的条件,那么写操作就不会被执行,主服务器会向请求执行写操作的客户端返回一个错误。

5. 主从复制的实现

准备两个或两个以上redis实例

1
mkdir /data/redis_m/638{0..2}

配置文件示例

6380

1
2
3
4
5
6
7
8
9
10
cat >/data/redis_m/6380/redis.conf <<'EOF'
port 6380
daemonize yes
pidfile /data/redis_m/6380/redis.pid
loglevel notice
logfile "/data/redis_m/6380/redis.log"
dbfilename dump.rdb
dir /data/redis_m/6380
protected-mode no
EOF

6381

1
2
3
4
5
6
7
8
9
10
cat >/data/redis_m/6381/redis.conf <<'EOF'
port 6381
daemonize yes
pidfile /data/redis_m/6381/redis.pid
loglevel notice
logfile "/data/redis_m/6381/redis.log"
dbfilename dump.rdb
dir /data/redis_m/6381
protected-mode no
EOF

6382

1
2
3
4
5
6
7
8
9
10
cat >/data/redis_m/6382/redis.conf <<'EOF'
port 6382
daemonize yes
pidfile /data/redis_m/6382/redis.pid
loglevel notice
logfile "/data/redis_m/6382/redis.log"
dbfilename dump.rdb
dir /data/redis_m/6382
protected-mode no
EOF

启动

1
2
3
redis-server /data/redis_m/6380/redis.conf
redis-server /data/redis_m/6381/redis.conf
redis-server /data/redis_m/6382/redis.conf

开启主从

redis主从只需要在从节点设置主库信息即可
6381

1
2
redis-cli -p 6381
SLAVEOF 127.0.0.1 6380

6382

1
2
redis-cli -p 6382
SLAVEOF 127.0.0.1 6380

主从状态查询

1
127.0.0.1:6382> info replication

6. 手动切换主从

模拟主库故障

1
2
redis-cli -p 6380
shutdown

启用6381为主

1
2
3
redis-cli -p 6381
info replication
slaveof no one

6382连接新主

1
2
3
redis-cli -p 6382
127.0.0.1:6382> SLAVEOF no one
127.0.0.1:6382> SLAVEOF 127.0.0.1 6381

二、redis高可用[redis-sentinel哨兵]

1. redis-sentinel简介

Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案,当用Redis做Master-slave的高可用方案时,假如master宕机了,Redis本身(包括它的很多客户端)都没有实现自动进行主备切换,而Redis-sentinel本身也是一个独立运行的进程,它能监控多个master-slave集群,发现master宕机后能进行自动切换。

2. 主要功能

监控(Monitoring):

Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

提醒(Notification):

当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送3. 自动故障迁移(Automatic failover):
当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。

3. 实现原理

  1. 发现主服务器
    Sentinel 通过用户给定的配置文件来发现主服务器,并与主服务器创建连个网络连接,命令连接用于向主服务器发送命令,订阅连接用于订阅指定的频道.
  2. 发现从服务
    Sentinel 通过向主服务器发送 INFO 命令来自动获得所有从服务器的地址,并与每个被发现的从服务器创建命令连接和订阅连接。
  3. 发现其他serntinel
    Sentinel 会通过命令连接向被监视的主从服务器发送 “HELLO” 信息[IP、端口号、ID 等],以此来向其他 Sentinel 宣告自己的存在。并通过订阅连接接收其他 Sentinel 的“HELLO” 信息,以此来发现监视同一个主服务器的其他 Sentinel
    Sentinel 之间只会互相创建命令连接,用于进行通信。因为已经有主从服务器作为发送和接收 HELLO 信息的中介,所以 Sentinel之间不会创建订阅连接
  4. 检测实例状态
    Sentinel 使用 PING 命令来检测实例的状态:如果实例在指定的时间内没有返回回复,或者返回错误的回复,那么该实例会被 Sentinel 判断为主观下线。
    如果多个sentinel交流后判断这个服务器下线了,这个时候才是真正的下线,也叫客观下线.所以生成环境一般使用的是奇数个sentinel,实例被多数哨兵认为判断才会真的下线

4. 故障转移步骤

  • 发现主服务器已经进入客观下线状态。
  • 基于Raft leader election协议 ,进行投票选举
  • 如果选举失败,那么在设定的故障迁移超时时间的两倍之后,重新尝试选举。 如果选举成功, 那么执行以下步骤。
  • 选出一个从服务器,并将它升级为主服务器。
  • 向被选中的从服务器发送 SLAVEOF NO ONE 命令,让它转变为主服务器。
  • 通过发布与订阅功能, 将更新后的配置传播给所有其他 Sentinel ,其他 Sentinel 对它们自己的配置进行更新。
  • 向已下线主服务器的从服务器发送 SLAVEOF 命令,让它们去复制新的主服务器。
  • 当所有从服务器都已经开始复制新的主服务器时, leader Sentinel 终止这次故障迁移操作。

5. 高可用哨兵搭建

这里只安装一个哨兵,但实际环境中,一般都会用到3个哨兵共同协作,防止脑裂和单机网络故障导致切换

创建目录

1
2
mkdir /data/redis_m/26380
cd /data/redis_m/26380

创建配置文件

1
2
3
4
5
6
7
cat >>sentinel.conf <<'EOF'
port 26380
dir "/data/redis_m/26380"
sentinel monitor mymaster 127.0.0.1 6380 1
sentinel down-after-milliseconds mymaster 5000
sentinel config-epoch mymaster 0
EOF

启动哨兵

1
redis-sentinel /data/redis_m/26380/sentinel.conf &

故障转移演练

1
2
3
4
5
6
7
8
# 停主库测试:
[root@db01 ~]# redis-cli -p 6380
shutdown
# 查看新主库信息
[root@db01 ~]# redis-cli -p 6381
info replication
# 启动源主库[6380]看状态。
原主库会自动被加入到主从环境做从库

6. 参数解释和常用命令

1)配置文件参数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
sh
# 指定监控master
sentinel monitor mymaster 127.0.0.1 6370 2
{2表示多少个sentinel同意}
# 安全信息
sentinel auth-pass mymaster root
# 超过多久后认为主机宕机
sentinel down-after-milliseconds mymaster 15000
# 当主从切换多久后认为主从切换失败
sentinel failover-timeout mymaster 900000
# 同时最多2个slave可更新配置
sentinel leader-epoch mymaster 2
# 确认mymater SDOWN时长
sentinel config-epoch mymaster 1

2)sentinel命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
PING
# 返回 PONG 。

SENTINEL masters
# 列出所有被监视的主服务器

SENTINEL slaves <master name>
# 列出指定从库

SENTINEL get-master-addr-by-name <master name>
# 返回给定名字的主服务器的 IP 地址和端口号。

SENTINEL reset <pattern>
# 重置所有名字和给定模式 pattern 相匹配的主服务器。

SENTINEL failover <master name>
# 当主服务器失效时,在不询问其他 Sentinel 意见的情况下, 强制开始一次自动故障迁移。