복제란

원문: https://redis.io/topics/replication

레디스 리플리케이션 (레디스 클러스터나 레디스 센티넬처럼 추가 레이어로 제공되는 HA기능은 제외) 은 Leader Follower (마스터-슬레이브) 복제를 사용하고 구성하는 것이 매우 간단하다. 복제 인스턴스는 마스터 인스턴스의 정확한 복사본이 될 수 있다. 복제본은 링크가 끊어질 때마다 매번 자동으로 마스터에 다시 연결되며, 마스터에게 무슨 일이 일어나든 상관 없이 정확한 복사본이 되려 한다. 이 시스템은 세 가지의 주요 메커니즘을 사용하여 작동한다.

  1. 마스터와 복제본이 잘 연결되어 있는 경우에, 마스터 측에서 발생하는 데이터 입력, 키의 만료와 제거 등 마스터 데이터셋의 변경작업들을 복제하기 위해 명령어 스트림을 전달하여 복제본을 업데이트시킨다.
  2. 마스터와 복제본 사이의 링크가 끊어졌을 때, 네트워크 이슈나 타임아웃이 마스터나 복제본 측에서 감지되기 때문에, 복제본은 다시 연결하여 부분적인 재동기화를 진행하려고 시도한다. 이는 연결이 끊겼을 때 놓쳤던 명령어 스트림의 일부만을 얻으려고 시도하는 것을 의미한다. (partial resync)
  3. 부분적인 재동기화가 불가능 할 때, 복제본은 완전한 재동기화를 시도한다. 마스터가 모든 데이터의 스냅샷을 생성해서, 복제본에 전송한 다음, 데이터셋이 변경될 때 명령어 스트림을 계속 전송해야 하는 복잡한 프로세스로 진행된다.

레디스는 기본적으로 비동기식 복제를 사용하는데, 이는 짧은 지연시간과 높은 성능을 가진다. 마스터는 복제본에서 명령어가 처리되는 것을 기다리지 않는다. 하지만 필요한 경우, 복제본에서 어떤 명령어가 수행됐는지 알 수 있다. 이를 통해 선택적으로 동기식 복제를 수행할 수 있다.

특정 데이터의 동기식 복제는 WAIT 명령어를 사용해서 클라이언트가 요청할 수 있다. 하지만 WAIT은 다른 레디스 인스턴스에 지정된 수의 복사본이 있는지 확인할 수 있을 뿐, 레디스 인스턴스를 강한 일관성을 가진 복제 시스템으로 변환하지는 않는다. 레디스 쓰기는 여전히 페일오버 중에 손실될 수 있다. 하지만 WAIT을 사용하면 실패 이벤트 이후에 쓰기모드를 잃을 가능성이 크게 저하되어 특정 장애 모드를 트리거하기 어렵다.

 WAIT <numreplicas> <timeout>
이 명령은 모든 이전 쓰기 명령이 최소한 지정된 복제본 수만큼 성공적으로 전송되고 확인 응답 될 때까지 현재 클라이언트를 차단한다. 지정한 시간 초과에 도달하면 지정한 수의 복제본에 아직 도달하지 않은 경우에도 명령이 리턴된다.

