"손실된 데이터"와 청크 크기는 서로 관련이 없으며 직접적인 논리적 연결이 없습니다. 이 두 가지를 누가 합쳐서 알려줄지 모르겠습니다. 데이터 손실이 구체적으로 어떤 시나리오를 의미하는지 모르기 때문에 제가 알고 있는 내용을 바탕으로 귀하에게 유용할 수 있는 몇 가지 답변을 드리겠습니다. 청크사이즈 문제가 아닌 데이터 손실 문제를 걱정하시는 것 같습니다. 게다가 일반적으로 청크사이즈를 기본값으로 두면 문제가 없으므로 청크사이즈 문제는 생략하도록 하겠습니다. '데이터 손실'에 대해 설명해주세요. 어떤 데이터베이스에서든 이유 없이 데이터가 손실되는 것은 용납할 수 없습니다. 그래서 데이터가 손실되는 상황이 있습니다.
정전, 하드웨어 손상, 네트워크 장애 등 거부할 수 없는 요인이 있습니다.
구성 이유
소프트웨어에 심각한 버그가 있습니다. 어쨌든 1에 대해서는 할 수 있는 일이 없습니다. 이는 ReplicaSet의 복제 기능을 통해 최소화되어야 합니다.
포인트 2, 저널을 열지 않은 경우(기본적으로 열려 있음) 정전 또는 프로그램 충돌이 발생하면 30ms 이내에 데이터가 손실될 수 있습니다. 데이터가 매우 중요하고 30ms 손실을 허용할 수 없는 경우 j 매개변수를 켜십시오: mongodb://ip:port/db?replicaSet=rs&j=1 (위 매개 변수는 코드를 통해 전달될 수도 있습니다. 단일 요청의 세분성에 따라 지정하세요. 사용 중인 드라이버 설명서를 참조하세요.) 이 매개 변수는 저널이 디스크에 기록될 때까지 데이터 쓰기가 차단되도록 합니다. 그런데 데이터를 디스크에 저장하면 안전하다고 생각하시나요? 이는 분산 환경이며 단일 시스템의 데이터 보안이 클러스터를 나타내지 않는다는 점을 기억하십시오. 따라서 긴급 상황이 발생하면 저널을 배치했지만 복제본의 다른 노드에 복사할 시간이 없었습니다. 그러면 primary은 적시에 삭제되고 다른 노드는 선택을 통해 새로운 primary이 됩니다. 이때 롤백(rollback)이라는 흥미로운 상황이 발생하게 됩니다. 관심 있는 분들은 읽어보시면 됩니다. 물론 복사 속도는 일반적으로 매우 빠르며 롤백은 매우 드뭅니다. 글쎄, 여전히 충분히 안전하지 않다고 느낄 수 있다면 사용할 수 있는 w 매개변수가 있습니다: mongodb://ip:port/db?replicaSet=rs&j=1&w=1 w 매개변수 이를 통해 데이터가 여러 노드(w=1/2/3...n)에 도달할 때까지 쓰기 작업이 차단됩니다. 이거 안전한가요? 죄송합니다. 특히 운이 좋지 않은 상황(복권을 사야 하는 경우)에서 데이터를 두 개 이상의 노드에 복사했습니다. 이 노드 집합이 동시에 실패하면 어떻게 될까요? 따라서 w=다수(다수)가 됩니다. 클러스터가 대부분의 노드를 잃으면 읽기 전용이 되므로 새 데이터가 기록되지 않으며 롤백도 발생하지 않습니다. 모든 것이 복원되어도 데이터는 그대로 유지됩니다. 위는 데이터 손실이 발생하는 몇 가지 상황입니다. w와 j의 구성은 데이터 보안을 보장하면서 확실히 쓰기 효율성에 큰 영향을 미칠 것이라고 상상할 수 있습니다. 이는 실제로 데이터 손실 허용 범위에 따라 사용자 정의하는 정책이어야 하며 버그로 간주되지 않습니다. 또 다른 생각: 저는 커뮤니티에서 이런 일을 좋아하는 사람들을 자주 만납니다.
으아아아
저한테 물어보면 그냥 너무 잔인해요. 왜 모기가 나오자마자 대포를 써서 쫓아내나요? 이 경우 데이터 손실은 당연하다고 할 수 있습니다. 사실
으아아아
은 안전하지만 -9는 귀하의 잘못입니다.
3번 항목의 경우, mongodb 3.0.8~3.0.10 개발 과정에서 데이터 손실을 일으키는 버그가 가장 많이 발생하는 부분이므로 이 버전은 피하세요. 그렇다면 어떤 소프트웨어 개발 프로세스에 문제가 없습니까? 3.0.11은 3.0.10에서 문제가 발견된 날 출시되었는데, 이미 복구 속도가 매우 빨랐다.
그렇습니다. 너무 많은 말을 했더니 질문자에게 도움이 될지 모르겠네요. 문제를 최대한 명확하게 설명하세요. 그렇지 않으면 어떤 시나리오에서 어떤 종류의 문제가 발생했는지 저처럼 추측할 수 있을 뿐입니다. 가장 가능성이 높은 상황은 다음과 같습니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
"손실된 데이터"와 청크 크기는 서로 관련이 없으며 직접적인 논리적 연결이 없습니다. 이 두 가지를 누가 합쳐서 알려줄지 모르겠습니다. 데이터 손실이 구체적으로 어떤 시나리오를 의미하는지 모르기 때문에 제가 알고 있는 내용을 바탕으로 귀하에게 유용할 수 있는 몇 가지 답변을 드리겠습니다.
청크사이즈 문제가 아닌 데이터 손실 문제를 걱정하시는 것 같습니다. 게다가 일반적으로 청크사이즈를 기본값으로 두면 문제가 없으므로 청크사이즈 문제는 생략하도록 하겠습니다.
'데이터 손실'에 대해 설명해주세요. 어떤 데이터베이스에서든 이유 없이 데이터가 손실되는 것은 용납할 수 없습니다. 그래서 데이터가 손실되는 상황이 있습니다.
정전, 하드웨어 손상, 네트워크 장애 등 거부할 수 없는 요인이 있습니다.
구성 이유
소프트웨어에 심각한 버그가 있습니다.
어쨌든 1에 대해서는 할 수 있는 일이 없습니다. 이는 ReplicaSet의 복제 기능을 통해 최소화되어야 합니다.
포인트 2, 저널을 열지 않은 경우(기본적으로 열려 있음) 정전 또는 프로그램 충돌이 발생하면 30ms 이내에 데이터가 손실될 수 있습니다. 데이터가 매우 중요하고 30ms 손실을 허용할 수 없는 경우 j 매개변수를 켜십시오:
으아아아mongodb://ip:port/db?replicaSet=rs&j=1
(위 매개 변수는 코드를 통해 전달될 수도 있습니다. 단일 요청의 세분성에 따라 지정하세요. 사용 중인 드라이버 설명서를 참조하세요.)
이 매개 변수는 저널이 디스크에 기록될 때까지 데이터 쓰기가 차단되도록 합니다.
그런데 데이터를 디스크에 저장하면 안전하다고 생각하시나요? 이는 분산 환경이며 단일 시스템의 데이터 보안이 클러스터를 나타내지 않는다는 점을 기억하십시오. 따라서 긴급 상황이 발생하면 저널을 배치했지만 복제본의 다른 노드에 복사할 시간이 없었습니다. 그러면
primary은 적시에 삭제되고 다른 노드는 선택을 통해 새로운primary이 됩니다. 이때 롤백(rollback)이라는 흥미로운 상황이 발생하게 됩니다. 관심 있는 분들은 읽어보시면 됩니다. 물론 복사 속도는 일반적으로 매우 빠르며 롤백은 매우 드뭅니다. 글쎄, 여전히 충분히 안전하지 않다고 느낄 수 있다면 사용할 수 있는 w 매개변수가 있습니다:mongodb://ip:port/db?replicaSet=rs&j=1&w=1
w 매개변수 이를 통해 데이터가 여러 노드(w=1/2/3...n)에 도달할 때까지 쓰기 작업이 차단됩니다.
이거 안전한가요? 죄송합니다. 특히 운이 좋지 않은 상황(복권을 사야 하는 경우)에서 데이터를 두 개 이상의 노드에 복사했습니다. 이 노드 집합이 동시에 실패하면 어떻게 될까요? 따라서 w=다수(다수)가 됩니다. 클러스터가 대부분의 노드를 잃으면 읽기 전용이 되므로 새 데이터가 기록되지 않으며 롤백도 발생하지 않습니다. 모든 것이 복원되어도 데이터는 그대로 유지됩니다.
위는 데이터 손실이 발생하는 몇 가지 상황입니다. w와 j의 구성은 데이터 보안을 보장하면서 확실히 쓰기 효율성에 큰 영향을 미칠 것이라고 상상할 수 있습니다. 이는 실제로 데이터 손실 허용 범위에 따라 사용자 정의하는 정책이어야 하며 버그로 간주되지 않습니다.
또 다른 생각: 저는 커뮤니티에서 이런 일을 좋아하는 사람들을 자주 만납니다.
저한테 물어보면 그냥 너무 잔인해요. 왜 모기가 나오자마자 대포를 써서 쫓아내나요? 이 경우 데이터 손실은 당연하다고 할 수 있습니다. 사실
으아아아은 안전하지만 -9는 귀하의 잘못입니다.
3번 항목의 경우, mongodb 3.0.8~3.0.10 개발 과정에서 데이터 손실을 일으키는 버그가 가장 많이 발생하는 부분이므로 이 버전은 피하세요. 그렇다면 어떤 소프트웨어 개발 프로세스에 문제가 없습니까? 3.0.11은 3.0.10에서 문제가 발견된 날 출시되었는데, 이미 복구 속도가 매우 빨랐다.
그렇습니다. 너무 많은 말을 했더니 질문자에게 도움이 될지 모르겠네요. 문제를 최대한 명확하게 설명하세요. 그렇지 않으면 어떤 시나리오에서 어떤 종류의 문제가 발생했는지 저처럼 추측할 수 있을 뿐입니다. 가장 가능성이 높은 상황은 다음과 같습니다.