Replica failure

In-Sync Replicas 리스트는 Leader가 관리하고, 메시지가 ISR 리스트의 모든 Replica에서 수신되면 Commit된 것으로 간주한다. Kafka Cluster의 Controller가 모니터링하는 ZooKeeper의 ISR 리스트에 대한 변경사항은 Leader partition이 있는 broker가 가지고 있다. n개의 Replica가 있는 경우 n-1개의 장애를 허용할 수 있다.

image

  • Follower broker 장애
    • Leader에 의해 ISR 리스트에서 삭제됨
    • Leader는 새로운 ISR을 사용하여 Commit함
  • Leader broker 장애
    • Controller는 Follower중에서 새로운 Leader를 선출
    • Controller는 새 Leader와 ISR 정보를 먼저 ZooKeeper에 Push한 다음 로컬 캐싱을 위해 Broker에 Push함

image

Broker failure

아래 그림처럼 Broker 4 대, Partition 4, Replication Factor가 3 일 경우를 가정해보자. Partition을 생성시 Broker들 사이에서 Partition들과 해당 replica들이 분산 배치된다.

image

만약 broker 104에 장애가 났다고 하면 follwer는 죽어도 상관없기 떄문에 partition1과 partition2는 아무 문제가 없다. 하지만 leader가 포함되어 있는 patition3은 follwer 중에 하나가 leader로 변경되면서 leader 1개, follower 1개가 동작하는 형태가 된다.

image

Partition에 Leader가 없으면, Leader가 선출될 때까지 해당 Partition을 사용할수 없게 된다. Producer의 send() 는 retries 파라미터가 설정되어 있으면 재시도하지만 leader가 없기 때문에 아무런 메세지를 보낼 수 없다. 만약 retries=0 이면 leader가 아예 없어서 보낼 곳이 없기 때문에 바로 NetworkException이 발생한다.