leader epoch란,
카프카의 파티션들이 복구 동작을 하 떄 메시지의 일관성을 유지하기위한 용도로 쓰임
리더 에포크 정보는 리플리케이션 프로토콜에 의해 전파되고 새로운 리더가 변경 된 후 변경된 리더에 대한 정보는 팔로워에게 전달됨
리더에포크는 복구 동작 시 하이워터마크를 대체하는 수단으로도 활용됨
- leader epoch의 위치 : partition dir
- leader epoch가 없을 경우 : high-water-mark 보다 앞에 있는 메시지들은 신뢰할 수 없는 메시지로 판단하여 전부 삭제됨
- leader epoch를 사용할 경우
- follwer가 메시지 복구동작을 하면서 leader-epoch 요청을 보냄
- leader가 leader epoch에 대한 응답으로 offset1의 message-B까지라고 follower에게 보냄
- follower는 high-water-mark보다 높은 offset 1의 message-B를 삭제하지 않고 high-water-mark를 상향조절함
- leader가 down이 되고 follower가 새로운 leader로 승격되어도 이전 follwer의 복구과정에서 leader-epoch를 통해 higj-water-mark를 올리고 message를 보존했기때문에 message 손실이 발생하지 않음
1. Leader-Epoch를 활용하지 않은 상태에서의 Kafka 브로커 복구
Leader-Epoch를 사용하지 않은 상태에서 특정 시점에서
Follower가 Error가 발생해서 Down 되고 추후 복구가 된다면?
1. Leader는 Message-B를 Producer로부터 받은 뒤 1번 Offset에 저장합니다.
2. Follower는 Message-B에 대해 Leader에게 가져오기 요청을 보내고 Leader의 응답으로부터 High-Water-Mark의 변화를 감지하고 High-Water-Mark를 1로 올립니다.
3. Follower는 1번 Offset의 message-B 메시지를 Replication 합니다.
4. Follower는 2번 Offset 대한 요청을 보내고 Leader는 High-Water-Mark를 2로 올립니다.
5. Follower가 Message-B를 Replication 하긴 했지만 High-Water-Mark를 올리라는 Leader의 응답을 받지 않은 이 시점에 Follower가 다운돼버립니다.
Follower가 장애에서 복구가 되면 kafka는 내부적으로 메시지 복구 동작을 진행합니다.
1. Follower는 자기가 갖고 있는 메시지 중에 자신의 High-Water-Mark보다 높은 메시지는 신뢰할 수 없다고 판단하며 삭제합니다.
2. Follower는 Offset 1의 새로운 메시지에 대해 가져오기 요청을 보냅니다
3. 하지만 이 순간에 Leader가 다운돼버립니다.
Leader Error 발생 이후 Follower가 기존 Leader의 Offset 1에 있던 Message-B가 없이 승격되었기 때문에 새로운 Leader는 Message-B를 갖고 있지 않게 됩니다.
즉 Leader가 변경되는 과정을 통해서 Message가 손실될 수 있습니다.
Leader-Epoch를 활용해서 다시 kafka 브로커를 복구
Follower가 장애에서 복구된 이후 상황이라고 가정해 봅시다.
기존의 경우 High-Water-Mark 보다 앞에 있는 메시지들은 신뢰할 수 없는 메시지로 판단하여 전부 삭제한다고 했습니다.
Leader-Epoch를 사용하는 경우에는
1. Follower가 메시지 복구동작을 하면서 Leader-Epoch 요청을 보냅니다.
2. Leader는 Leader-Epoch에 대한 응답으로 Offset1의 Message-B 까지라고 Follower에게 보냅니다.
3. Follower는 High-Water-Mark 보다 높은 Offset 1의 Message-B를 삭제하지 않고 High-Water-Mark를 상향조절 합니다.
Leader가 Down이 되고 Follower가 새로운 Leader로 승격되어도 이전 Follower의 복구과정에서 Leader-Epoch를 통해 High-Water-Mark를 올리고 Message를 보존했기 때문에 Message 손실이 발생하지 않습니다.
2. Leader와 Follower가 동시에 다운되는 경우
Leader만 Offset1에 Message-B를 저장했고 Follower는 Offset1 Message-B를 아직 Replication을 완료하지 못한 상태에서 Leader와 Follower둘다 장애가 발생해서 Down 됐다고 가정하고 Leader-Epoch를 사용하지 않고 복구를 해보겠습니다.
Follower였던 브로커가 먼저 복구가 됩니다.
1. Follower가 먼저 복구가 되었고 Partition에 Leader가 존재하지 않기 때문에 새로운 Leader로 승격됩니다
2. 새로운 Leader는 Producer로부터 Message-C를 받고 Offset1에 저장한 뒤 High-Water-Mark를 상향 조정합니다.
추후 기존 Leader였던 브로커가 복구가 됩니다.
1. 기존에 Leader 였던 브로커는 Topic에 0번 Partition에 이미 Leader가 있으므로 복구된 브로커는 Follower가 됩니다.
2. Follower는 Leader와 High-Water-Mark를 비교를 하고 비교를 해보니 일치하므로 브로커는 메시지를 삭제하지 않습니다.
3. Leader는 Message-D를 받고 Offset 2에 위치시키고 Follower는 Replication을 할 준비를 합니다.
Leader와 Follower가 동일한 High-Water-Mark를 나타내고 있지만 서로의 메시지가 다르게 됩니다.
Leader-Epoch를 활용해서 다시 복구
1. 기존 Leader였던 브로커가 장애에서 복구되고 이미 Leader가 있기 때문에 Follower가 됩니다.
2. Follower는 Leader에게 Leader-Epoch 요청을 보내고 Leader는 Offset 0까지 유효하다고 응답합니다.
3. Follower는 유효하지 않은 Offset 1번에 있는 Message-B를 삭제합니다.
4. Follower는 Offset 1번에 있는 Message-C를 Replication 할 준비를 합니다.
이와 같은 과정을 통해서 메시지가 달라지는 것을 막을 수 있습니다.
