SYSTEM

모든 내부 딕셔너리를 다시 불러옵니다. 기본적으로 내부 딕셔너리는 비활성화되어 있습니다. 내부 딕셔너리 업데이트 결과와 무관하게 항상 Ok.를 반환합니다.

SYSTEM RELOAD DICTIONARIES 쿼리는 상태가 LOADED인 딕셔너리, 즉 이전에 성공적으로 로드된 딕셔너리를 다시 로드합니다(system.dictionaries의 status 컬럼 참조). 기본적으로 딕셔너리는 지연 로드됩니다(dictionaries_lazy_load 참조). 따라서 시작 시 자동으로 로드되지 않으며, dictGet 함수를 사용하거나 ENGINE = Dictionary인 테이블에서 SELECT를 실행해 처음 접근할 때 초기화됩니다.

구문

SYSTEM RELOAD DICTIONARIES [ON CLUSTER cluster_name]

딕셔너리의 상태(LOADED / NOT_LOADED / FAILED)와 관계없이 딕셔너리 dictionary_name을 완전히 다시 로드합니다. 딕셔너리 업데이트 결과와 무관하게 항상 Ok.를 반환합니다.

SYSTEM RELOAD DICTIONARY [ON CLUSTER cluster_name] dictionary_name

system.dictionaries 테이블(table)을 쿼리하여 딕셔너리 상태를 확인할 수 있습니다.

SELECT name, status FROM system.dictionaries;

딕셔너리 상태가 LOADED인 경우, 메모리를 해제하기 위해 딕셔너리 dictionary_name의 로드를 해제합니다. 필요한 경우 딕셔너리는 다시 지연 로드됩니다.

SYSTEM UNLOAD DICTIONARY dictionary_name

딕셔너리 상태는 system.dictionaries 테이블을 조회하여 확인할 수 있습니다.

SELECT name, status FROM system.dictionaries;

SYSTEM UNLOAD DICTIONARIES 쿼리는 LOADED status를 가진 모든 딕셔너리, 즉 이전에 성공적으로 로드된 딕셔너리의 로드를 해제합니다(system.dictionaries의 status 컬럼 참고).

SYSTEM UNLOAD DICTIONARIES

모든 CatBoost 모델을 제거합니다.

구문

SYSTEM RELOAD MODELS [ON CLUSTER cluster_name]

model_path에 있는 CatBoost 모델의 로드를 해제합니다.

구문

SYSTEM RELOAD MODEL [ON CLUSTER cluster_name] <model_path>

설정 파일에서 등록된 모든 실행형 사용자 정의 함수 또는 특정 함수를 다시 로드합니다.

구문

SYSTEM RELOAD FUNCTIONS [ON CLUSTER cluster_name]
SYSTEM RELOAD FUNCTION [ON CLUSTER cluster_name] function_name

모든 비동기 메트릭을 다시 계산합니다. 비동기 메트릭은 설정 asynchronous_metrics_update_period_s에 따라 주기적으로 갱신되므로, 일반적으로는 이 구문을 사용해 수동으로 갱신할 필요가 없습니다.

SYSTEM RELOAD ASYNCHRONOUS METRICS [ON CLUSTER cluster_name]

ClickHouse의 내부 DNS 캐시를 비웁니다. 경우에 따라(이전 ClickHouse 버전에서는) 인프라가 변경될 때(다른 ClickHouse 서버의 IP 주소를 변경하거나 Dictionaries 기능에서 사용하는 서버를 변경할 때) 이 명령을 사용해야 합니다.

캐시를 더 편리하게(자동으로) 관리하려면 disable_internal_dns_cache, dns_cache_max_entries, dns_cache_update_period 매개변수를 참조하십시오.

마크 캐시를 비웁니다.

메모리에 MergeTree 테이블의 프라이머리 키를 보관하는 프라이머리 인덱스 캐시를 비웁니다. 크기는 서버 수준 설정인 primary_index_cache_size로 지정합니다.

Iceberg 메타데이터 캐시를 삭제합니다.

AvroConfluent 포맷에서 사용하는 URL별 Confluent 스키마 레지스트리 캐시를 지웁니다. 이렇게 하면 스키마 가져오기(fetch) 캐시(id → schema)와 스키마 등록 캐시(subject + schema → id)가 모두 삭제되므로, 이후 읽기 및 쓰기는 레지스트리 서버를 다시 사용합니다. 레지스트리 측에서 스키마가 삭제되었거나 다시 작성된 경우에 유용하며, 테스트에서 레지스트리의 멱등성을 확인하는 데에도 사용할 수 있습니다.

Parquet 메타데이터 캐시를 비웁니다.

구문 분석된 Paimon 메타데이터 파일(manifest 목록 및 매니페스트)에 대한 인메모리 캐시를 지웁니다.

함수 pointInPolygon에서 사용하는 전처리된 상수 다각형의 캐시를 지웁니다. 구성된 크기 제한(point_in_polygon_cache_size server setting)은 변경되지 않으므로, 이후에도 캐시는 계속 새 항목을 저장합니다. 캐시를 비활성화하려면 대신 point_in_polygon_cache_size를 0으로 설정하십시오.

