Redis 시작하기 - Redis 복제

Redis replication

Redis가 복제를 통해 고가용성 및 장애 조치를 지원하는 방법
Redis 복제의 기반(Redis Cluster 또는 Redis Sentinel에서 추가 계층으로 제공하는 고가용성 기능 제외)에는 사용 및 구성이 간편한 리더 팔로워(마스터-복제본) 복제가 있습니다. 이를 통해 복제본 Redis 인스턴스는 마스터 인스턴스의 정확한 복사본이 될 수 있습니다. 복제본은 링크가 끊어질 때마다 자동으로 마스터에 다시 연결되며 마스터에 어떤 일이 발생하든 관계없이 복제본의 정확한 복사본이 되려고 시도합니다.

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

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

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

그러나 WAIT는 다른 Redis 인스턴스에 지정된 수의 승인된 복사본이 있는지 확인할 수만 있으며, Redis 인스턴스 집합을 강력한 일관성을 가진 CP 시스템으로 전환하지 않습니다. 그러나 WAIT를 사용하면 실패 이벤트 후 쓰기가 손실될 확률이 트리거하기 어려운 특정 실패 모드로 크게 줄어듭니다.

고가용성 및 장애 조치에 대한 자세한 내용은 Redis Sentinel 또는 Redis 클러스터 설명서를 확인할 수 있습니다. 이 문서의 나머지 부분에서는 주로 Redis 기본 복제의 기본 특성에 대해 설명합니다.

Important facts about Redis replication

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

마스터가 지속성을 해제한 경우 복제의 안전성

Redis 복제가 사용되는 설정에서는 마스터 및 복제본에서 지속성을 설정하는 것이 좋습니다. 예를 들어 매우 느린 디스크로 인한 지연 시간 문제로 인해 이것이 가능하지 않은 경우 재부팅 후 자동으로 다시 시작되지 않도록 인스턴스를 구성해야 합니다. 자동 다시 시작으로 구성된 지속성이 해제된 마스터가 위험한 이유를 더 잘 이해하려면 마스터 및 모든 복제본에서 데이터가 지워지는 다음 오류 모드를 확인합니다:

1. 노드 A가 마스터 역할을 하고 지속성이 꺼지고 노드 B와 C가 노드 A에서 복제되는 설정이 있습니다.
2. 노드 A는 충돌하지만 프로세스를 다시 시작하는 자동 재시작 시스템이 있습니다. 그러나 지속성이 꺼져 있으므로 노드는 비어 있는 데이터 세트로 다시 시작됩니다.
3. 노드 B와 C는 비어 있는 노드 A에서 복제되므로 데이터 복사본을 효과적으로 삭제합니다.
   고가용성을 위해 Redis Sentinel을 사용하는 경우 프로세스의 자동 재시작과 함께 마스터의 지속성을 해제하는 것도 위험합니다. 예를 들어 마스터는 Sentinel이 장애를 감지하지 못할 만큼 빠르게 다시 시작하여 위에서 설명한 장애 모드가 발생하도록 할 수 있습니다.

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

How Redis replication works

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

Replication ID, offset

