[cassandra] node repair 처리 방식

대용량 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

성공