텍스트 인덱스의 토큰, 헤더 및 포스팅 캐시를 지웁니다.

이 캐시들 중 하나만 개별적으로 삭제하려면 다음을 실행할 수 있습니다.

• SYSTEM CLEAR TEXT INDEX TOKENS CACHE,
• SYSTEM CLEAR TEXT INDEX HEADER CACHE, 또는
• SYSTEM CLEAR TEXT INDEX POSTINGS CACHE

보조(데이터 스키핑) 인덱스용 마크 캐시를 비웁니다.

보조(데이터 스키핑) 인덱스의 비압축 블록 캐시를 지웁니다.

메모리 매핑 파일의 캐시를 지웁니다.

사용자 공간 페이지 캐시, 즉 기반 저장소에서 읽은 데이터를 저장하는 ClickHouse 자체의 인메모리 캐시를 비웁니다.

vector similarity index cache를 비웁니다.

아웃바운드 연결에 사용되는 HTTP 연결 풀 캐시를 지웁니다.

S3 클라이언트 캐시를 지웁니다.

테이블의 마크를 마크 캐시에 로드합니다. 보조 인덱스 마크도 인덱스 마크 캐시에 함께 로드합니다.

SYSTEM PREWARM MARK CACHE [ON CLUSTER cluster_name] [db.]table

MergeTree 테이블의 프라이머리 인덱스를 프라이머리 인덱스 캐시에 적재합니다.

SYSTEM PREWARM PRIMARY INDEX CACHE [ON CLUSTER cluster_name] [db.]table

지정한 디스크의 메타데이터 캐시를 지웁니다.

SYSTEM DROP DISK METADATA CACHE <disk_name>

ClickHouse의 파일 시스템 캐시에 대해 메모리에 있는 상태를 디스크에 실제로 존재하는 캐시 파일과 동기화하고, 캐시된 각 파일 세그먼트의 cache_name, path, 다운로드된 size를 반환합니다. 필요에 따라 캐시 이름을 지정하면 작업이 단일 캐시로 제한됩니다.

SYSTEM SYNC FILESYSTEM CACHE ['<cache_name>']

Distributed Cache를 삭제합니다. Distributed Cache 서버에 대한 캐시된 연결만 삭제하려면 CONNECTIONS를 사용하고, 단일 서버만 대상으로 하려면 서버 식별자를 지정하십시오.

SYSTEM DROP DISTRIBUTED CACHE [CONNECTIONS | 'server_id']

다음 구문을 사용하여 ReplicatedMergeTree 테이블의 죽은 레플리카를 삭제할 수 있습니다:

SYSTEM DROP REPLICA 'replica_name' FROM TABLE database.table;
SYSTEM DROP REPLICA 'replica_name' FROM DATABASE database;
SYSTEM DROP REPLICA 'replica_name';
SYSTEM DROP REPLICA 'replica_name' FROM ZKPATH '/path/to/table/in/zk';

쿼리는 ZooKeeper에서 ReplicatedMergeTree 레플리카 경로를 제거합니다. 이 기능은 레플리카가 더 이상 동작하지 않고, 해당 테이블이 이미 존재하지 않아 DROP TABLE로 ZooKeeper에서 메타데이터를 제거할 수 없을 때 유용합니다. 비활성 상태이거나 오래된 레플리카만 삭제할 수 있으며, 로컬 레플리카는 삭제할 수 없으므로 이 경우에는 DROP TABLE을 사용하십시오. DROP REPLICA는 어떤 테이블도 삭제하지 않으며, 디스크의 데이터나 메타데이터도 제거하지 않습니다.

첫 번째는 database.table 테이블의 'replica_name' 레플리카 메타데이터를 제거합니다. 두 번째는 데이터베이스의 모든 복제된 테이블에 대해 동일한 작업을 수행합니다. 세 번째는 로컬 서버의 모든 복제된 테이블에 대해 동일한 작업을 수행합니다. 네 번째는 테이블의 다른 모든 레플리카가 삭제된 경우, 더 이상 동작하지 않는 레플리카의 메타데이터를 제거할 때 유용합니다. 이 경우 테이블 경로를 명시적으로 지정해야 합니다. 이 경로는 테이블 생성 시 ReplicatedMergeTree 엔진의 첫 번째 인수로 전달한 경로와 동일해야 합니다.

Replicated 데이터베이스의 더 이상 동작하지 않는 레플리카는 다음 구문으로 삭제할 수 있습니다:

SYSTEM DROP DATABASE REPLICA 'replica_name' [FROM SHARD 'shard_name'] FROM DATABASE database;
SYSTEM DROP DATABASE REPLICA 'replica_name' [FROM SHARD 'shard_name'];
SYSTEM DROP DATABASE REPLICA 'replica_name' [FROM SHARD 'shard_name'] FROM ZKPATH '/path/to/table/in/zk';

