Redis 지속성 스냅샷의 방법 및 원칙

소위 지속성이란 데이터가 손실되지 않도록 유지하는 것이며 데이터는 일반적으로 하드 드라이브에 저장됩니다. Redis에는 두 가지 지속성 방법이 있는데, 하나는 스냅샷 지속성이고 다른 하나는 AOF 지속성입니다. 각각은 고유한 장점과 단점이 있습니다. 프로젝트에서는 실제 상황에 따라 특정 지속성 방법을 선택해야 합니다.

권장: redis 입문 튜토리얼

스냅샷 지속성(RDB)

RDB 지속성 방법이라고도 합니다. 이는 스냅샷을 찍어 특정 시간의 메모리 데이터를 rdb 파일에 저장하여 지속성을 달성하는 것입니다. Redis 서비스가 다시 시작될 때 파일의 데이터

영구 스냅샷 구성

Redis의 스냅샷 지속성은 기본적으로 활성화되어 있으며 redis.conf 구성 파일에 관련 구성 옵션이 있습니다

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

save 900 1   #900秒内至少有1个key被更改就执行快照
save 300 10  #300内描述至少有10个key被更改就执行快照
save 60 10000  #60秒内至少有10000个key被更改就执行快照

# By default Redis will stop accepting writes if RDB snapshots are enabled
# (at least one save point) and the latest background save failed.
# This will make the user aware (in a hard way) that data is not persisting
# on disk properly, otherwise chances are that no one will notice and some
# disaster will happen.
#
# If the background saving process will start working again Redis will
# automatically allow writes again.
#
# However if you have setup your proper monitoring of the Redis server
# and persistence, you may want to disable this feature so that Redis will
# continue to work as usual even if there are problems with disk,
# permissions, and so forth.
stop-writes-on-bgsave-error yes #拍摄快照失败是否继续执行写命令

# Compress string objects using LZF when dump .rdb databases?
# For default that&#39;s set to &#39;yes&#39; as it&#39;s almost always a win.
# If you want to save some CPU in the saving child set it to &#39;no&#39; but
# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression yes #是否对快照文件进行压缩

# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
# This makes the format more resistant to corruption but there is a performance
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
# for maximum performances.
#
# RDB files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
rdbchecksum yes #是否进行数据校验

# The filename where to dump the DB
dbfilename dump.rdb #快照文件存储的名称
# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the &#39;dbfilename&#39; configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir /opt/redis-5.0.3#快照文件存储的位置

확인하세요. effect

1. 설치 디렉터리에 들어가서 dump.db 파일이 있으면 삭제합니다.

2. redis를 시작한 다음 몇 가지 데이터를 추가하고 redis를 닫고

[root@root redis-5.0.3]# src/redis-cli 
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> set name aaa
OK
127.0.0.1:6379> set age 18
OK
127.0.0.1:6379> incr age
(integer) 19
127.0.0.1:6379> shutdown
not connected> exit

3을 종료합니다. 이것이 우리의 스냅샷 백업 파일입니다

4. Redis를 다시 시작하면 원본 데이터가 여전히 남아 있다는 것을 알 수 있습니다. 이는 Redis가 시작될 때 백업 파일에 데이터를 로드하기 때문입니다.

[root@root redis-5.0.3]# src/redis-server redis.conf 
1211:C 13 Feb 2019 01:27:22.668 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1211:C 13 Feb 2019 01:27:22.668 # Redis version=5.0.3, bits=64, commit=00000000, modified=0, pid=1211, just started
1211:C 13 Feb 2019 01:27:22.668 # Configuration loaded
[root@root redis-5.0.3]# src/redis-cli 
127.0.0.1:6379> ping 
PONG
127.0.0.1:6379> get name
"aaa"
127.0.0.1:6379> get age
"19"
127.0.0.1:6379> keys *
1) "name"
2) "age"

5. 닫고 종료합니다

닫고 종료한 후 dump.rdb 파일을 삭제합니다. 시작하면 데이터가 사라진 것을 확인할 수 있습니다.

[root@root redis-5.0.3]# src/redis-server redis.conf 
1218:C 13 Feb 2019 01:29:01.336 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1218:C 13 Feb 2019 01:29:01.336 # Redis version=5.0.3, bits=64, commit=00000000, modified=0, pid=1218, just started
1218:C 13 Feb 2019 01:29:01.336 # Configuration loaded
[root@root redis-5.0.3]# src/redis-cli 
127.0.0.1:6379> ping 
PONG
127.0.0.1:6379> keys *
(empty list or set)

스냅샷 지속성 원칙

save 명령:

redis는 실행하면 send A save 명령을 표시하여 스냅샷을 찍을 수 있습니다. save 명령은 차단 명령입니다. 즉, 서버가 save 명령을 받으면 스냅샷 촬영을 시작합니다. 이 기간 동안 다른 요청은 백업이 완료될 때까지 일시 중지됩니다.

bgsave 명령

bgsave 명령도 즉시 스냅샷을 찍습니다. save 명령과 달리 bgsave는 차단 명령이 아니지만 하위 스레드를 포크하고 이 하위 스레드가 백업 작업을 담당합니다. 상위 프로세스는 클라이언트의 요청을 계속 처리하므로 차단이 발생하지 않습니다.

127.0.0.1:6379> ping
PONG
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set name zhangsan
OK
127.0.0.1:6379> set age 20
OK
127.0.0.1:6379> bgsave
Background saving started

