[Redis] Redis Replication(복제)

번역 페이지

https://redis.io/topics/replication

Replication – Redis

 레디스의 Replication 기반은 leader follower replication으로 구성되며 사용 방법이 아주 간단합니다. 

 (leader follower replication : master-slave 형태)

 이 방식은 복제본 레디스 인스턴스가 마스터 인스턴스의 정확한 사본이 되도록 합니다.

 복제본이 마스터와 연결이 끊어지면 자동으로 재 연결하고 마스터가 어떻든간에 정확한 사본이 되기 위한

 작업을 시도합니다. 

 이 시스템은 3가지의 주요 매커니즘을 사용합니다. 

 1. 마스터와 복제본 인스턴스들이 잘 연결이 되어 있을 때는 마스터는 클라이언트 쓰기 작업, 키의 기한만료 또는 제거

    같은 마스터의 dataset에 변경을 가하는 모든 작업들로 인해서 마스터에서 발생하는 dataset에 대한 변화를

    복제하기 위해 명령어 스트림을 복제본에 전송해서 업데이트된 상태를 유지합니다.

 2. 네트워크 문제 또는 시간 초과가 감지되서 마스터와 복제본간의 연결이 끊어 졌을 때 복제본은 재 연결하고 

    부분 재동기화를 진행하려고 시도합니다. 

    부분 재동기화는 연결이 끊어진 동안의 손실된 명령 스트림을 얻으려고 시도하는 것을 말합니다.

 3. 부분 재동기화가 불가능하다면 복제본은 전체 재동기화를 요청할 것입니다. 

    전체 재동기화는 마스터가 모든 데이터에 대한 스냅샷을 생성하고 복제본에 전송한 다음에 dataset이 변경되면

    명령 스트림을 계속 보내는 복잡한 과정을 수반합니다. 

 레디스는 기본적으로 낮은 지연과 높은 성능을 가진 비동기 Replication을 사용하고 대부분의 레디스 사용 사례에서의

 일반적인 모드입니다. 

 레디스 복제본은 마스터와 주기적으로 수신한 데이터를 비동기적으로 승인합니다. 

 그래서 마스터는 복제본이 명령에 대한 처리를 매번 기다리지 않습니다.

 그러나 필요한 경우 복제본이 어떤 명령을 처리했는지 알 수 있습니다.  선택적으로 동기식 replication도 가능합니다.

 특정 데이터의 동기식 replication은 클라이언트에서 WAIT 명령어를 사용해 요청할 수 있습니다.

 WAIT는 다른 레디스 인스턴스에 승인된 사본의 명시적인 수만 확인 할 수 있습니다. 

 strong consistency의 CP System안에서 레디스 인스턴스의 셋팅을 변경하지 않습니다. 

 승인된 쓰기 작업도 레디스 영속성의 구성에 따라서 failover되는 동안 손실 될 수 있습니다.

 ( ※ failover : 시스템 장애시 대체본으로 자동으로 변경되어서 장애를 극복하는 것을 말합니다.)

 그러나 WAIT는 장애 후에 쓰기 작업을 잃어 버릴 확률이 failure mode를 발동이 어려워져 크게 줄어 듭니다. 

 높은 가용성과 failover에 대해서 더 많은 정보를 얻으려면 Sentinel 또는 Redis Cluster 문서를 확인 할 수 있습니다. 

 이 문서의 나머지 부분은 주로 레디스의 Replication의 기본적인 특성에 대해서 설명합니다. 

 

 다음은 레디스 Replication에 대한 몇가지 중요한 사항들입니다. 

 ▶ 레디스는 비동기 replication을 사용하고 처리된 데이터 양을 비동기적으로 승인합니다. 

 ▶ 마스터는 여러대의 복제본을 가질 수 있습니다. 

 ▶ 복제본은 다른 복제본의 접속을 수락 할 수 있습니다. 동일한 마스터에 여러 복제본을 연결하는 것 이외에도

     복제본도 계단식 구조로 다른 복제본과 연결 될 수 있습니다. 

     레디스 4.0 부터 모든 하위 복제본들은 마스터로 부터 동일한 replication 스트림을 정확히 전달 받습니다. 

 ▶ 레디스 Replication은 마스터 입장에서는 non-blocking입니다. 마스터는 하나의 이상의 복제본이

     초기 동기화 및 부분 재동기화를 수행될 때도 요청에 대한 처리를 계속 할 수 있다는 것을 의미합니다. 

 ▶ Replication은 복제본 입장에서도 대부분은 non-blocking입니다. 복제본이 초기 동기화를 수행하는 동안 

     redis.conf에서 레디스를 수행하도록 설정 했다면 이전 버전의 dataset을 사용해서 요청을 처리 할 수 있습니다.

     그렇지 않으면 replication이 중단 된 경우에 클라이언트에 에러를 반환하도록 레디스 복제본의 설정할 수 있습니다. 

     초기 동기화를 수행된 후에 이전의 dataset을 삭제 해야 하며 새로운 dataset을 로드해야 합니다. 

     복제본은 이 짧은 기간동안 들어오는 접속을 차단합니다.(dataset이 매우 큰 경우 몇 초가 걸릴 수 있습니다.)

     레디스 4.0부터 이전 dataset의 삭제를 다른 스레드에서 수행하도록 레디스를 구성할 수 있습니다. 

     그러나 새롭게 초기화된 dataset을 읽어들이는 것은 메인 스레드에서 수행하고 복제본을 block합니다. 

 ▶ Replication은 읽기 전용을 위한 여러개의 복제본을 만들거나 데이터 안전성과 높은 가용성을 개선하기 위해서

     사용 할 수 있습니다.

 ▶ 마스터가 디스크에 전체 dataset을 쓰는 비용을 피하기 위해서 replication을 사용 할 수 있습니다. 

     일반적인 기법은 디스크에 대해 영속성이 기록되지 않도록 마스터의 redis.conf를 설정하고 연결된 복제본의

     AOF를 활성화하거나 RDB를 저장하도록 구성하는 것입니다.

     그러나 이 설정에서 마스터의 재시작은 빈 dataset으로 시작하기 때문에 조심히 다루어야 합니다. 

     만약에 이상태에서 복제본이 동기화를 시도하면 복제본도 빈상태가 됩니다.

 

