Mongoose: 4.7.1 => 4.7.2 : Время ожидания подключения MongoError истекло

У меня та же проблема, [email protected] , [email protected]

• установка socketTimeoutMS на более высокие значения или 0 не имеет значения
• установка connectTimeoutMS на более высокие значения или 0 не имеет значения
• не запускается событие «закрыть» или «повторно подключиться», только «тайм-аут», что приводит к ошибке Mongoose в обратном вызове

Откат к mongoose @4.7.1/ [email protected] решает проблему, т.е. не вызывает тайм-ауты

С mongodb @ 2.2.11 до 2.2.12 прослушиватель событий тайм-аута изменился с «один раз» на «включено», может быть, это как-то связано с этим?

Или мы должны опубликовать это как проблему в собственном драйвере mongodb?

@silentjohnny Возникает та же проблема с мангустом @ 4.7.4

Я бы опубликовал проблему в собственном драйвере mongodb, mongoose мало что делает для первоначального подключения.

Вот драйвер mongodb jira

Странный. У меня такая же проблема, но с [email protected] и выше, которые используют [email protected].
С [email protected] и [email protected] это работает! .
Мой совокупный запрос без каких-либо параметров, поэтому я не знаю, может быть, это разница между мной и исходной проблемой @dcolens .

Кто-нибудь открывал вопрос с родным драйвером? так что я могу следить за ним ...
Сейчас я остаюсь с [email protected]

[email protected] обновлен до [email protected] , который включает исправление для отслеживания времени ожидания операций и создания события времени ожидания при выполнении операций @ 1284917

Вскоре Mongoose обновится до [email protected] , я попробую.

Та же проблема для меня, и я даже не уверен, что это просто длительные агрегаты, которые истекают, или это случайное, а не реальное время ожидания. Иногда кажется, что время ожидания истекает почти сразу, но иногда оно работает в течение 30 секунд или около того. В данном конкретном случае у меня одновременно запущено четыре агрегатных.exec.

Возврат к [email protected] и [email protected] исправляет это, поэтому я пока так и делаю.

Мы надеемся, что это должно быть исправлено в следующем выпуске, поскольку mongoose 4.7.7 использует [email protected]. В любом случае, это не проблема мангуста, как сказал @vkarpov15 , а больше связано с mongodb. Я собираюсь закрыть это на данный момент, но если вы все еще столкнетесь с той же проблемой после следующего выпуска, вам следует открыть тикет или PR на стороне mongodb.

Я думаю, что в этом вопросе может быть нечто большее, чем кажется на первый взгляд. Мне пришлось вернуться к 4.4.20, чтобы полностью остановить эти совокупные тайм-ауты, возникающие при любых обстоятельствах. 4.7.x и 4.6.x имели фиктивные очень быстрые тайм-ауты при некоторых обстоятельствах нескольких одновременных выполнений. Я пропустил 4.5 и сразу вернулся к заведомо хорошей версии (4.4.20), которую мы используем в производстве, и это полностью решило проблему, но я все еще озадачен тем, что происходит. Извините, у меня нет дополнительных данных для добавления, но я не уверен, что это проблема исключительно с версией собственного драйвера mongodb, которую использует mongoose, или есть более одного содействующего фактора. .

Та же проблема с [email protected] и [email protected]. Тайм-ауты действительно странные. Этот довольно короткий (около 5 с) и очень воспроизводимый, но другие запросы занимают больше 5 с и не истекают по тайм-ауту.

Я уверен, что тайм-ауты часто фальшивые. В одном сценарии, который я рассматривал, я запустил четыре одновременных операции агрегата.exec, которые занимают около 30 секунд. Время ожидания одного истекло через 8 секунд, время ожидания одного истекло через 20 секунд, но два других завершились нормально за 30 секунд. Повторение вызывало другой порядок тайм-аута, но всегда одинаковый результат. Я подозреваю, что тайм-ауты неправильно устанавливаются для неправильных соединений или не удаляются после завершения операции, поэтому они неожиданно срабатывают при последующем выполнении. Во всяком случае, что-то в этом роде. К сожалению, сейчас у меня нет времени этим заниматься.

[email protected] , кажется, решил для меня тайм-ауты. @steve-p-com, как вы предполагаете, тайм-ауты в 4.7.2 действительно были фальшивыми и вызывали появление ошибок при неправильном соединении, это было решено с помощью [email protected] , и поэтому [email protected] должен отлично работает в вашем случае. Вы проводили тест с этой версией?

