redis总结3-持久化rdb,aof,运维命令,Sentinel监控

redis总结1-Redis简介、安装、集群

redis总结2-Redis六种数据类型命令总结(附命令实例)

redis总结3-持久化rdb,aof,运维命令,Sentinel监控

redis总结4-KEY设计技巧,常见问题

一.简介

1.1 NoSQL简介

1.1.2 NoSQL特点

1.1.3 NoSQL适用场景

1.2 Redis简介

1.2.1 简介

1.2.2 Redis具体适用场合

1.2.3 redis和memcached相比

1.2.4 redis,mysql,mongodb对比

二.安装

2.1 单机安装

2.2 设值环境变量及服务

2.3 安装后的目录结构

2.4 配置详解

2.5 集群

三 Redis命令

3.1 连接命令

3.1 Redis通用命令

3.2 Redis字符串操作

3.4 set集合相关命令

3.5 order set 有序集合

3.6 Hash哈希

四 Redis的持久化-RDB,AOF

4.1 持久化

持久化: 即把数据存储于断电后不会丢失的设备中,通常是硬盘.

常见的持久化方式:

主从:通过从服务器保存和持久化,如mongoDB的replication sets配置

日志记录:操作生成相关日志,并通过日志来恢复数据;

日志本身:couchDB对于数据内容,不修改,只追加,则文件本身就是日志,不会丢失数据.

4.2 redis持久化

Redis的持久化有2种方式:

1: 快照RDB (Redis DataBase)

2: 日志AOF (Append-only file)

Redis在早起的版本还存在虚拟内存的方法，现在已经被废弃

4.2.1 快照RDB

RDB 是在某个时间点将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复。(内存数据映像到硬盘上,持久化方法也通常叫做snapshots) .

4.2.1.1 RDB工作原理:

snapshot触发的时机，是有“间隔时间”和“变更次数”共同决定，同时符合时间和次数2个条件(每隔N分钟或N次写操作后)才会触发snapshot,否则“变更次数”会被继续累加到下一个“间隔时间”上。snapshot过程中并不阻塞客户端请求。从内存dump数据形成rdb文件(压缩与否),snapshot首先将数据写入临时文件，当成功结束后，将临时文件重名为dump.rdb,并放在备份目录。

4.2.1.2 优缺点

优点：使用单独子进程来进行持久化，主进程不会进行任何IO操作，保证了redis的高性能.

缺点：RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候.(如:在2个保存点之间,断电,将会丢失1-N分钟的数据)

4.2.1.3 RDB快照的配置选项(conf中)

//可以查看redis总结1中的conf配置

##snapshot触发的时机，save <seconds> <changes>
save 900 1      // 900内,有1条写入,则产生快照
save 300 1000   // 如果300秒内有1000次写入,则产生快照
save 60 10000  // 如果60秒内有10000次写入,则产生快照
(这3个选项都屏蔽,则rdb禁用)

dbfilename dump.rdb  //导出来的rdb文件名
dir ./  //rdb的放置路径
rdbcompression yes    // 导出的rdb文件是否压缩,默认为“yes”，压缩往往意味着“额外的cpu消耗”，同时也意味这较小的文件尺寸以及较短的网络传输时间

//后台备份进程出错时,主进程停不停止写入;当snapshot时出现错误无法继续时，是否阻塞客户端“变更操作”，“错误”可能因为磁盘已满/磁盘故障/OS级别异常等
stop-writes-on-bgsave-error yes
Rdbchecksum   yes //  导入rbd恢复时数据时,要不要检验rdb的完整性

4.2.1.4 RDB客户端命令:

//前台进行存储，
./redis-cli -h ip -p port save
./redis-cli  save   //本机操作
//后台进行存储，
./redis-cli -h ip -p port bgsave
./redis-cli  bgsave //本机操作

//由于redis是用一个主线程来处理所有client的请求，这种方式会阻塞所有client请求。所以不推荐使用。另一点需要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步脏数据。如果数据量大的话，而且写操作比较多，必然会引起大量的磁盘io操作，可能会严重影响性能。

