Redis-主从复制，哨兵机制及redis cluster

一、Redis主从复制

1.1、主从复制介绍

1）使用异步复制。

2）一个主服务器可以有多个从服务器。从服务器也可以有自己的从服务器。

3）复制功能不会阻塞主服务器

4）可以通过复制功能来让主服务器免于执行持久化操作，由从服务器去执行持久化操作即可。

1.2、数据安全

当配置Redis复制功能时，强烈建议打开主服务器的持久化功能。否则的话，由于延迟等问题，部署的服务应该要避免自动拉起。为了帮助理解主服务器关闭持久化时自动拉起的危险性，参考一下以下会导致主从服务器数据全部丢失的例子：

1. 假设节点A为主服务器，并且关闭了持久化。并且节点B和节点C从节点A复制数据

2. 节点A崩溃，然后由自动拉起服务重启了节点A. 由于节点A的持久化被关闭了，所以重启之后没有任何数据

3. 节点B和节点C将从节点A复制数据，但是A的数据是空的，于是就把自身保存的数据副本删除。

4）在关闭主服务器上的持久化，并同时开启自动拉起进程的情况下，即便使用Sentinel来实现Redis的高可用性，也是非常危险的。因为主服务器可能拉起得非常快，以至于Sentinel在配置的心跳时间间隔内没有检测到主服务器已被重启，然后还是会执行上面的数据丢失的流程。

无论何时，数据安全都是极其重要的，所以应该禁止主服务器关闭持久化的同时自动拉起。

1.3、主从复制原理

原理说明：

1. 副本库通过slaveof 10.0.0.51 6379命令,连接主库,并发送SYNC给主库
2. 主库收到SYNC,会立即触发BGSAVE,后台保存RDB,发送给副本库
3. 副本库接收后会应用RDB快照
4. 主库会陆续将中间产生的新的操作,保存并发送给副本库
5. 到此,我们主复制集就正常工作了
6. 再此以后,主库只要发生新的操作,都会以命令传播的形式自动发送给副本库.
7. 所有复制相关信息,从info信息中都可以查到.即使重启任何节点,他的主从关系依然都在.
8. 如果发生主从临时断开。从库数据没有被破坏的情况下，在下次重连之后，，从库发送PSYNC给主库 (2.8版本之后)
9. 主库只会将从库缺失部分的数据同步给从库应用，达到快速恢复主从的目的

其他说明：

1）SYNC 命令执行示例

2）命令传播

在主从服务器完成同步之后，主服务器每执行一个写命令，它都会将被执行的写命令发送给从服务器执行，这个操作被称为“命令传播”（command propagate）。命令传播是一个持续的过程：只要复制仍在继续，命令传播就会一直进行，使得主从服务器的状态可以一直保持一致

3）复制中的SYNC与PSYNC

①在 Redis 2.8 版本之前，断线之后重连的从服务器总要执行一次完整重同步（full resynchronization）操作。

②从 Redis 2.8 开始，Redis 使用 PSYNC命令代替 SYNC 命令。PSYNC 比起 SYNC 的最大改进在于 PSYNC 实现了部分重同步（partial resync）特性：在主从服务器断线并且重新连接的时候，只要条件允许，PSYNC 可以让主服务器只向从服务器同步断线期间缺失的数据，而不用重新向从服务器同步整个数据库。

SYNC 处理断线重连示例：

PSYNC 处理断线重连示例：

1.4、复制一致性

1.4.1、问题引出

1）在读写分离环境下，客户端向主服务器发送写命令 SET n 10086，主服务器在执行这个写命令之后，向客户端返回回复，并将这个写命令传播给从服务器。

2）接到回复的客户端继续向从服务器发送读命令 GET n ，并且因为网络状态的原因，客户端的 GET命令比主服务器传播的 SET 命令更快到达了从服务器。

3）因为从服务器键 n 的值还未被更新，所以客户端在从服务器读取到的将是一个错误（过期）的 n值。

1.4.2、问题解决

