ClickHouse의 백업 및 복원
이 섹션에서는 ClickHouse의 백업 및 복원에 대해 전반적으로 설명합니다. 각 백업 방식에 대한 더 자세한 설명은 사이드바에 있는 해당 방식별 페이지를 참조하십시오.
소개
복제는 하드웨어 장애로부터는 보호하지만, 데이터를 실수로 삭제하거나, 잘못된 테이블 또는 잘못된 클러스터의 테이블을 삭제하는 경우, 그리고 잘못된 데이터 처리나 데이터 손상을 초래하는 소프트웨어 버그와 같은 인적 오류로부터는 보호하지 않습니다.
이러한 실수는 많은 경우 모든 레플리카에 영향을 미칩니다. ClickHouse에는 일부 유형의 실수를
방지하기 위한 안전장치가 내장되어 있으며, 예를 들어 기본값으로
50 GB를 초과하는 데이터를 포함하는 MergeTree 패밀리 엔진 테이블은
무작정 삭제할 수 없습니다. 그러나 이러한 안전장치가 모든 경우를 다
포함하는 것은 아니므로 여전히 문제가 발생할 수 있습니다.
잠재적인 인적 오류를 효과적으로 완화하려면, 데이터를 백업하고 복원하는 전략을 미리 신중하게 준비해야 합니다.
각 회사는 사용 가능한 리소스와 비즈니스 요구사항이 다르므로, 모든 상황에 맞는 범용적인 ClickHouse 백업 및 복원 솔루션은 존재하지 않습니다. 1 기가바이트의 데이터에 적합한 방식이 수십 페타바이트의 데이터에는 적합하지 않을 가능성이 큽니다. 각각 장단점을 가진 다양한 접근 방식이 있으며, 이 문서 섹션에서는 이러한 방법들을 설명합니다. 여러 접근 방식을 함께 사용하여 각 방법의 다양한 한계를 보완하는 것이 좋습니다.
무언가를 백업해 두었지만 실제로 복원을 시도해 본 적이 없다면, 실제로 복원이 필요할 때 제대로 동작하지 않을 가능성이 높습니다 (또는 최소한 비즈니스가 허용할 수 있는 시간보다 더 오래 걸릴 수 있습니다). 따라서 어떤 백업 방식을 선택하든, 복원 프로세스도 반드시 자동화하고 예비 ClickHouse 클러스터에서 정기적으로 연습해야 합니다.
다음 페이지들은 ClickHouse에서 사용할 수 있는 다양한 백업 및 복원 방법을 자세히 설명합니다:
| Page | Description |
|---|---|
| Backup/restore using local disk or S3 disk | 로컬 디스크 또는 S3 디스크로/에서 백업 및 복원하는 방법을 설명합니다 |
| Backup/restore using S3 endpoint | S3 엔드포인트로/에서 백업 및 복원하는 방법을 설명합니다 |
| Backup/restore using AzureBlobStorage | Azure Blob Storage로/에서 백업 및 복원하는 방법을 설명합니다 |
| Alternative methods | 대체 백업 방법을 설명합니다 |
백업은 다음과 같은 특성을 가질 수 있습니다:
- 전체 또는 증분 방식
- 동기식 또는 비동기식으로 수행
- 동시 또는 비동시로 수행
- 압축 또는 비압축 형태
- 명명된 컬렉션(named collections)을 사용
- 비밀번호로 보호
- system 테이블, 로그 테이블, 액세스 관리 테이블을 포함
백업 유형
백업은 전체 백업 또는 증분 백업으로 수행할 수 있습니다. 전체 백업은 데이터의 완전한 사본이며, 증분 백업은 마지막 전체 백업 이후 변경된 데이터의 변경분입니다.
전체 백업은 다른 백업에 의존하지 않는 단순하고 신뢰할 수 있는 복구 방법이라는 장점이 있습니다. 그러나 완료하는 데 오래 걸릴 수 있고 많은 저장 공간을 차지할 수 있습니다. 반면 증분 백업은 시간과 저장 공간 면에서 더 효율적이지만, 데이터를 복원하려면 모든 백업이 사용 가능해야 합니다.
요구 사항에 따라 다음과 같이 사용할 수 있습니다:
- 전체 백업: 규모가 작은 데이터베이스나 중요 데이터에 사용합니다.
- 증분 백업: 규모가 큰 데이터베이스이거나 백업을 자주, 그리고 비용 효율적으로 수행해야 할 때 사용합니다.
- 둘 다: 예를 들어, 주간 전체 백업과 일일 증분 백업을 함께 사용하는 방식입니다.
동기식 vs 비동기식 백업
BACKUP 및 RESTORE 명령은 ASYNC로도 지정할 수 있습니다. 이 경우
백업 명령은 즉시 반환되고, 백업 프로세스는 백그라운드에서 실행됩니다.
명령에 ASYNC가 지정되지 않은 경우 백업 프로세스는 동기식으로 동작하며,
백업이 완료될 때까지 명령이 블로킹됩니다.
동시 백업과 비동시 백업
기본적으로 ClickHouse는 백업과 복원을 동시에 실행하도록 허용합니다. 이는 여러 개의 백업 또는 복원 작업을 병렬로 시작할 수 있음을 의미합니다. 다만 이러한 동작을 허용하지 않도록 제어할 수 있는 서버 수준 설정이 있습니다. 이 설정을 false로 지정하면, 한 번에 하나의 백업 또는 복원 작업만 클러스터에서 실행되도록 제한됩니다. 이는 작업 간 리소스 경합이나 잠재적인 충돌을 방지하는 데 도움이 됩니다.
백업/복원의 동시 실행을 허용하지 않으려면, 각각 다음 설정을 사용할 수 있습니다:
두 설정의 기본값은 모두 true이므로 기본적으로 동시에 백업/복원 작업이 허용됩니다. 클러스터에서 이 설정이 false인 경우에는 한 번에 하나의 백업/복원 작업만 실행할 수 있습니다.
압축된 백업과 비압축 백업
ClickHouse 백업은 compression_method 및 compression_level 설정으로 압축을 지원합니다.
백업을 생성할 때 다음을 지정할 수 있습니다:
이름이 지정된 컬렉션 사용
이름이 지정된 컬렉션(named collections)을 사용하면 백업/복원 작업 전반에서 재사용할 수 있는 key-value 쌍(예: S3 자격 증명, 엔드포인트, 설정)을 저장할 수 있습니다. 이를 통해 다음을 수행할 수 있습니다:
- 관리자 권한이 없는 사용자로부터 자격 증명을 숨길 수 있습니다.
- 복잡한 구성을 중앙에 저장하여 명령을 단순화할 수 있습니다.
- 작업 전반에서 일관성을 유지할 수 있습니다.
- 쿼리 로그에서 자격 증명이 노출되는 것을 방지할 수 있습니다.
자세한 내용은 "named collections"을 참조하십시오.
시스템, 로그 또는 액세스 관리 테이블 백업
시스템 테이블도 백업 및 복원 워크플로우에 포함할 수 있지만, 포함 여부는 구체적인 사용 사례에 따라 달라집니다.
query_log, part_log와 같이 _log 접미사를 가진 테이블 등
이력 데이터를 저장하는 시스템 테이블은 다른 테이블과 동일하게
백업하고 복원할 수 있습니다. 사용 사례에서 이력 데이터 분석이 중요하다면
(예: query_log를 사용해 쿼리 성능을 추적하거나 문제를 디버깅하는 경우),
이러한 테이블을 백업 전략에 포함하는 것이 좋습니다. 반대로 이러한 테이블의
이력 데이터가 필요하지 않다면, 백업 스토리지 공간을 절약하기 위해
제외할 수 있습니다.
users, roles, row_policies, settings_profiles, quotas와 같이 액세스 관리와 관련된
시스템 테이블은 백업 및 복원 작업에서 별도의 방식으로 처리됩니다.
이 테이블들이 백업에 포함되면, 그 내용은 별도의 accessXX.txt 파일로
내보내지며, 이 파일에는 액세스 엔터티를 생성하고 설정하기 위한
동일한 SQL 문이 포함됩니다. 복원 시에는 이 파일들을
해석하여 SQL 명령을 다시 적용함으로써 사용자, 역할 및 기타 설정을
재생성합니다. 이 기능을 통해 ClickHouse 클러스터의 액세스 제어
구성을 클러스터 전체 설정의 일부로 백업하고 복원할 수 있습니다.
이 기능은 SQL 명령을 통해 관리되는 구성
(「SQL 기반 액세스 제어 및 계정 관리」로 언급됨)에만
적용됩니다. ClickHouse 서버 설정 파일(예: users.xml)에 정의된
액세스 구성은 백업에 포함되지 않으며 이 방법으로는 복원할 수 없습니다.
일반적인 구문
각 명령별 자세한 내용은 "command summary"를 참조하십시오.
명령어 요약
위의 각 명령어에 대한 자세한 설명은 아래와 같습니다.
| Command | Description |
|---|---|
BACKUP | 지정한 객체의 백업을 생성합니다 |
RESTORE | 백업에서 객체를 복원합니다 |
[ASYNC] | 작업을 비동기적으로 실행합니다 (즉시 ID를 반환하며, 해당 ID로 진행 상태를 모니터링할 수 있습니다) |
TABLE [db.]table_name [AS [db.]table_name_in_backup] | 특정 테이블을 백업/복원합니다 (이름을 변경할 수 있습니다) |
[PARTITION[S] partition_expr [,...]] | 테이블의 특정 파티션만 백업/복원합니다 |
DICTIONARY [db.]dictionary_name [AS [db.]name_in_backup] | 딕셔너리 객체를 백업/복원합니다 |
DATABASE database_name [AS database_name_in_backup] | 전체 데이터베이스를 백업/복원합니다 (이름을 변경할 수 있습니다) |
TEMPORARY TABLE table_name [AS table_name_in_backup] | 임시 테이블을 백업/복원합니다 (이름을 변경할 수 있습니다) |
VIEW view_name [AS view_name_in_backup] | VIEW를 백업/복원합니다 (이름을 변경할 수 있습니다) |
[EXCEPT TABLES ...] | 데이터베이스를 백업할 때 특정 테이블을 제외합니다 |
ALL | 모든 항목(전체 데이터베이스, 테이블 등)을 백업/복원합니다. ClickHouse 23.4 버전 이전에는 ALL이 RESTORE 명령어에만 적용되었습니다. |
[EXCEPT {TABLES|DATABASES}...] | ALL을 사용할 때 특정 테이블 또는 데이터베이스를 제외합니다 |
[ON CLUSTER 'cluster_name'] | ClickHouse 클러스터 전체에 걸쳐 백업/복원 작업을 실행합니다 |
TO|FROM | 방향 지정: 백업 대상에는 TO, 복원 소스에는 FROM을 사용합니다 |
File('<path>/<filename>') | 로컬 파일 시스템에 저장하거나 로컬 파일 시스템에서 복원합니다 |
Disk('<disk_name>', '<path>/') | 구성된 디스크에 저장하거나 해당 디스크에서 복원합니다 |
S3('<S3 endpoint>/<path>', '<Access key ID>', '<Secret access key>') | Amazon S3 또는 S3 호환 스토리지에 저장하거나 그로부터 복원합니다 |
[SETTINGS ...] | 설정 전체 목록은 아래 내용을 참조하십시오 |
설정
일반 백업/복원 설정
| 설정 | 설명 | 기본값 |
|---|---|---|
id | 백업 또는 복원 작업의 ID입니다. 지정하지 않으면 임의로 생성된 UUID가 사용됩니다. 동일한 ID를 가진 작업이 이미 실행 중인 경우 예외가 발생합니다. | |
compression_method | 백업에 사용할 압축 방법을 지정합니다. "컬럼 압축 코덱(column compression codecs)" 섹션을 참조하십시오. | |
compression_level | 백업에 사용할 압축 수준을 지정합니다. | |
password | 디스크에 있는 파일의 암호입니다. | |
base_backup | 증분 백업에 사용되는 베이스 백업의 대상 위치입니다. 예: Disk('backups', '1.zip') | |
use_same_password_for_base_backup | 기본(base) 백업 아카이브가 쿼리에서 지정한 암호를 상속할지 여부를 지정합니다. | |
structure_only | 활성화된 경우 실제 테이블 데이터는 제외하고 CREATE SQL 문만 백업하거나 복원합니다. | |
storage_policy | 복원 중인 테이블에 대한 스토리지 정책입니다. "데이터 저장에 여러 블록 장치를 사용하는 방법을 참조하십시오. RESTORE 명령에만 적용됩니다. 엔진이 MergeTree 계열인 테이블에만 적용됩니다. | |
allow_non_empty_tables | 비어 있지 않은 테이블에도 RESTORE TABLE이 데이터를 삽입할 수 있도록 허용합니다. 이렇게 하면 테이블의 기존 데이터와 백업에서 추출된 데이터가 섞이게 됩니다. 따라서 이 설정으로 인해 테이블에 데이터가 중복될 수 있으므로 주의해서 사용해야 합니다. | 0 |
backup_restore_keeper_max_retries | BACKUP 또는 RESTORE 작업 중간에 수행되는 [Zoo]Keeper 작업의 최대 재시도 횟수입니다. 일시적인 [Zoo]Keeper 장애로 인해 전체 작업이 실패하지 않도록 충분히 크게 설정하는 것이 좋습니다. | 1000 |
backup_restore_keeper_retry_initial_backoff_ms | 백업 또는 복원 중 [Zoo]Keeper 작업에 대한 초기 백오프 타임아웃(ms)입니다. | 100 |
backup_restore_keeper_retry_max_backoff_ms | 백업 또는 복원 중 [Zoo]Keeper 작업에 대한 최대 백오프 타임아웃(ms)입니다. | 5000 |
backup_restore_failure_after_host_disconnected_for_seconds | BACKUP ON CLUSTER 또는 RESTORE ON CLUSTER 작업 중 호스트가 지정된 시간 동안 ZooKeeper에서 자신의 일시적인 'alive' 노드를 다시 생성하지 않으면 전체 백업 또는 복구 작업이 실패한 것으로 처리됩니다. 이 값은 장애 발생 후 호스트가 ZooKeeper에 다시 연결하는 데 걸릴 수 있는 어떤 합리적인 시간보다도 크게 설정해야 합니다. 0으로 설정하면 제한이 없음을 의미합니다. | 3600 |
backup_restore_keeper_max_retries_while_initializing | BACKUP ON CLUSTER 또는 RESTORE ON CLUSTER 작업의 초기화 단계에서 [Zoo]Keeper 작업을 재시도할 수 있는 최대 횟수입니다. | 20 |
backup_restore_keeper_max_retries_while_handling_error | BACKUP ON CLUSTER 또는 RESTORE ON CLUSTER 작업에서 오류를 처리하는 과정에서 수행되는 [Zoo]Keeper 작업의 최대 재시도 횟수입니다. | 20 |
backup_restore_finish_timeout_after_error_sec | 현재 BACKUP ON CLUSTER 또는 RESTORE ON CLUSTER 작업에서 이니시에이터가 다른 호스트들이 'error' 노드에 반응하여 현재 작업을 중단할 때까지 대기해야 하는 최대 시간. | 180 |
backup_restore_keeper_value_max_size | 백업 중 [Zoo]Keeper 노드 하나에 저장될 수 있는 데이터의 최대 크기입니다. | 1048576 |
backup_restore_batch_size_for_keeper_multi | 백업 또는 복원 중 [Zoo]Keeper에 대한 multi 요청의 배치 최대 크기입니다. | 1000 |
backup_restore_batch_size_for_keeper_multiread | 백업 또는 복원 중 [Zoo]Keeper에 대한 multiread 요청의 배치 최대 크기입니다. | 10000 |
backup_restore_keeper_fault_injection_probability | 백업 또는 복원 중 Keeper 요청이 실패할 대략적인 확률을 지정합니다. 유효한 값의 범위는 [0.0f, 1.0f]입니다. | 0 |
backup_restore_keeper_fault_injection_seed | 0이면 무작위 시드, 그렇지 않으면 설정 값 | 0 |
backup_restore_s3_retry_attempts | Aws::Client::RetryStrategy에 대한 설정입니다. Aws::Client가 자체적으로 재시도를 수행하며, 0으로 설정하면 재시도를 수행하지 않습니다. 백업 및 복원에만 적용됩니다. | 1000 |
max_backup_bandwidth | 서버에서 특정 백업에 대해 허용되는 초당 최대 읽기 속도(바이트 단위)입니다. 0으로 설정하면 제한이 없습니다. | 0 |
max_backups_io_thread_pool_size | ClickHouse는 Backups IO Thread 풀의 스레드를 사용하여 S3 백업 IO 작업을 수행합니다. max_backups_io_thread_pool_size는 풀의 최대 스레드 수를 제한합니다. | 1000 |
max_backups_io_thread_pool_free_size | Backups IO Thread 풀에서 유휴 상태인 스레드 수가 max_backup_io_thread_pool_free_size 값을 초과하면 ClickHouse는 이러한 유휴 스레드가 점유하던 리소스를 해제하고 풀 크기를 줄입니다. 필요할 경우 스레드는 다시 생성됩니다. | 0 |
backups_io_thread_pool_queue_size | Backups IO 스레드 풀에서 스케줄할 수 있는 작업의 최대 개수입니다. 현재 S3 백업 로직을 고려할 때 이 큐는 무제한으로 두는 것이 좋습니다. 참고: 값이 0(기본값)이면 무제한을 의미합니다. | 0 |
backup_threads | BACKUP 요청을 처리하는 데 사용되는 최대 스레드 수입니다. | |
max_backup_bandwidth_for_server | 서버에서 모든 백업에 대해 허용되는 초당 최대 읽기 속도(바이트 단위)입니다. 0으로 설정하면 제한이 없습니다. | 0 |
shutdown_wait_backups_and_restores | true로 설정하면 ClickHouse는 종료하기 전에 실행 중인 모든 백업 및 복원 작업이 완료될 때까지 대기합니다. | 1 |
S3 관련 설정
| Setting | Description | Default value |
|---|---|---|
use_same_s3_credentials_for_base_backup | S3로 수행되는 기본 백업이 쿼리에서 사용하는 자격 증명을 그대로 사용할지 여부입니다. S3에서만 동작합니다. | |
s3_storage_class | S3 백업에 사용되는 스토리지 클래스입니다. 예: STANDARD |
Azure 관련 설정
| Setting | Description | Default value |
|---|---|---|
azure_attempt_to_create_container | Azure Blob Storage를 사용할 때 지정된 컨테이너가 없으면 해당 컨테이너를 생성하도록 시도할지 여부입니다. | true |
관리 및 문제 해결
백업 명령은 id와 status를 반환하며, 해당 id를 사용하여 백업 상태를
확인할 수 있습니다. 이는 긴 ASYNC 백업의 진행 상황을 확인할 때 매우
유용합니다. 아래 예시는 기존 백업 파일을 덮어쓰려고 시도하는 과정에서 발생한
실패 사례를 보여줍니다.
system.backups 테이블과 함께 모든 백업 및 복원 작업은 시스템 로그 테이블인 system.backup_log에서도 추적됩니다:
