많은 친구들이 이미 마스터-슬레이브 복제를 구성했지만 Redis 마스터-슬레이브 복제의 워크플로와 일반적인 문제에 대해 깊이 이해하지 못하고 있다고 생각합니다. Kaka는 이번에 Redis 마스터-슬레이브 복제에 대한 모든 지식 포인트를 수집하는 데 이틀을 보냈습니다.

본 글을 구현하는데 필요한 환경

centos7.0

redis4.0

1. Redis 마스터-슬레이브 복제란?

마스터-슬레이브 복제는 이제 두 개의 Redis 서버가 있고 한 Redis의 데이터가 다른 Redis 데이터베이스와 동기화된다는 의미입니다. 전자를 마스터 노드, 후자를 슬레이브 노드라고 합니다. 데이터는 마스터에서 슬레이브로 한 방향으로만 동기화될 수 있습니다.

그러나 실제 과정에서는 마스터-슬레이브 복제를 위해 Redis 서버를 2개만 보유하는 것은 불가능하며, 이는 각 Redis 서버를 마스터 노드(master)라고 부를 수 있음을 의미합니다

다음 그림에서 예를 들어, 우리의 Slave3은 마스터의 슬레이브 노드이자 슬레이브의 마스터 노드입니다.

먼저 이 개념을 이해하고, 더 자세한 설명을 보려면 아래를 계속 읽어보세요.

2. Redis 마스터-슬레이브 복제가 필요한 이유는 무엇입니까?

현재 독립형 상태인 Redis 서버가 있다고 가정해 보겠습니다.

이 경우 발생하는 첫 번째 문제는 서버가 다운되어 데이터 손실이 직접적으로 발생한다는 것입니다. 프로젝트가 RMB와 관련이 있다면 그 결과는 상상할 수 있습니다.

두 번째 상황은 메모리 문제입니다. 서버가 하나만 있으면 메모리는 확실히 정점에 도달합니다. 한 서버를 무한정 업그레이드하는 것은 불가능합니다.

그래서 위의 두 가지 문제에 대응하여 서버를 몇 대 더 준비하고 마스터-슬레이브 복제를 구성하겠습니다. 여러 서버에 데이터를 저장합니다. 그리고 각 서버의 데이터가 동기화되었는지 확인하세요. 서버가 다운되더라도 사용자의 이용에는 영향을 미치지 않습니다. Redis는 계속해서 고가용성과 데이터 중복 백업을 달성할 수 있습니다.

이때 마스터와 슬레이브를 어떻게 연결하는지 궁금하신 점이 많을 텐데요. 데이터를 동기화하는 방법은 무엇입니까? 마스터 서버가 다운되면 어떻게 되나요? 걱정하지 말고 문제를 조금씩 해결해 보세요.

3. Redis 마스터-슬레이브 복제의 역할

위에서 Redis의 마스터-슬레이브 복제를 사용하는 이유에 대해 이야기했으므로 마스터-슬레이브 복제의 역할은 그 이유를 설명하는 것입니다. 그것은 사용됩니다.

1. 계속해서 이 다이어그램을 사용하여
2. 에 대해 이야기해 보겠습니다. 첫 번째 요점은 데이터의 핫 백업을 구현하는 데이터 중복성입니다. 이는 지속성 이외의 또 다른 방법입니다.
3. 두 번째 요점은 단일 기계 고장에 관한 것입니다. 마스터 노드에 문제가 발생한 경우, 슬레이브인 슬레이브 노드에서 서비스를 제공할 수 있어 신속한 장애 복구가 가능한 서비스 이중화를 이룬다.
4. 세 번째 포인트는 읽기와 쓰기의 분리입니다. 마스터 서버는 주로 쓰기에 사용되고, 슬레이브는 주로 데이터 읽기에 사용되므로 서버의 로드 용량을 향상시킬 수 있습니다. 동시에 수요 변화에 따라 슬레이브 노드 수를 추가할 수 있습니다.
5. 네 번째 포인트는 로드 밸런싱입니다. 읽기와 쓰기의 분리에 따라 마스터 노드는 쓰기 서비스를 제공하고 슬레이브 노드는 읽기 서비스를 제공하여 서버 부하를 공유합니다. 특히 쓰기가 적고 읽기가 많은 경우에는 더욱 그렇습니다. 읽기 로드는 여러 슬레이브 노드를 통해 공유되며 Redis 서버의 동시성과 로드를 크게 향상시킬 수 있습니다.
6. 다섯 번째 요점은 고가용성의 초석입니다. 마스터-슬레이브 복제는 센티널과 클러스터 구현의 기초입니다. 따라서 마스터-슬레이브 복제는 고가용성의 초석이라고 할 수 있습니다.

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

