[Kafka] - 9.Replica failure&recovery

1. Replica Failure

---

ISR List 관리

Message(data)가 ISR의 모든 Replicas(복제본)에 수신되면 Commit으로 간주

Leader가 Zookeeper의 ISR-list의 변경 사항을 유지한다.

Monitoring은 Kafka의 Cluster 내에 Controller가 담당.

N개의 Replica가 있는 경우 N-1개의 장애를 허용한다.

 

Follower가 실패하는 경우

• Leader에 의해 ISR list에서 삭제
• Leader는 새로운 ISR을 사용하여 Commit

 

Leader가 실패하는 경우

• Controller가 ISR Follower 중 하나를 새로운 Leader로 선출한다.
• Controller는 새 Leader, ISR정보를 Zookeeper에게 Push 후 Local Caching을 위해 Broker에게 Push

 

4개의 Broker와 4Partition, Replication Factor = 3 인 경우

• Broker 104에서 장애가 발생하게 되면, Parition3에 대해서는 위 Leader가 실패하여 재선출 되는 과정을 진행

 

Partition Leader가 없는 경우 동작 원리

• Leader가 선출될 때 까지는 해당되는 Partition은 사용이 불가하다.
• Producer가 Record를 send() 후 Retries param이 설정되었다면 재시도 한다.
• retries=0 이면 NetworkException 발생

 

 

2. Replica Recovery

ACKS=all 

• Replica Factor=3, Producer가 4개의 Message 이라고 가정
• Follower는 M2까지 Message를 Commit하여 High water mark = 2이다.

 

이 때, Broker X가 장애가 났다고 가정하여 보자.

• 새로운 Leader를 뽑아야 함으로, Broker Y를 Leader로 선출한다.
• Leader Epoch = 0 -> 1 로 증가
• Z는 지속적인 Fetch를 통하여 M3를 replica
• Y는 High water mark 진행
• Z High water mark 수신 진행

 

• M3는 Commit이 된적이 없는데 Y는 M3를 가지고 있다.
• Broker X는 Broker Z가 M3를 받지 않았기 때문에 M3,M4에 대해 Ack를 날리지 않았다.
• Producer는 재시도하여 M3,M4를 재전송한다.
• Idempotence=False 임으로 중복이 발생한다.
• Broker Z는Y를 Fetch 진행한다.

장애가 난 Follower X가 복구 된다면?

• X는 Zookeeper에게 연결
• X는 Controller부터 Metadata를 받는다.
• Leader Y로부터 Leader Epoch을 Fetch
• Leadership이 변경된 시점부터 Parition을 Truncate한다.
• Leader Y로부터 복제
• 복제가 완료되면 ISR에 복귀한다.

 

만약에 Acks=1이었다면, 어떻게 되었을까?

• Broker X는 M3,M4에 대한 Ack를 응답하여 Producer는 재전송하여 주지 않는다.
• 그나마, Broker Y에는 M3에 대한 Message를 가지고 있어 복원이 되었으나, M4는 손실

 

3. Availability(가용성) vs Durablility(내구성)

가용성

# Topic Param
Unclean.leader.election.enable

ISR List에 없는 Replica가 Leader로 선출 할 것인지에 대한 Option ( Default =False )

ISR List에 Replica가 하나도 없으면, Leader 선출 X -> 서비스 중단

ISR List에 없는 Replica를 Leader로 선출하게 되면 Data는 손실된다.

 

내구성

# Topic Param
min.insync.replicas

최소 요구되는 ISR 갯수에 대한 Option( default=1 )

ISR이 min.insync.replicas보다 작다면, Producer는 NotenoughReplicas Exception 수신한다.

Producer에서 ACKS=all 과 함께 사용할 때 강력하게 보장되며, min.insync.replicas=2 이상 하는 것을 권장

N개에 Replica가 있고 min.insync.replicas=2 라면, N-2개의 장애 허용

 

Data의 유실을 방지

Topic : Replication.factor는 최소 3이상 / Min.insync.replicas는 2 이상

Producer : Acks = ALL

 

Data의 유실이 있어도 가용성 중시

Unclean.leader.election.enable = True