분류 sql

Redis Replication

컨텐츠 정보

  • 조회 437 (작성일 )

본문

Redis 복제의 기반 (Redis Cluster 또는 Redis Sentinel에서 추가 계층으로 제공되는 고 가용성 기능 제외)에는 리더 팔로워 (마스터-슬레이브) 복제를 사용하고 구성하기가 매우 간단합니다. 복제 Redis 인스턴스가 정확할 수 있습니다. 마스터 인스턴스의 사본. 복제본은 링크가 끊어 질 때마다 자동으로 마스터에 다시 연결되며 마스터에 어떤 일이 발생하든 상관없이 정확한 복제본이 되려고 합니다.


이 시스템은 세 가지 주요 메커니즘을 사용하여 작동합니다.

  • 마스터와 복제본 인스턴스가 잘 연결되면 마스터는 다음과 같은 이유로 인해 마스터 측에서 발생하는 데이터 세트에 미치는 영향을 복제하기 위해 복제본에 명령 스트림을 전송하여 복제본을 업데이트 된 상태로 유지합니다. 클라이언트 쓰기, 키 만료 또는 제거됨, 마스터 데이터 세트를 변경하는 기타 모든 작업.
  • 네트워크 문제로 인해 또는 마스터 또는 복제본에서 시간 초과가 감지되어 마스터와 복제본 간의 링크가 끊어지면 복제본이 다시 연결되고 부분 재 동기화를 진행하려고 시도합니다. 즉, 부품을 가져 오려고 한다는 의미입니다. 연결이 끊기는 동안 놓친 명령 스트림의.
  • 부분 재 동기화가 불가능한 경우 복제본은 전체 재 동기화를 요청합니다. 여기에는 마스터가 모든 데이터의 스냅 샷을 만들고 복제본으로 보낸 다음 데이터 집합이 변경 될 때 명령 스트림을 계속 전송해야 하는 더 복잡한 프로세스가 포함됩니다.

Redis는 기본적으로 짧은 지연 시간과 고성능 인 비동기 복제를 사용하며 대부분의 Redis 사용 사례에서 자연스러운 복제 모드입니다. 그러나 Redis 복제본은 마스터와 주기적으로 수신 한 데이터의 양을 비동기식으로 확인합니다. 따라서 마스터는 복제본이 명령을 처리 할 때마다 매번 기다리지 않지만 필요한 경우 어떤 복제본이 이미 어떤 명령을 처리했는지 알고 있습니다. 이를 통해 선택적 동기 복제를 사용할 수 있습니다.

WAIT 명령을 사용하여 클라이언트에서 특정 데이터의 동기 복제를 요청할 수 있습니다. 그러나 WAIT는 다른 Redis 인스턴스에 지정된 수의 확인 된 복사본이 있는지 확인할 수만 있으며 Redis 인스턴스 집합을 강력한 일관성을 가진 CP 시스템으로 전환하지 않습니다. 확인 된 쓰기는 장애 조치 중에 여전히 손실 될 수 있습니다. Redis 지속성의 정확한 구성. 그러나 WAIT를 사용하면 실패 이벤트 후 쓰기가 손실 될 확률이 트리거 하기 어려운 특정 실패 모드로 크게 감소합니다.

고 가용성 및 장애 조치에 대한 자세한 내용은 Sentinel 또는 Redis 클러스터 설명서를 참조하십시오. 이 문서의 나머지 부분에서는 주로 Redis 기본 복제의 기본 특성을 설명합니다.

