Master-Slave-Sentinel
레디스 운영환경은 기본적으로 Master-Slave 복제구조로 이루어진다. 운영 도중 마스터가 예기치 않게 다운되었을 때 Sentinel이 이를 감지해서 Slave를 Master로 FailOver해주는 역할을 한다.
기본적인 Master-Slave구조에 있어서 Slave서버는 Master서버의 데이터가 실시간으로 복제된다. 하지만 예기치 못한 Master의 다운으로 Slave는 자동적으로 FailOver 되지 않는다. 이 경우 Slave에서 지속적인 읽기 작업은 가능하지만 쓰기 작업은 불가능하다.
장애 복구
- Sentinel 서버는 매초마다 HeartBeat를 통해 Master와 Slave가 살아있는지 확인한다. 일정 TimeOut동안 응답이 없으면 장애가 발생한것으로 간주한다. 이를 Subjectively Down(주관적 다운)이라 한다. Timeout은 sentinel.conf의 down-after-milliseconds에서 설정 가능하다.
- Sentinel 서버가 Subjectively Down을 감지한 상황이고 Sentinel 서버가 여러대인 경우 모든 Sentinel 서버가 장애를 인지한다면 이를 Objectively Down(객관적 다운)이라 한다. Sentinel 서버는 Master가 다운된 경우 다른 Sentinel 서버들과 Quorum(정족수)를 확인하여 이를 만족하게 되면 최종적으로 실제 다운되었다고 판단한다.
- Subjectively Down과 Objectively Down이 확인되면 장애조치를 실시한다.
- 여러대의 Sentinel 서버로 구축되어있는 경우 Sentinel Leader를 내부적으로 선출한다.
- Leader는 장애가 발생한 Master 서버를 대신할 Slave를 선정한다
- 선정된 Slave 서버는 Master로 승격된다
- 남은 Slave 서버는 새로운 Master를 모니터링한다
부분 동기화
장애 복구가 완료된 후 Slave 서버들은 새로운 Master 서버의 데이터를 복제하게 된다. 이 때 이전 복제 데이터를 제거하고 새로운 Master 서버로부터 모든 데이터를 Full Sync하게 된다.(Redis 3.2 이하) 하지만 레디스 4.0 이상부터 이를 개선하여 Partial Resync를 수행하도록 한다. 하지만 동기화해야할 부분의 데이터가 repl-backlog-size 파라미터보다 큰 경우에는 Full Sync를 진행한다.