이 섹션에서는 ClickHouse의 백업과 복원을 전반적으로 설명합니다. 각 백업 방식에 대한 더 자세한 내용은 사이드바의 해당 방식별 페이지를 참조하십시오.
소개
복제는 하드웨어 장애로부터는 보호해 주지만, 사람의 실수까지 막아주지는 못합니다. 예를 들어 데이터를 실수로 삭제하거나, 잘못된 테이블 또는 잘못된 클러스터의 테이블을 삭제하거나, 잘못된 데이터 처리나 데이터 손상을 초래하는 소프트웨어 버그가 발생할 수 있습니다. 이러한 실수는 많은 경우 모든 레플리카에 영향을 미칩니다. ClickHouse에는 일부 유형의 실수를 방지하기 위한 내장 보호 장치가 있습니다. 예를 들어 기본값으로 50 Gb를 초과하는 데이터를 포함하는MergeTree 계열 엔진의 테이블은
바로 삭제할 수 없습니다. 하지만 이러한 보호 장치가 모든 경우를 포괄하는 것은 아니며,
문제는 여전히 발생할 수 있습니다.
발생 가능한 사람의 실수를 효과적으로 완화하려면, 데이터 백업 및 복원
전략을 미리 신중하게 준비해야 합니다.
회사마다 사용할 수 있는 리소스와 비즈니스 요구사항이 다르므로,
모든 상황에 맞는 ClickHouse 백업 및 복원용 범용 해법은 없습니다.
1기가바이트의 데이터에 적합한 방식이 수십 페타바이트의 데이터에는 맞지 않을 가능성이 큽니다.
적용 가능한 접근 방식은 다양하며 각각 장단점이 있고, 이 문서 섹션에서
이를 소개합니다. 각 방식의 단점을 보완하기 위해 하나의 방식만 사용하는 대신
여러 접근 방식을 함께 사용하는 것이 좋습니다.
무언가를 백업해 두고도 한 번도 복원을 시도해 보지 않았다면,
실제로 필요할 때 복원이 제대로 동작하지 않을 가능성이 높습니다(또는
적어도 비즈니스에서 감당할 수 있는 시간보다 더 오래 걸릴 수 있습니다). 따라서 어떤 백업
방식을 선택하든 복원 프로세스도 반드시 자동화하고, 여분의 ClickHouse 클러스터에서 정기적으로
연습하십시오.
백업은 다음과 같은 방식으로 수행할 수 있습니다:
- 전체 또는 증분
- 동기 또는 비동기
- 동시 또는 비동시
- 압축 또는 비압축
- 이름이 지정된 컬렉션 사용
- 비밀번호로 보호
- 시스템 테이블, log tables 또는 액세스 관리 테이블 백업
백업 유형
백업은 전체 백업 또는 증분 백업으로 수행할 수 있습니다. 전체 백업은 데이터 전체의 복사본이며, 증분 백업은 마지막 전체 백업 이후 변경된 데이터만 포함합니다. 전체 백업의 장점은 단순하고 다른 백업에 의존하지 않는 독립적인 방식이며, 복구 신뢰성이 높다는 점입니다. 하지만 완료하는 데 시간이 오래 걸릴 수 있고 많은 저장 공간을 차지할 수 있습니다. 반면 증분 백업은 시간과 공간 측면에서 더 효율적이지만, 데이터를 복원하려면 관련된 모든 백업이 모두 있어야 합니다. 요구 사항에 따라 다음과 같은 방식을 사용할 수 있습니다.- 전체 백업: 규모가 작은 데이터베이스나 중요한 데이터에 적합합니다.
- 증분 백업: 규모가 큰 데이터베이스이거나 백업을 자주, 비용 효율적으로 수행해야 하는 경우에 적합합니다.
- 둘 다: 예를 들어, 매주 전체 백업을 수행하고 매일 증분 백업을 수행합니다.
동기식 백업과 비동기식 백업
BACKUP 및 RESTORE 명령은 ASYNC로 지정할 수도 있습니다. 이 경우
백업 명령은 즉시 반환되고, 백업 프로세스는 백그라운드에서 실행됩니다.
명령에 ASYNC가 지정되지 않으면 백업 프로세스는 동기식으로 실행되며
백업이 완료될 때까지 명령 실행이 차단됩니다.
동시 백업과 비동시 백업
기본적으로 ClickHouse는 백업과 복원 작업의 동시 실행을 허용합니다. 즉, 여러 개의 백업 또는 복원 작업을 동시에 시작할 수 있습니다. 하지만 이러한 동작을 허용하지 않도록 제어하는 서버 수준 설정도 있습니다. 이 설정을 false로 지정하면, 클러스터에서는 한 번에 하나의 백업 또는 복원 작업만 실행할 수 있습니다. 이렇게 하면 리소스 경합이나 작업 간 잠재적 충돌을 방지하는 데 도움이 될 수 있습니다. 백업/복원의 동시 실행을 허용하지 않으려면, 각각 다음 설정을 사용할 수 있습니다:압축 백업과 비압축 백업
ClickHouse 백업은compression_method 및 compression_level 설정을 통해 압축을 지원합니다.
백업을 생성할 때 다음 항목을 지정할 수 있습니다:
이름이 지정된 컬렉션 사용하기
이름이 지정된 컬렉션을 사용하면 백업/복원 작업 전반에 걸쳐 재사용할 수 있는 key-value 쌍(S3 자격 증명, endpoint, 설정 등)을 저장할 수 있습니다. 다음과 같은 이점이 있습니다:- 관리자 권한이 없는 사용자가 자격 증명을 볼 수 없도록 할 수 있습니다
- 복잡한 구성을 중앙에서 저장해 명령을 단순화할 수 있습니다
- 여러 작업 간 일관성을 유지할 수 있습니다
- 쿼리 로그에 자격 증명이 노출되는 것을 방지할 수 있습니다
시스템, 로그 또는 액세스 관리 테이블 백업
시스템 테이블도 백업 및 복원 워크플로에 포함할 수 있지만, 포함할지 여부는 사용 사례에 따라 달라집니다._log 접미사가 있는 테이블(예:
query_log, part_log)처럼 이력 데이터를 저장하는 시스템 테이블은 다른 테이블과 마찬가지로
백업하고 복원할 수 있습니다.
예를 들어 query_log를 사용해
쿼리 성능을 추적하거나 문제를 디버깅하는 등, 사용 사례에서 이력 데이터 분석이 필요하다면 이러한
테이블을 백업 전략에 포함하는 것이 좋습니다. 반면 이러한 테이블의 이력 데이터가
필요하지 않다면 백업 저장 공간을 절약하기 위해 제외할 수 있습니다.
users, 역할, row_policies,
settings_profiles, 쿼터와 같이 액세스 관리와 관련된 시스템 테이블은 백업 및 복원 작업 중
특별히 처리됩니다.
이러한 테이블이 백업에 포함되면, 해당 내용은 특수한
accessXX.txt 파일로 내보내지며, 이 파일에는 해당 액세스 엔터티를 생성하고
구성하는 데 필요한 SQL 문이 담깁니다. 복원 시에는 복원 프로세스가
이 파일을 해석하고 SQL 명령을 다시 적용하여 users,
역할 및 기타 구성을 다시 생성합니다. 이 기능을 통해 ClickHouse 클러스터의 액세스 제어
구성을 클러스터 전체 구성의 일부로
백업하고 복원할 수 있습니다.
이 기능은 SQL 명령으로 관리되는 구성에 대해서만 작동합니다
(“SQL 기반 액세스 제어 및 계정 관리”라고 부름).
ClickHouse 서버 설정 파일(예: users.xml)에 정의된 액세스 구성은
백업에 포함되지 않으며 이 방법으로는 복원할 수 없습니다.
일반 구문
명령 요약
위의 각 명령은 아래에서 자세히 설명합니다.데이터 없이 테이블 백업하기
EXCEPT DATA FROM {TABLE|TABLES}는 테이블의 행을 제외하고 정의만 백업에 포함합니다. 복원 후
데이터를 다시 생성할 수 있는 테이블, 예를 들어 materialized view의 대상 테이블에
유용합니다.
이 절은 BACKUP이 백업에 기록할 내용을 결정할 뿐, 백업 결과에 대해 RESTORE가 수행할 수 있는 작업에는 영향을 주지 않습니다.
RESTORE가 재생성할 수 있는 테이블이라면 행 없이 정의만 백업해도 빈 테이블로 복원됩니다. 하지만 이 절을 사용한다고 해서
원래 복원할 수 없는 테이블까지 복원할 수 있게 되는 것은 아닙니다. 백업에 포함된 정의로 테이블을 재생성할 수 있는지는
엔진에 따라 다르며, 일부 엔진은 이를 전혀 허용하지 않습니다.
RESTORE가 재생성할 수 없는 엔진을 참조하세요.
이 절은 지정한 원소에만 적용됩니다.
DATABASE또는ALL원소에 지정하면 해당 원소가 백업하는 테이블 중 어느 것이든 선택할 수 있습니다:
table, dictionary, view, database 또는 all인 테이블이나 데이터베이스는 백쿼트로 감싸야 합니다. 쉼표
뒤에 따옴표 없이 쓰면 다음 원소의 시작으로 해석됩니다.
- 단일 객체 원소(
TABLE,DICTIONARY,VIEW,TEMPORARY TABLE)에서는 해당 원소의 객체만 참조할 수 있으므로, 절에는 해당 객체만 지정해야 합니다. 테이블마다 별도의 원소와 절을 지정하세요:
EXCEPT DATA FROM 절이 같은 테이블을 가리키면
해당 테이블의 데이터는 백업됩니다. 테이블을 지정하면 그 데이터도 백업 대상에 포함되기 때문입니다. 이는 더 넓은 범위의 원소에서
테이블을 제외하더라도 명시적으로 지정한 테이블은 백업되는 EXCEPT TABLES의 동작과 같습니다.
materialized view의 내부 테이블(또는 TimeSeries 테이블의 내부 테이블)의 데이터는
외부 객체의 이름을 지정해 제외합니다. 이 절에는 내부 테이블의 이름을 지정할 수 없습니다.
EXCEPT DATA FROM {TABLE|TABLES}는 BACKUP에서만 유효합니다. RESTORE에서는 이를
아무 효과가 없는 옵션으로 처리하지 않고 거부합니다.
RESTORE로 재생성할 수 없는 엔진
일부 엔진은 EXCEPT DATA FROM {TABLE|TABLES} 사용 여부와 관계없이 RESTORE로 재생성할 수 없습니다. 해당
테이블에서도 이 절을 사용하면 백업 크기는 줄일 수 있지만, 복원 시 빈 테이블이 생성되지는 않습니다.
RESTORE가 테이블 생성을 거부하므로 테이블 자체가 복원되지 않습니다.
특히 독립적인 MaterializedPostgreSQL 테이블에 유의해야 합니다. 이 테이블은 생성되자마자
실시간 PostgreSQL 원본에서 복제를 시작하므로 백업 스냅샷의 데이터와 현재 원격 데이터가 뒤섞일 수 있습니다.
따라서 RESTORE는 테이블 생성 전에 저장소 팩토리에서 NOT_IMPLEMENTED 오류를 반환합니다. 이는
엔진 자체의 특성으로, 일반적인 전체 백업에도 동일하게 적용됩니다.
지원되는 방법은 중첩 테이블의 구조에 맞춰 _sign 및 _version 컬럼을 포함한 ReplacingMergeTree 테이블을
미리 생성한 다음, 다른 이름으로 복원하는 것입니다:
MaterializedPostgreSQL 엔진을 사용하지만, 이를 의도적으로 일반 ReplacingMergeTree 테이블로 복원하므로
allow_different_table_def가 필요합니다.
EXCEPT DATA FROM TABLE을 지정하지 않으면 동일한 RESTORE 작업으로 행도 함께 복원됩니다.
설정
일반 백업/복원 설정
S3 관련 설정
Azure 관련 설정
관리 및 문제 해결
백업 명령은id와 status를 반환하며, 이 id를 사용해
백업의 상태를 확인할 수 있습니다. 이는 시간이 오래 걸리는
ASYNC 백업의 진행 상황을 확인할 때 매우 유용합니다. 아래 예시는
기존 백업 파일을 덮어쓰려고 할 때 발생한 오류를 보여줍니다:
system.backups 테이블과 마찬가지로, 모든 백업 및 복원 작업은 시스템 로그 테이블
system.backup_log에도 기록됩니다: