02.Replica Failure

In-Sync Replicas 리스트 관리

  • Leader가 관리

  • 메시지가 ISR 리스트의 모든 Replica(복제본)에서 수신되면 Commit된 것으로 간주

  • Kafka Cluster의 Controller가 모니터링하는 ZooKeeper의 ISR 리스트에 대한 변경 사항은 Leader가 유지

  • n개의 Replica가 있는 경우 n-1개의 장애를 허용할 수 있음

  • Follower가 실패하는 경우

    • Leader에 의해 ISR 리스트에서 삭제됨

    • Leader는 새로운 ISR을 사용하여 Commit함

  • Leader가 실패하는 경우

    • Controller는 Follower 중에서 새로운 Leader를 선출

    • Controller는 새 Leader와 ISR 정보를 먼저 ZooKeeper에 Push한 다음 로컬 캐싱을 위해 Broker에 Push함

ISR은 Leader가 관리

  • Zookeeper에 ISR 업데이트, Controller가 Zookeeper로부터 수신

  1. Follower가 너무 느리면 Leader는 ISR에서 Follower를 제거하고 ZooKeeper에 ISR을 유지

  2. Controller는 Partition Metadata에 대한 변경 사항에 대해서 Zookeeper로부터 수신

Leader Failure

  • Controller가 새로운 Leader 선출

  • Controller가 새로 선출한 Leader 및 ISR 정보는, Controller 장애로부터 보호하기 위해, ZooKeeper에 기록된 다음 클라이언트 메타데이터 업데이트를 위해 모든 Broker에 전파

Broker Failure

Broker 4 대, Partition 4, Replication Factor가 3 일 경우를 가정

  • Partition 생성시 Broker들 사이에서 Partition들이 분산하여 배치됨

  • Broker 4에 장애가 발생하는 경우

Partition Leader가 없는 경우

  • Partition에 Leader가 없으면, Leader가 선출될 때까지 해당 Partition을 사용할 수 없게 됨

  • Producer의 send() 는 retries 파라미터가 설정되어 있으면 재시도함 만약 retries=0 이면, NetworkException이 발생함

Last updated