Cloudera Manager 나 Ambari 에서 Regions in transition over threshold, 또는 found regions staying in transition state for a duration longer than ... 경고가 뜬다. 해당 리전에 대한 읽기와 쓰기가 막히고, 심하면 테이블 전체가 응답하지 않는다.
리전은 RegionServer 사이를 옮겨 다닌다. RegionServer 장애, 밸런싱, move 명령, split 과 merge 가 계기다. 옮기는 동안 리전은 이전 서버에서 닫히고 새 서버에서 열리는데, 그 사이에는 요청을 받지 못한다. 이 중간 상태가 Region in Transition(RIT)이다.
| 상태 | 뜻 |
|---|---|
OFFLINE |
어느 RegionServer 에도 할당되지 않음 |
OPENING / OPENED |
새 서버에서 여는 중 / 열림 |
CLOSING / CLOSED |
닫는 중 / 닫힘 |
SPLITTING / MERGING |
분할 · 병합 중 |
FAILED_OPEN / FAILED_CLOSE |
열기 · 닫기 실패 |
정상이라면 수 초 안에 끝난다. 분 단위로 머무르면 무언가 막혀 있다는 뜻이다.
RegionServer 가 죽었거나 GC 로 길게 멈춰 heartbeat 를 놓친 경우가 가장 흔하다. 다음으로 HDFS 쪽 문제(NameNode safemode, 블록 누락, 디스크 장애)로 HFile 이나 WAL 을 열지 못하는 경우, ZooKeeper 세션 만료, 그리고 hbase:meta 자체의 불일치가 있다. failed janitorial scan of hbase:meta table 이 함께 찍히면 meta 불일치를 우선 의심한다.
echo "status 'detailed'" | hbase shell -n | sed -n '/regions in transition/,+20p'
hbase hbck -j /path/to/hbase-hbck2.jar report
hdfs dfsadmin -safemode get
hdfs fsck /hbase -files -blocks | tail -20
Master 웹 UI(기본 16010)의 Regions in Transition 화면에도 같은 정보가 나오며 머문 시간을 함께 보여 준다.
먼저 RegionServer 와 HMaster 로그에서 해당 리전 이름을 찾아 실제 예외를 확인한다. 원인이 HDFS 라면 리전을 건드리기 전에 HDFS 를 먼저 정상화한다.
HBase 2.x 에서 메타데이터를 손봐야 한다면 반드시 HBCK2 를 쓴다. 1.x 시절의 hbase hbck -repair 는 2.x 에서 동작하지 않거나 상태를 더 망가뜨린다.
hbase hbck -j /path/to/hbase-hbck2.jar report
hbase hbck -j /path/to/hbase-hbck2.jar assigns <ENCODED_REGIONNAME>
hbase hbck -j /path/to/hbase-hbck2.jar unassigns <ENCODED_REGIONNAME>
hbase hbck -j /path/to/hbase-hbck2.jar fixMeta
hbase hbck -j /path/to/hbase-hbck2.jar bypass -o <PID>
assigns 와 unassigns 는 인코딩된 리전 이름을 받는다. 마지막 수단으로 해당 RegionServer 를 재시작하고, 그래도 풀리지 않으면 HMaster 를 재시작한다. HMaster 재시작 시 진행 중이던 프로시저가 재개되므로, 그전에 bypass 로 막힌 프로시저를 정리해야 할 때가 있다.
unable to ask master to split 은 RegionServer 가 split 요청을 Master 에 전달하지 못한 상태다. RegionServer 와 Master 사이의 RPC 또는 ZooKeeper 연결, Master 과부하, 이미 RIT 에 걸린 리전이 원인이다.
이 메시지가 뜬다고 즉시 쓰기가 실패하지는 않는다. 해당 리전이 여전히 online 이면 Put 은 들어간다. 다만 split 이 계속 미뤄져 리전이 hbase.hregion.max.filesize(기본 10GiB)를 크게 넘기면 flush 와 compaction 부하가 커지면서 쓰기 지연이 늘고, 최악에는 쓰기가 막힌다. offline 상태로 떨어진 리전에 대한 쓰기는 즉시 실패한다.
RIT 가 장시간 풀리지 않는 원인은 클러스터마다 다르다. 위 절차로 상태는 되돌릴 수 있지만, 근본 원인(GC · 디스크 · 네트워크)을 찾지 못하면 재발한다. 반복된다면 RegionServer 의 GC 로그와 디스크 I/O 지표를 함께 수집해 확인한다.
hbase:meta 자체가 RIT 에 걸린 사례.