SYSTEM DROP REPLICA와 유사하지만, DROP DATABASE를 실행할 데이터베이스가 없을 때 ZooKeeper에서 Replicated 데이터베이스의 레플리카 경로를 제거합니다. 다만 ReplicatedMergeTree 레플리카는 제거하지 않으므로(SYSTEM DROP REPLICA도 필요할 수 있음) 유의하십시오. 세그먼트 및 레플리카 이름은 데이터베이스를 생성할 때 Replicated 엔진 인수에 지정한 이름입니다. 또한 이러한 이름은 system.clusters의 database_shard_name 및 database_replica_name 컬럼에서 확인할 수 있습니다. FROM SHARD 절이 없으면 replica_name은 shard_name|replica_name 포맷의 전체 레플리카 이름이어야 합니다.

비압축 데이터 캐시를 지웁니다. 비압축 데이터 캐시는 쿼리/사용자/프로필 수준 설정인 use_uncompressed_cache로 활성화하거나 비활성화할 수 있습니다. 크기는 서버 수준 설정인 uncompressed_cache_size로 구성할 수 있습니다.

컴파일된 표현식 캐시를 비웁니다. 컴파일된 표현식 캐시는 쿼리/사용자/프로필 수준의 설정인 compile_expressions로 활성화하거나 비활성화할 수 있습니다.

쿼리 조건 캐시를 삭제합니다.

암호화 headers 캐시를 지웁니다. 이 캐시는 암호화된 파일 앞부분에서 읽은 암호화 headers를 저장하며, 실험적 use_reader_executor 읽기 경로에서 이를 다시 읽지 않도록 사용됩니다. 크기는 encryption_header_cache_size server setting으로 설정됩니다.

SYSTEM CLEAR QUERY CACHE;
SYSTEM CLEAR QUERY CACHE TAG '<tag>'

쿼리 캐시를 비웁니다. 태그를 지정하면 해당 태그가 있는 쿼리 캐시 엔트리만 삭제됩니다.

format_schema_path에서 로드된 스키마 캐시를 지웁니다.

지원되는 대상:

• Protobuf: 메모리에서 가져온 Protobuf 메시지 정의를 제거합니다.
• Files: format_schema_source가 query로 설정된 경우 format_schema_path에 로컬로 저장된 캐시된 스키마 파일을 삭제합니다. 참고: 대상을 지정하지 않으면 두 캐시가 모두 지워집니다.

SYSTEM CLEAR|DROP FORMAT SCHEMA CACHE [FOR Protobuf/Files]

버퍼링된 로그 메시지를 시스템 테이블(system tables)(예: system.query_log)에 플러시합니다. 대부분의 시스템 테이블은 기본 플러시 인터벌이 7.5초이므로, 주로 디버깅에 유용합니다. 메시지 큐가 비어 있더라도 시스템 테이블을 생성합니다.

SYSTEM FLUSH LOGS [ON CLUSTER cluster_name] [log_name|[database.table]] [, ...]

모두 플러시하고 싶지 않다면, 이름이나 대상 테이블(target table)을 지정해 개별 로그를 하나 이상 플러시할 수 있습니다:

SYSTEM FLUSH LOGS query_log, system.query_views_log;

ClickHouse 구성을 다시 로드합니다. 구성 정보가 ZooKeeper에 저장된 경우에 사용합니다. SYSTEM RELOAD CONFIG는 ZooKeeper에 저장된 USER 구성을 다시 로드하지 않으며, users.xml에 저장된 USER 구성만 다시 로드합니다. 모든 USER 구성을 다시 로드하려면 SYSTEM RELOAD USERS를 사용하십시오.

SYSTEM RELOAD CONFIG [ON CLUSTER cluster_name]

users.xml, 로컬 디스크 액세스 스토리지, 복제된(ZooKeeper의) 액세스 스토리지를 포함한 모든 액세스 스토리지를 다시 로드합니다.

SYSTEM RELOAD USERS [ON CLUSTER cluster_name]

일반적으로 ClickHouse를 정상 종료합니다(service clickhouse-server stop / kill {$pid_clickhouse-server}와 유사)

ClickHouse 프로세스를 강제 종료합니다(예: kill -9 {$ pid_clickhouse-server})

ENABLE_XRAY=1로 ClickHouse를 빌드한 경우 사용할 수 있는 LLVM의 XRay 기능을 통해 계측 지점을 관리합니다. 이를 통해 소스 코드를 수정하지 않고도 최소한의 오버헤드로 프로덕션 환경에서 디버깅과 프로파일링을 수행할 수 있습니다. 계측 지점을 추가하지 않은 경우 성능 저하는 무시할 수 있는 수준입니다. 이는 200개 이상의 명령어로 이루어진 함수의 프롤로그와 에필로그에 가까운 주소로 점프하는 추가 명령만 삽입되기 때문입니다.

새 계측 지점을 추가합니다. 계측된 함수는 system.instrumentation 시스템 테이블(system table)에서 확인할 수 있습니다. 동일한 함수에 핸들러를 둘 이상 추가할 수 있으며, 추가된 순서대로 실행됩니다. 계측할 함수는 system.symbols 시스템 테이블에서 가져올 수 있습니다.

함수에 추가할 수 있는 핸들러는 세 가지 종류가 있습니다:

구문

