Timeline 일관성 고가용성 읽기

Timeline 일관성 고가용성 읽기 (Timeline-consistent High Available Reads)

HBase는 region 복제(region replication)를 통해 읽기 고가용성을 제공해요. 강한 일관성(STRONG)보다는 timeline 일관성을 사용해 지연 시간에 민감한 읽기 사용 사례를 지원하며, 쓰기가 실패해도 stale 데이터라도 읽을 수 있게 해줘요.

출처: 문서

본문

소개 (Introduction)

HBase는 구조적으로 처음부터 강한 일관성(strong consistency)을 보장해 왔어요. 모든 읽기와 쓰기가 단일 region server를 통해 라우팅되어, 모든 쓰기가 순서대로 발생하고 모든 읽기가 가장 최근에 커밋된 데이터를 보는 것이 보장돼요.

하지만 이 단일 homing(읽기를 단일 위치로 고정) 때문에 서버가 사용 불가능해지면, 그 region server에서 호스팅되던 테이블의 region들이 일정 시간 동안 사용 불가능해져요. region 복구 과정에는 감지(detection), 할당(assignment), 복구(recovery)의 세 단계가 있어요. 이 중 감지가 보통 가장 길며, 현재 ZooKeeper 세션 타임아웃에 따라 약 20~30초 수준이에요. 이 시간 동안 그리고 복구가 완료되기 전에 클라이언트는 region 데이터를 읽을 수 없어요.

하지만 일부 사용 사례에서는 데이터가 읽기 전용이거나, 약간의 stale 데이터에 대해 읽기를 해도 수용 가능할 수 있어요. timeline 일관성 고가용성 읽기를 사용하면, HBase는 애플리케이션이 읽기 완료에 시간 상한을 기대할 수 있는 지연 시간에 민감한 이러한 사용 사례에 사용될 수 있어요.

읽기 고가용성을 달성하기 위해 HBase는 region replication이라고 하는 기능을 제공해요. 이 모델에서 테이블의 각 region에 대해 여러 개의 복제본(replicas)이 다른 RegionServer들에서 열려요. 기본적으로 region replication은 1로 설정되어 있어, 단일 region 복제본만 배포되고 원래 모델에서 변경이 없어요. region replication이 2 이상으로 설정되면 master가 테이블의 region 복제본을 할당해요. Load Balancer는 region 복제본이 같은 region server와 (가능하면) 같은 랙에 공동 호스팅되지 않도록 보장해요.

단일 region의 모든 복제본은 0부터 시작하는 고유한 replica_id를 가져요. replica_id==0인 region 복제본을 기본(primary) region이라 하고, 나머지를 보조(secondary) region 또는 secondaries라고 해요. 기본만 클라이언트의 쓰기를 받을 수 있으며, 기본은 항상 최신 변경을 포함할 거예요. 모든 쓰기가 여전히 기본 region을 거쳐야 하므로, 쓰기는 고가용성이 아니에요(region이 사용 불가능해지면 잠시 막힐 수 있음).

Timeline 일관성 (Timeline Consistency)

이 기능으로 HBase는 읽기 연산(get 또는 scan)마다 제공될 수 있는 일관성(Consistency) 정의를 도입해요.

public enum Consistency {
    STRONG, TIMELINE
}

Consistency.STRONG은 HBase가 제공하는 기본 일관성 모델이에요. 테이블이 region replication = 1인 경우, 또는 region 복제본이 있는 테이블인데 이 일관성으로 읽을 때는 읽기가 항상 기본 region에 의해 수행되어 이전 동작에서 변경이 없고, 클라이언트는 항상 최신 데이터를 관찰해요.

Consistency.TIMELINE으로 읽기가 수행되면, 읽기 RPC가 먼저 기본 region server로 전송돼요. 짧은 간격(hbase.client.primaryCallTimeout.get, 기본 10ms) 후 기본이 응답하지 않으면 보조 region 복제본에 대한 병렬 RPC도 전송돼요. 이후 어느 RPC가 먼저 끝나는지에 따라 결과가 반환돼요. 응답이 기본 region 복제본에서 왔다면 데이터가 항상 최신임을 알 수 있어요. 이를 위해 Result.isStale() API가 추가되어 stale 여부를 검사해요. 결과가 보조 region에서 온 것이라면 Result.isStale()이 true로 설정돼요. 사용자는 이 필드를 검사해 데이터에 대해 추론할 수 있어요.

