Redis Sentinel 구성 실습
- 실습을 진행하면서 여러 오류를 겪었다.
- 컴퓨터 성능 문제도 있는 것 같고... 제대로 원인과 해결법을 파악 못한 문제들도 존재한다.
- 도커 환경으로 간단히 해보려고 했는데... 오히려 간단하지 않았다.
- 실제 환경에서는 분리된 서버에 레디스와 센티넬을 구성할 것이므로 해당 실습과 궤를 달리하는 부분이 많을 것 같다.
마스터 장애시 failover 확인
- 디버그 레벨 로그까지 들어가 있다
- . 으로 시작하는 게 디버그 레벨 로그
1:X 26 May 2025 08:46:17.291 # +sdown master sentineltest 192.29.1.2 6379 1:X 26 May 2025 08:46:17.344 # +odown master sentineltest 192.29.1.2 6379 #quorum 3/2 1:X 26 May 2025 08:46:17.344 # +new-epoch 1 1:X 26 May 2025 08:46:17.344 # +try-failover master sentineltest 192.29.1.2 6379 1:X 26 May 2025 08:46:17.353 . Rewritten config file (/sentinel/sentinel.conf) successfully 1:X 26 May 2025 08:46:17.354 * Sentinel new configuration saved on disk 1:X 26 May 2025 08:46:17.354 # +vote-for-leader 27522544e4b37aeb815acd4bc440f43daebb3fe1 1 1:X 26 May 2025 08:46:17.354 * 27522544e4b37aeb815acd4bc440f43daebb3fe1 voted for 27522544e4b37aeb815acd4bc440f43daebb3fe1 1 1:X 26 May 2025 08:46:17.369 * c8740653fad1b7db7374f827ca223c65acef6019 voted for 27522544e4b37aeb815acd4bc440f43daebb3fe1 1 1:X 26 May 2025 08:46:17.370 * e09a5693ff8e2e7c7baba033d9c84bda53e6cd8d voted for 27522544e4b37aeb815acd4bc440f43daebb3fe1 1 1:X 26 May 2025 08:46:17.410 # +elected-leader master sentineltest 192.29.1.2 6379 1:X 26 May 2025 08:46:17.410 # +failover-state-select-slave master sentineltest 192.29.1.2 6379 1:X 26 May 2025 08:46:17.493 # +selected-slave slave 192.29.1.4:6379 192.29.1.4 6379 @ sentineltest 192.29.1.2 6379 1:X 26 May 2025 08:46:17.493 * +failover-state-send-slaveof-noone slave 192.29.1.4:6379 192.29.1.4 6379 @ sentineltest 192.29.1.2 6379 1:X 26 May 2025 08:46:17.546 * +failover-state-wait-promotion slave 192.29.1.4:6379 192.29.1.4 6379 @ sentineltest 192.29.1.2 6379 1:X 26 May 2025 08:46:18.538 - -role-change slave 192.29.1.4:6379 192.29.1.4 6379 @ sentineltest 192.29.1.2 6379 new reported role is master 1:X 26 May 2025 08:46:18.542 . Rewritten config file (/sentinel/sentinel.conf) successfully 1:X 26 May 2025 08:46:18.542 * Sentinel new configuration saved on disk 1:X 26 May 2025 08:46:18.542 # +promoted-slave slave 192.29.1.4:6379 192.29.1.4 6379 @ sentineltest 192.29.1.2 6379 1:X 26 May 2025 08:46:18.542 # +failover-state-reconf-slaves master sentineltest 192.29.1.2 6379 1:X 26 May 2025 08:46:18.609 * +slave-reconf-sent slave 192.29.1.3:6379 192.29.1.3 6379 @ sentineltest 192.29.1.2 6379 1:X 26 May 2025 08:46:19.585 * +slave-reconf-inprog slave 192.29.1.3:6379 192.29.1.3 6379 @ sentineltest 192.29.1.2 6379 1:X 26 May 2025 08:46:19.585 * +slave-reconf-done slave 192.29.1.3:6379 192.29.1.3 6379 @ sentineltest 192.29.1.2 6379 1:X 26 May 2025 08:46:19.637 # +failover-end master sentineltest 192.29.1.2 6379 1:X 26 May 2025 08:46:19.637 # +switch-master sentineltest 192.29.1.2 6379 192.29.1.4 6379 1:X 26 May 2025 08:46:19.638 * +slave slave 192.29.1.3:6379 192.29.1.3 6379 @ sentineltest 192.29.1.4 6379 1:X 26 May 2025 08:46:19.638 * +slave slave 192.29.1.2:6379 192.29.1.2 6379 @ sentineltest 192.29.1.4 6379 1:X 26 May 2025 08:46:19.642 . Rewritten config file (/sentinel/sentinel.conf) successfully 1:X 26 May 2025 08:46:19.642 * Sentinel new configuration saved on disk 1:X 26 May 2025 08:46:29.711 # +sdown slave 192.29.1.2:6379 192.29.1.2 6379 @ sentineltest 192.29.1.4 6379
- . 으로 시작하는 게 디버그 레벨 로그
실습에 사용한 docker-compose.yml, Dockerfile, 레디스와 센티넬 conf 파일들
docker-compose.yml
services:
redis-primary:
image: redis:8
container_name: redis-primary
ports:
- 6379:6379
environment:
TZ: Asia/Seoul
volumes:
- ./infra/primary/data:/data
- ./infra/primary/redis.conf:/usr/local/etc/redis/redis.conf
networks:
sentinel-redis:
ipv4_address: 192.29.1.2
command: >
sh -c "chmod 777 /run && redis-server /usr/local/etc/redis/redis.conf"
redis-replica1:
image: redis:8
container_name: redis-replica1
ports:
- 6380:6379
environment:
TZ: Asia/Seoul
volumes:
- ./infra/replica1/redis.conf:/usr/local/etc/redis/redis.conf
depends_on:
- redis-primary
networks:
sentinel-redis:
ipv4_address: 192.29.1.3
command: >
sh -c "chmod 777 /run && redis-server /usr/local/etc/redis/redis.conf --replicaof redis-primary 6379"
redis-replica2:
image: redis:8
container_name: redis-replica2
ports:
- 6381:6379
environment:
TZ: Asia/Seoul
volumes:
- ./infra/replica2/redis.conf:/usr/local/etc/redis/redis.conf
depends_on:
- redis-primary
networks:
sentinel-redis:
ipv4_address: 192.29.1.4
command: >
sh -c "chmod 777 /run && redis-server /usr/local/etc/redis/redis.conf --replicaof redis-primary 6379"
sentinel1:
build: infra/sentinel
container_name: sentinel1
ports:
- 26379:26379
environment:
TZ: Asia/Seoul
depends_on:
- redis-primary
- redis-replica1
- redis-replica2
networks:
sentinel-redis:
command: redis-server /sentinel/sentinel.conf --sentinel
sentinel2:
build: infra/sentinel
container_name: sentinel2
ports:
- 26380:26379
environment:
TZ: Asia/Seoul
depends_on:
- redis-primary
- redis-replica1
- redis-replica2
networks:
- sentinel-redis
command: redis-server /sentinel/sentinel.conf --sentinel
sentinel3:
build: infra/sentinel
container_name: sentinel3
ports:
- 26381:26379
environment:
TZ: Asia/Seoul
depends_on:
- redis-primary
- redis-replica1
- redis-replica2
networks:
sentinel-redis:
command: redis-server /sentinel/sentinel.conf --sentinel
networks:
sentinel-redis:
driver: bridge
ipam:
config:
- subnet: "192.29.1.0/24"
Dockerfile
FROM redis:8
COPY sentinel_config.conf /sentinel/sentinel.conf
RUN chown redis:redis /sentinel/sentinel.conf && \
chmod 777 /sentinel
레디스 conf
- 레디스 config 파일은 검색해보면 공식 홈페이지에서 상세한 주석과 함께 전체 옵션을 제공해준다.
- https://redis.io/docs/latest/operate/oss_and_stack/management/config/
- 몇 가지 주요 설정만 작성해서 활용했다.
- default 설정 그대로 작성된 것도 있다.
bind 0.0.0.0
protected-mode no
port 6379
pidfile /run/redis.pid
loglevel debug
stop-writes-on-bgsave-error no
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
rdb-del-sync-files no
dir ./
센티넬 conf
port 26379
sentinel monitor sentineltest 192.29.1.2 6379 2
sentinel down-after-milliseconds sentineltest 10000
sentinel failover-timeout sentineltest 60000
sentinel resolve-hostnames yes
# sentinel auth-pass myprimary a_strong_password
bind 0.0.0.0
protected-mode no
loglevel debug
작업하면서 만난 문제상황
1. temp.rdb 권한 문제 발생
- 도커 호스트 디렉토리 매핑으로 인해 발생한 문제 (윈도우에서 wsl + 도커 엔진이 돌아가는 환경에서 발생)
- 참고 링크 : https://ichmww2.tistory.com/102
2. protect_mode 설정
- 센티넬을 띄웠을 때, 계속해서 슬레이브 서버와 연결이 제대로 이어지지 않아 센티넬 서버가 틸트(tilt) 상태가 되는 문제가 발생했다.
tilt 모드란?
- 센티넬 서버가 비정상 일 때 전환되는 모드
- Sentinel이 마스터 및 슬레이브(레플리카) 상태를 정상적으로 모니터링할 수 없는 상황을 의미한다.
- 이 상태는 주로 마스터-슬레이브 간의 통신 장애 또는 Sentinel 서버의 자체 장애 등으로 인해 발생할 수 있다.
1:X 24 May 2025 07:40:26.235 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 1:X 24 May 2025 07:40:26.235 * Redis version=7.2.8, bits=64, commit=00000000, modified=0, pid=1, just started 1:X 24 May 2025 07:40:26.235 * Configuration loaded 1:X 24 May 2025 07:40:26.236 * monotonic clock: POSIX clock_gettime 1:X 24 May 2025 07:40:26.240 * Running mode=sentinel, port=26379. 1:X 24 May 2025 07:40:26.241 * Sentinel ID is d6d2e98e87b90efe028bbc34c09b6d9c61c7b24f 1:X 24 May 2025 07:40:26.241 # +monitor master myprimary 172.25.0.2 6379 quorum 2 1:X 24 May 2025 07:40:31.273 # +sdown slave 172.25.0.4:6379 172.25.0.4 6379 @ myprimary 172.25.0.2 6379 1:X 24 May 2025 07:40:31.273 # +sdown slave 172.25.0.7:6379 172.25.0.7 6379 @ myprimary 172.25.0.2 6379 1:X 24 May 2025 07:40:45.854 # +tilt #tilt mode entered 1:X 24 May 2025 07:40:44.984 # +tilt #tilt mode entered 1:X 24 May 2025 07:41:13.909 # +tilt #tilt mode entered 1:X 24 May 2025 07:41:12.975 # +tilt #tilt mode entered 1:X 24 May 2025 07:41:41.992 # +tilt #tilt mode entered
- 이 상태는 주로 마스터-슬레이브 간의 통신 장애 또는 Sentinel 서버의 자체 장애 등으로 인해 발생할 수 있다.
참고) 레디스 슬레이브 서버만 다운 상태가 된 이유
레디스 프라이머리 서버에는 레플리카 구성을 하면서 이미 아래에서 확인해 볼
보호 모드
를 해제를 해두었기에 슬레이브 서버만 다운된 것으로 센티넬이 처리한 것이다.센티넬 config 와 redis config 모두 bind 속성을 0.0.0.0 으로 열어둔 상태였는데 지속적으로 위와 같은 문제가 발생하여 센티넬 컨테이너에서 직접 PING 호출을 수행해보았다.
# redis-cli -h 172.25.0.2 -p 6379 PING PONG # redis-cli -h 172.25.0.4 -p 6379 PING (error) DENIED Redis is running in protected mode because protected mode is enabled and no password is set for the default user. In this mode connections are only accepted from the loopback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions: 1) Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so. Use CONFIG REWRITE to make this change permanent. 2) Alternatively you can just disable the protected mode by editing the Redis configuration file, and setting the protected mode option to 'no', and then restarting the server. 3) If you started the server manually just for testing, restart it with the '--protected-mode no' option. 4) Set up an authentication password for the default user. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside.
확인 결과 위와 같은 에러 로그를 확인할 수 있었다.
protected-mode
- 레디스 서버의 보호 모드 설정이다. 디폴트는 yes.
- bind 설정이나 requirepass 설정이 없다면 보호 모드가 활성화 될 수 있다.
- 나의 경우 bind 가 전체로 열려 있고, requirepass 가 설정되어 있지 않아서 보호 모드가 활성화 된 것이다.
- 해당 속성을 no 로 변경해주었다.
# Protected mode is a layer of security protection, in order to avoid that # Redis instances left open on the internet are accessed and exploited. # # When protected mode is on and the default user has no password, the server # only accepts local connections from the IPv4 address (127.0.0.1), IPv6 address # (::1) or Unix domain sockets. # # By default protected mode is enabled. You should disable it only if # you are sure you want clients from other hosts to connect to Redis # even if no authentication is configured. protected-mode no
- 해당 속성을 no 로 변경해주었다.
3. 도커 dns 문제
1:X 25 May 2025 13:17:26.141 # +sdown master myprimary 172.23.0.2 6379
1:X 25 May 2025 13:17:30.081 # Failed to resolve hostname 'redis-primary'
1:X 25 May 2025 13:17:30.082 # +sdown slave 172.23.0.4:6379 172.23.0.4 6379 @ myprimary 172.23.0.2 6379
1:X 25 May 2025 13:17:30.143 - Reading from client: Connection reset by peer
1:X 25 May 2025 13:17:30.182 # +tilt #tilt mode entered
1:X 25 May 2025 13:17:30.206 - Accepted 172.23.0.5:51014
1:X 25 May 2025 13:17:52.594 # Failed to resolve hostname 'redis-primary'
1:X 25 May 2025 13:17:52.666 # +tilt #tilt mode entered
1:X 25 May 2025 13:17:59.592 # Failed to resolve hostname 'redis-primary'
1:X 25 May 2025 13:17:59.659 # +tilt #tilt mode entered
1:X 25 May 2025 13:18:01.181 . Rewritten config file (/sentinel/sentinel.conf) successfully
1:X 25 May 2025 13:18:01.181 * Sentinel new configuration saved on disk
1:X 25 May 2025 13:18:01.181 # +new-epoch 1
1:X 25 May 2025 13:18:01.186 . Rewritten config file (/sentinel/sentinel.conf) successfully
1:X 25 May 2025 13:18:01.186 * Sentinel new configuration saved on disk
1:X 25 May 2025 13:18:01.186 # +vote-for-leader ba5cc855826c5c3d6b8a84e75094f5294e9dd24c 1
1:X 25 May 2025 13:18:02.553 - -role-change slave 172.23.0.4:6379 172.23.0.4 6379 @ myprimary 172.23.0.2 6379 new reported role is master
1:X 25 May 2025 13:18:06.668 # Failed to resolve hostname 'redis-primary'
1:X 25 May 2025 13:18:06.731 # +tilt #tilt mode entered
1:X 25 May 2025 13:18:13.853 # Failed to resolve hostname 'redis-primary'
1:X 25 May 2025 13:18:13.912 # +tilt #tilt mode entered
1:X 25 May 2025 13:18:21.048 # Failed to resolve hostname 'redis-primary'
1:X 25 May 2025 13:18:21.116 # +tilt #tilt mode entered
1:X 25 May 2025 13:18:28.224 # Failed to resolve hostname 'redis-primary'
1:X 25 May 2025 13:18:28.277 # +tilt #tilt mode entered
1:X 25 May 2025 13:18:35.442 # Failed to resolve hostname 'redis-primary'
1:X 25 May 2025 13:18:35.527 # +tilt #tilt mode entered
failover 수행 중에 기존의 primary 도메인 네임(컨테이너 네임) 정보를 확인할 수 없어서 문제가 발생한다.
primary 레디스 서버(redis-primary)를 종료해야 failover를 테스트 해볼 수 있다.
- 그러나 도커 시스템이 종료된 컨테이너의 dns 정보는 제공하지 않는 것 같다.(추측)
- 그리고 레디스 센티넬 서버는 config 파일에 작성된 redis-primary 컨테이너 명을 ip 정보로 재작성하였음에도 불구하고 계속해서 호스트네임으로 체크를 하는데(ping을 해보는 걸까...), 이유를 모르겠다.
- 아래는 sentinel.conf 파일
# 최초의 conf 파일 port 26379 sentinel monitor sentineltest redis-primary 6379 2 sentinel down-after-milliseconds sentineltest 10000 sentinel failover-timeout sentineltest 60000 sentinel resolve-hostnames yes # sentinel auth-pass myprimary a_strong_password bind 0.0.0.0 protected-mode no loglevel debug # sentinel 서버가 구동되고 수정된 버전 port 26379 sentinel monitor sentineltest 192.29.1.2 6379 2 sentinel down-after-milliseconds sentineltest 10000 sentinel failover-timeout sentineltest 60000 sentinel resolve-hostnames yes # sentinel auth-pass myprimary a_strong_password bind 0.0.0.0 protected-mode no loglevel debug # Generated by CONFIG REWRITE latency-tracking-info-percentiles 50 99 99.9 dir "/data" user default on nopass sanitize-payload ~* &* +@all sentinel myid 27522544e4b37aeb815acd4bc440f43daebb3fe1 sentinel config-epoch sentineltest 1 sentinel leader-epoch sentineltest 1 sentinel current-epoch 1 sentinel known-replica sentineltest 192.29.1.4 6379 sentinel known-replica sentineltest 192.29.1.3 6379 sentinel known-sentinel sentineltest 192.29.1.7 26379 c8740653fad1b7db7374f827ca223c65acef6019 sentinel known-sentinel sentineltest 192.29.1.6 26379 e09a5693ff8e2e7c7baba033d9c84bda53e6cd8d sentinel known-sentinel sentineltest 192.29.1.5 26379 27522544e4b37aeb815acd4bc440f43daebb3fe1
이 문제를 해소하기 위해서 dns (즉 container name mapping) 형태로 conf 파일을 작성하지 않고, 컨테이너의 프라이빗 ip를 바로 사용하는 것으로 수정했다.
- 이를 위해, 도커 컴포즈 파일도 컨테이너에 ip 주소를 고정으로 지정해주도록 수정했다. (관련한 docker-compose.yml 과 conf 파일 내용은 상단에 작성되어 있다.)
다른 블로그 작성자분들은 어떻게 문제 없이 하신 걸까...!
- 쿠버네티스를 활용하거나 도커 스왐을 활용하는 경우 유사한 문제를 겪고 레디스 레포 혹은 비트나미 레포에 이슈로 올린 것을 확인해 볼 수 있었다...
- 원인을 사실 잘 모르겠다. 추측만 해볼 뿐...
이런 문제(4번 문제 포함)가 없으셨던 분들은 부럽습니다. 그리고 시간 되신다면면 어떻게 하셨는지 조언 부탁드립니다...
4. 지속되는 (지옥의) tilt mode
1:X 25 May 2025 22:21:56.616 # +tilt #tilt mode entered
1:X 25 May 2025 22:21:56.935 # +tilt #tilt mode entered
1:X 25 May 2025 22:22:25.548 # +tilt #tilt mode entered
1:X 25 May 2025 22:22:25.867 # +tilt #tilt mode entered
1:X 25 May 2025 22:22:54.475 # +tilt #tilt mode entered
1:X 25 May 2025 22:22:54.824 # +tilt #tilt mode entered
1:X 25 May 2025 22:23:23.323 # +tilt #tilt mode entered
1:X 25 May 2025 22:23:23.672 # +tilt #tilt mode entered
1:X 25 May 2025 22:23:52.306 # +tilt #tilt mode entered
1:X 25 May 2025 22:23:52.595 # +tilt #tilt mode entered
1:X 25 May 2025 22:24:21.234 # +tilt #tilt mode entered
1:X 25 May 2025 22:24:21.549 # +tilt #tilt mode entered
1:X 25 May 2025 22:24:50.156 # +tilt #tilt mode entered
1:X 25 May 2025 22:24:50.474 # +tilt #tilt mode entered
1:X 25 May 2025 22:25:19.094 # +tilt #tilt mode entered
1:X 25 May 2025 22:25:19.456 # +tilt #tilt mode entered
1:X 26 May 2025 08:32:18.522 # +tilt #tilt mode entered
1:X 26 May 2025 08:32:33.600 # +tilt #tilt mode entered
1:X 26 May 2025 08:32:35.481 # +tilt #tilt mode entered
- 이건 컴퓨터 성능 문제로 추측하고 있다.
- 왜냐하면, 컴퓨터 상태가 안정적일 때 (막 컴퓨터를 켜고난 다음?) tilt 모드에서 벗어날 수 있었고, failover 테스트도 성공적으로 수행할 수 있었다.
- 다만 컨테이너 다시 실행하거나 좀만 잘못 건드리면, 다시 tilt 모드로 들어가버린다...
- 이 문제 때문에 레디스 버전 7.2, 7.4, 8 을 모두 체크해보았다. 그리고 여러 블로그를 참고하며, bitnami 에서 제공하는 레디스와 레디스 센티넬로도 확인해보았으나 동일한 문제를 겪었다.
- 이 문제 때문에 눈물 날 뻔 했다.
- failover 테스트는 정말 겨우 수행했다... 그나마 할 수 있었던 게 다행이라고 생각 중
- 이 문제 때문에 눈물 날 뻔 했다.
참고자료
'Infra > DB' 카테고리의 다른 글
몽고DB 구성(Replica Set/Sharded Cluster) 간단히 알아보기 (0) | 2025.05.31 |
---|---|
[MongoDB]몽고디비 개요 (0) | 2025.05.28 |
Redis Persistence (RDB/AOF) (0) | 2025.05.16 |
[Redis]레디스 replicaof 세팅 관련 trouble shooting (0) | 2025.05.13 |
우아한 Redis 강의 정리 (0) | 2025.05.12 |