redis 主从 哨兵

Redis 是一个开源(BSD许可)的,内存中的数据结构存储系统,它可以用作数据库、缓存和消息中间件。

它支持多种类型的数据结构,如 字符串(strings)……

与memcached一样,为了保证效率,数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者
把修改操作写入追加的记录文件,并且在此基础上实现了master-slave(主从)同步。

Redis 是一个高性能的key-value数据库。 redis的出现,很大程度补偿了memcached这类key/value存储的不足,
在部 分场合可以对关系数据库起到很好的补充作用。
它提供了Java,C/C++,C#,PHP,JavaScript,Perl,Object-C,Python,Ruby,Erlang等客户端,使用很方便。 
 
Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步,从服务器可以是关联其他从服务器的主服务器。
这使得Redis可执行单层树复制。存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制,
使得从数据库在任何地方同步树时,可订阅一个频道并接收主服务器完整的消息发布记录。
同步对读取操作的可扩展性和数据冗余很有帮助。
 
 
 

redis主从复制

redis主从复制的特点:

  • 一个Master可以有多个slave主机,支持链式复制;
  • Master以非阻塞方式同步数据至slave主机

 

 

主从复制 同时存在以下几个问题:

  1. 一旦 主节点宕机从节点 晋升成 主节点,同时需要修改 应用方 的 主节点地址,还需要命令所有 从节点去 复制 新的主节点,整个过程需要 人工干预

  2. 主节点 的 写能力 受到 单机的限制

  3. 主节点 的 存储能力 受到 单机的限制

  4. 原生复制 的弊端在早期的版本中也会比较突出,比如:Redis 复制中断 后,从节点 会发起 psync。此时如果 同步不成功,则会进行 全量同步主库 执行 全量备份 的同时,可能会造成毫秒或秒级的 卡顿

主从结构配置
  • 配置master节点
  • # vi /redis-4.0.10/redis.conf 
bind 0.0.0.0     #绑定地址
requirepass 123456   #启用密码认证
#默认master节点修改这两项就可以了,也可以进行其他设置
  • 配置各slave节点
bind 0.0.0.0    
slaveof 10.10.20.90 6379   #定义master信息
masterauth 123456  #认证

 

保存、重启redis
此时登录到master节点查看信息:
10.10.20.90:6379> CLIENT LIST 
id=3 addr=10.10.20.91:59980 fd=7 name=sentinel-2199a7c3-cmd age=556 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping id=4 addr=10.10.20.91:59982 fd=8 name=sentinel-2199a7c3-pubsub age=556 idle=1 flags=N db=0 sub=1 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=subscribe id=11 addr=10.10.20.90:47354 fd=15 name= age=55 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client id=5 addr=10.10.20.92:46180 fd=9 name=sentinel-1a83a49f-cmd age=556 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=ping id=9 addr=10.10.20.90:45468 fd=13 name=sentinel-9f117ed7-cmd age=541 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping id=10 addr=10.10.20.90:45470 fd=14 name=sentinel-9f117ed7-pubsub age=541 idle=1 flags=N db=0 sub=1 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=subscribe id=6 addr=10.10.20.92:46182 fd=10 name=sentinel-1a83a49f-pubsub age=556 idle=1 flags=N db=0 sub=1 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=subscribe id=7 addr=10.10.20.92:33030 fd=11 name= age=555 idle=1 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=replconf id=8 addr=10.10.20.91:38063 fd=12 name= age=555 idle=0 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=replconf

 

或者使用指令INFO replication指令查看信息:

10.10.20.90:6379> INFO replication
# Replication
role:master
connected_slaves:2
slave0:ip=10.10.20.92,port=6379,state=online,offset=194161,lag=1
slave1:ip=10.10.20.91,port=6379,state=online,offset=194431,lag=0
master_replid:cf428ae662f1880d3897f9b648671edd8d1ed006
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:194431
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:194431


接下来可以进行简单的验证复制,在master节点设置一个key,看两个slave节点复制情况:
master节点创建一个key

# redis-cli -h 10.10.20.90 -p 6379
10.10.20.90:6379> set 123 hello
OK

两个slave节点查看:

10.10.20.91:6379> get 123 
hello

10.10.20.92:6379> get 123 
hello

 

slave节点定义也可以通过指令设置,设置后立即生效,并且会被保存至配置文件中,指令配置方式如下:

配置slave节点:

redis-cli> SLAVEOF <MASTER_IP> <MASTER_PORT>
redis-cli> CONFIG SET masterauth <PASSWORD>

slaveof 10.10.20.90 6379
config set masterauth 123456

redis主从复制相关配置