出于对持久化的更精细要求,redis增添了aof方式 append only file

4.2.2 AOF

4.2.2.1 AOF工作原理

    Append-only file: 将“操作 + 数据”以格式化指令的方式追加到操作日志文件的尾部，在append操作返回后

(已经写入到文件或者即将写入)，才进行实际的数据变更，“日志文件”保存了历史所有的操作过程；当server需要数据恢复时，可以直接replay此日志文件，即可还原所有的操作过程。AOF相对可靠，它和MySQL中bin.log、apache.log、zookeeper中txn-log简直异曲同工。AOF文件内容是字符串，非常容易阅读和解析。

  我们可以简单的认为AOF就是日志文件，此文件只会记录“变更操作”(例如：set/del等)，如果server中持续的大量变更操作，将会导致AOF文件非常的庞大，意味着server失效后，数据恢复的过程将会很长；事实上，一条数据经过多次变更，将会产生多条AOF记录，其实只要保存当前的状态，历史的操作记录是可以抛弃的；因为AOF持久化模式还伴生了“AOF rewrite”。

    AOF的特性决定了它相对比较安全，如果你期望数据更少的丢失，那么可以采用AOF模式。如果AOF文件正在被写入时突然server失效，有可能导致文件的最后一次记录是不完整，你可以通过手工或者程序的方式去检测并修正不完整的记录，以便通过aof文件恢复能够正常；同时需要提醒，如果你的redis持久化手段中有aof，那么在server故障失效后再次启动前，需要检测aof文件的完整性。

4.2.2.2 AOF优缺点

优点：可以保持更高的数据完整性，如果设置追加file的时间是1s，如果redis发生故障，最多会丢失1s的数据；且如果日志写入不完整支持redis-check-aof来进行日志修复；AOF文件没被rewrite之前（文件过大时会对命令进行合并重写），可以删除其中的某些命令（比如误操作的flushall）。

缺点：AOF文件比RDB文件大，且恢复速度慢。

4.2.2.3 AOF的配置选项(conf中)

##是否打开 aof日志功能;##只有在“yes”下，aof重写/文件同步等特性才会生效
appendonly no
##指定aof文件名称
appendfilename appendonly.aof

##同步策略-三种
##指定aof操作中文件同步策略，有三个合法值：always everysec no,默认为everysec
##同步策略1-每1个命令,都立即同步到aof. 安全,速度慢
#每一条aof记录都立即同步到文件，这是最安全的方式，也以为更多的磁盘操作和阻塞延迟，是IO开支较大。
appendfsync always

##同步策略2-每秒同步一次，性能和安全都比较中庸的方式，也是redis推荐的方式。如果遇到物理服务器故障，有可能导致最近一秒内aof记录丢失(可能为部分丢失)。
# 折衷方案,每秒写1次
appendfsync everysec

##同步测了3-redis并不直接调用文件同步，而是交给操作系统来处理，操作系统可以根据buffer填充情况/通道空闲时间等择机触发同步；这是一种普通的文件操作方式。性能较好，在物理服务器故障时，数据丢失量会因OS配置有关。
# 写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof. 同步频率低,速度快,
appendfsync no

##在aof-rewrite期间，appendfsync是否暂缓文件同步，"no"表示“不暂缓”，“yes”表示“暂缓”，默认为“no”
no-appendfsync-on-rewrite  yes:

##aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite，默认“64mb”，建议“512mb”(aof文件,至少超过64M时,重写)
auto-aof-rewrite-min-size 64mb

##相对于“上一次”rewrite，本次rewrite触发时aof文件应该增长的百分比。
#aof文件大小比起上次重写时的大小,增长率100%时,重写
##每一次rewrite之后，redis都会记录下此时“新aof”文件的大小(例如A)，那么当aof文件增长到A*(1 + p)之后
##触发下一次rewrite，每一次aof记录的添加，都会检测当前aof文件的尺寸。
auto-aof-rewrite-percentage 100

