파견지에 redis 가 master-slave가 down 되면서 application 단에서 장애가 일어난적이 있다.
cluster down 이 된것이다. 이를 해결하기 위해서 몇가지 공부하고 테스트해본 내용을 작성해본다.
1번 Server : M1, S3
2번 Server : M2, S1
3번 Server : M3, S2
로 구성된 Redis Cluster 가 있다. Master-Slave 을 물리적으로 나누는 이유는 Server가 어떤한 이유로 down될 시 failover처리가 가능하기 때문이다.
application은 Key를 지정하여 HSET 요청을 한다.
그러면 위와 같이 M3(예시이며 다른 Master와 연결될 수 있다)와 Session을 맺으며 HSET을 실행한다. 여기서 M3를 Down 시키면 어떻게 되는가? (단, 처음 연결은 어느 node로 연결될지 알 수 없다.)
M3가 Down 되면 S3가 Master로 승격된다. failover 되는 시간은 약 1초 가량이며 이때 application에서 같은 키로 HSET 요청을 할 경우 M1 or M2 로 연결되며 slots 에 의하여 해당 키가 있는 M3를 찾지만 down 되었기에 S3이 Master로 승격되는 1초가량 순단현상이 일어난다. 이후 application 재기동 없이 잘 연동된다. 그렇다면 여기서 M3로 승격한 S3를 down시키면 어떻게 되는가?
Session이 끊기고 application에서는 erorr 가 발생한다. 해당 key는 M3에만 있기에 M1,M2가 있어도 erorr가 발생할 수 밖에 없다.
그렇다면 위와 같이 M3는 살아있고 M2, S2가 down되면 어떻게 될까?
정답은 위와 같이 Cluster Down이다. Redis Config 중에 cluster-require-full-coverage(default: yes)라는 config 가 존재한다. 이것을 no 로 설정한다면 위에 경우에도 Session 유지가 가능하다. 다만 key를 변경하면서 명령어를 보낼경우 redis 는 자체 알고리즘에 따라 M1,M2,M3 에 골고루 명령어를 보내며 M2가 Down 된 지금의 경우 3번 요청당 1번씩 erorr가 발생한다.
wireshark를 통해 application이 어느 redis node 로 요청하는지 확인한 내용이며 틀린부분있다면 지적바랍니다.
