-
Notifications
You must be signed in to change notification settings - Fork 0
docs(redis): 8편 HA와 토폴로지 - 단일/센티넬/클러스터, 리더 승격, 정합성, 장애 대처 #168
Copy link
Copy link
Open
Labels
area: blogBlog listing, post rendering, search, tags, or seriesBlog listing, post rendering, search, tags, or seriesarea: contentBlog post content changesBlog post content changesdocumentationImprovements or additions to documentationImprovements or additions to documentationtrack: redisRedis learning and mastery trackRedis learning and mastery tracktype: experimentHands-on experiment or verification taskHands-on experiment or verification task
Description
Metadata
Metadata
Assignees
Labels
area: blogBlog listing, post rendering, search, tags, or seriesBlog listing, post rendering, search, tags, or seriesarea: contentBlog post content changesBlog post content changesdocumentationImprovements or additions to documentationImprovements or additions to documentationtrack: redisRedis learning and mastery trackRedis learning and mastery tracktype: experimentHands-on experiment or verification taskHands-on experiment or verification task
상위 이슈
목적
Redis의 배포 토폴로지(단일 인스턴스, Sentinel, Cluster)가 각각 어떤 문제를 해결하는지 이해한다.
리더 승격(failover)이 어떻게 일어나며 그 과정에서 데이터 정합성이 어디까지 보장되는지 설명할 수 있어야 한다.
실제 장애("Redis가 죽었다") 상황에서 토폴로지별 대처 절차를 정리한다.
다룰 질문
토폴로지 (단일 / Sentinel / Cluster)
리더 승격 (failover 메커니즘)
quorum의 의미, 리더 Sentinel 선출, replica 승격은 누가 어떻게 결정하는가?데이터 정합성
min-replicas-to-write/min-replicas-max-lag,WAIT는 각각 무엇을 보장하고 무엇을 보장하지 못하는가?MIGRATING/IMPORTING,ASK/MOVED) 정합성은 어떻게 유지되는가?장애 대처 ("Redis가 죽었을 때")
실험 산출물
INFO replication,SENTINEL master <name>,CLUSTER NODES결과완료 조건
다음 세션 시작 지점
Sentinel failover 실험 기록과 정합성 한계 정리를 먼저 확인한다.