이제까지 설명했으니 먼저 마스터-슬레이브 복제 사례를 간단히 구성하고 구현 원칙에 대해 이야기해 보겠습니다.

redis 저장 경로는 다음과 같습니다: usr/local/redis

로그 및 구성 파일은 다음 위치에 저장됩니다: usr/local/redis/data

먼저 각각 redis6379 두 개의 구성 파일을 구성합니다. conf 및 redis6380.conf

주로 포트를 수정하려면 구성 파일을 수정하세요. 보기의 편의를 위해 로그 파일과 영구 파일의 이름은 해당 포트로 식별됩니다.

그런 다음 두 개의 Redis 서비스를 엽니다. 하나는 포트 6379이고 다른 하나는 포트 6380입니다.redis-server redis6380.conf,然后使用redis-cli -p 6380连接，因为redis的默认端口就是6379所以我们启动另外一台redis服务器直接使用redis-server redis6379.conf然后直接使用redis-cli명령을 실행하고 직접 연결하세요.

이제 우리는 두 개의 Redis 서비스를 성공적으로 구성했습니다. 하나는 6380이고 다른 하나는 6379입니다. 이는 단지 데모용입니다. 실제 작업에서는 두 개의 서로 다른 서버에 구성해야 합니다.

1. 시작하려면 클라이언트 명령줄을 사용하세요.

먼저 마스터-슬레이브 복제를 구성할 때 모든 작업이 슬레이브 노드에서 수행된다는 개념이 있어야 합니다. 노예입니다.

그런 다음slaveof 127.0.0.1 6379, 일단 실행되면 연결되었음을 의미합니다. .slaveof 127.0.0.1 6379，执行完就代表我们连接上了。

我们先测试一下看是否实现主从复制。在master这台服务器上执行俩个set kaka 123 和 set master 127.0.0.1

먼저 마스터-슬레이브 복제가 이루어졌는지 테스트해 보겠습니다. 두 개의kaka 123을 설정하고 마스터 127.0.0.1을 설정하면 Slave6380 포트를 성공적으로 얻을 수 있습니다. 이는 마스터가 슬레이브 복제가 구성되었습니다. 그러나 프로덕션 환경의 구현이 세상의 종말은 아닙니다. 나중에 고가용성이 달성될 때까지 마스터-슬레이브 복제가 더욱 최적화될 것입니다.

2. 구성 파일을 사용하여

을 활성화합니다. 구성 파일을 사용하여 마스터-슬레이브 복제를 시작하기 전에! 먼저 클라이언트 명령줄을 사용하여 이전 연결을 끊은 다음아무도 없음연결을 끊습니다. 슬레이브 복제 .slaveof no one即可断开主从复制。

在哪可以查看从节点已经断开了主节点呢！在主节点的客户端输入命令行info

슬레이브 노드가 마스터 노드에서 연결이 끊어졌는지 확인할 수 있나요? 메인 노드의 클라이언트에 명령줄을 입력하세요정보보기

슬레이브 노드를 사용하여 클라이언트 명령줄을 통해 마스터 노드에 연결한 후, 마스터 노드의 클라이언트에info打印的信息，可以看到有一个slave0的一个信息。

这个图是在从节点执行完slaveof no one后，在主节点打印的info，说明从节点已经跟主节点断开连接了。

在根据配置文件启动redis服务，redis-server redis6380.conf

을 입력하면 슬레이브 노드가 재시작된 후 바로 연결을 볼 수 있습니다. 마스터 노드의 슬레이브 노드 정보입니다.

마스터 노드에서 작성한 테스트 데이터와 내용은 슬레이브 노드에서 자동으로 동기화됩니다.

3. Redis 서버 시작 시 시작

