流程
dump.rdb也就是备份文件,redis可以根据这个文件来恢复数据。
备份配置
redis.conf可以对rdb文件进行配置
- dbfilename dump.rdb 文件名配置
- dir ./ 文件位置配置,默认为Redis启动时命令行所在的目录下
- stop-writes-on-bgsave-error yes 当Redis无法写入磁盘的话,直接关掉Redis的写操作。yes打开
- rdbcompression yes 对于存储到磁盘中的快照,可以设置是否进行压缩存储。如果是的话,redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话,可以设置为关闭此功能。推荐yes.
- rdbchecksum yes 在存储快照后,还可以让redis使用CRC64算法来进行数据校验,但是这样做会增加大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能,推荐yes.
最重要的命令 save
- save 900 1 # 3600秒(60分钟)内有1个key写入就保存(备份)
- save 300 10 # 300秒(5分钟)内有10个key写入就保存(备份)
- save 60 10000 # 60秒(1分钟)内有10000个key写入就保存(备份)可以同时打开多个。
而上面的数据问题也就是因为这个原因,比如 sava 20 10 在20秒内有10个key写入就保存,但当在18秒时宕机了,这时就会导致数据丢失。问题虽然有解决,但没完全解决。
rdb文件的使用
先通过config get dir 查询rdb文件的目录
将*.rdb的文件拷贝到别的地方
rdb的恢复
- 关闭Redis
- 先把备份的文件拷贝到工作目录下cp dump2.rdb dump.rdb
- 启动Redis, 备份数据会直接加载
优点:
适合大规模数据恢复节省空间对数据完整性和一致性要求不高恢复速度快
缺点:
在一定间隔时间做一次备份,所以如果redis意外down掉的话,就会丢失最后一次快照后的所有修改fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑,数据量大的时候,耗性能
AOF
以日志的形式来记录每个写操作(增量保存),将redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
配置
- aof默认不开启。
- 在redis.confg中配置文件名称,默认为appendonly.aofaof文件的保存路径,同rdb的路径一致
- 两种持久化同时开启,系统默认取aof的数据(数据不会存在丢失)
- aof的备份机制和性能虽然和rdb不同,但备份和操作同rdb一样
- 正常启动
- 修改默认的appendonly no,改为yes
- 将有数据的aof文件复制一份保存到对应目录(查看目录:config get dir)
- 恢复:重启redis然后重新加载
- 异常恢复
- 修改默认的appendonly no,改为yes
- 如遇到aof文件损坏,通过/usr/local/bin/redis-check-aof --fix appendonly.aof进行恢复
- 备份被写坏的aof文件
- 恢复:重启redis,然后重新加载
AOF同步频率(备份频率)设置
- appendfsync always始终同步,每次redis的写入都会立刻记入日志;性能较差但数据完整性比较好
- appendfsync everysec每秒同步,每秒计入日志一次,如果宕机,本秒的数据可能丢失
- appendfsync noredis不主动进行同步,把同步时机交给操作系统。
rewrite 压缩(重写)
AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制, 当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩, 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof (bg rewrite aof)
重写原理,如何实现重写
AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename,这里不懂看下面的流程),redis4.0版本后的重写,是指上就是把rdb 的快照,以二级制的形式附在新的aof头部,作为已有的历史数据,替换掉原来的流水账操作。也就是简写,栗如:set v1 v2 set b1 b2 会变成set v1 v2 b1 b2。
配置no-appendfsync-on-rewrite:如果no-appendfsync-on-rewrite=yes ,不写入aof文件只写入缓存,用户请求不会阻塞,但是在这段时间如果宕机会丢失这段时间的缓存数据。(降低数据安全性,提高性能)
如果no-appendfsync-on-rewrite=no, 还是会把数据往磁盘里刷,但是遇到重写操作,可能会发生阻塞。(数据安全,但是性能降低)
触发机制,何时重写
Redis会记录上次重写时的AOF大小,默认配置(可配置)是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发(重写虽然可以节约大量磁盘空间,减少恢复时间。但是每次重写还是有一定的负担的,因此设定Redis要满足一定条件才会进行重写。)
文件大小触发重写配置auto-aof-rewrite-percentage:设置重写的基准值,文件达到100%时开始重写(文件是原来重写后文件的2倍时触发)
auto-aof-rewrite-min-size:设置重写的基准值,最小文件64MB。达到这个值开始重写。
例如:文件达到70MB开始重写,降到50MB,下次什么时候开始重写?100MB
系统载入时或者上次重写完毕时,Redis会记录此时AOF大小,设为base_size,
如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下,Redis会对AOF进行重写。
重写流程
(1)bgrewriteaof触发重写,先判断是否当前有bgsave或bgrewriteaof在运行,如果有,则等待该命令结束后再继续执行。
(2)主进程fork出子进程执行重写操作,保证主进程不会阻塞。
(3)子进程遍历redis内存中数据到临时文件,客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。
(4)1).子进程写完新的AOF文件后,向主进程发信号,父进程更新统计信息。2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
(5)使用新的AOF文件覆盖旧的AOF文件,完成AOF重写。
优势
- 备份机制更稳健,丢失数据概率更低
- 可读的日志文件,通过操作aof稳健,可以处理误操作
劣势
- 比起rdb占用更多的磁盘空间
- 恢复备份速度更慢
- 每次读写都同步的话,有一定性能压力
- 存在一定bug,造成恢复不能
总结
用哪个好
官方推荐两个都启用。
如果对数据不敏感,可以选单独用RDB。
不建议单独用AOF,因为可能会出现Bug。
如果只是做纯内存缓存,可以都不用。
官方建议(没事的可以晃俩眼)
- RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
- AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.
- Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
- 只做缓存:如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
- 同时开启两种持久化方式
- 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
- RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢?
- 建议不要,因为RDB更适合用于备份数据库(AOF在不断变化不好备份),快速重启,而且不会有AOF可能潜在的bug,留着作为一个万一的手段。
性能建议
因为RDB文件只用作后备用途,建议只在Slave上持久化RDB文件,而且只要15分钟备份一次就够了,只保留save 900 1这条规则。
如果使用AOF,好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只load自己的AOF文件就可以了。
代价,一是带来了持续的IO,二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
只要硬盘许可,应该尽量减少AOF rewrite的频率,AOF重写的基础大小默认值64M太小了,可以设到5G以上。
默认超过原大小100%大小时重写可以改到适当的数值。
Redis的主从复制
是什么,能干嘛
主机数据更新后根据配置和策略,自动同步到备机的master(主)/slaver(从)机制,Master以写为主,Slave以读为主
- 读写分离,性能扩展
- 容灾快速恢复 (也就是解决宕机问题,一个slaver(从)死了可以用其他的slaver(从),而主死了后面说。)
操作
操作之前有几个配置注意下
- 开启daemonize yes (后台启动)
- dump.rdb名字dbfilename (之前有修改过的注意一下)
- appendonly AOP的生成 关掉或者换名字
新建多个config文件,并拷贝redis.conf里的内容,include命令去拷贝。
编辑新建的redis6379.conf,:wq!保存退出
一样的操作新建编辑redis6380.conf和redis6381.conf,注意里面的名字和端口不一样
- Pid文件名字pidfile
- 指定端口port
- slave-priority 10 设置从机的优先级,值越小,优先级越高,用于选举主机时使用。默认100
- Log文件名字
启动三台redis服务器
看查系统进程,三台服务器是否启动
看查三台主机运行情况,role属性角色
配置主从
命令:slaveof 成为某个实例的从服务器
1、在6380和6381上执行 : slaveof 127.0.0.1 6379
2、在主机上写,在从机上可以读取数据
在从机上写数据报错
3、主机挂掉,重启就行,一切如初
4、从机重启需重设:slaveof 127.0.0.1 6379
可以将配置增加到文件中。永久生效。
几个常见的问题
问:切入点问题?slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来,那之前的k1,k2,k3是否也可以复制?
答:当slave1挂掉之后,再次连接,他会去和主master同步数据,从头复制数据。
问:从机是否可以写?set可否?
答:从机只负责读取,主机负责写入。
问:主机shutdown后情况如何?从机是上位还是原地待命?
答:一般情况下当主机挂掉之后,从机是会原地待命的,不会上位(要上位的话,怎么上,这也就是下面要讲的哨兵机制)
问:主机又回来了后,主机新增记录,从机还能否顺利复制?
其中一台从机down后情况如何?依照原有它能跟上大部队吗?
答:主机回来后新增的数据记录,会同步到从机,从机联机主机时都会去比较数据然后同步。
复制原理
- Slave启动成功连接到master后会发送一个sync命令
- Master接到命令启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令, 在后台进程执行完毕之后,master将传送整个数据文件到slave,以完成一次完全同步
- 全量复制:而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中。
- 增量复制:Master继续将新的所有收集到的修改命令依次传给slave,完成同步
- 但是只要是重新连接master,一次完全同步(全量复制)将被自动执行
网络异常,图片无法展示|
性质
- 一主俩从,一般情况下都是配置的一主俩从。
- 薪火相传
- 上一个Slave可以是下一个slave的Master,Slave同样可以接收其他slaves的连接和同步请求,那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。
用slaveof
中途变更转向:会清除之前的数据,重新建立拷贝最新的
风险是一旦某个slave宕机,后面的slave都没法备份
主机挂了,从机还是从机,无法写数据了
- 反客为主
- 当一个master宕机后,后面的slave可以立刻升为master,其后面的slave不用做任何修改。
用slaveof no one 将从机变为主机。
哨兵模式(sentinel)
反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库
怎么玩(使用步骤)
调整为一主二仆模式,6379带着6380、6381
自定义的/myredis目录下新建sentinel.conf文件,名字绝不能错
配置哨兵,填写内容
sentinel monitor mymaster 127.0.0.1 6379 1
其中mymaster为监控对象起的服务器名称, 1 为至少有多少个哨兵同意迁移的数量。
启动哨兵
/usr/local/bin
redis做压测可以用自带的redis-benchmark工具
执行redis-sentinel /myredis/sentinel.conf
当主机挂掉,从机选举中产生新的主机
(大概10秒左右可以看到哨兵窗口日志,切换了新的主机)
哪个从机会被选举为主机呢?根据优先级别:replica-priority
原主机重启后会变为从机。
小缺点:复制延时
由于所有的写操作都是先在Master上操作,然后同步更新到Slave上,所以从Master同步到Slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器数量的增加也会使这个问题更加严重。(也就是RBD和AOF导致的)
流程
优先级在redis.conf中默认:replica-priority 100,值越小优先级越高
偏移量是指获得原主机数据最全的
每个redis实例启动后都会随机生成一个40位的runid