Kudu tablet server 롤링 재시작을 시도하다 abort 한 뒤, 한 노드의 WAL 디스크가 .recovery 디렉터리 70 GB 로 가득 차고 tablet 이 FAILED 로 남았으며, 다른 노드는 MAINTENANCE_MODE 에 걸려 있던 사례다. quiesce 가 하는 일, .recovery 가 커지는 원리, FAILED tablet 과 maintenance mode 의 처리 순서를 정리한다.
quiesce(Kudu 1.12+)는 서버를 내리기 전에 트래픽을 다른 서버로 빼는 드레인 단계다. 리더십을 다른 replica 로 넘기고 새 리더 선출을 거부하며, 새 스캔은 거부하고 진행 중인 스캔은 끝날 때까지 기다린다. 데이터나 replica 를 옮기지는 않는다.
sudo -u kudu kudu tserver quiesce start <tserver-addr>
sudo -u kudu kudu tserver quiesce status <tserver-addr> # 리더 0, 활성 스캔 0 이 될 때까지
sudo -u kudu kudu tserver quiesce stop <tserver-addr> # 재시작 없이 풀 때
한 번에 한 대씩만 진행하고, 다음 서버로 넘어가기 전에 ksck 가 healthy 인지 확인한다. RF=1 tablet 의 리더는 넘길 곳이 없어 드레인이 끝나지 않는다.
tserver 가 시작되면 tablet 마다 기존 WAL 디렉터리를 <tablet-id>.recovery 로 rename 하고 그것을 재생하면서 새 WAL 을 쓴 뒤, 부트스트랩이 끝나면 .recovery 를 지운다. 재생 중에는 WAL 공간이 두 배로 필요하다. 어떤 노드에만 WAL 이 비대해진 상태(follower lag 로 리더가 오래된 세그먼트를 보관, 플러시 지연, 롤링 재시작 중단으로 인한 리더 쏠림)에서 재시작하면 disk full → 부트스트랩 실패 → .recovery 잔류 → 재시도 반복으로 눈덩이처럼 커진다. 부트스트랩은 트리거일 뿐이고 근본 원인은 WAL 비대화다.
.recovery 나 WAL 파일을 지웠는지 확인한다. 지웠다면 그 tablet 의 미플러시 데이터는 유실된 것이다.FAILED tablet 은 자동 재시도되지 않는다. WAL 디렉터리에 평시 크기의 두 배 이상 여유를 확보하고 tserver 를 재시작해 다시 부트스트랩시킨다. BOOTSTRAPPING 이 진행 중이면 끝난 뒤 재시작한다.sudo -u kudu kudu cluster ksck <master-addrs>
# tserver 를 멈춘 뒤, RF=3 인 경우에만
sudo -u kudu kudu local_replica delete <tablet-id> --fs_wal_dir=<wal-dir> --fs_data_dirs=<data-dirs>
FAILED (TABLET_DATA_READY) ... tablet found rowset but no log segment could be found 는 데이터는 있는데 WAL 세그먼트가 하나도 없는 상태로, 정상 동작에서는 나오지 않으며 WAL 파일이 외부에서 지워졌다는 뜻이다. RF=3 이면 위와 같이 재복제한다.
maintenance mode 는 Kudu 가 스스로 들어가지 않는다. 수동 enter_maintenance 이거나 CM 등의 롤링 재시작이 노드를 내리기 전에 설정한 뒤 abort 로 해제 단계를 못 밟은 것이다. master 의 sys catalog 에 영구 저장되므로 시간이 지나도 풀리지 않는다. 서버가 살아 있는 동안은 무해해서 ksck 는 정상으로 보이지만, 그 서버가 죽었을 때 재복제를 억제하므로 반드시 해제한다.
sudo -u kudu kudu tserver list <master-addrs> -columns=uuid,rpc-addresses,state
sudo -u kudu kudu tserver state exit_maintenance <master-addrs> <tserver-uuid>
kudu table delete 로 지우면 HMS 연동 때문에 NoSuchObjectException 이 날 수 있다.