이 글을 보기 전에 먼저 봐야할 문서


http://knight76.tistory.com/entry/cassandra-node-repair-%EC%B2%98%EB%A6%AC-%EB%B0%A9%EC%8B%9D





cassandra 노드를 reparing하는 방법 중 가장 오래 걸리지만 서비스에 영향을 주지 않는 방법인 subrange repair 방법을 소개한다. 


우선 nodetool을 이용해 토큰 정보를 살펴본다.



$ nodetool ring

Datacenter: datacenter1
==========
Address        Rack        Status State   Load            Owns                Token
                                                                                                      9211576253984633484
1.1.1.1  rack1       Up     Normal  3.19 GB         100.00%             -9143017454602368711
1.1.1.2  rack1       Up     Normal  3.19 GB         100.00%             -9137016989552942674
,,


subrange를 사용하려면 계산하고 이런 작업이 귀찮아서 오픈소스를 확인했더니,https://github.com/BrianGallew/cassandra_range_repair.git(https://github.com/BrianGallew/cassandra_range_repair/blob/master/src/range_repair.py)가 괜찮을 것 같다. 특히 dry run모드가 있어서 테스트해볼 수 있는 장점이 있다 (단점으로는 중간에 중지시키는게 번거롭다. for 문에서 continue되어 다음 토큼으로 넘어가기기 때문에 kill로 작업해야 한다)

https://github.com/BrianGallew/cassandra_range_repair/blob/master/src/range_repair.py는 python 2.6이면 six 모듈 때문에 문제가 될 수 있으니. python 2.7.9로 업그레이드해야 한다.

git clone https://github.com/BrianGallew/cassandra_range_repair.git를 해서 ./src/range_repair.py을 실행한다. 

이 스크립트로 dry-run 모드로 실행해 본다. 



./range_repair.py  -k google -v -d -H localhost --dry-run 를 실행한다. 토큰이 제대로 되는지 확인했다. 


0001/1/256 nodetool -h localhost -p 7199 repair google -pr    -st +09211576253984633484 -et +09212497757635858978
0002/1/256 nodetool -h localhost -p 7199 repair google -pr    -st +09212497757635858978 -et +09213419261287084472

..
0100/256/256 nodetool -h localhost -p 7199 repair google -pr    -st +09211440617066457144 -et +09211576253984633484





로그 파일은 다음과 같이 추가한다.

 --logfile test.log


테이블 단위로 repairing할 수 있다.

./range_repair.py  -k story -c 테이블_이름 -d  -H localhost


시간이 오래 걸려서 screen 실행하고 백그라운드로 작업 돌리는 것이 좋을 것 같다. 

상황에 따라서는 너무 오래 걸리기도 하고, 부하를 줘서 latency가 커질 수 있어서 부하가 적은 시간에 여러 날에 걸쳐 동작시켜야 할 수도 있다. 



Posted by '김용환'
,


대용량 cassandra를 운영한다는 것은 좀 공부가 필요한 것 같다. redis 이상의 운영 노하우가 필요한 것 같다. 


특히 compaction이나 node repair를 하다가 cassandra를 읽는 부분에서 timeout나고 에러 뜨고 장난아니다.

dry-run 이런 옵션이 nodetool에 없기에 공부를 반드시 많이하고 다른 곳에서는 compaction을 어떻게 하는지 살펴볼 필요가 있다. 





cassandra는 3가지 동기화 방식을 가진다. 

cassandra 전문 용어로 Hinted Hand-off, Read-Repair, Anti-Entropy Repair이다. 


이 중 Anti-Entropy Repair 방식은 수동으로 동작시키는 nodetool repair를 말한다. 


node repair를 실행하면 가장 먼저 coordinator 노드는 데이터를 기준으로 primary와 복제본 파티션 정보를 얻기 위해 각 노드마다 요청하고 Merkle 트리를 구성하려 한다. 마침 요청받은 카산드라 노드(peer node)는 SSTable을 스캔해서 유효성 검사를 진행하고 major compaction(SSTable의 모든 row를 읽고 해시를 생성한다)을 실행시켜 Merkle tree의 구성을 완료하면 Merkle 트리의 기반이 되는 데이터를 coodinator node에 전달한다. coodinator node는 모든 Merkle 트리를 모든 트리와 비교해, 차이를 발견하면(해시 비교) 서로 다른 노드간에 데이터가 교환된다. 


<참고>

Merkle 트리 : 잎은 데이터이고, 상위 노드는 자식 노드의 해시 값으로 구성된 이진 트리