4.2.2.5 AOF rewrite

AOF rewrite 操作就是“压缩”AOF文件的过程，当然redis并没有采用“基于原aof文件”来重写的方式，而是采取了类似snapshot的方式：基于copy-on-write，全量遍历内存中数据，然后逐个序列到aof文件中。因此AOF rewrite能够正确反应当前内存数据的状态，这正是我们所需要的；rewrite过程中，对于新的变更操作将仍然被写入到原AOF文件中，同时这些新的变更操作也会被redis收集起来(buffer，copy-on-write方式下，最极端的可能是所有的key都在此期间被修改，将会耗费2倍内存)，当内存数据被全部写入到新的aof文件之后，收集的新的变更操作也将会一并追加到新的aof文件中，此后将会重命名新的aof文件为appendonly.aof,此后所有的操作都将被写入新的aof文件。如果在rewrite过程中，出现故障，将不会影响原AOF文件的正常工作，只有当rewrite完成之后才会切换文件，因为rewrite过程是比较可靠的。

  触发rewrite的时机可以通过conf配置文件来声明，同时redis中可以通过bgrewriteaof指令人工干预。

redis-cli -h ip -p port bgrewriteaof

  因为rewrite操作/aof记录同步/snapshot都消耗磁盘IO，redis采取了“schedule”策略：无论是“人工干预”还是系统触发，snapshot和rewrite需要逐个被执行。

AOF rewrite过程并不阻塞客户端请求。系统会开启一个子进程来完成。

4.2.3 总结及常见问题

4.2.3.1 优缺点总结

AOF和RDB各有优缺点，这是有它们各自的特点所决定：

1) AOF更加安全，可以将数据更加及时的同步到文件中，但是AOF需要较多的磁盘IO开支，AOF文件尺寸较大，文件内容恢复数度相对较慢。

2) RDB，安全性较差，它是“正常时期”数据备份以及master-slave数据同步的最佳手段，文件尺寸较小，恢复数度较快。

4.2.3.2 使用建议

  a). 可以通过配置文件来指定它们中的一种，或者同时使用它们(不建议同时使用)，或者全部禁用，在架构良好的环境中，master通常使用AOF，slave使用rdb，主要原因是master需要首先确保数据完整性，它作为数据备份的第一选择slave提供只读服务(目前slave只能提供读取服务)，它的主要目的就是快速响应客户端read请求；

  b). 但是如果你的redis运行在网络稳定性差/物理环境糟糕情况下，建议你master和slave均采取AOF，这个在master和slave角色切换时，可以减少“人工数据备份”/“人工引导数据恢复”的时间成本；

  c).如果你的环境一切非常良好，且服务需要接收密集性的write操作，那么建议master采取rdb，而slave采用AOF。

4.2.3.2 常见问题

注: 在dump RDB,AOF如果停止同步,会不会丢失?

答: 不会,所有的操作缓存在内存的队列里, dump完成后,统一操作.

注: AOF重写是指什么?

答: AOF重写是指把内存中的数据,逆化成命令,写入到.aof日志里.

以解决 aof日志过大的问题.

问: 如果RDB文件,和AOF文件都存在,优先用谁来恢复数据?

答: AOF

问: 2种是否可以同时用?

答: 可以,而且推荐这么做

问: 恢复时RDB和AOF哪个恢复的快

答: RDB快,因为其是数据的内存映射,直接载入到内存,而AOF是命令,需要逐条执行

五.redis运维命令

5.1 常用命令

