Redis 고가용성 Sentinel 메커니즘 구현 세부 정보

Redis 고가용성 Sentinel 메커니즘 구현 세부 정보

이 기사는 내 기술 노트 [1] Redis 기사에서 가져온 것입니다. 자주 방문해 주셔서 감사합니다.

텍스트

이전 기사 "Redis 고가용성 파노라마" 에서 Redis의 고가용성에 대해 배웠습니다. 고가용성은 두 가지 의미가 있습니다. 하나는 서비스 중단이 적고 다른 하나는 데이터 손실이 적다는 것입니다. 마스터-슬레이브 라이브러리 모드 및 센티넬은 서비스 중단을 줄이고 AOF 로그 및 RDB 스냅샷을 통해 데이터 손실을 줄입니다.

그리고 센티넬의 세 가지 책임, 즉 모니터링, 마스터 선택(마스터 라이브러리 선택) 및 알림을 배웠습니다. 오늘 우리는 자세히 배울 것입니다.

먼저 Sentinel을 시작하기 전에 Sentinel을 설정해야 합니다. Redis 소스 코드에는 sentinel.conf[2]라는 파일이 포함되어 있으며 그 중 일부는 다음과 같이 구성됩니다.

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000

구성의 첫 번째 줄은 Sentinel이 mymaster라는 마스터 서버를 모니터링하도록 지시합니다. 이 마스터 서버의 IP 주소는 127.0.0.1이고 포트 번호는 6379입니다. 최소 2개의 Sentinel이 이 마스터 서버를 유효하지 않은 것으로 판단하는 데 동의해야 합니다.

보시다시피 메인 라이브러리의 IP와 포트만 설정합니다. 다른 Sentinel의 연결 정보가 설정되어 있지 않은데 이러한 Sentinel 인스턴스는 서로의 주소를 알지 못하는데 어떻게 클러스터를 형성하는가?

Sentinel 인스턴스는 Redis에서 제공하는 게시/구독 메커니즘, 즉 게시/구독 메커니즘 덕분에 서로를 발견할 수 있습니다. 마스터-슬레이브 클러스터에는 마스터 라이브러리에 이름이 지정된 채널이 있으며 __sentinel__:hello이를 통해 서로 다른 센티넬이 서로를 발견하고 통신합니다.

1. Sentinel 클러스터 구성

2초마다 각 Sentinel 노드는 __sentinel__:hello마스터 노드에 대한 Sentinel 노드의 판단과 현재 Sentinel 노드의 정보를 Redis 데이터 노드의 채널로 보냅니다.

예를 들어. 위 그림에서 Sentinel 1은 자신의 IP(172.16.19.3)와 포트(26579)를 __sentinel__:hello채널에 공개하고 Sentinel 2와 3은 채널을 구독합니다. 그러면 이때 Sentinel 2와 3은 이 채널에서 Sentinel 1의 IP 주소와 포트 번호를 직접 얻을 수 있다.

그런 다음 Sentinel 2, 3은 Sentinel 1과 네트워크 연결을 설정할 수 있습니다. 이러한 방식으로 Sentinel 2와 3도 네트워크 연결을 설정할 수 있으므로 Sentinel 클러스터가 형성됩니다. 메인 라이브러리의 오프라인 여부를 판단하고 협상하는 등 네트워크 연결을 통해 서로 통신할 수 있습니다.

Sentinel은 클러스터를 형성하기 위해 서로 연결을 설정하는 것 외에도 슬레이브 라이브러리와 연결을 설정해야 합니다. 이는 Sentinel의 모니터링 작업에서 마스터 라이브러리와 슬레이브 라이브러리 모두에 대해 하트비트 판단을 수행해야 하며, 마스터-슬레이브 라이브러리 전환이 완료된 후 슬레이브 라이브러리에도 새로운 마스터 라이브러리와 동기화하도록 알려야 하기 때문입니다. .

그렇다면 Sentinel은 슬레이브 라이브러리의 IP 주소와 포트를 어떻게 알 수 있을까요?

2. 슬레이브 노드 정보 얻기