마스터 데이터 세트의 정확한 버전을 식별합니다.
복제본이 마스터에 연결되면 PSYNC 명령을 사용하여 이전 마스터 복제 ID와 지금까지 처리한 오프셋을 보냅니다. 이렇게 하면 마스터가 필요한 증분 부분만 보낼 수 있습니다. 그러나 마스터 버퍼에 백로그가 충분하지 않거나 복제본이 더 이상 알 수 없는 기록(복제 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인 인스턴스 B의 경우 첫 번째 인스턴스에는 데이터 세트에 적용된 특정 명령이 없음을 의미합니다. 또한 A가 몇 가지 명령만 적용하면 정확히 동일한 B 상태에 도달할 수 있음을 의미합니다.
Redis 인스턴스에 두 개의 복제 ID가 있는 이유는 마스터로 승격된 복제본 때문입니다. 장애 조치(failover) 후 승격된 복제본은 이전 복제 ID가 이전 마스터 중 하나였기 때문에 이전 복제 ID를 계속 기억해야 합니다. 이러한 방식으로 다른 복제본이 새 마스터와 동기화될 때 이전 마스터 복제 ID를 사용하여 부분 다시 동기화를 수행하려고 합니다. 복제본이 마스터로 승격될 때 보조 ID를 기본 ID로 설정하고 이 ID 전환이 발생했을 때 오프셋이 무엇인지 기억하기 때문에 예상대로 작동합니다. 나중에 새 기록이 시작되므로 새 임의 복제 ID를 선택합니다. 새 복제본 연결을 처리할 때 마스터는 해당 ID 및 오프셋을 현재 ID 및 보조 ID와 일치시킵니다(안전을 위해 지정된 오프셋까지). 즉, 장애 조치(failover) 후 새로 승격된 마스터에 연결하는 복제본은 전체 동기화를 수행할 필요가 없습니다.
마스터로 승격된 복제본이 장애 조치 후 복제 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 파일의 replica-read-only 옵션에 의해 제어되며 CONFIG SET를 사용하여 런타임에 활성화 및 비활성화할 수 있습니다.
읽기 전용 복제본은 모든 쓰기 명령을 거부하므로 실수로 인해 복제본입니다. 그렇다고 해서 DEBUG 또는 CONFIG와 같은 관리 명령이 여전히 활성화되어 있기 때문에 이 기능이 복제본 인스턴스를 인터넷이나 더 일반적으로 신뢰할 수 없는 클라이언트가 있는 네트워크에 노출하기 위한 것은 아닙니다 . 보안 페이지에서는 Redis 인스턴스를 보호하는 방법을 설명합니다.

읽기 전용 설정을 되돌리고 쓰기 작업의 대상이 될 수 있는 복제본 인스턴스를 가질 수 있는 이유가 궁금할 수 있습니다. 대답은 쓰기 가능한 복제본이 역사적인 이유로만 존재한다는 것입니다. 쓰기 가능한 복제본을 사용하면 마스터와 복제본 간에 불일치가 발생할 수 있으므로 쓰기 가능한 복제본을 사용하지 않는 것이 좋습니다. 이것이 어떤 상황에서 문제가 될 수 있는지 이해하려면 복제가 작동하는 방식을 이해해야 합니다. 마스터의 변경 사항은 일반 Redis 명령을 복제본에 전파하여 복제됩니다. 마스터에서 키가 만료되면 DEL 명령으로 전파됩니다. 마스터에 있지만 삭제되거나 만료되었거나 복제본에서 마스터와 다른 유형을 가진 키가 마스터에서 전파된 DEL, INCR 또는 RPOP와 같은 명령에 의도한 것과 다르게 반응합니다. 전파된 명령이 복제본에서 실패하거나 다른 결과가 발생할 수 있습니다. 위험을 최소화하려면(쓰기 가능한 복제본을 계속 사용해야 하는 경우) 다음 권장 사항을 따르는 것이 좋습니다.

• 마스터에서도 사용되는 쓰기 가능한 복제본의 키에 쓰지 마세요. (마스터에 쓰는 모든 클라이언트를 제어할 수 없는 경우 이를 보장하기 어려울 수 있습니다.)
• 실행 중인 시스템에서 인스턴스 집합을 업그레이드할 때 중간 단계로 인스턴스를 쓰기 가능한 복제본으로 구성하지 마세요. 일반적으로 데이터 일관성을 보장하려는 경우 인스턴스를 마스터로 승격할 수 있는 경우 쓰기 가능한 복제본으로 구성하지 마세요. 역사적으로 쓰기 가능한 복제본에 대해 합법적인 것으로 간주되는 몇 가지 사용 사례가 있었습니다. 버전 7.0부터 이러한 사용 사례는 이제 모두 사용되지 않으며 다른 방법으로도 동일한 작업을 수행할 수 있습니다. 예를 들어:
• 느린 집합 또는 정렬된 집합 연산을 계산하고 SUNIONSTORE 및 ZINTERSTORE와 같은 명령을 사용하여 결과를 임시 로컬 키에 저장합니다. 대신 SUNION 및 ZINTER와 같이 결과를 저장하지 않고 반환하는 명령을 사용합니다.
• SORT 명령 (선택적 STORE 옵션으로 인해 읽기 전용 명령으로 간주되지 않으므로 읽기 전용 복제본에서 사용할 수 없음) 사용. 대신 읽기 전용 명령인 SORT_RO를 사용합니다.
• EVAL 및 EVALSHA를 사용하는 것도 Lua 스크립트가 쓰기 명령을 호출할 수 있기 때문에 읽기 전용 명령으로 간주되지 않습니다. 대신 Lua 스크립트가 읽기 전용 명령만 호출할 수 있는 EVAL_RO 및 EVALSHA_RO 사용합니다.

복제본과 마스터가 다시 동기화되거나 복제본이 다시 시작되면 복제본에 대한 쓰기가 삭제되지만 자동으로 동기화된다는 보장은 없습니다. 버전 4.0 이전에는 쓰기 가능한 복제본이 TTL(Time to Live)이 설정된 키를 만료할 수 없었습니다. 즉 , EXPIRE 또는 키에 대한 최대 TTL을 설정하는 다른 명령을 사용하면 키가 누수되고 읽기 명령으로 액세스하는 동안 더 이상 키가 표시되지 않을 수 있지만 키 수에는 키가 표시되고 여전히 메모리를 사용합니다. Redis 4.0 RC3 이상 버전에서는 63보다 큰 DB 번호로 작성된 키를 제외하고 마스터와 마찬가지로 TTL이 있는 키를 제거할 수 있습니다(그러나 기본적으로 Redis 인스턴스에는 16개의 데이터베이스만 있음). 4.0 이상의 버전에서도 마스터에 존재할 수 있는 키에 EXPIRE를 사용하면 복제본과 마스터 간에 불일치가 발생할 수 있습니다. 또한 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 복제본은 매초마다 마스터를 ping하여 처리된 복제 스트림의 양을 확인합니다.
• Redis 마스터는 모든 복제본에서 마지막으로 ping을 수신한 시간을 기억합니다.
• 사용자는 최대 시간(초)보다 지연이 없는 최소 복제본 수를 구성할 수 있습니다. 지연이 M초 미만인 복제본이 N개 이상 있는 경우 쓰기가 허용됩니다. 지정된 쓰기에 대해 일관성이 보장되지 않지만 적어도 데이터 손실에 대한 시간이 지정된 시간(초)으로 제한되는 최선의 데이터 안전 메커니즘으로 생각할 수 있습니다. 일반적으로 바운드 데이터 손실은 바인딩되지 않은 데이터 손실보다 낫습니다.. 조건이 충족되지 않으면 마스터는 대신 오류로 응답하고 쓰기가 허용되지 않습니다. 이 기능에는 두 가지 구성 매개 변수가 있습니다:

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

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

How Redis replication deals with expires on keys

Redis 만료를 통해 키의 TTL(Time to Live)을 제한할 수 있습니다. 이러한 기능은 인스턴스를 계산하는 기능에 따라 달라지지만, Redis 복제본은 Lua 스크립트를 사용하여 이러한 키를 변경하더라도 만료된 키를 올바르게 복제합니다. 이러한 기능을 구현하기 위해 Redis는 마스터와 복제본의 클럭 동기화 기능에 의존할 수 없으며, 이는 해결할 수 없는 문제이며 경합 상태와 데이터 세트의 분기를 초래할 수 있으므로 Redis는 세 가지 주요 기술을 사용하여 만료된 키의 복제가 작동할 수 있도록 합니다:

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

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

Configuring replication in Docker and NAT

Docker 또는 포트 전달 또는 네트워크 주소 변환을 사용하는 다른 유형의 컨테이너를 사용하는 경우, 특히 Redis Sentinel 또는 마스터 INFO 또는 ROLE 명령 출력을 스캔하여 복제본의 주소를 검색하는 다른 시스템을 사용할 때 Redis 복제에 각별한 주의가 필요합니다. 문제는 마스터 인스턴스로 실행될 때 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입니다. replication 인수를 INFO 복제로 사용하여 명령을 호출하면 복제와 관련된 정보만 표시됩니다. 컴퓨터 친화적인 또 다른 명령은 마스터 및 복제본의 복제 상태와 복제 오프셋, 연결된 복제본 목록 등을 제공하는 ROLE입니다.

Partial sync after restarts and failovers

Redis 4.0부터는 장애 조치 후 인스턴스가 마스터로 승격되면 이전 마스터의 복제본과 부분 재동기화를 계속 수행할 수 있습니다. 이를 위해 복제본은 이전 복제 ID와 이전 마스터의 오프셋을 기억하므로 이전 복제 ID를 요청하더라도 연결 복제본에 백로그의 일부를 제공할 수 있습니다. 그러나 승격된 복제본의 새 복제 ID는 데이터 집합의 다른 기록을 구성하기 때문에 다릅니다. 예를 들어 마스터는 사용 가능을 반환할 수 있고 일정 시간 동안 쓰기를 계속 수락할 수 있으므로 승격된 복제본에서 동일한 복제 ID를 사용하면 복제 ID와 오프셋 쌍이 단일 데이터 세트만 식별한다는 규칙을 위반하게 됩니다. 또한 복제본은 전원을 부드럽게 껐다가 다시 시작하면 마스터와 다시 동기화하는 데 필요한 정보를 RDB 파일에 저장할 수 있습니다. 이는 업그레이드의 경우에 유용합니다. 이것이 필요한 경우, 복제본에 대한 저장 및 종료 작업을 수행하기 위해 SHUTDOWN 명령을 사용하는 것이 좋습니다. AOF 파일을 통해 다시 시작된 복제본을 부분적으로 동기화할 수 없습니다. 그러나 인스턴스를 종료하기 전에 RDB 지속성으로 전환하여 다시 시작할 수 있으며 마지막으로 AOF를 다시 활성화 할 수 있습니다.

Maxmemory on replicas

기본적으로 복제본은 maxmemory를 무시합니다 (장애 조치 후 또는 수동으로 마스터로 승격되지 않는 한). 즉, 키 제거는 마스터에서 처리되며, DEL 명령을 마스터 측에서 키가 제거될 때 복제본에 보냅니다. 이 동작은 마스터와 복제본이 일관성을 유지하도록 하며, 이는 일반적으로 원하는 것입니다. 그러나 복제본에 쓰기 가능하거나 복제본에 다른 메모리 설정을 적용하려는 경우 복제본에 수행된 모든 쓰기가 idempotent라고 확신하는 경우 이 기본값을 변경할 수 있습니다(그러나 수행 중인 작업을 이해해야 함). 복제본은 기본적으로 제거되지 않으므로 maxmemory를 통해 설정된 것보다 더 많은 메모리를 사용하게 될 수 있습니다 (복제본에서 더 클 수 있는 특정 버퍼가 있거나 데이터 구조가 때때로 더 많은 메모리를 차지할 수 있기 때문에). 복제본을 모니터링하고, 마스터가 구성된 maxmemory 설정에 도달하기 전에 실제 메모리 부족 상태에 도달하지 않도록 충분한 메모리가 있는지 확인합니다 . 이 동작을 변경하려면 복제본이 maxmemory를 무시하지 않도록 허용할 수 있습니다. 사용할 구성 지시문은 다음과 같습니다.:

replica-ignore-maxmemory no