레디스 복제의 특징은 다음과 같다.

  • 레디스는 비동기식 복제를 사용하며, 비동기식 슬레이브-마스터 는 처리되는 데이터의 양을 인식한다.
  • 마스터는 다수의 복제본을 가질 수 있다.
  • 복제본은 다른 복제본에서의 연결을 가질 수 있다. 같은 마스터를 가지고 있는 구조 이외에도, 계단식 구조로 다른 복제본과 수직 연결될 수 있다. 레디스 4.0 이후 모든 하위 복제본(sub-slave)은 마스터로부터 정확히 동일한 복제 스트림을 수신하게 된다.
  • 레디스 복제는 마스터 측에서 차단되지 않는다. 이는 하나 이상의 복제본이 동기화 혹은 부분 비동기화를 수행할 때 마스터는 쿼리를 계속해서 처리할 수 있음을 의미한다.
  • 복제는 복제본에서도 대부분 차단되지 않는다. 복제본에서 초기 동기화를 수행하는 동안은 이전 버전의 데이터셋을 사용해서 쿼리를 수행할 수 있다. 그렇지 않으면 복제 스트림이 중단된 경우 클라이언트에 오류를 반환하도록 레디스 복제본을 구성할 수 있다.(redis.conf의 REPLICA-SERVE-STALE-DATA 파라미터 설정) 하지만 최초 동기화 이후에는 이전 데이터셋을 삭제하는 작업 이 선행된 후 새 데이터셋을 로드한다. 이 짧은 기간 동안은 들어오는 연결이 차단된다 (매우 큰 데이터셋의 경우 몇 초까지 걸릴 수 있음). 레디스 4.0부터는 이전 데이터셋의 삭제가 다른 스레드에서 발생하도록 레디스를 구성할 수 있지만, 초기 데이터셋을 로드하는 건 여전히 메인 스레드에서 발생해서 복제본을 차단할 수 있다.
  • 복제는 read-only 쿼리 (예를 들어, 느린 O(N) 작업은 복제본에서 수행되도록 할 수 있음) 에 대한 다중 복제본을 가지거나, 단순히 데이터 안전 및 HA를 개선하기 위해 모두 사용할 수 있다.
  • 마스터가 디스크에 전체 데이터셋을 쓰도록 하는 비용을 피하기 위해 복제를 사용할 수 있다. 일반적으로는 마스터의 redis.conf를 구성해서 디스크에 지속되지 않도록 한 다음, 때때로 디스크에 저장하도록 구성된 복제본을 연결하거나 AOF를 사용하도록 설정하는 것이 포함된다. 하지만 다시 시작하는 마스터는 빈 데이터셋으로 시작하기 때문에 이 설정은 주의해서 사용되어야 한다. 복제본이 동기화를 시도할 때, 복제본도 비워지게 된다.

마스터 자동 시작과 Persistence 기능 사용

레디스 복제가 사용되는 설정에서는 마스터와 복제본에서 persistence 기능을 켜는 것이 좋다. 예를 들어 디스크 속도가 느려 레이턴시가 발생해서 이 작업이 불가능 한 경우, 재부팅 후 자동으로 다시 시작되지 않도록 인스턴스를 구성해야 한다.

persistence 기능이 꺼진 마스터가 자동 재시작되도록 구성된 상태가 위험한 이유를 이해하기 위해서, 마스터와 모든 복제본에서 데이터가 지워지는 다음의 장애 상황을 확인해보자.

  1. 노드 A가 마스터이고 지속성이 꺼진 상태에서, 노드 B와 C가 A에서 복제되는 환경이다.
  2. 노드 A에서 크래시가 발생하지만, 프로세스를 자동 재시작하는 시스템이 존재하여 리부팅 된다. 하지만 지속성이 꺼져 있어, 노드는 빈 데이터 셋으로 재시작된다.
  3. 노드 B와 C는 비어 있는 노드 A를 복제하므로, 데이터의 사본을 파괴할 것이다.

레디스 센티넬을 HA를 위해 사용할 경우, 프로세스의 자동 재시작을 사용하는것과 마찬가지로 마스터에서 persistence 기능을 끄는 것도 위험하다. 마스터는 센티넬이 장애를 감지하지 못할 정도로 빠르게 재시작하여, 위에서 설명한 장애 상황이 발생할 수 있다.

모든 상황에서 데이터의 안정성이 중요하기 때문에, persistence 기능이 꺼진 마스터에서 복제를 사용할 때마다 인스턴스의 자동 재시작을 비활성해야 한다.

Persistence (지속성)

레디스는 메모리 기반 DB 이기 때문에 전원이 꺼지면 데이타가 모두 날라가게 된다. 이에 파일에 메모리상의 데이타를 저장해두고 redis 서버 실행시 다시 그 파일에서 데이타를 읽어와 메모리상에 올리는 기능을 제공하는데 이를 Persistence (지속성) 라고 한다. 레디스는 RDB 와 AOF 의 두가지 지속성을 제공하고, 두 가지를 함께 사용 가능하다.

레디스의 복제 작동 방식

모든 레디스 마스터는 복제 ID (replication ID)를 가지고 있다. 이는 데이터셋의 특정 스토리를 나타내는 pseudo 랜덤 스트링이다. 각각의 마스터는 데이터셋을 수정하는 새로운 변경사항으로 복제본 상태를 업데이트하기 위해, 생성되는 복제 스트림의 모든 바이트에 대해 증가하는 오프셋을 갖는다. 실제로 연결된 복제본이 없는 경우에도 복제 오프셋이 증가한다.

| Replication ID, offset | | — |