从 Redis 2.8 开始，为了保证数据的安全性，可以通过配置，让主服务器只在有至少 N 个当前已连接从服务器的情况下，才执行写命令。不过，因为 Redis 使用异步复制，所以主服务器发送的写数据并不一定会被从服务器接收到，因此，数据丢失的可能性仍然是存在的。

通过以下两个参数保证数据的安全：

min-slaves-to-write <number of slaves>
min-slaves-max-lag <number of seconds>

这个特性的运作原理：
从服务器以每秒一次的频率 PING 主服务器一次， 并报告复制流的处理情况。
主服务器会记录各个从服务器最后一次向它发送 PING 的时间。

1）用户可以通过配置， 指定网络延迟的最大值 min-slaves-max-lag ，以及执行写操作所需的至少从服务器数量 min-slaves-to-write 。如果至少有 min-slaves-to-write 个从服务器， 并且这些服务器的延迟值都少于 min-slaves-max-lag秒，那么主服务器就会执行客户端请求的写操作。

2）另一方面， 如果条件达不到 min-slaves-to-write 和 min-slaves-max-lag 所指定的条件， 那么写操作就不会被执行，主服务器会向请求执行写操作的客户端返回一个错误。

1.5、主从复制配置

1）环境准备

准备两个或两个以上redis实例：主节点：6380 从节点：6381、6382

mkdir /data/638{0..2}

2）配置文件

cat >>/data/6380/redis.conf<<EOF
port 6380
daemonize yes
pidfile /data/6380/redis.pid
loglevel notice
logfile "/data/6380/redis.log"
dbfilename dump.rdb
dir /data/6380
requirepass 123
masterauth 123
EOF


cat >>/data/6381/redis.conf<<EOF
port 6381
daemonize yes
pidfile /data/6381/redis.pid
loglevel notice
logfile "/data/6381/redis.log"
dbfilename dump.rdb
dir /data/6381
requirepass 123
masterauth 123
EOF


cat >>/data/6382/redis.conf<<EOF
port 6382
daemonize yes
pidfile /data/6382/redis.pid
loglevel notice
logfile "/data/6382/redis.log"
dbfilename dump.rdb
dir /data/6382
requirepass 123
masterauth 123
EOF

3）启动

redis-server /data/6380/redis.conf
redis-server /data/6381/redis.conf
redis-server /data/6382/redis.conf
ps -ef|grep redis

4）开启主从

6381/6382命令行上操作

redis-cli -p 6381 -a 123 SLAVEOF 127.0.0.1 6380
redis-cli -p 6382 -a 123 SLAVEOF 127.0.0.1 6380

5）查询主从状态

redis-cli -p 6380 -a 123 info replication
redis-cli -p 6381 -a 123 info replication
redis-cli -p 6382 -a 123 info replication

示例：

[root@redis-master ~]#  redis-cli -p 6380 -a 123 info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6381,state=online,offset=1,lag=1
slave1:ip=127.0.0.1,port=6382,state=online,offset=1,lag=1
master_repl_offset:1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:0
[root@redis-master ~]#  redis-cli -p 6381 -a 123 info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:8
master_sync_in_progress:0
slave_repl_offset:1
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
[root@redis-master ~]#  redis-cli -p 6382 -a 123 info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:2
master_sync_in_progress:0
slave_repl_offset:15
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

1.6、主从切换

1）模拟主库故障

redis-cli -p 6380 -a 123 shutdown

2）解除主从关系

redis-cli -p 6381 -a 123 
info replication
slaveof no one

3）重新设置主从

#6382连接到6381：
redis-cli -p 6382 -a 123
SLAVEOF no one
SLAVEOF 127.0.0.1 6381		#6382作为6381的从库

二、Redis Sentinel

2.1、哨兵简介

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

2.2、Sentinel 的构造

Sentinel 是一个监视器，它可以根据被监视实例的身份和状态来判断应该执行何种动作。

2.3、哨兵功能

1）监控（Monitoring）：Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

2）提醒（Notification）：当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

3）自动故障迁移（Automatic failover）：当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作，它会将失效主服务器的其中一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为复制新的主服务器；当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。

4）应用透明 ==>相当于mysql MHA vip功能

---------------------------------------------------------------------------------------------------------------------------------------------------