이 구성도 매우 간단합니다. Redis 서버를 시작할 때 마스터-슬레이브 복제를 직접 시작하고 다음 명령을 실행할 수 있습니다.redis-server --slaveof host port.

4. 마스터-슬레이브 복제 시작 후 로그 정보 보기

마스터 노드의 로그 정보입니다

마스터 노드의 연결 정보와 RDB 스냅샷 저장이 포함된 슬레이브 노드의 정보입니다.

5. 마스터-슬레이브 복제의 작동 원리

1. 마스터-슬레이브 복제의 3단계

마스터-슬레이브 복제의 전체 작업 흐름은 다음과 같이 나뉩니다. 다음 세 단계. 각 세그먼트에는 고유한 내부 작업 흐름이 있으므로 세 가지 프로세스 프로세스에 대해 설명하겠습니다.

• 연결 확립 과정: 슬레이브를 마스터에 연결하는 과정
• 데이터 동기화 과정: 마스터가 슬레이브에 데이터를 동기화하는 과정
• 명령 전파 과정: 데이터를 반복적으로 동기화하는 과정
  

2 . 첫 번째 단계: 연결 설정 프로세스

위 그림은 완전한 마스터-슬레이브 복제 연결 설정 워크플로입니다. 그런 다음 짧은 단어를 사용하여 위의 작업 흐름을 설명합니다.

1. 마스터 주소와 포트 설정, 마스터 정보 저장
2. 소켓 연결 설정(이 연결이 수행하는 작업은 아래 설명됨)
3. 계속해서 ping 명령 보내기
4. 인증
5. 슬레이브 포트 정보 보내기

연결을 설정하는 과정에서 슬레이브 노드는 마스터의 주소와 포트를 저장하고, 마스터 노드는 슬레이브 노드의 포트를 저장합니다.

3. 2단계: 데이터 동기화 단계 프로세스

이 그림은 슬레이브 노드가 마스터 노드에 처음 연결될 때 데이터 동기화 프로세스를 자세히 설명합니다.

슬레이브 노드가 마스터 노드에 처음 연결되면 먼저 전체 복사를 수행하게 됩니다. 이 전체 복사는 불가피합니다.

전체 복제가 완료된 후 마스터 노드는 복제 백로그 버퍼에 데이터를 전송하고, 슬레이브 노드는 bgrewriteaof를 실행하여 데이터를 복원하는데, 이 역시 부분 복제입니다.

이 단계에서는 전체 복사, 부분 복사 및 복사 버퍼 백로그 영역이라는 세 가지 새로운 사항이 언급됩니다. 이러한 사항은 아래 FAQ에서 자세히 설명하겠습니다.

4. 세 번째 단계: 명령 전파 단계

마스터 데이터베이스가 수정되고 마스터 및 슬레이브 서버의 데이터가 일치하지 않는 경우 마스터 및 슬레이브 데이터가 일치하도록 동기화됩니다. 이 프로세스를 명령 전파라고 합니다.

마스터는 수신한 데이터 변경 명령을 슬레이브에 보내고, 슬레이브는 명령을 받은 후 명령을 실행하여 마스터-슬레이브 데이터를 일치시킵니다.

명령 전파 단계에서 부분 복제

• 명령 전파 단계에서 네트워크 연결이 끊어지거나 네트워크 지터로 인해 연결이 끊길 수 있습니다(연결 끊김)
• 이에 이때 마스터 노드는 여전히 마스터입니다. 계속해서 replbackbuffer(복제 버퍼 백로그 영역)에 데이터를 쓰게 됩니다
• 슬레이브 노드는 계속해서 마스터에 연결을 시도합니다(마스터에 연결)
• 슬레이브 노드가 데이터를 보내면 runid 및 복제 오프셋을 마스터 노드에 전달하고 pysnc 명령을 실행하여 동기화합니다.
• 마스터가 오프셋이 복사 버퍼 범위 내에 있다고 판단하면 계속 명령을 반환합니다. 그리고 복사 버퍼의 데이터를 슬레이브 노드로 보냅니다.
• 슬레이브 노드로부터 데이터를 수신하고 bgrewriteaof를 실행하여 데이터 복구

VI. 마스터-슬레이브 복제(전체 복제 + 부분 복제) 원리에 대한 자세한 소개