이 정보로 마스터 데이터셋의 정확한 버전을 식별할 수 있다.

복제본이 마스터에 연결되면 그것들은 PSYNC 명령어를 사용해서 그들의 예전 복제 ID와 진행됐던 오프셋을 전달한다. 이렇게 하면 마스터는 필요한 증분 파트만 보낼 수 있다. 그러나 마스터 버퍼에 충분한 백로그(backlog)가 존재하지 않거나, 복제본이 더이상 알 수 없는 기록(복제 ID)를 참조하는 경우엔 전체 재동기화가 발생한다. 이 경우, 복제본은 처음부터 데이터 셋의 전체 사본을 받게 된다.

마스터는 RDB 파일을 생성하기 위해 백그라운드에 저장 프로세스를 실행한다. 동시에 클라이언트로부터 받은 모든 새로운 쓰기 명령을 버퍼링한다. 백그라운드 저장이 완료되면 마스터는 데이터베이스 파일을 복제본으로 전송하여 디스크에 저장한 다음 메모리에 로드한다. 그 다음 마스터는 버퍼링 된 모든 명령을 복제본에게 보낸다. 이것은 명령어 스트림으로 동작하며, 레디스 프로토콜 자체의 형식과 비슷하다.

텔넷을 통해 직접 시도해 볼 수 있다. 서버가 일부 작업을 수행하는 동안 레디스 포트에 연결하고 SYNC 명령을 실행해 보자. 대량 전송이 나타나고, 마스터가 수신한 모든 명령어는 텔넷 세션에서 재발행(re-issued) 되는 것을 볼 수 있다. 실제로 SYNC 는 더이상 새로운 레디스 인스턴스에서 사용되지 않는 오래된 프로토콜이지만, 여전히 역호환성을 위해 존재한다. 이는 부분 재동기화를 허용하지 않기 때문에 PSYNC가 대신 사용된다.

이미 언급했듯이, 복제본은 마스터-슬레이브 링크가 어떤 이유에서든 다운되면 자동으로 다시 연결할 수 있다. 마스터가 여러 개의 동시 복제본 동기화 요청을 수신하는 경우 모든 요청을 처리하기 위해 단일 백그라운드 저장을 수행한다.

복제 ID

앞서 두 인스턴스가 동일한 복제 ID와 오프셋을 가지고 있다면, 그것은 정확히 동일한 데이터를 가지고 있다고 했다. 그러나 복제ID란 무엇이며, 인스턴스에 사실 두 개의 복제 ID (메인 ID와 보조(secondary) ID)가 존재하는 이유에 대해 이해하는 것이 유용하다.

복제ID는 기본적으로 데이터셋의 히스토리 를 기록한다. 인스턴스가 마스터로 처음부터 재시작되거나, 복제본이 마스터로 승격될 때마다 이 인스턴스에 대한 새 복제 ID가 생성된다. 마스터에 연결된 복제본은 핸드셰이크 과정 이후 복제 ID를 상속받는다. 동일한 ID를 가진 두 가지 인스턴스는 동일한 데이터를 가지고 있지만, 잠재적으로 다른 시간에 존재한다는 사실에 의해 관련되어 있다. 이는 가장 최근에 업데이트된 데이터셋을 보유하고 있는 히스토리 (복제 ID)에 대해 이해할 수 있는 논리적 시간으로 작동하는 오프셋이다.

예를 들어, 두 인스턴스 A와 B가 동일한 복제 ID를 가지고 있지만, 하나는 오프셋 1000이고, 다른 하나는 오프셋 1023인 경우, 첫 번째 인스턴스에는 데이터셋에 적용된 특정 커맨드가 없다는 것을 의미한다. 또한 A가 단지 몇 개의 커맨드를 적용함으로써 B의 상태에 정확하게 도달할 수 있는 것을 의미한다.

레디스 인스턴스가 두 개의 복제 ID를 갖는 이유는 마스터로 승격되는 복제본 때문이다. 페일오버 이후 마스터로 승격된 복제본은 복제 ID가 이전 마스터의 것이기 때문에 이전 복제 ID를 계속 기억해야 한다. 이와 같이 다른 복제본들이 새로운 마스터와 동기화 할 때, 그들은 이전의 마스터 복제 ID를 사용해서 부분적인 재동기화를 수행하려고 할 것이다. 왜냐하면, 복제본이 마스터로 승격될 때 당시의 오프셋을 기억하면서 보조 ID를 이전의 주 복제 ID로 설정하기 때문이다. 페일오버 이후 new history가 시작되기 때문에 주 복제 ID는 새로운 랜덤 값을 갖게 된다. 연결 중인 새 복제본을 처리할 때 마스터는 ID와 오프셋을 현재 ID와 보조 ID(안전을 위해 지정된 오프셋까지) 와 일치시킨다. 간단히 말해서, 페일오버 이후, 새로운 마스터에 연결된 복제본은 완전한 동기화를 수행할 필요가 없다는 것을 의미한다.

