p8. Replica Failure

In-Sync Replicas (ISR) 리스트 관리

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

 

만약, Follower가 문제가 발생한다면

• Leader에 의해 ISR 리스트에서 삭제된다.
• Leader는 새로운 ISR을 사용하여 계속 진행한다.

만약, Leader가 문제가 발생한다면

• Controller는 Follower 중에서 새로운 Leader를 선출한다.
• Controller는 새 Leader와 ISR 정보를 모든 Broker에 푸시한다.

• Broker에 장애가 발생한다. 그 Broker는 Leader Partition을 가지고 있다.
• Controller가 이를 감지하여 새로운 Leader를 선출한다. 그리고 새로운 ISR 리스트를 만들어낸다.
• 모든 Broker에게 새로운 ISR을 Push한다.
• 클라이언트들은 메타데이터를 요청하여 새로운 Leader 정보를 받은 후, 해당 Leader에 메시지를 읽고, 쓴다.

 

• Broker 4대,Partition 4, Replication Factor 3(Leader, Follower의 총 수가 3)인 경우,
• Partition 생성 시 Broker들 사이에서 Partition들이 분산되어 배치된다.
• 이때, Broker 4에 장애가 발생하면?

• Broker 4에 있는 Follower의 경우, Leader들이 해당 Follower를 제거하고 새로운 ISR을 만들어 계속해서 아무일 없다는 듯이 진행한다.
• 그런데 Partition 3의 경우 Leader가 고장난 상태가 된다. Leader가 새로 선출되어야 한다.
• Partition에 Leader가 없으면 Leader가 선출될 때까지 해당 Partition을 사용할 수 없게 된다.
• Producer의 send()는 retries 파라미터가 설정되어 있으면 재시도하고, 만약 retries = 0이면, NetworkException이 발생한다.
• 즉, Leader가 장애가 발생하면 해당 Partition을 사용할 수 없게 되므로 크나큰 문제가 될 수 있다.

 

정리를 하자면

• Follower가 실패하는 경우, Leader에 의해 ISR 리스트에서 삭제되고, Leader는 새로운 ISR을 사용하여 Commit한다.
• Leader가 실패하는 경우, Controller는 Follower중에서 새로운 Leader를 선출하고, Controller는 새 Leader와 ISR 정보를 모든 Broker들에게 로컬 캐싱을 위해 알린다.
• Leader가 장애가 나면, 새로운 Leader가 선출될 때까지 해당 Partition을 사용할 수 없게 된다.