이 프로세스는 가장 완벽한 마스터-슬레이브 복제 프로세스 설명입니다. 그럼 각 과정을 간략히 소개하겠습니다

1. 노드에서 지침을 보내psync ? 1 psync runid offset找对应的runid索取数据。但是这里可以考虑一下，当从节点第一次连接的时候根本就不知道主节点的runid 和 offset。所以第一次发送的指令是psync ？ 1意思就是主节点的数据我全要。
2. 主节点开始执行bgsave生成RDB文件，记录当前的复制偏移量offset
3. 主节点这个时候会把自己的runid 和 offset 通过 +FULLRESYNC runid offset 指令 通过socket发送RDB文件给从节点。
4. 从节点接收到+FULLRESYNC 保存主节点的runid和offset 然后清空当前所有数据，通过socket接收RDB文件，开始恢复RDB数据。
5. 在全量复制后，从节点已经获取到了主节点的runid和offset，开始发送指令psync runid offset
6. 主节点接收指令，判断runid是否匹配，判断offset是否在复制缓冲区中。
7. 主节点判断runid和offset有一个不满足，就会在返回到步骤2전체 복제를 계속 수행하세요. 여기서 runid 불일치는 슬레이브 노드를 다시 시작해야만 발생할 수 있습니다. 이 문제는 복제 백로그 버퍼 오버플로로 인해 해결될 예정입니다. runid나 offset 검사를 통과한 경우, 슬레이브 노드의 오프셋이 마스터 노드의 오프셋과 같으면 무시됩니다. runid 또는 오프셋 검사를 통과하고 슬레이브 노드의 오프셋이 오프셋과 다른 경우 +CONTINUE 오프셋(이 오프셋은 마스터 노드에 속함)이 전송되고, 슬레이브 노드 오프셋에서 마스터 노드 오프셋으로의 데이터가 전송됩니다. 복제 버퍼는 소켓을 통해 전송됩니다.
8. 노드로부터 +CONTINUE를 수신하고 마스터의 오프셋을 소켓을 통해 수신한 후 bgrewriteaof를 실행하여 데이터를 복원합니다.

1-4는 전체 복제 5-8은 부분 복제

마스터 노드 3단계에서 마스터-슬레이브 복제 기간 동안 마스터 노드는 클라이언트의 데이터를 수신해 왔습니다. 노드의 오프셋은 항상 변경됩니다. 변경 사항만 각 슬레이브에 전송됩니다. 이 전송 프로세스를 하트비트 메커니즘이라고 합니다

7. 하트비트 메커니즘

명령 전파 단계에서는 마스터 노드와 슬레이브 노드 간의 정보 교환이 항상 필요하며, 하트비트 메커니즘은 마스터 노드와 슬레이브 노드 간의 연결을 유지하기 위한 유지 관리에 사용됩니다. 슬레이브 노드가 온라인 상태입니다.

• master heartbeat

• 명령: ping
• 기본값은 10초에 한 번이며 repl-ping-slave-기간 매개변수에 의해 결정됩니다
• 가장 중요한 것은 슬레이브가 node is online
• 정보 복제를 사용하면 슬레이브 노드에서 임대한 후 연결 시간 간격을 확인할 수 있습니다. lag가 0 또는 1이면 정상입니다.

• 슬레이브 하트비트 작업

• 명령: replconf ack {offset}
• 초당 한 번 실행됩니다
• 이 작업이 수행하는 주요 작업은 자체 복제 오프셋을 마스터 노드로 보내고 마스터 노드에서 최신 정보를 얻는 것입니다. 마스터 노드 데이터 변경 명령은 마스터 노드가 온라인인지 확인하는 작업도 수행합니다.

하트비트 단계에서 주의할 사항

마스터 노드는 슬레이브 노드 수가 중단되거나 지연 시간이 너무 높을 때 데이터 안정성을 보장합니다. 모든 정보 동기화가 거부됩니다.

구성하고 조정할 수 있는 두 가지 매개변수가 있습니다.

min-slaves-to-write 2

min-slaves-max-lag 8

이 두 매개변수는 슬레이브 노드가 2개만 남았거나 슬레이브 노드의 지연이 다음보다 크다는 것을 나타냅니다. 8초가 지나면 마스터 노드는 마스터 기능을 강제로 끄고 데이터 동기화를 중지합니다.

