Mongoose: {useUnifiedTopology: true} приводит к ошибке подключения MongoDB: MongoTimeoutError: время ожидания выбора сервера истекло через 30000 мс

Какой образ докера вы используете? Кроме того, есть ли у вас трассировка стека для сообщения «Время ожидания выбора сервера истекло»?

Эй, просто заглянул сюда, чтобы сообщить, что у меня такая же проблема.

Я сам не использую ни Docker, ни какие-либо vm. Также следует отметить, что это, похоже, происходит не все время, однако сегодня я не смог получить какие-либо свои данные из-за тайм-аутов (30k), и проблема была немедленно решена при удалении флага useUnifiedTopology .

Я подключаюсь к кластеру Атлас.

Мангуст - 5.7.1
MongoDb - 3.3.2
Узел - 12.9.1

Подключение так:

mongoose.createConnection(uri,
    {
        useCreateIndex: true,
        useNewUrlParser: true,
        useUnifiedTopology: true, // commented out currently
        dbName: db_name
    });

Модель создается так:

import mongoose from 'mongoose';
import * as db_conns from '../db-connections'; // this is an object of connections generated via createConnection

// ... schema definition, for a model called 'article' from a collection called 'article'

// `site_content` is the name of a connection
export default db_conns.connections.site_content.model(`article`, schema, `article`);

Тогда это будет выглядеть так:

// ...
await query.model.find(query_expr).limit(30); // query_expr can change, however even an empty expression ({}) will cause the same issue
// ...

Вызов find зависает и выдает ошибку тайм-аута.

@ vkarpov15 Я использую последний образ mongo который предоставляет MongoDB v4.2.0.
https://hub.docker.com/_/mongo

Я также получаю ту же ошибку после добавления {useUnifiedTopology: true}, хотя ошибка возникает случайным образом. Что-то определенно не так. Я использую последнее изображение монго.

мангуста
.connect (process.env.MONGO_URI, {
useUnifiedTopology: true,
useNewUrlParser: правда,
})
.then (() => console.log ('БД подключена!'))
.catch (err => {
console.log (Ошибка, сообщение об ошибке);
});
Когда он запускается, я подхожу к консоли:
[Функция: ошибка] {stackTraceLimit: 16, prepareStackTrace: undefined} соединение 0 с acccluster-shard-00-01-xx47j.mongodb. сеть: 27017 закрыто

Какие-нибудь решения? Даже сейчас я столкнулся с этой проблемой ...

У меня такая же проблема. Я младший программист и впервые использую nodejs-express-graphql-mongoose-mongodbAtlas.

(узел: 9392) UnhandledPromiseRejectionWarning: MongoTimeoutError: время ожидания выбора сервера истекло через 30000 мс
в Timeout.setTimeout (MyAppPathgraphql2node_modulesmongodblibcoresdamtopology.js: 850: 16)
при ontimeout (timers.js: 436: 11)
в tryOnTimeout (timers.js: 300: 5)
в listOnTimeout (timers.js: 263: 5)
в Timer.processTimers (timers.js: 223: 10)
(узел: 9392) UnhandledPromiseRejectionWarning: необработанное отклонение обещания. Эта ошибка возникла либо из-за вызова асинхронной функции без блока catch, либо из-за отклонения обещания, которое не было обработано с помощью .catch (). (идентификатор отказа: 1)
(узел: 9392) [DEP0018] DeprecationWarning: необработанные отклонения обещаний устарели. В будущем необработанные отклонения обещаний завершат процесс Node.js с ненулевым кодом выхода.
events.js: 174
бросить эр; // Необработанное событие 'ошибка'
^

Ошибка: прочтите ECONNRESET
в TLSWrap.onStreamRead (internal / stream_base_commons.js: 111: 27)
Произошло событие "ошибка" в:
в TLSSocket.(MyAppPathnode_modulesmongodblibcoreconnectionconnection.js: 321: 10)
в Object.onceWrapper (events.js: 286: 20)
в TLSSocket.emit (events.js: 198: 13)
в emitErrorNT (внутренний / потоки / destroy.js: 91: 8)
в emitErrorAndCloseNT (внутренний / потоки / destroy.js: 59: 3)
в process._tickCallback (внутренний / процесс / next_tick.js: 63:19)

Мы также получаем ту же ошибку на нашем производственном сервере после включения useUnifiedTopology .

MongoTimeoutError: Server selection timed out after 30000 ms
    at Timeout.setTimeout [as _onTimeout] (/opt/app/node_modules/mongodb/lib/core/sdam/topology.js:850:16)
    at ontimeout (timers.js:498:11)
    at tryOnTimeout (timers.js:323:5)
    at Timer.listOnTimeout (timers.js:290:5)

Я начал сталкиваться с другой проблемой сейчас
MaxListenersExceededWarning: обнаружена возможная утечка памяти EventEmitter. Добавлены 11 прослушивателей topologyDescriptionChanged.

Когда я искал это предупреждение, я наткнулся на этот документ mongoDB
https://jira.mongodb.org/browse/NODE-2123

В нем говорится как об ошибках
«Истекло время выбора сервера», а также «MaxListenersExceededWarning», и обе ошибки связаны с изменением унифицированной топологии. Думаю, это было решающее изменение, о котором никогда не упоминалось.

Поскольку я сталкиваюсь с этой ошибкой на своем действующем сервере, у меня нет другого выбора, кроме как установить {useUnifiedTopology: false}. Я надеюсь, что кто-то из сообщества сможет сосредоточиться на этой проблеме и решить ее или внести несколько предложений по ее решению.

Я также получаю обе ошибки (время ожидания выбора сервера истекло через 30000 мс и MaxListenersExceededWarning: обнаружена возможная утечка памяти EventEmitter. 11 ) при использовании useUnifiedTopology, поэтому я думаю, это происходит со всеми, кто использует этот параметр.

Я пытался воспроизвести это, но мне не удалось воспроизвести. Я попробовал несколько вариантов:

