Redis哨兵(sentinel)

前言
- 原理
架构图
下载
命令
配置
启动
查看
Sentinel(哨兵)配置
常用命令
Q&A
- Redis主从配置异常解决：Error condition on socket for SYNC: Connection refused
- （DENIED Redis is running in protected mode）

前言

背景:测试环境的redis集群被运维回收，无奈之下只能自己动手，Redis高可用集群架构的搭建。

原理

Redis的哨兵(sentinel)系统用于管理多个redis服务器,该系统执行以下三个任务:

监控(Monitoring):哨兵(sentinel)会不断地检查你的Master和Slave是否运作正常。
提醒(Notification):当被监控的某个Redis出现问题时,哨兵(sentinel)可以通过API向管理员或者其他应用程序发送通知。
自动故障迁移(Automatic failover):当一个Master不能正常工作时，哨兵(sentinel)会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master,并让失效Master的其他Slave改为复制新的Master;当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master，客户端实际获取的链接是哨兵返回的。

哨兵(sentinel)是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel)进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。

每个哨兵(sentinel)会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown).

若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置.

虽然哨兵(sentinel)释出为一个单独的可执行文件redis-sentinel ,但实际上它只是一个运行在特殊模式下的Redis服务器，你可以在启动一个普通Redis服务器时通过给定--sentinel选项来启动哨兵(sentinel).

哨兵(sentinel)的一些设计思路和zookeeper非常类似。

架构图

下载

首页地址：http://redis.io/

最新稳定版下载地址:http://download.redis.io/releases/redis-3.2.9.tar.gz

# tar -xvf redis-3.2.9.tar.gz

# cd redis-3.2.9

# make install

# make test

命令

redis-server    -h

Usage: ./redis-server [/path/to/redis.conf] [options]

./redis-server - (read config from stdin)

./redis-server -v or --version

./redis-server -h or --help

./redis-server --test-memory

Examples:

./redis-server (run the server with default conf)

./redis-server /etc/redis/6379.conf

./redis-server --port 7777

./redis-server --port 7777 --slaveof 127.0.0.1 8888

./redis-server /etc/myredis.conf --loglevel verbose

Sentinel mode:

./redis-server /etc/sentinel.conf --sentinel

配置

daemonize yes        ###daemon后台运行模式

pidfile /var/run/redis.pid  ###pidfile

port 6379  ###默认6379端口

tcp-backlog 511  ###tcp三次握手等待确认ack最大的队列数

bind 192.168.65.128 127.0.0.1  ###绑定的监听的ip,可同时写多个ip,不写默认监控0.0.0.0

timeout 0  ###关闭空闲客户端,0为disable

tcp-keepalive 0 ###是否开启tcp长连接,定义socket连接timeout时长

loglevel notice  ###定义日志级别为notice(输出必要的日志)

logfile "/var/log/redis/redis.log" ###定义日志输出目录

databases 16  ###允许redis定义的最大的db簇

###开启rdb并应用如下数据保存策略,aof和rdb可同时启用,aof强烈建议开启

save 900 1

save 300 10

save 60 10000

stop-writes-on-bgsave-error yes  ###有任何问题导致的bgsave失败都停止redis的对外服务

rdbcompression yes  ###rdb写压缩

rdbchecksum yes  ###rdb文件正确性检查

dbfilename dump.rdb  ###rdb文件名称(dump.rdb可任意起)

dir /var/lib/redis/    ###rdb文件写目录

# slaveof     ###如果是slave需要写明master

# masterauth     ###master密码验证(因为redis基于内存,作用不大)

slave-serve-stale-data no  ###如果master宕机,slave是否还正常对外服务no->停止服务

slave-read-only yes    ###salve是否只读(默认只读)

repl-diskless-sync no  ### Disk-backed 启动新进程写rdb到disk,然后增量传输到salves 方式二:Diskless 直接写salve sockers,而不用写disk,当网络好的时候建议使用,但因为用到的是M/S+哨兵的架构,随时可能会进行主从切换,这个方式暂时不用