페일오버 후 마스터로 승격된 복제본이 복제 ID를 변경해야 하는 이유는 일부 네트워크의 파티션으로 인해 이전 버전의 마스터가 여전히 마스터로 작업하고 있을 수 있기 때문이다.동일한 복제 ID를 유지하면 두 인스턴스의 동일한 오프셋이 동일한 데이터 셋을 갖는다는 사실을 위반할 수 있다.

디스크를 사용하지 않는 동기화 (Diskless Replication)

일반적으로 완전 재동기화(full resynchronization)는 디스크에 RDB 파일을 만든 다음, 복제본에게 데이터를 공급하기 위해 디스크에서 동일한 RDB를 다시 로드해야 한다.

느린 디스크의 경우 마스터에게는 이 프로세스가 매우 답답한 작업이 될 수 있다. 레디스 버전 2.8.18은 디스크 없는 복제를 지원하는 첫 번째 버전이다. 이 설정에서 하위 프로세스는 디스크를 중간 저장소로 사용하지 않고 RDB를 직접 복제본으로 전송한다.

복제 구성

기본적인 레디스 복제를 구성하는 것은 간단하다. 아래 내용을 복제본의 redis.conf 파일에 추가하면 된다.

slaveof 192.168.1.1 6379

물론 192.168.1.1 6379를 마스터 IP주소 (또는 호스트 이름)와 포트로 교체해야 한다. 또는 SLAVEOF 명령을 호출하여 마스터 호스트가 복제본과 동기화를 시작할 수 있다.

마스터가 부분 재동기화를 수행하기 위해 사용하는 복제 백로그를 조정하기 위한 파라미터도 몇 가지 존재한다. diskless 복제는 repl-diskless-sync 매개 변수를 사용하여 실행할 수 있다. 첫 번재 복제본 이후에 더 많은 복제본이 도착할 때까지 대기하기 위해 전송을 시작하는 지연은 repl-diskless-sync-delay 매개 변수에 의해 제어된다. 자세한 내용은 Redis 배포와 함께 제공된 redis.conf 의 내용을 참고해라.

읽기 전용 복제본

레디스 2.6 버전 이후 복제본은 기본적으로 읽기 전용 모드를 사용한다. 이 동작은 redis.conf 파일의 slave-read-only 옵션에 의해 제어되며, CONFIG SET 커맨드를 사용하여 런타임 도중에 활성화 및 비활성화를 제어할 수 있다.

읽기 전용 복제본은 모든 쓰기 명령을 거부하므로 실수로 복제본에 쓰는 것이 불가능하다. DEBUG 또는 CONFIG 와 같은 어드민 명령어들이 여전히 사용 가능하기 때문에, 이 기능이 해당 노드를 신뢰할 수 없는 클라이언트가 존재하는 네트워크에 노출하기 위한 것이라고는 할 수 없다. 하지만 read-command 명령을 사용하여 redis.conf 에서 명령을 사용하지 않도록 설정하면 읽기 전용 인스턴스의 보안을 개선할 수 있다.

읽기 전용 기능을 회수하고, 쓰기가 가능한 복제본 인스턴스를 갖는 것이 왜 허용되는지 궁금할 수 있을 것이다. 쓰기 가능한 복제본에서는 로컬 키에 대한 접근이 필요한 오래 걸리는 연산(sorted set 등)을 수행하는 테스트 작업이 가능하다. 복제본과 마스터가 다시 동기화되거나 복제본이 다시 시작되면 이런 테스트 내용이 삭제되기 때문에 편리하다.