SYSTEM INSTRUMENT ADD FUNCTION HANDLER [ARGUMENTS]

여기서 FUNCTION은 QueryMetricLog::startQuery와 같은 함수 또는 함수 이름의 일부(부분 문자열)이며, handler는 다음 중 하나입니다

인수로 제공된 텍스트와 함수의 ENTRY 또는 EXIT 시점에 스택 트레이스를 출력합니다.

SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' LOG ENTRY 'this is a log printed at entry'
SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' LOG EXIT 'this is a log printed at exit'

ENTRY 또는 EXIT에서 지정된 초 수만큼 대기합니다:

SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' SLEEP ENTRY 0.5

또는 공백으로 구분된 최소값과 최대값을 지정해, 그 사이에서 균등 분포를 따르는 임의의 초 단위 값을 사용할 수 있습니다:

SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' SLEEP ENTRY 0 1

함수의 ENTRY와 EXIT 사이에 걸린 시간을 측정합니다. 프로파일링 결과는 system.trace_log에 저장되며 Chrome Event Trace Format으로 변환할 수 있습니다.

SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' PROFILE

다음을 사용하여 계측 지점 하나를 제거할 수 있습니다:

SYSTEM INSTRUMENT REMOVE ID

모두 ALL 키워드를 사용하여:

SYSTEM INSTRUMENT REMOVE ALL

서브쿼리에서 가져온 ID 집합:

SYSTEM INSTRUMENT REMOVE (SELECT id FROM system.instrumentation WHERE handler = 'log')

또는 지정한 function_name과 일치하는 모든 계측 지점:

SYSTEM INSTRUMENT REMOVE 'QueryMetricLog::startQuery'

계측 지점 정보는 system.instrumentation 시스템 테이블(system table)에서 조회할 수 있습니다.

ClickHouse에서는 분산 테이블을 관리할 수 있습니다. 사용자가 이러한 테이블에 데이터를 삽입하면 ClickHouse는 먼저 클러스터(cluster) 노드로 전송할 데이터 큐를 만든 다음, 이를 비동기적으로 전송합니다. STOP DISTRIBUTED SENDS, FLUSH DISTRIBUTED, START DISTRIBUTED SENDS 쿼리를 사용해 큐 처리를 관리할 수 있습니다. 또한 distributed_foreground_insert 설정을 사용하면 분산 데이터를 동기적으로 삽입할 수도 있습니다.

분산 테이블에 데이터를 삽입할 때 백그라운드에서 데이터를 분산 전송하는 기능을 비활성화합니다.

SYSTEM STOP DISTRIBUTED SENDS [db.]<distributed_table_name> [ON CLUSTER cluster_name]

ClickHouse가 데이터를 클러스터 노드로 동기식으로 전송하도록 강제합니다. 사용 불가능한 노드가 하나라도 있으면 ClickHouse는 예외를 발생시키고 쿼리 실행을 중단합니다. 모든 노드가 다시 온라인 상태가 되면 쿼리가 성공하므로, 성공할 때까지 쿼리를 재시도할 수 있습니다.

SETTINGS 절을 통해 일부 설정을 재정의할 수도 있습니다. 이는 max_concurrent_queries_for_all_users 또는 max_memory_usage와 같은 일시적인 제한을 우회하는 데 유용할 수 있습니다.

SYSTEM FLUSH DISTRIBUTED [db.]<distributed_table_name> [ON CLUSTER cluster_name] [SETTINGS ...]

분산 테이블에 데이터를 삽입할 때 백그라운드에서 데이터 분산 전송이 이루어지도록 활성화합니다.

SYSTEM START DISTRIBUTED SENDS [db.]<distributed_table_name> [ON CLUSTER cluster_name]

지정된 프로토콜과 포트의 소켓을 닫고, 해당 포트로 서버에 연결된 기존 연결을 정상적으로 종료합니다.

단, 해당 프로토콜 설정이 clickhouse-server 구성에 지정되어 있지 않으면 이 명령은 아무런 효과가 없습니다.

SYSTEM STOP LISTEN [ON CLUSTER cluster_name] [QUERIES ALL | QUERIES DEFAULT | QUERIES CUSTOM | TCP | TCP WITH PROXY | TCP SECURE | HTTP | HTTPS | MYSQL | GRPC | POSTGRESQL | PROMETHEUS | CUSTOM 'protocol']

• CUSTOM 'protocol' 수정자가 지정되면 서버 구성의 protocols 섹션에 정의된 해당 이름의 사용자 지정 프로토콜이 중지됩니다.
• QUERIES ALL [EXCEPT .. [,..]] 수정자가 지정되면 EXCEPT 절로 지정한 항목을 제외한 모든 프로토콜이 중지됩니다.
• QUERIES DEFAULT [EXCEPT .. [,..]] 수정자가 지정되면 EXCEPT 절로 지정한 항목을 제외한 모든 기본 프로토콜이 중지됩니다.
• QUERIES CUSTOM [EXCEPT .. [,..]] 수정자가 지정되면 EXCEPT 절로 지정한 항목을 제외한 모든 사용자 지정 프로토콜이 중지됩니다.

