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


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 '김용환'
,

cassandra table 변경

cassandra 2017. 1. 26. 13:17


TTL이 있고 삭제가 많은 카산드라 테이블에 대해서 

너무 낮은 gc_grace_seconds는 read 성능을 떨어뜨리게 된다. 

그렇다고 적당한 값으로 두기에는 언젠가는 compaction으로 cassandra가 gc로 인해 hang이 될 수 있다. 


적당히 타협하기 위해 gc_grace_seconds의 기본값을 수정해 하루로 변경했다.


변경 방법은 cqlsh에 진행하며 다음 커맨드를 사용한다.


cqlsh:cluster_name> alter table google_plus.recent_relation  with GC_GRACE_SECONDS = 86400;


확인은 다음과 같이 진행한다. 


cqlsh:cluster_name> describe google_plus.recent_relation


좀 더 응용을 한다면, with 에 속성을 주면 테이블 속성을 변경할 수 있다. 





참고로 

alter 만 된다고 생각하는 분들이 있는데, 테이블 생성할 때부터 compaction 정책을 생성할 수 있다.



CREATE TABLE google_plus. recent_relation (

  block_id uuid,

  species text,

  alias text,

  population varint,

  PRIMARY KEY (block_id)

) WITH compression =

    { 'sstable_compression' : 'DeflateCompressor', 'chunk_length_kb' : 64 }

  AND compaction =

    { 'class' : 'LeveledCompactionStrategy'};


Posted by '김용환'
,

repair 종료하는 방법을 소개하고 있다.


https://docs.datastax.com/en/cassandra/2.1/cassandra/tools/toolsStop.html


$ nodetool stop -- COMPACTION

$ nodetool stop -- VALIDATION



jsoncole 등을 이용해 cassandra의 jmx로 접속한 후, org.apache.cassandra.db:type=StorageService를 실행한다.


jmx 프로그램을 이용해서 실행할 수 있다. 

아래 url에서 jmx client 프로그램을 다운받을 수 있다. 

https://sourceforge.net/projects/cyclops-group/files/jmxterm


$ wget -q -O jmxterm.jar http://downloads.sourceforge.net/cyclops-group/jmxterm-1.0-alpha-4-uber.jar

$ java -jar ./jmxterm.jar

$ open server-name:7199

$ bean org.apache.cassandra.db:type=StorageService

$ run forceTerminateAllRepairSessions




* 참고로.

cassandra의 repair 정책에 따라 다 끝낼 때까지 진행될 수도 있고,

특정 토큰에만 repair를 취소할 수 있다. (즉 다음 토큰으로 repair를 넘어가는 현상을 볼 수 있다)


계속 모니터링하면서 상황에 따라 유연하게 대처할 필요가 있다. 



Posted by '김용환'
,




node repair를 실행할 때 관련 로그는 아래 url에서 설명하고 있다. 


http://www.datastax.com/dev/blog/interpreting-repair-logs



실제로 nodetool repair를 실행하면 datastax url과 설명한 것과 비슷하게 나타난다. 공부하는데 도움될 것 같다.


1. RepairJob.java : merkle 트리 구성 요청을 보낸다.

2. RepairSession.java : merkle 트리 요청을 받는다.

3. Difference.java : 일치(consistency), 불일치(inconsistency)를 확인한다.

4. StreamingRepairTask.java : repair 스트림 상태를 알린다.

5. RepairSession.java : 싱크가 완료됨을 알린다.

6. StorageService.java : (발견하지 못했지만) repair 세션 범위를 알린다






아래는 실제 로그이다. 약간 차이가 나지만 큰 차이는 없다.


$ nodetool repair -- google_plus media

...


