至于redis持久化,redis持久化

发布时间:2018-12-14  栏目:NoSQL  评论:0 Comments

manbet手机客户端3.0,redis持久化

redis提供了少于栽持久化的措施,分别是RDB(Redis DataBase)和AOF(Append
Only File)。
RDB,总而言之,就是以不同之时间点,将redis存储的数额变化快照并储存到磁盘等介质上;
AOF,则是更换了一个角度来兑现持久化,那就是是拿redis执行过的持有写指令记录下来,在下次redis重新启航时,只要把这多少个写指令以前方至晚再行重执行同样全勤,就足以实现数据苏醒了。
实则RDB和AOF二种植艺术吗可以又选拔,在这种状态下,假如redis重开的讲话,则会先行使用AOF措施来举行数据恢复生机,这是为AOF情势的数据苏醒完整度更胜。
而您无数据持久化的求,也完全好关闭RDB和AOF方式,这样的话,redis将成为一个纯内存数据库,就比如memcache一样。

关于redis持久化,redis持久化

Redis有些许栽持久化的方法:快照(RDB文件)和追加式文件(AOF文件)

  • RDB持久化形式是在一个一定的间隔保存有时间点的一个数快照。

  • AOF(Append only
    file)持久化情势即使会记录每一个服务器收到的形容操作。数据复苏时,那些记录的操作会相继执行从而重建起原本的多少。写操作命令
     记录的格式跟Redis协议一致,以追加的格局展通辽存。

Redis的持久化是可以禁用的,两种方式的持久化是可以同时存在的,但是当Redis重启时,AOF文件会被优先用于重建数据。

RDB

RDB形式,是拿redis某平等每天的数码持久化到磁盘中,是平等种快照式的持久化方法。
redis在展开数据持久化的历程遭到,会先将数据写入到一个临时文件中,待持久化过程还截至了,才谋面为此之临时文件替换上次持久化好之公文。正是这种特征,让大家得随时来展开备份,因为快照文件连续完全可用的。
对于RDB模式,redis会单独创设(fork)一个子进程来展开持久化,而主进程是匪会见展开另外IO操作的,这样尽管保险了redis极高之属性。
倘用举办大规模数据的回复,且对数据復苏的完整性不是挺灵活,这RDB模式如较AOF形式进一步的迅猛。
虽说RDB有成千上万亮点,但它们的症结也是不容忽视的。假若您对数据的完整性万分敏锐,那么RDB情势即使无极端相符您,因为就你各类5分钟还持久化一不成,当redis故障时,依旧会生濒临5分钟的多寡丢失。所以,redis还提供了其他一样种植持久化模式,这即使是AOF。

一、RDB

RDB纵使Snapshot存储,是默认的持久化格局。依据一定之方针周期性的将数据保存到磁盘。对许发的数据文件为dump.rdb,通过配备文件被的save参数来定义快照的周期。Redis帮忙以近日数的快照存成一个数据文件实现持久化。而一个持续写副的数据库如何转移快照呢。Redis借助了fork命令的copy
on
write机制。在转快照时,将眼前历程fork出一个子历程,然后在子进程被循环所有的数量,将数据勾勒成为RDB文件。

Client
也可以使用save或者bgsave命令通告redis做同浅快照持久化。save操作是于主线程中保存快照的,由于redis是用一个主线程来处理所有
client的呼吁,这种措施会阻塞所有client请求,
从而无推荐使用。另一些待注意的凡,每趟快照持久化都是拿内存数据总体写副到磁盘一坏,并无
是增量的单同脏数据。即便数据量大之语句,而且写操作相比多,必然会滋生大量之磁盘io操作,可能会合严重影响属性。 

Redis的RDB文件未相会坏掉,因为那写操作是当一个新历程面临展开的。当大成一个初的RDB文件时,Redis生成的子进程会先以数据勾勒及一个临时文件中,然后通过原子性rename系统调用将临时文件重命名为RDB文件。这样于此外时刻起故障,Redis的RDB文件还接连可用的。与此同时Redis的RDB文件也是Redis主从一头内部贯彻中的同样环抱

AOF

