일반적으로 잘 설계된 클러스터는 손대지 않고도 몇 년 동안 살 수 있습니다. 몇 년 동안 진행된 클러스터가있었습니다. 그러나 다음은 몇 가지 지침입니다.
모니터링은 매우 중요합니다.
1) 대기 시간을 모니터링합니다. 지연 시간을 추적하려면 opscenter 또는 자주 사용하는 메트릭 도구를 사용하십시오. 지연 시간 증가는 GC 일시 중지 (쓰기 작업보다 읽기 작업에서 더 흔함), 안정적인 문제 등을 포함하여 문제가 발생할 수 있습니다.
2) 안정적인 카운트를 모니터링합니다. 압축을 오버런하면 SSTable 수가 증가합니다 (각 sstable은 정확히 한 번 작성됩니다-삭제는 압축을 통해 이전 sstable을 새로운 sstable로 결합하여 처리됩니다).
3) 노드 상태 변경 (업 / 다운 등)을 모니터링합니다. 노드 플랩이 보이면 정상이 아니므로 조사하십시오.
4) 디스크 사용량을 추적하십시오. 일반적으로 50 % 미만을 유지해야합니다 (특히 STCS 압축을 사용하는 경우).
정기적으로 수행하지 말아야 할 몇 가지 기본 사항이 있습니다.
1) 명시 적으로 실행하지 마십시오 nodetool compact. 치명적이지는 않지만 매우 큰 마구간을 생성하여 압축에 계속 참여할 가능성이 적습니다. 반드시 계속 실행할 필요는 없지만 때로는 삭제 / 덮어 쓴 데이터를 제거하는 데 도움이 될 수 있습니다.
2) nodetool repair일반적으로 권장됩니다 gc_grace_seconds(기본적으로 10 일). 덜 중요한 워크로드가 있습니다. 수리가 필요한 가장 큰 이유는 삭제 마커 ( tombstones)가 만료되기 전에 전송되도록 gc_grace_seconds하는 것입니다. 수리하지 않고!). 삭제를 발행하지 않고 충분한 일관성 수준 (예 : QUORUM에서 읽기 및 쓰기)으로 쿼리하면 실제로 수리하지 않고 생활 할 수 있습니다.
3) 수리하려는 경우 증분 수리 사용을 고려하고 한 번에 작은 범위를 수리하십시오.
4) 압축 전략이 중요합니다. STCS는 쓰기에 좋고 LCS는 읽기에 좋습니다. DTCS에는 몇 가지 단점이 있습니다.
5) 데이터 모델이 중요합니다. 인덱스되지 않은 쿼리가 큰 테이블에 도달 할 때 RDBMS / SQL 환경이 문제를 일으키는 것처럼 Cassandra는 매우 큰 행 / 파티션에 문제가 될 수 있습니다.
6) 스냅 샷이 저렴합니다. 매우 싸다. 거의 즉각적인 하드 링크만으로 거의 디스크 공간이 거의 들지 않습니다. 버전, 특히 주요 버전을 업그레이드하기 전에 스냅 샷을 사용하십시오.
7) 삭제에주의하십시오. # 2에서 알 수 있듯이 delete는 디스크에 더 많은 데이터를 만들고 AT LEAST를 위해 비워 두지 않습니다 gc_grace_seconds.
다른 모든 것이 실패하면 :
나는 Prod의 Cassandra가 모든 규모의 클러스터를 관리하기 위해 전담 머리가 필요하다고 제안하는 기사를 보았습니다. 반드시 사실인지는 모르겠지만 걱정되는 경우 타사 컨설턴트를 고용하고 싶을 수도 있습니다 (TheLastPickle, Pythian ) 또는 지원 계약 (Datastax)이있어 안심할 수 있습니다.