slave-serve-stale-data yes : 是否可以把不新鲜的数据服务与客户端
slave-read-only yes : 从节点只读,启用slaveof定义后才生效
repl-diskless-sync no :是否同时向多个从节点同时发数据
repl-diskless-sync-delay 5 :发送的延迟时间
repl-ping-slave-period 10 探测从节点状态
repl-timeout 60 探测节点超时时间
repl-disable-tcp-nodelay no : 启用nodelay
repl-backlog-size 1mb
slave-priority 100 : 从节点优先级,复制集群中,主节点故障时,sentinel应用场景中的主节点选举时使用的优先级;数字越小优先级越高,但0表示不参与选举;
min-slaves-to-write 3:主节点仅允许其能够通信的从节点数量大于等于此处的值时接受写操作;
min-slaves-max-lag 10:从节点延迟时长超出此处指定的时长时,主节点会拒绝写入操作;

 

 

 
Sentinel(哨兵)
是用于监控redis集群中Master状态的工具,是Redis 的高可用性解决方案,
sentinel哨兵模式已经被集成在redis2.4之后的版本中。sentinel是redis高可用的解决方案,
sentinel系统可以监视一个或者多个redis master服务,以及这些master服务的所有从服务;
 
当某个master服务下线时,自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。

sentinel可以让redis实现主从复制,当一个集群中的master失效之后,

sentinel可以选举出一个新的master用于自动接替master的工作,

集群中的其他redis服务器自动指向新的master同步数据。

一般建议sentinel采取奇数台,防止某一台sentinel无法连接到master导致误切换。其结构如下:

 

 

 

 sentinel还能监控多个master-slave集群,发现master宕机后能进行自动切换。

sentinel集群工作原理

sentinel集群通过给定的配置文件发现master,启动时会监控master。通过向master发送info信息获得该服务器下面的所有从服务器。

sentinel集群通过流言协议与其他sentinel通信,以此来发现监视同一个主服务器的其他sentinel;
集群之间会互相创建命令连接用于通信。

sentinel集群使用ping命令来检测实例的状态,如果在指定的时间内(down-after-milliseconds)没有回复或则返回错误的回复,sentinel会认为主节点宕机,但是并不会立即提升一个从节点为新的master,因为会存在误判的情况,此时为主观宕机
此时当sentinel集群中有一半以上的节点通告master为宕机状态时,此时为客观宕机
sentinel基于选举协议选举提升从节点为新的master,从节点之间根据优先级来决策谁会成为新的master,修复的节点重新上线后作为从节点工作。


配置哨兵:
对每台哨兵的配置文件进行修改

# vim /etc/redis-sentinel.conf

bind 0.0.0.0
port 26379

#监控第一个集群 sentinel monitor mymaster
-1 10.10.20.90 6379 2
#监控第二个集群(如果存在) 
sentinel monitor mymaster-2 x.x.x.x 6379 2

  #关闭保护模式
   protected-mode no
  #开启后台进程模式
   daemonize yes
  #master密码
   sentinel auth-pass master 12345

 

参数说明:

sentinel monitor < master-name > < ip > < redis-port > < quorum >
sentinel auth-pass < master-name > < password >
< quorum >即至少有quorum个sentinel节点同时判定主节点故障时,才认为其真的故障;
sentinel down-after-milliseconds < master-name > < milliseconds >
监控到指定的集群的主节点异常状态持续多久方才将标记为“故障”;
sentinel parallel-syncs < master-name > < numslaves >
指在failover过程中,能够被sentinel并行配置的从节点的数量;
sentinel failover-timeout < master-name > < milliseconds >
sentinel必须在此指定的时长内完成故障转移操作,否则,将视为故障转移操作失败;
sentinel notification-script < master-name > < script-path > :
通知脚本,此脚本被自动传递多个参数;

 

 

Sentinel 客户端命令

显示被监控的所有 主节点 以及它们的状态

10.10.20.91:26379> SENTINEL masters
1)  1) "name"
    2) "master"
    3) "ip"
    4) "10.10.20.90"
    5) "port"
    6) "6379"
    7) "runid"
    8) "6f28549e9b0d3b5f8697aa318e4403aee544e0ab"
    9) "flags"
   10) "master"
   11) "link-pending-commands"
   12) "0"
   13) "link-refcount"
   14) "1"
   15) "last-ping-sent"
   16) "0"
   17) "last-ok-ping-reply"
   18) "374"
   19) "last-ping-reply"
   20) "374"
   21) "down-after-milliseconds"
   22) "30000"
   23) "info-refresh"
   24) "9071"
   25) "role-reported"
   26) "master"
   27) "role-reported-time"
   28) "14556886"
   29) "config-epoch"
   30) "2"
   31) "num-slaves"
   32) "2"
   33) "num-other-sentinels"
   34) "3"
   35) "quorum"
   36) "2"
   37) "failover-timeout"
   38) "180000"
   39) "parallel-syncs"
   40) "1"
redis-cli -h SENTINEL_HOST -p SENTINEL_PORT
redis-cli>
SENTINEL masters
SENTINEL slaves < MASTER_NAME >
SENTINEL failover < MASTER_NAME >
SENTINEL get-master-addr-by-name < MASTER_NAME >

 

启动顺序:先起  主、从,再启动哨兵

 

posted @ 2019-11-14 17:31  乌托邦眺望  阅读(206)  评论(0编辑  收藏  举报