Еще не тестировал 4.7.9 или 4.8.0, возможно, [email protected] представил регрессию, которая объяснила бы проблему, с которой столкнулся @flosky . Этот тайм-аут также происходит на mongoose @ 4.7.7?

Сегодня я повторно протестировал 4.8.1, и у меня не было проблем с неожиданными тайм-аутами. Сначала я удалил все кеши npm и кеши пряжи, затем удалил node_modules, а затем все переустановил. Все идет нормально.

У меня тоже такое бывает с 4.8.1. Я вернулся ко многим версиям Mongoose и MongoDB и постоянно сталкивался с проблемой.

@thenitai у вас есть больше контекста / можем ли мы увидеть, как вы настроили соединение с mongoDB?

@varunjayaraman Я обнаружил, что код ошибки нашего домена перехватывает ошибку и, таким образом, перезапускает наше приложение. Тем не менее, проблема все еще существует.

Не совсем уверен, что нужно видеть в настройках нашего соединения. Вы имеете в виду варианты подключения? Если да, то они:

var dbOptions = {
            db: { native_parser: true },
            server: {
                auto_reconnect: true,
                socketOptions: {
                    keepAlive: 1, 
                    connectTimeoutMS: 300000,
                    socketTimeoutMS: 300000
                }
            }
        };

У меня такая же проблема. даже с последней версией v4.8.4

только что нашел проблему. в моем случае это связано с тем, что использование памяти сервера слишком велико (всегда 95% ~ 99%), после увеличения памяти проблем больше нет.

Я также вижу эту проблему на своем сервере с Mongoose 4.7.7 , MongoDB 3.4.1 и Node 4.7.2 . Когда на моем сервере используется много памяти, тайм-ауты происходят случайным образом последовательно:

CosWebsite-27 MongoError: connection 42 to 127.0.0.1:27017 timed out
CosWebsite-27     at Function.MongoError.create (/home/cos/cos/node_modules/mongodb/node_modules/mongodb-core/lib/error.js:29:11)
CosWebsite-27     at Socket.<anonymous> (/home/cos/cos/node_modules/mongodb/node_modules/mongodb-core/lib/connection/connection.js:186:20)
CosWebsite-27     at Socket.g (events.js:260:16)
CosWebsite-27     at emitNone (events.js:67:13)
CosWebsite-27     at Socket.emit (events.js:166:7)
CosWebsite-27     at Socket.wrapped (/home/cos/cos/node_modules/newrelic/lib/transaction/tracer/index.js:183:28)
CosWebsite-27     at Socket.wrappedEmit [as emit] (/home/cos/cos/node_modules/newrelic/lib/transaction/tracer/index.js:220:46)
CosWebsite-27     at Socket._onTimeout (net.js:333:8)
CosWebsite-27     at _runOnTimeout (timers.js:537:11)
CosWebsite-27     at _makeTimerTimeout (timers.js:528:3)
CosWebsite-27     at Timer.unrefTimeout (timers.js:597:5)
... times 6
CosWebsite-27 GET /clans/compas-c-r-98QP9J2G/members 500 10569.300 ms - 9893
CosWebsite-27 GET /players/1000-99JQVQ9VU 500 12388.484 ms - 9849
CosWebsite-27 GET /players/R0YUPPRR/profile 500 8204.622 ms - 9857
CosWebsite-27 GET /players/UG8YJUJY/profile 500 4622.819 ms - 9857
CosWebsite-27 GET /clans/next-state-P8RYGQYV 500 11526.859 ms - 9861
CosWebsite-27 GET /clans/YY2CCUVV 500 6755.380 ms - 9817

Как видите, ни один запрос не длился более 12 секунд. Мой коннектор мангуста настроен следующим образом:

const mongoDB = {
    uri: "mongodb://127.0.0.1:27017/XXX",
    options: {
        host: '127.0.0.1',
        port: '27017',
        database: "XXX",
        compression: false,
        server: {
            poolSize: 5,
            auto_reconnect: true,
            socketOptions: {
                socketTimeoutMS: 0,
                connectTimeoutMS: 0
            }
        },
        promiseLibrary: Promise
    }
};

Любая идея, что может пойти не так?

@adrienbaron Я тоже!!!
кто-нибудь, пожалуйста, помогите мне.