AOF,英文是Append Only File,即只有同意多不允改写的文件。
比方前介绍的,AOF形式是将行了的刻画指令记录下来,在数据復苏时仍自后边至晚底次第再用指令都实施同样普,就如此简单。
咱俩经过安排redis.conf中的appendonly
yes就可以打开AOF效能。如果发描绘操作(如SET等),redis就相会被长至AOF文件之末梢。
默认的AOF持久化策略是每秒钟fsync一浅(fsync是赖把缓存中之写照指令记录及磁盘中),因为在那种状况下,redis依旧可维持好好之处理性能,即使redis故障,也只相会少近期1分钟的数码。
要是在添日志时,恰好遇见磁盘空间满、inode满或断电等情形导致日志写副不完全,也并未干,redis提供了redis-check-aof工具,能够为此来进行日志修复。
盖运用了添情势,如若非举行其他处理的话,AOF文件会变换得尤为大,为这,redis提供了AOF文件重写(rewrite)机制,即当AOF文件之大小超越所设定的阈值时,redis就碰面启动AOF文件之始末减弱,只保留得恢复生机数据的很是小命集。举个例子或许还像,假若大家调用了100蹩脚INCR指令,在AOF文件中就要存储100漫长指令,但登时明确是这个没用的,完全可以管顿时100修指令合并成一条SET指令,这即是重写机制的规律。
当开展AOF重写时,依然是采纳先勾勒临时文件,全体成功后还交替的流水线,所以断电、磁盘满等问题且非会合潜移默化AOF文件的可用性,这一点我们好放心。
AOF形式的其余一个益处,我们因而一个“场景再次出现”来表明。某同学在操作redis时,不小心执行了FLUSHALL,导致redis内存中的数据总体叫清空了,这是不行喜剧的事体。不过这吗非是世界末日,只要redis配置了AOF持久化情势,且AOF文件还尚无为还写(rewrite),我们就算可以用最抢的速暂停redis并编写AOF文件,将最后一行的FLUSHALL命令删除,然后还启redis,就好过来redis的享有数据到FLUSHALL此前的状态了。是不是深神奇,这即便是AOF持久化格局的裨益有。可是假设AOF文件都让再一次写了,那就不能够通过这种模式来过来数据了。
虽说长多多,但AOF格局吧一样有瑕疵,比如在同一数量规模的情形下,AOF文件要相比较RDB文件之体积大。而且,AOF模式的过来速度吗使慢于RDB格局。
假定您一直实施BGREWRITEAOF命令,那么redis会生成一个崭新的AOF文件,其中虽包括了可过来现有数量的绝少的授命集。
若命运相比较不同,AOF文件出现了让勾勒好之气象,也无须过分担忧,redis并无会晤一不小心加载是来题目标AOF文件,而是报错退出。这时可以透过以下步骤来修复出错的文本:

  1. 备份被描绘很的AOF文件
  2. 运作redis-check-aof –fix举行修补
  3. 就此diff -u来拘禁下零星单文本之别,确认问题点
  4. 重启redis,加载修复后底AOF文件

骨干同步

第一次Slave向Master同步的实现是:
Slave向Master发出同步请求,Master先dump出rdb文件,然后将rdb文件全量传输给slave,然后Master把缓存的命令转发给Slave,初次同步完成。
第二次以及以后的同步实现是:
Master将变量的快照直接实时依次发送给各个Slave。但不管什么原因导致Slave和Master断开重连都会重复以上两个步骤的过程。
Redis的主从复制是建立在内存快照的持久化基础上的,只要有Slave就一定会有内存快照发生。

AOF重写

AOF重写的中运转规律,大家有必要明白一下。
每当重写即将起先之际,redis会创设(fork)一个“重写子进程”,这么些子进程会首先读取现有的AOF文件,并拿这多少个富含的命令展开辨析压缩并勾画副到一个临时文件中。
与此同时,主工作经过会拿新吸纳及之勾指令一边累积到内存缓冲区中,一边继续写副到原有的AOF文件被,这样做是确保原有的AOF文件之可用性,制止以再次写过程中冒出奇怪。
当“重写子进程”完成再写工作后,它会叫父进程发一个信号,父进程收到信号后就是会面拿内存中缓存的写照指令增至新AOF文件中。
当多了后,redis就会师就此新AOF文件来顶替旧AOF文件,之后又爆发新的状指令,就都会师大增至新的AOF文件被了。