다음은 Redis 복제에 대한 몇 가지 매우 중요한 사실입니다.


  • Redis는 비동기식 복제를 사용하며 비동기식 복제 대 마스터는 처리 된 데이터 양을 인식합니다.
  • 복제본은 다른 복제본의 연결을 수락 할 수 있습니다. 여러 복제본을 동일한 마스터에 연결하는 것 외에도, 복제본은 계단식 구조로 다른 복제본에 연결할 수도 있습니다. Redis 4.0부터 모든 하위 복제본은 마스터에서 정확히 동일한 복제 스트림을 받습니다.
  • Redis 복제는 마스터 측에서 차단되지 않습니다. 즉, 하나 이상의 복제본이 초기 동기화 또는 부분 재 동기화를 수행 할 때 마스터가 쿼리를 계속 처리합니다.
  • 복제는 또한 복제 측에서 대부분 비 차단입니다. 복제본이 초기 동기화를 수행하는 동안 redis.conf에서 수행하도록 Redis를 구성했다고 가정하면 이전 버전의 데이터 세트를 사용하여 쿼리를 처리 할 수 ​​있습니다. 그렇지 않으면 복제 스트림이 다운 된 경우 클라이언트에 오류를 반환하도록 Redis 복제본을 구성 할 수 있습니다. 그러나 초기 동기화 후에는 이전 데이터 세트를 삭제하고 새 데이터 세트를로드해야합니다. 복제본은 이 짧은 기간 동안 들어오는 연결을 차단합니다 (매우 큰 데이터 세트의 경우 몇 초까지 걸릴 수 있음). Redis 4.0부터 이전 데이터 세트 삭제가 다른 스레드에서 발생하도록 Redis를 구성 할 수 있지만 새 초기 데이터 세트로드는 여전히 기본 스레드에서 발생하고 복제본을 차단합니다.
  • 복제는 확장 성, 읽기 전용 쿼리 (예 : 느린 O (N) 작업을 복제본으로 오프로드 할 수 있음)를 위해 여러 복제본을 갖기 위해 또는 단순히 데이터 안전 및 고 가용성을 향상 시키기 위해 사용할 수 있습니다.
  • 복제를 사용하여 마스터가 전체 데이터 세트를 디스크에 쓰는 비용을 피할 수 있습니다. 일반적인 기술은 마스터 redis.conf를 구성하여 디스크에 전혀 유지되지 않도록 한 다음 수시로 저장하도록 구성된 복제본을 연결하는 것입니다. , 또는 AOF가 활성화 된 경우. 그러나 다시 시작하는 마스터는 빈 데이터 세트로 시작되므로 이 설정은 주의해서 처리해야 합니다. 복제본이 데이터 세트와 동기화를 시도하면 복제본도 비워집니다.

Safety of replication when master has persistence turned off 


Redis 복제가 사용되는 설정에서는 마스터와 복제본에서 지속성을 켜는 것이 좋습니다. 예를 들어 매우 느린 디스크로 인한 지연 시간 문제로 인해 이것이 가능하지 않은 경우 재부팅 후 자동으로 다시 시작되지 않도록 인스턴스를 구성해야 합니다.

자동 다시 시작하도록 구성된 지속성이 해제 된 마스터가 위험한 이유를 더 잘 이해하려면 마스터 및 모든 복제본에서 데이터가 삭제되는 다음 오류 모드를 확인하십시오.


  • 우리는 노드 A가 마스터로 작동하고 지속성이 해제되고 노드 B와 C가 노드 A에서 복제되는 설정이 있습니다.
  • 노드 A가 충돌하지만 프로세스를 다시 시작하는 일부 자동 다시 시작 시스템이 있습니다. 그러나 지속성이 꺼져 있으므로 노드가 빈 데이터 세트로 다시 시작됩니다.
  • 노드 B와 C는 비어있는 노드 A에서 복제되므로 데이터 사본을 효과적으로 파괴합니다.

Redis Sentinel이 고 가용성을 위해 사용될 때 프로세스의 자동 재시작과 함께 마스터에서 지속성을 끄는 것은 위험합니다. 예를 들어 마스터는 Sentinel이 오류를 감지하지 못할 만큼 충분히 빠르게 다시 시작할 수 있으므로 위에서 설명한 오류 모드가 발생합니다.

데이터 안전이 중요하고 복제가 지속성 없이 구성된 마스터와 함께 사용될 때마다 인스턴스 자동 재시작을 비활성화 해야 합니다.


How Redis replication works 


모든 Redis 마스터에는 복제 ID가 있습니다. 이는 데이터 세트의 주어진 스토리를 표시하는 큰 의사 임의 문자열입니다. 또한 각 마스터는 생성 된 복제 스트림의 모든 바이트에 대해 증가하는 오프셋을 가져 와서 복제본으로 전송하여 데이터 세트를 수정하는 새로운 변경 사항으로 복제본의 상태를 업데이트합니다. 복제 오프셋은 실제로 연결된 복제본이 없는 경우에도 증가하므로 기본적으로 주어진 모든 쌍 :


Replication ID, offset


