백업 & 스냅샷

백업 & 스냅샷 (Backup & Snapshots)

HBase 데이터 보호를 위한 백업 전략과 스냅샷 운영을 설명하는 페이지예요. 전체 클러스터 백업과 라이브 클러스터 스냅샷, 그리고 다양한 중간 저장소 연동까지 다룹니다.

출처: 문서

본문

HBase 백업 (HBase Backup)

HBase 백업을 수행하는 두 가지 폭넓은 전략이 있어요: 전체 클러스터 종료와 함께하는 백업, 라이브 클러스터에서의 백업. 각 접근에는 장단점이 있어요.

추가 정보는 Sematext 블로그의 HBase Backup Options를 참고하세요.

전체 종료 백업 (Full Shutdown Backup)

일부 환경은 주기적 전체 종료를 견딜 수 있어요. 예를 들어 백엔드 분석 용량으로 사용되어 프론트엔드 웹 페이지를 서빙하지 않는 경우예요. 이점은 NameNode/Master가 RegionServers가 다운되어 StoreFiles나 메타데이터에 대한 진행 중인 변경을 놓칠 가능성이 없다는 것이에요. 명백한 단점은 클러스터가 다운된다는 것이에요. 단계는 다음과 같아요.

HBase 중지 (Stop HBase)

Distcp

Distcp는 HDFS의 HBase 디렉터리 내용을 같은 클러스터의 다른 디렉터리로나 다른 클러스터로 복사하는 데 사용할 수 있어요.

메모: Distcp가 이 상황에서 동작하는 것은 클러스터가 다운되어 파일에 진행 중인 편집이 없기 때문이에요. 라이브 클러스터에서는 HBase 디렉터리의 파일을 distcp하는 것이 일반적으로 권장되지 않아요.

복원(필요 시) (Restore (if needed))

HDFS에서 hbase 디렉터리의 백업은 distcp를 통해 '실제' hbase 디렉터리로 복사돼요. 이 파일들을 복사하는 행위는 새 HDFS 메타데이터를 만들기 때문에, 이런 종류의 복원에는 HBase 백업 시점의 NameNode edits 복원이 필요하지 않아요. 특정 HDFS 디렉터리(즉, HBase 부분)의 복원(distcp 통한)이지 전체 HDFS 파일시스템이 아니기 때문이에요.

라이브 클러스터 백업 - 복제 (Live Cluster Backup - Replication)

이 접근은 두 번째 클러스터가 있다고 가정해요. 자세한 내용은 replication에 대한 HBase 페이지를 참고하세요.

라이브 클러스터 백업 - CopyTable (Live Cluster Backup - CopyTable)

copytable 유틸리티는 같은 클러스터의 한 테이블에서 다른 테이블로 데이터를 복사하거나, 다른 클러스터의 다른 테이블로 데이터를 복사하는 데 사용할 수 있어요.

클러스터가 켜져 있으므로 복사 과정에서 편집이 놓칠 위험이 있어요.

라이브 클러스터 백업 - Export (Live Cluster Backup - Export)

export 접근은 테이블의 내용을 같은 클러스터의 HDFS로 덤프해요. 데이터를 복원하려면 import 유틸리티를 사용해요.

클러스터가 켜져 있으므로 export 과정에서 편집이 놓칠 위험이 있어요. HBase 백업·복원에 대해 더 알고 싶다면 Backup and Restore 페이지를 참고하세요.

HBase 스냅샷 (HBase Snapshots)

HBase Snapshots는 성능 영향이 매우 적게 테이블의 복사본(내용과 메타데이터 모두)을 찍을 수 있게 해줘요. 스냅샷은 스냅샷이 찍힌 시점의 테이블을 구성한 HFile 목록과 테이블 메타데이터의 불변 컬렉션이에요. 스냅샷의 "clone"은 그 스냅샷에서 새 테이블을 만들고, 스냅샷의 "restore"는 테이블의 내용을 스냅샷이 생성된 시점의 상태로 되돌려요. "clone"과 "restore" 연산은 데이터 복사를 요구하지 않아요. 기본 HFile(HBase 테이블의 데이터를 포함한 파일)은 어느 작업으로도 수정되지 않으니까요. 마찬가지로 스냅샷을 다른 클러스터로 export하는 것은 로컬 클러스터의 RegionServer에 영향이 적어요.

0.94.6 이전 버전에서 테이블을 백업하거나 clone하는 유일한 방법은 CopyTable/ExportTable을 사용하거나, 테이블을 비활성화한 뒤 HDFS의 모든 hfile을 복사하는 것이었어요. 이 방법들의 단점은 region server 성능을 저하시키거나(Copy/Export Table) 테이블을 비활성화해야 한다는 것(즉 읽기·쓰기 불가)이며, 이는 보통 받아들일 수 없어요.

