Redis의 마스터-슬레이브 복제에 대해 자세히 알아보기

이 글에서는 Redis의 마스터-슬레이브 복제에 대해 소개하고, 기본 마스터-슬레이브 구성을 소개하며, 마스터-슬레이브 구성의 기능과 원리를 소개하겠습니다.

Redis는 마스터-슬레이브 복제 기능을 지원합니다. Slaveof(Redis5 버전 이후에 Replicaof로 변경)를 실행하거나 구성 파일에서 Slaveof를 설정(Redis5 버전 이후에 Replicaof로 변경)하여 복제 기능을 활성화할 수 있습니다. [관련 권장 사항: Redis 동영상 튜토리얼]

• 마스터 1개와 클러스터 2개

• 마스터 1개와 슬레이브 여러 개

마스터-슬레이브 기본 구성

마스터 Redis 구성

Master Re dis 구성 기본적으로 수정할 필요가 없습니다. Redis에서 구성

Redis에서 구성

1. 관련 구성을 수정하세요

# salve的端口号
port 6380 

#把pid进程号写入pidfile配置的文件
pidfile /var/run/redis_6380.pid 

logfile "6380.log"  

#指定数据存放目录
dir /usr/local/redis‐5.0.3/data/6380 

#需要注释掉bind
#bind127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户端通过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可）

.

3. 마스터-슬레이브 복제 구성

#从本机master6379的redis实例复制数据，Redis5.0之前使用slaveof
replicaof 192.168.0.60 6379

#配置从节点只读
replica‐read‐only yes

4. 슬레이브 노드 시작

redis‐server redis.conf

5. 6379 인스턴스에서 데이터 쓰기를 테스트하고 6380이 작동하는지 확인합니다. 인스턴스는 새로 수정된 데이터를 적시에 동기화할 수 있습니다

redis‐cli ‐p 6380

마스터-슬레이브 구성

의 역할 읽기와 쓰기의 분리

하나의 마스터와 다중 슬레이브, 마스터-슬레이브 동기화

마스터가 쓰기를 담당 , 그리고 슬레이브는 읽기를 담당합니다

Redis의 성능과 처리량을 향상합니다

마스터-슬레이브 데이터 일관성 문제

• 데이터 재해 허용
• 슬레이브는 호스트의 백업입니다

호스트가 다운되었습니다. , 슬레이브는 읽을 수 있지만 쓸 수는 없습니다

기본적으로 호스트가 다운된 후에는 호스트가 슬레이브를 사용할 수 없습니다.

Sentinel은 마스터-슬레이브 전환을 실현하여 고가용성을 달성할 수 있습니다.

• Redis 마스터의 작동 원리- 슬레이브
• 마스터-슬레이브 복제 전체 복사
• 슬레이브 Redis가 마스터 Redis에 처음 연결될 때만 전체 복사가 발생합니다. 단기 이력서라면 전체 복사가 될 수 있습니다. 부분 복사일 수도 있습니다.

Flowchart

1. 마스터 Redis와 긴 Socker 연결을 설정합니다.

slaver는 마스터와 소켓 연결을 설정합니다.

slaver 관련 파일 이벤트 프로세서

이 프로세서는 R을 수신합니다. DB 파일(전체 복사), 마스터가 전송한 쓰기 명령을 수신(증분 복사)

마스터 서버가 슬레이브 서버 소켓 연결을 수락한 후 해당 클라이언트 상태를 생성합니다. 슬레이브 서버가 마스터 서버의 클라이언트가 되는 것과 같습니다.

• Slaver가 Master에게 ping 명령을 보냅니다

1. Master가 정상적으로 처리할 수 있는지 확인합니다.