命令	说明	备注
time	服务器端命令	显示服务器时间:第一行时间戳(秒),第二行是该秒经过了的微秒数
dbsize	当前数据库的key的数量
LASTSAVE	上次保存时间
BGREWRITEAOF	后台进程重写AOF
BGSAVE	后台保存rdb快照
SAVE	保存rdb快照
Flushall	清空所有库所有键
Flushdb	清空当前库所有键
Showdown	[save/nosave]
Info [Replication/CPU/Memory..]	查看redis服务器的信息
Config get 配置项	获取配置项	如:slowlog-log-slower-than
Config set 配置项 值	设置配置项	(特殊的选项,不允许用此命令设置,如slave-of, 需要用单独的slaveof命令来设置)
Slaveof master-Host port	把当前实例设为master的slave
SLOWLOG	显示服务器信息
MONITOR	打开控制台
SYNC	主从同步
CLIENT LIST	客户端列表
CLIENT KILL	关闭某个客户端
CLIENT SETNAME	为客户端设置名字
CLIENT GETNAME	获取客户端名字

5.2 注意事项及重要参数说明

5.2.1 如果不小心运行了flushall, 怎么办?

立即 shutdown nosave ,关闭服务器, 然后 手工编辑aof文件, 去掉文件中的 “flushall ”相关行, 然后开启服务器,就可以导入回原来数据. 如果,flushall之后,系统恰好bgrewriteaof了,那么aof就清空了,数据丢失.

5.2.2 怎么显示慢查询,多慢才叫慢?

答: Slowlog 显示慢查询,慢查询由slowlog-log-slower-than 10000 ,来指定,(单位是微秒)

5.2.3 服务器储存多少条慢查询的记录?

答: 由 slowlog-max-len 128 ,来做限制

5.2.4 通过命令设置的参数服务重启后还会生效吗?

答:不会,如果配置参数在conf中存在,然后通过config set 又重新设置了.如果redis服务重启,会使用conf配置文件中的配置. 不会使用config set的参数.

5.2.5 运行时更改master-slave

修改一台slave(设为A)为new master

1) 命令该服务不做其他redis服务的slave

命令: slaveof no one

2) 修改其readonly为yes

其他的slave再指向new master A

1) 命令该服务为new master A的slave

命令格式 slaveof IP port

5.2.6 Redis运维时需要注意的参数

1: 内存

Memory

used_memory:859192 数据结构的空间

used_memory_rss:7634944 实占空间

2: 主从复制

Replication

role:slave

master_host:192.168.1.128

master_port:6379

master_link_status:up

3:持久化

Persistence

rdb_changes_since_last_save:0

rdb_last_save_time:1375224063

4: fork耗时

Status

latest_fork_usec:936 上次导出rdb快照,持久化花费微秒

注意: 如果某实例有10G内容,导出需要2分钟,

每分钟写入10000次,导致不断的rdb导出,磁盘始处于高IO状态.

5: 慢日志

config get/set slowlog-log-slower-than

CONFIG get/SET slowlog-max-len

slowlog get N 获取慢日志

5.3 命令总结:

[root@bogon bin]# ./redis-cli
127.0.0.1:6379> time
1) "1504193711" //第一个字符串是当前时间(以 UNIX 时间戳格式表示)
2) "215301"     //而第二个字符串是当前这一秒钟已经逝去的微秒数。
127.0.0.1:6379>
127.0.0.1:6379> dbsize
(integer) 4
127.0.0.1:6379> lastsave
(integer) 1503825557
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started
127.0.0.1:6379> BGSAVE
Background saving started
127.0.0.1:6379>
127.0.0.1:6379> flushdb
OK
127.0.0.1:6379> flushall
OK
127.0.0.1:6379>
127.0.0.1:6379> shutdown
not connected> info [section]
[root@bogon bin]# ./redis-cli
Could not connect to Redis at 127.0.0.1:6379: Connection refused
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected>