의미론 측면에서 HBase가 구현한 TIMELINE 일관성은 다음 측면에서 순수 최종 일관성(pure eventual consistency)과 달라요.

단일 homing 및 순서 있는 갱신: region 복제 여부와 관계없이 쓰기 측에서는 여전히 쓰기를 받을 수 있는 정의된 복제본(기본)이 1개뿐이에요. 이 복제본은 편집 순서를 정하고 충돌을 방지할 책임이 있어요. 이는 두 개의 서로 다른 쓰기가 서로 다른 복제본에 의해 동시에 커밋되어 데이터가 갈라지는 것을 보장하지 않아요. 이를 통해 read-repair나 last-timestamp-wins 같은 충돌 해결이 필요 없어요.
보조(secondaries)도 기본이 커밋한 순서대로 편집을 적용해요. 이렇게 하면 보조는 임의의 시점에 기본 데이터의 스냅샷을 포함하게 돼요. 이는 RDBMS 복제와 심지어 HBase 자체의 멀티 데이터센터 복제와 유사하지만, 단일 클러스터 안에서요.
읽기 측에서 클라이언트는 읽기가 최신 데이터에서 오는지 stale 데이터에서 오는지 감지할 수 있어요. 또한 클라이언트는 자체 의미론 보장을 보장하기 위해 연산별로 다른 일관성 요구사항으로 읽기를 발행할 수 있어요.
클라이언트는 여전히 편집 순서가 뒤섞인 것을 관찰할 수 있고, 한 보조 복제본에서 읽은 다음 다른 보조 복제본에서 읽으면 시간을 거슬러 갈 수 있어요. region 복제본에 대한 stickiness나 transaction-id 기반 보장은 없어요. 필요하다면 나중에 구현할 수 있어요.

Timeline 일관성

TIMELINE 의미를 더 잘 이해하기 위해 위 다이어그램을 살펴볼게요. 클라이언트가 두 명 있고, 첫 번째가 처음 x=1을 쓰고, 나중에 x=2와 x=3을 쓴다고 가정해 봐요. 위처럼 모든 쓰기는 기본 region 복제본이 처리해요. 쓰기는 로그 선행 쓰기(WAL)에 저장되고 비동기적으로 다른 복제본에 복제돼요. 위 다이어그램에서 replica_id=1은 두 번의 갱신을 받았고 그 데이터는 x=2를 보여주며, replica_id=2는 한 번의 갱신만 받았고 그 데이터는 x=1을 보여주는 것에 주목하세요.

client1이 STRONG 일관성으로 읽으면 replica_id=0과만 대화하므로 x=3의 최신 값을 관찰하는 것이 보장돼요. TIMELINE 일관성 읽기를 발행하는 클라이언트의 경우 RPC가 (기본 타임아웃 후) 모든 복제본으로 가고 첫 번째 응답의 결과가 반환돼요. 따라서 클라이언트는 x의 값으로 1, 2 또는 3을 볼 수 있어요. 기본 region이 실패했고 로그 복제가 한동안 계속될 수 없다고 가정해 봐요. 클라이언트가 TIMELINE 일관성으로 여러 번 읽으면, 처음에 x=2를, 그다음 x=1을 관찰할 수 있어요.

트레이드오프 (Tradeoffs)

읽기 가용성을 위해 보조 region을 호스팅하는 것은 사용 사례별로 신중히 평가해야 할 몇 가지 트레이드오프와 함께 와요. 다음은 장점과 단점이에요.

장점:

읽기 전용 테이블에 대한 고가용성
stale 읽기에 대한 고가용성
매우 높은 백분위수(99.9%+)의 stale 읽기 지연 시간으로 매우 낮은 지연 시간 읽기 수행 능력

단점:

region replication > 1인 테이블에 대한 이중/삼중 MemStore 사용(region replication 수에 따라)
증가된 블록 캐시 사용량
로그 복제를 위한 추가 네트워크 트래픽
복제본을 위한 추가 백업 RPC

여러 복제본에서 region 데이터를 서빙하기 위해 HBase는 region server에서 region을 보조(secondary) 모드로 열어요. 보조 모드로 열린 region은 기본 region 복제본과 동일한 데이터 파일을 공유하지만, 각 보조 region 복제본은 플러시되지 않은 데이터를 유지하기 위한 자체 MemStore를 가져요(플러시는 기본 region만 할 수 있음). 또한 보조 region에서 읽기를 서빙하기 위해 데이터 파일의 블록이 보조 region의 블록 캐시에도 캐시될 수 있어요.