p2p나 cassandra과 같은 형태의 데이터 구조에서 해시의 변조를 통해 데이터가 바뀌었는지를 쉽게 알 수 있다. 

(참고 : https://docs.datastax.com)



Merkle 트리를 구성하기 위해서는 SSTable을 모두 읽기 때문에 cpu, memory, disk i/o, network inbound/outbound가 급격하게 올라간다. 또한 데이터의 불일치가 많이 발생하면 network 비용이 올라간다. 



node repair 방식을 설명하기 전에 아래 아래 디폴트 설정을 잠깐 본다.  reparing은 2가지 관점이 필요하다. 처음에 cassandra reparing을 공부할 때 헤매기도 한다.


Full <--> Increment

Parrallel <--> Sequentail


http://www.datastax.com/dev/blog/repair-in-cassandra

Cassandra 1.2 introduced a new option to repair to help manage the problems caused by the nodes all repairing with each other at the same time, it is call a snapshot repair, or sequential repair. As of Cassandra 2.1, sequential repair is the default, and the old parallel repair an option




http://docs.datastax.com/en/archived/cassandra_win/3.x/cassandra/tools/toolsRepair.html

Incremental repair is the default for Cassandra 2.2 and later, and full repair is the default in Cassandra 2.1 and earlier. In Cassandra 2.2 and later, when a full repair is run, SSTables are marked as repaired and anti-compacted. Parallel repair is the default for Cassandra 2.2 and later, and sequential repair is the default in Cassandra 2.1 and earlier.




따라서 2.1 cassandra의 default repairing 정책은 full, sequential repair이다!!




1. primary range repair

0.x부터 있던 옵션으로 오래된 방식의 repairing 방식으로, primary node(커맨드를 실행한 노드)만 repair가 일어난다. 다른 노드에서 작업할려면 다른 노드 서버로 로그인하고 repair 커맨드를 실행해야 한다. 잘 안쓴다.


2. sequential repair 

snapshot repair라기도 한다. 전체 노드에 대해서 순차적으로 repairing을 시도한다. 부하가 좀 낮기 때문에 괜찮다. 2.1의 default 정책이다.


3. parrallel repair

repair 옵션에 -par을 추가한 경우이다. 동시(concurrently)에 Merkle 트리를 구성하도록 모든 노드에 명령을 내린다. 빨리 repairing이 되지만 모든 부하가 커져서 요청 데이터를 받지 못할 수 있다. cassandra의 모든 데이터가  서비스에서 카산드라를 사용하는 중에 -par을 사용하면 애플리케이션 바로 hang이 된 것처럼 타임아웃이 발생한다. (서비스용도라면 절대로 사용하지 말아야 한다)


4. Incremental repair

2.1부터 추가된 옵션으로 증분 reparing을 지원한다. 2.2부터 default이다. (아직 안써봤다!)

leveled compaction strategy를 사용할 때 incremental repair를 할 때는 에러가 발생할 수 있다고 한다(https://issues.apache.org/jira/browse/CASSANDRA-9935). 또한 incremental repair를 사용하면 leveled compaction strategy에서 sizedTierStrategy로 바뀐다고 하니, 운영 노하우를 알면 좋을 듯 하다.


5. subrange repair

primary range repair와 같지만, 시작 토큰 값(start token)과 마지막 토큰 값(end token)을 정의할 수 있는 유연성을 가지고 있다. "-st" (or "–start-token") 와 "-et" (or “–end-token”) 를 사용한다. 많이 느리긴 하지만 부하를 줄이고 서비스의 안정성을 확보한다는 점에서 좋은 것 같다. 


subrange repair 작업은 http://knight76.tistory.com/entry/cassandra-node-subrange-repair-%EC%9E%91%EC%97%85-%EB%B2%94%EC%9C%84-%EB%8B%A8%EC%9C%84%EB%A1%9C-repairing-%ED%95%98%EA%B8%B0를 참고한다.



***

나름 repair를 해보니..


compaction할 것이 없다면(즉 tombstone이 없다면), sstable이 많을 수록 오래걸리지만 많은 부하를 발생하지 않는다. sstable이 작더라도 키 개수가 많으면 오래 걸린다. 


compaction할 것이 많다면(tombstone이 많으면), 키 개수와 상관없이 부하가 엄청 튄다. 


79만개이지만 tombstone이 많으면 튄다... 하지만 6백만개의 키이지만 tombstone이 없으면 많이 튀지 않는다. 




**


repair 실행할 때 키스페이스와 테이블을 설정할 수 있는데, 키스페이스 앞에 --을 두면 에러가 발생한다. -- 다음에 스페이스를 하나 두고 작업하는 것이 좋다.


$ nodetool repair --google_plus  recent_relation

 이건 에러가 발생한다.


$ nodetool repair -- google_plus  recent_relation

성공 


Posted by '김용환'
,

cassandra는 백업을 지원한다. cassandra에서는 snapshot이라고 부른다.

nodetool snapshot 커맨드를 사용해서 snapshot을 생성할 수 있다.
https://docs.datastax.com/en/cassandra/2.1/cassandra/tools/toolsSnapShot.html

$ nodetool snapshot -cf activity_history google
Requested creating snapshot(s) for [google] with snapshot name [1485312417477]
Snapshot directory: 1485312417477


정상적으로 저장되었는지 확인하려면 다음 커맨드를 실행한다. snapshot이라는 디렉토리가 생성되어 있다.  ss

 $ ls /data2/cassandra/data/google/activity_history-e37110b0b41c11e583234b983626f83b/snapshots/
1485312417477

해당 파일로 복구할 수 있다. 

복구는 sstableloader를 사용한다. 
http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/tools/toolsBulkloader_t.html




Posted by '김용환'
,

export -p

unix and linux 2017. 1. 31. 10:14



export -p를 실행하면 쉘에서 export 변수와 export 변수의 값을 나열한다.



$ export –p

export LOGNAME=samuel.kim

export PATH=/bin:/usr/bin:.

export TIMEOUT=600

export TZ=EST5EDT


$ export xxx=1


$ export –p

export LOGNAME=samuel.kim

export PATH=/bin:/usr/bin:.

export TIMEOUT=600

export TZ=EST5EDT

export xxx=1


Posted by '김용환'
,


리눅스의 PS1은 현재 쉘의 앞부분을 출력할 때 유용하게 사용할 수 있다.


[~] echo :$PS1:

:[\w]\[\033[00m\] :


$ PS1=" \"$PWD\" "

 "/Users/samuel.kim"


"/Users/samuel.kim" PS1="$ "

$


$ PS1="명령 내려주세요 $ "

명령 내려주세요 $

명령 내려주세요 $


$ PS1="\H $ "

google-MacBook-Air-100.local $

google-MacBook-Air-100.local $





리눅스의 PS2는 멀티 커맨드 라인에 사용되는 문자로 사용된다.


$ echo :$PS2:

:> :


$  for x in 10 20 30

> do

> echo $x

> done

10

20

30


$ for x in 10 20 30

 do

 echo $x

 done

10

20

30




자세한 내용은 man bash의 prompting 섹션에 설명되어 있다. 



$ man bash



PROMPTING

       When executing interactively, bash displays the primary prompt  PS1

       when  it  is  ready to read a command, and the secondary prompt PS2

       when it needs more input to complete a command.  Bash allows  these

       prompt strings to be customized by inserting a number of backslash-

       escaped special characters that are decoded as follows:

              \a     an ASCII bell character (07)

              \d     the date in "Weekday Month Date" format  (e.g.,  "Tue

                     May 26")

              \D{format}

                     the format is passed to strftime(3) and the result is

                     inserted into the  prompt  string;  an  empty  format

                     results  in  a  locale-specific  time representation.

                     The braces are required

              \e     an ASCII escape character (033)

              \h     the hostname up to the first `.'

              \H     the hostname

              \j     the number of jobs currently managed by the shell

              \l     the basename of the shell's terminal device name

              \n     newline

              \r     carriage return

              \s     the name of the shell, the basename of $0  (the  por-

                     tion following the final slash)

              \t     the current time in 24-hour HH:MM:SS format

              \T     the current time in 12-hour HH:MM:SS format

              \@     the current time in 12-hour am/pm format

              \A     the current time in 24-hour HH:MM format

              \u     the username of the current user

              \v     the version of bash (e.g., 2.00)




'unix and linux' 카테고리의 다른 글

[shell] 중괄호와 널에 대한 기본 문자열  (0) 2017.02.02
export -p  (0) 2017.01.31
echo 이스케이프 - \c  (0) 2017.01.23
echo 와 >& 팁  (0) 2017.01.19
네트워크 카드의 네트워크 트래픽 확인하기 - iftop  (0) 2017.01.19
Posted by '김용환'
,