1）发现并连接主服务器

Sentinel 通过用户给定的配置文件来发现主服务器。Sentinel 会与被监视的主服务器创建两个网络连接：

命令连接用于向主服务器发送命令。
订阅连接用于订阅指定的频道，从而发现监视同一主服务器的其他 Sentinel

2）发现并连接从服务器

Sentinel 通过向主服务器发送 INFO 命令来自动获得所有从服务器的地址。跟主服务器一样，Sentinel 会与每个被发现的从服务器创建命令连接和订阅连接

3）发现其他 Sentinel

Sentinel 会通过命令连接向被监视的主从服务器发送 “HELLO” 信息，该消息包含 Sentinel 的 IP、端口号、ID 等内容，以此来向其他 Sentinel 宣告自己的存在。与此同时Sentinel 会通过订阅连接接收其他 Sentinel 的“HELLO” 信息，以此来发现监视同一个主服务器的其他 Sentinel 。sentinel1 通过发送HELLO 信息来让sentinel2 和 sentinel3发现自己，其他两个sentinel 也会进行类似的操作。

4）多个Sentienl之间的链接

Sentinel 之间只会互相创建命令连接，用于进行通信。因为已经有主从服务器作为发送和接收 HELLO 信息的中介，所以 Sentinel之间不会创建订阅连接。

5）检测实例的状态

Sentinel 使用 PING 命令来检测实例的状态：如果实例在指定的时间内没有返回回复，或者返回错误的回复，那么该实例会被 Sentinel 判断为下线

Redis 的 Sentinel 中关于下线（down）有两个不同的概念：
①主观下线（Subjectively Down，简称 SDOWN）指的是单个 Sentinel 实例对服务器做出的下线判断。
②客观下线（Objectively Down，简称 ODOWN）指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的服务器下线判断。（一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线。）
如果一个服务器没有在 master-down-after-milliseconds 选项所指定的时间内，对向它发送 PING 命令的 Sentinel 返回一个有效回复（valid reply），那么 Sentinel 就会将这个服务器标记为主观下线。

6）故障转移FAILOVER

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

2.4、哨兵搭建过程

1）创建哨兵目录

mkdir /data/26380
cd /data/26380

2）哨兵配置文件

cat >>sentinel.conf<<EOF
port 26380
dir "/data/26380"
sentinel monitor mymaster 127.0.0.1 6380 1		#mymaster名称可选，1代表至少一台setinel认为主库宕机，则切换主库（一般是单数）（认为主库宕机的最小票数）
sentinel down-after-milliseconds mymaster 5000	#主库宕机失联最大时间，5s
sentinel auth-pass mymaster 123 				#setinel要监控节点，需要连接（所有节点密码要统一）
EOF

3）启动哨兵

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

如果有问题，可按如下方法解决：

1、重新准备1主2从环境
2、kill掉sentinel进程
3、删除sentinel目录下的所有文件
4、重新搭建sentinel

2.5、故障测试

1）停主库

2）查看哨兵配置

3）重新启动宕机的实例

2.6、哨兵管理命令

redis-cli -p 26380

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 意见的情况下， 强制开始一次自动故障迁移。

#---------------------------------------------------------------
[root@redis-master ~]# redis-cli -p 26380
127.0.0.1:26380> ping
PONG
127.0.0.1:26380> SENTINEL masters
...
127.0.0.1:26380> SENTINEL slaves mymaster
....
127.0.0.1:26380> SENTINEL get-master-addr-by-name mymaster
1) "127.0.0.1"
2) "6382"
127.0.0.1:26380> SENTINEL failover mymaster
.....

三、Redis cluster

3.1、cluster简介

1）Redis 集群是一个可以在多个 Redis 节点之间进行数据共享的设施（installation）。

2）Redis 集群不支持那些需要同时处理多个键的 Redis 命令，因为执行这些命令需要在多个 Redis 节点之间移动数据，并且在高负载的情况下，这些命令将降低 Redis 集群的性能，并导致不可预测的行为。

3）Redis 集群通过分区（partition）来提供一定程度的可用性（availability）：即使集群中有一部分节点失效或者无法进行通讯，集群也可以继续处理命令请求。

