cassandra 커밋 로그 동기화 기간에 따르면 ... 데이터는 먼저 os 버퍼로 이동 한 다음 os 버퍼에서 커밋 로그 동기화 기간을 기준으로 버퍼 데이터가 동기화되어 디스크의 로그 파일을 커밋합니다. 기본 동기화 기간은 10 초입니다. 서버가 10 초 내에 다운되면 어떻게됩니까? 데이터가 손실 되나요? 하지만 클라이언트가 성공으로 응답을 얻었습니다. 데이터가 os 버퍼 및 memtable의 commitlog 버퍼에 기록됩니다.하지만 결국 10 초 동안 시스템이 다운 되었기 때문에 데이터가 손실됩니다 ... 뭔가 빠졌습니까?Commitlog 동기화 기간
(면책 조항 : 나는 해요 ScyllaDB 직원)
내가 무엇을 누락하는 데이터가 디스크과 동시에 memtable에 을 commitlog을 작성, 당신은 RF를 사용하는 가정 것을> 한 생각 특정 노드가 손상 되더라도 CL> 1 (예 : 정족수) 이상인 다른 복제본은 나중에 데이터를 복구 할 수 있습니다.
RF> 1 및 CL = ONE를 사용하는 경우 복제본이 동기화되기 전에 노드가 손상되어 데이터가 손실 될 가능성이 있습니다.
전체 클러스터가 다운되거나 실제로 단일 노드 클러스터의 경우 클라이언트가 SUCCESS ACK를 다시받을 수 있지만 데이터는 손실됩니다.
당신은 더 나은 이해를 위해 실라 아키텍처 문서를 확인하실 수 있습니다 : 당신은 아무것도 누락되지 않습니다
. Cassandra와 Scylla와 같은 데이터베이스는 실패시 가용성에 대한 일관성을 유지할뿐만 아니라 Postgres와 같은 전통적인 데이터베이스와 마찬가지로 성능에 대한 내구성도 상쇄합니다. commitlog_sync 옵션을 batch으로 변경하거나 commitlog_sync_period_in_ms을 줄일 수 있습니다. 이 작업을 수행하는 경우 커밋 로그를 데이터 디렉토리가 아닌 다른 미디어에 저장하는 것이 가장 좋습니다.
내구성은 지속성을 통해뿐만 아니라 복제를 통해도 지속될 수 있다는 이유가 있습니다. 일반적인 Cassandra/Scylla 사용자는 일반적으로 RF = 3을 가지며 일관성 수준이 QUORUM으로 작성되므로 실제로 데이터를 잃어 버리기 위해 여러 대의 컴퓨터에서 조정 실패가 필요합니다.
단일 노드 클러스터의 경우 또는 rf = 1 인 클러스터의 사용자가 잘못되었으므로 사용자는 성공을 얻었지만 실제로 실패했으며 데이터가 손실되었습니다 ... –
RF> 1이고 나는 그것을 명시 적으로 썼다. 나는 더 많은 정보를 추가했다. – TomerSan
@RupeshMukherjee rf = 1의 경우 노드의 영구적 인 충돌로 인해 데이터가 영구적으로 손실되며 이는 물론 10 초의 데이터를 손실하는 것보다 훨씬 심각합니다. 이것이 카산드라의 실제 배치에서 rf = 1을 사용하지 않는 이유입니다 (데이터가 임시적인 경우는 제외). – nyh