이 페이지는 ClickHouse Cloud에는 해당되지 않습니다. 여기에서 설명하는 절차는 ClickHouse Cloud 서비스에서 자동으로 처리됩니다.
구현 세부 정보
clickhouse-keeper-converter 도구를 사용하면 ZooKeeper 데이터를 ClickHouse Keeper 스냅샷으로 변환할 수 있습니다. ClickHouse Keeper의 interserver 프로토콜도 ZooKeeper와 호환되지 않으므로, ZooKeeper / ClickHouse Keeper 혼합 cluster는 구성할 수 없습니다.
ClickHouse Keeper는 ZooKeeper와 동일한 방식으로 액세스 제어 목록(ACL)을 지원합니다. ClickHouse Keeper는 동일한 권한 집합을 지원하며, 기본 제공 스킴도 완전히 동일합니다. world, auth, digest입니다. digest 인증 스킴은 username:password 쌍을 사용하며, 비밀번호는 Base64로 인코딩됩니다.
외부 통합은 지원되지 않습니다.
구성
.xml 파일로 정의됩니다.
Keeper 구성 설정
<keeper_server>이며, 다음 매개변수를 사용합니다:
그 밖의 일반적인 매개변수는 ClickHouse 서버 구성(
listen_host, logger 등)에서 상속됩니다.
내부 조정 설정
<keeper_server>.<coordination_settings> 섹션에 있으며, 다음 매개변수가 있습니다:
쿼럼 구성은
<keeper_server>.<raft_configuration> 섹션에 있으며, 서버 설명을 포함합니다.
전체 쿼럼에 대한 유일한 매개변수는 secure이며, 쿼럼 참여자 간 통신에 암호화된 연결을 활성화합니다. 노드 간 내부 통신에 SSL 연결이 필요하면 이 매개변수를 true로 설정할 수 있으며, 그렇지 않으면 지정하지 않아도 됩니다.
각 <server>의 주요 매개변수는 다음과 같습니다:
id— 쿼럼의 서버 식별자입니다.hostname— 이 서버가 배치된 호스트명입니다.port— 이 서버가 연결을 수신하는 포트입니다.can_become_leader— 서버를learner로 설정하려면false로 지정합니다. 생략하면 값은true입니다.
ClickHouse Keeper 클러스터의 토폴로지가 변경되는 경우(예: 서버 교체)에는
server_id와 hostname의 매핑을 일관되게 유지하고, 서로 다른 서버에 기존 server_id를 뒤섞어 사용하거나 재사용하지 않도록 하십시오(예: ClickHouse Keeper 배포에 자동화 스크립트를 사용할 경우 이런 일이 발생할 수 있습니다).Keeper 인스턴스의 호스트가 변경될 수 있다면 원시 IP 주소 대신 호스트명을 정의하여 사용하는 것을 권장합니다. 호스트명을 변경하는 것은 서버를 제거한 뒤 다시 추가하는 것과 같으며, 경우에 따라 이렇게 하지 못할 수도 있습니다(예: 쿼럼을 충족할 만큼 Keeper 인스턴스가 충분하지 않은 경우).async_replication은 이전 버전과의 호환성이 깨지는 것을 방지하기 위해 기본적으로 비활성화되어 있습니다. 클러스터의 모든 Keeper 인스턴스가 async_replication을 지원하는 버전(v23.9+)으로 실행 중이라면, 단점 없이 성능을 개선할 수 있으므로 활성화하는 것을 권장합니다.test_keeper_ 접두사가 있는 통합 테스트에서 확인할 수 있습니다. 서버 #1의 예시 구성은 다음과 같습니다:
실행 방법
/etc/your_path_to_config/clickhouse-server/config.xml에 <keeper_server> 구성을 추가한 다음 평소처럼 ClickHouse 서버를 시작하면 됩니다. standalone ClickHouse Keeper를 실행하려면 다음과 같이 비슷한 방식으로 시작할 수 있습니다:
clickhouse-keeper)가 없으면 해당 링크를 생성하거나, clickhouse의 인수로 keeper를 지정할 수 있습니다:
네 글자 명령어
mntr, stat 등과 같이 네 글자로 이루어집니다. 그중 몇 가지 유용한 명령은 다음과 같습니다. stat는 서버와 연결된 클라이언트에 대한 일반 정보를 제공하고, srvr는 서버에 대한 추가 상세 정보를 제공하며, cons는 연결에 대한 추가 상세 정보를 제공합니다.
4lw 명령에는 four_letter_word_white_list라는 화이트리스트 구성이 있으며, 기본값은 conf,cons,crst,envi,ruok,srst,srvr,stat,wchs,dirs,mntr,isro,rcvr,apiv,csnp,lgif,rqld,ydld입니다.
클라이언트 포트에서 telnet 또는 nc를 사용해 ClickHouse Keeper에 명령을 보낼 수 있습니다.
ruok: 서버가 오류 없는 상태로 실행 중인지 테스트합니다. 실행 중이면 서버는imok로 응답합니다. 그렇지 않으면 전혀 응답하지 않습니다.imok응답이 반드시 서버가 쿼럼에 참여했다는 뜻은 아니며, 서버 프로세스가 활성 상태이고 지정된 클라이언트 포트에 바인딩되어 있다는 의미일 뿐입니다. 쿼럼 관련 상태와 클라이언트 연결 정보에 대한 자세한 내용은 “stat”를 사용하십시오.
mntr: 클러스터 상태를 모니터링하는 데 활용할 수 있는 변수 목록을 출력합니다.
srvr: 서버의 모든 세부 정보를 표시합니다.
stat: server 및 연결된 클라이언트의 간략한 정보를 나열합니다.
srst: server 통계를 재설정합니다. 이 명령은srvr,mntr,stat명령의 결과에 영향을 줍니다.
conf: 현재 사용 중인 구성의 세부 정보를 출력합니다.
cons: 이 서버에 연결된 모든 클라이언트의 전체 연결/세션 세부 정보를 나열합니다. 수신/전송된 패킷 수, 세션 ID, 작업 지연 시간, 마지막으로 수행한 작업 등의 정보를 포함합니다…
crst: 모든 연결의 연결/세션 통계를 재설정합니다.
envi: 서버 실행 환경의 세부 정보를 출력합니다
dirs: 스냅샷과 log file의 전체 크기를 바이트 단위로 표시합니다
isro: server가 읽기 전용 모드로 실행 중인지 확인합니다. 읽기 전용 모드이면ro로, 아니면rw로 응답합니다.
wchs: 서버의 watch에 대한 간단한 정보를 보여줍니다.
wchc: 서버의 watch에 대한 자세한 정보를 세션별로 나열합니다. 이 명령은 관련된 watch(경로)와 함께 세션(연결) 목록을 출력합니다. watch 수에 따라 이 작업은 비용이 많이 들 수 있으므로(서버 성능에 영향을 줄 수 있음) 주의해서 사용하십시오.
wchp: server의 watch에 대한 상세 정보를 경로별로 나열합니다. 관련 session이 연결된 경로(znode) 목록을 출력합니다. watch 수에 따라 이 작업은 비용이 많이 들 수 있으므로(즉, server 성능에 영향을 줄 수 있으므로) 주의해서 사용하십시오.
dump: 현재 남아 있는 세션과 임시 노드를 나열합니다. 이 명령은 리더에서만 작동합니다.
csnp: 스냅샷 생성 작업을 예약합니다. 성공하면 예약된 스냅샷의 마지막으로 커밋된 로그 인덱스를 반환하고, 실패하면Failed to schedule snapshot creation task.를 반환합니다.lgif명령을 사용하면 스냅샷이 완료되었는지 확인할 수 있습니다.
lgif: Keeper 로그 정보입니다.first_log_idx: 로그 저장소의 첫 번째 로그 인덱스,first_log_term: 첫 번째 로그 term,last_log_idx: 로그 저장소의 마지막 로그 인덱스,last_log_term: 마지막 로그 term,last_committed_log_idx: 상태 머신의 마지막 커밋된 로그 인덱스,leader_committed_log_idx: 현재 기준으로 본 leader의 커밋된 로그 인덱스,target_committed_log_idx: 커밋되어야 하는 대상 로그 인덱스,last_snapshot_idx: 마지막 스냅샷에서 가장 큰 커밋된 로그 인덱스.
rqld: 새로운 리더가 되도록 요청합니다. 요청이 전송되면Sent leadership request to leader.를 반환하고, 전송되지 않으면Failed to send leadership request to leader.를 반환합니다. 노드가 이미 리더인 경우에도 결과는 요청이 전송된 경우와 같습니다.
ftfl: 모든 기능 플래그 목록과 Keeper 인스턴스에서 각 플래그의 활성화 여부를 표시합니다.
ydld: 리더 역할을 넘기고 팔로어가 되도록 요청합니다. 요청을 받은 서버가 리더인 경우, 먼저 쓰기 작업을 일시 중지하고 후임자(현재 리더는 후임자가 될 수 없음)가 최신 로그를 모두 따라잡을 때까지 기다린 다음 리더 자리에서 물러납니다. 후임자는 자동으로 선택됩니다. 요청이 전송되면Sent yield leadership request to leader.를, 요청이 전송되지 않으면Failed to send yield leadership request to leader.를 반환합니다. 노드가 이미 팔로어인 경우에도 결과는 요청이 전송되었을 때와 동일합니다.
pfev: 수집된 모든 이벤트의 값을 반환합니다. 각 이벤트에 대해 이벤트 이름, 이벤트 값, 그리고 이벤트 설명을 반환합니다.
HTTP 제어
/ready 엔드포인트를 활성화하는 구성 예시:
기능 플래그
keeper_server.feature_flags 설정으로 활성화할 수 있습니다.
모든 기능은 명시적으로 비활성화할 수 있습니다.
Keeper 클러스터에서 새 기능을 활성화하려는 경우, 먼저 클러스터의 모든 Keeper 인스턴스를 해당 기능을 지원하는 버전으로 업데이트한 다음, 기능 자체를 활성화하는 것을 권장합니다.
multi_read를 비활성화하고 check_not_exists를 활성화하는 기능 플래그 설정 예시는 다음과 같습니다:
일부 기능 플래그는 버전 25.7부터 기본적으로 활성화되어 있습니다.
Keeper를 25.7+로 업그레이드하는 권장 방법은 먼저 버전 24.9+로 업그레이드하는 것입니다.
ZooKeeper에서 마이그레이션
clickhouse-keeper-converter 도구는 ZooKeeper 로그와 스냅샷을 ClickHouse Keeper 스냅샷으로 변환합니다. 이 도구를 사용하려면 ZooKeeper 3.4 이상이 필요합니다.
마이그레이션 전 준비
마이그레이션 단계
- 모든 ClickHouse 노드로의 데이터 수집을 중지합니다.
- 모든 ClickHouse 노드에서 모든 백그라운드 작업을 중지합니다(위 참고).
- 모든 ZooKeeper 노드를 중지합니다.
- 선택 사항이지만 권장됩니다. ZooKeeper 리더 노드를 찾은 다음, 시작했다가 다시 중지합니다. 이렇게 하면 변환 전에 ZooKeeper가 일관된 스냅샷을 디스크에 기록하도록 할 수 있습니다.
-
리더 노드에서
clickhouse-keeper-converter를 실행합니다. 전체 ClickHouse 실행 파일이 설치되어 있다면 대신keeper-converter하위 명령(clickhouse keeper-converter)을 사용합니다. 둘 다 사용할 수 없으면 실행 파일을 다운로드합니다.
- 스냅샷을 모든 ClickHouse Keeper 노드에 복사합니다. 어떤 노드라도 시작되기 전에 모든 노드에 스냅샷이 있어야 합니다. 스냅샷 없이 노드가 시작되면 빈 상태로 스스로 리더로 선출될 수 있습니다.
- 새 Keeper 클러스터를 가리키도록 ClickHouse 구성을 업데이트합니다.
- 모든 노드에서 ClickHouse Keeper를 시작한 다음 ClickHouse를 다시 시작합니다.
- 일관성이 유지되는지 확인할 수 있도록 메트릭을 마이그레이션 전 기준선과 비교합니다.
- 백그라운드 작업을 재개하고 데이터 수집을 다시 시작합니다.
여러 ZooKeeper 클러스터 통합
clickhouse-keeper-converter 도구는 일대일 변환(하나의 ZooKeeper 클러스터를 하나의 Keeper 스냅샷으로 변환)만 지원하므로, 통합하려면 여러 스냅샷을 머지할 수 있도록 컨버터의 소스 코드를 수정해야 합니다.
- 각 ZooKeeper 클러스터에서
clickhouse-keeper-converter를 개별적으로 실행하고, 각 출력은 서로 다른 디렉터리에 기록합니다. - 스냅샷 파일을 순차적으로 역직렬화합니다. 머지할 때는 서로 다른 원본 클러스터의 네임스페이스 사이에서 노드 ID 충돌이 발생하지 않도록
numChildren값을 다시 계산합니다. - 머지된 출력을 대상 ClickHouse Keeper 스냅샷 디렉터리에 기록합니다.
암호화 및 ACL 처리
world, auth, digest)을 지원합니다. 변환 과정에서 ACL을 처리하는 방법은 ZooKeeper 구성에 따라 달라집니다.
- 완전히 암호화되었거나 전혀 암호화되지 않은 경우: 직접 변환하십시오. 컨버터가 기존 ACL 정보를 그대로 유지합니다.
- 부분적으로 암호화된 경우: 변환하기 전에 슈퍼 관리자 계정을 설정하고, 영향을 받는 경로에서
setAcl -R로 ACL을 제거하십시오. 변환한 후 필요하면 ClickHouse Keeper에서 암호화를 다시 활성화하십시오.
마이그레이션 검증
- 공통 경로: 여러 소스 cluster에 동일한 데이터로 존재하는 경로입니다. 병합된 출력에서는 이러한 경로를 중복 제거해야 합니다.
- 구분 경로: 특정 cluster에만 존재하는 경로입니다(예: 각 세그먼트 그룹의
/clickhouse/tables아래). 이러한 경로는 올바른 소스의 것을 유지해야 합니다.
마이그레이션 후 튜닝
이 설정은 Keeper 구성의
coordination_settings 아래에서 설정합니다.
쿼럼을 잃은 후 복구하기
- 장애가 발생한 노드가 다시 클러스터에 연결될 수 없도록 하십시오.
- 단계에서 지정되기 전까지는 새 노드를 시작하지 마십시오.
- 새 리더로 사용할 Keeper 노드 1개를 선택합니다. 이 노드의 데이터가 전체 클러스터에 사용되므로, 가장 최신 상태를 가진 노드를 사용하는 것이 좋습니다.
- 다른 작업을 하기 전에 선택한 노드의
log_storage_path및snapshot_storage_path폴더를 백업하십시오. - 사용할 모든 노드에서 클러스터를 재구성합니다.
- 선택한 노드에 네 글자 명령
rcvr를 보내 노드를 복구 모드로 전환하거나, 선택한 노드의 Keeper 인스턴스를 중지한 뒤--force-recovery인수와 함께 다시 시작합니다. - 새 노드에서 Keeper 인스턴스를 하나씩 시작하고, 다음 노드를 시작하기 전에
mntr가zk_server_state에 대해follower를 반환하는지 확인하십시오. - 복구 모드에서는 리더 노드가 새 노드들과 쿼럼을 이룰 때까지
mntr명령에 대해 오류 메시지를 반환하며, 클라이언트와 팔로워의 모든 요청을 거부합니다. - 쿼럼이 형성되면 리더 노드는 정상 동작 모드로 돌아가 모든 요청을 수락합니다.
mntr로 이를 확인하면zk_server_state에 대해leader를 반환해야 합니다.
Keeper와 디스크 함께 사용하기
- s3_plain
- s3
- local
keeper_server.log_storage_disk 설정을 디스크 이름으로 지정해야 합니다.
스냅샷에 디스크를 사용하려면 keeper_server.snapshot_storage_disk 설정을 디스크 이름으로 지정해야 합니다.
추가로, 최신 로그에는 keeper_server.latest_log_storage_disk를, 최신 스냅샷에는 keeper_server.latest_snapshot_storage_disk를 사용할 수 있습니다.
이 경우 새 로그나 스냅샷이 생성되면 Keeper가 파일을 올바른 디스크로 자동 이동합니다.
상태 파일에 디스크를 사용하려면 keeper_server.state_storage_disk 설정을 디스크 이름으로 지정해야 합니다.
디스크 간 파일 이동은 안전하며, 전송 도중 Keeper가 중지되더라도 데이터가 손실될 위험은 없습니다.
파일이 새 디스크로 완전히 이동하기 전까지는 기존 디스크에서 삭제되지 않습니다.
keeper_server.coordination_settings.force_sync가 true로 설정된 Keeper는 (true가 기본값) 모든 타입의 디스크에서 일부 보장 사항을 충족할 수 없습니다.
현재 영속적 동기화를 지원하는 것은 local 타입 디스크뿐입니다.
force_sync를 사용하는 경우 latest_log_storage_disk를 사용하지 않으면 log_storage_disk는 local 디스크여야 합니다.
latest_log_storage_disk를 사용하는 경우에는 이것이 항상 local 디스크여야 합니다.
force_sync를 비활성화하면 모든 타입의 디스크를 어떤 구성에서든 사용할 수 있습니다.
Keeper 인스턴스에 사용할 수 있는 스토리지 구성 예시는 다음과 같습니다:
log_s3_plain 디스크에 저장하며, 최신 로그는 log_local 디스크에 저장됩니다.
스냅샷에도 동일한 방식이 적용됩니다. 최신 스냅샷을 제외한 모든 스냅샷은 snapshot_s3_plain에 저장되며, 최신 스냅샷은 snapshot_local 디스크에 저장됩니다.
디스크 설정 변경
keeper_server.old_snapshot_storage_disk와 keeper_server.old_log_storage_disk를 여러 개 정의할 수 있습니다.
다음 구성은 이전의 2개 디스크 설정에서 완전히 새로운 단일 디스크 설정으로 전환하는 방법을 보여줍니다:
log_local 및 log_s3_plain에서 log_local2 디스크로 이동됩니다.
또한 모든 스냅샷 file이 snapshot_local 및 snapshot_s3_plain에서 snapshot_local2 디스크로 이동됩니다.
로그 캐시 구성
latest_logs_cache_size_threshold- 캐시에 저장되는 최신 로그의 총 크기commit_logs_cache_size_threshold- 다음 커밋에 필요한 후속 로그의 총 크기
pfev 명령을 사용하면 각 캐시와 파일에서 읽은 로그 양을 확인할 수 있습니다.
또한 Prometheus 엔드포인트의 메트릭을 사용해 두 캐시의 현재 크기를 추적할 수 있습니다.Prometheus
endpoint– Prometheus server가 메트릭을 스크레이핑할 HTTP endpoint입니다. ’/‘로 시작해야 합니다.port–endpoint에 사용할 포트입니다.metrics– system.metrics 테이블의 메트릭을 노출할지 지정하는 플래그입니다.events– system.events 테이블의 메트릭을 노출할지 지정하는 플래그입니다.asynchronous_metrics– system.asynchronous_metrics 테이블의 현재 메트릭 값을 노출할지 지정하는 플래그입니다.
127.0.0.1을 ClickHouse 서버의 IP 주소 또는 호스트명으로 바꾸세요):
ClickHouse Keeper 사용자 가이드
1. Keeper 설정으로 노드 구성하기
-
3개의 호스트(
chnode1,chnode2,chnode3)에 ClickHouse 인스턴스 3개를 설치합니다. (ClickHouse 설치에 관한 자세한 내용은 Quick Start를 참조하십시오.) -
각 노드에 네트워크 인터페이스를 통해 외부와 통신할 수 있도록 다음 항목을 추가합니다.
-
다음 ClickHouse Keeper 구성을 3대의 서버 모두에 추가하고, 각 서버의
<server_id>설정값을 서버에 맞게 업데이트하십시오. 예를 들어chnode1은1,chnode2는2로 설정합니다.위에서 사용한 기본 설정은 다음과 같습니다: -
Zookeeper 컴포넌트를 활성화합니다. ClickHouse Keeper 엔진을 사용합니다:
다음은 위에서 사용한 기본 설정입니다:
-
ClickHouse를 다시 시작하고 각 Keeper 인스턴스가 실행 중인지 확인합니다. 각 서버에서 다음 명령을 실행하십시오.
ruok명령은 Keeper가 실행 중이며 정상 상태이면imok를 반환합니다: -
system데이터베이스에는 ClickHouse Keeper 인스턴스의 세부 정보가 들어 있는zookeeper라는 테이블(table)이 있습니다. 이 테이블을 살펴보겠습니다:테이블은 다음과 같습니다:
2. ClickHouse에서 클러스터 구성하기
-
2개의 세그먼트와 2개 노드에 각각 레플리카 1개만 있는 단순한 클러스터를 구성해 보겠습니다. 세 번째 노드는 ClickHouse Keeper 요구 사항의 쿼럼을 충족하는 데 사용됩니다.
chnode1및chnode2의 구성을 업데이트하십시오. 다음 클러스터는 각 노드에 1개의 세그먼트를 정의하므로 총 2개의 세그먼트가 되며 복제는 없습니다. 이 예시에서는 일부 데이터는 한 노드에, 나머지 데이터는 다른 노드에 저장됩니다: -
ClickHouse를 다시 시작하고 클러스터가 생성되었는지 확인하십시오:
다음과 같이 클러스터가 표시되어야 합니다:
3. 분산 테이블 생성 및 테스트
-
chnode1에서 ClickHouse client를 사용해 새 클러스터에 새 데이터베이스를 생성합니다.ON CLUSTER절을 사용하면 두 노드 모두에 데이터베이스가 자동으로 생성됩니다. -
db1데이터베이스에 새 테이블을 생성합니다. 여기서도ON CLUSTER를 사용하면 두 노드 모두에 테이블이 생성됩니다. -
chnode1노드에 행 2개를 추가합니다: -
chnode2노드에도 행 2개를 추가합니다: -
각 노드에서
SELECT문을 실행하면 해당 노드에 있는 데이터만 표시됩니다. 예를 들어chnode1에서는 다음과 같습니다:chnode2에서는 다음과 같습니다: -
-
두 세그먼트의 데이터를 나타내는
Distributed테이블을 생성할 수 있습니다.Distributed테이블 엔진을 사용하는 테이블은 자체 데이터를 저장하지 않지만, 여러 서버에 대해 분산 쿼리 처리를 수행할 수 있게 해줍니다. 읽기는 모든 세그먼트로 전송되며, 쓰기는 여러 세그먼트에 분산할 수 있습니다.chnode1에서 다음 쿼리를 실행합니다: -
dist_table을 쿼리하면 두 세그먼트의 데이터 4개 행이 모두 반환됩니다:
요약
고유한 경로를 사용하여 ClickHouse Keeper 구성하기
이 페이지는 ClickHouse Cloud에는 해당되지 않습니다. 여기에서 설명하는 절차는 ClickHouse Cloud 서비스에서 자동으로 처리됩니다.
설명
{uuid} 매크로 설정을 사용해
ClickHouse Keeper 또는 ZooKeeper에 고유한 항목을 생성하는 방법을 설명합니다. 고유한
경로를 사용하면 테이블을 자주 생성하고 삭제할 때 유용합니다.
경로를 만들 때마다 해당 경로에 새로운 uuid가 사용되므로
Keeper 가비지 컬렉션이 경로 항목을 제거할 때까지 몇 분씩 기다릴 필요가 없기
때문입니다. 경로는 절대 재사용되지 않습니다.
예시 환경
클러스터 구성 예시:
테이블에서 {uuid}를 사용하도록 설정하는 절차
- 각 서버에서 매크로를 설정합니다 server 1의 예시:
shard 및 replica 매크로는 정의하지만 {uuid}는 여기서 정의하지 않는다는 점에 유의하십시오. {uuid}는 내장값이므로 별도로 정의할 필요가 없습니다.- 데이터베이스 생성
- 매크로와
{uuid}를 사용해 클러스터에 테이블을 생성합니다
- 분산 테이블 생성
테스트
- 첫 번째 노드(예:
chnode1)에 데이터를 삽입합니다.
- 두 번째 노드(예:
chnode2)에 데이터를 삽입합니다
- 분산 테이블을 사용해 레코드 보기
대안
{uuid}를 사용해 기본 복제 경로를 미리 정의할 수 있습니다.
- 각 노드에서 테이블 기본값 설정
- 명시적 매개변수 없이 테이블을 생성합니다:
- 기본 구성의 설정이 사용되었는지 확인합니다
문제 해결
데이터베이스는
Atomic이어야 합니다. 이전 버전에서 업그레이드하는 경우
default 데이터베이스는 Ordinary 유형일 가능성이 높습니다.ClickHouse Keeper 동적 구성 변경
이 페이지는 ClickHouse Cloud에는 해당되지 않습니다. 여기에서 설명하는 절차는 ClickHouse Cloud 서비스에서 자동으로 처리됩니다.
설명
keeper_server.enable_reconfiguration이 활성화되어 있으면 ClickHouse Keeper는 동적 클러스터 재구성을 위해 ZooKeeper의 reconfig
명령을 부분적으로 지원합니다.
이 설정이 비활성화되어 있으면 레플리카의
raft_configuration
섹션을 수동으로 수정하여 클러스터를 재구성할 수 있습니다. 변경 사항은 리더만 적용하므로 모든 레플리카의 파일을 수정해야 합니다.
또는 ZooKeeper 호환 클라이언트에서 reconfig 쿼리를 보낼 수도 있습니다./keeper/config에는 마지막으로 커밋된 클러스터 구성이 다음 형식으로 저장됩니다:
- 각 서버 항목은 줄바꿈으로 구분됩니다.
server_type은participant또는learner입니다(learner는 리더 선출에 참여하지 않습니다).server_priority는 리더 선출 시 어떤 노드를 우선할지를 나타내는 0 이상의 정수입니다. 우선순위가 0이면 서버는 리더가 되지 않습니다.
reconfig 명령을 사용하여 새 서버를 추가하고, 기존 서버를 제거하거나 기존 서버의
우선순위를 변경할 수 있습니다. 다음은 예시입니다(clickhouse-keeper-client 사용):
kazoo 예시입니다:
joining의 서버는 위에서 설명한 서버 포맷이어야 합니다. 서버 항목은 쉼표로 구분해야 합니다.
새 서버를 추가할 때는 server_priority(기본값은 1)와 server_type(기본값은
participant)을 생략할 수 있습니다.
기존 서버 우선순위를 변경하려면 대상 우선순위와 함께 해당 서버를 joining에 추가하십시오.
서버의 host, port, type은 기존 서버 구성과 동일해야 합니다.
서버는 joining과 leaving에 나타나는 순서대로 추가 및 제거됩니다.
joining의 모든 업데이트는 leaving의 업데이트보다 먼저 처리됩니다.
Keeper 재구성 구현에는 몇 가지 주의 사항이 있습니다:
-
증분 재구성만 지원됩니다. 비어 있지 않은
new_members가 포함된 요청은 거부됩니다. ClickHouse Keeper 구현은 멤버십을 동적으로 변경하기 위해 NuRaft API를 사용합니다. NuRaft는 한 번에 단일 서버를 추가하거나 단일 서버를 제거하는 방식만 지원합니다. 즉, 구성의 각 변경 (joining의 각 항목,leaving의 각 항목)은 각각 별도로 결정되어야 합니다. 따라서 일괄 재구성은 최종 사용자에게 오해를 줄 수 있으므로 제공되지 않습니다. 서버 type(participant/learner) 변경도 NuRaft에서 지원하지 않으므로 불가능합니다. 이를 수행할 수 있는 유일한 방법은 서버를 제거한 뒤 다시 추가하는 것이지만, 이 역시 오해를 줄 수 있습니다. -
반환된
znodestat값은 사용할 수 없습니다. -
from_version필드는 사용되지 않습니다.from_version이 설정된 모든 요청은 거부됩니다. 이는/keeper/config가 가상 노드이기 때문입니다. 즉, 영구 저장소에 저장되지 않고 각 요청마다 지정된 노드 구성으로 즉시 생성됩니다. 이렇게 결정한 이유는 NuRaft가 이미 이 구성을 저장하고 있으므로 데이터를 중복 저장하지 않기 위해서입니다. -
ZooKeeper와 달리,
sync명령을 제출해 클러스터 재구성이 완료될 때까지 기다릴 방법은 없습니다. 새 구성은 결국 적용되지만, 적용 시점은 보장되지 않습니다. -
reconfig명령은 여러 이유로 실패할 수 있습니다. 클러스터 상태를 확인하여 업데이트가 적용되었는지 확인할 수 있습니다.
단일 노드 Keeper를 클러스터로 변환하기
- 중요: 새 노드는 현재 쿼럼보다 작은 batches로 추가해야 합니다. 그렇지 않으면 새 노드들끼리 리더를 선출할 수 있습니다. 이 예시에서는 노드를 하나씩 추가합니다.
- 기존 Keeper 노드에서는
keeper_server.enable_reconfiguration구성 매개변수가 활성화되어 있어야 합니다. - Keeper 클러스터의 새로운 전체 구성으로 두 번째 노드를 시작합니다.
- 시작된 후
reconfig를 사용해 노드 1에 추가합니다. - 이제 세 번째 노드를 시작한 다음
reconfig를 사용해 추가합니다. clickhouse-server구성에 새 Keeper 노드를 추가하고, 변경 사항을 적용하기 위해 다시 시작합니다.- 노드 1의 raft 구성을 업데이트하고, 필요하면 다시 시작합니다.
지원되지 않는 기능
create는Stat객체 반환을 지원하지 않습니다create는 TTL을 지원하지 않습니다addWatch는PERSISTENTwatch에서 작동하지 않습니다removeWatch및removeAllWatches는 지원되지 않습니다setWatches는 지원되지 않습니다CONTAINER유형 znode 생성은 지원되지 않습니다SASL authentication은 지원되지 않습니다