마스터 데이터 세트의 정확한 버전을 식별합니다. 복제본이 마스터에 연결될 때 이전 마스터 복제 ID와 지금까지 처리 한 오프셋을 보내기 위해 PSYNC 명령을 사용합니다. 이렇게 하면 마스터는 필요한 증분 부분 만 보낼 수 있습니다. 그러나 마스터 버퍼에 충분한 백 로그가 없거나 복제본이 더 이상 알려지지 않은 기록 (복제 ID)을 참조하는 경우 전체 재 동기화가 발생합니다.이 경우 복제본은 데이터 세트의 전체 복사본을 가져옵니다. , 기스로부터. 자세한 내용은 전체 동기화가 작동하는 방식입니다.

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

텔넷을 통해 직접 시도 할 수 있습니다. 서버가 일부 작업을 수행하는 동안 Redis 포트에 연결하고 SYNC 명령을 실행하십시오. 대량 전송이 표시되고 마스터가 수신 한 모든 명령이 텔넷 세션에서 재발행 됩니다. 실제로 SYNC는 최신 Redis 인스턴스에서 더 이상 사용되지 않는 오래된 프로토콜이지만 이전 버전과의 호환성을 위해 여전히 존재합니다. 부분 재 동기화를 허용하지 않으므로 이제 PSYNC가 대신 사용됩니다.

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


Replication ID explained 


이전 섹션에서 두 인스턴스가 동일한 복제 ID와 복제 오프셋을 갖는 경우 정확히 동일한 데이터를 갖는다 고 말했습니다. 그러나 복제 ID가 정확히 무엇인지, 인스턴스에 실제로 두 개의 복제 ID (기본 ID와 보조 ID)가있는 이유를 이해하는 것이 유용합니다.

복제 ID는 기본적으로 데이터 세트의 주어진 기록을 표시합니다. 인스턴스가 마스터로 처음부터 다시 시작되거나 복제본이 마스터로 승격 될 때마다이 인스턴스에 대한 새 복제 ID가 생성됩니다. 마스터에 연결된 복제본은 핸드 셰이크 후 복제 ID를 상속합니다. 따라서 동일한 ID를 가진 두 인스턴스는 동일한 데이터를 보유하지만 잠재적으로 다른 시간에 있다는 사실로 관련됩니다. 가장 많이 업데이트 된 데이터 세트를 보유한 주어진 기록 (복제 ID)에 대해 이해하기 위한 논리적 시간으로 작동하는 오프셋입니다.

예를 들어 두 인스턴스 A와 B가 동일한 복제 ID를 가지고 있지만 하나는 오프셋이 1000이고 다른 하나는 오프셋이 1023이면 첫 번째 인스턴스에는 데이터 세트에 적용된 특정 명령이 없음을 의미합니다. 또한 A가 몇 개의 명령 만 적용하면 B와 정확히 동일한 상태에 도달 할 수 있음을 의미합니다.

Redis 인스턴스에 두 개의 복제 ID가있는 이유는 마스터로 승격 된 복제본 때문입니다. 장애 조치 후 승격 된 복제본은 이전 복제 ID가 이전 마스터 중 하나이기 때문에 이전 복제 ID가 무엇인지 기억해야 합니다. 이러한 방식으로 다른 복제본이 새 마스터와 동기화 될 때 이전 마스터 복제 ID를 사용하여 부분 재 동기화를 수행하려고 합니다. 복제본이 마스터로 승격 될 때이 ID 전환이 발생했을 때 오프셋이 무엇인지 기억하면서 보조 ID를 기본 ID로 설정하기 때문에 예상대로 작동합니다. 나중에 새 기록이 시작되기 때문에 새 임의 복제 ID를 선택합니다. 연결하는 새 복제본을 처리 할 때 마스터는 현재 ID 및 보조 ID (안전을 위해 주어진 오프셋까지)와 모두 해당 ID 및 오프셋을 일치시킵니다. 즉, 장애 조치 후 새로 승격 된 마스터에 연결된 복제본이 전체 동기화를 수행 할 필요가 없음을 의미합니다.

마스터로 승격 된 복제본이 장애 조치 후에 복제 ID를 변경해야 하는 이유가 궁금한 경우 : 일부 네트워크 파티션으로 인해 이전 마스터가 여전히 마스터로 작동 할 수 있습니다. 동일한 복제 ID를 유지하면 두 개의 임의 인스턴스의 동일한 ID 및 동일한 오프셋은 동일한 데이터 세트를 가짐을 의미합니다.


Diskless replication 


