동기화 복제

동기화 복제 (Synchronous Replication)

이 문서는 HBase의 동기화 복제(synchronous replication)를 설명해요. 기본 클러스터 복제는 비동기 방식이라 마스터 클러스터가 크래시하면 슬레이브 클러스터에 최신 데이터가 없을 수 있어요. 강한 일관성이 필요할 때 동기화 복제를 설정하는 방법을 다뤄요.

출처: 문서

본문

배경

HBase의 현재 클러스터 복제는 비동기 방식이에요. 그래서 마스터 클러스터가 크래시하면 슬레이브 클러스터에 최신 데이터가 없을 수 있어요. 사용자가 강한 일관성을 원한다면 슬레이브 클러스터로 전환할 수 없어요.

설계

설계 문서는 HBASE-19064를 참고하세요.

운영과 유지보수

사례 1. 두 동기화 복제 클러스터 설정

소스 클러스터와 피어 클러스터 양쪽에 동기화 피어를 추가해요.

소스 클러스터:

hbase> add_peer  '1', CLUSTER_KEY => 'lg-hadoop-tst-st01.bj:10010,lg-hadoop-tst-st02.bj:10010,lg-hadoop-tst-st03.bj:10010:/hbase/test-hbase-slave', REMOTE_WAL_DIR=>'hdfs://lg-hadoop-tst-st01.bj:20100/hbase/test-hbase-slave/remoteWALs', TABLE_CFS => {"ycsb-test"=>[]}

피어 클러스터:

hbase> add_peer  '1', CLUSTER_KEY => 'lg-hadoop-tst-st01.bj:10010,lg-hadoop-tst-st02.bj:10010,lg-hadoop-tst-st03.bj:10010:/hbase/test-hbase', REMOTE_WAL_DIR=>'hdfs://lg-hadoop-tst-st01.bj:20100/hbase/test-hbase/remoteWALs', TABLE_CFS => {"ycsb-test"=>[]}

동기화 복제의 경우 현재 구현은 소스 클러스터와 피어 클러스터가 같은 피어 ID를 가져야 해요. 또 주의할 점은 피어가 클러스터 수준, 네임스페이스 수준, cf 수준 복제를 지원하지 않고 현재는 테이블 수준 복제만 지원한다는 것이에요.

피어 클러스터를 STANDBY 상태로 전환

hbase> transit_peer_sync_replication_state '1', 'STANDBY'

소스 클러스터를 ACTIVE 상태로 전환

hbase> transit_peer_sync_replication_state '1', 'ACTIVE'

이제 동기화 복제가 성공적으로 설정됐어요. HBase 클라이언트는 소스 클러스터에만 요청할 수 있어요. 피어 클러스터에 요청하면 현재 STANDBY 상태인 피어 클러스터가 읽기/쓰기 요청을 거부할 거예요.

사례 2. 대기 클러스터가 크래시했을 때 운영 방법

대기 클러스터(standby cluster)가 크래시하면 활성 클러스터가 remote WAL을 쓰지 못할 거예요. 그래서 소스 클러스터를 DOWNGRADE_ACTIVE 상태로 전환해야 해요. 이 상태는 소스 클러스터가 더 이상 remote WAL을 쓰지 않는다는 뜻이에요. 하지만 일반 복제(비동기 복제)는 여전히 정상 동작해서 새로 쓰인 WAL을 큐에 넣지만, 복제는 피어 클러스터가 돌아올 때까지 차단돼요.

hbase> transit_peer_sync_replication_state '1', 'DOWNGRADE_ACTIVE'

피어 클러스터가 돌아오면 소스 클러스터를 ACTIVE로 전환해서 복제가 동기화되도록 하면 돼요.

hbase> transit_peer_sync_replication_state '1', 'ACTIVE'

사례 3. 활성 클러스터가 크래시했을 때 운영 방법

활성 클러스터가 크래시했다면(지금은 연결이 안 될 수 있어요), 대기 클러스터를 DOWNGRADE_ACTIVE 상태로 전환하고, 그 후 클라이언트의 모든 요청을 DOWNGRADE_ACTIVE 클러스터로 리다이렉트하면 돼요.

hbase> transit_peer_sync_replication_state '1', 'DOWNGRADE_ACTIVE'

크래시한 클러스터가 다시 돌아오면 그냥 STANDBY로 전환하면 돼요. 그렇지 않고 클러스터를 DOWNGRADE_ACTIVE로 전환하면 원래 ACTIVE 클러스터가 현재 ACTIVE 클러스터에 비해 중복된 데이터를 가질 수 있어요. 소스 클러스터 WAL과 원격 클러스터 WAL을 동시에 쓰도록 설계했기 때문에 소스 클러스터 WAL이 원격 클러스터보다 더 많은 데이터를 가질 수 있고, 이는 데이터 불일치로 이어질 수 있어요. ACTIVE에서 STANDBY로 전환하는 절차는 원래 WAL을 재생하는 것을 건너뛰므로 문제가 없어요.

hbase> transit_peer_sync_replication_state '1', 'STANDBY'

그 후 DOWNGRADE_ACTIVE 클러스터를 ACTIVE로 승격시켜서 복제가 동기화되도록 할 수 있어요.

hbase> transit_peer_sync_replication_state '1', 'ACTIVE'

동기화 복제