지정된 프로토콜에서 새 연결이 설정될 수 있도록 합니다.

하지만 지정된 포트와 프로토콜의 server가 SYSTEM STOP LISTEN 명령으로 중지되지 않았다면, 이 명령은 아무런 효과가 없습니다.

SYSTEM START LISTEN [ON CLUSTER cluster_name] [QUERIES ALL | QUERIES DEFAULT | QUERIES CUSTOM | TCP | TCP WITH PROXY | TCP SECURE | HTTP | HTTPS | MYSQL | GRPC | POSTGRESQL | PROMETHEUS | CUSTOM 'protocol']

ClickHouse는 MergeTree 테이블에서 실행되는 백그라운드 프로세스를 관리할 수 있습니다.

MergeTree 엔진 계열에 속한 테이블의 백그라운드 머지를 중지할 수 있습니다:

SYSTEM STOP MERGES [ON CLUSTER cluster_name] [ON VOLUME <volume_name> | [db.]merge_tree_family_table_name]

MergeTree 엔진 계열 테이블에서 백그라운드 머지를 시작할 수 있습니다:

SYSTEM START MERGES [ON CLUSTER cluster_name] [ON VOLUME <volume_name> | [db.]merge_tree_family_table_name]

MergeTree 엔진 계열 테이블에서 TTL 표현식에 따라 오래된 데이터를 삭제하는 백그라운드 작업을 중지할 수 있습니다. 테이블이 존재하지 않거나 MergeTree 엔진 테이블이 아니어도 Ok.를 반환합니다. 데이터베이스가 존재하지 않으면 오류를 반환합니다:

SYSTEM STOP TTL MERGES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]

MergeTree 엔진 계열 테이블에서 TTL 표현식에 따라 오래된 데이터를 백그라운드에서 삭제하는 작업을 시작할 수 있습니다. 테이블이 존재하지 않아도 Ok.를 반환합니다. 데이터베이스가 존재하지 않으면 오류를 반환합니다:

SYSTEM START TTL MERGES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]

MergeTree 엔진 계열 테이블에서 TO VOLUME 또는 TO DISK 절이 포함된 TTL 테이블 표현식에 따른 백그라운드 데이터 이동 작업을 중지할 수 있습니다: 테이블이 존재하지 않아도 Ok.를 반환합니다. 데이터베이스가 존재하지 않으면 오류를 반환합니다:

SYSTEM STOP MOVES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]

MergeTree 엔진 계열의 테이블에 대해 TO VOLUME 및 TO DISK 절이 포함된 TTL 테이블 표현식에 따라 백그라운드 데이터 이동 작업을 시작합니다: 테이블이 존재하지 않아도 Ok.를 반환합니다. 데이터베이스가 존재하지 않으면 오류를 반환합니다:

SYSTEM START MOVES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]

지정된 이름의 동결된 백업을 모든 디스크에서 삭제합니다. 개별 파트의 동결을 해제하는 방법은 ALTER TABLE table_name UNFREEZE WITH NAME 에서 자세히 확인하십시오.

SYSTEM UNFREEZE WITH NAME <backup_name>

테이블에서 비동기적으로 로딩되는 모든 데이터 파트(data part)(오래된 데이터 파트)가 로딩될 때까지 기다립니다.

SYSTEM WAIT LOADING PARTS [ON CLUSTER cluster_name] [db.]merge_tree_family_table_name

ClickHouse는 ReplicatedMergeTree 테이블의 복제 관련 백그라운드 프로세스를 관리할 수 있습니다.

ReplicatedMergeTree 계열의 테이블에서 삽입된 파트의 백그라운드 페치를 중지할 수 있습니다: 테이블 엔진과 무관하게, 테이블이나 데이터베이스가 존재하지 않아도 항상 Ok.를 반환합니다.

SYSTEM STOP FETCHES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]

ReplicatedMergeTree 계열 테이블의 삽입된 파트에 대한 백그라운드 페치를 시작할 수 있습니다. 테이블 엔진과 무관하게, 테이블이나 데이터베이스가 존재하지 않아도 항상 Ok.를 반환합니다.

SYSTEM START FETCHES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]

ReplicatedMergeTree 계열 테이블에서 새로 삽입된 파트를 클러스터의 다른 레플리카로 백그라운드에서 전송하는 작업을 중지할 수 있습니다:

SYSTEM STOP REPLICATED SENDS [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]

ReplicatedMergeTree 계열 테이블에서 새로 삽입된 파트를 클러스터 내 다른 레플리카로 보내는 백그라운드 작업을 시작할 수 있습니다:

SYSTEM START REPLICATED SENDS [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]

ReplicatedMergeTree 계열 테이블에서는 Zookeeper에 저장된 복제 큐의 백그라운드 fetch 작업을 중지할 수 있습니다. 가능한 백그라운드 작업 유형은 merges, fetches, mutation, 그리고 ON CLUSTER 절이 포함된 DDL SQL 문입니다:

SYSTEM STOP REPLICATION QUEUES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]

