안녕하세요, 여기 redis 기사 시리즈가 있습니다. 이 기사는 [redis basics] sentinel, 이전 링크: [redis] redis master-slave replication_Work hard and work hard mlx's blog-CSDN 블로그
목차
마스터 1개와 슬레이브 2개로 redis 인스턴스를 시작하고, 센티널을 구성하고, 정상적인 마스터-슬레이브 복제 시연
Redis 서버를 수동으로 종료하면 시뮬레이션된 호스트가 중단됩니다.
마스터가 전화를 끊은 후 슬레이브의 변경 사항을 확인합니다.
King of Soldiers는 장애 조치를 켜고 새 마스터를 선출합니다.
모든 관리들이 고개를 숙이고 황제와 신하들이 보스를 다시 알아보았습니다.
옛 스승이 숭배하고, 그가 돌아왔을 때 옛 스승을 설득해야 한다
개념
센티널은 쉽게 말해 백그라운드에서 마스터 호스트의 이상 여부를 감시하고 감시하는 내부고발자로서, 실패할 경우 득표수에 따라 자동으로 특정 슬레이브 데이터베이스를 새로운 마스터 데이터베이스로 전환하고 계속 진행한다. 외부 세계에 봉사하기 위해.
효과
Sentinel에는 다음과 같은 네 가지 주요 기능이 있습니다.
- 마스터-슬레이브 모니터링
- 마스터-슬레이브 redis 라이브러리가 정상적으로 실행되고 있는지 모니터링
- 공고
- Sentry는 장애 조치 결과를 클라이언트에 보낼 수 있습니다.
- 장애 조치
- 마스터가 비정상인 경우 마스터-슬레이브 전환이 수행되고 슬레이브 중 하나가 새 마스터로 사용됩니다.
- 구성 센터
- 클라이언트는 Sentinel에 접속하여 현재 Redis 서비스의 마스터 노드 주소를 얻습니다.
Sentinel의 주요 기능을 한 문장으로 요약하면 다음과 같습니다.
1. 마스터 및 슬레이브를 포함한 redis 실행 상태 모니터링
2. 마스터가 다운되면 자동으로 슬레이브를 새 마스터로 전환할 수 있습니다.
Sentinel 사용 방법(사례 데모 + 실제 단계)
Redis Sentinel 아키텍처 미리 설명
redis sentry의 역할을 확인하기 위한 구성은 다음과 같습니다.
- 3 센티넬
- 클러스터를 자동으로 모니터링 및 유지 관리하고 데이터를 저장하지 않고 모니터링만 합니다.
- 1 마스터 2 슬레이브
- 데이터 읽기 및 저장용
- /myredis 디렉토리에 sentinel.conf 생성 또는 복사
- 먼저 redis 압축 해제 디렉토리에 있는 기본 sentinel.conf 파일의 내용을 살펴보십시오.
주요 매개변수 구성
Sentinel 파일 매개변수(리더)
클라이언트 연결에 사용되는 바인드 서비스 수신 주소(기본적으로 로컬 주소)
백그라운드 데몬으로 실행할지 여부 데몬화
보호 모드 보안 보호 모드
포트 포트
로그 파일 로그 파일 경로
pidfile pid 로그 경로
dir 작업 디렉토리
센티널 모니터 <마스터> <redis-port> <쿼럼>
마스터 쿼름을 모니터링하도록 설정한다는 것은 최소한 몇 명의 센트리가 객관적으로 오프라인으로 전환하고 오류 마이그레이션에 대한 법정 투표 수에 동의한다는 것을 의미합니다.
우리는 네트워크가 신뢰할 수 없다는 것을 알고 있습니다.때때로 Sentinel은 네트워크 정체로 인해 마스터 Redis가 죽었다고 잘못 생각할 수 있습니다 .Sentinel 클러스터 환경에서 여러 Sentinel은 마스터가 실제로 죽었는지 확인하기 위해 서로 통신해야 합니다 .매개 변수 쿼럼은 객관적인 오프라인의 기반입니다. 즉, 적어도 쿼럼 센티넬은 마스터에 결함이 있다고 믿고 마스터가 오프라인 상태가 되어 장애 조치를 취할 것임을 의미합니다. 때때로 Sentinel 노드는 자체 네트워크 문제로 인해 마스터에 연결하지 못할 수 있으며 현재 마스터에 결함이 없으므로 다음으로 진행하기 전에 여러 Sentinel이 마스터에 문제가 있음을 동의해야 합니다. 공정성과 고가용성을 보장하는 단계적 운영
sentinel auth-pass <master-name> <password> // 비밀번호를 통해 마스터에 접속
//비밀번호를 통해 호스트에 연결합니다. 여기에서 호스트의 구성 파일이더라도 이를 구성해야 합니다. 기본이며 슬레이브로 인식됩니다. 이 때 그는 또한 새 호스트에 연결해야 합니다.
이 경우에 대한 공통 파일 구성
다음 센티널 구성 파일을 구성합니다.
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.111.169 6379 2
sentinel auth-pass mymaster 111111
sentinel26380.conf
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.111.169 6379 2
sentinel auth-pass mymaster 111111sentinel26379.conf
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.111.169 6379 2
sentinel auth-pass mymaster 111111sentinel 파일의 기타 구성 정보
sentinel down-after-milliseconds <master-name> <milliseconds>：
指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线
sentinel parallel-syncs <master-name> <nums>：
表示允许并行同步的slave个数，当Master挂了后，哨兵会选出新的Master，此时，剩余的slave会向新的master发起同步数据
sentinel failover-timeout <master-name> <milliseconds>：
故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败
sentinel notification-script <master-name> <script-path> ：
配置当某一事件发生时所需要执行的脚本
sentinel client-reconfig-script <master-name> <script-path>：
客户端重新配置主节点参数脚本마스터 1개와 슬레이브 2개로 redis 인스턴스를 시작하고, 센티널을 구성하고, 정상적인 마스터-슬레이브 복제 시연
|
1
|
169 머신에 새 redis6379.conf 구성 파일을 생성합니다. 이 경우와 일치하도록 masterauth 항목의 액세스 비밀번호를 111111로 설정하십시오.
그렇지 않으면 나중에 오류가 보고될 수 있습니다. master_link_status:down
|
|
2
|
172 머신에서 새 redis6380.conf 구성 파일을 생성하고 <masterip> <masterport>의 복제본을 설정합니다.
|
|
삼
|
173 머신에서 새 redis6381.conf 구성 파일을 생성하고 <masterip> <masterport>의 복제본을 설정합니다.
|
이전 장에서 구성한 하나의 마스터와 두 개의 슬레이브를 기반으로 호스트 redis6379.conf를 변경해야 합니다.
redis6379.conf
6379는 나중에 슬레이브가 될 수 있습니다. 새 호스트에 액세스하려면 비밀번호를 설정해야 합니다. masterauth 항목의 액세스 비밀번호를 111111로 설정하십시오.
레디스 6380.conf
특정 IP 주소와 암호는 현지 실제 상황에 따라 수정해야 합니다.
레디스 6381.conf
하나의 마스터와 두 개의 슬레이브 시작
6379.conf
redis-server /myredis/redis6379.conf
redis-cli -a 111111 -p6379
6380.conf
redis-server /myredis/redis6380.conf
redis-cli -a 111111 -p 6380
6381.conf
redis-server /myredis/redis6381.conf
redis-cli -a 111111-p 6381
센티넬 시작
redis-sentinel sentinel26379.conf --sentinel
redis-sentinel sentinel26380.conf --sentinel
redis-sentinel sentinel26381.conf --sentinel센티넬 정보 보기
마스터-슬레이브 복제 정보를 확인하고 모든 것이 정상인지 확인
호스트가 다운되었습니다. 로그를 확인하세요.
Redis 서버를 수동으로 종료하면 시뮬레이션된 호스트가 중단됩니다.
마스터가 전화를 끊은 후 슬레이브의 변경 사항을 확인합니다.
발생할 수 있는 문제:
깨진 파이프에 대한 특정 설명:
|
끊어진 파이프 알기
|
파이프는 파이프라인을 의미하며 파이프라인 내부에는 일반적으로 파일 또는 네트워크 소켓에서 읽은 데이터인 데이터 스트림이 있습니다.
파이프가 다른 쪽에서 갑자기 닫히면 데이터가 갑자기 중단되어 끊어집니다.소켓의 경우,
네트워크가 연결되지 않았거나 다른 쪽 프로세스가 충돌했을 수 있습니다.
|
|
문제를 풀다
|
사실 예외가 발생해도 서버에 큰 영향을 주지는 않는다. 이 오류는 프로세스를 갑자기 종료한 클라이언트로 인해 발생할 수 있습니다.
|
|
요약깨진 파이프
|
이 예외는 클라이언트가 읽기 시간을 초과하여 연결을 닫은 것입니다. 이때 서버는 클라이언트를 보냅니다.
끊어진 연결이 데이터를 쓸 때 끊어진 파이프 예외가 발생합니다!
|
요약하면, 마스터의 끊기는 슬레이브에 일시적인 영향을 미치므로 이러한 문제가 발생하면 당황하지 말고 동일한 명령을 다시 입력하십시오.
사본 정보 보기 계속하기
6380
6381
6381이 호스트가 된 것을 발견했습니다.
구성 파일 비교
이전 마스터 vim redis6379.conf
redis6379 오프라인
vim redis6380.conf
새 마스터 vim redis6381.conf
우리는 다음과 같은 결론에 도달합니다.
- 이 문서의 sentinel26379.log, sentinel26380.log 및 sentinel26381.log는 작업 중에 동적으로 변경됩니다.
- 마스터-슬레이브 스위치에서 redis###.conf 파일의 내용이 자동으로 변경됩니다.
또한 Sentinel에서 한 줄에 하나씩 여러 마스터를 모니터링할 수 있습니다.
Sentinel의 운영 프로세스 및 선정 원칙
마스터-슬레이브 구성의 마스터가 실패하면 Sentinel은 원래 마스터의 작업을 인계할 새 마스터를 선택할 수 있으며 마스터-슬레이브 구성의 다른 Redis 서버는 자동으로 새 마스터를 가리켜 데이터를 동기화합니다. 일반적으로 특정 Sentinel이 마스터에 연결할 수 없어 실수로 전환되는 것을 방지하기 위해 홀수 개의 Sentinel을 사용하는 것이 좋습니다.
주관적인 오프라인과 객관적인 오프라인
SDOWN 주관적 오프라인
1. SDOWN은 하나의 Sentinel이 주관적으로 감지한 Master의 상태로 Sentinel의 입장에서 보면 PING heartbeat를 보낸 후 일정 시간 내에 정당한 회신을 받지 못하면 SDOWN 조건 2가 성립한다
. -sentinel 구성 파일의 after-milliseconds는 주관적인 오프라인 판단 시간을 설정합니다.
소위 주관적 다운(Subjectively Down, SDOWN이라고 함)은 단일 Sentinel 인스턴스가 서버에 대해 내리는 오프라인 판단 , 즉 단일 Sentinel이 서비스가 오프라인이라고 생각하는 것입니다(구독이 불가능할 수 있음). 수신, 그들 사이의 네트워크가 연결되지 않은 등 및 기타 이유). 주관적 오프라인은 서버가 PING 명령에 응답하지 않거나 [sentinel down-after-milliseconds]의 지정된 밀리초 내에 오류 메시지를 반환하는 경우 Sentinel이 주관적으로(일방적으로) 마스터를 사용할 수 없는 것으로 간주함 예 , o (╥﹏╥)o
Sentinel down-after-milliseconds <마스터 이름> <타임아웃>
현재 Sentinel 인스턴스에 의해 마스터가 유효하지 않은 것으로 간주되는 간격 시간을 나타냅니다. 이 구성은 실제로 주관적인 오프라인
마스터가 Sentine에 유효한 정보를 반환하지 않은 기간은 마스터가 주관적으로 오프라인 상태인 것으로 간주됩니다. 즉, 오랜 시간 동안 redis-servevr에 접속하지 않으면 redis-server가 SDOWN 상태에 들어간 것으로 간주합니다.
ODOWN 목표 오프라인
ODOWN은 일정 수의 센티넬이 필요하며 여러 센티널이 합의에 도달하여 마스터가 객관적으로 다운된 것으로 간주할 수 있습니다.
네 가지 매개변수의 의미:
masterName은 마스터+슬레이브 조합의 구별 식별자입니다(센티넬 세트는 마스터+슬레이브 조합의 여러 그룹을 모니터링할 수 있음).
매개 변수 정족수는 객관적인 오프라인의 기초 , 정족수/투표 정족수 입니다.
즉, 최소한 쿼럼 센티넬은 마스터가 오프라인 상태가 되어 장애 조치를 취하기 전에 마스터에 결함이 있다고 생각합니다. 때로는 센티넬 노드가 자체 네트워크로 인해 마스터에 연결하지 못할 수 있지만 현재로서는 마스터에 결함이 없으므로 다음 단계로 진행하기 전에 여러 센티넬이 마스터에 문제가 있음을 동의해야 합니다. . 이는 공정성과 고가용성을 보장합니다.
선거 지도자 센티넬 (센티넬에서 군인의 왕을 선택)
- 마스터노드가 객관적으로 오프라인 상태라고 판단되면 각 센티넬노드가 협상하여 군에서 리더 센티넬노드를 선출하고 리더노드는 페일오버(fault migration)를 수행한다.
- Raft 알고리즘은 리더 노드를 선택합니다.
마스터 노드를 모니터링하는 모든 Sentinel이 리더로 선출될 수 있음 선출에 사용되는 알고리즘은 Raft 알고리즘이며 Raft 알고리즘의 기본 아이디어는 선착순, 즉 선거 라운드에서 , Sentinel A는 B에게 리더가 되라는 메시지를 보냅니다. , B가 다른 Sentinel에 동의하지 않으면 A를 리더로 동의합니다.
로그 변경
King of Soldiers는 장애 조치를 켜고 새 마스터를 선출합니다.
새로운 군주가 즉위
슬레이브 후보가 새로운 마스터가 되어 새로운 마스터 규칙을 선택하게 되는데 , redis.conf 파일에서
나머지 슬레이브 노드가 건강한 상태라는 조건 하에서 우선순위가 가장 높은 슬레이브 노드인 slave-priority 또는 replica-priority(숫자가 작을수록) , 우선 순위가 높을수록)
오프셋 위치가 가장 큰 슬레이브 노드(로그에서 레코드 수가 가장 많은 노드)와
Run ID가 가장 작은 슬레이브 노드 즉, 사전순으로 ASCII 코드로 복사
모든 관리들이 고개를 숙이고 황제와 신하들이 보스를 다시 알아보았습니다.
slaveof no one 명령을 실행하여 선택한 슬레이브 노드를 새 마스터 노드로 만들고, slaveof 명령을 사용하여 다른 노드를 슬레이브 노드로 만듭니다.Sentinel 리더는 선출된
새 마스터에 대해 slaveof no one 작업을 실행하고 마스터로 승격합니다. 마스터 노드
Sentinel 리더는 다른 슬레이브에 명령을 보내 나머지 슬레이브를 새 마스터 노드의 슬레이브로 만듭니다.
옛 스승이 숭배하고, 그가 돌아왔을 때 옛 스승을 설득해야 한다
이전에 오프라인이었던 이전 마스터를 새로 선출된 새 마스터의 슬레이브 노드로 설정합니다. 이전 마스터가 다시 온라인 상태가 되면 새 마스터의 슬레이브 노드가 됩니다. 센티넬 리더는 원래 마스터를 슬레이브로 강등하고 재개합니다. 정상적인 작업.
Sentinel 사용을 위한 제안
- Sentinel 노드의 수는 여러 개가 되어야 하며 고가용성을 보장하기 위해 Sentry 자체가 클러스터링되어야 합니다.
- 센티넬 노드의 수는 홀수여야 합니다.
- 각 감시 노드의 구성은 일관되어야 합니다.
- Sentinel 노드가 Docker와 같은 컨테이너에 배포된 경우 올바른 포트 매핑에 주의하십시오.
- Sentinel 클러스터 + 마스터-슬레이브 복제는 제로 데이터 손실을 보장하지 않습니다.