마스터의 영속성이 꺼져 있을 때 replication의 안전성

 레디스에서 replication을 사용할 때는 마스터와 복제본의 영속성을 키는 것을 강력히 권장합니다. 

 예를 들어서 느린 디스크로 인한 지연 문제 때문에 마스터의 영속성을 키는 것이 불가능하다면 인스턴스가

 재부팅 후에 자동으로 재시작하지 않도록 구성해야합니다. 

 마스터의 영속성이 꺼진 설정에서 재시작이 위험한 이유를 더 잘 이해하려면 마스터와 모든 복제본의 데이터가

 삭제되는 다음에 실패 모드를 살펴보세요

1. 노드 A는 영속성이 꺼진 마스터 역활을 맡고 노드 B와 C는 노드 A에서 복제 됩니다. 
2. 노드 A가 중단되면 자동 재시작 시스템이 있어서 프로세스가 재시작 됩니다.
3. 노드 B와 C는 비어 있는 노드 A에서 복제 되므로 그들이 가진 데이터 사본이 파괴 될 것입니다.

 높은 가용성을 위해서 레디스 Sentinel을 사용할 때 프로세스이 자동 재시작과 마스터의 영속성을 끄는 것

 또한 위험합니다.  예를 들어서 Sentinel이 장애를 감지 하지 못할 정도로 마스터가 빠르게 재시작 할 수 있으므로

 위에서 설명한 장애 모드가 발생합니다.

 데이터 안전성이 중요하고 마스터의 영속성의 설정 없이 replication을 사용 할 때는 인스턴스의 재시작을 비활성화

 해야합니다. 

 

