Redis Sentinel, Sentinel 구성 과정, Sentinel 운영 과정 및 선출 원리(주관 오프라인, 객관적 오프라인, Sentinel 리더 선출 방법)에 대해 자세히 설명합니다.

Redis Sentinel(센티넬)

센티넬이란 무엇인가요?

내부 고발자는 백그라운드 마스터 호스트에 결함이 있는지 검사하고 모니터링하며, 실패할 경우 투표 수에 따라 슬레이브 데이터베이스를 새로운 마스터 데이터베이스로 자동 변환하여 외부 서비스를 계속합니다. [관련 권장 사항: Redis 동영상 튜토리얼]

일반적으로 무인 운영 및 유지 관리로 알려져 있습니다.

뭐하고 있어요?

• 마스터-슬레이브 모니터링: 마스터-슬레이브 Redis 라이브러리가 정상적으로 실행되는지 모니터링
• 메시지 알림: Sentinel이 장애 조치 결과를 클라이언트에 보낼 수 있음
• 장애 조치: 슬레이브 중 하나를 새로운 마스터로 사용
• 구성 센터 : 클라이언트 클라이언트는 sentinel

Case

Architecture

3 Sentinels에 연결하여 현재 Redis 서비스의 마스터 노드 주소를 얻습니다. 클러스터를 자동으로 모니터링하고 유지하며 데이터를 저장하지 않고 내부 고발자에 불과합니다.

1 Mas 모니터링할 마스터 서버를 설정하세요

정족수: 객관적으로 오프라인 상태인 최소 센티넬 수를 확인하세요. 장애 조치를 승인하기 위한 투표 쿼럼입니다.

cp sentinel.conf /myredis/sentinel26379.conf

• vim sentinel26379.conf
      
  bind 0.0.0.0
      
  # protected-mode yes 修改为 protected-mode no
  protected-mode no
  
  # daemonize no 修改为 daemonize yes
  daemonize yes
  
  # port 
  port 26379
  
  # pid文件名字，pidfile
  pidfile /var/run/redis_26379.pid
      
  # log文件名字，logfile（修改 logfile "" 为 logfile "/myredis/26379.log"）
  logfile "/myredis/26379.log"
  
  # 指定当前的工作目录（修改 dir /temp 为 dir /myredis）
  dir /myredis

  로그인 후 복사
  우리는 네트워크가 불안정하다는 것을 알고 있습니다. 때로는 센티널 클러스터 환경에서 센티널이 마스터 Redis가 죽었다고 잘못 생각할 수도 있습니다. 마스터가 실제로 죽었는지 확인하기 위해 더 많은 센티널이 서로 통신해야 합니다. 쿼럼 매개변수는 객관적인 오프라인의 기초입니다. 즉, 적어도 쿼럼 센티널은 마스터에 결함이 있다고 생각하고 그러면 마스터도 오프라인 상태가 되어 결함이 발생하게 됩니다. 옮기다. 때로는 센티넬 노드가 자신의 네트워크 문제로 인해 마스터에 연결하지 못하는 경우가 있는데, 이때는 마스터에 결함이 있는 것이 아니기 때문에 여러 센티넬이 마스터에 문제가 있다는 점에 동의한 후 노드를 진행해야 합니다. 다음 단계로 공정성과 고가용성을 보장합니다.

• 3개의 Linuxip와 포트를

  # sentinel monitor <master-name> <ip> <redis-port> <quorum>

  로그인 후 복사

  설치하세요. 3개의 sentinel

  sentinelxxxx.conf 파일sentinel00

  sentinel26379.conf

  # sentinel auth-pass <master-name> <password>

  로그인 후 복사

  sentinel01

  을 구성하세요.
sentinel26380.conf

# sentinel00
192.168.157.112    26379
# sentinel01
192.168.157.113    26380
# sentinel02
192.168.157.118    26381

sentinel02

sentinel26381 .conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 26379
logfile "/myredis/sentinel26379.log"
pidfile /var/run/redis-sentinel26379.pid
dir /myredis
sentinel monitor mymaster 192.168.157.115 6379 2
sentinel auth-pass mymaster 1234

