네트워크 파티션 또는 노드 크래시의 경우 대부분의 분산 형 원자 브로드 캐스트 프로토콜 (확장 가상 동기화 또는 Paxos와 같은)은 크래시 또는 파티션 된 노드가 클러스터에 다시 가입 할 때까지 로그 메시지를 보관하기 위해 노드를 실행해야합니다. 노드가 클러스터에 다시 참여하면 기록 된 메시지를 재생하면 현재 상태를 다시 확보 할 수 있습니다.그룹 통신 서비스 또는 paxos에서 로깅 메시지를 실용적으로 유지합니까?
제 질문은 파티션/크래시 노드가 클러스터에 다시 가입하는 데 실제로 시간이 오래 걸리는 경우 결국 로그가 오버플로됩니다. 이것은 매우 실용적인 문제로 보입니다. 그러나 여전히 그들 중 누구도 그것에 대해 이야기하지 않습니다. 제가 누락 된 이것에 대한 아주 명백한 해결책이 있습니까? 또는 잘못된 이해.
전체 로그를 기억할 필요가 없습니다. 예를 들어 노드 사이에서 동기화하는 상태가 (id : int, name : string) 형식의 행이있는 SQL 테이블과 같았고 로그에 기록 될 명령이 "행 삽입 id = x 및 name = y ","delete row where id = z ","set name = a where id = 1000 "...
이러한 명령이 커밋 된 후에는 최종 테이블. 그런 다음 오랜 시간 동안 오프라인 상태였던 노드가 온라인 상태가되면 테이블을 다운로드하는 동안 커밋 된 로그와 테이블에서 몇 가지 항목 만 다운로드하면됩니다.
이것을 "로그 압축"이라고하며, 자세한 내용은 Raft paper의 7 장을 확인하십시오.
무한 로그 문제에 대한 몇 가지 잠재적 인 솔루션이 있지만 복제 상태의 컴퓨터에서 자주 사용되는 방법 중 하나는 복제 된 전체 상태 시스템을 주기적으로 스냅 샷하고 그 시점 이전의 모든 기록을 삭제하는 것입니다. 너무 오랫동안 오프라인 상태였던 노드는 모든 정보를 버리고 스냅 샷을 다운로드 한 다음 해당 지점에서 복제 된 로그 재생을 시작합니다.
"... 아무도 그것에 대해 이야기하지 않습니다." 특정 용지에 대해 묻고 있습니까? 아니면 아무도이 문제를 해결하지 못하는 것 같습니까? –
그룹 커뮤니케이션 서비스와 관련된 대부분의 문서를 읽었으며 거기에서 제기 된 바가 없습니다. 예를 들어, Ken Birman의 Virtual Synhcrony Papers, Extended Virtual Syncrhony, CoREL 등 대부분 –