일반적으로 전체 재 동기화는 디스크에 RDB 파일을 생성 한 다음 복제본에 데이터를 공급하기 위해 디스크에서 동일한 RDB를 다시 로드해야 합니다.

느린 디스크를 사용하면 마스터에게 매우 스트레스가 되는 작업이 될 수 있습니다. Redis 버전 2.8.18은 디스크 없는 복제를 지원하는 첫 번째 버전입니다. 이 설정에서 하위 프로세스는 디스크를 중간 저장소로 사용하지 않고 유선을 통해 RDB를 복제본으로 직접 보냅니다.


Configuration 


기본 Redis 복제를 구성하는 것은 간단합니다. 복제 구성 파일에 다음 줄을 추가하기 만하면 됩니다.


replicaof 192.168.1.1 6379

물론 192.168.1.1 6379를 마스터 IP 주소 (또는 호스트 이름) 및 포트로 바꿔야 합니다. 또는 REPLICAOF 명령을 호출하면 마스터 호스트가 복제본과 동기화를 시작합니다.


부분 재 동기화를 수행하기 위해 마스터가 메모리에서 가져온 복제 백 로그를 조정하기 위한 몇 가지 매개 변수도 있습니다. 자세한 내용은 Redis 배포와 함께 제공되는 redis.conf 예제를 참조하십시오.

repl-diskless-sync 구성 매개 변수를 사용하여 디스크 없는 복제를 활성화 할 수 있습니다. 첫 번째 복제본 이후에 더 많은 복제본이 도착할 때까지 기다리는 전송 시작 ​​지연은 repl-diskless-sync-delay 매개 변수에 의해 제어됩니다. 자세한 내용은 Redis 배포의 예제 redis.conf 파일을 참조하십시오.


Read-only replica 


Redis 2.6부터 복제본은 기본적으로 활성화 된 읽기 전용 모드를 지원합니다. 이 동작은 redis.conf 파일의 복제본 읽기 전용 옵션으로 제어되며 CONFIG SET을 사용하여 런타임에 활성화 및 비활성화 할 수 있습니다.

읽기 전용 복제본은 모든 쓰기 명령을 거부하므로 실수로 인해 복제본에 쓸 수 없습니다. 이것은 DEBUG 또는 CONFIG와 같은 관리 명령이 여전히 활성화되어 있기 때문에 이 기능이 복제 인스턴스를 인터넷에 노출 시키거나 보다 일반적으로 신뢰할 수 없는 클라이언트가 있는 네트워크에 노출하도록 의도 된 것은 아닙니다. 그러나 rename-command 지시문을 사용하여 redis.conf에서 명령을 비활성화 하면 읽기 전용 인스턴스의 보안을 향상 시킬 수 있습니다.

읽기 전용 설정을 되돌릴 수 있고 쓰기 작업의 대상이 될 수 있는 복제본 인스턴스가 있는 이유가 궁금 할 수 있습니다. 복제본과 마스터가 재 동기화되거나 복제본이 다시 시작되면 이러한 쓰기가 삭제되지만 쓰기 가능한 복제본에 임시 데이터를 저장하는 몇 가지 합법적인 사용 사례가 있습니다. 예를 들어 느린 Set 또는 Sorted 집합 작업을 계산하고 로컬 키에 저장하는 것은 여러 번 관찰 된 쓰기 가능한 복제본의 사용 사례입니다.


그러나 버전 4.0 이전의 쓰기 가능한 복제본은 TTL이 설정된 키를 만료 할 수 없습니다. 즉, EXPIRE 또는 키에 대해 최대 TTL을 설정하는 다른 명령을 사용하면 키가 누출되고 읽기 명령으로 액세스하는 동안 더 이상 볼 수 없지만 키 수와 키 수에서 볼 수 있습니다. 여전히 메모리를 사용합니다. 따라서 일반적으로 쓰기 가능한 복제본 (이전 버전 4.0)과 키를 TTL과 혼합하면 문제가 발생합니다. Redis 4.0 RC3 이상 버전은 이 문제를 완전히 해결하고 이제 쓰기 가능한 복제본은 63보다 큰 DB 번호로 작성된 키를 제외하고 마스터처럼 TTL을 사용하여 키를 제거 할 수 있습니다 (기본적으로 Redis 인스턴스에는 16 개의 데이터베이스 만 있음).