ReplicatedMergeTree 계열 테이블의 경우 Zookeeper에 저장된 복제 큐에서 백그라운드 fetch 작업을 시작할 수 있습니다. 가능한 백그라운드 작업 유형은 머지, fetch, mutation, ON CLUSTER 절이 포함된 DDL SQL 문입니다:

SYSTEM START REPLICATION QUEUES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]

ReplicatedMergeTree 테이블에서 복제 로그의 새 항목을 복제 큐로 가져오는 작업을 중지합니다.

SYSTEM STOP PULLING REPLICATION LOG [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]

SYSTEM STOP PULLING REPLICATION LOG을 해제합니다.

SYSTEM START PULLING REPLICATION LOG [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]

ReplicatedMergeTree 테이블이 클러스터의 다른 레플리카와 동기화될 때까지 기다리며, 대기 시간은 receive_timeout초를 넘지 않습니다.

SYSTEM SYNC REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name [IF EXISTS] [STRICT | LIGHTWEIGHT [FROM 'srcReplica1'[, 'srcReplica2'[, ...]]] | PULL]

이 구문을 실행하면 [db.]replicated_merge_tree_family_table_name은 공통 복제 로그에서 자체 복제 큐로 명령을 가져오고, 이어서 쿼리는 레플리카가 가져온 모든 명령을 처리할 때까지 대기합니다. 다음 수정자를 지원합니다:

• IF EXISTS를 함께 사용하면(25.6부터 사용 가능) 테이블이 존재하지 않더라도 쿼리에서 오류가 발생하지 않습니다. 이는 새 레플리카를 클러스터에 추가할 때 유용합니다. 이 경우 해당 레플리카는 이미 클러스터 구성에 포함되어 있지만, 아직 테이블을 생성하고 동기화하는 중일 수 있습니다.
• STRICT 수정자를 지정하면 쿼리는 복제 큐가 빌 때까지 대기합니다. 복제 큐에 새 항목이 계속 추가되면 STRICT 버전은 영원히 성공하지 못할 수 있습니다.
• LIGHTWEIGHT 수정자를 지정하면 쿼리는 GET_PART, ATTACH_PART, DROP_RANGE, REPLACE_RANGE, DROP_PART 항목만 처리될 때까지 대기합니다. 또한 LIGHTWEIGHT 수정자는 선택적 FROM 'srcReplicas' 절을 지원하며, 여기서 'srcReplicas'는 쉼표로 구분된 소스 레플리카 이름 목록입니다. 이 확장 기능을 사용하면 지정된 소스 레플리카에서 시작된 복제 작업에만 집중하여 더 정밀하게 동기화할 수 있습니다.
• PULL 수정자를 지정하면 쿼리는 ZooKeeper에서 새 복제 큐 항목을 가져오지만, 어떤 항목도 처리될 때까지 대기하지는 않습니다.

지정된 복제된 데이터베이스가 해당 데이터베이스의 DDL 큐에 있는 모든 스키마 변경 사항을 적용할 때까지 대기합니다.

구문

SYSTEM SYNC DATABASE REPLICA replicated_database_name;

ReplicatedMergeTree 테이블의 ZooKeeper 세션 상태를 다시 초기화할 수 있습니다. 현재 상태를 기준 정보인 ZooKeeper와 비교한 뒤, 필요하면 ZooKeeper 큐에 작업을 추가합니다. ZooKeeper 데이터를 기반으로 한 복제 큐 초기화는 ATTACH TABLE 문과 동일한 방식으로 수행됩니다. 이 과정에서 짧은 시간 동안 테이블을 사용할 수 없습니다.

SYSTEM RESTART REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name

데이터는 [있을 수도 있지만] Zookeeper 메타데이터가 손실된 경우 레플리카를 복원합니다.

읽기 전용 ReplicatedMergeTree 테이블에서만 작동합니다.

다음과 같은 경우 이 쿼리를 실행할 수 있습니다:

• ZooKeeper 루트 / 손실.
• 레플리카 경로 /replicas 손실.
• 개별 레플리카 경로 /replicas/replica_name/ 손실.

레플리카는 로컬에서 찾은 파트를 ATTACH하고, 해당 정보를 Zookeeper에 전송합니다. 메타데이터 손실 전에 레플리카에 있던 파트는 outdated 상태가 아닌 한 다른 레플리카에서 다시 가져오지 않습니다(즉, 레플리카 복원은 네트워크를 통해 모든 데이터를 다시 다운로드한다는 뜻이 아닙니다).

데이터가 [남아 있을 수 있지만] Zookeeper 메타데이터가 손실된 경우 레플리카를 복원합니다.

구문

SYSTEM RESTORE DATABASE REPLICA repl_db [ON CLUSTER cluster]

예시

CREATE DATABASE repl_db
ENGINE=Replicated("/clickhouse/repl_db", shard1, replica1);

CREATE TABLE repl_db.test_table (n UInt32)
ENGINE = ReplicatedMergeTree
ORDER BY n PARTITION BY n % 10;

-- zookeeper_delete_path("/clickhouse/repl_db", recursive=True) <- 루트 손실.

SYSTEM RESTORE DATABASE REPLICA repl_db;