Redis 복제 작동 방식

 모든 레디스 마스터는 replication ID를 가집니다. 주어진 dataset을 표시하는 큰 가상의 임의의 문자열입니다. 

 각 마스터는 dataset을 수정하는 새로운 변경 사항을 복제본에 업데이트 하기 위해 전송되는 replication stream의

 바이트 수만큼 증가하는 offset을 가집니다. 

 실제로 복제본이 연결되지 않는 경우에도 복제 offset이 증가하므로 기본적으로 모든 주어진 쌍은 다음과 같습니다. 

Replication ID, offset

 이것으로 마스터의 dataset의 정확한 버전을 확인 합니다. 

 복제본들이 마스터에 접속되면 이전 마스터 복제ID와 지금까지 처리한 오프셋을 보내기 위해서

 PSYNC 명령어를 사용합니다. 이 방법 으로 마스터는 필요한 부분만 보낼 수 있습니다.

 그러나 마스터의 버퍼에 백로그가 충분하지 않거나 복제본이 알수 없는 Replication ID를 참조하는 경우에

 전체 동기화가 발생합니다. 이경우에 복제본은 dataset의 전체 사본을 전달 받습니다.

 

 전체 동기화 작동 방식에 대한 자세한 내용 :

 마스터는 RDB 파일을 생성하기 위해서 백그라운드 저장 프로세스를 실행합니다. 동시에 클라이언트에게 전달받은

 새로운 모든 쓰기 작업을 버퍼에 저장하기 시작합니다. 

 백그라운드 저장이 완료되면 마스터는 그것을 디스크에 저장 한 후에 메모리에 적재하고 복제본에

 데이터베이스 파일 전달합니다. 그후에 마스터는 버퍼에 저장한 모든 명령을 복제본으로 보냅니다. 

 이것은 명령어 스트림으로 수행되고 레디스 프로토콜과 동일한 형식입니다. 

 텔넷을 통해서 전체 동기화를 해볼 수 있습니다.

 서버가 수행될 때 레디스의 포트로 접속해서 SYNC 명령어를 실행하세요

 대량의 데이터가 전송되고 텔넷 세션에서 마스터가 수신한 모든 명령을 다시 받습니다. 

 실제로 SYNC는 새로운 레디스 인스턴스에 더 이상 사용하지 않는 오래된 프로토콜이지만 하위 호환성을 위해서

 존재합니다. 이것은 부분 동기화를 지원하지 않아서 대신에 PSYNC를 사용합니다. 

 

 이전에 말했듯이 어떠한 이유로 마스터와 복제본간의 연결이 끊겼을 때 복제본은 자동으로 재연결할 수 있습니다. 

 만약에 마스터가 동시에 여러개의 복제본에게 동기화 요청을 받는다면 그들에게 전달하기 위해서 

 단일 백그라운드로 저장을 수행합니다. 

 