repl-diskless-sync-delay 5  ##每5s传输一次diskless开启后生效

repl-ping-slave-period 3  ###slave每3s ping测试master是否存活

repl-timeout 10      ###定义replicationtxuq  timeout时间,这里的时间要大于repl-ping-slave-period里的时间,不然后一直发生low traffic between the master and the slave问题

repl-disable-tcp-nodelay no  ###yes 一条线40milliseconds发送一次数据包,意识着更小的tcp packets和更小的带宽去发送到slave,但在slave会有相应的数据延迟. No,刚相反.一般上我们期望是低延迟,所以最选择no是个不错的选择,但如果在复杂的网络情况或m/s之间有很多中继网络,这里建议修改为yes

slave-priority 100  ###slave优先级别,数字越小优先级别越高,当master宕机时优先选取slave

# min-slaves-to-write 3  ###当最少有3个slave延迟<= 10s时,master才正常提供服务

# min-slaves-max-lag 10  ###当最少有3个slave延迟<= 10s时,master才正常提供服务

maxmemory  1536000000  #1.5G  ###单位 ,redis最大占用内存数,当超过1.5G时redis会根据策略清理内存key

#############6种清理策略

# volatile-lru -> remove the key with an expire set using an LRU algorithm ##推荐使用

# allkeys-lru -> remove any key according to the LRU algorithm

# volatile-random -> remove a random key with an expire set

# allkeys-random -> remove a random key, any key

# volatile-ttl -> remove the key with the nearest expire time (minor TTL)

# noeviction -> don't expire at all, just return an error on write operations

maxmemory-policy volatile-lru  ###使用LRU算法清理过期key

# maxmemory-samples 3  ###LRU算法和TTL算法均为模糊算法,该精确算法redis会选择3个keys选择最少使用的一个key进行删除, 个人不建议使用

appendonly yes  ###aof持久化,增量写disk,比aof慢,但更可靠.企业的默认选择,有的会两者均开启

appendfilename "appendonly.aof"  ###aof文件名

# appendfsync always

appendfsync everysec  ###建议使用该方式

# appendfsync no

no-appendfsync-on-rewrite no  ##建议no, 主要用来缓和redis调用fsync()写数据时间长的问题.当BGSAVE或BGREWRITEAOF被调用期间,fsync()进程将阻止被调用,即相当于

auto-aof-rewrite-percentage 100  ###当文件大小达到64mb的100%大小时开始rewrite aof文件

auto-aof-rewrite-min-size 64mb  ###当文件大小达到64mb的100%大小时开始rewrite aof文件

aof-load-truncated yes  ###当aof文件被损坏时,redis将返回错误并退出

lua-time-limit 5000  ###LUA scripts最大执行时间,单位(milliseconds),超出后返回查询错误并写日志

slowlog-log-slower-than 10000 ###单位microseconds(毫秒) 1000000 microseconds=1 s,记录执行时长超过10000 microseconds的执行命令

slowlog-max-len 128  ###最大长度为128

latency-monitor-threshold 0  ###监控相关,关闭就好

notify-keyspace-events ""  ###空表示关闭,发布相关key的操作记录到所有 client

######下面是高级设置,个人保持为默认配置

hash-max-ziplist-entries 512

hash-max-ziplist-value 64

list-max-ziplist-entries 512

list-max-ziplist-value 64

set-max-intset-entries 512

zset-max-ziplist-entries 128

zset-max-ziplist-value 64

hll-sparse-max-bytes 3000

activerehashing yes

client-output-buffer-limit normal 0 0 0

client-output-buffer-limit slave 256mb 64mb 60

client-output-buffer-limit pubsub 32mb 8mb 60

hz 10

aof-rewrite-incremental-fsync yes

启动

# redis-server /etc/redis/redis.conf

查看

# redis-cli -h Mrds

Mrds:6379> info

# Server