• 마스터의 응답:

  • 1. 정상임을 나타내는 "퐁"을 보냅니다.
    2. 마스터가 비정상임을 나타내는 오류를 반환합니다.
    3.

  • 권한 확인

    • 마스터와 슬레이브가 정상적으로 연결된 후 권한 확인을 진행합니다
    • 마스터가 비밀번호(requirepass="")를 설정하지 않았으므로 설정할 필요가 없습니다. 비밀번호 (masterauth="")
      마스터는 비밀번호를 설정해야 하는 것(requirepass! =""), 비밀번호를 설정해야 하는 것(masterauth=마스터의 requirepass 값)
    또는 auth 명령

2. 마스터 Redis가 PSYNC 명령을 받습니다

• PSYNC 명령 후에 bgsave 명령을 실행하면 마스터 Redis가 rdb를 보냅니다. 마스터 Redis가 rdb 스냅샷을 슬레이브 Redis로 보내면 마스터는 계속해서 클라이언트의 요청을 수신하여 메모리의 데이터 세트를 수정하고 relp 버퍼 캐시에 저장합니다.
• 동기화 스냅샷 단계: 마스터가 스냅샷 RDB를 생성하여 슬레이브에 보내고, 슬레이브가 스냅샷을 로드하고 구문 분석합니다. 마스터는 또한 이 단계에서 생성된 새로운 쓰기 명령을 버퍼에 저장합니다.

4. 슬레이브 노드는 rdb 스냅샷을 수신합니다

슬레이브 노드는 rdb 스냅샷을 수신한 후 이전 데이터를 지우고 rdb 파일을 로드합니다

5. 마스터 Redis는 버퍼 캐시 파일을 slave Redis

쓰기 버퍼 동기화 단계: 마스터는 버퍼에 저장된 쓰기 작업 명령을 슬레이브에 동기화합니다.

6. 슬레이브 노드는 버퍼 캐시 파일을 수신합니다

슬레이브 노드는 버퍼 캐시 파일을 수신하고 버퍼 캐시 파일을 메모리에 로드합니다

7. 마스터 Redis는 슬레이브 노드에 지속적으로 명령을 보냅니다. Socker 긴 연결

Redis에서 마스터 Redis가 보낸 명령을 받아 현재 명령을 실행합니다

Overview

마스터를 위해 슬레이브를 구성하면 처음으로 슬레이브가 마스터에 연결되는지 여부에 관계없이 시간이 지나면 마스터가 데이터 복사를 요청하도록 PSYNC 명령을 보냅니다. PSYNC 명령을 받은 후 마스터는 백그라운드에서 데이터 지속성을 수행하고 bgsave를 통해 최신 RDB 스냅샷 파일을 생성합니다. 지속 기간 동안 마스터는 클라이언트 요청을 계속 수신하며 데이터를 수정할 수 있는 이러한 요청을 캐시합니다. 메모리에 설정합니다. 지속성이 완료되면 마스터는 RDB 파일 데이터 세트를 슬레이브에 보내고 슬레이브는 수신된 데이터를 유지하여 RDB를 생성한 다음 이를 메모리에 로드합니다. 그런 다음 마스터는 이전에 메모리에 캐시된 명령을 슬레이브에 보냅니다. 어떤 이유로 마스터와 슬레이브 간의 연결이 끊어지면 슬레이브는 자동으로 마스터에 다시 연결할 수 있습니다. 마스터가 여러 슬레이브 동시 연결 요청을 받으면 각 연결마다 한 번이 아닌 한 번만 지속된 다음 전송됩니다. 이 영구 데이터를 동시에 연결된 여러 슬레이브에 전달합니다.

마스터-슬레이브 복제 부분 복사



일반적인 과정은 전체 복사와 유사하므로 자세히 설명하지 않겠습니다.

간단한 설명

