标签：mymaster 主从复制 redis Sentinel sentinel data 节点
一.redis主从复制背景问题
Redis主从复制可将主节点数据同步给从节点，从节点此时有两个作用：
(1)一旦主节点宕机，从节点作为主节点的备份可以随时顶上来。
(2)扩展主节点的读能力，分担主节点读压力。
但是问题是：
一旦主节点宕机，从节点上位，那么需要人为修改所有应用方的主节点地址（改为新的master地址），还需要命令所有从节点复制新的主节点
那么这个问题，redis-sentinel就可以解决了
二. Redis-Sentinel
Redis-Sentinel是redis官方推荐的高可用性解决方案，
当用redis作master-slave的高可用时，如果master本身宕机，redis本身或者客户端都没有实现主从切换的功能。
而redis-sentinel就是一个独立运行的进程，用于监控多个master-slave主从复制，
自动发现master宕机，进行自动切换slave > master。
sentinel主要功能如下：
不时的监控redis是否良好运行，如果节点不可达就会对节点进行下线标识
如果被标识的是主节点，sentinel就会和其他的sentinel节点“协商”，如果其他节点也人为主节点不可达，就会选举一个sentinel节点来完成自动故障转义
在master-slave进行切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换
三.Sentinel的工作方式
每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令
如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。
如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线
在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令
当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次
若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。
若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。
主观下线和客观下线
主观下线：Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。
客观下线：Objectively Down， 简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover.
SDOWN适合于Master和Slave，只要一个 Sentinel 发现Master进入了ODOWN， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对下线的主服务器执行自动故障迁移操作。
ODOWN只适用于Master，对于Slave的 Redis 实例，Sentinel 在将它们判断为下线前不需要进行协商， 所以Slave的 Sentinel 永远不会达到ODOWN。
四.Redis Sentinel架构
redis的一个进程，但是不存储数据，只是监控redis
sentinel 会通过命令连接向被监视的主从服务器发送 “hello”信息,该信息包含sentinel的ip,端口号,id等内容,以此来向其他sentinel宣告自己的存在。与此同时sentinel会通过订阅连接接收其他sentinel的”hello”信息，以此来发现监视同一个主服务器的其他sentinel。
从图中sentinel1 通过发送hello信息来让sentinel2和sentinel3发现自己，其他两个sentinel也会进行类似的操作。
redis主库服务故障，主从复制重新判断主从结构的过程
1.redis命令整理
官网地址：http://redisdoc.com/
redis-cli info #查看redis数据库信息
redis-cli info replication #查看redis的复制授权信息
redis-cli info sentinel #查看redis的哨兵信息
2.配置哨兵模式redis sentinel实现主从复制及自动切换过程
配置五个redis数据库, 一主四从
环境：
192.168.1.209 配置了1主2从
192.168.1.209 配置了2从
（注意由于虚拟机上配置，虚拟机有限，所以将一台服务配置多个从库，生产从不会是这样的，生产中都是一个库一台服务器的）
(1)主从库配置文件如下
192.168.1.209 主库
# 声明端口 port 6379 # 表示后台启动 daemonize yes # 将pid文件放到某目录下 pidfile /data/6379/redis.pid # 日志级别和日志目录 loglevel notice logfile "/data/6379/redis.log" # 持久化相关 # dir /data/6379 # 安全模式 protected-mode no # 密码设置,redis一般不要密码 # requirepass hsz
192.168.1.209 从库1 6380端口
# 声明端口 port 6380 # 表示后台启动 daemonize yes # 将pid文件放到某目录下 pidfile /data/6380/redis.pid # 日志级别和日志目录 loglevel notice logfile "/data/6380/redis.log" # 持久化相关 # dir /data/6380 # 安全模式 protected-mode no # 密码设置,redis一般不要密码 # requirepass hsz slaveof 192.168.1.209 6379
192.168.1.209 从库2 6381 端口
# 声明端口 port 6381 # 表示后台启动 daemonize yes # 将pid文件放到某目录下 pidfile /data/6381/redis.pid # 日志级别和日志目录 loglevel notice logfile "/data/6381/redis.log" # 持久化相关 # dir /data/6380 # 安全模式,如果开启文件不会被修改 protected-mode no # 密码设置,redis一般不要密码 # requirepass hsz dir /data/6381/ dbfilename dbmp.rdb save 900 1 save 300 10 save 60 10000 slaveof 192.168.1.209 6379
192.168.1.208 从库1 6381端口
port 6381 daemonize yes pidfile /data/6381/redis.pid loglevel notice logfile "/data/6381/redis.log" dbfilename dump.rdb dir /data/6381 protected-mode no # 主库ip和端 slaveof 192.168.1.209 6379
192.168.1.208 从库1 6382端口
port 6382 daemonize yes pidfile /data/6382/redis.pid loglevel notice logfile "/data/6382/redis.log" dbfilename dump.rdb dir /data/6382 protected-mode no # 主库ip和端口 slaveof 192.168.1.209 6379
做好配置文件后都进行redis启动
redis-server redis配置文件名
最后确定主从信息及关系：
(2)配置五个哨兵
在配置之前首先进行学习下，配置哨兵的配置文件的各项解析：
# Sentinel节点的端口 port 26379 dir /var/redis/data/ logfile "26379.log" # sentinel announce-ip 127.0.0.1 # 宣告哨兵IP, 此配置只有当使用非127.0.0.1的IP配置哨兵无法成功时加上，同时redis三个服务端也需要同步修改IP # 当前Sentinel节点监控 127.0.0.1:6379 这个主节点 # 2代表判断主节点失败至少需要2个Sentinel节点节点同意 # mymaster是主节点的别名 sentinel monitor mymaster 127.0.0.1 6379 2 # 每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过30000毫秒30s且没有回复，则判定不可达 sentinel down-after-milliseconds mymaster 30000 # 当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，限制每次向新的主节点发起复制操作的从节点个数为1 sentinel parallel-syncs mymaster 1 # 故障转移超时时间为180000毫秒 sentinel failover-timeout mymaster 180000 daemonize yes
关于哨兵的配置，将5个哨兵配置到两台上，一台3个一台2个
那么接下来哨兵1配置（由于和主机同一台所以配置127.0.0.1）：
# vim redis-sentinel-26379.conf
port 26379 dir /var/redis/data/ logfile "26379.log" sentinel monitor mymaster 192.168.1.209 6379 2 sentinel down-after-milliseconds mymaster 30000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000 daemonize yes
启动之前新建日志目录
#mkdir -p /var/redis/data/
使用以下命令启动redis-sentinel
# redis-sentinel redis-sentinel-26379.conf
然后进行查看通信状态：# redis-cli -p 26379 info sentinel
可以从信息看出，有一台主库，ip及端口，4台从库，和1个哨兵，因为才配置一个，所有哨兵为
哨兵2配置：
# vim redis-sentinel-26380.conf
port 26380 dir /var/redis/data/ logfile "26380.log" sentinel monitor mymaster 192.168.1.209 6379 2 sentinel down-after-milliseconds mymaster 30000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000 daemonize yes
启动之前新建日志目录
# mkdir -p /var/redis/data/
使用以下命令启动redis-sentinel
# redis-sentinel redis-sentinel-26380.conf
然后进行查看通信状态：# redis-cli -p 26380 info sentinel
哨兵3配置
# vim redis-sentinel-26380.conf
port 26380 dir /var/redis/data/ logfile "26380.log" sentinel monitor mymaster 192.168.1.209 6379 2 sentinel down-after-milliseconds mymaster 30000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000 daemonize yes
启动之前新建日志目录
# mkdir -p /var/redis/data/
使用以下命令启动redis-sentinel
# redis-sentinel redis-sentinel-26380.conf
然后进行查看通信状态：# redis-cli -p 26380 info sentinel
哨兵4配置
# vim redis-sentinel-26381.conf
port 26381 dir /var/redis/data/ logfile "26381.log" sentinel monitor mymaster 192.168.1.209 6379 2 sentinel down-after-milliseconds mymaster 30000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000 daemonize yes
启动之前新建日志目录
# mkdir -p /var/redis/data/
使用以下命令启动redis-sentinel
# redis-sentinel redis-sentinel-26381.conf
然后进行查看通信状态：# redis-cli -p 26381 info sentinel
哨兵5配置
# vim redis-sentinel-26382.conf
port 26382 dir /var/redis/data/ logfile "26382.log" sentinel monitor mymaster 192.168.1.209 6379 2 sentinel down-after-milliseconds mymaster 30000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000 daemonize yes
启动之前新建日志目录
# mkdir -p /var/redis/data/
使用以下命令启动redis-sentinel
# redis-sentinel redis-sentinel-26382.conf
然后进行查看通信状态：# redis-cli -p 26382 info sentinel
最后可以查看下哨兵的配置文件，会自动加上这些内容：
而从库的配置文件会修改为这一句配置：
(3)进行redis高可用故障实验
关闭主库进程（模拟生产中服务器挂掉）如下截图：
此时进行等待30秒。。。。
从其中一个哨兵进行查看
查看可知：新的主库为192.168.1.209:6381
# redis-cli -p 6381 info replication
到这个redis主库进行查看信息，并查看数据，可知从库可同步数据：
最后高可用实现
标签：mymaster,主从复制,redis,Sentinel,sentinel,data,节点 来源： https://www.cnblogs.com/hszstudypy/p/11561494.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。