이것은 메인 라이브러리에 INFO 명령을 보내는 센티널에 의해 수행됩니다. 아래 그림과 같이 Sentinel 2는 메인 라이브러리에 INFO 명령을 보내고 명령을 받은 후 메인 라이브러리는 센티널에 슬레이브 라이브러리 목록을 반환합니다. 그러면 Sentinel은 슬레이브 라이브러리 목록의 연결 정보에 따라 각 슬레이브 라이브러리와 연결을 설정할 수 있습니다. Sentinel 1과 3도 동일한 방법으로 슬레이브 라이브러리와 연결을 설정할 수 있습니다.

다음은 마스터 노드에서 실행되는 info 명령의 스니펫입니다.

# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=4917,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=4917,lag=1

그 후 Sentinel은 이 연결에서 슬레이브 라이브러리를 지속적으로 모니터링합니다. 10초마다 Sentinel 노드는 클러스터의 최신 토폴로지를 얻기 위해 마스터 노드와 슬레이브 노드에 info 명령을 보냅니다. 이런 식으로 새로운 슬레이브 노드가 합류하면 즉시 감지할 수 있습니다. 노드에 도달할 수 없거나 새 마스터 라이브러리를 선택한 후 info 명령을 통해 노드 토폴로지 정보를 실시간으로 업데이트할 수도 있습니다.

클러스터에 대한 정보로 무장한 Sentinel은 마침내 작업을 시작할 수 있습니다. 첫 번째 책임: 마스터-슬레이브 라이브러리가 오프라인인지 확인합니다.

3. 마스터-슬레이브 데이터베이스가 오프라인인지 판단하는 방법은 무엇입니까?

3.1 정기적으로 ping 명령 실행

Sentinel 프로세스가 실행 중일 때 마스터 노드, 슬레이브 노드 및 기타 Sentinel 노드에 1초마다 ping 명령을 보내 온라인 상태인지 확인합니다. 마스터 및 슬레이브 라이브러리가 지정된 시간 내에 Sentinel의 ping 명령에 응답하지 않으면 Sentinel은 이를 "오프라인 상태"로 표시합니다.

탐지가 기본 라이브러리인 경우 센티넬은 단순히 마스터-슬레이브 전환을 활성화할 수 없습니다. 그러한 상황이 있을 가능성이 매우 높기 때문입니다. 즉, 센티넬이 잘못 판단했지만 실제로는 메인 라이브러리에 결함이 없습니다.

오판은 일반적으로 클러스터 네트워크에 대한 압력이 높거나 네트워크가 혼잡하거나 메인 라이브러리 자체가 높은 압력을 받고 있을 때 발생합니다. Sentinel이 마스터-슬레이브 전환을 잘못 판단하고 시작하면 후속 마스터 선택 및 알림 작업으로 인해 추가 컴퓨팅 및 통신 오버헤드가 발생합니다.

그렇다면 오판을 줄이는 방법은 무엇일까요?

3.2 주관적인 오프라인과 객관적인 오프라인

센티넬 메커니즘은 일반적으로 센티널 클러스터라고도 하는 여러 인스턴스로 구성된 클러스터 모드로 배포됩니다. 함께 판단하기 위해 여러 센티널 인스턴스를 도입하면 단일 센티널이 자체 네트워크 상태가 좋지 않아 메인 라이브러리가 오프라인이라고 잘못 판단하는 것을 방지할 수 있습니다. 동시에 여러 Sentinel의 네트워크가 동시에 불안정할 확률이 적고 함께 결정을 내리며 오판율도 줄일 수 있습니다.

기사 시작 부분에서 제공한 sentinel.conf 구성을 기억하십니까?

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000

down-after-milliseconds이 옵션은 Sentinel이 서버를 오프라인으로 간주하는 중요한 임계값입니다.

서버가 Sentinel이 보낸 ping 명령에 밀리초 내에 응답하지 않거나 오류를 반환하면 Sentinel은 서버를 주관적으로 다운(줄여서 SDOWN)한 것으로 표시합니다.