코드는 어디에 있나요 (Where is the code)

이 기능은 Phase 1과 2의 두 단계로 제공돼요. 첫 번째 단계는 HBase-1.0.0 릴리스에 맞춰 완료됐어요. 즉, HBase-1.0.x를 사용하면 Phase 1로 표시된 모든 기능을 사용할 수 있어요. Phase 2는 HBase-1.1.0에서 커밋되었으므로 1.1.0 이후의 모든 HBase 버전에는 Phase 2 항목이 포함되어야 해요.

region 복제본으로 쓰기 전파 (Propagating writes to region replicas)

위에서 논의했듯이 쓰기는 기본 region 복제본으로만 가요. 기본 region 복제본에서 보조로 쓰기를 전파하는 데는 두 가지 다른 메커니즘이 있어요. 읽기 전용 테이블의 경우 다음 방법 중 어떤 것도 사용할 필요가 없어요. 테이블을 비활성화하고 활성화하면 모든 region 복제본에서 데이터를 사용할 수 있게 돼요. 변경 가능한(mutable) 테이블의 경우 storefile refresher 또는 async wal replication 중 하나만 사용해야 해요. 후자를 권장해요.

StoreFile Refresher

첫 번째 메커니즘은 HBase-1.0+에서 도입된 store file refresher이에요. store file refresher는 region server당 하나의 스레드로, 주기적으로 실행되며 보조 region 복제본을 위해 기본 region의 store 파일에 대한 refresh 연산을 수행해요. 활성화되면 refresher는 보조 region 복제본이 기본 region에서 새로 플러시/압축/벌크 로드된 파일을 제때 볼 수 있도록 보장해요. 하지만 이는 플러시된 데이터만 보조 region 복제본에서 다시 읽을 수 있다는 것을 의미하며, refresher 실행 후 보조가 기본보다 더 오래 뒤처지게 해요.

이 기능을 켜려면 hbase.regionserver.storefile.refresh.period를 0이 아닌 값으로 구성해야 해요. 아래 Configuration 섹션을 참고해 주세요.

Async WAL replication

보조로 쓰기를 전파하는 두 번째 메커니즘은 "Async WAL Replication" 기능을 통한 것이에요. HBase-1.1+에서만 사용 가능해요. 이것은 HBase의 멀티 데이터센터 복제와 유사하게 작동하지만, 대신 region의 데이터가 보조 region으로 복제돼요. 각 보조 복제본은 항상 기본 region이 커밋한 것과 같은 순서로 쓰기를 받고 관찰해요. 어떤 의미에서 이 설계는 "클러스터 내 복제(in-cluster replication)"로 생각할 수 있는데, 다른 데이터센터로 복제하는 대신 데이터가 보조 region으로 가서 보조 region의 인메모리 상태를 최신으로 유지하는 것이에요. 데이터 파일은 기본 region과 다른 복제본 사이에 공유되므로 추가 저장 오버헤드가 없어요. 하지만 보조 region은 플러시되지 않은 최근 데이터를 memstore에 갖게 되어 메모리 오버헤드가 증가해요. 기본 region은 플러시, 압축, 벌크 로드 이벤트도 자신의 WAL에 기록하는데, 이 역시 wal replication을 통해 보조로 복제돼요. 보조 region은 그 플러시/압축 또는 벌크 로드 이벤트를 관찰할 때 이벤트를 재생해 새 파일을 가져오고 이전 파일을 버려요.

기본과 같은 순서로 쓰기를 커밋하면 보조가 기본 region 데이터에서 갈라지지 않도록 보장하지만, 로그 복제가 비동기이므로 보조 region의 데이터는 여전히 stale일 수 있어요.

Async WAL Replication은 기본적으로 비활성화돼요. hbase.region.replica.replication.enabled를 true로 설정해 이 기능을 활성화할 수 있어요.

3.0.0 이전에 이 기능은 복제 엔드포인트로 작동하며, 성능과 지연 시간 특성은 클러스터 간 복제와 유사할 것으로 기대돼요. 한 번 활성화하면, region replication > 1로 테이블을 처음 만들 때 region_replica_replication이라는 이름의 복제 peer를 생성해요.

이 기능을 비활성화하려면 다음 순서로 두 작업을 수행해야 해요.

