Redis RDB 및 AOF에 대한 자세한 설명
- 小云云원래의
- 2017-12-14 14:22:121814검색
Redis에는 RDB(Redis DataBase)와 AOF(Append Only File)라는 두 가지 지속성 솔루션이 있습니다. RDB 및 AOF를 빠르게 이해하고 사용하려면 기사 하단으로 바로 이동하여 요약을 읽어보세요. 이 장에서는 구성 파일, 스냅샷을 트리거하는 방법, 데이터 복구 작업, 명령 작업 데모, 장점과 단점을 사용하여 Redis의 핵심 지식 지속성을 학습합니다. 이 기사에서는 주로 Redis, RDB 및 AOF의 두 가지 지속성 솔루션에 대한 자세한 분석을 제공합니다. 우리가 편집한 콘텐츠가 모든 사람이 이 두 가지 솔루션을 더 깊이 이해하는 데 도움이 되기를 바랍니다.
RDB 자세한 설명
RDB는 Redis의 기본 지속성 솔루션입니다. 지정된 시간 간격 내에 지정된 횟수의 쓰기 작업이 수행되면 메모리의 데이터가 디스크에 기록됩니다. 즉, 지정된 디렉터리에 dump.rdb 파일이 생성됩니다. Redis를 다시 시작하면 dump.rdb 파일을 로드하여 데이터가 복원됩니다.
구성 파일에서 RDB에 대해 알아보세요
redis.conf 파일을 열고 SNAPSHOTTING의 해당 내용을 찾으세요
1 RDB 핵심 규칙 구성(핵심 사항)
save <seconds> <changes> # save "" save 900 1 save 300 10 save 60 10000
설명: 저장 <시간 간격 지정> ; , 조건이 충족되면 메모리의 데이터가 하드 디스크에 동기화됩니다. 기본 공식 공장 구성은 900초 이내에 1개의 변경, 300초 이내에 10개의 변경, 60초 이내에 10,000개의 변경이 있으면 메모리에 있는 데이터 스냅샷이 디스크에 기록된다는 것입니다.
RDB 솔루션을 사용하지 않으려면 저장 ""댓글, 다음 세 가지 댓글을 열 수 있습니다.
2 로컬 데이터베이스 파일 이름을 지정하고 일반적으로 기본 dump.rdb를 사용합니다.
dbfilename dump.rdb
3 로컬 데이터베이스 저장소 디렉터리를 지정하고 일반적으로 기본 구성을 사용합니다.
dir ./
4 데이터 압축 켜기 기본적으로
rdbcompression yes
설명: 로컬 데이터베이스에 데이터를 저장할 때 데이터를 압축할지 여부를 구성합니다. 기본값은 yes입니다. Redis는 LZF 압축을 사용하지만 약간의 CPU 시간을 차지합니다. 이 옵션을 끄면 데이터베이스 파일이 커집니다. 켜는 것이 좋습니다.
RDB 스냅샷 트리거
1 지정된 시간 간격 내에 지정된 수의 쓰기 작업을 수행합니다.
2 save(차단, 스냅샷만 저장, 다른 사람을 기다림) 또는 bgsave(비동기) 명령 실행
3 플러시all 명령을 실행하여 데이터베이스의 모든 데이터를 지웁니다. 이는 별 의미가 없습니다.
4 데이터 손실 없이 서버가 정상적으로 종료되도록 하려면 shutdown 명령을 실행하세요. 이는 별 의미가 없습니다.
RDB 파일을 통해 데이터 복구
dump.rdb 파일을 redis 설치 디렉터리의 bin 디렉터리에 복사하고 redis 서비스를 다시 시작하세요. 실제 개발에서는 일반적으로 물리적 머신의 하드디스크 손상을 고려하여 백업 dump.rdb를 선택합니다. 다음의 작동 시연을 통해 체험해 보실 수 있습니다.
RDB의 장점과 단점
장점:
1 대규모 데이터 복구에 적합합니다.
2 비즈니스에서 데이터 무결성 및 일관성에 대한 높은 요구 사항이 없다면 RDB가 좋은 선택입니다.
단점:
1 마지막 백업 중에 RDB가 다운되었을 수 있으므로 데이터 무결성과 일관성이 높지 않습니다.
2 백업 중에 Redis가 독립적으로 하위 프로세스를 생성하고 임시 파일에 데이터를 쓰고(현재 메모리에 있는 데이터는 원래 크기의 2배임) 최종적으로 임시 파일을 교체하기 때문에 백업 중에 메모리가 점유됩니다. 이전 백업 파일을 저장하세요.
그래서 Redis 지속성 및 데이터 복구를 한밤중에 실행하도록 선택하는 것이 더 합리적입니다.
작업 데모
[root@itdragon bin]# vim redis.conf save 900 1 save 120 5 save 60 10000 [root@itdragon bin]# ./redis-server redis.conf [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379 127.0.0.1:6379> keys * (empty list or set) 127.0.0.1:6379> set key1 value1 OK 127.0.0.1:6379> set key2 value2 OK 127.0.0.1:6379> set key3 value3 OK 127.0.0.1:6379> set key4 value4 OK 127.0.0.1:6379> set key5 value5 OK 127.0.0.1:6379> set key6 value6 OK 127.0.0.1:6379> SHUTDOWN not connected> QUIT [root@itdragon bin]# cp dump.rdb dump_bk.rdb [root@itdragon bin]# ./redis-server redis.conf [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379 127.0.0.1:6379> FLUSHALL OK 127.0.0.1:6379> keys * (empty list or set) 127.0.0.1:6379> SHUTDOWN not connected> QUIT [root@itdragon bin]# cp dump_bk.rdb dump.rdb cp: overwrite `dump.rdb'? y [root@itdragon bin]# ./redis-server redis.conf [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379 127.0.0.1:6379> keys * 1) "key5" 2) "key1" 3) "key3" 4) "key4" 5) "key6" 6) "key2"
1단계: vim에서 지속성 구성 시간을 수정합니다. 120초 내에 5번 수정하면 1번 지속됩니다.
2단계: 서비스를 다시 시작하여 구성을 적용합니다.
3단계: 각각 5개의 키를 설정합니다. 2분 후 bin의 현재 디렉터리에 dump.rdb 파일이 자동으로 생성됩니다. (key6 설정은 종료가 RDB 스냅샷을 트리거할 수 있는지 확인하기 위한 것입니다.)
4단계: 현재 dump.rdb의 백업 복사본을 만듭니다(온라인 작업 시뮬레이션).
5단계: FLUSHALL 명령을 실행하여 데이터베이스 데이터를 지웁니다(데이터 손실 시뮬레이션).
6단계: Redis 서비스를 다시 시작하고 데이터를 복원합니다... 응? ? ? ? ('◔ ‸◔`). 데이터가 비어 있습니까? ? ? ? FLUSHALL에는 RDB 스냅샷을 트리거하는 기능도 있기 때문입니다.
7단계: 백업 dump_bk.rdb를 dump.rdb로 바꾼 다음 redis합니다.
참고: SHUTDOWN 및 FLUSHALL 명령은 RDB 스냅샷을 트리거합니다. 주의하세요.
기타 명령:
keys * 데이터베이스의 모든 키 일치 save 블록 트리거 RDB 스냅샷을 통해 데이터 백업 FLUSHALL 전체 Redis 서버의 데이터 지우기(드물게 사용됨) SHUTDOWN 종료하고 나가기(드물게 사용됨)
AOF 자세한 설명
AOF: Redis는 기본적으로 활성화되어 있지 않습니다. RDB의 단점(데이터 불일치)을 보완한 것으로 보이므로 로그 형태를 사용하여 각 쓰기 작업을 기록하고 파일에 추가합니다. Redis가 다시 시작되면 로그 파일의 내용을 기반으로 앞에서 뒤로 쓰기 명령이 실행되어 데이터 복구 작업이 완료됩니다.
구성 파일에서 AOF에 대해 알아보세요
redis.conf 파일을 열고 APPEND ONLY MODE의 해당 내용을 찾으세요
1 redis는 기본적으로 닫혀 있습니다. 수동으로 no를 yes로 변경해야 합니다
2 指定本地数据库文件名，默认值为 appendonly.aof
appendfilename "appendonly.aof"
3 指定更新日志条件
# appendfsync always appendfsync everysec # appendfsync no
解说：
always：同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差当数据完整性比较好（慢，安全）
everysec：出厂默认推荐，每秒异步记录一次（默认值）
no：不同步
4 配置重写触发机制
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
解说：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。一般都设置为3G，64M太小了。
触发AOF快照
根据配置文件触发，可以是每次执行触发，可以是每秒触发，可以不同步。
根据AOF文件恢复数据
正常情况下，将appendonly.aof 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。但在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复 。从下面的操作演示中体会。
AOF的重写机制
前面也说到了，AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多。所以聪明的 Redis 新增了重写机制。当AOF文件的大小超过所设定的阈值时，Redis就会对AOF文件的内容压缩。
重写的原理：Redis 会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中。并没有读取旧文件（你都那么大了，我还去读你？？？ o(ﾟДﾟ)っ傻啊！）。最后替换旧的aof文件。
触发机制：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M” 可以通过配置文件修改。
AOF 的优缺点
优点：数据的完整性和一致性更高
缺点：因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。
操作演示
[root@itdragon bin]# vim appendonly.aof appendonly yes [root@itdragon bin]# ./redis-server redis.conf [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379 127.0.0.1:6379> keys * (empty list or set) 127.0.0.1:6379> set keyAOf valueAof OK 127.0.0.1:6379> FLUSHALL OK 127.0.0.1:6379> SHUTDOWN not connected> QUIT [root@itdragon bin]# ./redis-server redis.conf [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379 127.0.0.1:6379> keys * 1) "keyAOf" 127.0.0.1:6379> SHUTDOWN not connected> QUIT [root@itdragon bin]# vim appendonly.aof fjewofjwojfoewifjowejfwf [root@itdragon bin]# ./redis-server redis.conf [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379 Could not connect to Redis at 127.0.0.1:6379: Connection refused not connected> QUIT [root@itdragon bin]# redis-check-aof --fix appendonly.aof 'x 3e: Expected prefix '*', got: ' AOF analyzed: size=92, ok_up_to=62, diff=30 This will shrink the AOF from 92 bytes, with 30 bytes, to 62 bytes Continue? [y/N]: y Successfully truncated AOF [root@itdragon bin]# ./redis-server redis.conf [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379 127.0.0.1:6379> keys * 1) "keyAOf"
第一步：修改配置文件，开启AOF持久化配置。
第二步：重启Redis服务，并进入Redis 自带的客户端中。
第三步：保存值，然后模拟数据丢失，关闭Redis服务。
第四步：重启服务，发现数据恢复了。（额外提一点：有教程显示FLUSHALL 命令会被写入AOF文件中，导致数据恢复失败。我安装的是redis-4.0.2没有遇到这个问题）。
第五步：修改appendonly.aof，模拟文件异常情况。
第六步：重启 Redis 服务失败。这同时也说明了，RDB和AOF可以同时存在，且优先加载AOF文件。
第七步：校验appendonly.aof 文件。重启Redis 服务后正常。
补充点：aof 的校验是通过 redis-check-aof 文件，那么rdb 的校验是不是可以通过 redis-check-rdb 文件呢？？？
总结 Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。 RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。 Redis 需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。
AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。 Redis 针对 AOF文件大的问题，提供重写的瘦身机制。若只打算用Redis 做缓存，可以关闭持久化。若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份，留一后手。AOF出问题了，还有RDB。
相关推荐：
위 내용은 Redis RDB 및 AOF에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!