설정 (Configuration)

스냅샷 지원을 켜려면 hbase.snapshot.enabled 속성을 true로 설정하세요. (스냅샷은 0.95+에서 기본 활성화, 0.94.6+에서 기본 비활성화).

hbase.snapshot.enabled true

스냅샷 찍기 (Take a Snapshot)

테이블이 활성화되어 있든 비활성화되어 있든 스냅샷을 찍을 수 있어요. 스냅샷 연산은 데이터 복사를 수반하지 않아요.

$ ./bin/hbase shell hbase> snapshot 'myTable', 'myTableSnapshot-122112'

flush 없이 스냅샷 찍기 (Take a Snapshot Without Flushing)

기본 동작은 스냅샷을 찍기 전에 메모리의 데이터를 flush하는 것이에요. 즉 메모리의 데이터가 스냅샷에 포함된다는 뜻이에요. 대부분의 경우 이것이 바람직한 동작이에요. 그러나 설정이 메모리 데이터가 스냅샷에서 제외되는 것을 견딜 수 있다면, snapshot 명령의 SKIP_FLUSH 옵션을 사용해 스냅샷을 찍는 동안 flushing을 비활성화할 수 있어요.

hbase> snapshot 'mytable', 'snapshot123', {SKIP_FLUSH => true}

매우 동시적인 삽입이나 업데이트가 주어진 스냅샷에 포함될지 결정하거나 예측할 방법은 없어요. flush가 활성화되었든 비활성화되었든요. 스냅샷은 단지 특정 시간 창 동안 테이블의 표현일 뿐이에요. 스냅샷 연산이 각 Region Server에 도달하는 데 걸리는 시간은 리소스 부하와 하드웨어나 네트워크 속도 등을 포함한 요인에 따라 수 초에서 1분까지 달라질 수 있어요. 주어진 삽입이나 업데이트가 메모리에 있는지 flush되었는지 알 방법도 없어요.

TTL로 스냅샷 찍기 (Take a Snapshot With TTL)

스냅샷은 그것이 만들어진 테이블과 독립적인 수명 주기를 가져요. 테이블의 데이터가 TTL로 저장될 수 있지만, 그것을 포함하는 데이터 파일은 스냅샷에 의해 고정(frozen)돼요. 만료된 셀이 차지하는 공간은 컴팩션 같은 일반적인 테이블 하우스키핑으로 회수되지 않아요. 이는 예상되는 일이지만 규모가 커지면 불편할 수 있어요. 많은 스냅샷이 관리되고 다양한 테이블의 데이터가 TTL로 만료될 때, 스냅샷에 대한 선택적 TTL(및 선택적 기본 TTL) 개념이 유용할 수 있어요.

hbase> snapshot 'mytable', 'snapshot1234', {TTL => 86400}

위 명령은 TTL 86400초(24시간)인 스냅샷 snapshot1234를 만들어요. 따라서 스냅샷은 24시간 후에 정리되어야 해요.

기본 스냅샷 TTL: (Default Snapshot TTL:)

  • 설정 hbase.master.snapshot.ttl로 사용자 지정 기본 TTL
  • hbase.master.snapshot.ttl이 설정되지 않으면 FOREVER

스냅샷을 만들 때 TTL(초)을 명시적으로 지정하지 않으면 위 논리에 따라 TTL이 결정돼요. 설정을 변경하지 않으면 기본 동작은 모든 스냅샷이 (수동 삭제까지) 영원히 유지되는 것이에요. 다른 기본 TTL 동작이 필요하면 hbase.master.snapshot.ttl을 초 단위 기본 TTL로 설정할 수 있어요. 명시적 TTL 없이 만들어진 모든 스냅샷은 이 새 값을 가지게 돼요.

hbase.master.snapshot.ttl이 설정되면 명시적 {TTL ⇒ 0} 또는 {TTL ⇒ -1}을 가진 스냅샷도 이 값을 취해요. 이 경우 TTL < -1(예: {TTL ⇒ -2})을 사용해 FOREVER를 나타내야 해요.

간결히 요약하면,

  1. TTL 값이 < -1인 스냅샷은 서버 측 설정 변경과 무관하게 (사용자가 수동 삭제할 때까지) 영원히 유지돼요.
  2. TTL 값이 > 0인 스냅샷은 TTL 만료 직후 자동으로 삭제돼요.
  3. TTL을 지정하지 않고 만든 스냅샷은 항상 설정 hbase.master.snapshot.ttl이 나타내는 TTL 값을 가져요. 이 설정의 기본값은 0이며, 이는 (사용자가 수동 삭제할 때까지) 스냅샷을 영원히 유지한다는 뜻이에요.
  4. 클라이언트 측에서 TTL 값 0이나 -1은 명시적으로 제공해서는 안 돼요. TTL 없는 스냅샷과 동일하게 취급되고(위 3번과 같음) 따라서 설정 hbase.master.snapshot.ttl이 나타내는 값에 따른 TTL을 사용하게 되니까요.