1) Убиваем сервер прямо перед запросом

2) Запрос при отключенном соединении

3) Успешное выполнение запроса

В любом случае я еще не видел этого сообщения об ошибке. Не могли бы вы изменить приведенный ниже сценарий, чтобы продемонстрировать эту проблему?

'use strict';

const mongoose = require('mongoose');

run().catch(err => console.log(err));

async function run() {
  mongoose.set('useUnifiedTopology', true);
  mongoose.set('useNewUrlParser', true);

  await mongoose.connect('mongodb://localhost:27017/test');

  const Model = mongoose.model('Test', new mongoose.Schema({ name: String }));

  console.log('Query...');
  await Model.findOne();
  console.log('Done');
}

Или, по крайней мере, предоставьте некоторую информацию о том, какую версию Mongoose вы используете; используете ли вы автономный сервер, набор реплик или сегментированный кластер; и используете ли вы Mongoose напрямую или через другой модуль npm?

Я совершенно убежден, что это проблема не мангуста, а самого Монго.

@ vkarpov15 , мой комментарий , я обрисовал там свое окружение. Я использую мангуст напрямую.

@ vkarpov15 для меня эта проблема возникает случайным образом каждые 2-3 дня, когда сервер работает, поэтому даже если я предоставлю вам код, вам придется постоянно контролировать сервер.

Кто-нибудь обошел эту проблему?

Кто-нибудь обошел эту проблему?

Вы можете просто пока не использовать этот флаг. Mongo предупредит вас, что он будет отключен в будущем или что-то в этом роде, но на данный момент, похоже, полностью решает эту проблему.

Кто-нибудь обошел эту проблему?

Вы можете просто пока не использовать этот флаг. Mongo предупредит вас, что он будет отключен в будущем или что-то в этом роде, но на данный момент, похоже, полностью решает эту проблему.

когда я не использую флаг useUnifiedTopology: true, у меня есть эта ошибка, и приложение остановлено,
версия мангуста: 5.7.4

Могу подтвердить, что комментирование useUnifiedTopology out решает проблему в моей сборке. Также происходит (очевидно) случайным образом.

@rpedroni К сожалению, это не для нас ...

Также здесь происходит. Наш рабочий сервер отвечает следующим сообщением. Думаю, сейчас я прокомментирую useUnifiedTopology

Параметры подключения MongoDB

var options = {
    useCreateIndex: true,
    useNewUrlParser: true,
    useFindAndModify: false,
    useUnifiedTopology: true,
    promiseLibrary: global.Promise
};

Журнал сервера

MongoTimeoutError: Server selection timed out after 30000 ms 
Oct 16 12:56:31 app/web.1:     at Timeout.setTimeout (/app/node_modules/mongodb/lib/core/sdam/topology.js:850:16) 
Oct 16 12:56:31 app/web.1:     at Shim.applySegment (/app/node_modules/newrelic/lib/shim/shim.js:1424:20) 
Oct 16 12:56:31 app/web.1:     at Timeout.wrappedCallback [as _onTimeout] (/app/node_modules/newrelic/lib/shim/shim.js:1281:21) 
Oct 16 12:56:31 app/web.1:     at ontimeout (timers.js:436:11) 
Oct 16 12:56:31 app/web.1:     at tryOnTimeout (timers.js:300:5) 
Oct 16 12:56:31 app/web.1:     at listOnTimeout (timers.js:263:5) 
Oct 16 12:56:31 app/web.1:     at Timer.processTimers (timers.js:223:10) 

У нас тоже есть эта проблема, и мы не используем мангуста. Похоже, проблема связана с драйвером MongoDB для самого Node.js. О проблеме также сообщалось здесь https://jira.mongodb.org/browse/NODE-2249.
Версия 3.3.3 драйвера, которая была опубликована сегодня, должна добавить дополнительные сведения в MongoTimeoutError . Также рекомендуется обновить драйвер из-за исправления ошибки.

Эта ошибка является результатом того, что драйвер не может подключиться к серверу, удовлетворяющему предпочтению чтения данной операции (или первоначального подключения). Это может быть по ряду причин, в том числе недействительной строке подключения или неработающему узлу кластера. Если вы обновите драйвер до последней версии 3.3.3, мы добавим новое поле причины с MongoTimeoutError, которое поможет нам в дальнейшем расследовании вашей проблемы. Кроме того, эта версия включает исправление ошибки, которая приводила к ошибке тайм-аута при первоначальном подключении, если какой-либо член набора реплик был недоступен. Обновите драйвер и дайте нам знать, если проблема не исчезнет.

Цитируется из https://jira.mongodb.org/browse/NODE-2249?focusedCommentId=2485028&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment -2485028