redis_version:2.8.19    ###redis版本号

redis_git_sha1:00000000  ###git SHA1

redis_git_dirty:0  ###git dirty flag

redis_build_id:78796c63e58b72dc

redis_mode:standalone  ###redis运行模式

os:Linux 2.6.32-431.el6.x86_64 x86_64  ###os版本号

arch_bits:64  ###64位架构

multiplexing_api:epoll  ###调用epoll算法

gcc_version:4.4.7  ###gcc版本号

process_id:25899  ###服务器进程PID

run_id:eae356ac1098c13b68f2b00fd7e1c9f93b1c6a2c  ###Redis的随机标识符(用于sentinel和集群)

tcp_port:6379  ###Redis监听的端口号

uptime_in_seconds:6419 ###Redis运行时长(s为单位)

uptime_in_days:0  ###Redis运行时长(天为单位)

hz:10

lru_clock:10737922  ###以分钟为单位的自增时钟,用于LRU管理

config_file:/etc/redis/redis.conf  ###redis配置文件

# Clients

connected_clients:1  ###已连接客户端的数量（不包括通过从属服务器连接的客户端）

client_longest_output_list:0  ###当前连接的客户端中最长的输出列表

client_biggest_input_buf:0  ###当前连接的客户端中最大的输出缓存

blocked_clients:0  ###正在等待阻塞命令（BLPOP、BRPOP、BRPOPLPUSH）的客户端的数量 需监控

# Memory

used_memory:2281560  ###由 Redis 分配器分配的内存总量，以字节（byte）为单位

used_memory_human:2.18M  ###以更友好的格式输出redis占用的内存

used_memory_rss:2699264  ###从操作系统的角度，返回 Redis 已分配的内存总量（俗称常驻集大小）。这个值和 top 、 ps 等命令的输出一致

used_memory_peak:22141272  ### Redis 的内存消耗峰值（以字节为单位）

used_memory_peak_human:21.12M  ###以更友好的格式输出redis峰值内存占用

used_memory_lua:35840  ###LUA引擎所使用的内存大小

mem_fragmentation_ratio:1.18  ###used_memory_rss 和 used_memory 之间的比率

mem_allocator:jemalloc-3.6.0

###在理想情况下， used_memory_rss 的值应该只比 used_memory 稍微高一点儿。当 rss > used ，且两者的值相差较大时，表示存在（内部或外部的）内存碎片。内存碎片的比率可以通过 mem_fragmentation_ratio 的值看出。

当 used > rss 时，表示 Redis 的部分内存被操作系统换出到交换空间了，在这种情况下，操作可能会产生明显的延迟。

# Persistence

loading:0  ###记录服务器是否正在载入持久化文件

rdb_changes_since_last_save:0  ###距离最近一次成功创建持久化文件之后，经过了多少秒

rdb_bgsave_in_progress:0  ###记录了服务器是否正在创建 RDB 文件

rdb_last_save_time:1420023749  ###最近一次成功创建 RDB 文件的 UNIX 时间戳

rdb_last_bgsave_status:ok  ###最近一次创建 RDB 文件的结果是成功还是失败

rdb_last_bgsave_time_sec:0  ###最近一次创建 RDB 文件耗费的秒数

rdb_current_bgsave_time_sec:-1  ###如果服务器正在创建 RDB 文件，那么这个域记录的就是当前的创建操作已经耗费的秒数

aof_enabled:1  ###AOF 是否处于打开状态

aof_rewrite_in_progress:0  ###服务器是否正在创建 AOF 文件

aof_rewrite_scheduled:0  ###RDB 文件创建完毕之后，是否需要执行预约的 AOF 重写操作

aof_last_rewrite_time_sec:-1  ###最近一次创建 AOF 文件耗费的时长

aof_current_rewrite_time_sec:-1  ###如果服务器正在创建 AOF 文件，那么这个域记录的就是当前的创建操作已经耗费的秒数

