카프카의 내부 동작 원리와 구현

카프카 리플리케이션

리더에포크와 복구

리더에포크 실습

토픽은 chaptor4-topic03이고, 파티션 수는 1, 리플리케이션 팩터 수는 2로 진행한다
1. 토픽을 생성한다
2. 토픽 상세보기를 통해 리더를 확인한다

3. kafka2 에서 토픽 생성했음에도 리플리케이션은 1,3에서 되는 마법 퉷
4. cat 을 사용해 리더에포크 상태를 확인한다

0
1    -> 1은 현재의 리더에포크 번호
0 0  -> 첫 번째 0은 리더에포크 번호, 두 번째 0은 최종 커밋 후 새로운 메세지를 전송받게 될 오프셋 번호

---

1. 파티션의 변화를 주기 위해 메세지 전송
   • 
2. 리더에포크 상태 확인
   • 
   • 달라진 내용이 없다
3. 리더에포크 상태
   • 

---

1. 강제로 새로운 리더를 선출하도록 브로커3을 종료한다
   • sudo systemctl stop kafka-server
   • sudo systemctl status kafka-server
   • 

0
2     -> 현재의 리더에포크 번호, 브로커3이 종료되면서 새로운 리더 선출이 있었고, 리더에포크는 1에서 2로 변경( 리더가 변경될때마다 숫자증가)
0 0   -> 첫 번째 0은 리더에포크 번호, 두 번째 0은 최종 커밋 후 새로운 메세지를 전송하게 될 오프셋 번호
1 1   -> 첫 번째 1은 리더에포크 번호, 두 번째 1은 최종 커밋 후 새로운 메세지를 전송받게 될 오프셋 번호

2. 현재 리더에포크 상태
   • 

• 리더에포크는 새로운 리더가 선출이 되었으므로 1증가 (1 -> 2) => 2
• 리더에포크 번호가 1이었을때를 기준으로 가장 마지막에 커밋된 후 새로 메세지를 받게 될 오프셋 번호를 기록한다 => 0 0
• 가장 마지막에 커밋된 오프셋 번호가 0이므로 카프카는 새로 메세지를 전송 받도록 준비된 오프셋 번호 1을 leader-epoch-checkpoint 파일에 기록한다 => (1 1)
• 다운됐던 브로커3은 leader-epoch-checkpoint 파일에 기록된 정보를 이용해 복구 동작을 하게 된다
• 구 리더(브로커3)는 종료 직전 마지막 리더에포크 번호가 1이므로 뉴리더(브로커1)에게 1번 리더에포크에 대한 요청을 보내고, 뉴리더(브로커1)는 1번 리더에포크의 최종 커밋 후 준비된 오프셋 위치가 1이라는 응답을 보낸다