То же самое здесь происходит как при разработке, так и при производстве, при подключении к Mongo Atlas :(

Также есть проблема с подключением к атласу mongodb. Обычно происходит после перезапуска или обновления сервера atlas или чего-то подобного.

Так что я все еще не могу воспроизвести это локально с помощью набора реплик. Приведенный ниже сценарий продолжает успешно выполнять запросы даже при отработке отказа набора реплик или уничтожении основного. Не возникает ошибок тайм-аута выбора сервера:

'use strict';

const mongoose = require('mongoose');

run().catch(err => console.log(err));

async function run() {
  mongoose.set('useUnifiedTopology', true);
  mongoose.set('useNewUrlParser', true);

  await mongoose.connect('mongodb://localhost:27017,localhost:27018,localhost:27019/test?replicaSet=rs');

  const Model = mongoose.model('Test', new mongoose.Schema({ name: String }));


  while (true) {
    console.log(new Date(), 'Query...');
    await Model.findOne();
    await new Promise(resolve => setTimeout(resolve, 5000));
  }
} 

Я предполагаю, что объяснение [email protected] (который я отправлю через пару часов) и посмотрите, сохраняется ли эта проблема.

Кроме того, кто-нибудь знает, есть ли способ запустить перезапуск в Атласе? Может быть, эта проблема возникает только в том случае, если вы используете Атлас?

@ vkarpov15 Я думаю, вам нужно приостановить / возобновить кластер, чтобы запустить перезапуск. Это возможно только для размеров M10 +.
Мне также интересно, может ли это быть проблемой Атласа. Мне еще не удалось протестировать обновленный драйвер MongoDB, но я вернусь сюда, как только это сделаю.

Сегодня у меня такая же проблема с уровнем бесплатного пользования Atlas, независимо от флага useUnifiedTopology. Ошибка: MongoTimeoutError: Server selection timed out after 30000 ms

Я могу установить соединение с помощью другой службы MongoDB, например mLab.

У меня была такая же проблема, и это закончилось чем-то немного глупым, но я все равно поделюсь ею, потому что это может помочь кому-то, кто тоже окажется здесь.

Я проверил поле «причина» в MongoTimeoutError, и он сказал: «MongoError: неудачная аутентификация аутентификации».
Тогда я понял, что использую пароль mongoDB в строке подключения, а не пароль пользователя.
Теперь работает нормально.

Если вы используете MongoDB Atlas, вам следует внести свой IP-адрес в белый список.

Перейдите в раздел «Доступ к сети», отредактируйте текущий IP-адрес и нажмите «Разрешить доступ из любого места».

Я столкнулся с этой проблемой только при использовании Atlas. Я попытался добавить 0.0.0.0/0 IP в белый список, но это тоже не сработало.

Я использую:

• мангуст: 5.7.6
• узел: v10.16.3
• Уровень бесплатного пользования Atlas

Не удалось воспроизвести на локальном сервере mongodb. Там каждый запрос просто успешно работает.

Это не имеет ничего общего с доступом. У меня есть доступ 0/0/0/0, и это происходит
каждый раз при перезапуске сервера на атласе. Вы можете воспроизвести, сделав мультиузел
кластер (m10 +) и установка времени планового обслуживания. Затем запустите длинный
запущенная служба, и она должна выдать ошибку при перезапуске.

В среду, 23 октября 2019 г., 7:42 Мохаммад Мазедул Ислам, <
[email protected]> написал:

Я столкнулся с этой проблемой только при использовании Atlas. Я пробовал добавить
0.0.0.0/0 IP в белом списке, но он тоже не работал.

Я использую:

• мангуст: 5.7.6
• узел: v10.16.3
• Уровень бесплатного пользования Atlas

Не удалось воспроизвести на локальном сервере mongodb. Там каждый запрос просто работает
успешно.

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/Automattic/mongoose/issues/8180?email_source=notifications&email_token=AAUHUCYYQIQ5U42IBYT7CQTQQQA2B7A5CNFSM4IYQ3ZB2YY3PNVWWK3TULXG63LDFV45PNVWWK3TULXG4DFW45VMWWWK3TULXG4DFWC4DVMWWK3DNVWWWK3TULXG4DFW45
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/AAUHUCY5SNFGGCPTGW6GH5DQQA2B7ANCNFSM4IYQ3ZBQ
.

У меня тоже была эта проблема. Но теперь, после помещения 0.0.0.0/0 и моего IP-адреса в белый список из атласа, проблема решается.

https://jira.mongodb.org/browse/NODE-2147

~ Это проблема только с MongoDB Atlas. ~

У меня проблема с использованием MongoDB Atlas.

У меня такая же проблема с обычным MongoDB.

Я успешно воспроизвел условие, которое вызывает "MongoTimeoutError: время ожидания выбора сервера истекло после 30000", используя docker-compose.
https://github.com/anzairyo0127/mongodb-connection-bug

Сначала запустите это приложение

$ docker-compose up -d
$ docker-compose exec a mongo /tmp/conf/init.js
$ docker-compose exec node sh
$ npm i && npm run build
$ npm run start

> 0times
> waiting ....
> {_id: 5db27454b77b210040f2f84e, id: 1, text: 'hogehoge'}
> 1times
> waiting ....
> {_id: 5db27454b77b210040f2f84e, id: 1, text: 'hogehoge'}
> xtimes
> waiting ....
> {_id: 5db27454b77b210040f2f84e, id: 1, text: 'hogehoge'}
> ......



md5-cc5c53b3c0322ef988c85b63b4bb6c4e



$ docker-compose restart a b c



md5-788ff0ed4e46daf35b1b8594351b929f



> xtimes
> waiting ....
> (node: 4360) UnhandledPromiseRejectionWarning: MongoTimeoutError: Server selection timed out after 30000 ms
> at Timeout.setTimeout [as _onTimeout] (/var/work/node_modules/mongodb/lib/core/sdam/topology.js:878:9)
> at ontimeout (timers.js: 436: 11)
> at tryOnTimeout (timers.js: 300: 5)
> at listOnTimeout (timers.js: 263: 5)
> at Timer.processTimers (timers.js: 223: 10)
> (node: 4360) UnhandledPromiseRejectionWarning: Unhandled promise rejection.This error originated either by throwing inside of an> async function without a catch block, or by rejecting a promise which was not handled with .catch (). (rejection id: 1)
> (node: 4360) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that
> are not handled will terminate the Node.js process with a non-zero exit code.

@ anzairyo0127 можете ли вы попробовать то же самое с последней библиотекой mongodb 3.3.3?

@rvanmil Я могу воспроизвести его в версии 3.3.3.

Похоже, эта ошибка возникает, когда mongoDB находится в конфигурации репликации, и один из экземпляров (вероятно, первичный экземпляр) получает команду непосредственно перед тем, как он отключится, или сразу после его запуска.
Я думаю, что причина, по которой это часто происходит в MongoDB Atlas, заключается в том, что MongoDB Atlas регулярно отправляет запросы в кластер для мониторинга.

Какие-нибудь решения? Эта проблема ....

Та же проблема более 1 месяца и не решена -_-

Обновление до [email protected] решило

@octavioamu Не могли бы вы

извините, не знаю, какая версия была установлена, вероятно, очень старая, так как какое-то время я не работал с mongo.
Версия мангуста находится на @ 5.7.7
Сообщение было постоянным для меня, и как только я установил [email protected] (установленный через brew), сообщение остановилось.

Если я установил {useUnifiedTopology: false} я получаю ошибку аутентификации

(node:19948) UnhandledPromiseRejectionWarning: MongoNetworkError: failed to connect to server [localhost:27017] on first connect [MongoError: Authentication failed.]

и если я установлю {useUnifiedTopology: true} , у меня будет тайм-аут

(node:20213) UnhandledPromiseRejectionWarning: MongoTimeoutError: Server selection timed out after 30000 ms

Пароль определенно правильный. Это можно воспроизвести в локальной системе с помощью новейших версий всего и LST Node.js. Однако использование строки подключения без какой-либо аутентификации, похоже, работает локально. Поэтому, если я установил, например, const MONGODB_URI = "mongodb://localhost/fullstack" проблема с тайм-аутом

const mongoose = require('mongoose')
// const url = 'mongodb://fullstack:fullstack@localhost/fullstack'
const url = 'mongodb://localhost/fullstack'
console.log('Connection url = ', url, 'connecting')
mongoose.connect(url, { useNewUrlParser: true, useUnifiedTopology: true })
console.log('Connected.')
mongoose.connection.close()

Я использовал последний образ Docker для установки MongoDB.

Также здесь происходит. Наш рабочий сервер отвечает следующим сообщением. Думаю, сейчас я прокомментирую useUnifiedTopology

Параметры подключения MongoDB

var options = {
    useCreateIndex: true,
    useNewUrlParser: true,
    useFindAndModify: false,
    useUnifiedTopology: true,
    promiseLibrary: global.Promise
};

Журнал сервера

MongoTimeoutError: Server selection timed out after 30000 ms 
Oct 16 12:56:31 app/web.1:     at Timeout.setTimeout (/app/node_modules/mongodb/lib/core/sdam/topology.js:850:16) 
Oct 16 12:56:31 app/web.1:     at Shim.applySegment (/app/node_modules/newrelic/lib/shim/shim.js:1424:20) 
Oct 16 12:56:31 app/web.1:     at Timeout.wrappedCallback [as _onTimeout] (/app/node_modules/newrelic/lib/shim/shim.js:1281:21) 
Oct 16 12:56:31 app/web.1:     at ontimeout (timers.js:436:11) 
Oct 16 12:56:31 app/web.1:     at tryOnTimeout (timers.js:300:5) 
Oct 16 12:56:31 app/web.1:     at listOnTimeout (timers.js:263:5) 
Oct 16 12:56:31 app/web.1:     at Timer.processTimers (timers.js:223:10) 

Также здесь происходит. Наш рабочий сервер отвечает следующим сообщением. Думаю, сейчас я прокомментирую useUnifiedTopology

Параметры подключения MongoDB

var options = {
    useCreateIndex: true,
    useNewUrlParser: true,
    useFindAndModify: false,
    useUnifiedTopology: true,
    promiseLibrary: global.Promise
};

Журнал сервера

MongoTimeoutError: Server selection timed out after 30000 ms 
Oct 16 12:56:31 app/web.1:     at Timeout.setTimeout (/app/node_modules/mongodb/lib/core/sdam/topology.js:850:16) 
Oct 16 12:56:31 app/web.1:     at Shim.applySegment (/app/node_modules/newrelic/lib/shim/shim.js:1424:20) 
Oct 16 12:56:31 app/web.1:     at Timeout.wrappedCallback [as _onTimeout] (/app/node_modules/newrelic/lib/shim/shim.js:1281:21) 
Oct 16 12:56:31 app/web.1:     at ontimeout (timers.js:436:11) 
Oct 16 12:56:31 app/web.1:     at tryOnTimeout (timers.js:300:5) 
Oct 16 12:56:31 app/web.1:     at listOnTimeout (timers.js:263:5) 
Oct 16 12:56:31 app/web.1:     at Timer.processTimers (timers.js:223:10) 

Я использую атлас mongo db, и мы сталкиваемся с той же проблемой.

dub-tools-jobs: orders - error MongoTimeoutError: Server selection timed out after 30000 ms 
Oct 29 13:16:30 app/worker.1:      at Timeout.setTimeout [as _onTimeout] (/app/node_modules/mongoose/node_modules/mongodb/lib/core/sdam/topology.js:850:16) 
Oct 29 13:16:30 app/worker.1:     at ontimeout (timers.js:436:11) 
Oct 29 13:16:30 app/worker.1:     at tryOnTimeout (timers.js:300:5) 
Oct 29 13:16:30 app/worker.1:     at listOnTimeout (timers.js:263:5) 
Oct 29 13:16:30 app/worker.1:     at Timer.processTimers (timers.js:223:10) +2m

все это произошло с комментарием useUnifiedTopology, как предлагала одна рекомендация

// mongodb connections
var options = {
    useCreateIndex: true,
    useNewUrlParser: true,
    useFindAndModify: false,
    // useUnifiedTopology: true,      
    promiseLibrary: global.Promise
};

используя атлас mongoose и mongoDB, убедитесь, что параметры такие:
mongoose.connect (DATABASE_URL, {useNewUrlParser: true, useUnifiedTopology: true})

После этого, если истечет время ожидания, вам нужно внести свой IP-адрес в белый список из mongoDB, перейдя к сетевому доступу в mongoDB.

Как и другие, эта ошибка приводит к сбою моего приложения каждые несколько дней, и я могу подтвердить, что это не связано с доступом или внесением в белый список IP-адреса.

Я использую:

• мангуст: 5.7.6
• узел: v10.16.3
• Уровень бесплатного пользования Atlas

А пока я буду комментировать useUnifiedTopology: true . Кажется, это может быть связано либо с Атласом, либо с монго, как утверждали другие.

Это проблема с серверами MongoDB с набором реплик, и инженеры MongoDB работают над решением этой проблемы.

https://jira.mongodb.org/browse/NODE-2267

@ vkarpov15, вероятно, может закрыть эту проблему, потому что она не имеет ничего общего с Mongoose.

когда ваш текущий IP-адрес изменяется по какой-либо причине, соединение не удается, вы должны отредактировать его в белом списке IP-адресов доступа к сети и использовать текущий IP-адрес

Привет! Меня зовут Мэтт, я в команде водителей MongoDB. Мы очень сожалеем о сбоях, с которыми вы все столкнулись, и я хотел бы дать небольшую обновленную информацию по этой проблеме:

Мы пытаемся постепенно отказаться от устаревших типов топологии, что оказалось очень хирургическим процессом. Поэтапный отказ от этих типов поможет значительно снизить нагрузку на драйвер, и мы надеемся, что это означает более стабильный и эффективный драйвер для наших пользователей. В частности, при введении «унифицированной топологии» мы также не вводили перезапись пула соединений, чтобы уменьшить вероятность ошибки. Оказалось, что пул соединений был более тесно связан с типами топологии, чем мы ожидали, и в результате мы испытали некоторые регрессии, особенно в отношении мониторинга серверов.

Сегодня утром я запустил драйвер v3.3.4-rc0, который должен решить проблемы, с которыми вы столкнулись. Мы были бы чрезвычайно благодарны, если бы вы могли опробовать эту версию и поделиться своим опытом. Я оставил комментарии к каждому из существующих обращений, связанных с этой проблемой, на NODE-2267 , но, пожалуйста, не стесняйтесь открывать там дополнительные проблемы, если они у вас возникнут.

Я могу подтвердить, что 3.3.4-rc0 устранил проблему 👍 Я предоставлю более подробные результаты тестирования позже.

после того, как я изменил свою версию mongodb в package.json на
"mongodb": "3.3.4-rc0",
Я всегда получаю сообщение об ошибке (эта ошибка не возникает, если версия mongodb находится на 3.3.3):

=============================================
npm ERR! путь / tmp / app / node_modules / npm / node_modules / abbrev
npm ERR! код ENOENT
npm ERR! ошибка -2
npm ERR! переименование системного вызова
npm ERR! enoent ENOENT: нет такого файла или каталога, переименуйте '/ tmp / app / node_modules / npm / node_modules / abbrev' -> '/tmp/app/node_modules/npm/node_modules/.abbrev.DELETE'
npm ERR! enoent Это связано с тем, что npm не может найти файл.
npm ERR! enoent
npm ERR! Полный журнал этого запуска можно найти в:
npm ERR! /home/vcap/.npm/_logs/2019-11-06T17_19_55_661Z-debug.log
[31; 1 мин. ОШИБКА [0 мин. Невозможно построить зависимости: статус выхода 254
Не удалось скомпилировать дроплет: не удалось запустить все сценарии поставки: статус выхода 14
Статус выхода 223

==================================
моя версия npm - npm на 6.11.3.

Связана ли эта ошибка с новой сборкой mongodb v3.3.4-rc0?

@zhenwan, похоже, проблема с загрузкой пакета abbrev . Я предполагаю, что есть проблемы с вашим package-lock.json , попробуйте удалить этот файл и снова запустить npm install .

Мне удалось воспроизвести ошибку и проверить, была ли она решена с помощью драйвера v3.3.4-rc0, используя следующую настройку:

• Веб-сервер Node.js, предоставляющий простой http api GET /api/todos который запрашивает коллекцию todo MongoDB, которая содержит некоторые образцы данных
• Скрипт, который вызывает api каждые 500 мс, работает локально на моей машине
• После запуска сценария инициируйте аварийное переключение (перезапустите основной) в MongoDB (в Atlas я смог сделать это в кластере M10, выбрав пункт меню «Test Failover»).

Результаты этого теста были следующими:

✅ Mongodb Node.js 3.3.2 useUnifiedTopology false

> MongoDB failover triggered
> MongoDB 'reconnect' event
> A few http calls with +/- 5000ms response times
> MongoDB failover finished
> Everything back to normal

❌ Mongodb Node.js 3.3.2 useUnifiedTopology true

> MongoDB failover triggered
> MongoDB 'close' event
> Many MongoNetworkError errors
    {
      "name": "MongoNetworkError",
      "stack": "Error: connect ECONNREFUSED <ip_redacted>:27017
          at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1128:14)",
      "errorLabels": [
        "TransientTransactionError"
      ]
    }
> EventEmitter memory leak warning
    (node:18) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 topologyDescriptionChanged listeners added to [NativeTopology]. Use emitter.setMaxListeners() to increase limit
> Many MongoTimeoutError errors
    {
      "name": "MongoTimeoutError",
      "stack": "MongoTimeoutError: Server selection timed out after 30000 ms
          at Timeout._onTimeout (/app/node_modules/mongodb/lib/core/sdam/topology.js:850:16)
          at listOnTimeout (internal/timers.js:531:17)
          at processTimers (internal/timers.js:475:7)"
    }
> MongoDB failover finished
> Server unable to recover MongoDB connection
> Server restarted manually
> Everything back to normal

⚠️ Mongodb Node.js 3.3.4-rc0 useUnifiedTopology true

> MongoDB failover triggered
> MongoDB 'reconnect' event expected but not seen
> A few http calls with +/- 5000ms response times
> A couple failed http calls:
    {
      "name": "MongoError",
      "stack": "MongoError: Cache Reader No keys found for HMAC that is valid for time: { ts: Timestamp(1573064656, 1) } with id: 6756219367492419585
          at Connection.<anonymous> (/app/node_modules/mongodb/lib/core/connection/pool.js:451:61)
          at Connection.emit (events.js:210:5)
          at processMessage (/app/node_modules/mongodb/lib/core/connection/connection.js:368:10)
          at TLSSocket.<anonymous> (/app/node_modules/mongodb/lib/core/connection/connection.js:537:15)
          at TLSSocket.emit (events.js:210:5)
          at addChunk (_stream_readable.js:308:12)
          at readableAddChunk (_stream_readable.js:289:11)
          at TLSSocket.Readable.push (_stream_readable.js:223:10)
          at TLSWrap.onStreamRead (internal/stream_base_commons.js:182:23)",
      "ok": 0,
      "errmsg": "Cache Reader No keys found for HMAC that is valid for time: { ts: Timestamp(1573064656, 1) } with id: 6756219367492419585",
      "code": 211,
      "codeName": "KeyNotFound"
    }
> MongoDB failover finished
> Everything back to normal

Таким образом, похоже, что он работает с v3.3.4-rc0 , сервер может восстановить соединение и возобновить обслуживание данных из MongoDB. Однако есть еще две проблемы:

• Событие повторного подключения отсутствует
• Пара запросов завершается неудачно с сообщением об ошибке «Читатель кэша Не найдены ключи для HMAC, которые действительны в течение времени».

@mbroadst да, удаление package-lock.json решило мою проблему с отсутствующим файлом.

Но я все равно получаю ошибку:
2019-11-06T12: 52: 10.35-0600 [CELL / 0] OUT Контейнер стал исправным
2019-11-06T12: 52: 39.06-0600 [APP / PROC / WEB / 0] ERR /home/vcap/app/node_modules/connect-mongo/src/index.js:135
2019-11-06T12: 52: 39.06-0600 [APP / PROC / WEB / 0] ERR throw err
2019-11-06T12: 52: 39.06-0600 [APP / PROC / WEB / 0] ERR ^
2019-11-06T12: 52: 39.06-0600 [APP / PROC / WEB / 0] ERR Ошибка: время ожидания выбора сервера истекло через 30000 мс
2019-11-06T12: 52: 39.06-0600 [APP / PROC / WEB / 0] ERR в Timeout.setTimeout [как _onTimeout] (/ home / vcap / app / node_modules / connect-mongo / node_modules / mongodb / lib / core /sdam/topology.js:878:9)
2019-11-06T12: 52: 39.06-0600 [APP / PROC / WEB / 0] ERR при ontimeout (timers.js: 469: 11)
2019-11-06T12: 52: 39.06-0600 [APP / PROC / WEB / 0] ERR в tryOnTimeout (timers.js: 304: 5)
2019-11-06T12: 52: 39.06-0600 [APP / PROC / WEB / 0] ERR в Timer.listOnTimeout (timers.js: 264: 5)
2019-11-06T12: 52: 39.35-0600 [APP / PROC / WEB / 0] OUT Статус выхода 1

@zhenwan похоже, что это может быть связано с невозможностью подключиться к вашему кластеру при первоначальном подключении. Также ваш возврат к topology.js:878 любопытно не указывает на место, где генерируется ошибка, и вы не получаете правильный тип MongoTimeoutError .

Не могли бы вы открыть новый тикет jira, чтобы мы могли отсортировать ваш конкретный случай. Похоже, нам понадобится больше деталей, чем то, что вы здесь вставили. Спасибо!

@mbroadst
Спасибо за помощь в решении проблемы. Я просто хочу сказать, что использование v3.3.4-rc0 не решает мою проблему. Я все еще получаю это сообщение

MongoTimeoutError: Server selection timed out after 30000 ms
    at Timeout.setTimeout (api/node_modules/mongodb/lib/core/sdam/topology.js:899:9)
    at ontimeout (timers.js:498:11)
    at tryOnTimeout (timers.js:323:5)
    at Timer.listOnTimeout (timers.js:290:5)

В моем случае я использую loopback-connector-mongodb , но я настраиваю package.json на принудительное использование последней версии mongodb в resolutions как показано ниже.

"resolutions": {
    "mongodb": "^3.3.4-rc0"
  }

мои параметры подключения, как показано ниже

"host": "127.0.0.1",
 "port": 27017,
"database": "***",
"password": "***",
"user": "***",
"authSource": "***",
"useNewUrlParser": true,
"enableGeoIndexing": true

ниже мои параметры среды

MongoDB server version: 3.6.3 on localhost
yarn v1.19.1
node v8.16.2 

заранее спасибо

Обновить
Я также пробовал добавить useUnifiedTopology: true в параметры подключения, но получил тот же результат.

Еще одно подтверждение здесь, от кого-то, кто напрямую использует мангуста, что useUnifiedTopology: false работает для меня.

@mbroadst спасибо за обновление от MongoDB. Извините за мое незнание, но будет ли вышеупомянутое исправление в mongodb v3.3.4-rc0 в какой-то момент перерасти в мангуст? Немного неудобно использовать устаревшие функции в качестве временного решения в рабочей среде.

@mmmmoj похоже на вопрос @zhenwan выше, ваша трассировка стека, похоже, указывает на то, что вы на самом деле не используете v3.3.4-rc0. Может попробовать удалить свой package-lock.json ? Не могли бы вы подать заявку на jira, чтобы мы могли вникнуть в специфику вашего дела.

@bigsee (человек, GitHub _не_ любит автозаполнение вашего имени!) Рад слышать, что это работает для вас, и добро пожаловать в обновление - наше сообщество очень важно для нас. Я позволю @ vkarpov15 говорить о сроках выпуска, но мы тесно сотрудничаем, и я уверен, что он заинтересован в том, чтобы исправить это для всех вас :)

@mbroadst
сделано! Спасибо
УЗЕЛ-2313

@mbroadst ha! извините за неловкое название!

оказывается, я мог сказать слишком рано, возможно, учитывая случайный характер появившейся ошибки. При холодном запуске моего приложения вместе с ожидаемым предупреждением об устаревании я теперь вижу в журналах эту немного более страшную ошибку:

Unhandled rejection: { MongoNetworkError: failed to connect to server [myserver.mlab.com:55841] on first connect [{ MongoNetworkError: connection 0 to myserver.mlab.com:55841 timed out
    at Socket.<anonymous> (/var/task/node_modules/mongodb/lib/core/connection/connection.js:335:7)
    at Object.onceWrapper (events.js:313:30)
    at emitNone (events.js:106:13)
    at Socket.emit (events.js:208:7)
    at Socket._onTimeout (net.js:420:8)
    at ontimeout (timers.js:482:11)
    at tryOnTimeout (timers.js:317:5)
    at Timer.listOnTimeout (timers.js:277:5) name: 'MongoError', [Symbol(mongoErrorContextSymbol)]: {} }]
    at Pool.<anonymous> (/var/task/node_modules/mongodb/lib/core/topologies/server.js:431:11)
    at emitOne (events.js:116:13)
    at Pool.emit (events.js:211:7)
    at connect (/var/task/node_modules/mongodb/lib/core/connection/pool.js:580:14)
    at callback (/var/task/node_modules/mongodb/lib/core/connection/connect.js:109:5)
    at provider.auth.err (/var/task/node_modules/mongodb/lib/core/connection/connect.js:352:21)
    at _authenticateSingleConnection (/var/task/node_modules/mongodb/lib/core/auth/auth_provider.js:66:11)
    at sendAuthCommand (/var/task/node_modules/mongodb/lib/core/auth/scram.js:177:16)
    at Connection.errorHandler (/var/task/node_modules/mongodb/lib/core/connection/connect.js:321:5)
    at Object.onceWrapper (events.js:317:30)
    at emitTwo (events.js:126:13)
    at Connection.emit (events.js:214:7)
    at Socket.<anonymous> (/var/task/node_modules/mongodb/lib/core/connection/connection.js:333:10)
    at Object.onceWrapper (events.js:313:30)
    at emitNone (events.js:106:13)
    at Socket.emit (events.js:208:7)
  name: 'MongoNetworkError',
  errorLabels: [ 'TransientTransactionError' ],
  [Symbol(mongoErrorContextSymbol)]: {} }

Раньше это было MongoTimeoutError а теперь MongoNetworkError ... ... есть идеи?

@bigsee эта ошибка будет означать, что вы _не_ используете унифицированную топологию. Пожалуйста, включите его, передав useUnifiedTopology: true в свой MongoClient

@mbroadst , это правильно, и я считаю, что это суть проблемы. Прошу прощения, если я ошибаюсь.

Когда я передаю useUnifiedTopology: true предупреждение об устаревании исчезает, но мое приложение случайно вылетает с ошибкой заголовка этой проблемы MongoTimeoutError: Server selection timed out after 30000 ms .

Как и в случае с @ vkarpov15 и другими выше, мне не удавалось последовательно воспроизвести эту проблему. Ошибка возникает несколько раз в день, время от времени приводя к 502 и ужасным ошибкам UX. Вроде новый вопрос.

Как сообщалось выше, обходной путь установки useUnifiedTopology: false (или комментирования) предотвращает ошибку в этой проблеме, но восстанавливает предупреждение об устаревании и теперь немного более пугающую MongoNetworkError выше. Кстати, это на самом деле не убивает мое приложение, но меня беспокоит, что в какой-то момент это будет для пользователя.

@bigsee, MongoNetworkError которыми вы столкнулись, не нова, и это означает, что драйвер не смог установить начальное соединение с кластером (кстати, если какое-то состояние гонки между запуском вашего приложения и запуском кластера вызывает это, то и здесь должна помочь унифицированная топология).

Суть этой проблемы в том, что люди следовали инструкциям по использованию унифицированной топологии, и когда они это делали, у них возникали ложные ошибки тайм-аута. v3.3.4-rc0 был выпущен для решения этой конкретной проблемы, поэтому текущее руководство состоит в том, чтобы использовать эту версию, которая должна удалить уведомление об устаревании и исправить ложные проблемы с тайм-аутом, с которыми люди столкнулись.

Я также должен сказать: эта версия не предотвратит _все_ ошибки тайм-аута. Эта ошибка вызвана неспособностью драйвера выполнить первоначальное подключение к кластеру, что может указывать на какую-то конфигурацию (строка подключения) или сетевая ошибка с вашей стороны. В унифицированной топологии это будет отображаться как MongoTimeoutError с полем reason указывающим на сетевую ошибку, которая вызвала тайм-аут при первоначальном подключении.

@mbroadst Я не имел в виду предположить, что MongoNetworkError был новым в моем последнем комментарии, поэтому извиняюсь, если это то, как он читается. Это новая ошибка MongoTimeoutError. Чтобы быть яснее, это был мой процесс:

1. приложение имеет конфигурацию с useUnifiedTopology: true - все работает как ожидалось
2. приложение запускает случайный сбой и представляет MongoTimeoutError соответствующее названию этой проблемы, а также первые несколько строк трассировки стека, представленные выше
3. поиск Google / SO в конечном итоге приводит меня сюда
4. Я использую useUnifiedTopology: false предложенный обходной путь
5. ошибка MongoTimeoutError исчезает вместе с аварийным завершением работы приложения. однако изначально оно заменяется предупреждением об устаревании. затем, позже, с помощью дополнительного MongoNetworkError не видимого в приложении перед установкой useUnifiedTopology: false

Возможно, как вы предполагаете, это скорее корреляция, чем причинная связь. Мне это показалось дымящимся пистолетом. По крайней мере, сейчас приложение не вылетает. Я просто беспокоюсь о том, чтобы оставить опцию, которая устарела.

@bigsee Ах! Извините, я неправильно прочитал ваш исходный комментарий, что означает, что вы подтверждаете, что исправления ошибок v3.3.4-rc0 разрешили ваши проблемы с v3.3.3 . Довелось ли вам опробовать новую версию?

Это моя первая пробная версия Mongodb, и у меня возникает эта ошибка. прочитал комментарии и изменил мой db на v3.3.4-rc0, и он все еще не исправил ошибку

DeprecationWarning: текущий механизм обнаружения и мониторинга серверов устарел и будет удален в будущей версии. Чтобы использовать новый механизм обнаружения и мониторинга сервера, передайте параметр {useUnifiedTopology: true} конструктору MongoClient.
MongoNetworkError: не удалось подключиться к серверу [cluster0-shard-00-00-rhdve.mongodb. net: 27017 ] при первом подключении [MongoNetworkError: подключение 3 к cluster0-shard-00-00-rhdve.mongodb. сеть: 27017 закрыто
в TLSSocket.(C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnection.js: 356: 9)
в Object.onceWrapper (events.js: 297: 20)
в TLSSocket.emit (events.js: 209: 13)
в net.js: 588: 12
в TCP.done (_tls_wrap.js: 479: 7) {
name: 'MongoNetworkError',
errorLabels: [Массив],
}]
в бассейне.(C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoretopologiesserver.js: 433: 11)
в Pool.emit (events.js: 209: 13)
в C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionpool.js: 562: 14
в C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionpool.js: 999: 9
при обратном вызове (C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnect.js: 109: 5)
в C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnect.js: 129: 7
в Connection.errorHandler (C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnect.js: 321: 5)
в Object.onceWrapper (events.js: 297: 20)
в Connection.emit (events.js: 209: 13)
в TLSSocket.(C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnection.js: 354: 12) {
name: 'MongoNetworkError',
errorLabels: ['TransientTransactionError'],
}
TypeError: невозможно прочитать свойство 'find' из undefined
в C: laragonwwwVue-express-mongodbserverroutesapiposts.js: 12:26

@ Syfon01 ошибка, с которой вы столкнулись, mongo ). Если у вас по-прежнему возникают проблемы, откройте тикет jira, чтобы мы могли продолжить разговор там и не сбивать с толку людей, которые смотрят на эту проблему GitHub.