干活规律

  • Redis调用fork(),爆发一个子进程。

  • 老子进程继续处理client请求,子进程将内存数据勾勒及一个临时之RDB文件。由于os的描摹时复制机制(copy
    on
    write)父子进程会共享相同之大体页面,当大爷进程处理写请求时os会为小叔进程而改的页面创立副本,而无是描摹共享的页面。所以子进程的地方空间内的数目是fork时刻整个数据库的一个快照。

  • 当子进程将快照写副临时文件完毕后,用临时文件替换原来的快照文件,然后子进程退出

主从(master-slave)

比如MySQL一样,redis是永葆大旨同步的,而且为扶助一兆多起同系列从结构。
大旨结构,一凡为纯粹的冗余备份,二凡是为着提高读性能,比如十分耗费性能的SORT就可由从服务器来负担。
redis的主干同步是异步进行的,这意味着基本同步不会师潜移默化主逻辑,也未会见稳中有降redis的拍卖性能。
主导架构中,可以考虑关闭主服务器的数额持久化功用,只吃从服务器举行持久化,这样好加强主服务器的处理性能。
于主导架构中,从服务器平时为装也就读形式,这样可免从服务器的多少让无意修改。可是于服务器仍旧可以承受CONFIG等一声令下,所以如故不应当将从服务器直接显露到不安全之网络环境受到。倘使非得这样,这好设想给要指令展开重新命名,来避免命令于旁人误执行。

优点

  • RDB文件是一个百般简单之单文件,它保存了某个时间点的Redis数据,很适合用于做备份。你可设定一个时空接触对RDB文件举行归档,那样即便能于需要之时光杀随便的管数据复苏到不同之版。

  • RDB很抱用来灾备。单文件特别有利就会传输到长途的服务器上。

  • RDB的性能好好,需要展开持久化时,主进程会fork一个子历程出来,然后把持久化的工作交给子进程,自己非会师来有关的I/O操作。

  • 比起AOF,在数据量相比较老之状态下,RDB的起步速度更快。

旅原理

自服务器会向主服务器发SYNC指令,当主服务器收到这么些命令后,就会见调用BGSAVE指令来创立一个子进程专门展开数据持久化工作,也即是将主服务器的数据勾勒入RDB文件中。在多少持久化期间,主服务器将推行之描绘指令都休息存在内存中。
当BGSAVE指令执行得后,主服务器会将持久化好之RDB文件发送给于服务器,从服务器收到这一个文件后会用那储存到磁盘上,然后还将其读取到内存中。那一个动作一气浑成后,主服务器会将顿时段时缓存的描绘指令再盖redis协议的格式发送给起服务器。
除此以外,要说的少数凡是,即便暴发差不四只自服务器又发来SYNC指令,主服务器也止会实施同一蹩脚BGSAVE,然后将持久化好的RDB文件发放五只下游。在redis2.8本子在此以前,如果打服务器和主服务器因一些原因断开连接的说话,都会晤展开同样次于核心之间的全量的数额并;而于2.8本子后,redis协理了频率又胜的增量同步策略,那大大降低了连年断开的复原资本。
预告服务器会在内存中维护一个缓冲区,缓冲区中贮存在用如发给从服务器的情。从服务器在跟主服务器出现网络刹那断之后,从劳动器会尝试还和主服务器连接,一旦连续成,从服务器即会管“希望同的主服务器ID”和“希望请的数量的舞狮地点(replication
offset)”发送出。主服务器接收及这么的一道请求后,首先相会验证主服务器ID是否以及投机之ID匹配,其次会检讨“请求的摇地点”是否存在为自己之缓冲区中,假如两岸都满意的语句,主服务器就会朝着于服务器发送增量内容。
增量同步效用,需要劳务器端匡助新的PSYNC指令。这么些命令,只有以redis-2.8之后才有所。

缺点

  • RDB容易造成数的丢失。尽管每5分钟保存一坏快照,假设Redis因为一些原因无可知健康干活,那么自从上次暴发快照到Redis出现问题当即段时日之多少就会晤丢了。

  • RDB使用fork()暴发子进程展开数据的持久化,如若数量比丰硕的言辞也许就是会见花费点时间,造成Redis为止服务几毫秒。倘诺数据量很死还CPU性能不是相当好之时段,截至服务之岁月如故会合暨1秒。