메인 라이브러리가 오프라인이 되었다는 데 동의할 Sentinel이 충분하지 않은 경우 메인 라이브러리가 Sentinel의 PING 명령에 유효한 응답을 반환하면 메인 라이브러리의 주관적인 오프라인 상태가 제거됩니다. 그리고 2개 이상의 Sentinel이 주관적으로 메인 라이브러리를 오프라인으로 표시하면 메인 라이브러리는 객관적으로 다운된 것으로 표시됩니다(줄여서 ODOWN). Sentinel은 새로운 마스터 라이브러리가 될 많은 슬레이브 라이브러리에서 슬레이브 라이브러리를 선택하는 다음 의사 결정 프로세스를 시작하려고 합니다.

4. 새 메인 라이브러리를 선택하는 방법은 무엇입니까?

4.1 초기 심사

마스터가 선택되었을 때 슬레이브 라이브러리가 정상적으로 실행 중이라면 새로운 마스터 라이브러리로 선택하여 사용하기 시작한다고 상상해보십시오. 그러나 곧 네트워크에 장애가 발생했고 이때 마스터를 다시 선출해야 했습니다. 이것은 분명히 우리가 기대했던 것이 아닙니다. 따라서 마스터를 선택할 때 슬레이브 라이브러리의 현재 온라인 상태를 확인하는 것 외에도 이전 네트워크 연결 상태도 판단해야 합니다. 슬레이브 라이브러리가 마스터 라이브러리에서 항상 연결 해제되고 연결 해제 횟수가 특정 임계값을 초과하는 경우 슬레이브 라이브러리의 네트워크 상태가 좋지 않다고 믿을 수 있으므로 슬레이브 라이브러리를 필터링할 수 있습니다.

판단하는 방법? 구성 항목 down-after-milliseconds * 10을 사용합니다. 그 중 down-after-milliseconds는 마스터-슬레이브 라이브러리가 연결 해제되었다고 생각하는 최대 연결 시간 초과 시간입니다. down-after-milliseconds 밀리초 내에 마스터 노드와 슬레이브 노드가 네트워크를 통해 연결되지 않으면 마스터 노드와 슬레이브 노드가 연결 해제된 것으로 간주할 수 있습니다. 연결 끊김 횟수가 10회를 초과하면 슬레이브 라이브러리의 네트워크 상태가 좋지 않아 새로운 마스터 라이브러리로 사용하기에 적합하지 않다는 의미입니다.

이렇게 메인 라이브러리에 적합하지 않은 슬레이브 라이브러리를 걸러내고 선별 작업을 완료합니다.

다음 단계는 나머지 슬레이브 라이브러리에 점수를 매기는 것입니다. 슬레이브 라이브러리 우선 순위, 슬레이브 라이브러리 복사 진행률, 슬레이브 라이브러리 ID 번호의 세 가지 규칙에 따라 3라운드의 점수 매기기를 순차적으로 수행할 수 있습니다.

4.2 3라운드 득점

첫 번째 라운드: 우선 순위가 가장 높은 슬레이브가 더 높은 점수를 얻습니다.

사용자는 슬레이브 우선 순위 구성 항목을 통해 다른 슬레이브 라이브러리에 대해 다른 우선 순위를 설정할 수 있습니다. 예를 들어 메모리 크기가 다른 두 개의 슬레이브 라이브러리가 있는 경우 메모리가 큰 인스턴스에 수동으로 높은 우선 순위를 설정할 수 있습니다.

두 번째 라운드: 이전 마스터 라이브러리의 동기화 정도에 가장 가까운 슬레이브 라이브러리는 높은 점수를 받습니다.

이 규칙의 기본은 이전 마스터 라이브러리와 가장 가까운 슬레이브 라이브러리를 마스터 라이브러리로 선택하면 새 마스터 라이브러리가 최신 데이터를 갖게 된다는 것입니다.

슬레이브 라이브러리와 이전 마스터 라이브러리 간의 동기화 진행 상황을 판단하는 방법은 무엇입니까?

마스터-슬레이브 라이브러리가 동기화될 때 명령 전파 프로세스가 있습니다. 이 과정에서 마스터 라이브러리는 master_repl_offset을 사용하여 repl_backlog_buffer에 마지막 쓰기 작업 위치를 기록하고 슬레이브 라이브러리는 slave_repl_offset 값을 사용하여 현재 복제 진행 상황을 기록합니다.