Кто-нибудь отправляет отчет об ошибке разработчикам собственного драйвера mongo?

эта проблема все еще существует в 4.9.1?

Да, проблема все еще существует в 4.9.1....

мангуст@4.9.1
монгодб@2.2.25
[email protected]

Была такая же проблема сегодня после обновления до последней версии мангуста, чем я понизил версию до 4.7.1, и все работает отлично!

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

Я обновил Mongoose с 4.4.17 до 4.7.9 около месяца назад. С тех пор ежедневный cronjob выдавал ошибку три раза, всегда с ошибкой тайм-аута подключения mongo.

Я переключусь на Mongoose 4.7.1 и посмотрю, поможет ли это.

редактировать: сообщение об ошибке

2017-04-19 03:09:23: You have triggered an unhandledRejection, you may have forgotten to catch a Promise rejection:
MongoError: connection 261 to localhost:27017 timed out
    at Function.MongoError.create (/var/www/someproject/node_modules/mongodb-core/lib/error.js:29:11)
    at Socket.<anonymous> (/var/www/someproject/node_modules/mongodb-core/lib/connection/connection.js:186:20)
    at Socket.g (events.js:286:16)
    at emitNone (events.js:86:13)
    at Socket.emit (events.js:185:7)
    at Socket._onTimeout (net.js:333:8)
    at tryOnTimeout (timers.js:224:11)
    at Timer.listOnTimeout (timers.js:198:5)

@centigrade-thomas-becker У меня была такая же проблема больше месяца в продакшене, вчера я вернулся к 4.7.1, проблем больше нет!

такая же проблема возникает @ 4.7.7

С Mongo 4.7.1 проблем меньше, чем с 4.7.9, но я все еще иногда получаю сообщение об ошибке при сохранении в MongoDB:

2017-04-30 03:09:32: Error: connection timeout
    at .<anonymous> (/var/www/someproject/node_modules/mongoose/lib/drivers/node-mongodb-native/connection.js:168:17)
    at emitTwo (events.js:106:13)
    at emit (events.js:191:7)
    at listener (/var/www/someproject/node_modules/mongodb/lib/db.js:1791:14)
    at emitOne (events.js:96:13)
    at emit (events.js:188:7)
    at .<anonymous> (/var/www/someproject/node_modules/mongodb/lib/server.js:270:14)
    at g (events.js:286:16)
    at emitOne (events.js:96:13)
    at emit (events.js:188:7)
    at .<anonymous> (/var/www/someproject/node_modules/mongodb-core/lib/topologies/server.js:322:12)
    at emitOne (events.js:96:13)
    at emit (events.js:188:7)
    at .<anonymous> (/var/www/someproject/node_modules/mongodb-core/lib/connection/pool.js:271:12)
    at g (events.js:286:16)
    at emitTwo (events.js:106:13)
    at emit (events.js:191:7)
    at Socket.<anonymous> (/var/www/someproject/node_modules/mongodb-core/lib/connection/connection.js:175:10)
    at Socket.g (events.js:286:16)
    at emitNone (events.js:86:13)
    at Socket.emit (events.js:185:7)
    at Socket._onTimeout (net.js:333:8)
    at tryOnTimeout (timers.js:224:11)
    at Timer.listOnTimeout (timers.js:198:5)

Ошибка возникает на виртуальной машине Linux под управлением Ubuntu 15.04.

То же самое здесь с:

├─┬ [email protected]
│ ├─┬ [email protected]
│ │ ├── [email protected]

версия монго @ 3.2.11

на AWS EC2.

Любое обновление/обходной путь? Будет ли keepAlive: true иметь положительный эффект?

Не уверен, что это кому-нибудь поможет, но в нашем случае мы заметили, что передавали параметры тайм-аута ( socketTimeoutMS и т. д.) через options.server . Это было _неправильно_! Мы используем набор реплик, поэтому наши параметры должны быть следующими:

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

const serverOptions = {
  poolSize: 100,
  socketOptions: {
    socketTimeoutMS: 60000
  }
};

mongoose.createConnection(dbpath, {
  server: serverOptions,
  replset: serverOptions
});

Надеюсь, это поможет кому-то!