hbase-site.xml에서 hbase.region.replica.replication.enabled 구성 속성을 false로 설정(아래 Configuration 섹션 참고)
hbase shell 또는 Admin 클래스를 사용해 클러스터에서 region_replica_replication이라는 복제 peer를 비활성화:

hbase> disable_peer 'region_replica_replication'

3.0.0에서 이 기능은 일반 복제 프레임워크에서 분리되도록 재구현됐어요. 이제 특수 복제 peer를 만들 필요가 없어요. 그리고 rolling 업그레이드 중에 그 복제 peer가 존재하면 자동으로 제거할 거예요. 자세한 내용은 HBASE-26233과 우리 git 저장소의 디자인 문서를 참고해 주세요.

Async WAL Replication과 hbase:meta 테이블은 조금 더 복잡하며 아래에서 자체 섹션을 갖습니다. META 테이블의 region에 대한 Region replication을 참고해 주세요.

Store File TTL

위에서 언급한 두 쓰기 전파 접근 모두에서 기본의 store 파일이 기본 region과 독립적으로 보조에서 열려요. 그래서 기본이 압축해 버린 파일을 보조가 여전히 읽기를 위해 참조할 수 있어요. 두 기능 모두 파일을 참조하는 데 HFileLinks를 사용하지만, 파일이 조기에 삭제되지 않도록 보장하는 보호(아직)는 없어요. 따라서 가드로서 hbase.master.hfilecleaner.ttl 구성 속성을 1시간 같은 더 큰 값으로 설정해 복제본으로 가는 요청에 대해 IOException을 받지 않도록 보장해야 해요.