[root@bogon bin]# ./redis-cli
127.0.0.1:6379> info default //返回默认选择的信息
//注意info all 会多列出Commandstats,而info不会列出Commandstats信息
127.0.0.1:6379> info all
127.0.0.1:6379> info
# Server
redis_version:4.0.1 // Redis 服务器版本
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:4eb7abcd4e2d679
redis_mode:standalone
os:Linux 2.6.32-642.3.1.el6.x86_64 x86_64   // Redis 服务器的宿主操作系统
arch_bits:64    // 架构（32 或 64 位）
multiplexing_api:epoll  // Redis 所使用的事件处理机制
atomicvar_api:sync-builtin
gcc_version:4.4.7   //编译 Redis 时所使用的 GCC 版本
process_id:8723 //服务器进程的 PID
run_id:4679c264bd6214e740403ead64136ac725f49912 // Redis 服务器的随机标识符（用于 Sentinel 和集群）
tcp_port:6379 //TCP/IP 监听端口
uptime_in_seconds:390661    //自 Redis 服务器启动以来，经过的秒数
uptime_in_days:4 //自Redis 服务器启动以来，经过的天数
hz:10
lru_clock:11021702  //以分钟为单位进行自增的时钟，用于 LRU 管理
executable:/usr/local/redis/bin/redis-server
config_file:/usr/local/redis/conf/6379.conf

# Clients
connected_clients:1 //已连接客户端的数量（不包括通过从属服务器连接的客户端）
client_longest_output_list:0    // 当前连接的客户端当中，最长的输出列表
client_biggest_input_buf:0  //当前连接的客户端当中，最大输入缓存
blocked_clients:0   //正在等待阻塞命令（BLPOP、BRPOP、BRPOPLPUSH）的客户端的数量

# Memory
used_memory:827824  //由Redis 分配器分配的内存总量，以字节（byte）为单位
used_memory_human:808.42K   //以人类可读的格式返回 Redis 分配的内存总量
used_memory_rss:5861376 //从操作系统的角度，返回 Redis 已分配的内存总量（俗称常驻集大小）。这个值和 top 、 ps 等命令的输出一致。
used_memory_rss_human:5.59M //人类刻度常驻内存大小
used_memory_peak:889912 //Redis 的内存消耗峰值（以字节为单位）
used_memory_peak_human:869.05K //人类可读峰值
used_memory_peak_perc:93.02%
used_memory_overhead:815246
used_memory_startup:765616
used_memory_dataset:12578
used_memory_dataset_perc:20.22%
total_system_memory:1036374016
total_system_memory_human:988.36M
used_memory_lua:37888   //Lua 引擎所使用的内存大小（以字节为单位）
used_memory_lua_human:37.00K//人类可读lua
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
mem_fragmentation_ratio:7.08 //used_memory_rss 和 used_memory 之间的比率
mem_allocator:jemalloc-4.0.3// 在编译时指定的， Redis 所使用的内存分配器。可以是 libc 、 jemalloc 或者 tcmalloc 。
active_defrag_running:0
lazyfree_pending_objects:0

###
注意:
used_memory_rss 的值应该只比 used_memory 稍微高一点儿。
当 rss > used ，且两者的值相差较大时，表示存在（内部或外部的）内存碎片。
内存碎片的比率可以通过 mem_fragmentation_ratio 的值看出。
当 used > rss 时，表示 Redis 的部分内存被操作系统换出到交换空间了，在这种情况下，操作可能会产生明显的延迟。
当 Redis 释放内存时，分配器可能会，也可能不会，将内存返还给操作系统。
如果 Redis 释放了内存，却没有将内存返还给操作系统，那么 used_memory 的值可能和操作系统显示的 Redis 内存占用并不一致。
查看 used_memory_peak 的值可以验证这种情况是否发生。
###

# Persistence   //RDB 和 AOF 的相关信息
loading:0
rdb_changes_since_last_save:5   //上次rdb之后修改了几条信息
rdb_bgsave_in_progress:0
rdb_last_save_time:1504193912   //上次rdb的时间
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:4370432
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:0
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_last_cow_size:4300800