Replication ID 설명

 이전 섹션에서 두 인스턴스가 같은 replication ID와 replication offset을 가진다면 그둘은 동일한 데이터를 가진다고 

 말했습니다.  Replication ID는 정확히 무엇이고 왜 인스턴스가 main ID와 secondary ID를 가지는지를 

 이해하는 것이 유용합니다.

 replication ID는 기본적으로 dataset의 기록을 나타냅니다. 인스턴스가 처음부터 마스터로 시작하거나

 복제본이 마스터로 승격 될 때마다 인스턴스를 위한 새로운 replication ID가 생성됩니다. 

 마스터에 연결된 복제본은 연결 수립 후에 replication ID를 상속 받습니다.

 동일한 ID를 가지는 두 인스턴스는 같은 데이터를 보유하지만 잠재적으로 다른 시간을 가질 수 있다는 사실과 관련

 있습니다. offset은 가장 최근에 업데이트 된 dataset의 기록을 알기 위해서 논리적 시간으로 동작합니다. 

 예를 들면 두 인스턴스 A와 B는 같은 replication ID를 가지지만 하나는 1000 offset을 가지고 하나는 1023의 offset을

 가진다면 첫번째 인스턴스에 dateset에 적용되어야 할 명령어가 부족하다는 것을 뜻합니다.

 또한 몇개의 명령어를 A에 적용하면 B와 완전히 동일해 질 수 있다는 것을 뜻합니다.

 레디스가 두개의 replication ID를 가지는 이유는 복제본이 마스터로 승격할 수 있기 때문입니다.

 failover 후에 마스터로 승격된 복제본은 이전 마스터의 replication ID를 기억 해야 합니다.

 이러한 방식으로 다른 복제본이 새로운 마스터에 동기화를 요청 할 때 이전 마스터의 replication ID를 가지고

 부분 재동기화를 수행하려고 시도할 것입니다.

 복제본이 마스터로 승격되면 Secondary ID를 Main ID로 설정하고 이 전환시 offset을 기억하기 때문에 예상대로

 작동합니다. 이후에 새로운 기록이 시작되면 새로운 임의의 replication ID를 선택합니다. 

 연결하는 새로운 복제본들을 처리 할 때 마스터는 현재의 ID와 secondary ID를 복제본과 일치시킵니다. 

 간단히 말해서 failover후에 승격된 마스터에 연결한 복제본들은 전체 동기화를 수행할 필요가 없습니다.

 failover후에 마스터로 승격된 복제본의 replication ID의 변경이 왜 필요한 이유는 다음과 같습니다.

 어떤한 네트워크 분리로 인해서 이전 마스터가 동작 중일 가능성이 있습니다.

 동일한 replication ID가 운영된다면 동일한 ID와 동일한 offset을 가진 두 임의 인스턴스는 같은 dataset을 

 가져야 한다는 사실을 위반합니다.

 

디스크 없는 replication 

 보통 전체 재동기화를 수행하려면 디스크에 RDB파일을 생성한 다음 복제본에게 데이터를 보내 주기 위해서 

 RDB파일을 다시 로드합니다. 

 디스크의 속도가 느리다면 마스터에게 매우 스트레스 받는 작업이 될 수 있습니다. 

 레디스 2.8.18 버전은 디스크 없는 replication을 지원하는 첫번째 버전입니다. 

 이 설정에서 자식 프로세스는 디스크를 중간 저장소로 사용하지 않고 복제본과의 연결을 통해 RDB를 바로 전송합니다.

 

설 정

 기본 레디스 replication을 설정하는 것은 간단합니다. 복제본 구성 파일에 다음 줄을 추가하면 됩니다. 

replicaof 192.168.1.1 6379

 물론 192.168.1.1 6379를 마스터의 IP와 port로 변경 해야 합니다.

 다른 방법으로는 REPLICAOF 명령어와 마스터의 호스트 정보를 호출하면 복제본은 동기화를 시작합니다. 

 마스터가 메모리에서 가져온 백로그를 조정해서 부분 재동기화를 수행하기 위한 몇 가지 파라미터가 있습니다. 

 자세한 내용은 레디스 배포시 제공되는 redis.conf 예제를 참조하세요

 디스크 없는 replication은 repl-diskless-sync 설정 파라미터를 사용해서 활성화 할 수 있습니다. 

 첫번째 복제본을 받은 후에 다음 복제본에게 전송을 시작하기 위한 지연을 설정하기 위해서 repl-diskless-sync-delay를 

 사용해서 제어합니다. 자세한 내용은 레디스 배포시 제공되는 redis.conf 예제를 참조하세요.

 

