Redis 고 가용성 예비 마스터-슬레이브 복제 원칙

Redis 고 가용성 예비 마스터-슬레이브 복제 원칙

(1) 마스터-슬레이브 복제 란?

마스터-슬레이브 복제는 한 redis 서버의 데이터를 다른 redis 서버로 복사하는 것을 말합니다. 전자를 마스터라고하고 후자를 슬레이브라고합니다. 데이터 복제는 마스터 노드에서 슬레이브 노드로만 단방향입니다. 마스터 노드는 쓰기 작업을 담당하고 슬레이브 노드는 읽기 작업을 담당합니다. 마스터-슬레이브 복제는 여러 데이터 복사본을 다른 노드에 배포하여 redis의 고 가용성을 달성하고 데이터의 중복 백업을 달성하며 데이터 및 서비스의 높은 안정성을 보장합니다.

간단히 말해서 마스터-슬레이브 복제의 주요 기능은 데이터의 신뢰성을 보장하는 것입니다. 정전 또는 하드 디스크 손상으로 인한 서버 다운 타임의 경우 마스터-슬레이브 복제의 다중 노드 데이터 백업은 데이터 복구에 매우 편리하고 빠를 수 있습니다. 안정성을 보장하는 것 외에도 마스터-슬레이브 복제에는 다음과 같은 다른 기능이 있습니다.

1. 데이터 이중화 : 마스터-슬레이브 복제는 데이터의 핫 백업을 실현합니다. 이는 지속성 외에 데이터 이중화 방법입니다.
2. 장애 복구 : 마스터 노드에 문제가있을 때 슬레이브 노드는 신속한 장애 복구를 달성하기위한 서비스를 제공 할 수 있습니다.
3.로드 밸런싱 : 읽기와 쓰기가 분리 된 마스터-슬레이브 복제를 기반으로 마스터 노드는 쓰기 서비스를 제공 할 수 있으며 슬레이브 노드는 특히 쓰기가 적고 읽기가 많은 시나리오에서 서버 부하를 공유하기 위해 읽기 서비스를 제공합니다. 슬레이브 노드는 읽기로드를 공유하므로 Redis 서버의 동시성을 크게 높일 수 있습니다.
4. 고 가용성의 초석 : 마스터-슬레이브 복제는 센티넬 및 클러스터 구현의 기반이므로 마스터-슬레이브 복제는 Redis 고 가용성의 기반입니다.

(2) 마스터-슬레이브 복제의 3 단계

마스터-슬레이브 복제의 전체 워크 플로는 다음 세 단계로 구분되며 각 단계에는 자체 내부 워크 플로가 있으며이 세 가지 프로세스를 살펴 보겠습니다.

1. 연결을 설정하는 과정 : 슬레이브를 마스터에 연결하는 과정
2. 데이터 동기화 프로세스 : 마스터에서 슬레이브로 데이터를 동기화하는 프로세스
3. 명령 전파 프로세스 : 마스터가 반복적으로 데이터를 슬레이브에 동기화

1. 연결 프로세스 설정

연결 설정은 마스터-슬레이브 복제의 첫 번째 단계입니다. 연결 설정 단계의 워크 플로에 대해 간단히 설명합니다.

1. 슬레이브는 마스터의 주소와 포트를 설정하고 마스터의 정보를 저장합니다.
2. 소켓 연결 설정
3. 지속적으로 ping 명령 보내기
4. 입증
5. 마스터에 슬레이브 포트 정보 보내기

분명히 연결을 설정하는 과정에서 슬레이브 노드는 마스터의 주소와 포트를 저장하고 마스터 노드 마스터는 슬레이브 노드의 포트를 저장합니다. 다음은 순서도입니다.

2. 데이터 동기화 프로세스

슬레이브 노드가 처음 마스터 노드에 연결되면 먼저 전체 복사를 수행합니다. 전체 복사는 리소스 집약적이지만이 전체 복사는 불가피합니다. 전체 복사가 실행 된 후 마스터 노드는 복사 버퍼의 데이터를 슬레이브 노드로 보내고 슬레이브 노드는 bgrewriteaof 명령을 실행하여 데이터를 복원합니다. 이는 부분 복사이기도합니다. 다음은 순서도입니다.

3. 명령 전파 단계

마스터 데이터베이스가 수정되고 마스터와 슬레이브 서버의 데이터가 일치하지 않는 경우, 이때 마스터와 슬레이브 데이터가 일치하도록 동기화되며이 과정을 명령 전파라고합니다. 마스터는 수신 된 데이터 변경 명령을 슬레이브로 보내고 슬레이브는 명령을받은 후 명령을 실행하여 마스터-슬레이브 데이터를 일관되게 만듭니다.

