redis主从（redis主从模式）

本篇文章给大家谈谈redis主从，以及redis主从模式对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、redis主从和哨兵
• 2、Redis主从复制的配置过程
• 3、Redis主从模式、哨兵模式以及Cluster 集群模式
• 4、【redis】redis 手动切换主从

redis主从和哨兵

主从复制：主节点负责写数据，从节点负责读数据，主节点定期把数据同步到从节点保证数据的一致性

a,配置主从复制方式一、新增redis6380.conf, 加入 slaveof 192.168.152.128 6379, 在6379启动完后再启6380，完成配置；

b,配置主从世数早复制方式二、redis-server --slaveof 192.168.152.128 6379 临时生效

c,查看状态：info replication

d,断开主从复制：在slave节点，执行6380:slaveof no one

e,断开后再变成主从复制：6380: slaveof 192.168.152.128 6379

f,数据较重要的节点，主从复制时使用密码验证： requirepass

e, 从节点建议用只读模式slave-read-only=yes, 若从节点修改数据，主从数据不一致

h,传输延迟：主从一般部署在不同机器上，复制时存在网络延时问题，redis提供repl-disable-tcp-nodelay参数决定是否关闭TCP_NODELAY,默认为关闭

参数关闭时：无论大小都会及时发布到从节点，占带宽，适用于主从网络好的场景，

参数启用时：主节点合并所有数据成TCP包节省带宽，默认为40毫秒发一次，取决于内核，主从的同步延迟40毫秒，适用于网络环境复杂或带宽紧张，如跨机房

a)一主一从：用于主节点故障转移从节点，当主节点的“写”命令并发高且需要持久化，可以只在从节点开启AOF（主节点不需要），这样即保证了数据的安全性，也避免持久化对主节点的影响

b)一主多从：针对“读”较多的场景，“读”由多个从节点来分担，但节点越多，主节点同步到多节点的次数也越多，影响带宽，也加重主节点的稳定

c)树状主从：一主多从的缺点（主节点推送次数多压力大）可用些方案解决，主节点只推送搜雀一次数据到从节点B，再由从节点B推送到C，减轻主节点推送的压力。

redis 2.8版本以上使用psync命令完成同步，过程分“全量”与“部分”复制

全量复制：一般用于初次复制场景（第一次建立SLAVE后全量）

部分复制：网络出现问题，从节点再次连接主节点时，主节点补发缺少的数据，每次数据增量同步

心跳：主从有长连接心跳，主节点默认每10S向从节点发ping命令，repl-ping-slave-period控制发送频率

a)主从复制，若主节点出现问题，则不能提供服务，需要人工修改配置将从变主

b)主从复制主节点的写能力单机，能力有限

c)单机节点的存储能力也有限

a)主节点(master)故障，从节点slave-1端执行 slaveof no one后变成新主节点；

b)其它的节点成为新主节点的从节点，并从新毕简节点复制数据；

c)需要人工干预，无法实现高可用。

1. 为什么要有哨兵机制？

原理：当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。

其实整个过程只需要一个哨兵节点来完成，首先使用Raft算法（选举算法）实现选举机制，选出一个哨兵节点来完成转移和通知

任务1：每个哨兵节点每10秒会向主节点和从节点发送info命令获取最拓扑结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到

任务2：每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish和subscribe来完成的

任务3：每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据

客观下线：当主观下线的节点是主节点时，此时该哨兵3节点会通过指令sentinel is-masterdown-by-addr寻求其它哨兵节点对主节点的判断，当超过quorum（选举）个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意下线操作，也就说是客观下线

a)每个在线的哨兵节点都可以成为领导者，当它确认（比如哨兵3）主节点下线时，会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；

b)当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；

c)如果哨兵3发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举…………

a)由Sentinel节点定期监控发现主节点是否出现了故障

sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了

b) 当主节点出现故障，此时3个Sentinel节点共同选举了Sentinel3节点为领导，负载处理主节点的故障转移

c) 由Sentinel3领导者节点执行故障转移，过程和主从复制一样，但是自动执行

流程：

1. 将slave-1脱离原从节点，升级主节点，

d) 故障转移后的redis sentinel的拓扑结构图

a) 过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点

b) 选择salve-priority从节点优先级最高（redis.conf）的

