최근 몇 가지 데이터가 사라집니다. 우리의 데이터는 로그 데이터입니다. 복합 키 (id, requestdate)가 있습니다.일관성을 1로 설정하면 데이터가 사라집니다.
우리 프로그램은 지속적으로 새로운 레코드를 C *에 삽입합니다. 삭제 작업이 없습니다. 데이터가 성공적으로 작성되었으며 데이터를 선택할 수있었습니다. 그러나 얼마 후 일부 ID에 대한 데이터가 사라졌습니다.
우리가 생각할 수있는 한 가지 이유는 kundera cassandra 드라이버를 사용하는 것입니다.이 드라이버에는 기본 write consistency_level이 ONE으로 설정되어 있습니다. 시스템 로그에 오류가 없습니다.
이 문제는 write consistency_level 때문에 발생한다고 생각하십니까? 감사.
편집 : 잠시 동안 노드 복구를 실행하지 않았습니다. 이로 인해 데이터가 사라질 수 있습니까?
ONE의 일관성은 하나의 복제본 노드에서 쓰기가 완료 되 자마자 상태가 반환됨을 나타냅니다. 쓰기 자체가 결코 성공하지 못한다면, 데이터는 카산드라에서 사라져서는 안됩니다.
다운 노드로 인해 삽입이 실패한 경우. 이 경우 암시 된 핸드 오프를 확인하십시오. 암시 된 손을 놓을 시간을 늘리십시오.
복제 요소 란 무엇입니까? 다운 된 노드 때문에 서비스가 손실되지 않도록 더 큰 숫자로 늘리십시오.
쓰기 직후에 읽은 다음 다른 복제본 중 하나를 코디네이터로 사용하여 데이터를 아직 검색하지 못하게 될 가능성이 있습니다. 읽기에 일관성이 필요하면 CL.QUORUM을 사용하여 읽기/쓰기를 수행하십시오. 이 창은 ~ 500ms 정도 지나간 것으로 가정하는 것이 안전합니다. Eventual Consistency != Hopeful Consistency
우리의 문제는 쓰기가 성공적이었으며 쓰기 후 읽기가 데이터를 표시했다는 것입니다. 하루 후 또는 일부 시간이 지나면 일부 ID (파티션 키) 아래의 데이터가 사라지고 노드에서 선택할 수 없습니다. –
내 추측에 따르면 데이터를 삭제하거나 TTL을 설정하는 것이 있습니다. 또 다른 가능성은 응용 프로그램이 잘못된 파티션 키를 사용하려고 시도하는 것입니다. –
데이터에 TTL 설정이 없습니다. 잘못된 파티션 키를 설정하면 어떻게 될 수 있습니까? 감사. –
쓰기 성공 데이터를 작성한 후 데이터가 선택되어 표시되었습니다. 복제는 3입니다. 우리가 발견 한 또 다른 문제점은 nodetool 수리가 잠시 동안 실행되지 않았다는 것입니다. 데이터 손실의 경우 최신 데이터뿐만 아니라 하나의 ID (파티션 키) 아래에있는 모든 데이터가 손실됩니다. 감사. –
혹시 키 공간에 TTL을 사용할 가능성이 있습니까? Nodetool 수리는 적어도 한 번 수동으로 gc_grace_seconds를 실행해야한다는 것을 알고 있습니다. –
하나의 ID가 특정 노드에 할당되어 있는지 확인하십시오. 또 다른 가능성은 시간 소인이 될 수 있습니다. 여기서 특정 데이터는 더 오래된 시간 소인이있는 값으로 겹쳐 쓰지 않습니다. 또한, 당신은 nodetool flush를 실행 해보고, {가능성없는 시나리오}를 새로 고칠 수도 있습니다. –