META 테이블의 region에 대한 Region replication (Region replication for META table's region)

일반 Async WAL Replication은 META 테이블의 WAL에 대해서는 작동하지 않아요. meta 테이블의 보조 복제본은 hbase.regionserver.meta.storefile.refresh.period(0이 아닌 값)마다 영속 store 파일에서 스스로 새로고침해요. META 복제 주기가 사용자 영역의 hbase.regionserver.storefile.refresh.period 값과 구별된다는 점에 주의하세요.

hbase-2.4.0+에서 META 테이블에 대한 Async WAL Replication

META에 대한 Async WAL replication은 2.4.0의 새 기능으로 추가됐어요. hbase.region.replica.replication.catalog.enabled를 설정해 META region 복제본에 대한 async WAL Replication을 활성화해 주세요. 기본적으로 꺼져 있어요.

META 복제본 수와 관련해 hbase-2.4.0까지는 특수 속성 'hbase.meta.replica.count'를 설정했어요. 이제 사용자 공간 테이블처럼 META 테이블을 변경할 수 있어요(hbase.meta.replica.count가 설정되면, META 테이블의 replica count에 설정된 값보다 우선하며 META replica count가 그에 맞게 갱신됨).

hbase-3.0.0+에서 META 테이블에 대한 Async WAL Replication

HBASE-26233에서 region replication 프레임워크를 일반 복제 프레임워크에 의존하지 않도록 재구현해서, META 테이블과도 함께 작동할 수 있게 했어요. 위 섹션에서 설명한 코드는 대부분 제거되었지만 hbase.region.replica.replication.catalog.enabled 구성은 여전히 유지되어, META 테이블에 대한 async wal replication을 활성화할지 제어하는 데 계속 사용할 수 있어요. 그리고 META 테이블을 변경하는 능력도 유지돼요.

META 테이블 부하 분산 (Load Balancing META table load)

hbase-2.4.0은 또한 새로운 클라이언트 측 LoadBalance 모드를 추가해요. 클라이언트 측에서 활성화되면 클라이언트는 기본에 폴백하기 전에 먼저 META 복제본을 읽으려 시도해요. 그 전에는 복제본 조회 모드 — 이제 hbase-2.4.0에서 HedgedRead라는 이름으로 불림 — 가 클라이언트가 기본을 읽고 구성 가능한 시간이 경과해도 응답이 없으면 복제본에 대해 읽기를 시작했어요. hbase-2.4.12(모든 더 높은 마이너 버전)부터 클라이언트 측 LoadBalance 모드에서 클라이언트는 기본 META region을 포함해 모든 META replica region에 걸쳐 META scan 요청의 부하를 분산해요. NotServingRegionException 같은 예외가 발생하면 기본 META region에 폴백해요.

새 'LoadBalance' 모드는 META 테이블에 대한 hot-spotting을 완화하고 META 읽기 부하를 분산해주는 데 도움을 줘요.

meta replica locator의 load balance 모드를 활성화하려면 클라이언트 측에서만(만) 다음 구성을 설정해 주세요: 'hbase.locator.meta.replicas.mode'를 "LoadBalance"로 설정. 이 구성의 유효한 옵션은 None, HedgedRead, LoadBalance예요. 옵션 파싱은 대소문자를 구분하지 않아요. 기본 모드는 None(현재 기본인 HedgedRead로 이어짐)이에요. 이 구성을 HBase 서버 측(Master 또는 RegionServer) 구성에 넣지 마세요(Master가 stale 상태를 기반으로 결정을 내릴 수 있으므로 피해야 해요).

메모리 회계 (Memory accounting)

보조 region 복제본은 기본 region 복제본의 데이터 파일을 참조하지만 자체 memstore(HBase-1.1+)를 가지며 블록 캐시도 사용해요. 하지만 한 가지 차이는 보조 region 복제본은 memstore에 메모리 압박이 있을 때 데이터를 플러시할 수 없다는 것이에요. 기본 region이 플러시를 하고 그 플러시가 보조에 복제될 때만 memstore 메모리를 해제할 수 있어요. 어떤 region에 대해서는 기본 복제본을, 다른 region에 대해서는 보조를 호스팅하는 region server에서 보조가 같은 호스트의 기본 region에 추가 플러시를 일으킬 수 있어요. 극단적인 상황에서는 wal replication을 통해 기본에서 오는 새 쓰기를 추가하기 위한 메모리가 남지 않을 수 있어요. 이 상황을 해제하기 위해(그리고 보조가 스스로 플러시할 수 없으므로) 보조는 파일시스템 목록 연산을 수행해 기본에서 새 파일을 가져오고, 가능하면 memstore를 버리는 "store file refresh"를 수행할 수 있어요. 이 refresh는 가장 큰 보조 region 복제본의 memstore 크기가 가장 큰 기본 복제본 memstore의 hbase.region.replica.storefile.refresh.memstore.multiplier(기본 4)배 이상일 때만 수행돼요. 한 가지 주의할 점은, 이 작업이 수행되면 보조가 컬럼 패밀리 전반에 걸쳐 부분적인 행 갱신을 관찰할 수 있다는 것이에요(컬럼 패밀리가 독립적으로 플러시되기 때문). 기본값은 이 연산을 자주 수행하지 않도록 하기에 좋아야 해요. 원하면 이 값을 큰 숫자로 설정해 이 기능을 비활성화할 수 있지만, 복제가 영원히 막힐 수 있으니 주의해야 해요.

보조 복제본 장애 조치 (Secondary replica failover)

보조 region 복제본이 처음 온라인 상태가 되거나 장애 조치할 때, memstore에서 일부 편집을 서빙했을 수 있어요. 보조 복제본의 복구는 다르게 처리되므로, 보조는 할당 후 요청 서빙을 시작하기 전에 시간을 거슬러 가지 않도록 해야 해요. 이를 위해 보조는 전체 플러시 주기(플러시 시작, 플러시 커밋) 또는 기본에서 복제된 "region open 이벤트"를 관찰할 때까지 기다려요. 그때까지 보조 region 복제본은 "The region's reads are disabled" 메시지와 함께 IOException을 던져 모든 읽기 요청을 거부할 거예요. 하지만 다른 복제본은 여전히 읽을 수 있을 것이므로 TIMELINE 일관성의 rpc에 영향이 없을 거예요. 더 빠른 복구를 돕기 위해 보조 region은 열릴 때 기본에 플러시 요청을 트리거해요. 구성 속성 hbase.region.replica.wait.for.primary.flush(기본 활성화)를 사용해 필요하면 이 기능을 비활성화할 수 있어요.

구성 속성 (Configuration properties)

고가용성 읽기를 사용하려면 hbase-site.xml 파일에 다음 속성을 설정해야 해요. region 복제본을 활성화/비활성화하는 특정 구성은 없어요. 대신 테이블 생성이나 alter table에서 제목당 region 복제본 수를 변경해 늘리거나 줄일 수 있어요. 다음 구성은 async wal replication을 사용하고 meta 복제본 3개를 사용하기 위한 것이에요.

서버 측 속성

<property>
  <name>hbase.regionserver.storefile.refresh.period</name>
  <value>0</value>
  <description>
    The period (in milliseconds) for refreshing the store files for the secondary regions. 0 means this feature is disabled. Secondary regions sees new files (from flushes and compactions) from primary once the secondary region refreshes the list of files in the region (there is no notification mechanism). But too frequent refreshes might cause extra Namenode pressure. If the files cannot be refreshed for longer than HFile TTL (hbase.master.hfilecleaner.ttl) the requests are rejected. Configuring HFile TTL to a larger value is also recommended with this setting.
  </description>
</property>

<property>
  <name>hbase.regionserver.meta.storefile.refresh.period</name>
  <value>300000</value>
  <description>
    The period (in milliseconds) for refreshing the store files for the hbase:meta tables secondary regions. 0 means this feature is disabled. Secondary regions sees new files (from flushes and compactions) from primary once the secondary region refreshes the list of files in the region (there is no notification mechanism). But too frequent refreshes might cause extra Namenode pressure. If the files cannot be refreshed for longer than HFile TTL (hbase.master.hfilecleaner.ttl) the requests are rejected. Configuring HFile TTL to a larger value is also recommended with this setting. This should be a non-zero number if meta replicas are enabled.
  </description>
</property>

<property>
  <name>hbase.region.replica.replication.enabled</name>
  <value>true</value>
  <description>
    Whether asynchronous WAL replication to the secondary region replicas is enabled or not. If this is enabled, a replication peer named "region_replica_replication" will be created which will tail the logs and replicate the mutations to region replicas for tables that have region replication > 1. If this is enabled once, disabling this replication also requires disabling the replication peer using shell or Admin java class. Replication to secondary region replicas works over standard inter-cluster replication.
  </description>
</property>

<property>
  <name>hbase.master.hfilecleaner.ttl</name>
  <value>3600000</value>
  <description>
    The period (in milliseconds) to keep store files in the archive folder before deleting them from the file system.
  </description>
</property>

<property>
  <name>hbase.region.replica.storefile.refresh.memstore.multiplier</name>
  <value>4</value>
  <description>
    The multiplier for a "store file refresh" operation for the secondary region replica. If a region server has memory pressure, the secondary region will refresh it's store files if the memstore size of the biggest secondary replica is bigger this many times than the memstore size of the biggest primary replica. Set this to a very big value to disable this feature (not recommended).
  </description>
</property>

<property>
  <name>hbase.region.replica.wait.for.primary.flush</name>
  <value>true</value>
  <description>
    Whether to wait for observing a full flush cycle from the primary before start serving data in a secondary. Disabling this might cause the secondary region replicas to go back in time for reads between region movements.Please note that if you set per-table property `REGION_MEMSTORE_REPLICATION` to false,`hbase.region.replica.wait.for.primary.flush` will be ignored.
  </description>
</property>

한 가지 명심할 것은 region 복제본 배치 정책은 기본 밸런서인 StochasticLoadBalancer에 의해서만 강제된다는 거예요. hbase-site.xml(hbase.master.loadbalancer.class)에서 커스텀 로드 밸런서 속성을 사용한다면 region 복제본이 같은 서버에 호스팅될 수 있어요.

클라이언트 측 속성

region 복제본을 사용할 모든 클라이언트(및 서버)에 대해 다음을 설정해야 해요.

<property>
  <name>hbase.ipc.client.specificThreadForWriting</name>
  <value>true</value>
  <description>
    Whether to enable interruption of RPC threads at the client side. This is required for region replicas with fallback RPC's to secondary regions.
  </description>
</property>
<property>
  <name>hbase.client.primaryCallTimeout.get</name>
  <value>10000</value>
  <description>
    The timeout (in microseconds), before secondary fallback RPC's are submitted for get requests with Consistency.TIMELINE to the secondary replicas of the regions. Defaults to 10ms. Setting this lower will increase the number of RPC's, but will lower the p99 latencies.
  </description>
</property>
<property>
  <name>hbase.client.primaryCallTimeout.multiget</name>
  <value>10000</value>
  <description>
    The timeout (in microseconds), before secondary fallback RPC's are submitted for multi-get requests (Table.get(List<Get>)) with Consistency.TIMELINE to the secondary replicas of the regions. Defaults to 10ms. Setting this lower will increase the number of RPC's, but will lower the p99 latencies.
  </description>
</property>
<property>
  <name>hbase.client.replicaCallTimeout.scan</name>
  <value>1000000</value>
  <description>
    The timeout (in microseconds), before secondary fallback RPC's are submitted for scan requests with Consistency.TIMELINE to the secondary replicas of the regions. Defaults to 1 sec. Setting this lower will increase the number of RPC's, but will lower the p99 latencies.
  </description>
</property>
<property>
  <name>hbase.meta.replicas.use</name>
  <value>true</value>
  <description>
    Whether to use meta table replicas or not. Default is false.
  </description>
</property>

참고: HBase-1.0.x 사용자는 hbase.ipc.client.specificThreadForWriting 대신 hbase.ipc.client.allowsInterrupt를 사용해야 해요.

사용자 인터페이스 (User Interface)

master 사용자 인터페이스에서 테이블의 region 복제본도 기본 region과 함께 표시돼요. region의 복제본이 같은 시작·끝 키와 같은 region 이름 접두사를 공유하는 것을 알 수 있어요. 유일한 차이는 덧붙여진 replica_id(hex로 인코딩됨)이며, region 인코딩 이름은 달라질 거예요. 또한 UI에서 복제본 id가 명시적으로 표시되는 것을 볼 수 있어요.

region replication으로 테이블 만들기 (Creating a table with region replication)

Region replication은 제목당 속성이에요. 모든 테이블은 기본적으로 REGION_REPLICATION = 1을 가지며, 이는 region당 복제본이 하나뿐이라는 뜻이에요. 테이블 설명자에 REGION_REPLICATION 속성을 제공해 테이블의 region당 복제본 수를 설정하고 변경할 수 있어요.

REGION_MEMSTORE_REPLICATION이라는 또 다른 제목당 속성이 있어요. 모든 테이블은 기본적으로 REGION_MEMSTORE_REPLICATION = true를 가지며, 이는 기본 region에 기록된 새 데이터가 복제되어야 한다는 뜻이에요. false로 설정하면 복제본이 기본 RegionServer의 memstore 갱신을 받지 못하고, 플러시와 벌크로드 같은 이벤트에 대한 갱신만 받으며, 기본이 아직 플러시하지 않은 데이터에는 접근할 수 없어요. REGION_MEMSTORE_REPLICATION을 false로 설정하면 hbase.region.replica.wait.for.primary.flush가 무시된다는 점에 주의해 주세요.

Shell

create 't1', 'f1', {REGION_REPLICATION => 2}

describe 't1'

for i in 1..100
put 't1', "r#{i}", 'f1:c1', i
end

flush 't1'

Java

HTableDescriptor htd = new HTableDescriptor(TableName.valueOf("test_table"));
htd.setRegionReplication(2);
...
admin.createTable(htd);

또한 setRegionReplication()과 alter table을 사용해 테이블의 region replication을 늘리거나 줄일 수 있어요.

읽기 API 및 사용법 (Read API and Usage)

Shell

Consistency.TIMELINE 의미론으로 shell에서 다음과 같이 읽기를 할 수 있어요.

hbase(main):001:0> get 't1','r6', {CONSISTENCY => "TIMELINE"}

region server가 일시 정지하거나 사용 불가능해지는 것을 시뮬레이션하고 보조 복제본에서 읽기를 할 수 있어요.

$ kill -STOP <pid or primary region server>

hbase(main):001:0> get 't1','r6', {CONSISTENCY => "TIMELINE"}

스캔 사용도 비슷해요.

hbase> scan 't1', {CONSISTENCY => 'TIMELINE'}

Java

Gets와 Scans에 일관성을 설정하고 다음과 같이 요청할 수 있어요.

Get get = new Get(row);
get.setConsistency(Consistency.TIMELINE);
...
Result result = table.get(get);

여러 get을 전달할 수도 있어요.

Get get1 = new Get(row);
get1.setConsistency(Consistency.TIMELINE);
...
ArrayList<Get> gets = new ArrayList<Get>();
gets.add(get1);
...
Result[] results = table.get(gets);

그리고 Scans:

Scan scan = new Scan();
scan.setConsistency(Consistency.TIMELINE);
...
ResultScanner scanner = table.getScanner(scan);

결과가 기본 region에서 왔는지 Result.isStale() 메서드를 호출해 검사할 수 있어요.

Result result = table.get(get);
if (result.isStale()) {
  ...
}

더 알아보기 (Learn more)

Region replication, Regions, RegionServer 등 HBase 고가용성과 region 관리 관련 문서를 이어서 보시길 권해요.