kudu master 3대 중 특정 마스터(리더로 보고되는 노드)를 다른 마스터가 인정하지 않는 형태로 ksck 결과의 consensus matrix가 마스터마다 다르게 나온다. 서비스 자체는 눈에 띄는 장애 없이 동작 중이다.
master sys_catalog consensus 불일치와 일반 데이터 tablet의 quorum 손실은 서로 다른 복구 대상이다. 원본에 master 재동기화 제안은 있으나 적용 성공 기록은 없어 확정 해결로 표시하지 않았다.
ksck와 master 로그로 일시적인 leader 변경인지 지속적인 sys_catalog 불일치인지 확인한다. 지속 불일치의 재동기화는 해당 Kudu 버전의 master 복구 절차로 수행하며 tablet server의 unsafe_change_config를 대체 절차로 사용하지 않는다.
확인 수준: 추가 조사 해법 · 해당 케이스 적용 결과 미확인
적용 조건: <...>와 예시 DB·테이블·경로·수치는 실제 확인값으로 바꾼다. 명령과 메뉴는 참고 문서를 바탕으로 보강한 예시이며 대상 시스템에서 실행하지 않았다. 버전·원인에 따른 분기와 남은 확인 사항은 아래에 명시한다.
kudu cluster ksck '<master1>:7051,<master2>:7051,<master3>:7051'
kudu master list '<master1>:7051,<master2>:7051,<master3>:7051'
/masters와 로그에서 leader, term, config index와 RPC 연결 오류를 비교한다. DNS·네트워크 장애나 빠른 leader 교체가 있으면 그 원인을 먼저 고친다.kudu master --help와 해당 배포판 master 복구 가이드로 적용 경로를 결정한다. 손상 replica 삭제 명령을 재사용하기 전에 대상 UUID·디렉터리·정상 quorum을 확인한다.remote_replica unsafe_change_config는 이 master 불일치의 일반 해법이 아니다. 복구 후 모든 master의 상태와 ksck 일치 여부, 실제 테이블 목록·읽기·쓰기를 확인한다.3대 마스터의 ksck 결과가 서로 일관되게 HEALTHY로 나오고, 재시작을 반복해도 동일한 consensus conflict가 재발하지 않는지 확인한다.