disable 'tbl' 을 실행했는데 끝나지 않고 disabling 상태에 머문다. is_enabled 와 is_disabled 가 모두 true 를 돌려주지 않는다. drop 도 되지 않고, 테이블이 목록에 보이지 않는데 같은 이름으로 create 하면 이미 존재한다는 오류가 난다.
echo "is_enabled 'my_table'" | hbase shell -n
echo "is_disabled 'my_table'" | hbase shell -n
echo "describe 'my_table'" | hbase shell -n
hbase hbck -j /path/to/hbase-hbck2.jar report
HMaster 로그에서 disable 프로시저가 어느 단계에서 멈췄는지, RegionServer 로그에서 리전을 닫지 못한 이유가 무엇인지 확인한다. 대부분 일부 리전이 Region in Transition 에 걸려 닫히지 않은 상태다.
HBase 2.x 라면 HBCK2 로 진행 중인 프로시저를 우회하고 테이블 상태를 직접 고친다.
hbase hbck -j /path/to/hbase-hbck2.jar bypass -o <PID>
hbase hbck -j /path/to/hbase-hbck2.jar setTableState my_table DISABLED
echo "drop 'my_table'" | hbase shell -n
bypass 는 report 나 Master UI 의 Procedures 화면에서 확인한 프로시저 ID 를 받는다. setTableState 는 hbase:meta 의 테이블 상태를 강제로 바꾸므로, 리전이 여전히 열려 있는 상태에서 쓰면 불일치가 남는다. 먼저 리전을 정리하고 마지막 수단으로 쓴다.
삭제가 중간에 끊기면 ZooKeeper 나 hbase:meta 에 흔적이 남아 같은 이름을 다시 만들지 못한다.
hbase hbck -j /path/to/hbase-hbck2.jar report
hbase zkcli
ls /hbase/table
ls /hbase/table-lock
ZooKeeper znode 를 직접 지우는 것은 HBase 1.x 시절 절차다. HBase 2.x 는 테이블 상태를 hbase:meta 에 두므로, znode 를 지워도 해결되지 않고 오히려 상태가 갈린다. 2.x 에서는 setTableState 와 fixMeta 로 처리하고, 그래도 안 되면 HMaster 를 재시작한다.
HDFS 에 남은 디렉터리를 지워야 한다면 HBase 가 그 경로를 더 이상 쓰지 않는 것을 확인한 뒤 진행한다.
hdfs dfs -ls /hbase/data/default/my_table
hdfs dfs -rm -r -skipTrash /hbase/data/default/my_table
-skipTrash 는 되돌릴 수 없다. 스냅샷이 있는지 먼저 확인한다.
-skipTrash 를 조직 차원에서 막는 직접적인 HDFS 설정은 없다. 실무에서는 감사 로그에서 사용을 탐지하거나, 운영 계정에서 hdfs 명령을 래퍼 스크립트로 감싸 거르거나, Ranger 정책으로 삭제 권한 자체를 제한하는 방식으로 다룬다.