Redis 클 러 스 터 구축 Sentinel 상세 설명
Redis 는 메모리 데이터베이스 로 서 높 은 사용 가능 한 특징 을 가 져 야 합 니 다.그렇지 않 으 면 서버 가 다운 되면 메모리 에 있 는 데 이 터 를 잃 어 버 릴 수 있 습 니 다.우리 가 가장 자주 사용 하 는 높 은 방법 은 바로 클 러 스 터 를 구축 하 는 것 입 니 다.master 기 계 를 끊 으 면 slave 기 계 를 꼭대기 에 올 려 서 서 서 비 스 를 계속 제공 할 수 있 습 니 다.그러나 레 디 스 클 러 스 터 는 주종 전환 을 자동 으로 하지 않 는 다.즉,메 인 노드 가 매우 무기력 하 게 새벽 3 시 에 끊 으 면 운영 학생 들 은 바로 일어나 노드 에서 메 인 노드 로 바 꾸 어야 한다.이런 조작 은 매우 번 거 롭 고 비효 율 적 이다.이 를 위해 Redis 는 공식 적 으로 해결 방안 을 제공 했다.Redis Sentinel
간단 한 소개
Redis Sentinel 클 러 스 터 는 보통 3~5 개의 노드 로 구성 되 는데 개별 노드 가 끊 기 면 클 러 스 터 가 정상적으로 작 동 할 수 있다.레 디 스 군집 의 건강 상 태 를 감시 하 는 일 을 맡 고 있다.메 인 노드 가 끊 기 면 Sentinel 클 러 스 터 는 투 표를 통 해 새로운 메 인 노드 를 선택 합 니 다.원래 의 메 인 노드 가 복 구 될 때 새로운 메 인 노드 로 노드 에서 Redis 군집 에 다시 가입 합 니 다.
기본 원리
Sentinel 클 러 스 터 는 지정 한 설정 파일 을 통 해 master 를 발견 하여 모니터링 하고 info 명령 을 보 내 master 의 노드 정 보 를 얻 습 니 다.Sentinel 클 러 스 터 의 노드 는 감시 하 는 메 인 노드 에 hello 정보(Sentinel 자체 의 ip,포트 와 id 등 내용 포함)를 보 내 다른 Sentinel 에 게 자신의 존 재 를 알 립 니 다.
Sentinel 클 러 스 터 는 구독 연결 을 통 해 다른 Sentinel 의 hello 정 보 를 받 습 니 다.
Sentinel 클 러 스 터 는 ping 명령 을 통 해 모니터링 의 인 스 턴 스 상 태 를 검사 합 니 다.지정 한 시간 내 에 되 돌아 오지 않 으 면 이 인 스 턴 스 가 오프라인 이 라 고 생각 합 니 다.
Sentinel 이 failover 주종 전환 을 터치 하면 바로 진행 되 지 않 습 니 다.지정(quorum)Sentinel 만 권한 을 부여 한 후 master 노드 는 ODOWN 상태 로 표 시 됩 니 다.이제 야 새로운 master 를 선택 하 는 투 표를 시작 했다.
Sentinel 은 새로운 master 를 선택 하 는 원칙 은 우선 우선 우선 순 위 를 판단 하고 우선 순위 가 작은 것 을 선택 하 는 것 이다.우선 순위 가 같 으 면 복사 아래 표 시 를 보고 복사 데이터 가 많은 것 을 선택 하 십시오.아래 표 시 를 복사 하 는 것 도 같 으 면 프로 세 스 ID 가 작은 것 을 선택 하 십시오.
Sentinel 이 권한 을 수 여 받 으 면 지 워 진 master 의 최신 설정 버 전 번호(config-epoch)를 얻 을 수 있 습 니 다.failover 가 실 행 된 후에 이 버 전 번 호 는 최신 설정 에 사 용 됩 니 다.라디오 형식 으로 다른 Sentinel 에 게 알 리 고 다른 Sentinel 은 master 에 대한 설정 을 업데이트 합 니 다.
기본 사용
우 리 는 Python 을 예 로 들 어 클 라 이언 트 에서 Sentinel 을 어떻게 사용 하 는 지 간단하게 설명 합 니 다.
from redis.sentinel import Sentinel
if __name__ == '__main__':
sentinel = Sentinel(['localhost', 26379], socket_timeout=0.1)
print(sentinel.discover_master('mymaster'))
print(sentinel.discover_slaves('mymaster'))
master = sentinel.master_for('mymaster', socket_timeout=0.1)
slave = sentinel.slave_for('mymaster', socket_timeout=0.1)
master.set('follow', 'Jackeyzhe2018')
follow = slave.get('follow')
print(follow)
master_for 와 slavefor 방법 은 연결 풀 에서 연결 하 나 를 꺼 내 사용 하고 주소 가 여러 개 있 으 면 폴 링 방법 을 사용 합 니 다.redis 가 주종 전환 이 발생 했 을 때 클 라 이언 트 는 주소 가 변경 되 었 다 는 것 을 어떻게 알 았 습 니까?우 리 는 redis-py 의 소스 코드 에서 답 을 찾 아 보 자.
redis 가 새로운 연결 을 만 들 때 get 을 호출 하 는 것 을 볼 수 있 습 니 다.master_address 방법 으로 메 인 노드 주 소 를 가 져 옵 니 다.get_master_address 방법 에서 클 라 이언 트 는 먼저 메 인 노드 주 소 를 조회 한 다음 에 메모리 의 주소 와 비교 합 니 다.일치 하지 않 으 면 연결 을 끊 고 새로운 주소 로 다시 연결 합 니 다.
만약 에 메 인 노드 가 끊 기지 않 았 고 Sentinel 이 주동 적 으로 주종 전환 을 했 기 때문에 이런 상황 에 대해 redis-py 도 처리 했다.ReadOnly Error 의 이상 을 포착 하고 연결 을 끊 으 면 후속 명령 이 다시 연결 되 어야 합 니 다.물론 수정 명령 이 없 으 면 연결 이 전환 되 지 않 지만 데이터 가 파괴 되 지 않 아 영향 이 크 지 않다.
건설 에 착수 하 다
Sentinel 의 작업 원리 와 사용 방법 에 대해 우 리 는 이미 대략적인 인식 을 가지 게 되 었 다.이 해 를 깊이 있 게 하기 위해 우 리 는 스스로 Sentinel 군집 을 만 들 었 다.
우선 우리 에 게 필요 한 redis 군집 환경 을 구축 합 니 다.
redis 를 설치 한 후 redis 디 렉 터 리 에 있 는 프로필 redis.conf 를 3 부 복사 합 니 다.각각 redis 6379.conf,redis 6380.conf,redis 6381.conf 라 고 명명 되 었 습 니 다.
redis 6381.conf 파일 에서 다음 과 같은 몇 가지 항목 을 수정 합 니 다.
bind 127.0.0.1
port 6381
logfile "6381.log"
dbfilename "dump-6381.rdb"
redis 6379.conf 에서 수정
bind 127.0.0.1
port 6379
logfile "6379.log"
dbfilename "dump-6379.rdb"
slaveof 127.0.0.1 6381
redis 6380.conf 의 수정 은 redis 6379.conf 를 참조 합 니 다.수정 이 끝 난 후 각각 세 개의 인 스 턴 스 를 시작 합 니 다.우리 가 원 하 는 redis 주종 환경 을 만 들 었 습 니 다.마스터 노드 를 연결 하면 마스터 설정 정 보 를 볼 수 있 습 니 다.
이어서 우 리 는 Sentinel 군집 을 설정 합 니 다.여기 서 우 리 는 똑 같이 세 개의 인 스 턴 스 를 설정 합 니 다.sentinel.conf 파일 3 부 를 복사 하여 각각 sentinel-26379.conf,sentinel-26380.conf 와 sentinel-26381.conf 라 고 명명 합 니 다.
sentinel-26379.conf 파일 에서 다음 내용 편집
port 26379
daemonize yes
logfile "26379.log"
dir /home/xxx/redis/data
sentinel monitor mymaster 127.0.0.1 6381 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel-26380.conf 와 sentinel-26381.conf 의 내용 은 상기 와 유사 하 다.설정 이 끝 난 후,우 리 는 명령 redis-sentinel 을 사용 하여 세 개의 sentinel 인 스 턴 스 를 시작 합 니 다.이때,우 리 는 redis-cli 명령 으로 26379 의 인 스 턴 스 를 연결 하여 sentinel 의 정 보 를 봅 니 다.
그것 이 우리 의 세 개의 redis 노드 를 감시 하기 시작 한 것 을 발견 했다.이때 우리 의 전체 군집 이 배치 되 었 으 니 다음 에 테스트 해 보 자.
kill master 노드 를 제거 하고 sentinel 로 그 를 보면 sentinel 이 앞에서 말 한 절차 에 따라 새로운 master 를 선택 한 것 을 발견 할 수 있 습 니 다.
이 때 sentinel 메 시 지 를 보 겠 습 니 다.
이때 6380 은 이미 새로운 master 가 되 었 다.
축하합니다.이제 새벽 에 일어나 서 Redis 주종 인 스 턴 스 를 바 꿀 필요 가 없습니다.
요약:
이상 은 이 글 의 전체 내용 입 니 다.본 논문 의 내용 이 여러분 의 학습 이나 업무 에 어느 정도 참고 학습 가치 가 있 기 를 바 랍 니 다.궁금 한 점 이 있 으 시 면 댓 글 을 남 겨 주 셔 서 저희 에 대한 지지 에 감 사 드 립 니 다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
Redis 해시에 대한 완벽한 가이드변경 가능하므로 필요에 따라 쉽게 변경하고 업데이트할 수 있습니다. Redis 해시는 구조가 평평하므로 JSON에서와 같이 여러 수준을 가질 수 없습니다. redis 해시의 명명 규칙은 hash:key 로 입력되므로...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.