redis持久化 – 两种方式
redis提供了两种持久化的方式,分别是RDB(Redis DataBase)和AOF(Append Only File)。
官方建议:两种方式都打开,同时进行备份。耐久性不高的可以选快照 RDB。
RDB:就是在不同的时间点,将redis存储的数据生成快照并存储到磁盘等介质上;
优点:备份文件体积小,恢复速度快,fork子进程不影响父进程io;
缺点:故障时丢失数据会多点,数据集庞大时,因fork进程慢,导致客户端响应延迟;
配置:save 600 1,默认为dump.rdb(CONFIG GET save && CONFIG GET dir .....)
AOF:就是将redis执行过的所有写指令记录下来,在下次redis重新启动时,把这些写指令从前到后再重复执行一遍,就可以实现数据恢复了,类似于mysql的binlog。根据fsync策略查找缓存指令记录
优点:数据完整型好,体积过大时会自动重写(将100条写入变为1条set),采用redis协议易读懂;
缺点:文件体积大,恢复较慢,存在fsync策略导致速度较慢;
配置:appendonly yes,默认文件名appendonly.aof (CONFIG GET appendonly);
恢复:比如执行了flushall,将备份文件中此条删除,重启即可。
注:重写,Redis 2.2 需要自己手动执行 BGREWRITEAOF 命令;2.4 则可以自动触发 AOF 重写。
AOF文件出错:(redis重启时会拒绝载入aof文件)
a、备份现有的aof文件
b、# redis-check-aof --fix 命令行执行对现有aof文件进行修复
c、对比两个aof文件区别,重启服务器,载入修复后的aof备份文件
同时使用两种备份策略,redis重启情况下,默认aof优先,因为数据完整性高。
关闭使用两种备份策略,redis就成内存数据库了,和memcache一样。
主从备份:
架构及原理:一主可以多从,从也可以配多从;
1、从连接到主服务器后,发送sync指令;
2、主接到sync指令后,开始执行bgsave,将命令写入缓冲区;
3、bgsave结束后,主将保存得到的.rdb快照文件发给所有从,期间继续记录写操作,telnet可验证;
4、从丢弃旧的快照,载入新的快照。完毕后,主继续发送缓冲区的写指令,从进行增量备份。
配置:从服务器设置如下(当然也可以在redis内部修改,但建议还是修改配置文件)
port 6380
slaveof 192.168.1.1 6379 //配置主的IP 和端口
masterauth <password> //配置主的密码
slave-read-only yes //让从只读,2.4以后默认就是只读
repl-ping-slave-period 10 //设置slave向master发起ping的频率,每10s发起一次
再详细的配置,见redis章节。
同步策略:
策略是,首先会尝试进行增量同步,如不成功,要求从机进行全量同步,之后进行增量同步。
主从切换
1、手动切换
redis-cli -n 6379 shutdown //关掉主
redis-cli -p 6380 slaveof NO ONE //将从设为主,插入 set ddd aaa测试是否成功
cp -f /redis2/dump.rdb /redis/ //主恢复后,将从的dump拷贝到主下
redis-server /redis/master.conf //启动主(要确保从的save设置已生效)
redis-cli -p 6380 slaveof 192.168.10.1 6379 //将从再切换为从,即 ok
2、自动切换 sentinel
暂时先不了解,参考http://www.cnblogs.com/Xrinehart/p/3502198.html
转载于:https://blog.51cto.com/tengxiansheng/1912969