커스텀 MAX_FILESIZE로 스냅샷 찍기 (Take a snapshot with custom MAX_FILESIZE)

선택적으로, 전역 hbase.hregion.max.filesize 설정 속성 대신 clone된 테이블이 사용할 커스텀 최대 파일 크기 설정으로 스냅샷을 만들 수 있어요. 이는 주로 다른 클러스터 간에 스냅샷을 export할 때 유용해요. 원래 스냅샷이 찍힌 HBase 클러스터의 hbase.hregion.max.filesize 값이 스냅샷을 export하는 대상 클러스터보다 훨씬 크다면, 대상 클러스터에서 스냅샷을 복원할 때 region split 폭풍이 발생할 수 있어요. snapshot 명령에 전달되는 속성에 MAX_FILESIZE를 지정하면 스냅샷 생성 시점에 정보가 있는 값을 테이블의 MAX_FILESIZE 디스크립터에 저장해요. 테이블이 이미 MAX_FILESIZE 디스크립터를 정의하고 있다면 이 속성은 무시되고 효과가 없어요.

snapshot 'table01', 'snap01', {MAX_FILESIZE => 21474836480}

실행 중인 클러스터에서 스냅샷 자동 정리 활성화/비활성화: (Enable/Disable Snapshot Auto Cleanup on running cluster:)

기본적으로 TTL 기반 스냅샷 자동 정리는 어떤 새 클러스터에서도 활성화돼요. 어떤 시점에 스냅샷 복원 활동이나 다른 이유로 스냅샷 정리를 중지해야 한다면 셸 명령으로 비활성화하는 것이 좋아요.

hbase> snapshot_cleanup_switch false

다음을 사용해 다시 활성화할 수 있어요.

hbase> snapshot_cleanup_switch true

switch false인 셸 명령은 TTL 기반 스냅샷 자동 정리 활동을 비활성화하고 이전 활동 상태를 반환해요(true: 이미 실행 중, false: 이미 비활성화).

위 명령의 샘플 출력:

Previous snapshot cleanup state : true Took 0.0069 seconds => "true"

다음을 사용해 클러스터에 스냅샷 자동 정리가 활성화되어 있는지 조회할 수 있어요.

hbase> snapshot_cleanup_enabled

명령은 true/false로 출력을 반환해요.

스냅샷 나열 (Listing Snapshots)

찍은 모든 스냅샷을 (이름과 관련 정보를 출력해) 나열하세요.

$ ./bin/hbase shell hbase> list_snapshots

스냅샷 삭제 (Deleting Snapshots)

스냅샷을 제거할 수 있고, 그 스냅샷을 위해 유지되던 파일은 더 이상 필요하지 않으면 제거돼요.

$ ./bin/hbase shell hbase> delete_snapshot 'myTableSnapshot-122112'

스냅샷에서 테이블 clone (Clone a table from snapshot)

스냅샷에서 스냅샷이 찍힌 시점에 가졌던 것과 같은 데이터로 새 테이블(clone 연산)을 만들 수 있어요. clone 연산은 데이터 복사를 수반하지 않으며, clone된 테이블의 변경은 스냅샷이나 원래 테이블에 영향을 주지 않아요.

$ ./bin/hbase shell hbase> clone_snapshot 'myTableSnapshot-122112', 'myNewTestTable'

스냅샷 복원 (Restore a snapshot)

restore 연산은 테이블이 비활성화되어 있어야 하며, 테이블은 스냅샷이 찍힌 시점의 상태로 복원돼요. 필요하면 데이터와 스키마 모두 변경돼요.

$ ./bin/hbase shell hbase> disable 'myTable' hbase> restore_snapshot 'myTableSnapshot-122112'

Replication은 로그 수준에서, snapshots은 파일시스템 수준에서 동작하므로 복원 후 복제본은 master와 다른 상태가 돼요. restore를 사용하려면 replication을 중지하고 bootstrap을 다시 해야 해요.

잘못 동작하는 클라이언트로 인한 부분 데이터 손실의 경우, 테이블 비활성화가 필요한 전체 복원 대신 스냅샷에서 테이블을 clone하고 Map-Reduce 작업으로 필요한 데이터를 clone에서 메인 테이블로 복사할 수 있어요.

스냅샷 연산과 ACL (Snapshots operations and ACLs)