文件路径和名称

默认Redis会将快照文件存储吗当前目录下一个称为吧dump.rdb的文件。要改文件之仓储路径和称号,可以透过修改配置文件redis.conf实现:

# RDB文件名,默认为dump.rdb。
dbfilename dump.rdb

# 文件存放的目录,AOF文件同样存放在此目录下。默认为当前工作目录。
dir ./

保存点(RDB的启用和剥夺)

公可安排保存点,使Redis假使在每N秒后数暴发了M次改变就封存快照文件。例如上边是保存点配置表示每60秒,假使数量来了1000不良以上之反,Redis就会师活动保存快照文件:

save 60 1000

保存点可以设置六个,Redis的布局文件就默认设置了3单保存点:

# 格式为:save <seconds> <changes>
# 可以设置多个。
save 900 1 #900秒后至少1个key有变动
save 300 10 #300秒后至少10个key有变动
save 60 10000 #60秒后至少10000个key有变动

假如想禁用快照保存之职能,可以经过注释掉所有”save”配置上,或者当最终一久”save”配置后上加如下的布局:

save ""

错误处理

默认情况下,假设Redis在后台生成快照的当儿败北,那么即便会合已接收数据,目标是为用户可以明了多少没有持久化成功。可是假设您有任何的点子能够监督到Redis及其持久化的状态,那么得将那效果禁止掉。

stop-writes-on-bgsave-error yes

数据压缩

默认Redis会采用LZF本着数据开展削减。假诺你想节约点CPU的性质,你得拿减掉效用禁用掉,可是多少集就会比没有减的上要打。

rdbcompression yes

多上校验

从版本5的RDB的开始,一个CRC64的校验码会放在文件的结尾。那样还是可以管文件之完整性,不过在保存依然加载文件时会见损失一定之性(大概10%)。倘诺想追求更胜似的习性,可以拿它们禁用少,这样文件在描写入校验码时会师用0替,加载的时节见到0不怕碰面直接跨越了校验

rdbchecksum yes

手动生成快照

Redis提供了零星个命用于手动生成快照。

SAVE

SAVE命令会使用并的法门生成RDB快照文件,这表示当那过程中会师死所有其他客户端的请。因而无提议以养环境下那一个命令,除非因为某种原因需要去阻止Redis使用子进程展开后台生成快照(例如调用fork(2)出错)。

BGSAVE

BGSAVE命令下后台的形式保留RDB文件,调用此命令后,会霎时返OK回到回码。Redis会出一个子经过展开拍卖并立时回复对客户端的劳务。在客户端我们得以使用LASTSAVE命令查看操作是否成。

127.0.0.1:6379> BGSAVE
Background saving started
127.0.0.1:6379> LASTSAVE
(integer) 1433936394

配置文件里禁用了快照生成功能不影响SAVE和BGSAVE命令的效果。

二、AOF

快照并无是生可靠。假若服务器突然Crash了,那么流行的数码就会丢掉。而AOF文件则提供了一如既往种植更加可靠的持久化模式。每当Redis接受与修改数据集的一声令下时,就会把命追加到AOF文件里,当您又启Redis时,AOF里之指令会让再次履行同样不成,重建数据

原理

  • redis调用fork ,现在生父子两独过程

  • 旁进程遵照内存中的数据库快照,往临时文件中描绘副重建数据库状态的指令

  • 姑丈进程继续处理client请求,除了将写命令写副到本的aof文件中。同时将收到的刻画命令缓存起来。这样尽管能确保如若实进程再写黄的言辞并无会面出问题

  • 当子进程将快照内容写副曾三令五申道写及临时文件中后,子进程发信号通告岳父进程。然后大进程将缓存的状命令也写入到临时文件

  • 现行父进程可以行使临时文件替换老的aof文件,比量齐观命名,前面收的勾命令也开通往新的aof文件中多