그러나 버전 4.0 이전의 쓰기 가능 복제본은 만료 시간이 설정된 키(EXPIRE 명령어 등)를 만료시킬 수 없었다는 점에 유의해야 한다. EXPIRE 또는 최대 TTL 시간을 포함한 명령어를 사용했을 때 그 키는 누출되고, 읽기 명령으로 액세스하는 동안은 키가 보이지 않을 수 있지만, 전체 키 개수에 해당 키가 표시되고 키에 할당된 메모리는 계속 사용되었다. 따라서 일반적으로 쓰기 가능한 복제본과 TTL 키를 혼합하면 문제가 발생할 수 있었다.

레디스 4.0 이상 버전은 이 문제를 해결했고, 이제 쓰기 가능한 복제본은 마스터처럼 TTL 키를 제거할 수 있다.

또한 레디스 4.0부터 복제본에 쓰는 내용은 오직 로컬에서만 유지되며, 해당 인스턴스에 연결된 서브 복제본으로 전파되지 않는다. 서브 복제본은 항상 최상위 마스터가 중간 복제본으로 보낸 것과 동일한 복제 스트림을 전달받는다.

아래와 같이 복제 노드가 세팅되어 있다 하자.

A ---> B ---> C

만약 B가 쓰기 가능일 때, C는 B가 작성한 것을 볼 수 없다. 대신에 마스터 노드인 A와 동일한 데이터셋을 갖는다.

마스터의 인증이 필요한 복제본

만약에 마스터가 requirepass 파라미터를 이용해서 인증 패스워드를 가지고 있다면, 모든 동기화 작업에서 해당 암호를 사용하도록 복제본을 구성하는 것은 간단하다. 실행중인 인스턴스에서 수행하려면 redis-cli에서 다음을 입력해라.

config set masterauth <password>

영구하게 지속하고 싶을 경우에는, config 파일에 아래 설정을 추가해라.

masterauth <password>

N개 이상의 복제본이 연결된 경우에서만 쓰기 허용

레디스 2.8버전부터는 최소한 N개의 복제본이 현재 마스터에 연결되어 있는 경우에만 쓰기를 허용하도록 레디스 마스터를 구성할 수 있다. 그러나 레디스는 비동기 복제를 사용하기 때문에 복제본이 실제로 명령어 스트림을 받았는지 확인할 수 없기 때문에 항상 데이터 손실의 가능성이 있다.

다음은 이 기능의 작동 방식이다.

  • 레디스 복제본은 매 초마다 ping을 소행하여 복제 스트림의 처리량을 확인한다.
  • 레디스 마스터는 모든 복제본으로부터 ping을 받은 마지막 시간을 기억한다.
  • 사용자는 최대 지연시간을 초과하지 않는 복제본의 최소 수를 구성할 수 있다.

지연이 M초 미만인 N개의 복제본이 있어야 쓰기가 허용된다.

이것이 데이터 안전 매커니즘을 위한 최선의 노력이라고 생각할 수 있겠지만, 여기서 데이터의 비손실은 보장되지 않지만, 적어도 데이터 손실의 시간대는 주어진 시간으로 제한된다. In general bound data loss is better than unbound one.

조건이 충족되지 않으면 마스터는 대신 오류로 응답하고, 쓰기는 허용되지 않는다. 이 기능에는 두 가지 관련 파라미터가 존재한다.

min-slaves-to-write <number of slaves>
min-slaves-max-lag <number of seconds>

레디스 복제에서 키를 만료하는 방법

레디스의 키는 제한된 시간 이후에 만료될 수 있다. 이러한 기능은 시간을 계산하는 인스턴스의 능력에 따라 달라지지만, 레디스 복제본은 키가 루아 스크립트를 사용하여 변경되는 경우에도 만료된 키를 올바르게 복제한다.

이러한 기능을 구현하려면 레디스는 마스터와 복제본에서 클럭을 동기화 하는 기능에 의존할 수 없다. 이것은 해결할 수 없는 문제이며, 경쟁 조건 (race condition) 과 데이터 셋의 분리를 초래하므로 레디스는 만료된 키의 복제가 작동하도록 하기 위해 세 가지 주요 기법을 사용한다.

  1. 복제본에서는 키가 만료되지 않고, 대신 마스터가 키를 만료시키기를 기다린다. 마스터가 키를 만료시킬 때 (또는 LRU 에 의해 제거될 때) 모든 복제본에게 DEL 명령어를 합성(synthesize) 한다.

  2. 그러나 때때로 마스터가 제시간에 DEL 명령을 제공할 수 없는 경우에, 복제본에는 이미 논리적으로 만료된 키가 메모리 내에 있을 수 있다. In order to deal with that the slave uses its logical clock in order to report that a key does not exist only for read operations that don’t violate the consistency of the data set (as new commands from the master will arrive). 이런 식으로 복제본은 논리적으로 만료된 키를 보고하는 것을 피할 수 있다. 실용적인 면에서, 복제본을 이용해서 규모를 조정하는 HTML 파편 캐시는 원하는 시간보다 이미 오래된 아이템을 반환하는 것을 피할 것이다.

  3. 루아 스크립트 실행 중 키 만료는 수행되지 않는다. 루아 스크립트가 실행될 때, 개념적으로 마스터의 시간이 동결되어 스크립트가 실행되는 동안 주어진 키가 존재하거나 존재하지 않게 된다. 스크립트 중간에 키가 만료되는 것을 방지하고, 데이터 셋에 동일한 효과가 보장되는 방식으로 동일한 스크립트를 복제본에 전송하기 위해 필요하다.

