附: 关闭redis
./redis-cli -p <修改的端口号> -a <修改的密码> shutdown
开启redis:
./redis-server redis.conf
每个单实例中的 redis.conf 配置:
# 配置redis日志,便于检查
logfile /usr/local/redis/redis-221.log
# 开启集群模式
cluster-enabled yes
# 每一个节点需要有一个配置文件,需要6份。每个节点处于集群的角色都需要告知其他所有节点,彼此知道,这个文件用于存储集群模式下的集群状态等信息,这个文件是由redis自己维护,我们不用管。如果你要重新创建集群,那么把这个文件删了就行
cluster-config-file nodes-221.conf
# 超时时间,超时则认为master宕机,随后主备切换
cluster-node-timeout 5000
# 开启AOF
appendonly yes
创建集群,在任意节点运行如下命令一次:
#####
# 注意1:如果你使用的是redis3.x版本,需要使用redis-trib.rb来构建集群,最新版使用C语言来构建了,这个要注意
# 注意2:以下为新版的redis构建方式
#####
# 创建集群,主节点和从节点比例为1,1-3为主,4-6为从,这也是最经典用的最多的集群模式。cluster-replicas是几个slave,-a是执行秘密。
./redis-cli --cluster create ip1:port1 ip2:port2 ip3:port3 ip4:port4 ip5:port5 ip6:port6 --cluster-replicas 1 -a 123456
从上图中可以看到,slots槽,用于装数据,主节点有,从节点没有。
在任意节点查看集群信息:
./redis-cli --cluster check 192.168.1.221:6379 -a 123456
查看主从状态信息:
./redis-cli -a 123456
info replication
M221与S225
M222与S226
M223与S224
从节点日志,主要进行复制:
cluster nodes
查看各个节点的信息
如果一个master挂了,那么剩余的2个master会发起投票选举,从挂了的master对应的slave中选举出一个新的master,发生故障的master不会参与投票,这个要注意。
选举的时候需要半数以上的master都投票给同一个slave,那么他才会成为新的master。所以redis集群中至少需要3个主节点,2个是不行的。而且我们也是建议在不同的物理节点上去进行配置,如果是伪分布式集群,那么可能会有问题。
故障转移的主要流程首先是主观下线,然后是客观下线,这个我们在课程里有说过,要以客观为主,也就是半数以上的master都收不到某节点的心跳,则认为他宕机了,此时发起选举。
上图中,225升级为master,原来的221下线。slots自动重新分配。
在新的主225中可以看到221的加入ask询问同步等信息
./redis-cli -a 123456 -c
set name lee
集群中设值与取值,需要加-c
。
图中数据进入到了主222中,那么验证一下从某个从节点中能不能获取,他会跳转到222中去获取,因为现在是一个集群形态。
如果不加-c
,以单实例形式去操作,那么会报错。
关闭主222,观察原来设置的数据,在slave226转变为master后,数据是否存在:
因为数据会主从同步,所以master宕机后,slave中还是会有他的数据。这些数据都是跟着slot走的。
紧接上面的,接着关闭新主226,剩余2主2从,查看状态,你会发现出错,提示说slots分配不均匀,因为有一对主从没有的slot都没了。
随后在任意节点去查询数据,提示说当前集群不可用,我们需要恢复了。
同时有2个redis-master都宕机,那么无法达到半数以上,此时无法选举,当前集群不可用。由于速度比较快,虚拟机里难以演示,所以此处意会一下哈~ (如果半数以上 Master 处于关闭状态那么整个集群处于不可用状态。)
redis集群模式下的几个节点之间也会相互通信,他们的通信协议是gossip,各个节点之间会有ping pong等消息类型,每个节点也维护着redis的元数据,一旦发生更改会相互发送。
新增192.168.1.227 修改redis.conf文件后,启动服务。查看分片信息:
对比现有的master
对比后他自己虽然标识master,但是没起作用,也没加入到现有的集群
这个时候需要使用如下命令,把节点加入到当前集群:
# 添加一个新的节点到现有的集群中。第一个ip为新节点,第二个ip为现有集群中的某个节点ip
新增192.168.1.227
./redis-cli --cluster add-node 192.168.1.227:6379 192.168.1.221:6379 -a 123456
如上图,新节点,加入成功。
这个时候新加入的节点为master了,但是从图中看的出来,并没有slot槽位信息,我们还需要重新分槽,才能使用。
# ip端口是集群中任意一个节点和对应端口号
./redis-cli --cluster reshard ip:port -a 密码
询问需要迁移多少个slots,迁移之后,原来的数据还是存在与slots中的,因为哈希后取模的接口还是对应某个slot,数据还在。
填入需要迁移的节点id,也就是新增的master的id,复制进去。
随后输入all
,表示从每个现有master中都取出一定的slot进行迁移。(done
的话是从指定的节点中拿出一部分slot来迁移)
然后再yes
,表示执行reshard操作。
等待一段时间迁移后,迁移成功。重新检查集群信息。这个时候227中有2000个slot,分别都是从其他节点迁移的一部分共同组合的。
如此一来,新的master节点加入到集群了。
之前的name是在别的master中,由于slot迁移了,这个时候再查询的时候,他会路由到227节点,说明了数据不会因为节点增加而丢失,都会跟着slot走。
测试关闭这台新的master,由于slot不完整,集群不可用。其实也就是说明了整个集群形态下,总数16384个哈希槽必须都存在,缺少了就不完整了。所以就必定需要使用高可用,每个master下都要挂在至少1个slave。
执行如下命令:
./redis-cli --cluster add-node --cluster-slave --cluster-master-id [master-id] [slave-ip:port] [master-ip:port]
添加节点成功。 这个时候查看,可以看到228加入到集群,并且成为了slave:
228的分片信息slave归属为227,如此一来slave添加到某个master下成功了。