优点

  • 比RDB可靠。你可制定不同之fsync策略:不举办fsync、每秒fsync一糟糕以及每趟查询举行fsync。默认是各样秒fsync一涂鸦。这表示你无限多有失一分钟的数据。

  • AOF日志文件是一个纯粹追加的文本。虽然服务器突然Crash,也未会合油但是生日志的固定如故损坏问题。甚至使因某些原因(例如磁盘满了)命令唯有写了大体上及日志文件里,我们呢堪用redis-check-aof斯家伙非常简单的进展修复。

  • 当AOF文件太好时,Redis会自动在后台举行重写。重写深安全,因为重写是当一个初的公文及进展,同时Redis会继续于旧的文件扩张数据。新文件及会刻画副能重建当前数据集的可是小操作命令的成团。当新文件重写了,Redis会把新老文件举行切换,然后开端把数量勾勒到新文件上。

  • AOF把操作命令以简练容易亮的格式一久连接一长达之保留于文书里,很容易导出来用于复苏数据。例如我们无聊心用FLUSHALL一声令下将拥有数据刷掉了,只要文件没有让重复写,大家得以拿劳务停掉,把最后这长命令删掉,然后再开服务,这样就能将让刷掉的数据恢复生机回来。

缺点

  • 当同之数集下,AOF文件的深浅相似会比RDB文件充分。

  • 当好几fsync策略下,AOF的快慢会比RDB慢。平常fsync设置为各级秒五遍等就能取相比较大的特性,而当取缔fsync的景下速度可以达成RDB的档次。

  • 在过去已经发现有些万分罕的BUG导致使用AOF重建的数量跟原数据不相同的题材。

启用AOF

管部署起appendonly设为yes

appendonly yes

文本路径和名称

# 文件存放目录,与RDB共用。默认为当前工作目录。
dir ./

# 默认文件名为appendonly.aof
appendfilename "appendonly.aof"

可靠性

若得安排Redis调用fsync的频率,有三独选项:

  • 在暴发新命令追加至AOF的时节调用fsync。速度最好缓慢,不过太安全。

  • 每秒fsync三回于。速度快(2.4本子与快照模式速度多),安全性不错(最多有失1秒的数量)。

  • 莫fsync,交由系统去处理。这些方法速度极抢,可是安全性没有管教

推荐下各样秒fsync一欠好的计(默认的措施),因为它快快,安全性也不利。相关配置如下:

# appendfsync always
appendfsync everysec
# appendfsync no

日记重写

趁写操作的连追加,AOF文件会愈来愈不行。例如你递增一个计数器100差,那么最后结出就是数集里的计数器的值也最后之与日俱增结果,然而AOF文件里倒会管即刻100糟操作完的记录下来。而其实假若回升这一个记录,只待1只命就推行了,也就是说AOF文件里那么100久命令其实可以简单为1长达。所以Redis匡助这样一个效用:在非间歇服务之情下将来台重建AOF文件。

工作规律如下:

  • Redis调用fork(),发生一个子经过。

  • 分层进程将新的AOF写到一个临时文件里。

  • 预示进程不断拿新的改写到内存里的buffer,同时也会将这个新的反写到原来的AOF里,这样就是重写失败为克保证数据的安全。

  • 当子进程就文件之重写后,主进程会拿到一个信号,然后拿内存里的buffer追加到子进程生成的深新AOF里。

俺们好透过部署安装日志重写的尺度:

#在日志重写时,不进行命令追加操作,而只是将其放在缓冲区里,避免与命令的追加造成DISK IO上的冲突。
#设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入,默认为no,建议yes
no-appendfsync-on-rewrite yes 

# Redis会记住自从上一次重写后AOF文件的大小(如果自Redis启动后还没重写过,则记住启动时使用的AOF文件的大小)。
# 如果当前的文件大小比起记住的那个大小超过指定的百分比,则会触发重写。
# 同时需要设置一个文件大小最小值,只有大于这个值文件才会重写,以防文件很小,但是已经达到百分比的情况。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

万一禁用自动的日记重写功能,我们得管百分比设置为0:

auto-aof-rewrite-percentage 0

Redis 2.4以上才可以自动进行日志重写,之前的版本需要手动运行BGREWRITEAOF这个命令。

数据损坏修复

而盖某些原因(例如服务器崩溃)AOF文件损坏了,导致Redis加载不了,可以通过以下措施展开修复:

  • 备份AOF文件。

  • 使用redis-check-aof命修复原始的AOF文件:

    $ redis-check-aof --fix
    
  • 可动用diff -u命令看下四个文本之异样。

  • 运修复了之文书还启Redis服务。

从RDB切换到AOF