c) 选择复制偏移量最大，指复制最完整的从节点

以3个Sentinel节点、2个从节点、1个主节点为例进行安装部署

1. 前提： 先搭好一主两从redis的主从复制，和之前的主从复制搭建一样，搭建方式如下：

A）主节点6379节点（/usr/local/bin/conf/redis6379.conf）：

修改 requirepass 12345678，注释掉#bind 127.0.0.1

B) 从节点redis6380.conf和redis6381.conf: 配置都一样

修改 requirepass 12345678 ,注释掉#bind 127.0.0.1,

加上访问主节点的密码masterauth 12345678 ,加上slaveof 192.168.152.128 6379

2. redis sentinel哨兵机制核心配置 (也是3个节点)：

将三个文件的端口改成: 26379 26380 26381

然后：sentinel monitor mymaster 192.168.152.128 6379 2 //监听主节点6379

三个配置除端口外，其它一样。

3. 哨兵其它的配置 ：只要修改每个sentinel.conf的这段配置即可：

sentinel monitor mymaster 192.168.152.128 6379 2

//监控主节点的IP地址端口，sentinel监控的master的名字叫做mymaster，2代表，当集群中有2个sentinel认为master死了时，才能真正认为该master已经不可用了

sentinel auth-pass mymaster 12345678 //sentinel连主节点的密码

sentinel config-epoch mymaster 2 //故障转移时最多可以有2从节点同时对新主节点进行数据同步

sentinel leader-epoch mymaster 2

sentinel failover-timeout mymasterA **180000 **//故障转移超时时间180s，

a,如果转移超时失败，下次转移时时间为之前的2倍；

b,从节点变主节点时，从节点执行slaveof no one命令一直失败的话，当时间超过 180S 时，则故障转移失败

c,从节点复制新主节点时间超过 180S 转移失败

sentinel down-after-milliseconds mymasterA 300000 //sentinel节点定期向主节点ping命令，当超过了 300S 时间后没有回复，可能就认定为此主节点出现故障了……

sentinel parallel-syncs mymasterA 1 //故障转移后， 1 代表每个从节点按顺序排队一个一个复制主节点数据，如果为3，指3个从节点同时并发复制主节点数据，不会影响阻塞，但存在网络和IO开销

4. 启动redis服务和sentinel服务:

a)先把之前安装的redis里面的标绿色的文件都拷贝到 usr/local/bin目录下，然后再再bin目录下新建一个conf文件夹存放配置好的redis主从配置文件和哨兵配置文件

b)启动主从复制服务，先启动主再启动从

主：./redis-server conf/redis6379.conf

从：

./redis-server conf/redis6380.conf

./redis-server conf/redis6381.conf

c）启动sentinel服务:

./redis-sentinel conf/sentinel_26381.conf

到此服务全部启动完毕

连接到6379的redis的服务，可看到6379就是主节点，他有6380和6381两个从节点

5. 测试： kill -9 6379 杀掉6379的redis服务

可以看到杀掉6379以后6380变为了主节点，6381变为了6380的从节点

重新启动6379以后变为6380的从节点

看日志是分配6380 是6381的主节点，当6379服务再启动时，已变成从节点

假设6380升级为主节点:进入6380info replication 可以看到role:master

打开sentinel_26379.conf等三个配置，sentinel monitor mymaster 192.168.152.128 6380 2

打开redis6379.conf等三个配置, slaveof 192.168.152.128 6380,也变成了6380

注意：生产环境建议让redis Sentinel部署到不同的物理机上。

a，sentinel节点应部署在多台物理机（线上环境）

b，至少三个且奇数个sentinel节点

c，通过以上我们知道，3个sentinel可同时监控一个主节点或多个主节点

sentinel参考资料：

redis sentinel的机制与用法一：

redis sentinel的机制与用法二：

Redis主从复制的配置过程

有两个已经启动的redis节点：

现在需要将上述redis节点配置为主从复制。

在redis的配置文件中加上 slaveof host port 即可实镇搏现。

配置前，查看m161p114中的内容如下：

如下，在服务器192.168.161.115节点的redis的配置文件中增加如下配置：

之后重启redis服务：

此时查看m161p115中的key:

这与m161p114中的内容一致。这说明配置生效，启动从库闷渗数据会直接同步。