4）将数据自动切分（split）到多个节点的能力。当集群中的一部分节点失效或者无法进行通讯时，仍然可以继续处理命令请求的能力。

3.2、集群数据共享

Redis 集群使用数据分片（sharding）而非一致性哈希（consistency hashing）来实现：一个 Redis 集群包含 16384 个哈希槽（hash slot），数据库中的每个键都属于这 16384 个哈希槽的其中一个，集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽，其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和。

节点 A 负责处理 0 号至 5500 号哈希槽。

节点 B 负责处理 5501 号至 11000 号哈希槽。

节点 C 负责处理 11001 号至 16384 号哈希槽。

集群使用公式 CRC16(key) & 16384 计算键 key属于哪个槽

1）高性能

1、在多分片节点中，将16384个槽位，均匀分布到多个分片节点中
2、存数据时，将key做crc16(key),然后和16384进行取模，得出槽位值（0-16383之间）
3、根据计算得出的槽位值，找到相对应的分片节点的主节点，存储到相应槽位上
4、如果客户端当时连接的节点不是将来要存储的分片节点，分片集群会将客户端连接切换至真正存储节点进行数据存储

2）高可用

在搭建集群时，会为每一个分片的主节点，对应一个从节点，实现slaveof的功能，同时当主节点down，实现类似于sentinel的自动failover的功能。

3.3、运行机制

1）所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽.

2）节点的fail是通过集群中超过半数的master节点检测失效时才生效.

3）客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可

4）把所有的物理节点映射到[0-16383]slot上,cluster 负责维护node<->slot<->key

3.4、集群的复制

为了使得集群在一部分节点下线或者无法与集群的大多数（majority）节点进行通讯的情况下，仍然可以正常运作， Redis 集群对节点使用了主从复制功能：集群中的每个节点都有 1 个至 N 个复制品（replica），其中一个复制品为主节点（master），而其余的 N-1 个复制品为从节点（slave）。

在之前列举的节点 A 、B 、C 的例子中，如果节点 B 下线了，那么集群将无法正常运行，因为集群找不到节点来处理 5501 号至 11000 号的哈希槽。

假如在创建集群的时候（或者至少在节点 B 下线之前），我们为主节点 B 添加了从节点 B1 ，那么当主节点 B 下线的时候，集群就会将 B1 设置为新的主节点，并让它代替下线的主节点 B ，继续处理 5501 号至 11000 号的哈希槽，这样集群就不会因为主节点 B 的下线而无法正常运作了。

不过如果节点 B 和 B1 都下线的话， Redis 集群还是会停止运作。

集群的复制特性重用了 SLAVEOF 命令的代码，所以集群节点的复制行为和 SLAVEOF 命令的复制行为完全相同。

3.5、集群故障转移

在集群里面，节点会对其他节点进行下线检测。当一个主节点下线时，集群里面的其他主节点负责对下线主节点进行故障移。换句话说，集群的节点集成了下线检测和故障转移等类似 Sentinel 的功能。因为 Sentinel 是一个独立运行的监控程序，而集群的下线检测和故障转移等功能是集成在节点里面的，它们的运行模式非常地不同，所以尽管这两者的功能很相似，但集群的实现没有重用 Sentinel 的代码。

3.6、集群执行命令情况

1）命令发送给正确的节点

命令发送到了正确的节点：命令要处理的键所在的槽正好是由接收命令的节点负责，那么该节点执行命令，就像单机 Redis 服务器一样。键 date 位于 2022 槽，该槽由节点 7000 负责，命令会直接执行

2）命令发送给了错误的节点

命令发送到了错误的节点：接收到命令的节点并非处理键所在槽的节点，那么节点将向客户端返回一个转向（redirection）错误，告知客户端应该到哪个节点去执行这个命令，客户端会根据错误提示的信息，重新向正确的节点发送命令。键 date 位于 2022 槽，该槽由节点 7000 负责，但错误发送到了7001节点

转向错误的实现:

1）集群中的节点会互相告知对方，自己负责处理哪些槽

2）集群中的每个节点都会记录 16384 个槽分别由哪个节点负责，从而形成一个“槽表”（slot table）。