Для людей, у которых возникла эта проблема, если вы используете экземпляр облака Mongo Atlas, проверьте, правильно ли вы указали свой IP-адрес на вкладке «Доступ к сети».

У меня возникла проблема, и кажется, что, поскольку мой интернет-провайдер выдает новые IP-адреса каждый раз (DHCP), когда я повторно подключаюсь к сети, Mongo Atlas составлял только белый список ранее указанного IP-адреса. Надеюсь, это кому-то поможет.

обновление - не работает

Мне удалось решить эту проблему, изменив структуру моего кода, в частности обратный вызов, следующим образом:

mongoose.connect(DATABASE_URL, {
    useNewUrlParser: true,
    useUnifiedTopology: true,
}).then(() => {
    console.log('Connected to DB');
    app.listen({ port: PORT }, () => {
        console.log(`Server running at http://localhost:${PORT}`)
    });
}).catch(err => console.log(err));

mongoose.connect(DATABASE_URL, { 
    useNewUrlParser: true, 
    useUnifiedTopology: true,
}, () => {
    console.log('Connected to DB');
    app.listen({ port: PORT }, () => {
        console.log(`Server running at http://localhost:${PORT}`);
    });
}).catch(err => console.log(err));

@ mtn2bay, что не имеет никакого смысла, вы в основном использовали функцию обратного вызова вместо обещания, результат все тот же, с той лишь разницей, что в функции обратного вызова вы получаете как соединение, так и ошибку в функции обратного вызова который вы не регистрируете вместо того, чтобы полагаться на .then и .catch, поэтому ваша функция регистрирует подключение к db и запускает приложение в любом случае, даже если есть ошибка. попробуйте это вместо