마스터-슬레이브 라이브러리가 동기화될 때 명령 전파 프로세스가 있습니다. 이 과정에서 마스터 라이브러리는 master_repl_offset을 사용하여 repl_backlog_buffer에 마지막 쓰기 작업 위치를 기록하고 슬레이브 라이브러리는 slave_repl_offset 값을 사용하여 현재 복제 진행 상황을 기록합니다.

아래 그림과 같이 슬레이브 라이브러리 2를 새로운 마스터 라이브러리로 선택해야 합니다.

세 번째 라운드: ID 번호가 작은 슬레이브가 더 높은 점수를 얻습니다.

각 인스턴스에는 슬레이브 라이브러리의 번호와 유사한 ID가 있습니다. 현재 Redis가 마스터 라이브러리를 선택할 때 기본 규칙이 있습니다. 우선 순위 및 복제 진행이 동일한 경우 ID 번호가 가장 작은 슬레이브 라이브러리가 가장 높은 점수를 가지며 새 마스터 라이브러리로 선택됩니다.

이 시점에서 새 메인 라이브러리가 선택되고 다음 단계는 슬레이브 라이브러리를 메인 라이브러리로 업그레이드하는 것입니다. 그러나 여기에서 누가 마스터-슬레이브 전환 작업을 수행해야 하는 센티넬이 많은지 다시 질문이 옵니다.

4.3 마스터-슬레이브 전환을 수행하는 센티넬은 무엇입니까?

모든 Sentinel 인스턴스는 상대방이 마스터 라이브러리가 오프라인이라고 생각하는지 묻기 위해 마스터 라이브러리가 "주관적으로 오프라인"이라고 판단하는 한 SENTINEL is-master-down-by-addr 명령을 다른 Sentinel에 보냅니다. 그러면 다른 센티널 인스턴스는 메인 라이브러리와의 연결에 따라 Y 또는 N으로 응답합니다. Y는 찬성 투표에 해당하고 N은 반대 투표에 해당합니다.

이 시점에서 Sentinel은 다른 Sentry에 명령을 보내서 마스터-슬레이브 전환을 스스로 수행하고 다른 모든 Sentry가 투표하도록 할 수 있습니다. 이 투표 과정을 "리더 선출"이라고 합니다. 선출된 리더는 최종적으로 마스터-슬레이브 전환을 수행하는 파수꾼입니다.

예를 들어, 이제 3개의 센티널이 있고 쿼럼 구성은 2입니다. 선거 프로세스가 어떻게 보이는지 봅시다.

T1에서 S1은 주 데이터베이스가 "객관적으로 오프라인"이라고 판단하고 리더가 되려면 먼저 자신에게 투표한 다음 각각 S2와 S3에 명령을 보내 리더가 되고 싶다는 의사를 표시합니다.

T2에서 S3는 기본 데이터베이스가 "객관적으로 오프라인"이라고 판단하고 리더가 되고 싶어하므로 먼저 자신에게 투표한 다음 각각 S1과 S2에 명령을 보내 리더가 되고 싶다는 의사를 표시합니다.

T3 시간에 S1은 S3에서 리더 투표 요청을 받습니다. S1은 Y에 투표했기 때문에 더 이상 다른 Sentry에 투표할 수 없으므로 S1은 N에 반대 의사를 표시합니다. 동시에 S2는 T2에서 S3이 보낸 리더 투표 요청을 받습니다. S2는 이전에 투표한 적이 없기 때문에 처음으로 투표 요청을 보낸 Sentinel에는 Y로 응답하고 나중에 투표 요청을 보낸 Sentinel에는 N으로 응답하므로 T3에서 S2는 S3에 응답하고 S3가 승인됨을 동의합니다. 리더.

T4에서 S2는 T1에서 S1이 보낸 투표 명령을 받습니다. S2는 T3에서 S3의 투표 요청에 동의했으므로 이때 S2는 S1에게 N으로 답장하여 S1이 리더가 되는 것을 반대합니다. 이는 S3과 S2 사이의 네트워크 트래픽이 정상인데 S1과 S2 사이의 네트워크 트래픽이 정체되어 투표 요청이 느리게 전송될 수 있기 때문입니다.