此只说Redis >= 2.2版的方法:

  • 备份一个风靡的dump.rdb的文本,并把备份文件放在一个有惊无险之地点。

  • 运作以下简单漫漫命令:

    $ redis-cli config set appendonly yes
    $ redis-cli config set save ""
    
  • 包数据跟切换前同等。

  • 保险数据对的状到AOF文件里。

第二条命令是用来禁用RDB的持久化方式,但是这不是必须的,因为你可以同时启用两种持久化方式。

记得对配置文件redis.conf进行编辑启用AOF,因为命令行方式修改配置在重启Redis后就会失效。

自地点看出,RDB和AOF操作都是逐一IO操作,性能都大高。而以在通过RDB文件或者AOF日志举办数据库苏醒的上,也是各样的读取数据加载到内存中。所以呢无会晤造成磁盘的随意读。

到底采取啊啊?下边是根源官方的提出:

经常,假诺您如记挂提供特别高的多太史障性,那么提出乃还要以有限种植持久化格局。假若你可以承受灾难带来的几分钟的数量丢失,那么你可就使用RDB。很多用户仅仅用了AOF,可是我们提议,既然RDB可以时不时底为多少做只完整的快照,并且提供更快之重启,所以最好好依然为利用RDB。

于数据苏醒方面:RDB的起步时间会师更短,原因有有限个

  • 相同凡RDB文件中每一样长条数只有出相同长记下,不会合像AOF日志这样可能暴发同漫漫数的多次操作记录。所以每条数据仅待写一不善就是尽了。

  • 旁一个原因是RDB文件的储存格式和Redis数据在内存中的编码格式是千篇一律的,不欲重新展开数据编码工作,所以于CPU消耗及如多小于AOF日志的加载。 

注意:

下面说了RDB快照的持久化,需要专注:在开展快照的上(save),fork出来举行dump操作的子进程会占用和老子进程同的内存,真正的copy-on-write,对性能的熏陶以及内存的耗用都是比卓殊的。比如机械8G内存,Redis已经下了6G内存,这时save的话会再生成6G,变成12G,大于系统的8G。这时候会生出互换;如若虚拟内存不够则会崩溃,导致数据丢失。所以当于是redis的下肯定对系统内存做好容量规划。

现阶段,平常的规划思路是采纳Replication机制来弥补aof、snapshot性能上之欠缺,达到了数码可持久化。即Master上Snapshot和AOF都无举行,来确保Master的读写性能,而Slave上虽同时拉开Snapshot和AOF来拓展持久化,保证数据的安全性。

其三、对Redis持久化的测试

透过下面的辩解对snapshot和aof有了定之明,上面伊始展开一些测试

1、redis.conf 开启snapshot 关闭aof

save 900 1
save 300 10
save 60 10000

rdbcompression no
rdbchecksum no
dbfilename redis.rdb
dir /home/backup/redis

appendonly  no

测试

[[email protected] redis]# ./src/redis-cli 
127.0.0.1:6379> keys *
1) "a"
127.0.0.1:6379> set b 2
OK
127.0.0.1:6379> set c 3
OK
127.0.0.1:6379> set d 4
OK
127.0.0.1:6379> keys *
1) "c"
2) "a"
3) "aa"
4) "b"
5) "d"
127.0.0.1:6379> save
OK
#保存,进行持久化,每执行一次save,会在日至里面记录一条:" * DB saved on disk "

127.0.0.1:6379> lpush aa 1
(integer) 1
127.0.0.1:6379> lpush aa 2
(integer) 2

持久化验证,重启redis

127.0.0.1:6379> keys *
1) "c"
2) "a"
3) "aa"
4) "b"
5) "d"

lpush 操作以 save事后,可是再度开之后仍然有之数量

咦来头呢,我们得查转日志 

6720:signal-handler (1453738444) Received SIGTERM scheduling shutdown...
6720:M 26 Jan 00:14:04.896 # User requested shutdown...
6720:M 26 Jan 00:14:04.896 * Saving the final RDB snapshot before exiting.
6720:M 26 Jan 00:14:04.932 * DB saved on disk
6720:M 26 Jan 00:14:04.932 * Removing the pid file.
6720:M 26 Jan 00:14:04.932 # Redis is now ready to exit, bye bye...

由日记里可以见到,正常关闭redis,在关门前履行save命令。
用kill的功效与上边一样,属于常规关闭