그럼 마스터 노드가 슬레이브 노드의 데이터와 지연 시간을 알고 있다면 어떨까요? 하트비트 메커니즘에서 슬레이브는 매초 perlconf ack 명령을 보냅니다. 이 명령은 슬레이브 노드의 오프셋, 지연 시간 및 슬레이브 노드 수를 전달할 수 있습니다.

8. 부분 복제의 세 가지 핵심 요소

1. 서버의 실행 ID(run id)

먼저 이 실행 ID가 무엇인지 살펴보겠습니다. info 명령을 실행하면 도착합니다. 이는 위의 시작 로그 정보를 보면 알 수 있습니다.

Redis는 시작될 때 자동으로 무작위 ID를 생성합니다(여기서 ID는 시작될 때마다 다르다는 점에 유의해야 합니다). 이 ID는 40개의 무작위 16진수 문자열로 구성되며 Redis 노드를 고유하게 식별하는 데 사용됩니다.

마스터-슬레이브 복제가 처음 시작되면 마스터는 자신의 runid를 슬레이브에 보내고 슬레이브는 마스터의 ID를 저장하여

을 볼 수 있습니다.

슬레이브가 연결을 끊었다가 다시 연결하면 이 ID를 슬레이브가 저장한 runid가 마스터의 현재 runid와 동일하면 마스터는 부분 복제를 시도합니다(또 다른 이 블록이 성공적으로 복사될 수 있는지 여부를 결정하는 요소는 오프셋입니다). 슬레이브가 저장한 runid가 마스터의 현재 runid와 다를 경우 바로 전체 복사가 수행됩니다.

2. 복사 백로그 버퍼

복사 버퍼 백로그는 사용자가 마스터 데이터 수집의 명령 레코드를 저장하는 선입선출 대기열입니다. 복사 버퍼의 기본 저장 공간은 1M입니다.

구성 파일repl-backlog-size 1mb에서 수정하여 버퍼 크기를 제어할 수 있습니다. 이 비율은 사용자의 서버 메모리에 따라 약 30% 정도 수정될 수 있습니다.

복사 버퍼에는 정확히 무엇이 저장되나요?

명령을set name kaka로 실행하면 영구 파일 보기를 볼 수 있습니다.

복사 백로그 버퍼는 영구 데이터가 저장된 것이며 바이트로 구분되며 각 바이트는 자체 오프셋. 이 오프셋도 복사 오프셋(offset)

그럼 왜 복사 버퍼 백로그로 인해 전체 복사가 발생할 수 있다고 하는 걸까요

명령 전파 단계에서 마스터 노드는 수집된 데이터를 복제 버퍼에 저장한 후 슬레이브 노드로 보냅니다. 여기서 문제가 발생하는데, 마스터 노드에 있는 데이터의 양이 순간적으로 너무 많아 복제 버퍼의 메모리를 초과하게 되면 일부 데이터가 압착되어 마스터 노드와 슬레이브 노드 사이의 데이터 불일치가 발생하게 됩니다. . 전체 사본을 만들려면 버퍼 크기가 적절하게 설정되지 않으면 무한 루프가 발생할 수 있습니다. 슬레이브 노드는 항상 전체를 복사하고 데이터를 지우고 전체를 복사합니다.

3. 복제 오프셋(offset)

마스터 노드 복제 오프셋은 슬레이브 노드에 한 번 레코드를 보내고, 슬레이브 노드는 레코드를 한 번 받습니다.

은 정보를 동기화하고, 마스터 노드와 슬레이브 노드의 차이점을 비교하고, 슬레이브 연결이 끊어졌을 때 데이터 사용량을 복원하는 데 사용됩니다.

이 값은 복사 버퍼 백로그 영역의 오프셋입니다.

9. 마스터-슬레이브 복제의 일반적인 문제

1. 마스터 노드 재시작 문제(내부 최적화)

마스터 노드가 다시 시작되면 runid 값이 변경되어 모든 슬레이브 노드가 전체 복제를 수행하게 됩니다.

이 문제에 대해 생각할 필요는 없으며 시스템이 어떻게 최적화되어 있는지 알면 됩니다.