일단 복제본이 마스터로 승격되면 독립적으로 키를 만료시키기 시작할 것이며, 이전의 마스터로부터 어떠한 도움도 요구하지 않을 것이다.

도커 및 NAT에서의 복제 구성

도커, 혹은 포트 포워딩이나 NAT(Network Address Translation)을 사용하는 다른 유형의 컨테이너를 사용하는 경우, 특히 마스터 INFO 또는 ROLE 명령 출력이 검색되는 레디스 센티넬 또는 다른 시스템을 사용하는 경우, 약간의 주의가 필요하다.

문제는 ROLE 명령과 복제 섹션에 대한 INFO 출력에서 마스터에 연결된 복제본의 IP주소를 보여주는데, 이는 NAT를 사용하는 환경에서 복제본 인스턴스의 논리적 주소(클라이언트가 연결하기 위해 사용해야 하는 주소)와 다를 수 있다는 것이다.

마찬가지로 포트가 재생성되는 경우, 포워딩 포트와 다를 수 있는 redis.conf 에서 구성된 수신 포트로 복제본이 나열될 것이다. 두 가지 문제를 모두 해결하기 위해, 레디스 3.2.2 이후, 아래 내용처럼 복제본이 마스터에게 임의의 IP 와 포트 쌍을 알리도록 강제하는 것이 가능하다.

slave-announce-ip 5.5.5.5
slave-announce-port 1234

INFO, ROLE 명령어

마스터와 복제본 인스턴스의 현재 복제 매개 변수에 대한 많은 정보를 제공하는 레디스 명령어는 두가지가 있다. 복제 인수를 INFO 명령어와 함께 호출하면 복제와 관련된 정보만 표시된다. ROLE 명령어는 마스터와 복제본의 복제 상태를 복제 오프셋, 연결된 복제본 목록등과 함께 제공한다.

재시작 및 페일오버 이후 부분 재동기화

레디스 4.0 이후 장애 조치 이후에 인스턴스가 마스터로 승격될 때, 여전히 이전 마스터의 복제본들과 부분적인 재동기화를 수행할 수 있을 것이다. 이를 위해 복제본은 이전의 복지 IP와 이전 마스터의 오프셋을 기억하기 때문에, 이전 복제 IP를 요청하더라도 백로그의 일부를 연결된 복제본에게 제공할 수 있다.

하지만 승격된 복제본의 새 복제 ID는 데이터셋의 다른 기록을 구성하기 때문에 다를 것이다. 예를 들어 마스터는 사용 가능한 상태로 반환할 수 있으며 한동안 쓰기를 계속 허용할 수 있으므로 승격된 복제본에서 동일한 복제 ID를 사용하면 복제 ID와 오프셋 쌍이 단일 데이터셋만 식별한다는 규칙을 위반할 수 있다.

게다가, 정상적으로 전원을 종료했다가 다시 시작할 때, 복제본은 마스터와 다시 동기화하기 위해 필요한 정보를 RDB파일에 저장할 수 있다. 이것은 업그레이드의 경우에 유용하다. 이 작업이 필요할 때는 복제본에 대해 저장 및 종료 작업을 수행하기 위해 SHUTDOWN 명령을 사용하는 것이 좋다.

AOF 파일을 통해 재시작된 복제본을 부분적으로 다시 동기화하는 것은 올바르지 않다. 하지만 인스턴스 종료 전 RDB persistence 옵션을 켠 후, 재시작을 하고, 마지막으로 AOF를 다시 활성화 할 수 있다.