Raft 로그가 커져 스냅샷을 만든 뒤 오래된 로그를 지우려 합니다. 중간에 서버가 꺼져도 복구할 수 있도록 어떤 기준과 저장 순서를 지켜야 하나요?

Raft snapshot은 데이터 덤프가 아니라 어느 로그 index·term까지 state machine에 적용했는지를 담는 복구 기준입니다. lastIncludedIndex와 lastIncludedTerm을 보존해 이후 로그를 올바르게 이어 붙이고, 구성·요청 중복 기록이 상태 의미에 포함되면 함께 저장합니다.

내구화와 삭제

쓰기와 snapshot이 동시에 일어나면 서로 다른 시점이 섞일 수 있으므로 정지나 불변 view로 일관된 상태를 만들고 임시 파일·체크섬·metadata를 내구화한 뒤 원자적으로 manifest를 교체합니다. 안전한 snapshot이 재시작 가능해지기 전에 이전 로그를 삭제하면 복구 경로가 끊깁니다. 생성 중 유입된 로그는 포함 index 뒤부터 남깁니다.

필요한 로그가 삭제된 follower에는 InstallSnapshot을 보냅니다. 수신자는 임시 청크·검증·원자 교체 후 snapshot 다음 로그를 재생하고 설치 중 부분 상태를 노출하지 않습니다. 주기를 짧게 하면 복구는 빨라지나 I/O·메모리·foreground 지연이 커집니다. 생성·전송·재시작·중복 요청 중단을 검증합니다.

포함 위치를 상태와 일치시킵니다

commit index가 120이고 applied index가 115라면 현재 상태 덤프는 115까지 반영한 상태입니다. 여기에 lastIncludedIndex=120을 붙이면 복구 뒤 116~120을 이미 적용한 것으로 오인해 건너뛸 수 있습니다. 스냅샷에는 실제 적용된 위치와 그 위치의 term을 저장하고, 그 이후 로그는 재생 대상으로 남깁니다. 상태 머신의 값뿐 아니라 구성 정보와 클라이언트 요청 중복 기록도 복원할 상태에 포함합니다.

생성 중 쓰기가 계속되면 일부 키는 115, 일부 키는 118의 상태가 섞일 수 있습니다. 일시 정지·copy-on-write·불변 view 등으로 일관된 기준을 잡고 스냅샷 생성의 CPU·메모리를 요청 처리 예산과 분리합니다. 임시 파일 생성, 데이터와 메타데이터의 내구화, 완성 manifest 게시, 이전 로그 정리 순서를 지켜야 중단 후 선택할 유효한 복구 지점이 남습니다. 원자적 rename만으로 전원 장애 내구화까지 보장된다고 하지 않습니다.

follower 설치와 로그 연결

오래 뒤처진 follower가 필요한 접두부 로그를 더 이상 받을 수 없으면 스냅샷을 받아 따라잡습니다. 설치 중 청크별 무결성을 확인하고 부분 파일은 읽기 상태로 게시하지 않습니다. 마지막 포함 위치와 term이 기존 로그와 맞는지에 따라 이어 쓸 접미부를 결정하는 구현 규칙을 따르고, 무조건 모든 로컬 로그를 지우지 않습니다.

느린 네트워크에서 스냅샷 전송이 계속 실패하면 리더의 메모리·디스크 읽기·대역폭이 반복 소비됩니다. 전송 동시성과 재시도, 중단된 청크의 재개 가능성을 제한하고 정상 AppendEntries·heartbeat가 굶지 않게 합니다. 설치 후 applied index와 실제 상태가 맞는지 확인하기 전에는 선형화 읽기를 허용하지 않습니다.

시험은 생성 도중 중단, 파일 내구화 전후 중단, 이전 로그 삭제 직전·직후, follower의 부분 수신을 포함합니다. 복구 후 값과 구성·처리 ID가 같은 기준 위치로 돌아오고 그 다음 명령이 정확히 한 번 적용되는지 대조하겠습니다.