Всем привет,
Я использую mlab для размещения своей базы данных. я получаю эту ошибку
Ошибка подключения Mongo DB: {[MongoError: подключение 0 к ds155841.mlab. com:xxxxx истекло время ожидания'}

@RemeAjayi Я думаю, что это не имеет ничего общего с этим билетом.
Вы должны попробовать/создать еще один после изучения проблемы.

@ht2 ты спас мой день ❤️

Есть ли жизнеспособное решение исходной проблемы?

На случай, если это кому-нибудь поможет, я столкнулся с этой проблемой при распараллеливании 2 жестоких запросов find() (с использованием шаблона Promise).

Превращение

Promise.all([
  col1.find({longQuery: true}),
  col2.find({longQuery: true})
])
.spread(function(result1, result2) {
  //stuff
});

в последовательный подход

col1.find({longQuery: true})
.then(function(result1) {
  return Promise.all([
    result1,
    col2.find({longQuery: true})
  ]);
})
.spread(function(result1, result2) {
  //stuff
});

Сделал это работать

@cyrilchapon думал, что это работает для меня, но ваш последовательный подход не решил мою проблему :/

переодически..иногда работает,иногда вылетает..

Почему это тихое закрытие?

Продолжение моего предыдущего комментария https://github.com/Automattic/mongoose/issues/4789#issuecomment -298849907

Я переместил проблемную базу данных с виртуальной машины в док-контейнер с новым linux, nodeJS и mongoDB. Я создал стресс-тест, который не делает ничего, кроме усечения и повторного заполнения базы данных в течение всего дня. Я обнаружил, что примерно 1 из 6000 тестов приводит к ошибке тайм-аута.

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

Но обновление узла до одной из его последних версий вместе со всеми другими приложениями, по-видимому, помогло.

Теперь, с комментарием выше, я считаю, что это вопрос устаревшей ошибки.

У меня также была такая же проблема с mongo 3.6.2 и mongoose 4.9.2
Я исправил это, передав дополнительные параметры подключения

MONGO_URI=mongodb://user:[email protected]:27017/dbname?keepAlive=true&poolSize=30&autoReconnect=true&socketTimeoutMS=360000&connectTimeoutMS=360000

@mzahidriaz Большое спасибо, ваши решения работают для меня, но не могли бы вы объяснить или дать ссылку на то, как вы выбрали эти параметры для решения этой проблемы?

@MinhNguyen41092 MinhNguyen41092 прямо сейчас единственными документами являются документы драйвера MongoDB http://mongodb.github.io/node-mongodb-native/3.1/api/MongoClient.html#connect . мы добавим подробности об этом на http://mongoosejs.com/docs/connections.html.

Для тех, кто испытывает периодические ошибки, у меня они тоже были на mongoose-4.13.11 с mongodb-2.2.35 mongodb-core-2.1.19 в определенной среде. Различные запросы в разных точках нашего набора тестов, хотя в основном тестировалась одна конкретная часть нашего приложения, которая имеет более тяжелые запросы и выполняет действия в параллельном IIRC, все получали это сообщение об ошибке. И для запуска всего набора тестов даже не требуется 15 секунд, поэтому я никоим образом не должен был использовать встроенные тайм-ауты по умолчанию в 30 секунд:

     MongoError: connection 0 to localhost:27017 timed out
      at Function.MongoError.create (node_modules/mongoose/node_modules/mongodb-core/lib/error.js:29:11)
      at Socket.<anonymous> (node_modules/mongoose/node_modules/mongodb-core/lib/connection/connection.js:200:20)
      at Socket._onTimeout (net.js:448:8)

Это произошло только на нашем сервере тестовой сборки CI. Я не мог воспроизвести это на своей машине разработчика.

(В моей собственной системе (частное репозиторий, это для моей справки на случай, если когда-нибудь снова понадобится выкопать это), эта ошибка проявляется, по крайней мере, в номерах сборки: 358, 356, 355, 352).

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

Я думаю, @thenitai @steve-p-com @adrienbaron тоже столкнулись со странными фальшивыми тайм-аутами. Я думаю, что ошибка происходила с вами, ребята, до того, как вышла версия 4.11, которая даже предлагала useMongoClient: true в качестве опции. Можете ли вы сказать, повлияло ли это на ваши рабочие нагрузки?

[email protected]
монгодб@2.2.26
мангуст @ 4.9.10
Такая же проблема, 1,5М ошибок в руле за пару дней, с чем это может быть связано? Как решить?

@SergeyVatz смотрите ответ на свой вопрос в #5376