읽기 전용 복제본

 레디스가 2.6버전부터 기본 설정으로 read-only모드가 활성화된 복제본을 지원합니다.

 이 동작은 redis.conf 파일에 replica-read-only 옵션을 통해서 관리하고 실행중에서는 CONFIG SET을 사용해서

 활성화 여부를 설정할 수 있습니다.

 읽기 전용 복제본은 쓰기 명령어를 거부하기 때문에 실수로 인한 복제본에 쓰기 작업을 방지합니다. 

 인터넷 또는 일반적으로 신뢰할 수 없는 클라이언트가 있는 네트워크에 노출 시키는 작업은 DEBUG나 CONFIG와 같은

 관리용 명령어를 통해서 활성할 수 있기 때문에 읽기 전용 복제본은 이러한 기능을 지원하기 위한 목적이 아닙니다.

 하지만 redis.conf의 rename-command를 사용해서 명령을 비활성화하면 읽기 전용 인스턴스의 보안을

 향상 시킬 수 있습니다.

 읽기 전용 설정을 되돌려서 쓰기 작업이 가능한 복제본 인스턴스가 있는 이유가 궁금할 수 있습니다. 

 복제본과 마스터가 재동기화를 하거나 복제본이 재시작하면 쓰기 가능한 복제본들이 쓴 작업이 폐기되지만

 쓰기 작업의 임시 데이터를 저장하기 위한 몇가지 방법이 있습니다. 

 예를 들어서 느린 작업인 Set또는 Sorted set 작업을 연산하고 로컬 키에 저장하는 것은 여러 사례에서 확인된

 쓰기 가능한 복제본의 사용방법 입니다. 

 그러나 레디스 4.0 이전 버전에서는 쓰기 가능한 복제본은 시간이 설정된 키를 만료 시킬 수 없었습니다. 

 만약에 EXPIRE나 다른 명령어를 사용해서 TTL이 완료된 키에 적용하면 키는 유실되며 그것을 읽기 명령으로

 확인 할 수 없지만 메모리를 사용하고 키가 카운팅이 됩니다. 

 일반적으로 레디스 4.0 이전 버전에서는 쓰기 가능한 복제본과 TTL을 가진 키를 혼합해서 사용하면 문제가 됩니다. 

 레디스 4.0 RC3보다 높은 버전에서는 이 문제가 해결되었고 이제 쓰기 가능한 복제본은 마스터처럼 TTL을 사용해서 

 키를 제거 할 수 있습니다. DB 번호가 63보다 큰 것에 쓰여진 키를 제외하지만 기본적으로 레디스 인스턴스는

 16개의 데이터베이스를 가집니다.

 레디스 4.0 부터 복제본의 쓰기 작업은 로컬 전용이므로 인스턴스에 연결된 하위 복제본에 전파되지 않습니다. 

 대신에 하위 복제본은 언제나 최상위 마스터가 중간의 복제본으로 보내는 것과 동일한 스트림을 전달 받습니다. 

 예를 들어서 다음 설정에서 

A ---> B ---> C

 B가 쓰기 가능 복제본이면 C는 B가 작성한 것을 볼 수 없고 대신에 A인스턴스와 동일한 dataset을 전달받습니다. 

  
마스터 인증을 위한 복제본 셋팅

 만약에서 마스터가 requirepass를 통해서 비밀번호를 가진다면 모든 동기화 작업에 패스워드를 사용하도록 복제본을 

 구성하는 것을 어렵지 않습니다. 

 실행중인 인스턴스에서 이를 수행하려면 redis-cli을 사용해서 다음을 입력하세요

config set masterauth <password>

 영구적으로 셋팅하려면 아래 내용을 설정파일에 추가 하세요

masterauth <password>

 

