새 보조 구성원의 초기 동기화 (STARTUP2)의 색인 작성 단계의 전반적인 진행 상태를 확인하는 좋은 방법은 무엇입니까? 인덱스 구축 단계는 필자의 경우 (며칠) 매우 오랜 시간이 걸리며, 프로세스가 진행되는 곳을 확인하는 것이 좋습니다.STARTUP2 BTree Bottom Up 단계의 전반적인 진행 상황을 확인하는 방법은 무엇입니까?
는 로그 출력은 다음과 같습니다
Tue Jan 27 20:04:45.006 [rsSync] Index: (2/3) BTree Bottom Up Progress: 782212700/946547617 82%
를 지금까지 내가 걱정하고,이이 "일부 개체의 82 %, 알 수없는 크기의 객체의 알 수없는 수 중에서."번역
rs.status()를 사용하여 STARTUP2의 모니터링을 강화하는 장소에서 티켓이 있지만이 진행 상황을 모니터링 할 현재의 방법은 없다 : https://jira.mongodb.org/browse/SERVER-7526 https://jira.mongodb.org/browse/SERVER-7019
말했다 시간 이 단계에서 요구되는 시간은 대략적으로 각 색인에 필요한 색인의 수를 곱한 시간의 함수입니다. 차례로 각 색인에 필요한 시간은 각 색인에있는. 서 수의 함수입니다.
색인을 작성하는 데 걸리는 시간을 측정하는 경우, 색인의 총 문서 수로 나눕니다. 그러면 단일 문서의 색인을 생성하는 속도에 대한 대략적인 아이디어를 얻을 수 있습니다. 그런 다음 모든 인덱스의 총 문서 수를 곱하면 남은 시간을 알 수 있습니다.
이제는 대략적인 아이디어입니다. 전체 시간에 영향을주는 것은 인덱싱해야하는 총 데이터 크기와 사용 가능한 메모리 크기입니다. 인덱스를 만들려면 동일한 문서를 터치 한 다른 인덱싱을 만든 후에도 데이터가 메모리에 여전히 캐시되어 있으면 훨씬 빠르게 처리 될 수 있습니다. 문서의 이전 캐싱으로 인해 전체 문서 크기가 메모리보다 많은 경우보다 훨씬 빠르게 처리 할 수 있다고 말하는 것 외에는 쉽게 예측할 수 없습니다.
장기적으로 나는 큰 MongoDB 데이터베이스를 가지고 있지 않기 때문에 고통 스럽기 때문에 이것을 https://jira.mongodb.org/browse/SERVER-7019에 투표하여 우리가 대기열에 넣을 수 없는지 알아 보겠다.