시간 T5에서 S1은 자신으로부터 Y 투표 1개를 받고 S2로부터 N 투표 1개를 받습니다. 자체 투표 Y 외에도 S3는 S2로부터 투표 Y를 받았습니다. 이때 S3는 리더 투표의 절반 이상을 얻었을 뿐만 아니라 미리 설정된 쿼럼 값(쿼럼은 2)에 도달하여 최종적으로 리더가 되었다.

그런 다음 S3는 마스터 선택 작업을 시작하고 새 마스터 라이브러리가 선택된 후 다른 슬레이브 라이브러리 및 클라이언트에 새 마스터 라이브러리 정보를 알립니다.

5. 새로운 마스터 라이브러리를 슬레이브 라이브러리와 클라이언트에 알립니다.

위의 연구를 통해 센티넬이 슬레이브 라이브러리의 IP 주소와 포트를 얻기 위해 마스터 라이브러리에 INFO 명령을 보낼 수 있음을 알게 되었습니다.

그러나 Sentinel은 마스터 및 슬레이브 라이브러리에만 연결할 수 없습니다. 왜냐하면 마스터-슬레이브 라이브러리가 전환된 후 클라이언트도 새로운 마스터 라이브러리에 요청 작업을 보내기 전에 새로운 마스터 라이브러리의 연결 정보를 알아야 하기 때문입니다. 따라서 Sentinel도 클라이언트에게 새로운 메인 라이브러리의 정보를 알려줘야 합니다.

그렇다면 클라이언트에게 새로운 메인 라이브러리의 정보를 어떻게 알려줄까요?

5.1 게시/구독 메커니즘에 기반한 클라이언트 이벤트 알림

본질적으로 Sentinel은 특정 모드에서 실행되는 Redis 인스턴스이지만 요청 작업을 수행하지 않고 모니터링, 마스터 선택 및 알림 작업만 완료합니다. 따라서 각 Sentinel 인스턴스는 pub/sub 메커니즘도 제공하며 클라이언트는 Sentinel에서 메시지를 구독할 수 있습니다.

아래 그림은 몇 가지 중요한 채널과 관련된 몇 가지 주요 이벤트를 보여줍니다. 기사 끝에 있는 링크 [3]에서 더 많은 채널을 확인할 수 있습니다.

클라이언트는 메인 라이브러리에서 Sentinel의 구성 파일을 읽은 후 Sentinel의 주소와 포트를 얻고 Sentinel과 네트워크 연결을 설정할 수 있습니다.

Sentinel이 새 마스터 라이브러리를 선택하면 클라이언트는 다음과 같은 switch-master 이벤트를 보게 됩니다. 이 이벤트는 기본 라이브러리가 전환되었으며 새 기본 라이브러리의 IP 주소 및 포트 정보가 이미 사용 가능함을 나타냅니다. 이때 클라이언트는 새로운 메인 라이브러리의 주소와 포트를 사용하여 통신할 수 있습니다.

switch-master <master name> <oldip> <oldport> <newip> <newport>

요약

지금까지 센트리의 직무와 세부 사항에 대한 학습을 ​​마쳤습니다. 이 글의 지식 소화 링크를 다음과 같이 정리했습니다.

在sentinel.conf中配置哨兵
-> 没有配置其他哨兵ip，怎么组成集群的？
-> 哨兵是怎么知道从库的IP和端口的？
-> 职责1：如何判断主从库下线了？
-> 职责2：如何选定新主库？
-> 由哪个哨兵执行主从切换？
-> 职责3：如何把新主库告诉客户端？

다음 콘텐츠에서 더 많은 기술 건조 제품을 계속 공유할 예정이니 계속 지켜봐 주시기 바랍니다. 공개 계정 "Student Yang technotes"는 기술 교류를 환영합니다.

본문에 언급된 링크

• [1] https://www.dbses.cn/technotes
• [2] https://github.com/redis/redis/blob/unstable/sentinel.conf
• [3] https://redis.io/docs/management/sentinel/#pubsub-messages

첨부된 Redis 문서

• http://www.redis.cn/topics/sentinel.html
• https://redis.io/docs/management/sentinel