redis总结3-持久化rdb,aof,运维命令,Sentinel监控
来源:互联网 发布:ibm软件 编辑:程序博客网 时间:2024/06/05 05:50
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 常用命令
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> time1) "1504193711" //第一个字符串是当前时间(以 UNIX 时间戳格式表示)2) "215301" //而第二个字符串是当前这一秒钟已经逝去的微秒数。127.0.0.1:6379> 127.0.0.1:6379> dbsize(integer) 4127.0.0.1:6379> lastsave(integer) 1503825557127.0.0.1:6379> BGREWRITEAOFBackground append only file rewriting started127.0.0.1:6379> BGSAVEBackground saving started127.0.0.1:6379> 127.0.0.1:6379> flushdbOK127.0.0.1:6379> flushallOK127.0.0.1:6379> 127.0.0.1:6379> shutdownnot connected> info [section][root@bogon bin]# ./redis-cli Could not connect to Redis at 127.0.0.1:6379: Connection refusedCould not connect to Redis at 127.0.0.1:6379: Connection refusednot connected> [root@bogon bin]# ./redis-cli 127.0.0.1:6379> info default //返回默认选择的信息//注意info all 会多列出Commandstats,而info不会列出Commandstats信息127.0.0.1:6379> info all127.0.0.1:6379> info# Serverredis_version:4.0.1 // Redis 服务器版本redis_git_sha1:00000000redis_git_dirty:0redis_build_id:4eb7abcd4e2d679redis_mode:standaloneos: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-builtingcc_version:4.4.7 //编译 Redis 时所使用的 GCC 版本process_id:8723 //服务器进程的 PIDrun_id:4679c264bd6214e740403ead64136ac725f49912 // Redis 服务器的随机标识符(用于 Sentinel 和集群)tcp_port:6379 //TCP/IP 监听端口uptime_in_seconds:390661 //自 Redis 服务器启动以来,经过的秒数uptime_in_days:4 //自Redis 服务器启动以来,经过的天数hz:10lru_clock:11021702 //以分钟为单位进行自增的时钟,用于 LRU 管理executable:/usr/local/redis/bin/redis-serverconfig_file:/usr/local/redis/conf/6379.conf# Clientsconnected_clients:1 //已连接客户端的数量(不包括通过从属服务器连接的客户端)client_longest_output_list:0 // 当前连接的客户端当中,最长的输出列表client_biggest_input_buf:0 //当前连接的客户端当中,最大输入缓存blocked_clients:0 //正在等待阻塞命令(BLPOP、BRPOP、BRPOPLPUSH)的客户端的数量# Memoryused_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:815246used_memory_startup:765616used_memory_dataset:12578used_memory_dataset_perc:20.22%total_system_memory:1036374016total_system_memory_human:988.36Mused_memory_lua:37888 //Lua 引擎所使用的内存大小(以字节为单位)used_memory_lua_human:37.00K//人类可读luamaxmemory:0maxmemory_human:0Bmaxmemory_policy:noevictionmem_fragmentation_ratio:7.08 //used_memory_rss 和 used_memory 之间的比率mem_allocator:jemalloc-4.0.3// 在编译时指定的, Redis 所使用的内存分配器。可以是 libc 、 jemalloc 或者 tcmalloc 。active_defrag_running:0lazyfree_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:0rdb_changes_since_last_save:5 //上次rdb之后修改了几条信息rdb_bgsave_in_progress:0rdb_last_save_time:1504193912 //上次rdb的时间rdb_last_bgsave_status:okrdb_last_bgsave_time_sec:0rdb_current_bgsave_time_sec:-1rdb_last_cow_size:4370432aof_enabled:0aof_rewrite_in_progress:0aof_rewrite_scheduled:0aof_last_rewrite_time_sec:0aof_current_rewrite_time_sec:-1aof_last_bgrewrite_status:okaof_last_write_status:okaof_last_cow_size:4300800# Stats//一般统计信息total_connections_received:10total_commands_processed:76instantaneous_ops_per_sec:0total_net_input_bytes:2593total_net_output_bytes:103047instantaneous_input_kbps:0.01instantaneous_output_kbps:6.20rejected_connections:0sync_full:0sync_partial_ok:0sync_partial_err:0expired_keys:0evicted_keys:0keyspace_hits:16keyspace_misses:5pubsub_channels:0pubsub_patterns:0latest_fork_usec:1589 //上次导出rdb快照,持久化花费微秒migrate_cached_sockets:0slave_expires_tracked_keys:0active_defrag_hits:0active_defrag_misses:0active_defrag_key_hits:0active_defrag_key_misses:0# Replication // 主/从复制信息role:masterconnected_slaves:0master_replid:81d07a765e5767c47c10c21014e88f9d01d7dbfemaster_replid2:0000000000000000000000000000000000000000master_repl_offset:0second_repl_offset:-1repl_backlog_active:0repl_backlog_size:1048576repl_backlog_first_byte_offset:0repl_backlog_histlen:0# CPU // CPU 计算量统计信息used_cpu_sys:11.99used_cpu_user:5.32used_cpu_sys_children:0.21used_cpu_user_children:0.02# Commandstatscmdstat_set:calls=1,usec=20,usec_per_call=20.00cmdstat_keys:calls=1,usec=15,usec_per_call=15.00cmdstat_auth:calls=4,usec=12,usec_per_call=3.00cmdstat_psync:calls=2,usec=1583,usec_per_call=791.50cmdstat_replconf:calls=1903323,usec=3283980,usec_per_call=1.73cmdstat_info:calls=5,usec=17552,usec_per_call=3510.40cmdstat_config:calls=1,usec=42,usec_per_call=42.00cmdstat_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-than1) "slowlog-log-slower-than"2) "10000"127.0.0.1:6379> config set slowlog-log-slower-than 15000OK127.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-len1) "slowlog-max-len"2) "128"127.0.0.1:6379> config set slowlog-max-len 256OK127.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 timeout1) "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 #Replicationrole:masterconnected 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变为不是slave127.0.0.1:6379>slaveof no oneOK##2.1查看slave的读功能127.0.0.1:6379>config get slave-read-only1) "slave-read-only"2) "yes"##2.2修改readonly为no127.0.0.1:6379>config set slave-read-only noOK##2.3查看确认127.0.0.1:6379>config get slave-read-only1) "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台的来指向新的mastersentinel 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 越小越优先,默认100slave-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集群)
- redis总结3-持久化rdb,aof,运维命令,Sentinel监控
- Redis---持久化 ( RDB AOF )
- Redis 持久化 RDB AOF
- Redis持久化--RDB+AOF
- redis--RDB持久化--AOF持久化
- redis 持久化机制AOF/RDB详解
- redis持久化RDB和AOF
- REDIS持久化RDB和AOF
- redis持久化RDB和AOF
- Redis持久化-RDB与AOF
- redis持久化RDB和AOF
- redis持久化RDB和AOF
- redis持久化RDB和AOF
- redis持久化RDB和AOF
- Redis 持久化数据方式 RDB AOF
- redis----RDB和AOF持久化对比
- redis持久化RDB和AOF
- redis 持久化rdb aof 简介
- BZOJ 4636 蒟蒻的数列
- Java中方法的重载和重写的区别
- Spring AOP(3)
- 巴铁
- ANR
- redis总结3-持久化rdb,aof,运维命令,Sentinel监控
- Hive数据去重、多变一与一变多等实现
- Java中对象的深复制(深克隆)和浅复制(浅克隆)介绍
- 深度学习基础(三)--SVM
- jQuery--4.文档处理
- Global Jobcoin——世界上区块链上的第一个就业平台
- 计算几何小知识点
- maven总结
- java 从字符串中提取数字