文章目录
主从复制的概念
主从复制:是指将一台Reis服务器的数据,复制到其他的redis服务器。前者称为主节点(master/leader),后者称为从节点(slave/follower);数据的复制时由主节点到从节点单向进行, 在集群中,主节点负责写操作,从节点负责读操作 。默认情况下,每台redis服务器都是主节点
主从复制的作用:
1.数据冗余:主从复制实现了数据的热备份,是持久化备份策略的另一种数据冗余方式
2.故障恢复:当主节点出现问题时,可以改用从节点提供服务,实现快速的故障恢复
3.负载均衡:在主从复制的基础上,配合读写分离,即主节点写入,从节点读取,分担服务器负载。尤其是在写少读多的场景下,可以通过部署多个从节点分担读取负载,极大提高redis服务器的并发量
4.高可用(集群):通过哨兵和集群的基础上实现高可用
集群模型图
一、环境配置
由于redis默认每个节点都为主节点,因此只需要配置从机
命令方式配置主从
1. 查看当前库的信息
info replication
查看当前库信息
connected_saves:0
表示当前没有从机
2. 配置从机,复制配置文件
需要修改的配置文件,修改成对应的端口的配置
1.端口 port 6379
2.pid名字 pidfile /var/run/redis_6379.pid
3.log文件名字 logfile "6379.log"
4.rdb文件名 dbfilename dump6379.rdb
3. 根据配置文件分别启动服务
如下图,成功启动了三个redis服务
4. 主机测试ping
5. 配置从机,一主(6379)二从(6380,6381)
slaveof host port //配置指定ip和端口的作为自己的主节点
slave no one //恢复到主机身份
6380从机配置,如图可见role已经从master变为slave
查看6379的主机,已经进行了主从的关联
将6381从机也执行slaveof命令,可以看到6379主机已经连接到了两台从机
注意:此时的命令配置只是暂时的,在真正的生产环境中的配置应该是配置文件中进行配置
配置文件方式配置主从
此种方式在redis服务启动时就已经确定了主从关系
二、主从读写测试
注意:如果是使用命令配置的主从关系,在从机重启后自动会变回主机
三、主从复制原理
slave启动成功连接到master后会发送一个sync的同步,master接收到命令后启动后台的存盘进程,同时收集所有用于修改数据集命令,在后台进程执行完毕后,master将传送整个数据文件到slave,一次完成同步。从机只要是重新连接到了master,一次完全同步(全量复制)将自动执行
- 全量复制:slave服务在接收到数据库文件数据后,将其存盘并加载到内存中
- 增量复制:master继续将新的所有的收集到的修改命令依次传给slave,完成同步
四、哨兵模式
概述
哨兵模式是一个独立运行的进程,通过发送命令,等待redis服务器响应来监控主机是否故障,如果故障就根据投票数自动将从库转换为主库的模式。
基本模型
单哨兵模式
- 通过发送命令,让redis主从服务器返回,监控其运行状态
- 哨兵检测到master宕机,会自动将slave切换成master,然后通过发布订阅模式通知其他的从服务器修改配置文件切换主机
多哨兵模型
如果master服务器宕机,哨兵1接收不到master返回的信息,主观上哨兵1认为主服务器不可用,此时线上叫做主观下线。在其他哨兵检测到master也不可用,并且数量达到一定值的时候,一个哨兵发情failover(故障转移)操作,切换成功后通过发布订阅模式,让其他哨兵把自己监控的从服务器实现切换主机的操作,这个过程叫做客观下线
实际操作
1.新增哨兵配置文件
sentinel.conf
#核心配置
#sentinel monitor 被监控的名称 host port 选举时的权重值
sentinel monitor myredis 192.168.0.184 6379 1
2.启动哨兵
./redis-sentinel config/sentinel.conf
3.模拟主机宕机后哨兵的选举
主机6379执行shutdown命令
稍等片刻即可打印出哨兵选举的结果
查看6380和6379的配置信息
原来的主机恢复服务后,只能归并到新的主机
小结
优点:
-
哨兵集群基于主从复制的模式,继承了所有主从复制的优点
-
主从可以切换,可以故障转移(failover),系统可用性更高
-
哨兵模式是自动的主从模式的升级,系统的健壮性更高
缺点: -
redis扩展性不高,集群容量到达上限时,只能横向扩展
-
哨兵模式的配置繁杂
sentinel.conf全配置
# Example sentinel.conf
# *** IMPORTANT ***
# 绑定IP地址
# bind 127.0.0.1 192.168.1.1
# 保护模式(是否禁止外部链接,除绑定的ip地址外)
# protected-mode no
# port <sentinel-port>
# 此Sentinel实例运行的端口,集群时,需要多个配置
port 26379
# 默认情况下,Redis Sentinel不作为守护程序运行。 如果需要,可以设置为 yes。
daemonize no
# 启用守护进程运行后,Redis将在/var/run/redis-sentinel.pid中写入一个pid文件
pidfile /var/run/redis-sentinel.pid
# 指定日志文件名。 如果值为空,将强制Sentinel日志标准输出。守护进程下,如果使用标准输出进行日志记录,则日志将发送到/dev/null
logfile ""
# sentinel announce-ip <ip>
# sentinel announce-port <port>
# 上述两个配置指令在环境中非常有用,因为NAT可以通过非本地地址从外部访问Sentinel。
#
# 当提供announce-ip时,Sentinel将在通信中声明指定的IP地址,而不是像通常那样自动检测本地地址。
#
# 类似地,当提供announce-port 有效且非零时,Sentinel将宣布指定的TCP端口。
#
# 这两个选项不需要一起使用,如果只提供announce-ip,Sentinel将宣告指定的IP和“port”选项指定的服务器端口。
# 如果仅提供announce-port,Sentinel将通告自动检测到的本地IP和指定端口。
#
# Example:
#
# sentinel announce-ip 1.2.3.4
# dir <working-directory>
# 每个长时间运行的进程都应该有一个明确定义的工作目录。对于Redis Sentinel来说,/tmp就是自己的工作目录。
dir /tmp
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
#
# 告诉Sentinel监听指定主节点,并且只有在至少<quorum>哨兵达成一致的情况下才会判断它 O_DOWN 状态。
#
#
# 副本是自动发现的,因此您无需指定副本。
# Sentinel本身将重写此配置文件,使用其他配置选项添加副本。另请注意,当副本升级为主副本时,将重写配置文件。
#
# 注意:主节点(master)名称不能包含特殊字符或空格。
# 有效字符可以是 A-z 0-9 和这三个字符 ".-_".
sentinel monitor mymaster 127.0.0.1 6379 2
# 如果redis配置了密码,那这里必须配置认证,否则不能自动切换
# Example:
#
# sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
# sentinel down-after-milliseconds <master-name> <milliseconds>
#
# 主节点或副本在指定时间内没有回复PING,便认为该节点为主观下线 S_DOWN 状态。
#
# 默认是30秒
sentinel down-after-milliseconds mymaster 30000
# sentinel parallel-syncs <master-name> <numreplicas>
#
# 在故障转移期间,多少个副本节点进行数据同步
sentinel parallel-syncs mymaster 1
# sentinel failover-timeout <master-name> <milliseconds>
#
# 指定故障转移超时(以毫秒为单位)。 它以多种方式使用:
#
# - 在先前的故障转移之后重新启动故障转移所需的时间已由给定的Sentinel针对同一主服务器尝试,是故障转移超时的两倍。
#
# - 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
#
# - 取消已在进行但未生成任何配置更改的故障转移所需的时间
#
# - 当进行failover时,配置所有slaves指向新的master所需的最大时间。
# 即使过了这个超时,slaves依然会被正确配置为指向master。
#
# 默认3分钟
sentinel failover-timeout mymaster 180000
# 脚本执行
#
# sentinel notification-script和sentinel reconfig-script用于配置调用的脚本,以通知系统管理员或在故障转移后重新配置客户端。
# 脚本使用以下规则执行以进行错误处理:
#
# 如果脚本以“1”退出,则稍后重试执行(最多重试次数为当前设置的10次)。
#
# 如果脚本以“2”(或更高的值)退出,则不会重试执行。
#
# 如果脚本因为收到信号而终止,则行为与退出代码1相同。
#
# 脚本的最长运行时间为60秒。 达到此限制后,脚本将以SIGKILL终止,并重试执行。
# 通知脚本
#
# sentinel notification-script <master-name> <script-path>
#
# 为警告级别生成的任何Sentinel事件调用指定的通知脚本(例如-sdown,-odown等)。
# 此脚本应通过电子邮件,SMS或任何其他消息传递系统通知系统管理员 监控的Redis系统出了问题。
#
# 使用两个参数调用脚本:第一个是事件类型,第二个是事件描述。
#
# 该脚本必须存在且可执行,以便在提供此选项时启动sentinel。
#
# 举例:
#
# sentinel notification-script mymaster /var/redis/notify.sh
# 客户重新配置脚本
#
# sentinel client-reconfig-script <master-name> <script-path>
#
# 当主服务器因故障转移而变更时,可以调用脚本执行特定于应用程序的任务,以通知客户端,配置已更改且主服务器地址已经变更。
#
# 以下参数将传递给脚本:
#
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
#
# <state> 目前始终是故障转移 "failover"
# <role> 是 "leader" 或 "observer"
#
# 参数 from-ip, from-port, to-ip, to-port 用于传递主服务器的旧地址和所选副本的新地址。
#
# 举例:
# sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
# 安全
# 避免脚本重置,默认值yes
# 默认情况下,SENTINEL SET将无法在运行时更改notification-script和client-reconfig-script。
# 这避免了一个简单的安全问题,客户端可以将脚本设置为任何内容并触发故障转移以便执行程序。
sentinel deny-scripts-reconfig yes
# REDIS命令重命名
#
#
# 在这种情况下,可以告诉Sentinel使用不同的命令名称而不是正常的命令名称。
# 例如,如果主“mymaster”和相关副本的“CONFIG”全部重命名为“GUESSME”,我可以使用:
# SENTINEL rename-command mymaster CONFIG GUESSME
# 设置此类配置后,每次Sentinel使用CONFIG时,它将使用GUESSME。 请注意,实际上不需要尊重命令案例,因此在上面的示例中写“config guessme”是相同的。
# SENTINEL SET也可用于在运行时执行此配置。
# 为了将命令设置回其原始名称(撤消重命名),可以将命令重命名为它自身:
# SENTINEL rename-command mymaster CONFIG CONFIG