HBase 복제는 원본 클러스터의 WAL(Write-Ahead Log) 을 대상 클러스터로 보내 재생하는 방식이다. 비동기이며 최종 일관성을 갖는다. 즉 원본에 쓴 즉시 대상에 반영되는 것이 아니고, 복제 지연과 재시도가 있는 것을 전제로 설계해야 한다.
복제 단위는 컬럼 패밀리다. 테이블을 통째로 지정하는 것처럼 보이는 명령도 내부적으로는 컬럼 패밀리의 REPLICATION_SCOPE 를 바꾼다.
HBase 2 계열에서는 hbase.replication 이 기본으로 켜져 있다. Cloudera Manager 에서는 HBase 서비스 설정에서 복제 관련 항목을 확인한다. 값이 꺼져 있으면 켜고 HBase 를 재시작한다 — 이 설정 변경은 재시작을 요구한다.
원본 클러스터의 hbase shell 에서 대상 클러스터를 피어로 등록한다.
add_peer 'peer1', CLUSTER_KEY => 'zk1.example.com,zk2.example.com,zk3.example.com:2181:/hbase'
CLUSTER_KEY 는 ZooKeeper 쿼럼:포트:znode 부모 형식이며, 대상 클러스터의 값을 넣는다. znode 부모는 대상의 zookeeper.znode.parent 와 같아야 한다.
등록 상태를 확인한다.
list_peers
피어를 다루는 명령은 다음과 같다.
disable_peer 'peer1'
enable_peer 'peer1'
remove_peer 'peer1'
remove_peer 는 되돌릴 수 없고 대기 중이던 WAL 큐를 버린다. 일시 중단이 목적이면 disable_peer 를 쓴다.
컬럼 패밀리의 REPLICATION_SCOPE 를 1 로 바꾼다. 0 은 복제하지 않음이다.
disable 'ns:my_table'
alter 'ns:my_table', {NAME => 'cf1', REPLICATION_SCOPE => '1'}
enable 'ns:my_table'
다음 명령은 대상 클러스터에 같은 테이블이 있는지 확인하고 전체 컬럼 패밀리의 스코프를 한 번에 바꾼다.
enable_table_replication 'ns:my_table'
새로 만든 테이블과 나중에 추가한 컬럼 패밀리는 복제 대상이 되지 않는다. 테이블 생성 절차에 스코프 설정을 넣어 두지 않으면 조용히 빠진다.
복제는 설정한 시점 이후의 WAL 만 보낸다. 이미 들어 있던 데이터는 따로 옮겨야 한다. 스냅샷을 떠서 ExportSnapshot 으로 대상에 복사한 뒤 복제를 켜는 순서가 일반적이다.
status 'replication'
Cloudera Manager 의 HBase 차트에서 복제 관련 지표(대기 중인 WAL 크기, age of last shipped op)를 보는 편이 추세 파악에 낫다. 지연이 계속 커지면 대상 클러스터의 쓰기 성능이나 네트워크를 먼저 본다.
양방향 복제를 구성하면 같은 행 키에 양쪽에서 쓰는 순간 충돌 해소 규칙이 없다. 키 공간을 네임스페이스나 접두사로 갈라 두는 전제에서만 쓴다.
피어를 제거하면 그 피어의 WAL 큐가 정리되는데, 이 과정에서 RegionServer 에 영향이 간 사례가 있다. 복제 피어 제거가 RegionServer 를 죽이는 증상 을 먼저 읽고 작업한다.