구문

SYSTEM RESTORE REPLICA [db.]replicated_merge_tree_family_table_name [ON CLUSTER cluster_name]

대체 구문:

SYSTEM RESTORE REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name

예시

여러 서버에 테이블을 생성합니다. ZooKeeper에 저장된 레플리카 메타데이터가 손실되면 메타데이터가 없기 때문에 해당 테이블은 읽기 전용으로 ATTACH됩니다. 마지막 쿼리는 모든 레플리카에서 실행해야 합니다.

CREATE TABLE test(n UInt32)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/test/', '{replica}')
ORDER BY n PARTITION BY n % 10;

INSERT INTO test SELECT * FROM numbers(1000);

-- zookeeper_delete_path("/clickhouse/tables/test", recursive=True) <- 루트 손실.

SYSTEM RESTART REPLICA test;
SYSTEM RESTORE REPLICA test;

또 다른 방법:

SYSTEM RESTORE REPLICA test ON CLUSTER cluster;

모든 ReplicatedMergeTree 테이블의 Zookeeper 세션 상태를 다시 초기화할 수 있습니다. 현재 상태를 기준 정보인 Zookeeper와 비교한 뒤, 필요하면 Zookeeper 큐에 작업을 추가합니다.

파일 시스템 캐시를 비울 수 있습니다.

SYSTEM CLEAR FILESYSTEM CACHE [ON CLUSTER cluster_name]

sync 시스템 호출을 수행합니다.

SYSTEM SYNC FILE CACHE [ON CLUSTER cluster_name]

지정한 테이블(table) 또는 모든 테이블의 기본 키(primary key)를 로드합니다.

SYSTEM LOAD PRIMARY KEY [db.]name

SYSTEM LOAD PRIMARY KEY

지정한 테이블이나 모든 테이블의 기본 키를 언로드합니다.

SYSTEM UNLOAD PRIMARY KEY [db.]name

SYSTEM UNLOAD PRIMARY KEY

갱신 가능 구체화 뷰가 수행하는 백그라운드 작업을 제어하는 명령입니다.

사용하는 동안에는 system.view_refreshes를 주기적으로 확인하십시오.

지정한 뷰 또는 모든 갱신 가능한 뷰의 주기적 갱신을 중지합니다. 갱신이 진행 중인 경우 해당 작업도 취소합니다.

뷰가 Replicated 또는 Shared 데이터베이스에 있는 경우, STOP VIEW는 현재 레플리카에만 영향을 미치고, STOP REPLICATED VIEW는 모든 레플리카에 영향을 미칩니다.

SYSTEM STOP VIEW [db.]name

SYSTEM STOP VIEWS

지정한 뷰 또는 모든 갱신 가능한 뷰에 대해 주기적 갱신을 활성화합니다. 즉시 갱신되지는 않습니다.

뷰가 Replicated 또는 Shared 데이터베이스에 있는 경우, START VIEW는 STOP VIEW의 효과를 취소하고, START REPLICATED VIEW는 STOP REPLICATED VIEW의 효과를 취소합니다. START VIEW는 PAUSE VIEW의 효과도 취소합니다.

SYSTEM START VIEW [db.]name

SYSTEM START VIEWS

지정된 뷰 또는 모든 갱신 가능한 뷰의 주기적 갱신을 일시 중지합니다. SYSTEM STOP VIEW와 달리 SYSTEM PAUSE VIEW는 이미 진행 중인 갱신을 중단하지 않습니다. 현재 실행 중인 갱신은 끝까지 완료되며, 그 이후의 갱신만 중지됩니다.

SYSTEM START VIEW 또는 SYSTEM START VIEWS를 사용해 다시 시작할 수 있습니다.

SYSTEM PAUSE VIEW [db.]name

SYSTEM PAUSE VIEWS

주어진 뷰에 대해 예약되지 않은 즉시 갱신을 실행합니다.

SYSTEM REFRESH VIEW [db.]name

현재 실행 중인 갱신이 완료될 때까지 기다립니다. 실행 중인 갱신이 없으면 즉시 반환됩니다. 가장 최근 갱신 시도가 실패한 경우 오류를 보고합니다.

새 갱신 가능 구체화 뷰를 생성한 직후(EMPTY 키워드 없이) 초기 갱신이 완료될 때까지 기다리는 데 사용할 수 있습니다.

뷰가 Replicated 또는 Shared 데이터베이스에 있고 다른 레플리카에서 갱신이 실행 중인 경우, 해당 갱신이 완료될 때까지 기다립니다.

SYSTEM WAIT VIEW [db.]name

현재 레플리카에서 지정된 뷰의 갱신이 진행 중이면 이를 중단하고 취소합니다. 그렇지 않으면 아무 작업도 하지 않습니다.

SYSTEM CANCEL VIEW [db.]name

단일 테이블 또는 서버 내 모든 해당 테이블의 백그라운드 활동을 제어하는 엔진 독립적 명령입니다. 다음에 적용됩니다.

• 갱신 가능 구체화 뷰의 주기적 갱신
• 외부 소스에서 지속적으로 데이터를 소비하는 스트리밍 테이블 엔진: Kafka, RabbitMQ, NATS, S3Queue, AzureQueue

