나는이 Mongo몇 세컨더리으로 복제 세트를. 보조 인스턴스를 호스팅하는 상자에서 데이터베이스가 충돌하여 손실되었습니다.
보조 Mongo인스턴스를 다시 시작 했는데 이제 STARTUP2에서 12 시간 이상 멈췄습니다. 말이 되나요? 문서 Mongo가 RECOVERING 상태로 들어가기 전에 짧은 시간 동안 STARTUP2에 있어야 한다고 말합니다.
STARTUP2는 정확히 무엇을 의미합니까? 기본 데이터베이스에서 데이터베이스를 복사하고 있습니까? Mongo가 Linux에서 실행되고 있다고 가정하면 어떻게 확인할 수 있습니까?
답변:
eoinbrazil의 대답은 부분적으로 잘못되었습니다. 새 노드는 오랫동안 STARTUP2에있을 수 있습니다. 게시 된 링크는 다음과 같습니다.
mongod가 해당 구성원의 구성로드를 완료하자마자 복제본 세트의 각 구성원이 STARTUP2 상태가되고, 이때 복제본 세트의 활성 구성원이됩니다. 그런 다음 멤버는 초기 동기화를 수행할지 여부를 결정합니다. 멤버가 초기 동기화를 시작하면 모든 데이터가 복사되고 모든 인덱스가 작성 될 때까지 멤버가 STARTUP2에 남아 있습니다. 이후 멤버가 RECOVERING으로 전환됩니다.
700GB 모음을 관리하고 있으며 새 노드를 추가해도 STARTUP2 상태는 24 시간 이상 유지됩니다. 그러나 데이터베이스가 커지는 지 확인하여 문제가 있는지 확인할 수 있습니다. 새 노드에서 데이터베이스의 크기를 볼 수 있습니다.
show databases또는 데이터 디렉토리를 관찰하여 여전히 증가하고 있는지 확인할 수 있습니다. (리눅스에서는 ls, df, du, iotop 등의 명령으로 ....)
STARTUP2 상태는 노드가 투표 할 수 없음을 의미합니다. MongoD 프로세스가 구성로드를 완료하면 RS 구성원이이 상태로 전환됩니다. 이 상태에서 구성원은 내부 복제 작업을 처리하기 위해 스레드를 만들었지 만 아직 상태를 복구 중으로 변경 한 후 2 차로 변경하지 않았습니다 ( [상태 및 문서의 세부 정보] 참조) .
노드가 잠시 동안이 상태에 있었던 경우 이상한 동작이 발생합니다. 로그가없는 이유를 판별하기 위해 로그없이 분석하는 것은 거의 불가능합니다. rs.status () 및 db.printSlaveReplicationInfo ()를 실행하면 노드의 로컬 그림에 대한 세부 정보가 제공됩니다.
이 문제를 해결하는 일반적인 방법은 노드를 종료하고 해당 데이터 파일 (dbpath에있는 파일)을 지우고 다시 시작하는 것입니다. 초기 동기화 프로세스가 다시 시작되고 SECONDARY로 이동해야합니다. STARTUP2에 다시 멈춘 경우에는 원인에 대한 자세한 정보를 수집하기 위해 로그를 살펴 봐야합니다. 원인은 다양하지만 비정상적인 네트워크 또는 일부 로컬 리소스 경합입니다.
한 가지 주목할 점은 초기 동기화가 진행되는 동안 노드는 STARTUP2에 유지되므로 동기화되는 데이터의 양에 따라 상당한 시간 (잠재적으로)이 될 수 있습니다.
db.stats데이터베이스 에서 볼 수 있듯이 증가하고 있습니다. 로그는 일부 개체를 말합니다 cloned. 여전히이 문제의 가능한 원인을 찾고 있습니다.
ping호스트 사이의 Mongo 2.4.6 은 Ok입니다.
show databases실패not master and slaveOk=false