이 글은 Redis sentinel 모드의 원리에 대한 심층적인 이해를 제공하고, sentinel이 수행할 수 있는 작업에 대해 설명하고, sentinel 방법과 Sentinel 워크플로를 시작하는 데 도움이 되기를 바랍니다.
Redis Sentinel은 고가용성을 달성하기 위해 Redis에서 제공하는 공식 솔루션입니다. Redis Sentinel은 Redis에 고가용성을 제공합니다. 실제로 이는 Sentinel을 사용하면 특정 유형의 오류에 저항하고 사람의 개입 없이 자동으로 장애 조치를 구현하는 Redis 클러스터를 생성할 수 있음을 의미합니다. [관련 추천 : Redis 영상 튜토리얼]
1. Redis 클러스터 노드(마스터+복제본) 및 Sentinel 노드의 상태를 모니터링합니다
2. 자동 장애 조치: 마스터가 실패하면 Sentinel은 장애 조치를 구현하고 클라이언트에 새 마스터에 연결하도록 알릴 수 있습니다.
3. 알림: API를 통해 관리자, 개발자에게 알림을 보낼 수 있으며 모니터링되는 Redis 인스턴스가 실패합니다.
4. 구성 센터: 클라이언트가 센티널에 연결되고 센티널은 마스터에 액세스하고 노드 정보를 반환할 수 있습니다.
1.redis-sentinel /path/to/sentinel.conf
2.redis-server /path/to/sentinel.conf --sentinel
sentinel.
# 配置需要监控的master节点信息 2代表法定人数 作用是表示需要最少需要多少个sentinel节点同意 #master节点不可达才标记为客观下线 #举例 5个sentinel实例 quorum设置成2 那么有2个sentinel节点认为master不可达, #则其中一个会启动故障转移#如果至少有三个哨兵可到达,故障转移将被授权并实际启动。 sentinel monitor mymaster 127.0.0.1 6379 2 #只需要配置master sentinel会自动检测slave信息 sentinel down-after-milliseconds mymaster 60000 #如果master在指定时间内没有响应ping命令/或报错,则认为主观下线了。 sentinel failover-timeout mymaster 180000 sentinel parallel-syncs mymaster 1 #指定故障转移的时候,同时支持多少个replica并行的与master同步数据,越小故障转移越久 #以上配置可以通过SENTINEL SET command.来实时修改。 sentinel monitor resque 192.168.1.3 6380 4 sentinel down-after-milliseconds resque 10000 sentinel failover-timeout resque 180000 sentinel parallel-syncs resque 5
참고:
Redis-sentinel은 구성 파일을 사용하여 시작해야 합니다. 구성 파일에 따라 다시 시작을 복원해야 합니다. 포트 액세스는 기본적으로 Sentinel 간에 열려 있어야 합니다. 상호 접근을 용이하게 합니다.
1. 먼저 Sentinel은 Redis의 Pub/Sub 메커니즘을 통해 동적 인식을 구현합니다.
오프라인 목표:
주관적으로 오프라인인 노드가 마스터 노드인 경우 센티넬 노드는 sentinel is-masterdown-by-addr
명령을 통해 마스터 노드에 있는 다른 센티넬 노드의 판단을 구합니다. 센티넬 구성에 구성된 이 때 센티넬 노드는 실제로 마스터 노드에 문제가 있다고 판단하여 객관적으로 오프라인 상태라고 하는 대부분의 센티넬 노드가 오프라인 동작에 동의합니다.
목표 오프라인은 마스터 노드에만 적용되며 장애 조치가 발생합니다
3. 마스터가 오프라인이고 장애 조치가 필요합니다
이것은 두 단계로 나누어집니다. 먼저 센티넬 마스터를 선택해야 합니다. 노드를 사용하고 Sentinel 마스터 노드를 사용하여 Redis 장애 조치를 수행합니다.
먼저 센티넬이 리더를 선출합니다. 뗏목 알고리즘(상태 합의 알고리즘)을 사용합니다.
모든 Sentinel 노드는 리더가 될 수 있습니다. Sentinel 노드가 Redis 클러스터의 마스터 노드가 주관적으로 오프라인임을 확인하면 다른 Sentinel 노드가 리더로 선출되도록 요청합니다. 요청된 Sentinel 노드가 다른 Sentinel 노드의 선택 요청에 동의하지 않은 경우 해당 요청에 동의(선거 투표 + 1)하고, 그렇지 않으면 동의하지 않습니다.
Sentinel 노드가 얻은 선거 투표 수가 최소 리더 투표 수(최대 정족수 및 Sentinel 노드 수/2+1)에 도달하면 Sentinel 노드가 리더로 선출됩니다. 다시 실행됩니다.
뗏목 핵심 아이디어: 선착순, 소수가 다수에 복종합니다.
Sentinel이 마스터 노드를 선택한 후 Sentinel 마스터 노드는 Redis 클러스터 마스터 노드를 선택하여 새로운 클러스터 관계를 구축해야 합니다.
새 Redis 마스터 노드를 선택하는 기준은 다음과 같습니다.
1 Sentinel과의 연결이 끊어지는 시간입니다. 구성된 호스트 시간 초과 시간(밀리초 후)
2보다 오랫동안 기본 센티널 서버에서 연결이 끊어진 것으로 발견된 복제본 슬레이브를 필터링합니다. 복제본 우선순위가 낮은 항목에 우선순위를 부여합니다.
3. 우선순위가 동일하면 복사 오프셋이 처리된 것입니다. 값이 클수록 우선순위가 높아지며 이는 비즈니스 시나리오 기능에 더 부합합니다.
4. 복사 오프셋이 동일한 경우 실행 ID를 확인하세요. 작은 것을 선호하십시오.
마스터 노드를 선택한 후 클러스터 관계 유지를 시작하세요.
1. Sentinel 노드는 새로운 마스터 노드에 슬레이브 no one 명령을 보내 독립 노드로 만듭니다.
2. Sentinel 노드, 다른 노드에 슬레이브 IP 포트를 보내고 마스터 노드로 이동합니다.
위 분석을 통해 Sentinel은 예약 모니터링을 통해 자동 장애 조치를 수행할 수 있습니다. 그러나 Sentinel에는 여전히 몇 가지 문제가 있습니다. 예를 들어 단일 마스터 노드의 경우 데이터 손실 가능성이 있으며, 단일 시스템은 제한되어 있으며 수평 확장 기능이 없습니다.
위 내용은 Redis에서 감시 모드의 원리를 분석하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!