Test

이전 Redis 복제를 바탕으로 마스터 1개와 슬레이브 2개를 시작하여 마스터-슬레이브 복제가 정상인지 테스트하고, info 복제를 입력하여 정상인지 확인

센티넬 3개 시작 그리고 모니터링을 완료하세요

bind 0.0.0.0
daemonize yes
protected-mode no
port 26380
logfile "/myredis/sentinel26380.log"
pidfile /var/run/redis-sentinel26380.pid
dir /myredis
sentinel monitor mymaster 192.168.157.115 6379 2
sentinel auth-pass mymaster 1234

마스터-슬레이브 복제 테스트 중 모든 것이 정상입니다

로그 보기

• sentinel.conf
• rrre 에

  -

마스터 다운타임 시뮬레이션

bind 0.0.0.0
daemonize yes
protected-mode no
port 26381
logfile "/myredis/sentinel26381.log"
pidfile /var/run/redis-sentinel26381.pid
dir /myredis
sentinel monitor mymaster 192.168.157.115 6379 2
sentinel auth-pass mymaster 1234

로그인 후 복사

• Question

두 슬레이브 머신의 데이터가 정상인가요? (예)

• 데이터를 얻으려면 절약하세요

  2. 새 마스터 보기
마스터는 다시 작성하고 시작하지 않습니다. 승천을 다시 시작하세요.

• 구성 파일 비교

• sentinel6379.conf 파일

• 新master

哨兵运行流程和选举原理

当一个主从配置中的master失效后，sentinel可以选举出一个新的master用于自动替换原master的工作，主从配置中的其他redis服务自动指向新的master同步数据，一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换。

SDown主观下线(Subjectively Down)

SDOWN（主观不可用）是单个哨兵自己主观检测到的关于master的状态，从sentinel的角度来看，如果发送了PING心跳后，在一定时间内没有收到合法的回复，就到达了SDOQN的条件。

sentinel配置文件中的 down-after-milliseconds 设置了主观下线的时间长度（默认30秒）。

# sentinel down-after-milliseconds <masterName> <timeout>
sentinel down-after-milliseconds mymaster 30000

ODown客观下线(Objectively Down)

ODOWN需要一定数量的sentinel，多个哨兵达成一致意见才能确认一个master客观上已经宕机了。

# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2

选举出领导者哨兵

当主节点被判断客观下线后，各个哨兵节点会进行协商，先选举出一个领导者哨兵节点，并由该领导者哨兵节点进行failover（故障迁移）

领导者哨兵如何选出来的？

Raft算法

监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得，即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者。

选新的master（im）

整个过程由sentinel自己独立完成，无需人工干涉。

新主登基

某一个slave被选中成为master

选出新的master的规则，剩余slave节点健康的前提下

1. redis.conf文件中，优先级slave-priority或者replica-priority最高节点（数字越小优先级越高）
2. 复制偏移量offset最大的从节点。
3. 最小Run ID的从节点。

群臣俯首

• 执行 slaveof no one 命令让选出来的从节点成为新的主节点，并通过 slaveof 命令让其他节点成为其从节点。

• sentinel leader 会对选举出来的新 master 执行 slaveof no one，将其提升为master节点

• sentinel leader 向其他slave发送命令，让剩余的slave成为新的master节点的slave。

旧主拜服

• 将之前的已经下线的旧master设置为新选出的新master的从节点，当旧master重新上线后，它会成为新master的从节点
• sentinel leader 会让原来的master降级为slave并恢复正常工作。

哨兵使用建议

• 哨兵节点数量应该为多个，哨兵本身应该为集群，保证高可用
• 哨兵节点数量应该是奇数
• 各个哨兵节点的配置应该一致
• 如果哨兵节点部署在docker等容器里面，尤其要注意端口的正确映射
• 哨兵集群 + 主从复制，并不能保证数据零丢失

更多编程相关知识，请访问：编程视频！！

위 내용은 Redis의 센티널에 대해 자세히 이해하기의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!