此后，从库m161p115将变为只读状态，无法再set内容：

将配置文件中新增的slaveof 注释掉，再重启redis,则主从复制就会关闭，不过从库中的数据不会清除。

当然，主从复制也可以不在配置文件中配置，而直接在命令行中执行命令：

这样数据就会同步过来。

通过info可以看到主从建立成功：

从节点的断开

在从节点执行，slaveof no one 即可。

之后从节点就会变成master状态，但是数据不会清除。如果要清除数据，需要执行flashall

从建立主从复制到断开过程的日制：御罩祥

Redis主从模式、哨兵模式以及Cluster 集群模式

主从模式指的是使用一个Redis实例作为主机，其余的实例作为备份机。一般来说主节点负责写请求，从节点负责读请求，主节点异步的同步给从节点。主节点和从节点保存的数据是相同的，但是因为同步，从节点的数据会有一点延迟。但是主从模式的高可用会有问题。因为主节点挂了之后是没有自动选主机制的，需要人工干预来指定一个从节点作为主节点。

为了解决主从模式不能高可用的问题，哨兵模式就出现了。哨兵模式就是在主从模式的基础上再加一个哨兵集群。每个哨兵都会监控主节点和从节点的状态。如果主节点挂了，就会从从节点中选出一个来作为主节点，以达到高可用的目的。（也就是有了自动选主机制）

哨兵集群中的握团每个节点都会启动三个定时任务

如果一个 实例（instance）距离最后一次有效回复 PING命令的时间超过 down-after-milliseconds 所指定的值，那么这个实例会被 Sentinel标记为 主观下线 。

如果一个 主服务器 被标记为主观下线，那么正在 监视 这个主服务器的所有 Sentinel 节点，要以 每秒一次的频率确认 该主服务器是否的确进入了主观下线状态。

如果一个主服务器 被标记为主观下线，并且有 足够数量的 Sentinel（至少要达到配置文件指定的数量段唯橘）在指定的 时间范围 内同意这一判断，那么这个该主服务器被标记为 客观下线。

哨兵模式解决了故障不能自动恢复的问题，但仍存在的问题是：Redis较难支持在线扩容，对于集群，容量达到上限时在线 扩容会变得很复杂 。

Redis Cluster采用虚拟槽分区，所有的键按照哈山信希函数映射到0~16383槽中，每个Redis节点维护部分槽和槽中的数据。

【redis】redis 手动切换主从

在redis节点：

$ redis-cli  -h  xx.xx.xx.xx  -p  XX  -a  'XX'    shutdown 

不要直接关闭redis进程，使用 shutdown ，能在进程带镇迹关闭前持久化内存旅烂中的数据

待主从切换完毕后：

$  systemctl start redis-server 

架构:  3台服务器，1主2从3哨兵，每台服务有一个主（或从））和蠢并哨兵。

主（哨兵1）：192.168.1.11

从（哨兵2）：192.168.1.12

从（哨兵3）：192.168.1.13

线上redis master异常关机之后重启，  发现redis哨兵模式下 三个节点都是slave，无法选择出主。

登录192.168.1.11（master），关闭redis进程

$ redis-cli  -h  192.168.1.11   -p   6379  -a  'XX'   shutdown 

登录192.168.1.12（new master）

$ redis-cli  -h 192.168.1.12   -p   6379  -a  'XX'      slaveof no one

$ redis-cli  -h 192.168.1.12   -p   6379  -a  'XX'       config set  slave-read-only no

登录192.168.1.13（slave）

$ redis-cli  -h 192.168.1.12    -p   6379  -a  'XX'        config set  masterauth  'XXX'

$ redis-cli  -h 192.168.1.12    -p   6379  -a  'XX'       slaveof 192.168.1.12  6379

启动192.168.1.11 redis进程，成为192.168.1.12（new master）的slave

$  systemctl start redis-server 

$ redis-cli  -h 192.168.1.12    -p 6379  -a  'XX'        config set  masterauth  'XXX'

$ redis-cli  -h 192.168.1.12    -p 6379  -a  'XX'        slaveof 192.168.1.12  6379

Redis的主从切换

redis主从宕机切换 SLAVEOF

手动调整master-slave切换

redis 主从备份（手动切换）

Redis的主从切换

[img]

关于redis主从和redis主从模式的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。