# Stats//一般统计信息
total_connections_received:10
total_commands_processed:76
instantaneous_ops_per_sec:0
total_net_input_bytes:2593
total_net_output_bytes:103047
instantaneous_input_kbps:0.01
instantaneous_output_kbps:6.20
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:0
evicted_keys:0
keyspace_hits:16
keyspace_misses:5
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:1589   //上次导出rdb快照,持久化花费微秒
migrate_cached_sockets:0
slave_expires_tracked_keys:0
active_defrag_hits:0
active_defrag_misses:0
active_defrag_key_hits:0
active_defrag_key_misses:0

# Replication   // 主/从复制信息
role:master
connected_slaves:0
master_replid:81d07a765e5767c47c10c21014e88f9d01d7dbfe
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

# CPU   // CPU 计算量统计信息
used_cpu_sys:11.99
used_cpu_user:5.32
used_cpu_sys_children:0.21
used_cpu_user_children:0.02

# Commandstats
cmdstat_set:calls=1,usec=20,usec_per_call=20.00
cmdstat_keys:calls=1,usec=15,usec_per_call=15.00
cmdstat_auth:calls=4,usec=12,usec_per_call=3.00
cmdstat_psync:calls=2,usec=1583,usec_per_call=791.50
cmdstat_replconf:calls=1903323,usec=3283980,usec_per_call=1.73
cmdstat_info:calls=5,usec=17552,usec_per_call=3510.40
cmdstat_config:calls=1,usec=42,usec_per_call=42.00
cmdstat_time:calls=1,usec=3,usec_per_call=3.00

# Cluster   //Redis 集群信息
cluster_enabled:0

# Keyspace  //数据库相关的统计信息
127.0.0.1:6379>

///查看设置值,配置参数值
127.0.0.1:6379> config get slowlog-log-slower-than
1) "slowlog-log-slower-than"
2) "10000"
127.0.0.1:6379> config set slowlog-log-slower-than 15000
OK
127.0.0.1:6379>
127.0.0.1:6379> config get slowlog
(empty list or set)
127.0.0.1:6379> slowlog get 10
(empty list or set)
127.0.0.1:6379> config get slowlog-max-len
1) "slowlog-max-len"
2) "128"
127.0.0.1:6379> config set slowlog-max-len 256
OK
127.0.0.1:6379> config get slowlog-max-len  //注,这样配置在conf中也存在
1) "slowlog-max-len"
2) "256"
127.0.0.1:6379> config get slowlog-max-len  //注,这样配置在conf中也存在
1) "slowlog-max-len"
2) "256"
127.0.0.1:6379> config get appendaof
(empty list or set)
127.0.0.1:6379> config get timeout
1) "timeout"
2) "0"

5.4 config配置列表

Config get 配置项|获取配置项|如:slowlog-log-slower-than

Config set 配置项 值 |设置配置项|(特殊的选项,不允许用此命令设置,如slave-of, 需要用单独的slaveof命令来设置)

配置也在conf中存在如下:

# There is no limit to this length. Just be aware that it will consume memory.
# You can reclaim memory used by the slow log with SLOWLOG RESET.
slowlog-max-len 128

注意: 命令设置的参数,在服务重启后重新以conf配置为准.