mongoose.connect(DATABASE_URL, { 
    useNewUrlParser: true, 
    useUnifiedTopology: true,
}, (err, connection) => {
if(err) {
console.error(err)
return
}    
console.log('Connected to DB');
    app.listen({ port: PORT }, () => {
        console.log(`Server running at http://localhost:${PORT}`);
    })

@khaledosman спасибо за исправление. Вы правы, я просто игнорировал ошибку, а не исправлял ее. У меня действительно была проблема с моим путем к базе данных.

Я столкнулся с той же проблемой, я обновил пакет mongoose npm с 5.6.9 до 5.7.6, и проблема исчезла.

Для людей, у которых возникла эта проблема, если вы используете экземпляр облака Mongo Atlas, проверьте, правильно ли вы указали свой IP-адрес на вкладке «Доступ к сети».

У меня возникла проблема, и кажется, что, поскольку мой интернет-провайдер выдает новые IP-адреса каждый раз (DHCP), когда я повторно подключаюсь к сети, Mongo Atlas составлял только белый список ранее указанного IP-адреса. Надеюсь, это кому-то поможет.

решил мою проблему
UnhandledPromiseRejectionWarning: MongoTimeoutError: Server selection timed out after 30000 ms at Timeout.setTimeout (C:\Users\Umer MIB\Desktop\Chatbots2\mongobot\node_modules\mongodb\lib\core\sdam\topology.js:878:9) at ontimeout (timers.js:436:11) at tryOnTimeout (timers.js:300:5) at listOnTimeout (timers.js:263:5) at Timer.processTimers (timers.js:223:10) (node:4304) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1) (node:4304) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code

Не знаю, как это решило проблему, но я скачал Compass и подключил его к базе данных, просто скопировал ссылку. После подключения ошибка исчезла. Топология в моем коде по-прежнему актуальна. Возможно, он настроил некоторые параметры с помощью Compass, которые не подходили при обычной установке mongodb. Теперь я могу подключиться без компаса, и все вроде работает, просто сделал это один раз в начале.

У меня такая же проблема, и благодаря этому форуму я справился, прокомментировав настройку useUnifiedTopology. Однако затем я раскомментировал этот параметр, но теперь он все еще работает нормально ... довольно запутанный ...

Mongoose v5.7.11 использует недавно выпущенный драйвер MongoDB 3.3.4, поэтому я собираюсь закрыть эту проблему. Если вы получаете подобное сообщение об ошибке, откройте новую проблему и следуйте шаблону проблемы.