redis总结2-Redis六种数据类型命令总结(附命令实例)
redis总结3-持久化rdb,aof,运维命令,Sentinel监控
一.简介
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与master通信,如果某次因为master IO操作频繁,导致超时,此时,认为master失效,很武断.
解决: sentnel允许多个实例看守1个master, 当N台(N可设置)sentinel都认为master失效,才正式失效.
扫一扫
1228
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