갱신 가능 구체화 뷰의 경우, 각 동사는 갱신 가능 구체화 뷰 관리에 있는 해당 SYSTEM ... VIEW 명령의 별칭입니다. 따라서 SYSTEM STOP [db.]name은 SYSTEM STOP VIEW [db.]name과 정확히 동일하게 동작하며, 다른 명령도 마찬가지입니다.

테이블별 형식과 와일드카드 형식은 백그라운드 활동이 없는 테이블을 처리하는 방식이 다릅니다. 테이블별 형식(SYSTEM STOP [db.]table)은 지정한 테이블이 스트리밍 엔진이나 갱신 가능 구체화 뷰가 아니면 오류를 발생시킵니다. 와일드카드 형식은 이러한 테이블을 조용히 건너뛰므로 언제든 안전하게 실행할 수 있습니다.

STOP과 CANCEL은 가능한 한 빨리 소비를 중단합니다. Kafka, RabbitMQ, NATS의 경우 소스 읽기는 중단하지만 이미 시작된 삽입은 중단하지 않습니다. 구체화 뷰에 기록 중인 블록은 끝까지 기록된 후 커밋됩니다. S3Queue와 AzureQueue는 단일 파이프라인에서 읽기와 삽입을 수행합니다. 중복 제거가 활성화된 경우(기본값)에는 삽입도 취소되고 파일은 나중에 다시 처리됩니다. 중복 제거가 비활성화된 경우에는 행 중복을 방지하기 위해 진행 중인 Batch가 대신 완료된 후 커밋됩니다(위 엔진과 동일). 읽었지만 아직 커밋되지 않은 데이터는 나중에 다시 소비되므로, 재전송할 수 없어 이를 삭제하는 JetStream 없는 core NATS를 제외하면 데이터는 손실되지 않습니다.

PAUSE는 실행 중인 삽입을 중단하지 않으므로 일반적으로 데이터가 손실되지 않습니다. core NATS는 예외입니다. 일시 중지하면 소비가 중단되고 이미 수신했지만 아직 삽입하지 않은 메시지는 삭제되며, core NATS는 이를 재전송할 수 없습니다.

백그라운드 활동을 중지하고 중지 상태를 유지합니다. 현재 실행 중인 작업을 중단하고, SYSTEM START를 실행할 때까지 추가 작업을 실행하지 않습니다. PAUSE + CANCEL과 동일합니다.

SYSTEM STOP [db.]table
SYSTEM STOP ALL BACKGROUND

이전에 실행한 SYSTEM STOP 또는 SYSTEM PAUSE를 되돌리고 작업을 재개합니다. 작업이 중단되지는 않습니다.

SYSTEM START [db.]table
SYSTEM START ALL BACKGROUND

추가 백그라운드 활동이 시작되지 않도록 하되, 현재 실행 중인 작업은 완료될 때까지 기다립니다.

SYSTEM PAUSE [db.]table
SYSTEM PAUSE ALL BACKGROUND

향후 활동에는 영향을 주지 않고 현재 실행 중인 활동만 중단합니다. 테이블은 일정에 따라 계속 갱신되거나 데이터를 소비합니다. 진행 중인 활동이 없으면 아무 작업도 수행하지 않습니다.

SYSTEM CANCEL [db.]table
SYSTEM CANCEL ALL BACKGROUND

일정에 따라 실행되는 사이클 외에 추가로 한 번 실행합니다. 스트리밍 테이블에서는 테이블이 중지되었거나 일시 중지된 상태에서도 즉시 한 번 실행됩니다. 갱신 가능 구체화 뷰에서는 SYSTEM REFRESH VIEW처럼 동작합니다. 뷰가 중지된 경우 갱신 요청이 저장되며, SYSTEM START로 중지가 해제되면 한 번 실행됩니다.

SYSTEM REFRESH [db.]table
SYSTEM REFRESH ALL BACKGROUND

각 명령을 실행하려면 대상 엔진에 해당하는 권한이 필요합니다. 갱신 가능 구체화 뷰에는 SYSTEM VIEWS 권한이, 스트리밍 테이블에는 SYSTEM STREAMING ENGINES 권한이 필요합니다. 두 권한은 모두 SYSTEM BACKGROUND의 하위 권한이므로, SYSTEM BACKGROUND를 부여하면 이러한 모든 테이블의 백그라운드 활동을 제어할 수 있습니다. ALL BACKGROUND 형식은 사용자가 제어할 수 있는 테이블에만 적용되며, 나머지 테이블은 조용히 건너뜁니다.

지정된 S3Queue 또는 AzureQueue 테이블이 지정된 파일을 처리하거나 해당 파일의 영구적 실패를 확정할 때까지 대기합니다. 파일이 이미 처리된 경우에는 즉시 반환됩니다. 파일이 영구적으로 실패한 경우(모든 재시도를 소진한 경우) 오류를 발생시킵니다.

SYSTEM FLUSH OBJECT STORAGE QUEUE [db.]table_name PATH 'path'