마스터-슬레이브 복제가 설정된 후 마스터 노드는 master-replid 변수를 생성합니다. 생성된 전략은 runid와 동일하며 길이는 41비트, runid 길이는 40비트입니다. 그런 다음 슬레이브 노드로 전송됩니다.

마스터 노드에서 shutdown save 명령이 실행되면 RDB 지속성이 수행되고 runid 및 오프셋이 RDB 파일에 저장됩니다. redis-check-rdb 명령을 사용하여 이 정보를 볼 수 있습니다.

마스터 노드 재시작 후 RDB 파일을 로드하고, 파일에 포함된 repl-id와 repl-offset을 메모리에 로드합니다. 모든 슬레이브 노드가 이전 마스터 노드로 간주되는 경우에도 마찬가지입니다.

2. 슬레이브 노드 네트워크가 중단되고 오프셋이 경계를 넘어 전체 복제가 발생합니다.

네트워크 환경이 좋지 않아 슬레이브 노드 네트워크가 중단됩니다. 복제 백로그 버퍼 메모리가 너무 작아서 데이터 오버플로가 발생하고 슬레이브 노드 오프셋이 경계를 넘으면서 전체 복제가 발생합니다. 이로 인해 전체 복사가 반복될 수 있습니다.

해결책: 복제 백로그 버퍼 크기 수정: repl-backlog-size

설정 제안: 마스터 노드가 슬레이브 노드에 연결하는 데 걸리는 시간을 테스트하고 평균 총 명령 수를 얻습니다. 마스터 노드에 의해 생성됨 write_size_per_second

복사 버퍼 공간 설정 = 2마스터-슬레이브 연결 시간초당 마스터 노드에서 생성되는 총 데이터 양

3. 빈번한 네트워크 중단

마스터 노드의 과도한 CPU 사용량으로 인해 높거나, 슬레이브 노드가 자주 연결됩니다. 이러한 상황의 결과로 버퍼, 대역폭, 연결 등을 포함하되 이에 국한되지 않는 마스터 노드의 다양한 리소스가 심각하게 점유됩니다.

마스터 노드 자원이 심각하게 점유되는 이유는 무엇인가요?

하트비트 메커니즘에서 슬레이브 노드는 매초 마스터 노드에 replconf ack 명령 명령을 보냅니다.

슬레이브 노드가 느린 쿼리를 실행하여 CPU를 많이 점유했습니다.

마스터 노드가 1초마다 복제 타이밍 기능인 복제Cron을 호출한 후 슬레이브 노드가 오랫동안 응답하지 않았습니다.

해결책:

슬레이브 노드 시간 제한 해제 설정

매개변수 설정: repl-timeout

이 매개변수의 기본값은 60초입니다. 60초 후에 슬레이브를 해제합니다.

4. 데이터 불일치 문제

네트워크 요인으로 인해 여러 슬레이브 노드의 데이터가 일치하지 않습니다. 이 요인을 피할 수 있는 방법은 없습니다.

이 문제에 대한 해결책은 두 가지가 있습니다.

첫 번째 데이터는 일관성이 뛰어나고 Redis 서버를 구성해야 하며, 읽기와 쓰기 모두에 하나의 서버를 사용해야 합니다. 이 방법은 소량으로 제한됩니다. 데이터의 일관성이 매우 높아야 합니다.

두 번째는 마스터-슬레이브 노드의 오프셋을 모니터링합니다. 슬레이브 노드의 지연이 너무 크면 슬레이브 노드에 대한 클라이언트의 액세스가 일시적으로 차단됩니다. 매개변수를slave-serve-stale-data yes|no로 설정합니다. 이 매개변수가 설정되면 info Slaveof와 같은 몇 가지 명령에만 응답할 수 있습니다.

10. 요약

이 문서에서는 주로 마스터-슬레이브 복제가 무엇인지, 마스터-슬레이브 복제 작업의 세 가지 주요 단계, 워크플로 및 부분 복제의 세 가지 핵심에 대해 설명합니다. 명령 전파 단계 중 하트비트 메커니즘. 마지막으로 마스터-슬레이브 복제의 일반적인 문제에 대해 설명합니다.

위 내용은 Redis 마스터-슬레이브 복제 작동 원리 및 일반적인 문제의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!