[root@bogon bin]# ./redis-cli
127.0.0.1:6379> config get *
1) "dbfilename"
2) "dump.rdb"
3) "requirepass"
4) ""
5) "masterauth"
6) ""
7) "cluster-announce-ip"
8) ""
9) "unixsocket"
10) ""
11) "logfile"
12) ""
13) "pidfile"
14) ""
15) "slave-announce-ip"
16) ""
17) "maxmemory"
18) "0"
19) "maxmemory-samples"
20) "5"
21) "timeout"
22) "0"
23) "active-defrag-threshold-lower"
24) "10"
25) "active-defrag-threshold-upper"
26) "100"
27) "active-defrag-ignore-bytes"
28) "104857600"
29) "active-defrag-cycle-min"
30) "25"
31) "active-defrag-cycle-max"
32) "75"
33) "auto-aof-rewrite-percentage"
34) "100"
35) "auto-aof-rewrite-min-size"
36) "67108864"
37) "hash-max-ziplist-entries"
38) "512"
39) "hash-max-ziplist-value"
40) "64"
41) "list-max-ziplist-size"
42) "-2"
43) "list-compress-depth"
44) "0"
45) "set-max-intset-entries"
46) "512"
47) "zset-max-ziplist-entries"
48) "128"
49) "zset-max-ziplist-value"
50) "64"
51) "hll-sparse-max-bytes"
52) "3000"
53) "lua-time-limit"
54) "5000"
55) "slowlog-log-slower-than"
56) "10000"
57) "latency-monitor-threshold"
58) "0"
59) "slowlog-max-len"
60) "128"
61) "port"
62) "6379"
63) "cluster-announce-port"
64) "0"
65) "cluster-announce-bus-port"
66) "0"
67) "tcp-backlog"
68) "511"
69) "databases"
70) "16"
71) "repl-ping-slave-period"
72) "10"
73) "repl-timeout"
74) "60"
75) "repl-backlog-size"
76) "1048576"
77) "repl-backlog-ttl"
78) "3600"
79) "maxclients"
80) "10000"
81) "watchdog-period"
82) "0"
83) "slave-priority"
84) "100"
85) "slave-announce-port"
86) "0"
87) "min-slaves-to-write"
88) "0"
89) "min-slaves-max-lag"
90) "10"
91) "hz"
92) "10"
93) "cluster-node-timeout"
94) "15000"
95) "cluster-migration-barrier"
96) "1"
97) "cluster-slave-validity-factor"
98) "10"
99) "repl-diskless-sync-delay"
100) "5"
101) "tcp-keepalive"
102) "300"
103) "cluster-require-full-coverage"
104) "yes"
105) "no-appendfsync-on-rewrite"
106) "no"
107) "slave-serve-stale-data"
108) "yes"
109) "slave-read-only"
110) "yes"
111) "stop-writes-on-bgsave-error"
112) "yes"
113) "daemonize"
114) "no"
115) "rdbcompression"
116) "yes"
117) "rdbchecksum"
118) "yes"
119) "activerehashing"
120) "yes"
121) "activedefrag"
122) "no"
123) "protected-mode"
124) "yes"
125) "repl-disable-tcp-nodelay"
126) "no"
127) "repl-diskless-sync"
128) "no"
129) "aof-rewrite-incremental-fsync"
130) "yes"
131) "aof-load-truncated"
132) "yes"
133) "aof-use-rdb-preamble"
134) "no"
135) "lazyfree-lazy-eviction"
136) "no"
137) "lazyfree-lazy-expire"
138) "no"
139) "lazyfree-lazy-server-del"
140) "no"
141) "slave-lazy-flush"
142) "no"
143) "maxmemory-policy"
144) "noeviction"
145) "loglevel"
146) "notice"
147) "supervised"
148) "no"
149) "appendfsync"
150) "everysec"
151) "syslog-facility"
152) "local0"
153) "appendonly"
154) "no"
155) "dir"
156) "/usr/local/redis/bin"
157) "save"
158) "3600 1 300 100 60 10000"
159) "client-output-buffer-limit"
160) "normal 0 0 0 slave 268435456 67108864 60 pubsub 33554432 8388608 60"
161) "unixsocketperm"
162) "0"
163) "slaveof"
164) ""
165) "notify-keyspace-events"
166) ""
167) "bind"
168) ""
127.0.0.1:6379>

//查看集群信息
127.0.0.1:6379> info replication
#Replication
role:master
connected slaves:0

六. 运维监控 sentinel

6.1 概述

  Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自懂切换。

6.1.1 功能特点

不时地监控redis是否按照预期良好地运行;

如果发现某个redis节点运行出现状况，能够通知另外一个进程(例如它的客户端);

能够进行自动切换。当一个master节点不可用时，能够选举出master的多个slave(如果有超过一个slave的话)中的一个来作为新的master,其它的slave节点会将它所追随的master的地址改为被提升为master的slave的新地址。