(3) 전체 복사 및 부분 복사

아래에서 전체 복사 및 부분 복사에 대해 자세히 설명하겠습니다.

1. 슬레이브 노드는 psync? 1 psync runid offset 명령을 전송하여 데이터를 요청하기 위해 해당 runid의 노드를 찾는데 문제가 있습니다. 슬레이브 노드가 처음 연결될 때 마스터 노드의 runid와 오프셋을 전혀 알 수 없습니다. 첫 번째 명령은 psync입니까? 1. 마스터 노드의 모든 데이터가 동기화되어야 함을 의미합니다.
2. 마스터 노드는 bgsave를 실행하여 RDB 파일을 생성하고 현재 복사 오프셋 오프셋을 기록합니다.
3. 마스터 노드는 + FULLRESYNC runid offset 명령을 통해 자신의 runid와 offset을 슬레이브 노드로 보낸 다음 소켓을 통해 슬레이브 노드로 RDB 파일을 보냅니다. 이 단계에서 마스터 노드는 클라이언트로부터 명령을 수신 할 수 있으며 오프셋이 변경되었습니다.
4. 슬레이브 노드는 마스터 노드의 runid 및 오프셋을 수신하여 저장 한 다음 데이터베이스의 모든 현재 데이터를 지우고 소켓을 통해 RDB 파일을 수신하고 RDB 데이터 (전체 복사) 복원을 시작합니다.
5. 전체 복제 후 슬레이브 노드는 마스터 노드의 runid 및 오프셋을 확보하고 psync runid offset 명령을 전송하기 시작합니다.
6. 마스터 노드는 명령을 수신하고 runid가 일치하는지 판단하고 오프셋이 복사 버퍼에 있는지 판단합니다.
7. 마스터 노드는 runid와 오프셋을 판단하고 만족하지 않으면 2 단계로 돌아가 전체 복제를 계속 수행합니다. 여기서 runid 불일치의 이유는 슬레이브 노드의 예기치 않은 재시작 때문일 수 있으며 오프셋 (오프셋) 불일치는 복사 버퍼 오버 플로우로 인해 발생합니다. runid 또는 offset 검사를 통과하면 슬레이브 노드의 오프셋이 마스터 노드의 오프셋과 같으면 무시됩니다. 슬레이브 노드의 오프셋이 마스터 노드의 오프셋과 같지 않으면 마스터 노드는 + CONTINUE 오프셋 (마스터 노드의이 오프셋)을 보냅니다. ) 소켓을 통해 노드 오프셋에서 복사 버퍼의 마스터 노드 오프셋으로 작업을 보내는 명령입니다 (실제로 슬레이브 노드는 마스터 노드보다 적은 작업을 수행합니다).
8. 슬레이브 노드는 마스터 노드가 보낸 오프셋을 받고 소켓을 통해 정보를받은 후 bgrewriteaof를 실행하여 데이터를 복원합니다.

분명히 부분 복사가 전체 복사보다 훨씬 더 복잡하다는 것을 알았으므로 부분 복사에 대한 몇 가지 세부 사항을 살펴 보겠습니다.

1. 룬드

이 runid는 위에서 여러 번 언급되었습니다. 실제로 runid는 redis가 시작될 때 자동으로 생성되는 임의의 id입니다 (여기서는 시작할 때마다 id가 달라짐에 유의해야 함) 40 개의 임의의 16 진수로 구성됩니다. redis 노드를 고유하게 식별하기위한 시스템 문자열로 구성됩니다.

마스터-슬레이브 복제가 처음 시작되면 마스터는 룬 ID를 슬레이브로 보내고 슬레이브는 마스터의 ID를 저장합니다. 슬레이브의 연결이 끊어졌다가 다시 연결되면 슬레이브는이 id를 마스터에게 보냅니다. 슬레이브가 저장 한 runid가 마스터의 현재 runid와 같으면 마스터는 부분 복제를 사용하려고합니다 (성공적인 복제를위한 다른 요소는 위에서 언급 한 오프셋입니다). . 슬레이브가 저장 한 runid가 현재 master의 runid와 다른 경우 전체 복사를 직접 수행합니다.

2. 복사 버퍼

복사 버퍼는 데이터를 수집하기 위해 마스터의 명령 레코드를 저장하는 데 사용되는 선입 선출 대기열입니다. 복사 버퍼의 기본 저장 공간은 1M입니다. 구성 파일에서 repl-backlog-size 1mb를 수정하여 버퍼 크기를 제어 할 수 있습니다.