节点在接收到命令请求时，会通过槽表检查键所在的槽是否由本节点处理：

如果是的话，那么节点直接执行命令；
如果不是的话，那么节点就从槽表里面提取出正确节点的地址信息，然后返回转向错误。

3.7、集群搭建过程

1）环境准备

6个redis实例，一般会放到3台硬件服务器
注：在企业规划中，一个分片的两个分到不同的物理机，防止硬件主机宕机造成的整个分片数据丢失。

端口号：7000-7005

2）安装集群插件

#使用国内源，安装ruby支持
yum install ruby rubygems -y
gem sources -l
gem sources -a http://mirrors.aliyun.com/rubygems/ 
gem sources  --remove https://rubygems.org/
gem sources -l
gem install redis -v 3.3.3

#或者：
gem sources -a http://mirrors.aliyun.com/rubygems/  --remove https://rubygems.org/

3）集群节点准备

mkdir /data/700{0..5}

cat > /data/7000/redis.conf <<EOF
port 7000
daemonize yes
pidfile /data/7000/redis.pid
loglevel notice
logfile "/data/7000/redis.log"
dbfilename dump.rdb
dir /data/7000
protected-mode no
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
EOF

cat > /data/7001/redis.conf <<EOF
port 7001
daemonize yes
pidfile /data/7001/redis.pid
loglevel notice
logfile "/data/7001/redis.log"
dbfilename dump.rdb
dir /data/7001
protected-mode no
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
EOF

cat > /data/7002/redis.conf <<EOF
port 7002
daemonize yes
pidfile /data/7002/redis.pid
loglevel notice
logfile "/data/7002/redis.log"
dbfilename dump.rdb
dir /data/7002
protected-mode no
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
EOF


cat > /data/7003/redis.conf <<EOF
port 7003
daemonize yes
pidfile /data/7003/redis.pid
loglevel notice
logfile "/data/7003/redis.log"
dbfilename dump.rdb
dir /data/7003
protected-mode no
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
EOF


cat > /data/7004/redis.conf <<EOF
port 7004
daemonize yes
pidfile /data/7004/redis.pid
loglevel notice
logfile "/data/7004/redis.log"
dbfilename dump.rdb
dir /data/7004
protected-mode no
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
EOF

cat > /data/7005/redis.conf <<EOF
port 7005
daemonize yes
pidfile /data/7005/redis.pid
loglevel notice
logfile "/data/7005/redis.log"
dbfilename dump.rdb
dir /data/7005
protected-mode no
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
EOF

3.8、集群节点管理

3.8.1、增加新的节点

1）创建新节点的目录及配置文件

mkdir /data/7006
mkdir /data/7007

cat >>/data/7006/redis.conf<<EOF
port 7006
daemonize yes
pidfile /data/7006/redis.pid
loglevel notice
logfile "/data/7006/redis.log"
dbfilename dump.rdb
dir /data/7006
protected-mode no
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
EOF

cat >>/data/7007/redis.conf<<EOF
port 7007
daemonize yes
pidfile /data/7007/redis.pid
loglevel notice
logfile "/data/7007/redis.log"
dbfilename dump.rdb
dir /data/7007
protected-mode no
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
EOF

2）启动新节点

redis-server /data/7006/redis.conf 
redis-server /data/7007/redis.conf

3）添加主节点

redis-trib.rb add-node 127.0.0.1:7006 127.0.0.1:7000

#7006：新加的主节点
#7000：管理节点
#注意：此时新加入的主节点并没有分配槽位，还不能使用

4）转移slot（重新分片），从已有的节点上分配槽位给新添加的节点

redis-trib.rb reshard 127.0.0.1:7000
#16384/4=4096，新节点需要分配的slot为4096个

重新分片过程：

[root@redis-master ~]# redis-trib.rb reshard 127.0.0.1:7000
>>> Performing Cluster Check (using node 127.0.0.1:7000)
M: ffe340c33558da0d97d2bf1c0d5fb677d03607f2 127.0.0.1:7000
   slots:0-5460 (5461 slots) master
   1 additional replica(s)