6.1.2 原理

sentinel不断与master通信,获取master的slave信息.

监听master与slave的状态

如果某slave失效,直接通知master去除该slave.

如果master失效,,是按照slave优先级(可配置), 选取1个slave做 new master

,把其他slave–> new master

注意:sentinel没有独立的进程,功能是在和redis-server中启动的.

6.2 操作步骤

原本6379master;6380和6381都是6379的slave.

然后6379down掉,然后6380变为master,6381变为6380的slave

6.2.1 手工操作步骤

#如何从slave变为maseter
#1.从slave变为不是slave
127.0.0.1:6379>slaveof no one
OK
##2.1查看slave的读功能
127.0.0.1:6379>config get slave-read-only
1) "slave-read-only"
2) "yes"
##2.2修改readonly为no
127.0.0.1:6379>config set slave-read-only no
OK
##2.3查看确认
127.0.0.1:6379>config get slave-read-only
1) "slave-read-only"
2) "no"
## 2其它slave再指向新的master(new master A)
## 在其它slave上执行
>slaveof localhsot 6380

这么操作,但是需要人操作,Sentinel实现的就是自动完成这个过程.

6.2.2 Sentinel操作配置

////sentinel在slave中来监控master的.所以可以有一个权限
////配置entinel can-failover def_master的值为yes

//监控配置,监视127.0.0.1的6379端口.
//2和下面的30秒配合使用,如果2次发现30秒还连接失效才算失效.
//注意:def_master是为127.0.0.1 6379起的别名,后面的配置都会用到该别名.
sentinel monitor def_master 127.0.0.1 6379 2

sentinel auth-pass def_master 012_345^678-90

##master被当前sentinel实例认定为“失效”的间隔时间
##如果当前sentinel与master直接的通讯中，在指定时间内没有响应或者响应错误代码，那么
##当前sentinel就认为master失效(SDOWN，“主观”失效)
##<mastername> <millseconds>
##默认为30秒
sentinel down-after-milliseconds def_master 30000

##当前sentinel实例是否允许实施“failover”(故障转移)
##no表示当前sentinel为“观察者”(只参与"投票".不参与实施failover)，
##全局中至少有一个为yes
sentinel can-failover def_master yes

#如果master挂了.然后会选择一个slave为master.如果其它(多个)slave同时指向新的master,
#那么新的master会负载过高,压力过大.该配置为执行同时几台slave来指向新的master,
#该配置为1,则为1台1台的来指向新的master
sentinel parallel-syncs mymas1ter 1

#做完这些事情的时间,如果不行,则执行脚本(脚本可以告警短信或邮件等通知).
sentinel failover-timeout mymaster 180000
##sentinel notification-script mymaster /var/redis/notify.sh

#多个slave时优先哪个为master挂了之后的心的maseter
#配置redis.conf(不是sentinel.conf配置)
#slave-priority 越小越优先,默认100
slave-priority 10

sentinel启动模式

##以哨兵模式启动redis服务.用sentinel.conf的哨兵配置
./bin/redis-server ./sentinel.conf --sentinel

配置解释:

port 26379 # 端口
sentinel monitor mymaster 127.0.0.1 6379 2 ,
给主机起的名字(不重即可), 当2个sentinel实例都认为master失效时,正式失效
sentinel down-after-milliseconds mymaster 30000  多少毫秒后连接不到master认为断开
sentinel can-failover mymaster yes #是否允许sentinel修改slave->master. 如为no,则只能监控,无权修改./
sentinel parallel-syncs mymaster 1 , 一次性修改几个slave指向新的new master.
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh ,# 在重新配置new master,new slave过程,可以触发的脚本

6.2.3 配置实例

sentinel.conf

疑问: sentinel与master通信,如果某次因为master IO操作频繁,导致超时,此时,认为master失效,很武断.

解决: sentnel允许多个实例看守1个master, 当N台(N可设置)sentinel都认为master失效,才正式失效.

参考文章(包含sentinel集群)