Skip to content

Latest commit

 

History

History
42 lines (21 loc) · 2.64 KB

locksync.md

File metadata and controls

42 lines (21 loc) · 2.64 KB

Redis failover시 데이터 손실 방지 방법

레디스 분산락을 적용하여 한 데이터에 대해 락 메커니즘을 적용했다고 가정해보자.

락을 취득한 상태로 레디스 마스터 노드가 다운이 되어, 레플리카 노드가 failover 되었다.

여기서 failover 된 레플리카 노드는 락 정보를 갖고있지 않아 락 정보가 없어지게 된다면 어떻게 될까?

당연히 다른 노드들도 락에 대한 정보를 인지하지 못해 동시성 이슈가 발생하게 될 것이다. (락 상태 손실)

그렇기 때문에 꼭 이러한 문제를 해결해야한다.

RedLock

RedLock은 여러 redis 노드가 락을 취득해 과반수 이상의 노드가 취득하게 되었다면 락을 획득하는 방식으로 작동하게 된다.

클라이언트는 다수의 레디스 노드가 락을 획득해야만 성공한 것으로 간주되며, 한 노드에 장애가 발생해도 다수의 노드가 락 상태를 유지하고 있으면 락이 유효하게 유지된다. 즉 가용성이 더욱 높아지는 것이다.


동기식 복제

동기 복제와 비동기 복제의 주요 차이점은 데이터가 복제본에 기록되는 방식이다.

대부분의 동기식 복제는 기본 스토리지와 복제본에 동시에 데이터를 쓰게 된다. 그렇기에 기본 복사본과 복제본은 항상 동기화된 상태를 유지한다.

대조적으로 비동기 복제는 기본 스토리지에 데이터를 쓴 다음 복제본에 데이터를 복사한다. 거의 실시간으로 반영되게 구현할 수 있지만, 예약된 방식으로 발생하는 것이 더 일반적이다.

비동기식 복제가 동기식 복제보다 비용이 훨씬 적게드는 경향이 존재한다. 복제 프로세스가 실시간으로 발생할 필요가 없기 때문이다.

동기 복제는 복제 비용이 많이 들지만 복제 노드들과 데이터들이 일관성있게 존재하므로 데이터의 복제 유지 일관성이 중요하게 된다면 동기식 복제를 통해 레플리카를 구성해 둘 수 있을 것이다.


클라이언트 측 복구

클라이언트에서 페일오버 중 락 손실이 발생했을 가능성을 감지하는 메커니즘을 구축하는 방식인데.

클라이언트가 페일오버를 하트비트나 타임아웃을 통해 감지하는 것이다. 감지하게 된다면 락을 수동으로 해제하거나 락의 만료 시간을 기다린 후에 다시 시도할 수 있다.

이러한 방식들을 사용해 레디스 클러스터 뿐만 아니라 클러스터 환경에서 페일오버시 데이터가 손실되는 문제를 해결해볼 수 있다.