M: 33d39fb9d19b8fd58527540ca5630552948a2ef9 127.0.0.1:7002
   slots:10923-16383 (5461 slots) master
   1 additional replica(s)
S: 8da392038590f0898ec87fbb7c7b0328fbee5b75 127.0.0.1:7004
   slots: (0 slots) slave
   replicates 9fa6e1fed6ce5048a1fe7ca1424a7b892c7a7740
S: e570f62c75dfa81196e0a76e68fe8facb3642876 127.0.0.1:7003
   slots: (0 slots) slave
   replicates ffe340c33558da0d97d2bf1c0d5fb677d03607f2
S: 0130e90c4dc85caf281ba158c44707c12f7b9f44 127.0.0.1:7005
   slots: (0 slots) slave
   replicates 33d39fb9d19b8fd58527540ca5630552948a2ef9
M: 3da906766793c65696c75adecd1797e782bd6f94 127.0.0.1:7006
   slots: (0 slots) master
   0 additional replica(s)
M: 9fa6e1fed6ce5048a1fe7ca1424a7b892c7a7740 127.0.0.1:7001
   slots:5461-10922 (5462 slots) master
   1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
How many slots do you want to move (from 1 to 16384)? 4096  ##需要移动多少个槽位
What is the receiving node ID? 3da906766793c65696c75adecd1797e782bd6f94  #接受者id
Please enter all the source node IDs.
  Type 'all' to use all the nodes as source nodes for the hash slots.
  Type 'done' once you entered all the source nodes IDs.
Source node #1:all  #来源的节点id
.......
    Moving slot 1363 from ffe340c33558da0d97d2bf1c0d5fb677d03607f2
    Moving slot 1364 from ffe340c33558da0d97d2bf1c0d5fb677d03607f2
Do you want to proceed with the proposed reshard plan (yes/no)?  yes  #同意
.......

分片完之后，再次查看节点的槽位变化：

5）添加从节点

redis-trib.rb add-node --slave --master-id 主节点的id 127.0.0.1:7007 127.0.0.1:7000
#--master-id：主节点的id（7006）

过程说明：

[root@redis-master ~]# redis-cli -p 7000 cluster nodes|grep master
ffe340c33558da0d97d2bf1c0d5fb677d03607f2 127.0.0.1:7000 myself,master - 0 0 1 connected 1365-5460
33d39fb9d19b8fd58527540ca5630552948a2ef9 127.0.0.1:7002 master - 0 1570117851388 3 connected 12288-16383
3da906766793c65696c75adecd1797e782bd6f94 127.0.0.1:7006 master - 0 1570117851892 7 connected 0-1364 5461-6826 10923-12287
9fa6e1fed6ce5048a1fe7ca1424a7b892c7a7740 127.0.0.1:7001 master - 0 1570117850380 2 connected 6827-10922
[root@redis-master ~]# redis-trib.rb add-node --slave --master-id 3da906766793c65696c75adecd1797e782bd6f94 127.0.0.1:7007 127.0.0.1:7000
>>> Adding node 127.0.0.1:7007 to cluster 127.0.0.1:7000
>>> Performing Cluster Check (using node 127.0.0.1:7000)
M: ffe340c33558da0d97d2bf1c0d5fb677d03607f2 127.0.0.1:7000
   slots:1365-5460 (4096 slots) master
   1 additional replica(s)
M: 33d39fb9d19b8fd58527540ca5630552948a2ef9 127.0.0.1:7002
   slots:12288-16383 (4096 slots) master
   1 additional replica(s)
S: 8da392038590f0898ec87fbb7c7b0328fbee5b75 127.0.0.1:7004
   slots: (0 slots) slave
   replicates 9fa6e1fed6ce5048a1fe7ca1424a7b892c7a7740
S: e570f62c75dfa81196e0a76e68fe8facb3642876 127.0.0.1:7003
   slots: (0 slots) slave
   replicates ffe340c33558da0d97d2bf1c0d5fb677d03607f2
S: 0130e90c4dc85caf281ba158c44707c12f7b9f44 127.0.0.1:7005
   slots: (0 slots) slave
   replicates 33d39fb9d19b8fd58527540ca5630552948a2ef9