마스터와 슬레이브 연결이 끊어지고 다시 연결되면 일반적으로 전체 데이터가 복사본으로 만들어집니다. 그러나 redis 버전 2.8부터 redis는 부분 데이터 복제를 지원할 수 있는 PSYNC 명령을 사용하여 마스터와 데이터를 동기화합니다. 슬레이브와 마스터는 네트워크 연결이 끊겼다가 다시 연결된 후에만 부분 데이터 복제(전송 재개)를 수행할 수 있습니다. 마스터는 자신의 메모리에 데이터를 복사하기 위한 캐시 큐를 생성하여 가장 최근 기간의 데이터를 캐시합니다. 따라서 마스터와 모든 슬레이브는 복사된 데이터 첨자 오프셋과 마스터의 프로세스 ID를 유지합니다. 그 후, 슬레이브는 마스터에게 기록된 데이터 인덱스부터 시작하여 완료되지 않은 복제를 계속하도록 요청합니다. 마스터 프로세스 ID가 변경되거나 슬레이브 노드 데이터 오프셋이 너무 오래되어 더 이상 마스터의 캐시 대기열에 없으면 전체 데이터 복사가 수행됩니다. 마스터-슬레이브 복제(부분 복제, 중단점 재개) 흐름도:

마스터-슬레이브 복제의 증분 동기화

• Redis 증분 동기화는 주로 슬레이브가 초기화를 완료하고 시작할 때 마스터에서 발생하는 쓰기 작업을 나타냅니다. 슬레이브와 동기화하는 과정입니다.

• 일반적으로 마스터가 쓰기 명령을 실행할 때마다 동일한 쓰기 명령을 슬레이브에 보내고 슬레이브가 이를 수신하여 실행합니다.

마스터-슬레이브 복제의 하트비트 감지

1. 마스터-슬레이브 서버의 연결 상태를 감지합니다.

INFO 복제 명령을 전송하여 마스터-슬레이브 서버의 네트워크 연결 상태를 감지합니다. 마스터 서버의 경우, 마지막 명령이 마스터로 전송된 후 몇 초가 경과했는지 확인할 수 있습니다. lag 값은 0 또는 1 사이에서 점프해야 합니다. 1을 초과하면 마스터와 슬레이브 간의 연결에 결함이 있음을 의미합니다.

2. 최소 슬레이브의 보조 구현

Redis는 주 서버가 min-slaves-to-write 3(min-replicas-to-write 3) min-slaves 쓰기 명령을 실행하지 못하도록 구성할 수 있습니다. unsafe Conditions -max-lag 10 (min-replicas-max-lag 10) 위의 구성은 슬레이브 서버의 수가 3개 미만이거나, 슬레이브 서버 3대의 지연(lag) 값이 크거나 같은 경우를 의미합니다. 10초까지는 마스터 서버의 쓰기 명령 실행이 거부됩니다. 여기서 지연 값은 위의 INForeplication 명령의 지연 값입니다.

3. 명령 손실 감지

마스터 서버에서 슬레이브 서버로 전송된 쓰기 명령이 네트워크 장애로 인해 중간에 손실된 경우 슬레이브 서버가 마스터 서버로 REPLCONF ACK 명령을 보내면 마스터 서버는 슬레이브 서버의 현재 상태를 확인합니다. 복제 오프셋이 자신의 복제 오프셋보다 작으면 마스터 서버는 슬레이브가 제출한 복제 오프셋을 기반으로 복제 백로그 버퍼에서 슬레이브 서버의 누락된 데이터를 찾습니다. 서버로 전송하고 데이터를 슬레이브 서버로 다시 보냅니다. (재발급) 네트워크는 지속적으로 증분식으로 동기화됩니다. 네트워크 연결이 끊어졌다가 다시 연결되면

전체 복사인지 부분 복사인지 판단하는 방법



클라이언트가 saveof를 보낸 후 처음 복사되었는지 여부를 판단하고 일치하지 않으면 전체 복사를 수행합니다. , runid offset offset으로 판단하여 일치하면 부분 복사하고, 일치하지 않으면 전체 복사를 합니다.

더 많은 프로그래밍 관련 지식을 보려면 프로그래밍 비디오를 방문하세요! !

위 내용은 Redis의 마스터-슬레이브 복제에 대해 자세히 알아보기의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!