합의 클러스터의 노드를 교체하려고 합니다. 각 서버의 노드 목록만 새 목록으로 바꾸면 왜 위험한가요?

합의 클러스터의 구성은 단순 설정 파일이 아니라 결정에 참여할 노드를 정하는 합의 상태입니다. 이전 목록과 새 목록을 각 서버에 동시에 배포하면 두 구성의 과반이 겹치지 않을 수 있습니다. 이전 A·B·C와 새 C·D·E에서 A·B와 D·E가 서로 만나지 않아도 각각 자기 과반이라고 판단하면 같은 로그 위치에 다른 결정을 확정할 위험이 있습니다.

구성 변경을 합의한다

구성은 현재 구성의 승인으로 기록하고, 전환 중에는 이전 구성과 새 구성 모두의 쿼럼 조건을 만족시키는 공동 합의(joint consensus)를 사용할 수 있습니다. 공동 구성이 확정된 다음 새 구성만 쓰는 단계로 이동합니다. 이는 해당 절차를 지원하는 Raft 계열 구현의 계약이며 모든 합의 구현에 그대로 일반화하지 않습니다.

새 노드를 즉시 투표자로 넣으면 로그를 따라잡지 못해 쿼럼 응답과 리더 변경을 늦출 수 있습니다. 먼저 비투표 학습 노드로 스냅샷·로그를 따라잡게 하고 lag·디스크를 확인한 뒤 승격하겠습니다. 변경 중 리더가 죽으면 joint entry의 커밋 여부와 새 노드의 로그 보유를 확인해야 하며, 구성 파일 동시 배포로 대체하지 않습니다.

전환과 복구

제거된 노드가 늦게 돌아오면 현재 term과 로그 약속에 따라 오래된 메시지를 거부해야 합니다. 과반 손실 뒤 강제로 새 구성을 만드는 복구는 이미 확정됐는지 모르는 기록을 버릴 수 있으므로 정상 재시작과 다릅니다. 한 번에 여러 장애 영역의 노드를 제거하지 않고 commit index, 이전·새 쿼럼의 교집합, 늦은 노드의 성공 응답 여부를 검증합니다.

안전한 구성 변경은 서버 목록을 맞추는 일이 아니라 새 참여 집합을 현재 합의 이력에 연결하는 일입니다. 구현이 제공하는 joint consensus·단일 노드 변경·learner 승격 계약과 term·로그 위치의 보존을 함께 따르겠습니다.

전환 중 두 과반을 계산합니다

이전 구성 A·B·C와 새 구성 C·D·E의 공동 단계에서는 전체 다섯 노드 중 아무 세 개가 아니라 이전 구성에서 둘, 새 구성에서 둘의 동의를 함께 요구합니다. A·B·D는 전체로는 세 개지만 새 구성의 동의가 D 하나라 충분하지 않습니다. A·C·D는 이전 A·C와 새 C·D를 만족할 수 있습니다. 이런 규칙이 전환 중 서로 분리된 결정 집합을 막습니다.

어느 구성 규칙을 적용하는 시점과 미커밋 구성 항목을 처리하는 절차는 구현 프로토콜을 그대로 따라야 합니다. 공동 구성 기록, 그 기록의 커밋, 최종 새 구성 기록을 설정 파일 변경 한 번으로 대체하지 않습니다. learner가 따라잡았다는 판정도 로그 끝 숫자만이 아니라 적용 상태·저장 안정성·복제 지연을 포함해야 합니다.

3개 클러스터에서 두 노드가 이미 사라진 뒤 남은 노드가 설정만 1개로 바꾸는 것은 정상적인 합의 구성 변경이 아닙니다. 정상 구성에서 변경을 승인할 쿼럼이 없기 때문입니다. 재해 복구로 새 클러스터를 만들려면 옛 클러스터가 다시 쓰지 못하게 격리하고 어떤 확정 기록을 잃을 수 있는지 승인·대사해야 합니다. 안전한 전환과 손실을 감수한 복구를 별도 절차로 두겠습니다.