M: 3da906766793c65696c75adecd1797e782bd6f94 127.0.0.1:7006
   slots:0-1364,5461-6826,10923-12287 (4096 slots) master
   0 additional replica(s)
M: 9fa6e1fed6ce5048a1fe7ca1424a7b892c7a7740 127.0.0.1:7001
   slots:6827-10922 (4096 slots) master
   1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
>>> Send CLUSTER MEET to node 127.0.0.1:7007 to make it join the cluster.
Waiting for the cluster to join.
>>> Configure node as replica of 127.0.0.1:7006.
[OK] New node added correctly.
[root@redis-master ~]# redis-cli -p 7000 cluster nodes|grep slave
e68ab83af8aceae5e92ca16c536a897cf7df74c0 127.0.0.1:7007 slave 3da906766793c65696c75adecd1797e782bd6f94 0 1570118059124 7 connected
8da392038590f0898ec87fbb7c7b0328fbee5b75 127.0.0.1:7004 slave 9fa6e1fed6ce5048a1fe7ca1424a7b892c7a7740 0 1570118058622 5 connected
e570f62c75dfa81196e0a76e68fe8facb3642876 127.0.0.1:7003 slave ffe340c33558da0d97d2bf1c0d5fb677d03607f2 0 1570118059124 4 connected
0130e90c4dc85caf281ba158c44707c12f7b9f44 127.0.0.1:7005 slave 33d39fb9d19b8fd58527540ca5630552948a2ef9 0 1570118058119 6 connected

3.8.2、删除节点

#删除master节点之前首先要使用reshard移除master的全部slot,然后再删除当前节点
redis-trib.rb del-node 127.0.0.1:7006 1c98b2b2ce18f88c76821cdb82dba4defaa5eb48
redis-trib.rb del-node 127.0.0.1:7007 00185d1cf069b23468d5863202ac651f0d02a9f8

1）查看当前槽位分配状态：

127.0.0.1:7006 master - 0 1570152124813 7 connected 0-1364 5461-6826 10923-12287

                                     需要归还         1365       1365        1365

2）将之前获取的槽位分批归还

#1.归还7000的槽位
[root@redis-master ~]# redis-trib.rb reshard 127.0.0.1:7000
>>> Performing Cluster Check (using node 127.0.0.1:7000)
M: ffe340c33558da0d97d2bf1c0d5fb677d03607f2 127.0.0.1:7000
   slots:1365-5460 (4096 slots) master
   1 additional replica(s)
S: e68ab83af8aceae5e92ca16c536a897cf7df74c0 127.0.0.1:7007
   slots: (0 slots) slave
   replicates 3da906766793c65696c75adecd1797e782bd6f94
M: 33d39fb9d19b8fd58527540ca5630552948a2ef9 127.0.0.1:7002
   slots:12288-16383 (4096 slots) master
   1 additional replica(s)
S: 8da392038590f0898ec87fbb7c7b0328fbee5b75 127.0.0.1:7004
   slots: (0 slots) slave
   replicates 9fa6e1fed6ce5048a1fe7ca1424a7b892c7a7740
S: e570f62c75dfa81196e0a76e68fe8facb3642876 127.0.0.1:7003
   slots: (0 slots) slave
   replicates ffe340c33558da0d97d2bf1c0d5fb677d03607f2
S: 0130e90c4dc85caf281ba158c44707c12f7b9f44 127.0.0.1:7005
   slots: (0 slots) slave
   replicates 33d39fb9d19b8fd58527540ca5630552948a2ef9
M: 3da906766793c65696c75adecd1797e782bd6f94 127.0.0.1:7006
   slots:0-1364,5461-6826,10923-12287 (4096 slots) master
   1 additional replica(s)
M: 9fa6e1fed6ce5048a1fe7ca1424a7b892c7a7740 127.0.0.1:7001
   slots:6827-10922 (4096 slots) master
   1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
