1 redis的主从复制
配置复制的方式有以下三种:
- 配置文件配置slaveof{masterHost}{masterPort}随Redis启动生效。
- 在redis-server启动命令后加入--slaveof{masterHost}{masterPort}生 效
- 直接使用命令:slaveof{masterHost}{masterPort}生效。
slaveof配置都是在从节点发起,这时6379作为主节点
命令流程如下:
查看主从复制状态
命令:info replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6379,state=online,offset=43,lag=0
断开复制
slaveof命令不但可以建立复制,还可以在从节点客户端执行slaveof no one来断 开与主节点复制关系
这是在使用命令查看, info replication, 发现已经断开。
流程如下:
1) 断开与主节点的复制关系
2) 从节点晋升为主节点 。
从节点不会抛弃原有数据,只是无法获取主节点数据。
切主操作
slaveof命令还可以实现切主操作,所谓切主是指把当前从节点对主 节点的复制切换到另一个主节点。执行slaveof{newMasterIp}
流程如下:
1) 断开与就主节点的关系
2) 与新节点建立连接
3)删除从节点当前所有数据
4) 对新主节点进行复制操作
注: 如果想了解redis 的复制原理。更多可以查看 《redis开发与运维》。
主从复制可以主节点的数据改变同步给主节点。 从节点的两个作用
1)作为主节点的一个备份, 一旦主节点出现故障,不可达。 从节点便可以备用主几点。 手动切主操作。 并且尽量保证数据不丢失。 (主从最终一致性)
2)从节点可以扩展主节点的读能力,
主从复制所带来的问题:
1) 一旦主机节点出现故障, 需要手动进行切主操作, 并修改配置。 其他从节点也需要指定对应的主节点。 整个过程都需要人工干预;
2) 主节点的写能力首先单机限制;
3) 存储能力受单机限制;2和3 都是属于redis的高可用问题。
2 redis的哨兵机制
redis哨兵机制的目的就是解决 : 主从复制的缺陷的方案之一 。
结构图如下:
1 流程大体如下
1 此时的主节点出故障, 2个从节点则断开连接
2 每个sentinel节点定期监控,发现主节点故障, 不可达
3 多个sentinel 节点对主节点故障不可达, 达成一致, 则会选出领导节点
4 由选举处理的领导者, 进行故障转移。将 redis-slave 设置为主节点, redis- master 和redis-slave2 重新指定新的节点 (过程不需要认为干预)
故障转移后的为:
liux 部署如下:
三个redis 实例:
master_redis 主节点 端口6379
slave1_redis 从节点1 端口6378
slave2_redis 从节点2 端口6377
server.conf 配置如下
master
可以跨网络访问: bind 0.0.0.0
设置密码: requirepass ‘123456’
配置redis日志文件位置: logfile “ redis_6379.log”
设置存储文件名字: dbfilename "dump-6379.rdb"
文件路径:dir "/opt/soft/redis/data/"
slave1和slave2 如下 (主节点 和端口自行修改)
可以跨网络访问: bind 0.0.0.0
设置密码: requirepass ‘123456’
指定主服务器,replicaof 127.0.0.1 6379
指定主服务器密码:masterauth 123456
配置redis日志文件位置: logfile “ redis_6378.log”
设置存储文件名字: dbfilename "dump-6378.rdb"
文件路径:dir "/opt/soft/redis/data/
使用命令查看其中节点
使用 info replication 查看连接情况
sentinel 集群配置(都在同一台虚拟机)
sentinel_1 主节点 端口26379 sentinel_26379.conf
sentinel_2 从节点1 端口26378 sentinel_26378.conf
sentinel_3 从节点2 端口26377 sentinel_26377.conf
创建 sentinel.config文件。 根据ip和端口的不同设置不同
port 26379
daemonize yes
logfile "26379.log"
dir "./"
sentinel monitor mymaster 127.0.0.1 7000 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 15000
sentinel auth-pass mymaster 123
bind 127.0.0.1
配置说明:
sentinel monitor <master-name> <ip> <redis-port> <quorum>
告诉sentinel去监听地址为ip:port的一个master,这里的master-name可以自定义,quorum是一个数字,指明当有多少个sentinel认为一个master失效时,master才算真正失效。
sentinel auth-pass <master-name> <password>
设置连接master和slave时的密码,注意的是sentinel不能分别为master和slave设置不同的密码,因此master和slave的密码应该设置相同。
sentinel down-after-milliseconds <master-name> <milliseconds>
这个配置项指定了需要多少失效时间,一个master才会被这个sentinel主观地认为是不可用的。 单位是毫秒,默认为30秒
sentinel parallel-syncs <master-name> <numslaves>
这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步,这个数字越小,完成failover所需的时间就越长,但是如果这个数字越大,就意味着越 多的slave因为replication而不可用。可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
sentinel failover-timeout <master-name> <milliseconds>
failover-timeout 可以用在以下这些方面:
1. 同一个sentinel对同一个master两次failover之间的间隔时间。
2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
3.当想要取消一个正在进行的failover所需要的时间。
4.当进行failover时,配置所有slaves指向新的master所需的最大时间。不过,即使过了这个超时,slaves依然会被正确配置为指向master,但是就不按parallel-syncs所配置的规则来了。
开启哨兵集群
启动哨兵
./redis-sentinel sentinel_26379.conf
./redis-sentinel sentinel_26378.conf
./redis-sentinel sentinel_26377.conf
确认哨兵机制:
redis-cli -h 127.0.0.1 -p 26379 info Sentinel
正常显示。
日常踩坑:
开启了3个, 当只有主, 没有从????这是为何???
在redis.conf 加上主从连接密码
masterauth 123456 # 若主服务设置了密码需要加上,在设置哨兵时主从之间连接需要(变更主从需要连接master 的密码.建议主从2个选项都设置上)
或者 在sentinel.conf 中 password 要对应一样sentinel auth-pass <master-name> <password>