这好关闭也?当以kill -9 的样式发送信号

127.0.0.1:6379> set ss 1
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected> get ss
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected> get ss
(nil)

透过测试,开启RDB持久化,在知足save条件、手动save、正常关闭的时光数据还谋面吃持久化;而生关闭终止之上数据会丢

2、redis.conf 关闭snapshot,关闭aof

#save 900 1
#save 300 10
#save 60 10000
rdbcompression no
rdbchecksum no
dbfilename redis.rdb
dir ./

appendonly  no

操作

redis 127.0.0.1:6379> keys * 
(empty list or set)
redis 127.0.0.1:6379> set name test
OK
redis 127.0.0.1:6379> save
OK
redis 127.0.0.1:6379> set aa 1
OK
redis 127.0.0.1:6379> 

#重启redis

redis 127.0.0.1:6379> keys *                          #发现刚才没有被保存的key丢失了
1) "name"

自地方的结果看出,关闭持久化,唯有在手动save的早晚数据还汇合吃持久化,正常关闭的时光数据丢失。假设打同起初到关闭写副数据的里边一直不手动save,则数全丢失,既然权威动save直接的讲明了快照一向还留存,所以无克说是禁止snapshot,应该是明令禁止自动snapshot功用。

3、redis.conf 关闭snapshot,开启aof

appendonly  yes
appendfilename redis.aof
# appendfsync always
appendfsync everysec
# appendfsync no

no-appendfsync-on-rewrite no
auto-aof-rewrite-min-size 64mb

 操作

redis 127.0.0.1:6379> keys *
1) "name"

#修改开启AOF参数,重启数据库:

redis 127.0.0.1:6379> keys *
(empty list or set)
redis 127.0.0.1:6379> 

#数据库里面没有记录
#查看日志:
#* DB loaded from append only file: 0.000 seconds
#发现是从0字节的aof文件里面同步数据,为什么不同步rdb的数据?原来redis代码里面写好了优先级,AOF>RDB

查看源代码 redis.c   grep ‘DB loaded from’ ./ -R

void loadDataFromDisk(void) {
    long long start = ustime();
    if (server.aof_state == REDIS_AOF_ON) {
        if (loadAppendOnlyFile(server.aof_filename) == REDIS_OK)
            redisLog(REDIS_NOTICE,"DB loaded from append only file: %.3f seconds",(float)(ustime()-start)/1000000);
    } else {
        if (rdbLoad(server.rdb_filename) == REDIS_OK) {
            redisLog(REDIS_NOTICE,"DB loaded from disk: %.3f seconds",
                (float)(ustime()-start)/1000000);
        } else if (errno != ENOENT) {
            redisLog(REDIS_WARNING,"Fatal error loading the DB: %s. Exiting.",strerror(errno));
            exit(1);
        }    
    }
}

此间需要注意的是:当中途被AOF,重开让生效的下,不克第2浅正常再开了

因为第一不佳重复开让aof生效的时光,启动redis已经读取这些文件了,导致这底redis数据为空的(优先级)。第二不善重启,则会把这拖欠的数额save到RDB文件,那样造成RDB原有的多寡为轮换,导致数据丢失。所以自然要小心,为了避免喜剧的有,当要重启redis的时光最好好且备份下RDB文件

redis 127.0.0.1:6379> keys *
(empty list or set)
redis 127.0.0.1:6379> set name tt
OK
redis 127.0.0.1:6379> save
OK

#开启aof参数
#第一次重启
redis 127.0.0.1:6379> keys *   #如上面所说的优先级原因:aof > rdb,结果为空
(empty list or set)


#第2次正常重启,把上面空的结果save到了RDB,数据丢失。此时的db是空的,日志记录 "* DB saved on disk"
redis 127.0.0.1:6379> keys *
(empty list or set)

#数据已经被初始化了,数据丢失

此地虽发出一个问题,比如以就此redis的时段,刚初始只是开RDB的恒久模式,AOF没有打开,在走一段时间之后想被AOF,这哪把RDB的数额直接写及AOF文件呢?有2种方法

a、在开启AOF之前,先执行bgrewriteaof,再重启

redis 127.0.0.1:6379> keys *                   #查看是否有数据
(empty list or set)
redis 127.0.0.1:6379> set name ttd
OK
redis 127.0.0.1:6379> keys *
1) "name"