INFO  [RepairJobTask:3] 2020-12-31 14:25:30,934 RepairJob.java:163 - [repair #b033fec0-e2be-11e6-bcf3-edb4e9adcd85] requesting merkle trees for media (to [/1.1.1.1, /1.1.1.2, /1.1.1.3])

INFO  [AntiEntropyStage:1] 2020-12-31 14:25:30,939 RepairSession.java:171 - [repair #b033fec0-e2be-11e6-bcf3-edb4e9adcd85] Received merkle tree for media from /1.1.1.1

INFO  [AntiEntropyStage:1] 2020-12-31 14:25:30,944 RepairSession.java:171 - [repair #b033fec0-e2be-11e6-bcf3-edb4e9adcd85] Received merkle tree for media from /1.1.1.2

INFO  [AntiEntropyStage:1] 2020-12-31 14:25:30,949 RepairSession.java:171 - [repair #b033fec0-e2be-11e6-bcf3-edb4e9adcd85] Received merkle tree for media from /1.1.1.3

INFO  [RepairJobTask:2] 2020-12-31 14:25:30,949 Differencer.java:67 - [repair #b033fec0-e2be-11e6-bcf3-edb4e9adcd85] Endpoints /1.1.1.1 and /1.1.1.3 are consistent for media

INFO  [RepairJobTask:1] 2020-12-31 14:25:30,949 Differencer.java:67 - [repair #b033fec0-e2be-11e6-bcf3-edb4e9adcd85] Endpoints /1.1.1.2 and /1.1.1.3 are consistent for media

INFO  [RepairJobTask:3] 2020-12-31 14:25:30,949 Differencer.java:67 - [repair #b033fec0-e2be-11e6-bcf3-edb4e9adcd85] Endpoints /1.1.1.1 and /1.1.1.2 are consistent for media

INFO  [AntiEntropySessions:18] 2020-12-31 14:25:30,949 RepairSession.java:260 - [repair #b037cf50-e2be-11e6-bcf3-edb4e9adcd85] new session: will sync /1.1.1.3, /1.1.1.4, /1.1.1.5 on range (-7269152197870639307,-7265094729233520360] for google_plus.[media]

INFO  [AntiEntropyStage:1] 2020-12-31 14:25:30,949 RepairSession.java:237 - [repair #b033fec0-e2be-11e6-bcf3-edb4e9adcd85] media is fully synced

INFO  [AntiEntropySessions:20] 2020-12-31 14:25:30,949 RepairSession.java:299 - [repair #b033fec0-e2be-11e6-bcf3-edb4e9adcd85] session completed successfully

INFO  [RepairJobTask:2] 2020-12-31 14:25:30,960 RepairJob.java:163 - [repair #b037cf50-e2be-11e6-bcf3-edb4e9adcd85] requesting merkle trees for media (to [/1.1.1.4, /1.1.1.5, /1.1.1.3])

INFO  [AntiEntropyStage:1] 2020-12-31 14:25:30,961 RepairSession.java:171 - [repair #b037cf50-e2be-11e6-bcf3-edb4e9adcd85] Received merkle tree for media from /1.1.1.4

INFO  [AntiEntropyStage:1] 2020-12-31 14:25:30,962 RepairSession.java:171 - [repair #b037cf50-e2be-11e6-bcf3-edb4e9adcd85] Received merkle tree for media from /1.1.1.5

INFO  [AntiEntropyStage:1] 2020-12-31 14:25:30,963 RepairSession.java:171 - [repair #b037cf50-e2be-11e6-bcf3-edb4e9adcd85] Received merkle tree for media from /1.1.1.3

INFO  [RepairJobTask:2] 2020-12-31 14:25:30,963 Differencer.java:67 - [repair #b037cf50-e2be-11e6-bcf3-edb4e9adcd85] Endpoints /1.1.1.4 and /1.1.1.5 are consistent for media

INFO  [RepairJobTask:1] 2020-12-31 14:25:30,963 Differencer.java:67 - [repair #b037cf50-e2be-11e6-bcf3-edb4e9adcd85] Endpoints /1.1.1.4 and /1.1.1.3 are consistent for media

INFO  [RepairJobTask:3] 2020-12-31 14:25:30,963 Differencer.java:67 - [repair #b037cf50-e2be-11e6-bcf3-edb4e9adcd85] Endpoints /1.1.1.5 and /1.1.1.3 are consistent for media

INFO  [AntiEntropySessions:20] 2020-12-31 14:25:30,963 RepairSession.java:260 - [repair #b039f230-e2be-11e6-bcf3-edb4e9adcd85] new session: will sync /1.1.1.3, /1.1.1.1, /1.1.1.2 on range (4489624031702179489,4492484221112590824] for google_plus.[media]

INFO  [AntiEntropyStage:1] 2020-12-31 14:25:30,963 RepairSession.java:237 - [repair #b037cf50-e2be-11e6-bcf3-edb4e9adcd85] media is fully synced

INFO  [AntiEntropySessions:18] 2020-12-31 14:25:30,963 RepairSession.java:299 - [repair #b037cf50-e2be-11e6-bcf3-edb4e9adcd85] session completed successfully





....


INFO  [RepairJobTask:2] 2020-12-31 14:31:28,036 RepairJob.java:163 - [repair #850e32f0-e2bf-11e6-bcf3-edb4e9adcd85] requesting merkle trees for media (to [/1.1.1.4, /1.1.1.7, /1.1.1.3])

INFO  [AntiEntropyStage:1] 2020-12-31 14:31:28,106 RepairSession.java:171 - [repair #850e32f0-e2bf-11e6-bcf3-edb4e9adcd85] Received merkle tree for media from /1.1.1.4

INFO  [AntiEntropyStage:1] 2020-12-31 14:31:28,177 RepairSession.java:171 - [repair #850e32f0-e2bf-11e6-bcf3-edb4e9adcd85] Received merkle tree for media from /1.1.1.7

INFO  [AntiEntropyStage:1] 2020-12-31 14:31:28,221 RepairSession.java:171 - [repair #850e32f0-e2bf-11e6-bcf3-edb4e9adcd85] Received merkle tree for media from /1.1.1.3

INFO  [RepairJobTask:2] 2020-12-31 14:31:28,221 Differencer.java:74 - [repair #850e32f0-e2bf-11e6-bcf3-edb4e9adcd85] Endpoints /1.1.1.4 and /1.1.1.7 have 2 range(s) out of sync for media

INFO  [RepairJobTask:3] 2020-12-31 14:31:28,221 Differencer.java:67 - [repair #850e32f0-e2bf-11e6-bcf3-edb4e9adcd85] Endpoints /1.1.1.7 and /1.1.1.3 are consistent for media

INFO  [RepairJobTask:1] 2020-12-31 14:31:28,221 Differencer.java:74 - [repair #850e32f0-e2bf-11e6-bcf3-edb4e9adcd85] Endpoints /1.1.1.4 and /1.1.1.3 have 2 range(s) out of sync for media

INFO  [RepairJobTask:2] 2020-12-31 14:31:28,221 StreamingRepairTask.java:81 - [repair #850e32f0-e2bf-11e6-bcf3-edb4e9adcd85] Forwarding streaming repair of 2 ranges to /1.1.1.4 (to be streamed with /1.1.1.7)

INFO  [RepairJobTask:1] 2020-12-31 14:31:28,223 StreamingRepairTask.java:68 - [streaming task #850e32f0-e2bf-11e6-bcf3-edb4e9adcd85] Performing streaming repair of 2 ranges with /1.1.1.4

INFO  [RepairJobTask:1] 2020-12-31 14:31:28,224 ColumnFamilyStore.java:912 - Enqueuing flush of media: 364 (0%) on-heap, 80 (0%) off-heap

INFO  [MemtableFlushWriter:14683] 2020-12-31 14:31:28,224 Memtable.java:347 - Writing Memtable-media@1433910433(0.033KiB serialized bytes, 1 ops, 0%/0% of on/off-heap limit)

INFO  [MemtableFlushWriter:14683] 2020-12-31 14:31:28,224 Memtable.java:382 - Completed flushing /var/lib/cassandra/data/google_plus/media-6c2e8460af9311e69f844b983626f83b/google_plus-media-tmp-ka-2204-Data.db (0.000KiB) for commitlog position ReplayPosition(segmentId=1483928411656, position=2911640)

INFO  [MemtableFlushWriter:14683] 2020-12-31 14:31:28,228 Memtable.java:347 - Writing Memtable-media.friend_profileid_index@1788192341(0.030KiB serialized bytes, 1 ops, 0%/0% of on/off-heap limit)

INFO  [MemtableFlushWriter:14683] 2020-12-31 14:31:28,228 Memtable.java:382 - Completed flushing /var/lib/cassandra/data/google_plus/media-6c2e8460af9311e69f844b983626f83b/google_plus-media.friend_profileid_index-tmp-ka-1997-Data.db (0.000KiB) for commitlog position ReplayPosition(segmentId=1483928411656, position=2911640)

INFO  [RepairJobTask:1] 2020-12-31 14:31:28,232 StreamResultFuture.java:86 - [Stream #852b7ef0-e2bf-11e6-bcf3-edb4e9adcd85] Executing streaming plan for Repair

INFO  [StreamConnectionEstablisher:12] 2020-12-31 14:31:28,232 StreamSession.java:220 - [Stream #852b7ef0-e2bf-11e6-bcf3-edb4e9adcd85] Starting streaming to /1.1.1.4

INFO  [StreamConnectionEstablisher:12] 2020-12-31 14:31:28,233 StreamCoordinator.java:209 - [Stream #852b7ef0-e2bf-11e6-bcf3-edb4e9adcd85, ID#0] Beginning stream session with /1.1.1.4

INFO  [STREAM-IN-/1.1.1.4] 2020-12-31 14:31:28,240 StreamResultFuture.java:166 - [Stream #852b7ef0-e2bf-11e6-bcf3-edb4e9adcd85 ID#0] Prepare completed. Receiving 2 files(80817 bytes), sending 1 files(80161 bytes)

INFO  [StreamReceiveTask:543] 2020-12-31 14:31:28,248 SecondaryIndexManager.java:163 - Submitting index build of [media.friend_profileid_index] for data in SSTableReader(path='/var/lib/cassandra/data/google_plus/media-6c2e8460af9311e69f844b983626f83b/google_plus-media-ka-2205-Data.db'), SSTableReader(path='/var/lib/cassandra/data/google_plus/media-6c2e8460af9311e69f844b983626f83b/google_plus-media-ka-2206-Data.db')





문제가 있었는지 확인하기 위해 로그를 확인하는 방법이다. 


$ grep -r 'Sync failed' /var/log/cassandra/system.log

..


$ grep -i -e "ERROR" -e "WARN" /var/log/cassandra/system.log

..

WARN  [SharedPool-Worker-1] 2020-01-14 13:17:13,272 SliceQueryFilter.java:319 - Read 6 live and 1157 tombstone cells in google_plus.part_of_friend_permission_activities.allow_profile_ids_idx for key: 04727367 (see tombstone_warn_threshold). 200 columns were requested, slices=[04488138:_-04488138:!]

WARN  [SharedPool-Worker-7] 2020-01-14 13:17:13,287 SliceQueryFilter.java:319 - Read 6 live and 1157 tombstone cells in google_plus.part_of_friend_permission_activities.allow_profile_ids_idx for key: 04727367 (see tombstone_warn_threshold). 200 columns were requested, slices=[04488138:_-04488138:!]

java.io.IOException: Error while read(...): 연결 시간 초과

WARN  [SharedPool-Worker-3] 2020-01-17 10:58:03,992 SliceQueryFilter.java:319 - Read 7 live and 1330 tombstone cells in google_plus.part_of_friend_permission_activities.allow_profile_ids_idx for key: 04ee9da7 (see tombstone_warn_threshold). 200 columns were requested, slices=[04f4dfdb:_-04f4dfdb:!]

java.io.IOException: Error while read(...): 연결이 상대편에 의해 끊어짐

java.io.IOException: Error while read(...): 연결이 상대편에 의해 끊어짐

WARN  [SharedPool-Worker-3] 2020-01-24 12:11:57,223 SliceQueryFilter.java:319 - Read 4 live and 1232 tombstone cells in google_plus.part_of_friend_permission_activities.allow_profile_ids_idx for key: 04e66181 (see tombstone_warn_threshold). 200 columns were requested, slices=[04f4dfdb:_-04f4dfdb:!]

WARN  [SharedPool-Worker-4] 2017-01-24 12:11:57,289 SliceQueryFilter.java:319 - Read 4 live and 1232 tombstone cells in google_plus.part_of_friend_permission_activities.allow_profile_ids_idx for key: 04e66181 (see tombstone_warn_threshold). 21 columns were requested, slices=[04f4dfdb:_-04f4dfdb:!]





Posted by '김용환'
,



Troubleshooting Cassandra (J.B. Langston, DataStax) | C* Summit 2016 from DataStax


1



Posted by '김용환'
,


cassandra summit 2016 중 compaction과 tombstone과 관련된 자료 





Deletes Without Tombstones or TTLs (Eric Stevens, ProtectWise) | Cassandra Summit 2016 from DataStax





Cassandra at Instagram 2016 (Dikang Gu, Facebook) | Cassandra Summit 2016 from DataStax



How Cassandra Deletes Data (Alain Rodriguez, The Last Pickle) | Cassandra Summit 2016 from DataStax







Posted by '김용환'
,