N개로 연결되었을 때 쓰기 작업 허용

 레디스 2.8 버전 부터 N개 이상의 복제본이 마스터에 연결된 경우에만 쓰기 쿼리를 수락하도록 레디스 마스터를

 구성  할 수 있습니다. 

 레디스는 비동기 replication을 사용하기 때문에 복제본이 실제로 쓰기 데이터를 받았는지 확인 할 수 없으므로

 데이터가 손실 될 가능성이 있습니다. 

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

 ▶ 레디스 복제본은 매초마다 마스터에게 ping을 보내서 처리된 replication 스트림을 승인합니다. 

 ▶ 레디스 마스터는 모드 복제본에게 마지막에 받은 ping 시간을 기억합니다. 

 ▶ 사용자는 최대 지연시간보다 작은 지연 시간을 가지는 최소 복제본의 숫자를 설정할 수 있습니다. 

 지연시간이 M초 미만인 N개 이상의 복제본이 있으면 쓰기 작업이 허용됩니다.  

 주어진 쓰기 작업 완전한 일광성을 보장하지 못하지만 데이터의 손실을 지정된 시간으로 제한되는 것이

 최소한의 노력으로 얻을 수 있는 최선의 데이터 안전 매커니즘이고 생각 할 수 있습니다. 

일반적으로 bound 데이터의 손실이 unbound 데이터보다 더 문제가 되지 않습니다. 

 ( bounded 데이터는 저장되고 나서 더 이상 증가나 변경이 없이 유지 되는 데이터를 말하며

  unbounded 데이터는 데이터 수가 정해져 있지 않고 계속 추가나 변경되는 데이터를 말합니다.)

 조건이 충족되지 않으면 마스터는 오류를 응답하고 쓰기가 허용되지 않습니다. 

 이 기능을 위한 두가지 파라미터가 있습니다. 

• min_replicas-to-write <복제본의 수>
• min-replicas-max-lag <초 단위 수>

 더 많은 정보를 원하면 레디스 배포시 제공되는 redis.conf 예제를 참조하세요

 

레디스의 replication이 만료된 key를 처리하는 방법 

 레디스의 expire가 설정된 키는 제한 수명을 가집니다.

 이 기능은 인스턴스가 시간을 계산하는 능력에 종속되지만 레디스 복제본은 만료된 키를 정확히 복제하는데 

 lua 스크립트를 사용 할 때도 가능합니다. 

 이 기능을 구현하기 위해서는 레디스는 마스터와 복제본의 클럭 동기화 기능에 의존 할 수 없습니다.

 왜냐하면 이것은 해결할 수 없는 문제이고 레이스 컨디션(경쟁 상태)과 dataset 분기가 발생할 것이기 때문입니다.

 그래서 레디스는 replication에서 만료된 키에 대한 작업을 위해서 3가지 기법을 사용합니다.

  1. 복제본은 키를 만료 하지 않고 대신에 마스터가 키를 만료하는 것을 기다립니다. 마스터가 키를 만료하면 DEL명령을

     합성해서 모든 복제본에 전송합니다. 

  2. 그러나 마스터 주도의 expire 작업에서는 DEL명령어를 제 시간에 제공 할 수 없을 수 있기 때문에 복제본은

     이미 논리적으로 만료된 키를 메모리에 가지고 있을 수도 있습니다. 

     이것을 처리하기 위해서 복제본은 dataset의 일관성을 위반하지 않는 읽기 작업에만 키가 존재하지 않는다고 

     알리기 위해서 logical clock을 사용합니다. 이 방식으로 복제본에 존재하는 논리적으로 만료된 키가

     보고되지 않도록 합니다.

     실제로 복제본을 사용하여 확장하는 HTML 조각 캐시는 원하는 수명보다 오래된 항목을 반환하지 않습니다.

   3. lua 스크립트가 수행되는 동안 키의 만료는 수행되지 않습니다. lua 스크립트가 수행 될 때 개념적으로 마스터의

      시간은 멈춘다고 생각하기 때문에 주어진 키는 스크립트가 수행되는 모든 시간에 존재하거나 존재하지 않습니다. 

      이것은 스크립트 중간에 키가 만료되는 것을 방지하고 dataset에 같은 효과가 발생되도록 보장하는 동일한

      스크립트를 복제본에 전송하기 위해서 필요합니다. 

