한 뿌리에서 나오는 여러 얼굴이다.
async tablet task AlterTable RPC for tablet ... failed: Not found: Failed to reset TS proxy: could not find TS for UUID ...
RequestConsensusVote: wrong destination UUID requested. local uuid ..., requested uuid ...
Table consistency check error: 63 out of 72 tables are not healthy
ALTER TABLE 이 끝나지 않고 멈춰 있거나, ksck 에서 대부분의 테이블이 unhealthy 로 잡히거나, 특정 테이블만 tserver 를 잘못된 UUID 로 본다면 같은 문제를 보고 있을 가능성이 높다.
Kudu 는 tablet 복제본의 위치를 호스트 이름이 아니라 tserver UUID 로 관리한다. UUID 는 tserver 가 처음 기동할 때 데이터 디렉터리(fs_data_dirs · fs_wal_dir)에 기록되고, 그 뒤로 바뀌지 않는다.
UUID 가 바뀌는 상황은 정해져 있다. 데이터 디렉터리를 지우고 다시 띄운 경우, 디스크를 교체하거나 새로 포맷한 경우, 다른 노드의 디스크 이미지를 복제해 올린 경우다. 이때 마스터의 Raft 설정에는 옛 UUID 가 남아 있고, 그 주소로 접속하면 다른 UUID 를 가진 서버가 응답하므로 위 메시지가 난다.
특정 테이블만 문제가 되고 다른 테이블은 멀쩡한 것도 이것으로 설명된다. 복제본 배치가 테이블마다 다르기 때문이다.
kudu cluster ksck master-01,master-02,master-03
kudu cluster ksck master-01,master-02,master-03 -tables=db.tbl
kudu tserver list master-01,master-02,master-03 -columns=uuid,rpc-addresses,http-addresses
각 노드에서 실제 UUID 를 읽는다.
kudu fs dump uuid --fs_wal_dir=/var/lib/kudu/wal --fs_data_dirs=/var/lib/kudu/data
ksck 가 보고하는 UUID 와 노드의 실제 UUID 를 대조하면 어느 쪽이 유령인지 드러난다.
ksck 실행 중 Not authorized: unauthorized access to method: Quiesce 같은 경고가 섞이면, 그것은 권한 문제일 뿐 클러스터 상태와는 별개다. 관리 작업은 kudu 계정으로 수행한다.
sudo -u kudu kudu cluster ksck master-01,master-02,master-03
과반이 살아 있으면 기다린다. RF=3 에서 정상 복제본이 2개 이상이면 마스터가 스스로 재복제한다. 재복제가 도는 동안 rebalance 를 걸면 오히려 방해가 되므로, 끝난 뒤에 돌린다.
과반이 깨졌으면 수동 개입이 필요하다. kudu remote_replica unsafe_change_config 로 남아 있는 정상 복제본만으로 Raft 설정을 다시 쓴다. 데이터 손실 가능성이 있는 명령이므로 다음을 지킨다. 대상 tablet 과 정상 복제본을 ksck 로 특정하고, 작업 전 상태를 기록하고, 가능하면 벤더 지원과 함께 진행한다.
kudu remote_replica unsafe_change_config <tserver_host:7050> <tablet_id> <healthy_uuid>
UUID 가 바뀐 노드를 되돌릴 수 있으면 그게 가장 안전하다. 디렉터리를 잘못 지운 것이 원인이고 원본이 남아 있다면 복구해 원래 UUID 로 기동한다.
Unable to create file system roots: FsManager roots already exist
이미 Kudu 메타데이터가 있는 디렉터리에 kudu fs format 같은 초기화를 시도할 때 난다. 기존 데이터를 지우라는 신호가 아니라, 초기화할 필요가 없다는 신호로 읽는 편이 안전하다. 정말로 노드를 새로 만들 작정이 아니면 디렉터리를 지우지 않는다. 지우면 UUID 가 바뀌어 위의 문제를 스스로 만드는 셈이 된다.
DDL 은 마스터가 모든 관련 tserver 에 RPC 를 보내고 응답을 모아 완료한다. 한 대라도 응답하지 않으면 작업이 대기 상태로 남는다. 마스터 웹 UI(:8051)와 마스터 로그에서 어느 tablet · 어느 tserver 에서 막혔는지 확인하고, 그 노드의 상태부터 해결한다.