1. 유지 관리
이 챕터에서 우리는 카산드라를 건강하게 유지하기 위해서 당신이 할 수 있는 것들을 살펴본다. 당신의 주의를 기울이고 이제 시작하자.
Nodetool은 카산드라와 함께 오고
Nodetool을 사용하기 위해서 카산드라 자신과 같은 환경이 필요하다. 그것은 같은 클래스패스와 로깅 파일을 필요로 한다.
Nodetool을 시작하는 것은 쉽다. 단지 터미널을 열고
$bin/nodetool
이런 식으로 실행하면 에러가 나온다. 그러나 다음에 보는것처럼 실행이 가능한 명령의 리스트가 출력되도록 프로그램을 구동할 수 있다.
1.1. 링의 정보를 구하기
당신이 링과 그 노드에 대하여 얻을 수 있는 정보는 다양하다. 이 섹션에서 살펴보도록 한다. 당신은 각 노드에 대하여 기본적인 정보를 가질 수도 있고 링에 참여하는 모든 노드에 대해서도 볼 수 있다.
10.1.1 정보
가장 직접적인 방법은 info 명령어이다. Nodetool 이 한 개의 노드에 연결하여 그 현재 상태에 대한 기본적인 데이터를 가져온다. 단지 당신이 정보를 구하기 원하는 노드의 주소를 전달하라.
$ bin/nodetool -h 192.168.1.5 info
134439585115453215112331952664863163581
Load : 3.93 MB
Generation No : 1277663698
Uptime (seconds) : 19639
Heap Memory (MB) : 36.60 / 1011.25
여기서 분명하지 않을 수 있는 아이템은 “Generation No” 필드이다. 이것은 모든 엔드포인트와 연관된 심장박동 상태이다. 이것은 Gossiper 가 타임스탬프를 이용하여 관리된다.
10.1.2 링
어떤 노드가 당신의 링에 있고 그것들이 어떤 상태에 있는지 결정하기 위해서 host 와 ring 스윗치를 Nodetool에서 사용하라. 다음과 같다.
$ bin/nodetool -host 192.168.1.5 ring
이것은 당신에게 다음과 같은 결과를 준다.
Address Status Load Range Ring
41654880048427970483049687892424207188
192.168.1.5 Up 1.71 KB 20846671262289044293293447172905883342 |<--|
192.168.1.7 Up 2.93 KB 41654880048427970483049687892424207188 |-->|
여기서 우리는 링안의 모든 노드들의 IP 주소를 본다. 이 경우에 우리는 두 개의 노드가 있고 한 개는 1.5 에 또 하나는 1.7에 있다. 둘 다 현재 살아있다. Load 컬럼은 각 노드가 가지고 있는 데이터의 바이트 개수다.
10.1.3 Range Tokens
키스페이스는 그들의 데이터를 범위로 나눈다. 카산드라는 클러스터의 각 노드에게 고유한 토큰을 할당하는데 그것이 Range Token 이다. 그것은 노드가 주된 복사를 하는 것이 어떤 키인지 결정한다. Ring 스윗치를 사용하여 보여지는 범위 컬럼은 각 노드가 책임이 있는 토큰이 어느것인지 알려준다.
“wrapping range” 라고 불리는 특별한 범위가 있다. 가장 낮은 토큰 값을 가진 노드는 그 토큰보다 적은 모든 키를 할당받는다. 또한 가장 큰 토큰은 그 범위보다 큰 모든 키를 받는다. 그것은 가장 큰것에서 작은 것으로 랩핑한다.
1.2. 통계를 구하기
Nodetool은 또한 당신이 서버의 상태를 데이터 레벨까지 통계를 모을 수 있게 한다. 이것은 info 스윗치로 모은것보다 더 자세한 데이터에 대한 정보이다. 기본적인 두가지 명령이 있다. Cfstats 와 tpstats 이다. 양쪽 다 이제 살펴보도록 한다.
10.2.1 cfstats 사용하기
각 컬럼군의 오버뷰를 보기 위해서 당신은 cfstats스윗치를 사용할 수 있다. 이것은 당신의 클러스터에게 메트릭스를 준다. 컬럼 군의 통계를 보이기 위해 Nodetool을 아래와 같이 실행하라.
$ bin/nodetool -host 192.168.1.5 cfstats
이것은 아래와 같은 출력을 낸다.
Keyspace: Keyspace1
Read Count: 13
Read Latency: 0.3252307692307692 ms.
Write Count: 3
Write Latency: 0.13266666666666665 ms.
Pending Tasks: 0
Column Family: StandardByUUID1
SSTable count: 0
Space used (live): 0
Space used (total): 0
Memtable Columns Count: 0
Memtable Data Size: 0
Memtable Switch Count: 0
Read Count: 0
Read Latency: NaN ms.
Write Count: 0
Write Latency: NaN ms.
Pending Tasks: 0
Key cache capacity: 200000
Key cache size: 0
Key cache hit rate: NaN
Row cache: disabled
Compacted row minimum size: 0
Compacted row maximum size: 0
Compacted row mean size: 0
Column Family: Standard2
SSTable count: 1
Space used (live): 379
Space used (total): 379
Memtable Columns Count: 0
Memtable Data Size: 0
Memtable Switch Count: 1
Read Count: 13
Read Latency: 0.325 ms.
Write Count: 3
Write Latency: 0.133 ms.
Pending Tasks: 0
Key cache capacity: 1
Key cache size: 0
Key cache hit rate: NaN
Row cache: disabled
Compacted row minimum size: 0
Compacted row maximum size: 0
Compacted row mean size: 0
여기서 많은 출력을 간결하게 하기 위해서 생략하였다. 같은 통계가 각 컬럼군을 위해서 생성된다. 우리는 읽기와 쓰기에서 좀 지연되는 것을 볼 수 있고 읽기 쓰기의 총 숫자를 볼수 있으며 캐쉬의 힛트 율, 그리고 Pending Tasks 카운트에서 아직 완료되지 않은 일의 개수를 볼 수 있다.
여기서 통계가 보여주는 한가지는 카산드라가 얼마나 빠른가이다. 이 박스에 로드가 많이 걸리지는 않았으나 쓰기는 1/10 밀리초로 수행되어진다.
10.2.2 tpstats 사용하기
Tpstats 도구는 카산드라가 유지하고 있는 쓰레드 풀에 대한 정보를 준다. 카산드라는 상당히 동시적이고 멀티프로세서 멀티코어기계에 최적화 되어 있다. 게다가 카산드라는 내부적으로 Staged Event-Driven Architecture (SEDA)를 사용하여 카산드라를 잘 유지하기 위해서는 쓰레드풀의 행동과 건강상태를 이해하는 것이 중요하다.
쓰레드풀의 통계를 찾기 위해서 Nodetool을 tpstats 스윗치와 함께 사용하며 아래와 같다.
$ bin/nodetool -host 192.168.1.5 tpstats
이것은 특정한 노드의 쓰레드 풀 데이터를 표현하는 ASCII 출력을 생성한다.
Pool Name Active Pending Completed
FILEUTILS-DELETE-POOL 0 0 101
MESSAGING-SERVICE-POOL 2 4 71594081
STREAM-STAGE 0 0 2
RESPONSE-STAGE 0 0 38154433
ROW-READ-STAGE 0 0 12542
LB-OPERATIONS 0 0 0
COMMITLOG 1 0 65070187
GMFD 0 0 1002891
MESSAGE-DESERIALIZER-POOL 0 0 105025414
LB-TARGET 0 0 0
CONSISTENCY-MANAGER 0 0 2079
ROW-MUTATION-STAGE 1 1 52419722
MESSAGE-STREAMING-POOL 0 0 121
LOAD-BALANCER-STAGE 0 0 0
FLUSH-SORTER-POOL 0 0 115
MEMTABLE-POST-FLUSHER 0 0 115
COMPACTION-POOL 0 0 364
FLUSH-WRITER-POOL 0 0 115
HINTED-HANDOFF-POOL 0 0 154
당신은 직접적으로 얼마나 많은 동작이 어떤 상태에 있는지 볼 수 있다. 그리고 그것들이 액티브한지, 지연되고 있는지, 완료가 되었는지도 볼 수 있다. 이 출력은 쓰기 동작도중에 캡처된다. 그리고 따라서 ROW-MUTATION-STAGE에 활성화된 일이 있다는 것을 보여준다.
출력에서 많은 제로를 보게되는 것은 당신이 서버에서 매우 적은 활동을 한다는 것이나 카산드라가 로드를 감당하기 위해 예외적인 일을 하고 있다는 것을 의미한다.
1.3. 기본적인 유지 관리
당신이 좀 더 영향이 있는 일을 하기 전이나 후에 해야할 몇 가지 일들이 있다. 예를 들어 당신이 플러쉬를 수행한 후에 스냅샷을 찍는 것은 의미가 있다. 그래서 이 섹션에서는 기본적인 유지 관리 일들을 살펴본다. 이것은 repair, snapshot, cleanup 등이다.
10.3.1 Repair
Nodetool repair를 실행하는 것은 카산드라가 주된 압축을 실행하도록 한다. 타겟 노드의 데이터의 Merkel 트리는 계산된다. 그리고 Merkle 트리는 다른 복사본의 것과 비교된다. 이 과정은 다른 노드와 싱크가 맞지 않는 데이터가 잊혀지지 않는다는 것을 확실히 한다.
주된 압축 동안에 서버는 이웃한 노드들과 Merkle 트리를 교환하기 위해서 TreeRequest/TreeResponse를 시작한다. Merkle 트리는 그 컬럼군에 있는 데이터를 표현하는 해쉬이다. 만약 다른 노드의 트리와 맞지 않으면 좀 조정이 된다. 그것은 그들이 셋팅되어져야 할 가장 최근의 값을 결정하기 위해서 이다. 이 트리의 비교 확인은 org.apache.cassandra.service.AntiEntropyService 클래스의 책임이다. AntiEntropyService 는 싱글톤 패턴을 구현한다. 그리고 또한 정적인 Differencer 클래스를 정의한다. 이것은 두개의 트리를 비교하는데 사용된다. 만약 차이점을 발견하면 일치하지 않는 그 범위에서 repair를 런치한다.
그래서 카산드라가 그런 사항들을 자동적으로 다루지만 당신 스스로 그런 것을 실행할 수도 있다.
다른 Nodetool 명령과는 다르게 repair 명령은 당신이 repair하고 싶은 특정한 키스페이스의 이름을 전달하는 것을 요구한다.
$ bin/nodetool repair Keyspace1 -h 192.168.1.7
도구를 실행시킨 후에 당신의 서버로그에서 다음과 같은 출력을 보게된다.
DEBUG 13:34:59,683 Started deliverAllHints
INFO 13:34:59,684 Compacting []
DEBUG 13:34:59,684 Expected bloom filter size : 128
DEBUG 13:34:59,685 Finished deliverAllHints
Merkle 트리란?
그 발명자의 이름 Ralph Merkle 을 딴 Merkle 트리는 또한 “해쉬 트리” 로 알려져 있다. 그것은 바이너리 트리로 표현된 데이터 구조이며 더 큰 데이터셋의 짧은 요약본 데이터 형태이므로 유용하다. 해쉬 트리에서 각 잎은 요약되어야 할 데이터 블록이다. 모든 트리의 부모노드는 그 직접적인 자식노드의 해쉬이다. 그것은 요약을 잘 압축한다.
카산드라에서 org.apache.cassandra.utils.MerkleTree 클래스에 Merkle 트리가 구현되어 있다.
Merkle 트리는 카산드라에서 peer-to-peer 네트워크 노드가 데이터를 받고 바뀌어 지거나 손상이 되지 않았다는 것을 확실히 하기 위해 사용된다. 그것은 암호화에서 파일의 내용을 검사하고 전달하기 위해서도 사용된다. 이것은 Google Wave 에서도 사용이 된다.
10.3.2 Flush
데이터는 memtable에 저장이 된다. Memtable 로부터 파일 시스템의 SSTable로 데이터를 쓰기 위해서 당신은 Nodetool의 flush 명령을 쓸 수 있다. 다음과 같다.
bin/nodetool flush -h 192.168.1.1 -p 9160
당신이 서버 로그를 확인한다면 다음과 같은 출력을 보게 된다.
DEBUG 15:16:33,945 Forcing binary flush on keyspace Keyspace1, CF Standard2
DEBUG 15:16:33,945 Forcing flush on keyspace Keyspace1, CF Standard2
INFO 15:16:33,945 Standard2 has reached its threshold;
switching in a fresh Memtable at
CommitLogContext(file='/var/lib/cassandra/commitlog/CommitLog-1277663698134.log',
position=1390)
//etc
INFO 15:16:34,104 Completed flushing /var/lib/cassandra/data/Keyspace1/
Standard2-3-Data.db
10.3.3 Cleanup
얼마간 운용이 되는 클러스터를 가지고 있다고 하자. 그리고 당신은 replication factor나 replication strategy 를 변경하기 원한다. 그것은 두가지 경고와 함께 가능하다. 첫째 이것은 살아있는 클러스터에 수행되려는 것은 아니었다. 그래서 노드를 다운시키고 다시 올리는 것을 요구할 지도 모른다. 그것은 당신이 설정을 다이나믹하게 다시 로드 했어도 마찬가지 이다. 둘째 당신은 모든 것이 이상없다는 것을 확인하기 위해 Nodetool cleanup을 실행하기 원하게 될 것이다.
당신은 당신이 깨끗이 하기 원하는 노드에 Nodetool을 cleanup 인자를 가지고 실행할 수 있다.
$ bin/nodetool cleanup -h 192.168.1.7
이것은 실행하고 곧바로 컨트롤을 터미널에게 반환한다. 근본적으로 이것은 특정한 노드에 반압축을 실행한다.
1.4. Snapshots
Snapshot의 목적은 노드에서 일부나 전체 키스페이스의 복사본을 만들고 별도의 데이터 베이스 파일에 근본적으로 저장하는 것이다. 이것은 당신이 키스페이스를 백업하여 놓았다가 당신이 차후에 되살릴수 있다는 것을 의미한다.
10.4.1 Snapshot을 찍기
당신이 한 개나 그 이상의 키스페이스의 스냅샷을 찍을 때 카산드라는 Table 클래스에 그 호출을 대신한다. 그리고 후에 모든 컬럼군에 스냅샷 메서드를 부른다. 이것은 SSTable의 복사본을 생성하기 위해서 단지 자바 파일을 사용한다. 여기서 의미하는 바를 기억하자. 데이터가 commit log에만 존재한다면 스냅샷의 일부가 아니다. 이전에 flush 된 데이터만이 스냅샷의 일부이다. 그것은 storage service가 기본적으로 직접적인 복사를 행하기 때문이다.
스냅샷을 찍는것은 복잡하지 않다.
$ bin/nodetool -h 192.168.1.5 snapshot
이것은 서버 로그에서 스냅샷이 찍혔다는 것을 출력한다.
DEBUG 14:25:15,385 Snapshot for Keyspace1 table data file
/var/lib/cassandra/data/Keyspace1/Standard2-1-Filter.db
created as /var/lib/cassandra/data/Keyspace1/snapshots/1277673915365/
Standard2-1-Filter.db
DEBUG 14:25:15,424 Snapshot for system table data file
/var/lib/cassandra/data/system/LocationInfo-9-Filter.db
created as /var/lib/cassandra/data/system/snapshots/1277673915389/
LocationInfo-9-Filter.d
스냅샷은 그것이 찍혀진 타임스탬프 이름의 폴더에 위치하며 그 데이터파일 끝과 같이 .db 익스텐션으로 끝난다. 그것은 다른 카산드라의 일반적인 데이터 테이블과 같다. 여기 카산드라의 내부적인 키스페이스 system을 포함하여 서버의 모든 키스페이스의 스냅샷이 찍혀있다.
당신이 만약 단 한 개의 키스페이스의 스냅샷만을 찍기 원한다면 추가적인 인자를 전달하여야 한다.
$ bin/nodetool -h 192.168.1.5 snapshot Keyspace1
만약 당신이 이전에 찍었던 스냅샷을 되살리고 싶다면 몇가지 간단한 과정이 있다. 단순히 노드를 닫고 오래된 SSTable과 commit log를 제거한다. 그리고 스냅샷 디렉토리로부터 모든 파일을 일반적인 데이터 디렉토리로 복사한다.
10.4.2 스냅샷을 깨끗이 하기
당신은 당신이 만든 어떤 스냅샷이던 지울수 있다. 말하자면 당신이 그것들을 영구한 저장을 위해 어딘가 저장한 후이다. 당신의 스냅샷을 지우기 위해 Nodetool의 clearsnapshot 스윗치를 사용한다.
당신은 서버에서 아래와 같은 출력을 보게된다.
DEBUG 14:45:00,490 Disseminating load info ...
DEBUG 14:45:11,797 Removing snapshot directory
/var/lib/cassandra/data/Keyspace1/snapshots
DEBUG 14:45:11,798 Deleting Standard2-1-Index.db
DEBUG 14:54:45,727 Deleting 1277675283388-Keyspace1
//...clearing out other data files
DEBUG 14:54:45,728 Deleting snapshots
DEBUG 14:45:11,806 Cleared out all snapshot directories
여기서의 행동을 주의하자. 이 키스페이스를 위해 system 테이블과 같이 저장된 것을 포함하여 모든 스냅샷이 지워진다.
1.5. Load-Balancing the Cluster
만약 당신이 당신의 클러스터가 밸런스가 맞지 않는 것을 발견했다면 아마 특정한 범위에 많은 키가 삽입되어졌기 때문이다. 당신은 당신의 클러스터의 밸런스를 맞추기 위해 데이터를 재배분할 수 있다.
10.5.1 loadbalance and streams
Nodetool의 loadbalance 스윗치를 사용하는 것은 노드를 해체한다. 그래서 그 토큰을 다른 노드로 보내고 그것을 다시 시작한다. Loadbalance 명령은 근본적으로 두 개의 별도 일을 편리하게 하는 랩퍼이다. Decommission 과 bootstrap 이다.
당신은 load-balancing 동작을 모니터할 수 있다. 그것은 데이터가 많이 있다면 조금 시간이 걸린다. Nodetool에서 stream 스윗치를 한다면 그렇다.
여기 loadbalance 인자를 Nodetool에 주고 데이터를 1.5에서 다른 노드로 보낸다.
$ bin/nodetool -host 192.168.1.5 loadbalance
이것은 load-balancing 프로세스를 시작한다. 그것이 일어나는 동안 우리는 우리가 확인하기 원하는 호스트와 stream 인자를 사용하여 그 상태를 체크할 수 있다. 그리고 우리의 다른 노드들은 아직 OK인지 확인한다.
eben@morpheus$ bin/nodetool streams -h 192.168.1.5
Mode: Leaving: streaming data to other nodes
Not sending any streams.
Not receiving any streams.
eben@morpheus$ bin/nodetool streams -h 192.168.1.7
Mode: Normal
Not sending any streams.
Not receiving any streams
일단 load balancing이 끝나면 우리는 로그를 보고 balancing 동안에 무엇이 일어났는지 체크할 수 있다.
여기 우리는 우리가 load balanced를 한 후 1.5에 있는 노드가 클러스터를 떠나는 것을 보고 데이터를 다른 노드로 보내는 것을 본다. 그리고 스스로 부트스트랩을 한다. 그리고 나서 데이터를 다시 받기 시작한다. 이것은 load balancing의 효과가 있다.
DEBUG 10:46:58,727 Leaving: old token was 20846671262289044293293447172905883342
DEBUG 10:46:58,746 Pending ranges:
/192.168.1.7:
(41654880048427970483049687892424207188,
20846671262289044293293447172905883342]
INFO 10:46:58,746 Leaving: sleeping 30000 for pending range setup
DEBUG 10:46:59,323 Disseminating load info ...
DEBUG 10:47:28,748 Node /192.168.1.5 ranges
[(41654880048427970483049687892424207188,20846671262289044293293447172905883342]]
DEBUG 10:47:28,749 Range
(41654880048427970483049687892424207188,20846671262289044293293447172905883342]
will be responsibility of /192.168.1.7
DEBUG 10:47:28,750 Ranges needing transfer are
[(41654880048427970483049687892424207188,20846671262289044293293447172905883342]]
INFO 10:47:28,750 Leaving: streaming data to other nodes
DEBUG 10:47:28,753 Beginning transfer process to /192.168.1.7 for ranges
(41654880048427970483049687892424207188,20846671262289044293293447172905883342]
INFO 10:47:28,753 Flushing memtables for Keyspace1...
INFO 10:47:28,753 Performing anticompaction ...
DEBUG 10:47:28,754 waiting for stream aks.
INFO 10:47:28,754 AntiCompacting [org.apache.cassandra.io.SSTableReader(
path='/var/lib/cassandra/data/Keyspace1/Standard2-1-Data.db')]
DEBUG 10:47:28,755 index size for bloom filter calc for file :
/var/lib/cassandra/data/Keyspace1/Standard2-1-Data.db : 256
DEBUG 10:47:28,755 Expected bloom filter size : 128
INFO 10:47:28,886 AntiCompacted to /var/lib/cassandra/data/Keyspace1/stream/
Standard2-2-Data.db.
239/239 bytes for 1 keys. Time: 131ms.
INFO 10:47:28,887 AntiCompacting []
DEBUG 10:47:28,887 Expected bloom filter size : 128
INFO 10:47:28,888 AntiCompacting []
INFO 10:47:28,892 Stream context metadata /var/lib/cassandra/data/Keyspace1/stream/
Standard2-2-Index.db:55,
1 sstables./var/lib/cassandra/data/Keyspace1/stream/Standard2-2-Filter.db:325,
1 sstables./var/lib/cassandra/data/Keyspace1/stream/Standard2-2-Data.db:239
DEBUG 10:47:28,893 Adding file /var/lib/cassandra/data/Keyspace1/stream/
Standard2-2-Index.db to be streamed.
DEBUG 10:47:28,893 Adding file /var/lib/cassandra/data/Keyspace1/stream/
Standard2-2-Filter.db to be streamed.
DEBUG 10:47:28,893 Adding file /var/lib/cassandra/data/Keyspace1/stream/
Standard2-2-Data.db to be streamed.
INFO 10:47:28,895 Sending a stream initiate message to /192.168.1.7 ...
DEBUG 10:47:28,895 attempting to connect to /192.168.1.7
INFO 10:47:28,895 Waiting for transfer to /192.168.1.7 to complete
DEBUG 10:47:29,309 Running on default stage
DEBUG 10:47:29,310 Received a stream initiate done message ...
DEBUG 10:47:29,310 Streaming 55 length file /var/lib/cassandra/data/Keyspace1/stream/
Standard2-2-Index.db ...
DEBUG 10:47:29,316 Bytes transferred 55
DEBUG 10:47:29,316 Done streaming /var/lib/cassandra/data/Keyspace1/stream/
Standard2-2-Index.db
DEBUG 10:47:29,331 Running on default stage
DEBUG 10:47:29,332 Deleting file /var/lib/cassandra/data/Keyspace1/stream/
Standard2-2-Index.db after streaming
55/619 bytes.
DEBUG 10:47:29,332 Streaming 325 length file /var/lib/cassandra/data/Keyspace1/stream/
Standard2-2-Filter.db ...
DEBUG 10:47:29,335 Bytes transferred 325
DEBUG 10:47:29,335 Done streaming /var/lib/cassandra/data/Keyspace1/stream/
Standard2-2-Filter.db
DEBUG 10:47:29,345 Running on default stage
DEBUG 10:47:29,345 Deleting file /var/lib/cassandra/data/Keyspace1/stream/
Standard2-2-Filter.db after streaming
325/619 bytes.
DEBUG 10:47:29,345 Streaming 239 length file /var/lib/cassandra/data/Keyspace1/
stream/Standard2-2-Data.db ...
DEBUG 10:47:29,347 Bytes transferred 239
DEBUG 10:47:29,347 Done streaming /var/lib/cassandra/data/Keyspace1/stream/
Standard2-2-Data.db
DEBUG 10:47:29,389 Running on default stage
DEBUG 10:47:29,390 Deleting file /var/lib/cassandra/data/Keyspace1/stream/
Standard2-2-Data.db after streaming
239/619 bytes.
DEBUG 10:47:29,390 Signalling that streaming is done for /192.168.1.7
INFO 10:47:29,390 Done with transfer to /192.168.1.7
DEBUG 10:47:29,391 stream acks all received.
DEBUG 10:47:29,392 No bootstrapping or leaving nodes -> empty pending ranges
for Keyspace1
DEBUG 10:48:59,322 Disseminating load info ...
DEBUG 10:49:01,406 Processing response on a callback from 191997@/192.168.1.7
INFO 10:49:01,406 New token will be 134439585115453215112331952664863163581 to
assume load from /192.168.1.7
INFO 10:49:01,407 re-bootstrapping to new token
134439585115453215112331952664863163581
INFO 10:49:01,407 Joining: sleeping 30000 for pending range setup
INFO 10:49:31,408 Bootstrapping
DEBUG 10:49:31,408 Beginning bootstrap process
DEBUG 10:49:31,413 Added /192.168.1.7/Keyspace1 as a bootstrap source
DEBUG 10:49:31,414 Requesting from /192.168.1.7 ranges
(41654880048427970483049687892424207188,134439585115453215112331952664863163581]
DEBUG 10:49:32,097 Running on default stage
DEBUG 10:49:32,098 StreamInitiateVerbeHandler.doVerb STREAM_INITIATE 10579
이제 카산드라가 load balancing을 수행하는 과정을 좀 더 자세히 보자. 우리는 출력에서 몇가지가 일어나는 것을 본다. 첫째, 카산드라는 가용한 클러스터 노드를 조사한다. 그리고 각 토큰 범위를 본다. 그리고 그것은 스트림되어야 할 1.5 서버의 데이터 베이스 파일의 리스트를 생성한다. Standard2 컬럼군이 데이터를 가지기 때문에 그것은 인덱스, 데이터 그리고 필터 파일의 값을 다른 노드로 옮긴다. 1.5 노드는 stream initiate 메시지를 1.7 노드로 보내고 데이터를 그 노드로 스트리밍 시작한다는 것을 표시한다. 바이트는 그리고 전송된다. 그리고 일단 1.7이 데이터를 받는 다는 것을 알게되면 로컬 파일은 1.5에서 지워진다. 그리고 서버는 잠시동안 해체된다. 곧바로 1.5 노드는 돌아온다. 그리고 클러스터에 그것이 다시 가용하고 데이터를 받는다는 것을 알린다. 새로운 범위 토큰이 할당되고 1.5 노드는 1.7 서버로 부터 약간의 load 를 가정하기 시작한다.
만약 우리가 이제 Nodetool을 ring 인자와 같이 실행한다면 우리는 새로운 범위가 그 노드에 할당이 되는 것을 보게 된다. 그리고 그것들은 둘다 대략 똑 같은 양의 데이터를 데이터를 가지게 된다.
Address Status Load Range Ring
134439585115453215112331952664863163581
192.168.1.7 Up 3.53 KB 41654880048427970483049687892424207188 |<--|
192.168.1.5 Up 2.95 KB 134439585115453215112331952664863163581 |-->|
1.6. 노드를 해체하기
노드를 해체하는 것은 서비스에서 그것을 끌어내는 것을 의미한다. 당신이 Nodetool에서 decommission을 호출 할 때 카산드라의 StorageService 클래스에 해체 동작을 호출하는 것이다.
당신이 링에서 두개의 노드를 가지고 있다고 하자.
eben@morpheus$ bin/nodetool -host 192.168.1.5 ring
Address Status Load Range Ring
134439585115453215112331952664863163581
192.168.1.7 Up 4.17 KB 41654880048427970483049687892424207188 |<--|
192.168.1.5 Up 3.59 KB 134439585115453215112331952664863163581 |-->|
이제 우리는 1.7 노드를 해체하기 원한다. 당신은 서비스에서 한 개의 노드를 끌어내기 위해서 decommission 인자를 Nodetool에게 발행할 수 있다. 다음과 같다.
$ bin/nodetool decommission -h 192.168.1.7
이 명령을 발행한 후에 그것은 설정된대로 얼마간 기다린다. 디폴트로 이것은 30초이다. Nodetool은 어떤 것도 더 이상 출력하지 않는다. 그러나 서버 로그는 한다. 우리의 1.5 노드에서 우리는 decommission 명령을 발행한 후에 아래와 같은 출력을 보게된다.
DEBUG 13:59:00,488 Disseminating load info ...
DEBUG 13:59:40,010 Node /192.168.1.7 state leaving, token
41654880048427970483049687892424207188
DEBUG 13:59:40,022 Pending ranges:
/192.168.1.5:
(134439585115453215112331952664863163581,41654880048427970483049687892424207188]
DEBUG 14:00:00,488 Disseminating load info ...
DEBUG 14:00:10,184 Running on default stage
DEBUG 14:00:10,184 StreamInitiateVerbeHandler.doVerb STREAM_INITIATE 4084
DEBUG 14:00:10,187 no data needed from /192.168.1.7
DEBUG 14:00:10,551 Node /192.168.1.7 state left, token
41654880048427970483049687892424207188
DEBUG 14:00:10,552 No bootstrapping or leaving nodes -> empty pending ranges for
Keyspace1
INFO 14:00:18,049 InetAddress /192.168.1.7 is now dead.
Gossiper는 1.5에게 떠나는 상태에 있음을 말해준다. 이 특별한 케이스에서 그것은 1.7로부터 데이터를 스트림하지 않아도 되는데 이미 밸런스가 맞기 때문이다. 그리고 1.5는 소식을 듣게 된다. 1.7은 죽었다. 우리가 만약 nodetool –h
그 동안에 우리가 해체하는 노드의 서버 로그에서는 아래와 같은 출력을 본다.
INFO 13:37:36,299 InetAddress /192.168.1.5 is now UP
INFO 13:59:40,929 Leaving: sleeping 30000 for pending range setup
INFO 14:00:11,286 Leaving: streaming data to other nodes
INFO 14:00:11,318 Flushing memtables for Keyspace1...
INFO 14:00:11,318 Performing anticompaction ...
INFO 14:00:11,333 AntiCompacting [org.apache.cassandra.io.SSTableReader(path='c
:\var\lib\cassandra\data\Keyspace1\Standard2-2-Data.db'),org.apache.cassandra.io
.SSTableReader(path='c:\var\lib\cassandra\data\Keyspace1\Standard2-1-Data.db')]
INFO 14:00:11,349 AntiCompacting []
INFO 14:00:11,364 AntiCompacting []
INFO 14:00:11,411 Stream context metadata
INFO 14:00:11,427 Sending a stream initiate message to /192.168.1.5 ...
INFO 14:00:13,455 Shutting down MessageService...
INFO 14:00:13,455 Shutdown complete (no further commands will be processed)
INFO 14:00:13,470 Decommissioned
INFO 14:00:13,470 MessagingService shutting down server thread.
노드는 1.5를 안 상태에서 시작한다. 그리고 decommission 명령을 받는다. 그것은 떠나는 상태로 되고 30초를 잠든다. 그리고 모든 필요한 범위 정보를 모으기에 충분한 시간이라는 것을 확인한다. Memtable은 메모리에서 SSTable의 디스크로 flush 된다. 그리고 데이터에대해 anti-compaction 이 실행된다. 그리고 그것은 필요한대로 1.5로 그 데이터를 전송하기 위해 스트림을 시작한다. 마지막으로 셧 다운된다.
만약 당신이 decommission을 decommission 될 수 없는 노드에 호출하면 당신은 에러 메시지를 보게 된다. Decommission 동안 기본적인 실행되는 과정은 다음과 같다.
1. Gossiper는 더 이상의 데이터를 받지 않도록 셧 다운된다.
2. 이 노드를 위한 메시징 서비스는 셧 다운된다.
3. SEDA 스테이지 매니저는 셧 다운된다. 왜냐하면 스테이지간에 옮기기 위해서 더 이상의 일을 받지 않기 때문이다.
4. 모드는 “decommissioned” 로 셋팅된다.
5. 스토리지 서비스는 전송되어야 할 범위에 어떤 노드가 적당한 데이터를 받을지 결정하게 된다. 데이터는 다른 노드로 스트림된다.
6. 일단 받는 노드가 성공적인 데이터의 전송을 알게되고 더 이상의 전송이 없으면 서버는 링을 떠나게 된다.
1.7. 노드를 업데이트하기
10.7.1 토큰을 제거하기
만약 당신이 토큰을 제거하기 원한다면 당신은 Nodetool로 그것을 할 수 있다.
단순하게 removetoken 에의 인자가 실제 당신이 제거하기 원하는 토큰이 되게 하고 다음과 같은 명령을 실행하라.
$ bin/nodetool -h 127.0.0.1 removetoken 42218023250148343019074760608074740927
클라이언트는 성공했다는 커멘트가 없이 반환된다. 당신이 노드의 토큰을 제거할 수 없다는 것을 기억하라. 그것은 노드의 온전함을 파괴한다. 당신은 node1에 연결할 수 있고 그것을 주어진 토큰을 지우도록 사용할 수 있는데 그것은 링안에 어디서든 이다.
10.7.2 Compaction Threshold
Compaction Threshold 는 SSTable의 숫자를 참조한다. 그것은 마이너한 compaction 이 되기 전에 큐에 있는 것이다. 디폴트로 미니멈 숫자는 4이고 맥시멈은 32 이다. 당신은 이 숫자가 너무 작게를 원하지는 않거나 카산드라는 많은 빈번하고 필요없는 compaction을 리소스가 수행하지는 않도록 클라이언트와 싸움을 벌인다. 그래서 당신은 또한 이 숫자가 너무 크기를 원하지는 않는다. 아니면 카산드라는 많은 compaction을 한 번에 수행하기 위해서 많은 리소스를 사용한다. 그래서 클라이언트에게는 적은 리소스만이 가용하다.
주어진 노드에서 compaction threshold를 찾기 위해서는 Nodetool과 getcompactionthreshold 명령을 사용한다.
eben@morpheus$ bin/nodetool -h 192.168.1.5 getcompactionthreshold
Current compaction threshold: Min=4, Max=32
10.7.2 작동중인 클러스터에서 컬럼군을 변경하기
만약 당신이 필요하다면 당신은 추가하고 제거하고 컬럼군의 이름을 바꾸는 등 일을 작동하는 카산드라 클러스터에서 할 수 있다. 여기 실행해야 할 과정이 있다.
1. Nodetool을 사용하여 drain을 commit log를 비우기 위해 수행하라.
2. 카산드라를 셧 다운하고 commit log에 아무 데이터도 남아있지 않다는 것을 확인한다.
3. SSTable 파일들을 삭제한다. 이 파일들은 당신의 데이터 디렉토리에 있고