사실, 복사 버퍼는 저장된 AOF 영구 데이터 (aof 영구 기록 클라이언트가 실행 한 명령)이며 바이트로 구분되며 각 바이트에는 자체 오프셋 (이 오프셋)이 있습니다. 양은 앞에서 언급 한 복사 오프셋 (오프셋)입니다.

앞서 언급했듯이 복사 버퍼 공간이 부족하면 전체 복사로 이어질 수 있는데 그 이유는 무엇입니까? 명령 전파 단계에서 마스터 노드는 수집 된 명령을 복사 버퍼에 저장 한 다음 슬레이브 노드로 보냅니다. 문제가 발생하는 곳입니다. 클라이언트로부터 마스터 노드가 수신 한 명령이 순식간에 너무 많아서 복사 버퍼의 메모리를 초과하면 일부 데이터가 압착되어 마스터 노드와 슬레이브 노드에서 명령이 발생합니다. 일관성이 없으므로 전체 사본입니다. 버퍼 크기가 불합리하게 설정되면 무한 루프가 발생할 가능성이 매우 높으며 슬레이브 노드는 항상 전체를 복사하고 데이터를 비우고 전체를 복사합니다.

3. 오프셋 복사

마스터 노드 복사 오프셋은 슬레이브 노드에 레코드를 한 번 전송하고 슬레이브 노드는 레코드를 한 번 수신합니다. 정보 동기화, 마스터 노드와 슬레이브 노드의 차이 비교, 슬레이브 연결 해제시 데이터 사용량 복원에 사용됩니다. 이 값은 복사 버퍼 백 로그 영역의 오프셋에서도 가져옵니다.

(4) 하트 비트 메커니즘

문제를 생각할 수 있습니다. 마스터-슬레이브 복제 과정에서 마스터 노드와 슬레이브 노드가 온라인 상태이고 정상적으로 작동하는지 알아야합니다. 특정 노드의 지연 시간이 길거나 응답이없는 경우 다음과 같은 대응 조치를 취해야합니다. 마스터-슬레이브 복제 등을 중지 한 다음 각 노드는 다른 노드가 온라인 상태인지 어떻게 알 수 있습니까?

명령 전파 단계에서 마스터 노드와 슬레이브 노드는 항상 정보를 교환해야하며,이 정보 교환은 유지 관리를 위해 하트 비트 메커니즘을 사용하여 마스터 노드와 슬레이브 노드 간의 연결을 상호 인식합니다. 마스터 노드의 하트 비트 역할과 슬레이브 노드의 하트 비트 역할을 살펴 보겠습니다.

1. 마스터 하트 비트

Instruction : Ping은
기본적으로 10 초마다 수행됩니다. 매개 변수 repl-ping-slave-period에 의해 결정됩니다.
주로 슬레이브 노드가 온라인 상태인지 판단하는 역할을합니다.
정보 복제를 사용하여 슬레이브 노드가 임대 된 후 연결 시간 간격을 볼 수 있습니다. 지연 시간은 0 또는 1입니다. 정상 상태.

2. 슬레이브 하트 비트

명령 : replconf ack {offset}
은 1 초에 한 번 실행됩니다. 가장 중요한 것은 마스터 노드에 자체 복제 오프셋을 보내고 마스터 노드에서 최신 데이터 변경 명령을 가져 와서
마스터 노드가 온라인 상태인지 확인하는 것입니다.

참고 : 데이터 안정성을 보장하기 위해 마스터 노드는 정지 된 슬레이브 노드의 수가 설정 값을 초과하거나 지연이 너무 높을 때 모든 정보의 동기화를 거부합니다. 구성 및 조정할 수있는 두 가지 매개 변수가 있습니다.

• 쓰기 위해 최소 슬레이브 2
• 최소 슬레이브 최대 지연 8

이 두 매개 변수는 2 개의 슬레이브 노드 만 남아 있음을 나타내거나 슬레이브 노드의 지연이 8 초 이상인 경우 마스터 노드는 강제로 마스트 기능을 닫고 데이터 동기화를 중지합니다. 그렇다면 마스터 노드는 슬레이브 노드의 수와 지연 시간을 어떻게 알 수 있습니까? 위에서 언급했듯이 하트 비트 메커니즘에서 슬레이브는 초당 perlconf ack 명령을 전송하며이 명령은 오프셋, 슬레이브 노드의 지연 시간 및 슬레이브 노드 수를 전달할 수 있습니다.

2020 년 9 월 15 일