Я конвертирую свой автономный mongodb в набор реплик. Я добавил еще одного участника (и я хочу добавить еще двух участников позже и выключить основной сервер).
Мой основной mongodb работает под управлением 2.2.3, а новый член реплики работает под управлением последней версии mongodb, 2.6.4.
Обе базы данных работают на сервере Ubuntu 14.04, в Microsoft Azure и работают в одной группе Affinity. (Размер Vm - A2)
Я отредактировал ulimit "nofile" и "nproc" на 65535. Увидев совет по MMMS-мониторингу, БУТ только на вторичных серверах, чтобы избежать перезагрузки машин. Это необходимо?
У меня есть где-то более 80 миллионов документов в первичной базе данных, и он работает в реальном времени. это из-за этого?
После нескольких часов синхронизации данных TTL показал следующие ошибки и снова начал синхронизацию. и он продолжает зацикливаться.
[rsSync] завершил построение нижнего слоя, собираюсь зафиксировать
[rsSync] старый файл журнала будет удален: /datadrive/data/journal/j._9
Индекс построения [rsSync] завершен. отсканировано всего 55381316 записей. 1348.97 секунд
[conn221] serverStatus был очень медленным: {после базового: 0, после утверждения: 0, после backgroundFlushing: 0, после подключений: 0, после курсоров: 0, после dur: 0, после extra_info: 0, после globalLock: 0, после indexCounters: 0, после блокировок: 0, после сети: 0, после opcounters: 0, после opcountersRepl: 0, после recordStats: 744214, после ответа: 744214, в конце: 744214}
[conn221] команда admin. $ cmd команда: serverStatus {serverStatus: 1} keyUpdates: 0 numYields: 0 блокировок (микросхем) r: 31 reslen: 3920 1243515 мс
[conn228] serverStatus был очень медленным: {после основного: 0, после утверждения: 0, после backgroundFlushing: 0, после подключений: 0, после курсоров: 0, после dur: 0, после extra_info: 0, после globalLock: 0, после indexCounters: 0, после блокировок: 0, после сети: 0, после opcounters: 0, после opcountersRepl: 0, после recordStats: 634932, после ответа: 634932, в конце: 634932}
[conn228] команда admin. $ cmd команда: serverStatus {serverStatus: 1} keyUpdates: 0 numYields: 0 блокировок (микросхем) r: 33 reslen: 3920 1073310 мс
[conn235] serverStatus был очень медленным: {после основного: 0, после утверждений: 0, после backgroundFlushing: 0, после подключений: 0, после курсоров: 0, после dur: 0, после extra_info: 0, после globalLock: 0, после indexCounters: 0, после блокировок: 0, после сети: 0, после opcounters: 0, после opcountersRepl: 0, после recordStats: 578551, после ответа: 578551, в конце: 578551}
[conn235] команда admin. $ cmd команда: serverStatus {serverStatus: 1} keyUpdates: 0 numYields: 0 блокировок (микросхем) r: 28 reslen: 3920 963376 мс
[conn194] Запрос обработки SocketException, закрытие клиентского соединения: исключение сокета 9001 [SEND_ERROR] сервер [ServerIp: 1250]
[conn252] Запрос обработки SocketException, закрытие клиентского соединения: исключение сокета 9001 [SEND_ERROR] сервер [ServerIp: 1248]
[rsSync] Сокет говорит send () errno: 110 Время ожидания соединения истекло ServerIp: 27017
[rsSync] replSet исключение начальной синхронизации: 9001 исключение сокета [SEND_ERROR] сервер [Serverip: 27017] Осталось 8 попыток
[rsSync] replSet начальная ожидающая синхронизация
[rsSync] replSet синхронизации с: [ServerAddress]: 27017
[rsSync] replSet первоначальная синхронизация отбросить все базы данных
[rsSync] dropAllDatabasesExceptLocal 2
[rsSync] removeJournalFiles
[rsSync] replSet initial sync clone all database
[rsSync] replSet начальная синхронизация клонирования db: PkgsKeyValues
[FileAllocator] размещение нового файла данных /datadrive/data/PkgsKeyValues.ns, заполнение нулями ...
[FileAllocator] размещение нового файла данных /datadrive/data/PkgsKeyValues.3, заполнение нулями ...
[FileAllocator] выделил файл данных /datadrive/data/PkgsKeyValues.3, размер: 512 МБ, занял 0,124 секунды.
Любые идеи?
Трудно сказать наверняка, основываясь на такой ограниченной информации, но похоже, что что-то убивает соединение между вторичным и первичным, пока оно пытается синхронизироваться. Если это происходит неоднократно примерно в одно и то же время, это говорит о том, что что-то в вашей сети требует максимального времени соединения. Если это происходит случайно, это говорит о том, что в самой сети есть что-то нестабильное (невозможно сказать, что это может быть, без серьезного устранения неполадок).
Из фрагмента журналов также очевидно, что вторичный сервер находится под большой нагрузкой, когда это происходит, поскольку для запуска ServerStatus требуется несколько часов (обычно менее 100 мс, когда он не находится под нагрузкой) - теперь он создает индекс в то время, которое операция блокировки, так что это может быть отвлекающим маневром, если это большой индекс. Если это не большой индекс, то это означает, что вторичный сервер немного не имеет ресурсов.
Если вы не можете решить цикл, вы можете принять другие меры для запуска и работы вторичного устройства, например копирование файлов данных, однако, если у вас нет параметров моментального снимка, которые включают остановку записи или отключение времени на время копирования.