How many slots do you want to move (from 1 to 16384)? 1365   #归还的槽位
What is the receiving node ID? ffe340c33558da0d97d2bf1c0d5fb677d03607f2  #7000接受者
Please enter all the source node IDs.
  Type 'all' to use all the nodes as source nodes for the hash slots.
  Type 'done' once you entered all the source nodes IDs.
Source node #1:3da906766793c65696c75adecd1797e782bd6f94  ##7006要删除的节点
Source node #2:done
......
    Moving slot 1363 from 3da906766793c65696c75adecd1797e782bd6f94
    Moving slot 1364 from 3da906766793c65696c75adecd1797e782bd6f94
Do you want to proceed with the proposed reshard plan (yes/no)? yes
.........

#2.同理归还1365槽位给7001
#3.同理归还1365槽位给7002

查看最后归还结果：

3）删除主从节点（最好先删除从节点后删除主节点）

[root@redis-master ~]# redis-cli -p 7000 cluster nodes
ffe340c33558da0d97d2bf1c0d5fb677d03607f2 127.0.0.1:7000 myself,master - 0 0 8 connected 0-5460
e68ab83af8aceae5e92ca16c536a897cf7df74c0 127.0.0.1:7007 slave 33d39fb9d19b8fd58527540ca5630552948a2ef9 0 1570153094607 10 connected
33d39fb9d19b8fd58527540ca5630552948a2ef9 127.0.0.1:7002 master - 0 1570153093599 10 connected 12287-16383
8da392038590f0898ec87fbb7c7b0328fbee5b75 127.0.0.1:7004 slave 9fa6e1fed6ce5048a1fe7ca1424a7b892c7a7740 0 1570153094102 9 connected
e570f62c75dfa81196e0a76e68fe8facb3642876 127.0.0.1:7003 slave ffe340c33558da0d97d2bf1c0d5fb677d03607f2 0 1570153094102 8 connected
0130e90c4dc85caf281ba158c44707c12f7b9f44 127.0.0.1:7005 slave 33d39fb9d19b8fd58527540ca5630552948a2ef9 0 1570153093599 10 connected
3da906766793c65696c75adecd1797e782bd6f94 127.0.0.1:7006 master - 0 1570153092594 7 connected
9fa6e1fed6ce5048a1fe7ca1424a7b892c7a7740 127.0.0.1:7001 master - 0 1570153094102 9 connected 5461-12286
[root@redis-master ~]# redis-trib.rb del-node 127.0.0.1:7007 e68ab83af8aceae5e92ca16c536a897cf7df74c0
>>> Removing node e68ab83af8aceae5e92ca16c536a897cf7df74c0 from cluster 127.0.0.1:7007
>>> Sending CLUSTER FORGET messages to the cluster...
>>> SHUTDOWN the node.
[root@redis-master ~]# redis-trib.rb del-node 127.0.0.1:7006 3da906766793c65696c75adecd1797e782bd6f94
>>> Removing node 3da906766793c65696c75adecd1797e782bd6f94 from cluster 127.0.0.1:7006
>>> Sending CLUSTER FORGET messages to the cluster...
>>> SHUTDOWN the node.
[root@redis-master ~]#

注意：删除之后，删除节点的进程会自动关闭

posted @ 2019-10-03 20:12 运维人在路上阅读(1383) 评论(0) 编辑收藏举报

刷新页面返回顶部

运维人在路上

当你发现自己的才华撑不起野心时，就请安静下来学习吧

Redis-主从复制，哨兵机制及redis cluster

一、Redis主从复制

1.1、主从复制介绍

1.2、数据安全

1.3、主从复制原理

1.4、复制一致性

1.4.1、问题引出

1.4.2、问题解决

1.5、主从复制配置

1）环境准备

1.6、主从切换

二、Redis Sentinel

2.1、哨兵简介

2.2、Sentinel 的构造

2.3、哨兵功能

2.4、哨兵搭建过程

2.5、故障测试

2.6、哨兵管理命令

三、Redis cluster

3.1、cluster简介

3.2、集群数据共享

3.3、运行机制

3.4、集群的复制

3.5、集群故障转移

3.6、集群执行命令情况

3.7、集群搭建过程

3.8、集群节点管理

3.8.1、增加新的节点

3.8.2、删除节点

公告