※ Logical clock은 분산 시스템에 완벽한 시간이 존재하지 않기 때문에 발생한 이벤트의 인과 관계(순서)만 체크하는 것 

 

Docker와 NAT 안에서 replication 구성

 Docket나 다른 타입의 container를 사용해서 포트 포워딩을 사용하거나 NAT를 사용 할 때 레디스의 replication에 대한 

 약간의 주의가 필요하고 레디스 sentinel이나 마스터의 INFO또는 ROLE 명령의 출력의 스캔해서 복제본의 주소를 

 찾는 시스템의 경우 특히 더 주의 해야 합니다. 

 마스터 인스턴스의 ROLE 명령과 INFO의 replication 섹션의 출력은 마스터와 연결에 사용된 복제본이 가진 IP 주소를

 보여주는데 NAT환경에서는 복제본 인스턴스의 논리적 주소와 다를 수 있어서 문제입니다. 

 이와 비슷하게 복제본은 redis.conf 설정안에서 listening port와 함께 나열되고 포트가 재맵핑 된 경우에 전달된 포트와 

 다를 수 있습니다. 

 이 두가지 문제를 해결하기 위해서 레디스 3.2.2.버전부터는 복제본은 임의의 IP와 포트를 마스터에게 알릴수 있습니다.

 두 명령어는 다음과 같이 사용할 수 있습니다.

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

최신 배포된 레디스의 redis.conf 예제 안에 문서화 되어 있습니다. 

 

INFO와 ROLE 명령

 두 레디스 명령어는 마스터와 복제본 인스터스들의 현재의 replication 파라미터 정보에 대한 많은 정보를 제공합니다. 

 replication 인자와 같이 INFO를 호출하면 오직 replication에 관련이 있는 정보만 출력됩니다. 

 또 다른 명령은 컴퓨터 친화적인 ROLE인데 마스터와 복제본의 replication offset, 연결된 복제본 리스트 등등의

 replication의 상태를 제공합니다. 

 

재시작 후의 부분 재동기화와 failover

 레디스 4.0 부터 failover 후에 인스턴스가 마스터로 승격될 때 새로운 마스터는 이전 마스터의 복제본들의

 부분 재동기화를 수행 할 수 있습니다.

 이것을 수행하기 위해서 복제본은 이전 마스터의 replication ID와 offset을 기억합니다. 

 그래서 연결된 이전 마스터의 복제본들이 이전 replication ID를 요청하더라도 백로그의 일부분을 제공할 수 있습니다.

 그러나 승격된 복제본의 새로운 replication ID는 이전 replication과 다릅니다.

 때문에 dataset의 기록이 다르게 구성됩니다. 

 예를 들면 마스터는 사용 가능상태로 되돌리고 한동안 쓰기 작업을 받을 수 있습니다. 

 승격된 복제본에서 같은 replication ID를 사용하는 것은 replication ID와 offset은 오직 하나의 dataset만 식별한다는 

 규칙을 위반합니다. 

 추가로 복제본은 마스터와 재동기화 하는 데 필요한 정보를 RDB파일에 저장 할 수 있습니다. 

 이 방법은 업그레이드시 유용합니다. 이것이 필요하다면 복제본에서 save & quir를 수행하기 위해서 SHUTDOWN

 명령어를 사용하는 것이 좋습니다. 

 AOF 파일을 통해서 재시작시 복제본의 부분 재동기화를 수행하는 것은 불가능합니다. 

 그러나 인스턴스는 종료하기 전에 RDB 영속성으로 전환해서 재시작 할 수 있고 최종적으로 AOF

 다시 활성화 할 수 있습니다.