redis 127.0.0.1:6379> bgsave                   #保存数据
Background saving started
redis 127.0.0.1:6379> keys *
1) "name"

#只有一个RDB文件,没有AOF文件

redis 127.0.0.1:6379> bgrewriteaof             #执行合并重写功能,生成AOF文件
Background append only file rewriting started

#这时候去打开redis.conf 文件中的aof参数(appendonly yes),重启生效。
#日志里面出现:* DB loaded from append only file: 0.000 seconds

redis 127.0.0.1:6379> keys *                    #数据还在
1) "name"


#查看文件
[[email protected] data]# od -c redis.aof 
0000000   *   2  \r  \n   $   6  \r  \n   S   E   L   E   C   T  \r  \n
0000020   $   1  \r  \n   0  \r  \n   *   3  \r  \n   $   3  \r  \n   S
0000040   E   T  \r  \n   $   4  \r  \n   n   a   m   e  \r  \n   $   4
0000060  \r  \n   j   a   c   k  \r  \n
0000070 

b、利用CONFIG GET/SET 的办法动态修改配置文件

redis 127.0.0.1:6379> BGSAVE
Background saving started
#此时,只有rdb文件

#动态修改参数,把aof功能开启:appendonly yes
redis 127.0.0.1:6379> CONFIG SET appendonly yes        #动态修改参数
OK
redis 127.0.0.1:6379> CONFIG GET append*
1) "appendonly"
2) "yes"
3) "appendfsync"
4) "everysec"
redis 127.0.0.1:6379>

#aof文件已经生成,并且有数据(同步rdb)

#日志里面的信息:* Background append only file rewriting started by pid 3165
#因为参数是动态修改的,在重启之后会失效,所以在维护的时候修改redis.conf文件的参数即可

于点的结果看出,redis重开载入数据的时节,读取aof的文件要先于rdb文件,所以尽可能一开首被aof选项,不要以半路打开。

经过日记可以丰硕驾驭的了解redis通过充裕文件来取多少的:

RDB:   * DB loaded from disk: 0.000 seconds
AOF: * DB loaded from append only file: 0.000 seconds

保留数据则是

RDB:* DB saved on disk
AOF:  * Calling fsync() on the AOF file

4、redis.conf 开启snapshot,开启aof

save 900 1
save 300 10
save 60 10000

appendonly  yes
appendfilename zhoujy.aof
# appendfsync always
appendfsync everysec
# appendfsync no

no-appendfsync-on-rewrite no
auto-aof-rewrite-min-size 64mb

经过者的那些测试,已经表达RDB和AOF他们之操作方法,以及一旦再度开时的载入,重启时将据以下优先级回复数据及内存:

  • 倘单独安排AOF,重开时加载AOF文件復苏数据

  • 若以 配置了RBD和AOF,启动是单加载AOF文件恢复生机数据

  • 设单安排RDB,启动时加载dump文件復苏数据

季、Redis数据备份

备份很粗略,只待拿RDB,AOF的文书复制备份起来就是好了

#redisA: A上生成测试数据
redis 127.0.0.1:6379> set name test
7.0.0.1:6379> set age 17
OK
redis 127.0.0.1:6379> keys *
1) "age"

redis 127.0.0.1:6379> bgsave
Background saving started

#redisB: B上没有数据
redis 127.0.0.1:6380> keys *
(empty list or set)

#复制A的文件到B(rdb和aof文件)
cp redis/* redis2/  
#修改权限
chown -R redis.redis *
#重启B 还原
redis 127.0.0.1:6380> keys *
1) "sex"

 

参考

http://redis.io/topics/persistence
http://www.cnblogs.com/zhoujinyi/archive/2013/05/26/3098508.html
http://heylinux.com/archives/1932.html
http://database.51cto.com/art/201203/322144.htm

http://www.bkjia.com/Linuxjc/1095930.htmlwww.bkjia.comtruehttp://www.bkjia.com/Linuxjc/1095930.htmlTechArticle关于redis持久化,redis持久化
Redis有星星点点种植持久化的章程:快照( RDB 文件)和追加式文件( AOF 文件)
RDB持久化情势是以一个一定的距离保存…

留下评论

网站地图xml地图