제목에 명시된 대로 Cassandra 클러스터에 문제가 있습니다. 있다9노드와복제 인자 3사용하여네트워크토폴로지전략. 모두 동일한 DC 및 랙에 있습니다. 카산드라 버전은3.11.4(3.11.10에 이전 예정). 인스턴스에는CPU 4개그리고32GB RAM. (8 CPU로 이동할 계획)
클러스터에서 복구를 실행하려고 할 때마다(노드 중 하나에서 Cassandra Reaper를 사용하여) 프로세스 어딘가에서 노드 하나가 손실됩니다. 신속하게 수리를 중지하고 노드에서 Cassandra 서비스를 다시 시작한 후 링에 합류할 때까지 기다립니다. 그래서 요즘은 수리를 절대 할 수 없습니다.
문제를 관찰한 결과 이 문제는 일부 노드의 높은 CPU 사용량으로 인해 발생한다는 것을 깨달았습니다.(정확히 3). 아래에서 1주 간격 그래프를 볼 수 있습니다.기복은 앱 사용으로 인해 발생합니다. 아침에는 기온이 매우 낮습니다.
각 노드에서 실행 중인 프로세스를 비교했는데 높은 CPU 노드에는 추가 항목이 없습니다. 구성을 비교해 봤습니다. 그것들은 동일합니다. 어떤 차이점도 찾을 수 없었습니다.
또한 이 노드가 트래픽의 대부분을 차지하는 노드라는 것도 깨달았습니다. 아래의 1주 간격 그래프를 참조하세요.전송된 바이트와 수신된 바이트 모두입니다.
나는 약간의 연구를 했다. 나는 찾았다이것스레드를 종료하고 마지막에는 dynamic_snitch: falseCassandra 구성으로 설정하는 것이 좋습니다. 나는 우리의 스니치 전략을 살펴보았습니다.험담재산파일밀고. 실제로 이 전략은 제대로 작동해야 하지만 그렇지 않은 것 같습니다.
밀고자의 임무는 Cassandra가 요청을 효율적으로 라우팅할 수 있도록 네트워크 토폴로지에 대한 정보를 제공하는 것입니다.
이 문제의 원인이 될 수 있는 유일한 관찰은 다음과 같은 파일이 있다는 것입니다.카산드라 토폴로지.속성이는 구체적으로제거하라고 함GossipingPropertyFileSnitch를 사용하는 경우
로컬 노드의 랙 및 데이터 센터는 cassandra-rackdc.properties에 정의되어 있으며 gossip을 통해 다른 노드로 전파됩니다. cassandra-topology.properties가 존재하는 경우 대체 항목으로 사용되어 PropertyFileSnitch에서 마이그레이션할 수 있습니다.
이 파일이 문제의 원인이라는 확실한 증거를 찾을 수 없기 때문에 이 파일을 제거하지 않았습니다. 이에 대한 지식이 있거나 내 문제에 대한 다른 이유가 있으면 도움을 주시면 감사하겠습니다.