部署redis主从
# redis的主从同步功能
https://www.cnblogs.com/pyyu/p/10012904.html (opens new window)
redis主从同步
redis集群中在数据库复制是通过主从同步来实现的
主节点(Master)把数据分发给从节点(slave)
主从同步的好处在于高可用，redis节点有冗余设计
# 主从同步示例
准备两个或两个以上redis实例
redis 类型 状态
6379 master 可读可写
6380 slave 可读
6381 slave 可读
2
3
4
5
1、主要还是写nginx.conf配置文件
！pkill -9 redis 需要清空redis端口，在公司的话要注意用这个
redis_6379.conf
port 6379
daemonize yes
pidfile /data/6379/redis.pid
loglevel notice
logfile "/data/6379/redis.log"
dbfilename dump.rdb
dir /data/6379
protected-mode no
2
3
4
5
6
7
8
redis_6380.conf
port 6379
daemonize yes
pidfile /data/6379/redis.pid
loglevel notice
logfile "/data/6379/redis.log"
dbfilename dump.rdb
dir /data/6379
protected-mode no
slaveor 127.0.0.1 6379
2
3
4
5
6
7
8
9
redis_6381.conf
port 6379
daemonize yes
pidfile /data/6379/redis.pid
loglevel notice
logfile "/data/6379/redis.log"
dbfilename dump.rdb
dir /data/6379
protected-mode no
slaveor 127.0.0.1 6379
2
3
4
5
6
7
8
9
可以用重定向的方式添加：在从节点中配置主 slaveor 127.0.0.1 6379
echo slaveof 127.0.0.1 6379 >> /opt/redis-4.0.10/redis_6380.conf
mkdir -p /data/{6379,6380,6381}
2、启动三个redis实例
redis-server redis_6379.conf
redis-server redis_6380.conf
redis-server redis_6381.conf
# 主从规划
主节点：6379
从节点：6381、6380
2
3
4
5
6
7
3、检查主从状态
从库：
127.0.0.1:6380> info replication
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
....
2
3
4
5
6
7
8
主库：
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=609,lag=1
...
2
3
4
5
6
7
出现这些信息表示连接成功
4、测试
主写入数据，从读
主
127.0.0.1:6380> set name chaoge
从
127.0.0.1:6381>get name
2
3
4
从写数据就报错
(error) READONLY You can't write against a read only slave.
# 手动进行主从复制故障切换
模拟如果主redis故障了，将从升级为主
#关闭主库6379
redis-cli -p 6379
shutdown # 输入shutdown关掉6379的服务器
2
3
检查从库主从信息，此时状态为master_link_status:down ,成功的话是up
redis-cli -p 6380
info replication
redis-cli -p 6381
info replication
# 主的状态已经为down
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:down
...
2
3
4
5
6
7
8
9
10
11
12
既然主库挂了，我想要在6380 6381之间选一个新的主库
1.关闭6380的从库身份（关闭之后就是主）
redis-cli -p 6380
info replication
slaveof no one # 去掉slaveof从的配置，变成主
127.0.0.1:6380> info replication
role:master
...
2
3
4
5
6
7
8
9
10
2.将6381设为6380的从库
# 6381连接到6380：
[root@db03 ~]# redis-cli -p 6381
127.0.0.1:6381> SLAVEOF no one
127.0.0.1:6381> SLAVEOF 127.0.0.1 6380
127.0.0.1:6380> info replication
2
3
4
5
6
3.测试
主写入数据，从读
主
127.0.0.1:6380> set name chaoge
从
127.0.0.1:6381>get name
2
3
4
从写数据就报错
(error) READONLY You can't write against a read only slave.
！！！！这个只是通过命令更改，后面还是要改配置脚本
# redis-sentinel主从复制高可用
详细资料：https://www.cnblogs.com/pyyu/p/9718679.html (opens new window)
配置redis主从功能，如果master主挂了，我们可以手动切换从为主。但是手动切换比较麻烦，所以就有redis-sentinel哨兵，给每个redis开启一个进程去监事，如果主master挂了，自动把从切换成主。
Redis-Sentinel是redis官方推荐的高可用性解决方案，
当用redis作master-slave的高可用时，如果master本身宕机，redis本身或者客户端都没有实现主从切换的功能。
而redis-sentinel就是一个独立运行的进程，用于监控多个master-slave集群，
自动发现master宕机，进行自动切换slave > master。
2
3
4
5
sentinel主要功能如下：
不时的监控redis是否良好运行，如果节点不可达就会对节点进行下线标识
如果被标识的是主节点，sentinel就会和其他的sentinel节点“协商”，如果其他节点也人为主节点不可达，就会选举一个sentinel节点来完成自动故障转义
在master-slave进行切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换
Sentinel的工作方式：
每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令
如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。
如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线
在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令
当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次
若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。
若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。
主观下线和客观下线
主观下线：Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。
客观下线：Objectively Down， 简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover.
SDOWN适合于Master和Slave，只要一个 Sentinel 发现Master进入了ODOWN， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对下线的主服务器执行自动故障迁移操作。
ODOWN只适用于Master，对于Slave的 Redis 实例，Sentinel 在将它们判断为下线前不需要进行协商， 所以Slave的 Sentinel 永远不会达到ODOWN。
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
主从复制架构