aof_last_bgrewrite_status:ok  ###最近一次创建 AOF 文件的结果是成功还是失败

aof_last_write_status:ok

aof_current_size:176265  ###AOF 文件目前的大小

aof_base_size:176265  ###服务器启动时或者 AOF 重写最近一次执行之后，AOF 文件的大小

aof_pending_rewrite:0  ###是否有 AOF 重写操作在等待 RDB 文件创建完毕之后执行

aof_buffer_length:0  ###AOF 缓冲区的大小

aof_rewrite_buffer_length:0  ###AOF 重写缓冲区的大小

aof_pending_bio_fsync:0  ###后台 I/O 队列里面，等待执行的 fsync 调用数量

aof_delayed_fsync:0    ###被延迟的 fsync 调用数量

# Stats

total_connections_received:8466  ###服务器已接受的连接请求数量

total_commands_processed:900668  ###服务器已执行的命令数量

instantaneous_ops_per_sec:1  ###服务器每秒钟执行的命令数量

total_net_input_bytes:82724170

total_net_output_bytes:39509080

instantaneous_input_kbps:0.07

instantaneous_output_kbps:0.02

rejected_connections:0  ###因为最大客户端数量限制而被拒绝的连接请求数量

sync_full:2

sync_partial_ok:0

sync_partial_err:0

expired_keys:0  ###因为过期而被自动删除的数据库键数量

evicted_keys:0  ###因为最大内存容量限制而被驱逐（evict）的键数量。

keyspace_hits:0  ###查找数据库键成功的次数。

keyspace_misses:500000  ###查找数据库键失败的次数。

pubsub_channels:0  ###目前被订阅的频道数量

pubsub_patterns:0  ###目前被订阅的模式数量

latest_fork_usec:402  ###最近一次 fork() 操作耗费的毫秒数

# Replication

role:master  ###如果当前服务器没有在复制任何其他服务器，那么这个域的值就是 master ；否则的话，这个域的值就是 slave 。注意，在创建复制链的时候，一个从服务器也可能是另一个服务器的主服务器

connected_slaves:2  ###2个slaves

slave0:ip=192.168.65.130,port=6379,state=online,offset=1639,lag=1

slave1:ip=192.168.65.129,port=6379,state=online,offset=1639,lag=0

master_repl_offset:1639

repl_backlog_active:1

repl_backlog_size:1048576

repl_backlog_first_byte_offset:2

repl_backlog_histlen:1638

# CPU

used_cpu_sys:41.87  ###Redis 服务器耗费的系统 CPU

used_cpu_user:17.82  ###Redis 服务器耗费的用户 CPU

used_cpu_sys_children:0.01  ###后台进程耗费的系统 CPU

used_cpu_user_children:0.01  ###后台进程耗费的用户 CPU

# Keyspace

db0:keys=3101,expires=0,avg_ttl=0  ###keyspace 部分记录了数据库相关的统计信息，比如数据库的键数量、数据库已经被删除的过期键数量等。对于每个数据库，这个部分都会添加一行以下格式的信息

Sentinel(哨兵)配置

vi sentinel.conf

启动前:

port 26379

dir "/var/lib/redis/tmp"  ###定义目录存放

sentinel auth-passmymaster vhreal   ##密码

sentinel monitor mymaster 192.168.65.128 6379 2    ###监控mymaster(可自定义-但只能包括A-z 0-9和”._-”)

sentinel down-after-milliseconds mymaster 30000  ###mymaster多久不响应认为SDOWN

sentinel parallel-syncs mymaster 1  ###指定最大同时同步新maser配置的salve数量

sentinel failover-timeout mymaster 180000  ###2次failover切换时间

启动后(redis.con配置文件完全由sentinel控制,请不要再随意手动改动):

port 26379

dir "/var/lib/redis/tmp"

sentinel monitor mymaster 192.168.65.128 6379 2

sentinel config-epoch mymaster 18  ###确认mymater SDOWN时长