또한 Redis 4.0 복제본 쓰기는 로컬 일 뿐이며 인스턴스에 연결된 하위 복제본으로 전파되지 않습니다. 대신 하위 복제본은 항상 최상위 마스터에서 중간 복제본으로 보낸 것과 동일한 복제 스트림을 받습니다. 예를 들어 다음 설정에서 :

A ---> B ---> C

B가 쓰기 가능하더라도 C는 B 쓰기를 볼 수 없으며 대신 마스터 인스턴스 A와 동일한 데이터 세트를 갖게 됩니다.


Setting a replica to authenticate to a master 


마스터에 requirepass를 통한 암호가 있는 경우 모든 동기화 작업에서 해당 암호를 사용하도록 복제본을 구성하는 것은 간단합니다.


실행 중인 인스턴스에서 이를 수행하려면 redis-cli를 사용하고 다음을 입력합니다.

config set masterauth <password>

영구적으로 설정하려면 다음을 구성 파일에 추가하십시오.

masterauth <password>

Allow writes only with N attached replicas 


Redis 2.8부터는 현재 최소 N 개의 복제본이 마스터에 연결된 경우에만 쓰기 쿼리를 허용하도록 Redis 마스터를 구성 할 수 있습니다.

그러나 Redis는 비동기식 복제를 사용하기 때문에 복제본이 실제로 주어진 쓰기를 받았는지 확인할 수 없으므로 항상 데이터 손실 창이 있습니다.

기능이 작동하는 방식은 다음과 같습니다.


  • Redis 복제본은 처리 된 복제 스트림의 양을 확인하면서 매초마다 마스터를 핑합니다.
  • Redis 마스터는 모든 복제본에서 마지막으로 핑을 수신 한 시간을 기억합니다.
  • 사용자는 지연이 최대 시간 (초)보다 크지 않은 최소 복제본 수를 구성 할 수 있습니다.

M 초 미만의 지연이 있는 복제본이 N 개 이상 있으면 쓰기가 허용됩니다. 주어진 쓰기에 대해 일관성이 보장되지 않지만 최소한 데이터 손실 시간이 주어진 시간 (초)으로 제한되는 최선의 데이터 안전 메커니즘이라고 생각할 수 있습니다. 일반적으로 바인딩 된 데이터 손실은 바인딩 되지 않은 데이터 손실보다 낫습니다.

조건이 충족되지 않으면 마스터는 대신 오류로 응답하고 쓰기가 허용되지 않습니다. 이 기능에 대한 두 가지 구성 매개 변수가 있습니다.


  • min-replicas-to-write <복제본 수>
  • min-replicas-max-lag <초 수>

자세한 내용은 Redis 소스 배포와 함께 제공되는 예제 redis.conf 파일을 확인하십시오.


How Redis replication deals with expires on keys 


Redis가 만료되면 키가 제한된 TTL (Time to Live)을 가질 수 있습니다. 이러한 기능은 인스턴스가 시간을 계산하는 기능에 따라 달라 지지만 Redis 복제본은 Lua 스크립트를 사용하여 키가 변경된 경우에도 만료 된 키를 올바르게 복제합니다.

이러한 기능을 구현하기 위해 Redis는 마스터 및 복제본이 클럭을 동기화 하는 능력에 의존 할 수 없습니다. 이는 해결할 수 없는 문제이고 경쟁 조건과 데이터 세트 발산을 초래할 수 있으므로 Redis는 다음과 같은 세 가지 주요 기술을 사용합니다. 만료 된 키의 복제가 작동 할 수 있도록 합니다.


  • 복제본은 키를 만료 하지 않고 마스터가 키를 만료 할 때까지 기다립니다. 마스터가 키를 만료 (또는 LRU 때문에 제거)하면 모든 복제본으로 전송되는 DEL 명령을 합성합니다.
  • 그러나 마스터 기반 만료로 인해 마스터가 제때에 DEL 명령을 제공 할 수 없었기 때문에 때때로 복제본이 이미 논리적으로 만료 된 메모리 키에있을 수 있습니다. 이를 처리하기 위해 복제본이 논리적 시계를 사용하여 데이터 세트의 일관성을 위반하지 않는 읽기 작업에만 키가 존재하지 않는다고 보고 합니다 (마스터의 새 명령이 도착할 때). 이러한 방식으로 복제본은 논리적으로 만료 된 키가 여전히 존재한다고 보고 하지 않습니다. 실제적으로 복제를 사용하여 크기를 조정하는 HTML 조각 캐시는 원하는 수명보다 이미 오래된 항목을 반환하지 않습니다.
  • Lua 스크립트 실행 중에는 키 만료가 수행되지 않습니다. Lua 스크립트가 실행되면 개념적으로 마스터의 시간이 고정되어 스크립트가 실행되는 동안 주어진 키가 존재하거나 존재하지 않게 됩니다. 이렇게 하면 스크립트 중간에 키가 만료되는 것을 방지하고 데이터 세트에서 동일한 효과를 보장하는 방식으로 복제본에 동일한 스크립트를 전송하는 데 필요합니다.

