Sentinel — 자동 페일오버와 고가용성

┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│ Sentinel #1 │  │ Sentinel #2 │  │ Sentinel #3 │
└──────┬──────┘  └──────┬──────┘  └──────┬──────┘
       │                │                │
       └────────┬───────┴────────┬───────┘
                │                │
         ┌──────┴──────┐  ┌─────┴───────┐
         │   Master    │  │  Replica 1  │
         └─────────────┘  └─────────────┘
                          ┌─────────────┐
                          │  Replica 2  │
                          └─────────────┘

# 기본 설정
port 26379
sentinel monitor mymaster 192.168.1.100 6379 2
# mymaster: 마스터 이름
# 192.168.1.100 6379: 마스터 주소
# 2: 쿼럼 (페일오버에 동의해야 하는 Sentinel 수)

# 다운 판정 시간 (밀리초)
sentinel down-after-milliseconds mymaster 5000
# 5초간 응답 없으면 SDOWN

# 페일오버 타임아웃
sentinel failover-timeout mymaster 60000

# 동시에 새 마스터로 동기화하는 레플리카 수
sentinel parallel-syncs mymaster 1

# 인증
sentinel auth-pass mymaster "마스터비밀번호"

# 방법 1
redis-sentinel /path/to/sentinel.conf

# 방법 2
redis-server /path/to/sentinel.conf --sentinel

Sentinel → PING → Master
         ← 응답 없음 (down-after-milliseconds 초과)

→ 이 Sentinel이 마스터를 SDOWN으로 표시
  (주관적 판단 — 이 Sentinel만의 의견)

SDOWN을 감지한 Sentinel이 다른 Sentinel에게 확인:
"마스터가 다운된 것 같은데, 너희도 그렇게 보여?"

쿼럼(예: 2) 이상이 동의하면 → ODOWN (객관적 다운)

ODOWN이 확정되면 페일오버를 실행할 리더를 선출
- Raft 유사 알고리즘으로 과반수 동의 필요
- 리더만 페일오버를 실행

1. Sentinel Leader가 레플리카 중 하나를 선택
   선택 기준 (우선순위 순):
   - replica-priority가 낮은 것 (0은 제외)
   - 복제 오프셋이 가장 큰 것 (최신 데이터)
   - run_id가 가장 작은 것 (타이브레이커)

2. 선택된 레플리카에 REPLICAOF NO ONE 실행 → 마스터로 승격

3. 다른 레플리카에 REPLICAOF <new-master> 실행
   → 새 마스터를 바라보도록 변경

4. 기존 마스터가 복구되면 새 마스터의 레플리카로 편입

# 레플리카 설정
replica-priority 100  # 기본값

# 0으로 설정하면 마스터로 승격 대상에서 제외
replica-priority 0    # 백업 전용 레플리카 등

# 현재 마스터 주소 조회
127.0.0.1:26379> SENTINEL GET-MASTER-ADDR-BY-NAME mymaster
1) "192.168.1.101"  # 페일오버 후 새 마스터 IP
2) "6380"

# 마스터 정보 조회
127.0.0.1:26379> SENTINEL MASTER mymaster

# 레플리카 정보 조회
127.0.0.1:26379> SENTINEL REPLICAS mymaster

# Sentinel 목록 조회
127.0.0.1:26379> SENTINEL SENTINELS mymaster

# application.yml
spring:
  data:
    redis:
      sentinel:
        master: mymaster
        nodes:
          - sentinel1:26379
          - sentinel2:26379
          - sentinel3:26379
        password: sentinel-password
      password: redis-password

@Configuration
public class RedisSentinelConfig {

    @Bean
    public LettuceConnectionFactory redisConnectionFactory() {
        RedisSentinelConfiguration sentinelConfig =
            new RedisSentinelConfiguration()
                .master("mymaster")
                .sentinel("sentinel1", 26379)
                .sentinel("sentinel2", 26379)
                .sentinel("sentinel3", 26379);
        sentinelConfig.setPassword("redis-password");

        return new LettuceConnectionFactory(sentinelConfig);
    }
}

정상 상태:
[Sentinel1] [Sentinel2] [Sentinel3]
     |           |           |
  [Master]   [Replica1]  [Replica2]

네트워크 분할:
파티션 A                    파티션 B
[Sentinel1]                [Sentinel2] [Sentinel3]
[Master] ← 쓰기 계속 받음    |           |
                          [Replica1] ← 새 마스터로 승격

→ 두 개의 마스터가 동시에 쓰기를 받음!
→ 네트워크 복구 후 기존 Master의 데이터 유실

# 마스터 측 설정 — 레플리카가 부족하면 쓰기 거부
min-replicas-to-write 1
min-replicas-max-lag 10

# 이렇게 하면 고립된 마스터는 쓰기를 거부
# 파티션 A의 기존 마스터: 레플리카 0개 → 쓰기 거부
# 파티션 B의 새 마스터: 레플리카 1개 → 쓰기 허용

# sentinel.conf
sentinel notification-script mymaster /path/to/notify.sh
sentinel client-reconfig-script mymaster /path/to/reconfig.sh

#!/bin/bash
# notify.sh — 장애 알림
# 인자: <event_type> <event_description>
echo "Redis 장애: $1 - $2" | mail -s "Redis Alert" admin@example.com

#!/bin/bash
# reconfig.sh — 페일오버 후 재설정
# 인자: <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
echo "마스터 변경: $4:$5 → $6:$7"
# DNS 업데이트, 로드밸런서 재설정 등

3 Sentinel, 쿼럼 2:
- ODOWN 판정: 2개 동의 필요
- 리더 선출: 과반수(2개) 동의 필요
- 1대 장애 허용

5 Sentinel, 쿼럼 3:
- ODOWN 판정: 3개 동의 필요
- 리더 선출: 과반수(3개) 동의 필요
- 2대 장애 허용

# 강제 페일오버 트리거
127.0.0.1:26379> SENTINEL FAILOVER mymaster

# 마스터를 의도적으로 중단
redis-cli -p 6379 DEBUG SLEEP 30  # 30초 동안 응답 중단