AccessController Coprocessor를 사용한 보안을 사용한다면(hbase.accesscontrol.configuration 참고), 전역 관리자만 스냅샷을 찍거나 clone·restore할 수 있고, 이러한 동작은 ACL 권한을 캡처하지 않아요. 이는 테이블을 restore하면 기존 테이블의 ACL 권한이 보존되지만, 테이블을 clone하면 관리자가 ACL을 추가할 때까지 ACL 권한이 없는 새 테이블을 만든다는 뜻이에요.

다른 클러스터로 export (Export to another cluster)

ExportSnapshot 도구는 스냅샷과 관련된 모든 데이터(hfiles, logs, snapshot metadata)를 다른 클러스터로 복사해요. 이 도구는 distcp와 유사한 Map-Reduce 작업을 실행해 두 클러스터 사이에 파일을 복사하며, 파일시스템 수준에서 동작하므로 hbase 클러스터가 온라인일 필요가 없어요.

MySnapshot이라는 스냅샷을 16개 mapper로 HBase 클러스터 srv2(hdfs:///srv2:8082/hbase)에 복사하려면:

$ bin/hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot -snapshot MySnapshot -copy-to hdfs://srv2:8082/hbase -mappers 16

대역폭 소비 제한 (Limiting Bandwidth Consumption)

-bandwidth 매개변수를 지정해(초당 메가바이트를 나타내는 정수) 스냅샷 export 시 대역폭 소비를 제한할 수 있어요. 다음 예제는 위 예제를 200 MB/sec로 제한해요.

$ bin/hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot -snapshot MySnapshot -copy-to hdfs://srv2:8082/hbase -mappers 16 -bandwidth 200

Amazon S3 버킷에 스냅샷 저장 (Storing Snapshots in an Amazon S3 Bucket)

다음 절차를 사용해 Amazon S3에서 스냅샷을 저장하고 검색할 수 있어요.

또한 Microsoft Azure Blob Storage에도 스냅샷을 저장할 수 있어요. Storing Snapshots in Microsoft Azure Blob Storage를 참고하세요.

전제 조건 (Prerequisites)

  • Amazon AWS SDK를 사용하는 첫 번째 구성인 HBase 1.0 이상과 Hadoop 2.6.1 이상을 사용해야 해요.
  • Amazon S3에 연결하려면 s3a:// 프로토콜을 사용해야 해요. 더 오래된 s3n://와 s3:// 프로토콜은 다양한 제한이 있고 Amazon AWS SDK를 사용하지 않아요.
  • s3a:// URI는 스냅샷을 export·restore하는 명령을 실행하는 서버에서 구성되고 사용 가능해야 해요.

전제 조건을 충족했다면 평소처럼 스냅샷을 찍으세요. 그 후 필요에 따라 copy-from이나 copy-to 지시문에 자신의 s3a:// 경로를 대입하고 다른 옵션을 대체·수정해 다음과 같은 org.apache.hadoop.hbase.snapshot.ExportSnapshot 명령으로 export할 수 있어요.

$ hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot
-snapshot MySnapshot
-copy-from hdfs://srv2:8082/hbase
-copy-to s3a:////hbase
-chuser MyUser
-chgroup MyGroup
-chmod 700
-mappers 16

$ hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot
-snapshot MySnapshot -copy-from s3a:////hbase
-copy-to hdfs://srv2:8082/hbase
-chuser MyUser
-chgroup MyGroup
-chmod 700
-mappers 16

또한 -remote-dir 옵션을 포함해 s3a:// 경로로 org.apache.hadoop.hbase.snapshot.SnapshotInfo 유틸리티를 사용할 수 있어요.

$ hbase org.apache.hadoop.hbase.snapshot.SnapshotInfo
-remote-dir s3a:////hbase
-list-snapshots

Microsoft Azure Blob Storage에 스냅샷 저장 (Storing Snapshots in Microsoft Azure Blob Storage)

Storing Snapshots in an Amazon S3 Bucket과 같은 기법으로 Microsoft Azure Blob Storage에 스냅샷을 저장할 수 있어요.

전제 조건 (Prerequisites)

전제 조건을 충족한 뒤 Storing Snapshots in an Amazon S3 Bucket의 지침을 따르되 프로토콜 지정자를 wasb:// 또는 wasbs://로 바꾸세요.

Aliyun Object Storage Service에 스냅샷 저장 (Storing Snapshots in Aliyun Object Storage Service)

Storing Snapshots in an Amazon S3 Bucket과 같은 기법으로 Aliyun Object Storage Service(Aliyun OSS)에 스냅샷을 저장할 수 있어요.

전제 조건 (Prerequisites)

전제 조건을 충족한 뒤 Storing Snapshots in an Amazon S3 Bucket의 지침을 따르되 프로토콜 지정자를 oss://로 바꾸세요.

더 알아보기 (Learn more)