복제본이 마스터로 승격되면 키가 독립적으로 만료되기 시작하며 이전 마스터의 도움이 필요하지 않습니다.


Configuring replication in Docker and NAT 


Docker 또는 포트 전달을 사용하는 다른 유형의 컨테이너 또는 네트워크 주소 변환이 사용되는 경우 Redis 복제는 특히 Redis Sentinel 또는 복제본을 검색하기 위해 마스터 INFO 또는 ROLE 명령 출력이 스캔되는 기타 시스템을 사용할 때 약간의 주의가 필요합니다. 구애.

문제는 ROLE 명령과 INFO 출력의 복제 섹션이 마스터 인스턴스로 발행 될 때 복제본이 마스터에 연결하는 데 사용하는 IP 주소를 갖는 것으로 표시한다는 것입니다. 이는 NAT를 사용하는 환경에서 비교 될 수 있습니다. 복제본 인스턴스의 논리적 주소 (클라이언트가 복제본에 연결하는 데 사용해야 하는 주소).

사하게 복제본은 redis.conf에 구성된 수신 대기 포트와 함께 나열되며 포트가 다시 매핑 되는 경우 전달 된 포트와 다를 수 있습니다.

두 가지 문제를 모두 해결하기 위해 Redis 3.2.2부터 복제본이 임의의 IP 및 포트 쌍을 마스터에 알리도록 강제 할 수 있습니다. 사용할 두 가지 구성 지시문은 다음과 같습니다.

replica-announce-ip 5.5.5.5
replica-announce-port 1234

그리고 최근 Redis 배포판의 redis.conf 예제에 설명되어 있습니다.


The INFO and ROLE command 


마스터 및 복제본 인스턴스의 현재 복제 매개 변수에 대한 많은 정보를 제공하는 두 가지 Redis 명령이 있습니다. 하나는 정보입니다. 복제 인수를 INFO 복제로 사용하여 명령을 호출하면 복제와 관련된 정보 만 표시됩니다. 컴퓨터에 더 친숙한 또 다른 명령은 복제 오프셋, 연결된 복제본 목록 등과 함께 마스터 및 복제본의 복제 상태를 제공하는 ROLE입니다.


Partial resynchronizations after restarts and failovers 


Redis 4.0부터는 장애 조치 후 인스턴스가 마스터로 승격 될 때 이전 마스터의 복제본과 부분적인 재 동기화를 수행 할 수 있습니다. 이를 위해 복제본은 이전 복제 ID와 이전 마스터의 오프셋을 기억하므로 이전 복제 ID를 요청하더라도 연결 복제본에 백 로그의 일부를 제공 할 수 있습니다.

그러나 승격 된 복제본의 새 복제 ID는 데이터 세트의 다른 기록을 구성하므로 달라집니다. 예를 들어 마스터는 사용 가능 상태를 반환하고 일정 시간 동안 쓰기를 계속 허용 할 수 있으므로 승격 된 복제본에서 동일한 복제 ID를 사용하면 복제 ID 및 오프셋 쌍의 a가 단일 데이터 세트 만 식별한다는 규칙을 위반하게 됩니다.

더욱 이 복제본은 전원을 껐다가 다시 시작할 때 마스터와 재 동기화 하는 데 필요한 정보를 RDB 파일에 저장할 수 있습니다. 이는 업그레이드시 유용합니다. 이것이 필요한 경우 복제본에서 저장 및 종료 작업을 수행하기 위해 SHUTDOWN 명령을 사용하는 것이 좋습니다.

AOF 파일을 통해 다시 시작된 복제본을 부분적으로 재 동기화 할 수 없습니다. 그러나 인스턴스를 종료하기 전에 다시 시작할 수 있는 것보다 RDB 지속성으로 전환 할 수 있으며 마지막으로 AOF를 다시 활성화 할 수 있습니다.