sentinel leader-epoch mymaster 18  ###同时一时间最多18个slave可同时更新配置,建议数字不要太大,以免影响正常对外提供服务

sentinel known-slave mymaster 192.168.65.129 6379  ###已知的slave

sentinel known-slave mymaster 192.168.65.130 6379  ###已知的slave

sentinel known-sentinel mymaster 192.168.65.130 26379 be964e6330ee1eaa9a6b5a97417e866448c0ae40    ###已知slave的唯一id

sentinel known-sentinel mymaster 192.168.65.129 26379 3e468037d5dda0bbd86adc3e47b29c04f2afe9e6  ###已知slave的唯一id

sentinel current-epoch 18  ####当前可同时同步的salve数最大同步阀值

开启sentinel

开启sentinel后会后redis.conf会由sentinel进行管理

# redis-server /etc/redis/sentinel.conf --sentinel &> /var/log/redis/sentinel.log &

常用命令

redis-cli

redis-server

auth

set key value

get key

Q&A

Redis主从配置异常解决：Error condition on socket for SYNC: Connection refused

Redis主从集群时，从服务器上的redis日志报错：

32677:S08Feb16:14:38.947*ConnectingtoMASTER172.168.10.70:637932677:S08Feb16:14:38.948*MASTER<->SLAVEsyncstarted32677:S08Feb16:14:38.948#ErrorconditiononsocketforSYNC:Connectionrefused32677:S08Feb16:14:39.950*ConnectingtoMASTER172.168.10.70:637932677:S08Feb16:14:39.950*MASTER<->SLAVEsyncstarted32677:S08Feb16:14:39.950#ErrorconditiononsocketforSYNC:Connectionrefused32677:S08Feb16:14:40.952*ConnectingtoMASTER172.168.10.70:637932677:S08Feb16:14:40.952*MASTER<->SLAVEsyncstarted32677:S08Feb16:14:40.953#ErrorconditiononsocketforSYNC:Connectionrefused

解决方案：

在redis主服务器上的redis.conf中修改bind字段，将

bind 127.0.0.1

修改为

bind 0.0.0.0

又或者直接注释掉bind字段

# bind 127.0.0.1

原因：

如果redis主服务器绑定了127.0.0.1，那么跨服务器IP的访问就会失败，从服务器用IP和端口访问主的时候，主服务器发现本机6379端口绑在了127.0.0.1上，也就是只能本机才能访问，外部请求会被过滤，这是Linux的网络安全策略管理的。如果bind的IP地址是172.168.10.70，那么本机通过localhost和127.0.0.1、或者直接输入命令redis-cli登录本机redis也就会失败了。只能加上本机ip才能访问到。

所以，在研发、测试环境可以考虑bind 0.0.0.0，线上生产环境建议绑定IP地址。

（DENIED Redis is running in protected mode）

Java程序中使用JedisSentinelPool建立redis连接池



Set sentinels = new HashSet();

sentinels.add("172.17.16.7:26379");

sentinels.add("172.17.16.8:26379");

sentinels.add("172.17.16.9:26379");

JedisSentinelPool sentinelPool = new JedisSentinelPool("mymaster", sentinels, "123456");

报错：

DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to    clients.......

使用redis-cli -h 127.0.0.1 -p 26379连接sentinel可以执行命令，而使用redis-cli -h 172.17.16.7 -p 26379连接sentinel执行命令则会报同上的错误。

查遍了网上没有找到相关的问题分析和解决的案例，所以只能自己猜测和排查，初步怀疑是通过172.17.16.7访问sentinel时受限。

由于此错误和redis server的protect-mode为yes的访问错误颇为相似，官方在redis.conf的注释说明中有protected-mode这一配置项，但sentinel.conf的注释中完全没有提到过该配置项，我很疑惑，但还是尝试在sentinel.conf中加入

protected-mode no

之后保存并重新启动sentinel，之后用Java程序建立连接池，没有报错，且可以对redis server进行数据处理，问题解决。