Raft 리더가 응답하지 않아 새 선거가 시작됐는데 이전 리더의 메시지가 뒤늦게 도착합니다. term과 투표 기록은 충돌을 어떻게 막으며 어떤 기록을 영속화해야 하나요?

Raft term은 벽시계가 아니라 선거 세대인 단조 논리 값입니다. 높은 term 메시지를 받으면 후보·leader도 follower로 내려가고 낮은 term 메시지는 현재 상태를 바꾸지 못합니다. 그래서 늦은 옛 leader 메시지가 새 leader의 기록을 덮지 못합니다.

vote와 로그

한 term에서 여러 후보에게 투표하지 않도록 currentTerm과 votedFor를 안정 저장소에 기록하고 재시작 뒤 유지합니다. 후보 로그는 마지막 log term을 먼저, 같으면 index를 비교해 커밋 이력을 잃을 후보를 막습니다. 옛 leader가 term 4, 새 leader가 term 5라면 옛 AppendEntries를 성공시키지 않습니다.

선거 timeout은 죽음의 증명이 아니라 leader 메시지 부재 추정입니다. 너무 짧으면 RTT·GC·디스크 지연에 선거가 반복되고 너무 길면 감지가 늦습니다. 무작위 timeout과 pre-vote가 분할 투표·불필요한 term 증가를 줄입니다. 지연 메시지·재시작·분할 투표·짧은 로그 후보를 검증해 term 증가와 커밋 로그 보존을 함께 봅니다.

투표가 로그 보존으로 이어집니다

후보는 자신의 term에서 투표를 요청하고, follower는 그 term에 이미 다른 후보에게 투표했는지와 후보 로그가 충분히 최신인지 검사합니다. 마지막 로그의 term을 먼저 비교하고 같으면 index를 비교하므로 단순히 엔트리가 더 많은 후보가 이기는 것은 아닙니다. 예를 들어 마지막 term 5,index 10인 후보는 term 4,index 100인 로그보다 최신으로 판정됩니다. 전체 안전성은 이 비교와 로그 일치·커밋 규칙이 함께 만듭니다.

투표 응답 전에 currentTerm과 votedFor를 안정 저장소에 기록해야 합니다. 응답 뒤 저장하기 전에 죽으면 재시작 후 같은 term의 다른 후보에게 다시 투표할 수 있어 한 term의 유일 리더 보장을 깨뜨릴 수 있습니다. 로그 수락도 필요한 내구 기록을 완료한 뒤 응답하는 규칙을 지켜야 합니다. term 숫자를 메모리에만 두는 구현은 재시작 모델에서 충분하지 않습니다.

선거 지연과 늦은 메시지

높은 term을 관찰하면 역할을 follower로 바꾸지만 낮은 term 메시지는 현재 권위를 바꾸지 못하게 거절합니다. 고립된 옛 리더가 새 term을 모르면 스스로는 리더라고 생각할 수 있어도 과반 확인 없이 새 쓰기를 확정할 수 없습니다. 따라서 '시스템에 리더를 자처하는 프로세스가 잠시 둘 있다'와 '서로 다른 확정값이 둘 생긴다'는 다른 사건입니다.

선거 timeout은 네트워크와 스케줄링 지연보다 충분한 여유를 가져야 합니다. 너무 짧으면 정상 리더도 자주 의심하고, 너무 길면 실제 장애 감지가 늦습니다. 무작위 timeout은 동시에 후보가 되는 충돌을 줄이고 pre-vote는 고립 노드가 복귀할 때 불필요하게 term을 올리는 일을 줄일 수 있지만 지원 여부와 규칙은 구현마다 확인합니다.

시험은 지연된 투표 응답, 동시에 시작한 후보, 투표 기록 직후 재시작, 디스크 지연과 네트워크 분할을 나눕니다. 선거 횟수·리더 공백 시간뿐 아니라 이전에 커밋된 로그가 새 리더에 보존되는지, 한 term에 이중 투표가 없는지 함께 확인하겠습니다.