4. 종료 명령

명령을 종료하고 싶을 때. 서버는 자동으로 저장 명령을 보내 스냅샷 작업을 완료합니다. 그리고 백업 작업이 완료된 후 서버를 종료하세요. 따라서 작업이 처음 세 가지 조건을 충족하지 못하는 경우 서버를 종료한 후 다시 열 때 데이터가 손실되지 않습니다.

5. sync 명령

마스터-슬레이브 환경에서 슬레이브 노드는 마스터 노드의 데이터를 동기화하려고 할 때 복제를 개발하기 위해 동기화 명령을 보냅니다. 이때 마스터 노드는 bgsave 명령을 보내 새 스레드를 포크하여 스냅샷을 완료하고, bgsave 명령 작업이 완료된 후 슬레이브 노드에 스냅샷 파일을 보내 마스터 노드와 슬레이브 노드의 데이터 동기화를 완료합니다.

장점과 단점

장점

RDB 파일은 Redis 데이터를 특정 시점에 저장하므로 백업에 적합합니다. RDB 파일을 보관할 시점을 설정하여 필요할 때 쉽게 보관할 수 있습니다. 데이터가 다른 버전으로 복원됩니다. RDB는 재해 복구에 매우 적합합니다. 단일 파일을 원격 서버로 쉽게 전송할 수 있습니다. 데이터 양이 상대적으로 많을 경우 RDB가 빨리 시작됩니다.

단점

RDB는 3분마다 저장하도록 설정하면 어떤 이유로 Redis가 제대로 작동하지 않을 경우 마지막부터 시간이 걸립니다. Redis가 나타나는 시간에 대한 스냅샷 이 기간 동안의 데이터는 손실됩니다.

스냅샷 지속성을 비활성화하는 방법

1. redis.conf 구성 파일의 모든 저장 구성을 주석 처리합니다. 2. 마지막 저장 구성

save ""

AOF 지속성

에 eat 명령을 직접 스냅샷 지속성과 함께 추가합니다. Redis의 키-값 쌍 데이터, AOF 지속성은 Redis가 실행하는 쓰기 명령을 저장하여 Redis의 메모리 데이터를 기록합니다. 이론적으로 Redis 메모리 데이터를 수정할 수 있는 모든 명령(즉, 쓰기 명령)을 저장하면 저장된 쓰기 명령을 기반으로 Redis의 메모리 상태를 복원할 수 있습니다. AOF 지속성은 데이터 지속성과 데이터 복구를 달성하기 위해 이 원칙을 사용합니다. Redis에서는 기본적으로 aof가 꺼져 있습니다. aof를 켜려면 구성 파일을 수정해야 합니다.

appendonly yes
appendfilename "appendonly.aof"
# If unsure, use "everysec".
# appendfsync always
appendfsync everysec
# appendfsync no
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

확인하고 다시 시작하세요. 서비스

간단한 명령어 연산을 실행해 보면,append.aof 파일에 저장된 내용이 우리가 실행한 명령어임을 알 수 있습니다

AOF 영구 백업에 대한 참고 사항

1. appendfsync 세 가지 값, 즉 Everysec, Always 및 No가 있습니다. 여기서는 Everysec을 사용하는 것이 좋지만 항상 권장하지는 않습니다. 왜냐하면 항상 서버 성능에 심각한 영향을 미치기 때문입니다. 2. 최악의 경우, Everysec은 1초의 데이터만 손실되며 그 영향은 제어 가능한 범위 내에 있습니다.

장점 및 단점

장점

AOF 지속성 방법은 다양한 동기화 빈도를 제공합니다. 기본 동기화 빈도를 사용하여 초당 한 번씩 동기화하더라도 Redis는 최대 1초의 데이터만 손실합니다. AOF 파일의 형식은 읽기 쉽기 때문에 사용자에게 보다 유연한 처리 방법을 제공합니다. 예를 들어, 다시 쓰기가 진행되기 전에 실수로 FLUSHALL 명령을 사용한 경우 마지막 FLUSHALL 명령을 수동으로 제거한 다음 AOF를 사용하여 데이터를 복구할 수 있습니다.

단점

AOF는 여러 동기화 주파수를 제공하지만 기본적으로 초당 한 번 동기화하는 빈도도 더 높은 성능을 제공합니다. 그러나 Redis의 로드가 높을 경우 RDB는 AOF보다 더 나은 성능을 보장합니다. RDB는 스냅샷을 사용하여 전체 Redis 데이터를 유지하는 반면 AOF는 실행된 각 명령만 AOF 파일에 추가합니다. 따라서 이론적으로 RDB는 AOF 방법보다 더 강력합니다

지속성을 위한 몇 가지 사용 제안

1. 캐시 서버로만 사용되므로 지속성을 사용할 수 없습니다.

2. 일반적인 상황에서는 두 가지 지속성 방법을 모두 활성화합니다. redis는 데이터를 응답하기 위해 먼저 AOF 파일을 로드합니다. RDB의 장점은 속도가 빠르다는 것이다.

3. 마스터-슬레이브 노드에서는 RDB가 백업 데이터 역할을 하며 salve(슬레이브 노드)에서만 시작됩니다. 동기화 시간은 더 길게 설정할 수 있으며 규칙(900 1 저장)만 남습니다.

관련 권장 사항:

mysql 비디오 튜토리얼: https://www.php.cn/course/list/51.html

위 내용은 Redis 지속성 스냅샷의 방법 및 원칙의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!