SYSTEM RELOAD EMBEDDED DICTIONARIES
Ok.를 반환합니다.
SYSTEM RELOAD DICTIONARIES
SYSTEM RELOAD DICTIONARIES 쿼리는 상태가 LOADED인 딕셔너리, 즉 이전에 성공적으로 로드된 딕셔너리를 다시 로드합니다(system.dictionaries의 status 컬럼 참조).
기본적으로 딕셔너리는 지연 로드됩니다(dictionaries_lazy_load 참조). 따라서 시작 시 자동으로 로드되지 않으며, dictGet 함수를 사용하거나 ENGINE = Dictionary인 테이블에서 SELECT를 실행해 처음 접근할 때 초기화됩니다.
구문
SYSTEM RELOAD DICTIONARY
dictionary_name을 완전히 다시 로드합니다.
딕셔너리 업데이트 결과와 무관하게 항상 Ok.를 반환합니다.
system.dictionaries 테이블(table)을 쿼리하여 딕셔너리 상태를 확인할 수 있습니다.
SYSTEM RELOAD MODELS
이 statement와
SYSTEM RELOAD MODEL은 clickhouse-library-bridge에서 catboost 모델을 제거만 합니다. 함수 catboostEvaluate()
는 모델이 아직 로드되지 않은 경우 처음 접근할 때 해당 모델을 로드합니다.SYSTEM RELOAD MODEL
model_path에 있는 CatBoost 모델의 로드를 해제합니다.
구문
SYSTEM RELOAD FUNCTIONS
SYSTEM RELOAD ASYNCHRONOUS METRICS
SYSTEM CLEAR|DROP DNS CACHE
disable_internal_dns_cache, dns_cache_max_entries, dns_cache_update_period 매개변수를 참조하십시오.
SYSTEM CLEAR|DROP MARK CACHE
SYSTEM CLEAR|DROP ICEBERG METADATA CACHE
SYSTEM CLEAR|DROP AVRO SCHEMA CACHE
AvroConfluent 포맷에서 사용하는 URL별 Confluent 스키마 레지스트리 캐시를 지웁니다. 이렇게 하면 스키마 가져오기(fetch) 캐시(id → schema)와 스키마 등록 캐시(subject + schema → id)가 모두 삭제되므로, 이후 읽기 및 쓰기는 레지스트리 서버를 다시 사용합니다. 레지스트리 측에서 스키마가 삭제되었거나 다시 작성된 경우에 유용하며, 테스트에서 레지스트리의 멱등성을 확인하는 데에도 사용할 수 있습니다.
SYSTEM DROP PARQUET METADATA CACHE
SYSTEM CLEAR|DROP TEXT INDEX CACHES
SYSTEM CLEAR TEXT INDEX HEADER CACHE,SYSTEM CLEAR TEXT INDEX DICTIONARY CACHE, 또는SYSTEM CLEAR TEXT INDEX POSTINGS CACHE
SYSTEM DROP REPLICA
ReplicatedMergeTree 테이블의 죽은 레플리카를 삭제할 수 있습니다:
ReplicatedMergeTree 레플리카 경로를 제거합니다. 이 기능은 레플리카가 더 이상 동작하지 않고, 해당 테이블이 이미 존재하지 않아 DROP TABLE로 ZooKeeper에서 메타데이터를 제거할 수 없을 때 유용합니다. 비활성 상태이거나 오래된 레플리카만 삭제할 수 있으며, 로컬 레플리카는 삭제할 수 없으므로 이 경우에는 DROP TABLE을 사용하십시오. DROP REPLICA는 어떤 테이블도 삭제하지 않으며, 디스크의 데이터나 메타데이터도 제거하지 않습니다.
첫 번째는 database.table 테이블의 'replica_name' 레플리카 메타데이터를 제거합니다.
두 번째는 데이터베이스의 모든 복제된 테이블에 대해 동일한 작업을 수행합니다.
세 번째는 로컬 서버의 모든 복제된 테이블에 대해 동일한 작업을 수행합니다.
네 번째는 테이블의 다른 모든 레플리카가 삭제된 경우, 더 이상 동작하지 않는 레플리카의 메타데이터를 제거할 때 유용합니다. 이 경우 테이블 경로를 명시적으로 지정해야 합니다. 이 경로는 테이블 생성 시 ReplicatedMergeTree 엔진의 첫 번째 인수로 전달한 경로와 동일해야 합니다.
SYSTEM DROP DATABASE REPLICA
Replicated 데이터베이스의 더 이상 동작하지 않는 레플리카는 다음 구문으로 삭제할 수 있습니다:
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 포맷의 전체 레플리카 이름이어야 합니다.
SYSTEM CLEAR|DROP UNCOMPRESSED CACHE
use_uncompressed_cache로 활성화하거나 비활성화할 수 있습니다.
크기는 서버 수준 설정인 uncompressed_cache_size로 구성할 수 있습니다.
SYSTEM CLEAR|DROP COMPILED EXPRESSION CACHE
compile_expressions로 활성화하거나 비활성화할 수 있습니다.
SYSTEM CLEAR|DROP QUERY CONDITION CACHE
SYSTEM CLEAR|DROP QUERY CACHE
SYSTEM CLEAR|DROP FORMAT SCHEMA CACHE
format_schema_path에서 로드된 스키마 캐시를 지웁니다.
지원되는 대상:
- Protobuf: 메모리에서 가져온 Protobuf 메시지 정의를 제거합니다.
- Files:
format_schema_source가query로 설정된 경우format_schema_path에 로컬로 저장된 캐시된 스키마 파일을 삭제합니다. 참고: 대상을 지정하지 않으면 두 캐시가 모두 지워집니다.
SYSTEM FLUSH LOGS
SYSTEM RELOAD CONFIG
SYSTEM RELOAD CONFIG는 ZooKeeper에 저장된 USER 구성을 다시 로드하지 않으며, users.xml에 저장된 USER 구성만 다시 로드합니다. 모든 USER 구성을 다시 로드하려면 SYSTEM RELOAD USERS를 사용하십시오.
SYSTEM RELOAD USERS
시스템 종료
service clickhouse-server stop / kill {$pid_clickhouse-server}와 유사)
SYSTEM KILL
kill -9 {$ pid_clickhouse-server})
SYSTEM INSTRUMENT
ENABLE_XRAY=1로 ClickHouse를 빌드한 경우 사용할 수 있는 LLVM의 XRay 기능을 통해 계측 지점을 관리합니다.
이를 통해 소스 코드를 수정하지 않고도 최소한의 오버헤드로 프로덕션 환경에서 디버깅과 프로파일링을 수행할 수 있습니다.
계측 지점을 추가하지 않은 경우 성능 저하는 무시할 수 있는 수준입니다. 이는 200개 이상의 명령어로 이루어진 함수의 프롤로그와 에필로그에
가까운 주소로 점프하는 추가 명령만 삽입되기 때문입니다.
SYSTEM INSTRUMENT ADD
system.instrumentation 시스템 테이블(system table)에서 확인할 수 있습니다. 동일한 함수에 핸들러를 둘 이상 추가할 수 있으며, 추가된 순서대로 실행됩니다.
계측할 함수는 system.symbols 시스템 테이블에서 가져올 수 있습니다.
함수에 추가할 수 있는 핸들러는 세 가지 종류가 있습니다:
구문
FUNCTION은 QueryMetricLog::startQuery와 같은 함수 또는 함수 이름의 일부(부분 문자열)이며, handler는 다음 중 하나입니다
LOG
ENTRY 또는 EXIT 시점에 스택 트레이스를 출력합니다.
SLEEP
ENTRY 또는 EXIT에서 지정된 초 수만큼 대기합니다:
PROFILE
ENTRY와 EXIT 사이에 걸린 시간을 측정합니다.
프로파일링 결과는 system.trace_log에 저장되며
Chrome Event Trace Format으로 변환할 수 있습니다.
SYSTEM INSTRUMENT REMOVE
ALL 매개변수를 사용하여:
system.instrumentation 시스템 테이블(system table)에서 조회할 수 있습니다.
분산 테이블 관리
STOP DISTRIBUTED SENDS, FLUSH DISTRIBUTED, START DISTRIBUTED SENDS 쿼리를 사용해 큐 처리를 관리할 수 있습니다. 또한 distributed_foreground_insert 설정을 사용하면 분산 데이터를 동기적으로 삽입할 수도 있습니다.
SYSTEM STOP DISTRIBUTED SENDS
prefer_localhost_replica가 활성화되어 있으면(기본값) 데이터는 어쨌든 로컬 세그먼트에 삽입됩니다.SYSTEM FLUSH DISTRIBUTED
SETTINGS 절을 통해 일부 설정을 재정의할 수도 있습니다. 이는 max_concurrent_queries_for_all_users 또는 max_memory_usage와 같은 일시적인 제한을 우회하는 데 유용할 수 있습니다.
각 대기 중인 블록은 최초 INSERT 쿼리의 설정과 함께 디스크에 저장되므로, 경우에 따라 설정을 재정의해야 할 수 있습니다.
SYSTEM START DISTRIBUTED SENDS
SYSTEM STOP LISTEN
CUSTOM 'protocol'수정자가 지정되면 서버 구성의 protocols 섹션에 정의된 해당 이름의 사용자 지정 프로토콜이 중지됩니다.QUERIES ALL [EXCEPT .. [,..]]수정자가 지정되면EXCEPT절로 지정한 항목을 제외한 모든 프로토콜이 중지됩니다.QUERIES DEFAULT [EXCEPT .. [,..]]수정자가 지정되면EXCEPT절로 지정한 항목을 제외한 모든 기본 프로토콜이 중지됩니다.QUERIES CUSTOM [EXCEPT .. [,..]]수정자가 지정되면EXCEPT절로 지정한 항목을 제외한 모든 사용자 지정 프로토콜이 중지됩니다.
SYSTEM START LISTEN
MergeTree 테이블 관리
SYSTEM STOP MERGES
DETACH / ATTACH 테이블은 이전에 모든 MergeTree 테이블의 머지가 중지된 상태였더라도 해당 테이블의 백그라운드 머지를 시작합니다.SYSTEM START MERGES
SYSTEM STOP TTL MERGES
Ok.를 반환합니다. 데이터베이스가 존재하지 않으면 오류를 반환합니다:
SYSTEM START TTL MERGES
Ok.를 반환합니다. 데이터베이스가 존재하지 않으면 오류를 반환합니다:
SYSTEM STOP MOVES
Ok.를 반환합니다. 데이터베이스가 존재하지 않으면 오류를 반환합니다:
SYSTEM START MOVES
Ok.를 반환합니다. 데이터베이스가 존재하지 않으면 오류를 반환합니다:
SYSTEM SYSTEM UNFREEZE
SYSTEM WAIT LOADING PARTS
ReplicatedMergeTree 테이블 관리
SYSTEM STOP FETCHES
ReplicatedMergeTree 계열의 테이블에서 삽입된 파트의 백그라운드 페치를 중지할 수 있습니다:
테이블 엔진과 무관하게, 테이블이나 데이터베이스가 존재하지 않아도 항상 Ok.를 반환합니다.
SYSTEM START FETCHES
ReplicatedMergeTree 계열 테이블의 삽입된 파트에 대한 백그라운드 페치를 시작할 수 있습니다.
테이블 엔진과 무관하게, 테이블이나 데이터베이스가 존재하지 않아도 항상 Ok.를 반환합니다.
SYSTEM STOP REPLICATED SENDS
ReplicatedMergeTree 계열 테이블에서 새로 삽입된 파트를 클러스터의 다른 레플리카로 백그라운드에서 전송하는 작업을 중지할 수 있습니다:
SYSTEM START REPLICATED SENDS
ReplicatedMergeTree 계열 테이블에서 새로 삽입된 파트를 클러스터 내 다른 레플리카로 보내는 백그라운드 작업을 시작할 수 있습니다:
SYSTEM STOP REPLICATION QUEUES
ReplicatedMergeTree 계열 테이블에서는 Zookeeper에 저장된 복제 큐의 백그라운드 fetch 작업을 중지할 수 있습니다. 가능한 백그라운드 작업 유형은 merges, fetches, mutation, 그리고 ON CLUSTER 절이 포함된 DDL SQL 문입니다:
SYSTEM START REPLICATION QUEUES
ReplicatedMergeTree 계열 테이블의 경우 Zookeeper에 저장된 복제 큐에서 백그라운드 fetch 작업을 시작할 수 있습니다. 가능한 백그라운드 작업 유형은 머지, fetch, mutation, ON CLUSTER 절이 포함된 DDL SQL 문입니다:
SYSTEM STOP PULLING REPLICATION LOG
ReplicatedMergeTree 테이블에서 복제 로그의 새 항목을 복제 큐로 가져오는 작업을 중지합니다.
SYSTEM START PULLING REPLICATION LOG
SYSTEM STOP PULLING REPLICATION LOG을 해제합니다.
SYSTEM SYNC REPLICA
ReplicatedMergeTree 테이블이 클러스터의 다른 레플리카와 동기화될 때까지 기다리며, 대기 시간은 receive_timeout초를 넘지 않습니다.
[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에서 새 복제 큐 항목을 가져오지만, 어떤 항목도 처리될 때까지 대기하지는 않습니다.
SYNC DATABASE REPLICA
SYSTEM RESTART REPLICA
ReplicatedMergeTree 테이블의 ZooKeeper 세션 상태를 다시 초기화할 수 있습니다. 현재 상태를 기준 정보인 ZooKeeper와 비교한 뒤, 필요하면 ZooKeeper 큐에 작업을 추가합니다.
ZooKeeper 데이터를 기반으로 한 복제 큐 초기화는 ATTACH TABLE 문과 동일한 방식으로 수행됩니다. 이 과정에서 짧은 시간 동안 테이블을 사용할 수 없습니다.
SYSTEM RESTORE REPLICA
ReplicatedMergeTree 테이블에서만 작동합니다.
다음과 같은 경우 이 쿼리를 실행할 수 있습니다:
- ZooKeeper 루트
/손실. - 레플리카 경로
/replicas손실. - 개별 레플리카 경로
/replicas/replica_name/손실.
outdated 상태가 아닌 한 다른 레플리카에서 다시 가져오지 않습니다(즉, 레플리카 복원은 네트워크를 통해 모든 데이터를 다시 다운로드한다는 뜻이 아닙니다).
모든 상태의 파트는
detached/ 폴더로 이동됩니다. 데이터 손실 전에 활성 상태였던(커밋된) 파트는 ATTACH됩니다.SYSTEM RESTORE DATABASE REPLICA
SYSTEM RESTART REPLICAS
ReplicatedMergeTree 테이블의 Zookeeper 세션 상태를 다시 초기화할 수 있습니다. 현재 상태를 기준 정보인 Zookeeper와 비교한 뒤, 필요하면 Zookeeper 큐에 작업을 추가합니다.
SYSTEM CLEAR|DROP FILESYSTEM CACHE
SYSTEM SYNC FILE CACHE
부하가 너무 크고 오용될 소지가 있습니다.
SYSTEM LOAD PRIMARY KEY
SYSTEM UNLOAD PRIMARY KEY
갱신 가능 구체화 뷰 관리
system.view_refreshes를 주기적으로 확인하십시오.
SYSTEM STOP [REPLICATED] VIEW, STOP VIEWS
STOP VIEW는 현재 레플리카에만 영향을 미치고, STOP REPLICATED VIEW는 모든 레플리카에 영향을 미칩니다.
중지된 상태는 서버를 재시작해도 유지되지 않습니다. 재시작 후에는 뷰가 구성된 갱신 일정에 따라 다시 갱신됩니다.
Replicated 또는 Shared 데이터베이스에서
SYSTEM STOP VIEW는 현재 레플리카에만 영향을 미칩니다. 모든 레플리카의 갱신을 중지하려면 SYSTEM STOP REPLICATED VIEW를 사용하십시오.SYSTEM START [REPLICATED] VIEW, START VIEWS
START VIEW는 STOP VIEW의 효과를 취소하고, START REPLICATED VIEW는 STOP REPLICATED VIEW의 효과를 취소합니다. START VIEW는 PAUSE VIEW의 효과도 취소합니다.
SYSTEM PAUSE VIEW, PAUSE VIEWS
SYSTEM STOP VIEW와 달리 SYSTEM PAUSE VIEW는 이미 진행 중인 갱신을 중단하지 않습니다. 현재 실행 중인 갱신은 끝까지 완료되며, 그 이후의 갱신만 중지됩니다.
SYSTEM START VIEW 또는 SYSTEM START VIEWS를 사용해 다시 시작할 수 있습니다.
일시 중지 상태는 server가 재시작되면 유지되지 않습니다. 재시작 후에는 뷰가 구성된 갱신 일정에 따라 다시 갱신됩니다.
Replicated 또는 Shared 데이터베이스에서는
SYSTEM PAUSE VIEW가 현재 레플리카에만 적용됩니다.SYSTEM REFRESH VIEW
SYSTEM WAIT VIEW
EMPTY 키워드 없이) 초기 갱신이 완료될 때까지 기다리는 데 사용할 수 있습니다.
뷰가 Replicated 또는 Shared 데이터베이스에 있고 다른 레플리카에서 갱신이 실행 중인 경우, 해당 갱신이 완료될 때까지 기다립니다.