您要请求功能还是报告错误?
一个错误。
目前的行为是什么?
更新到 Mongoose 5.7.1 后,出现如下警告:
(node:41563) DeprecationWarning: current Server Discovery and Monitoring engine is deprecated, and will be removed in a future version. To use the new Server Discover and Monitoring engine, pass option { useUnifiedTopology: true } to the MongoClient constructor.
at parseFn (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/mongoose/node_modules/mongodb/lib/operations/connect.js:312:5)
at parseConnectionString (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/mongoose/node_modules/mongodb/lib/core/uri_parser.js:628:3)
at connect (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/mongoose/node_modules/mongodb/lib/operations/connect.js:266:3)
at ConnectOperation.execute (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/mongoose/node_modules/mongodb/lib/operations/connect.js:191:5)
at executeOperation (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/mongoose/node_modules/mongodb/lib/operations/execute_operation.js:83:26)
at MongoClient.connect (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/mongoose/node_modules/mongodb/lib/mongo_client.js:216:10)
at Promise (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/mongoose/lib/connection.js:632:12)
at Promise._execute (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/bluebird/js/release/debuggability.js:313:9)
at Promise._resolveFromExecutor (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/bluebird/js/release/promise.js:488:18)
at new Promise (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/bluebird/js/release/promise.js:79:10)
at NativeConnection.Connection.openUri (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/mongoose/lib/connection.js:629:19)
at Mongoose.connect (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/mongoose/lib/index.js:327:15)
at Object.connect (/Users/tschaffter/dev/PHCCollaborationPortal/server/app.js:17:44)
at Module._compile (internal/modules/cjs/loader.js:778:30)
at Module._compile (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/pirates/lib/index.js:99:24)
at Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Object.newLoader [as .js] (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/pirates/lib/index.js:104:7)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require (internal/modules/cjs/helpers.js:25:18)
at Object.<anonymous> (/Users/tschaffter/dev/PHCCollaborationPortal/server/index.js:12:28)
at Module._compile (internal/modules/cjs/loader.js:778:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
我按照消息的建议将useUnifiedTopology: true
到我的 mongoose 配置对象中,即使我没有使用 MongoDB 副本集或分片集群。 以下是我使用 mongoose 配置和连接的方法:
``` 蒙戈:{
选项: {
// https://mongoosejs.com/docs/deprecations.html
useNewUrlParser: 真,
useFindAndModify: 假,
使用创建索引:真,
useUnifiedTopology: true,
重新连接尝试:30,
reconnectInterval: 500, // 以毫秒为单位
}
},
and here is where I used this `mongo.options` object:
// 连接到MongoDB
const mongooseConnectionPromise = mongoose.connect(config.mongo.uri, config.mongo.options);
mongoose.connection.on('错误', 错误 => {
console.error( MongoDB connection error: ${err}
);
process.exit(-1); // eslint-disable-line no-process-exit
});
The warning is gone but the issue is that mongoose is now no longer able to connect:
MongoDB 连接错误:MongoTimeoutError:服务器选择在 30000 毫秒后超时
[nodemon] 应用程序崩溃 - 在开始之前等待文件更改...
Here is how I run MongoDB using docker during development:
docker run -p ${MONGO_PORT}:${MONGO_PORT} --name mongo -d mongo
``
如果当前行为是错误,请提供重现步骤。
看上面
什么是预期行为?
猫鼬应该删除弃用警告并在使用useUnifiedTopology: true
时正常运行 mongoose 建议。
您使用的 Node.js、Mongoose 和 MongoDB 是什么版本?
节点:v10.16.2
猫鼬:5.7.1(最新)
MongoDB:数据库版本 v4.2.0
你使用什么docker镜像? 另外,您是否有“服务器选择超时”消息的堆栈跟踪?
嘿,只是戳这里报告我有同样的问题。
我自己没有使用 Docker 或任何虚拟机。 还要注意的是,这似乎并不是一直发生,但是今天由于超时(30k),我无法检索我的任何数据,并且在删除useUnifiedTopology
标志后问题立即得到解决.
我正在连接到 Atlas 集群。
猫鼬是 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我正在使用提供 MongoDB v4.2.0 的最新mongo
图像。
https://hub.docker.com/_/mongo
添加 { useUnifiedTopology: true } 后,我也遇到了同样的错误,尽管错误是随机发生的。 肯定有问题。 我正在使用最新的 mongo 图像。
猫鼬
.connect(process.env.MONGO_URI, {
useUnifiedTopology: true,
useNewUrlParser: 真,
})
.then(() => console.log('DB Connected!'))
.catch(错误 => {
控制台日志(错误,错误消息);
});
当它开始时,我进入控制台:
[函数:错误] { stackTraceLimit: 16, prepareStackTrace: undefined } connection 0 to acccluster-shard-00-01-xx47j.mongodb。 净值:27017关闭
任何解决方案? 即使我现在也面临这个问题......
我有同样的问题。 我是一名初级程序员,这是我第一次使用 nodejs-express-graphql-mongoose-mongodbAtlas。
(node: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] 弃用警告:不推荐使用未处理的承诺拒绝。 将来,未处理的承诺拒绝将以非零退出代码终止 Node.js 进程。
事件.js:174
扔er; // 未处理的“错误”事件
^
错误:读取 ECONNRESET
在 TLSWrap.onStreamRead (internal/stream_base_commons.js:111:27)
在以下位置发出“错误”事件:
在 TLSSocket。
在 Object.onceWrapper (events.js:286:20)
在 TLSSocket.emit (events.js:198:13)
在emitErrorNT (internal/streams/destroy.js:91:8)
在emitErrorAndCloseNT (internal/streams/destroy.js:59:3)
在 process._tickCallback (internal/process/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 }。 我希望社区中的某个人可以关注这个问题并解决它或提供一些建议来解决它。
在使用useUnifiedTopology时,我也遇到了两个错误(服务器选择在 30000 毫秒后超时和MaxListenersExceededWarning: 检测到可能的 EventEmitter 内存泄漏。11 )所以我猜每个使用这个选项的人都会发生这种情况。
我试图重现这个,但我无法重现。 我尝试了几个选项:
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 模块?
我相当确信这不是猫鼬的问题,而是 Mongo 本身的问题。
@vkarpov15 ,请看我的评论,我在那里概述了我的环境。 我直接使用猫鼬。
@vkarpov15对我来说,这个问题在服务器运行时每 2-3 天随机出现一次,因此即使我为您提供代码,您也必须持续监控服务器。
有没有人解决过这个问题?
有没有人解决过这个问题?
您暂时不能使用此标志。 Mongo 会警告你它会在将来被禁用或其他什么的,但目前它似乎完全解决了这个问题。
有没有人解决过这个问题?
您暂时不能使用此标志。 Mongo 会警告你它会在将来被禁用或其他什么的,但目前它似乎完全解决了这个问题。
当我不使用标志 useUnifiedTopology: true 时,我遇到了这个错误并且应用程序停止了,
猫鼬版本:5.7.4
可以确认将useUnifiedTopology
注释掉解决了我构建中的问题。 也以(显然)随机的方式发生。
@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)
我们也有这个问题,我们不使用猫鼬。 Node.js 本身的 MongoDB 驱动程序似乎有问题。 该问题也已在此处报告https://jira.mongodb.org/browse/NODE-2249
今天发布的 3.3.3 版驱动程序应该向MongoTimeoutError
添加更多细节。 由于错误修复,还建议更新驱动程序。
此错误是驱动程序无法连接到满足给定操作(或初始连接)的读取首选项的服务器的结果。 这可能有多种原因,包括您的连接字符串无效或集群中的节点已关闭。 如果您更新到最新的 v3.3.3 驱动程序,我们会在 MongoTimeoutError 中包含一个新的原因字段,这将有助于我们进一步调查您的问题。 此外,此版本包含一个错误修复,如果副本集的任何成员不可用,则会导致初始连接超时错误。 请更新您的驱动程序,如果您继续遇到此问题,请告诉我们。
同样在这里,发生在开发和生产中,连接到 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));
}
}
我最好的猜测是@rvanmil的解释是正确的。 尝试升级到[email protected] (我将在几个小时内发送)并查看此问题是否仍然存在。
另外,有没有人知道是否有办法在 Atlas 中触发重启? 也许只有在使用 Atlas 时才会出现此问题?
@vkarpov15我认为您必须暂停/恢复集群才能触发重启。 仅适用于 M10+ 尺寸。
我也想知道这是否可能是 Atlas 问题。 我还没有能够测试更新的 MongoDB 驱动程序,但我会在测试后在这里报告。
无论 useUnifiedTopology 标志如何,我今天在 Atlas 免费层上也遇到了同样的问题。 错误: MongoTimeoutError: Server selection timed out after 30000 ms
我可以使用其他 MongoDB 服务(例如 mLab)建立连接。
我遇到了同样的问题,结果有点愚蠢,但无论如何我都会分享它,因为它可能也会帮助到这里的人。
我检查了 MongoTimeoutError 中的“原因”字段,它说“MongoError: bad auth Authentication failed”。
那时我意识到我在连接字符串中使用了 mongoDB 密码,而不是用户密码。
现在它工作正常。
如果您使用的是 MongoDB Atlas,您应该将您的 IP 地址列入白名单。
转到网络访问,编辑当前的 IP 地址,然后单击允许从任何地方访问。
我只在使用 Atlas 时遇到这个问题。 我曾尝试在白名单中添加0.0.0.0/0
IP,但它也不起作用。
我在用:
无法在本地 mongodb 服务器中重现。 在那里,每个查询都可以成功运行。
这与访问无关。 我有 0/0/0/0 访问权限,这发生了
每次服务器在地图集上重新启动。 您可以通过制作多节点来重现
集群 (m10+) 并设置计划维护时间。 然后跑很久
运行服务,它应该在重新启动时产生错误。
2019 年 10 月 23 日星期三上午 7:42 Mohammad Mazedul Islam,<
[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=AAUHUCYYQIQ5U42IBYT7CQTQQA2B7A5CNFSM4IYQ3ZB2YY3PNVWWK3TUL52HS4DFVREXG43MVVMVBWJKZ3043MVVWWWZHW604040000000000000000000000000000000000000000000000000000000005
或取消订阅
https://github.com/notifications/unsubscribe-auth/AAUHUCY5SNFGGCPTGW6GH5DQQA2B7ANCNFSM4IYQ3ZBQ
.
我以前也有这个问题。 但是现在将 0.0.0.0/0 和我的 IP 地址都从 atlas 加入白名单后解决了这个问题。
~这只是MongoDB Atlas的问题~
我在使用 MongoDB Atlas 时遇到了一些问题。
我在使用普通 MongoDB 时遇到了同样的问题。
我已经使用 docker-compose 成功重现了导致“MongoTimeoutError:服务器选择在 30000 后超时”的情况。
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你能用最新的 3.3.3 mongodb 库试试吗?
@rvanmil我可以在 ver3.3.3 中重现它。
当 mongoDB 处于复制配置并且其中一个实例(可能是主实例)在它关闭之前或启动之后收到命令时,似乎会发生此错误。
我认为MongoDB Atlas 上经常出现这种情况的原因是MongoDB Atlas 定期向集群发送查询以进行监控。
任何解决方案? 这个问题是......
同样的问题1个多月了还没解决-_-
更新到[email protected]为我解决了这个问题。
@octavioamu你能提供更多细节吗? 您在 4.2 之前运行的是哪个版本的 MongoDB 数据库 [集群]? 您使用的是什么版本的 mongoose 和 mongodb npm 包,您是否升级了这些包? 您运行 4.2 有多久了才能确信它已在此版本中解决?
抱歉不知道安装了什么版本,可能是一个很旧的版本,因为我有一段时间没有使用 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"
超时问题就会消失。 也许这个问题与身份验证有关? 这是在我的本地设置中重现问题的 MWE:
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 atlas,我们面临同样的问题。
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 })
在此之后,如果超时出现,您需要通过转到 mongoDB 中的网络访问将您的 ip 地址从 mongoDB 列入白名单
像其他人一样,此错误每隔几天就会使我的应用程序崩溃,我可以确认这与 IP 地址的访问或白名单无关。
我在用:
现在,我也将注释掉useUnifiedTopology: true
。 正如其他人所说,它似乎可能与 Atlas 或 mongo 有关。
https://jira.mongodb.org/browse/NODE-2267
@vkarpov15可能可以关闭此问题,因为它与猫鼬无关。
当您当前的 ip 地址因某种原因更改连接失败时,您应该在网络访问 ip 白名单中编辑它并使用当前 ip
你好! 我叫马特,是 MongoDB 的司机团队成员。 对于你们一直面临的中断,我们感到非常抱歉,我想就这个问题提供一些更新:
我们正在尝试逐步淘汰我们的传统拓扑类型,结果证明这是一个非常外科手术的过程。 逐步淘汰这些类型将有助于大大减轻驱动程序的维护负担,我们希望这意味着为我们的用户提供更稳定、更高效的驱动程序。 特别是,在引入“统一拓扑”的同时,我们并没有引入连接池的重写,以减少出错的可能性。 事实证明,连接池与拓扑类型的耦合比我们预期的要紧密,因此我们经历了一些回归,尤其是在服务器监控方面。
今天早上我推送了一个v3.3.4-rc0驱动程序,它应该可以解决您遇到的问题。 如果您能试用此版本并报告您的体验,我们将不胜感激。 我已经在NODE-2267上对与此问题相关的每个现有票证发表了评论,但如果您遇到这些问题,请随时在那里打开其他问题。
我可以确认3.3.4-rc0已经修复了问题👍稍后我会提供更详细的测试结果。
在我将 package.json 中的 mongodb 版本更改为
"mongodb": "3.3.4-rc0",
我总是收到错误(当 mongodb 版本为 3.3.3 时不会发生此错误):
==============================================
错误! 路径 /tmp/app/node_modules/npm/node_modules/abbrev
错误! 代码 ENOENT
错误! 错误号 -2
错误! 系统调用重命名
错误! enoent ENOENT: 没有这样的文件或目录,重命名 '/tmp/app/node_modules/npm/node_modules/abbrev' -> '/tmp/app/node_modules/npm/node_modules/.abbrev.DELETE'
错误! enoent 这与 npm 无法找到文件有关。
错误! 恩恩特
错误! 可以在以下位置找到此运行的完整日志:
错误! /home/vcap/.npm/_logs/2019-11-06T17_19_55_661Z-debug.log
[31;1m ERROR [0m 无法构建依赖项:退出状态 254
无法编译 droplet:无法运行所有供应脚本:退出状态 14
退出状态 223
==================================
我的 npm 版本是 6.11.3 的 npm。
这个错误是否与这个新的 mongodb v3.3.4-rc0 版本有关?
@zhenwan这看起来像是下载abbrev
包的问题。 我的猜测是您的package-lock.json
存在问题,请尝试删除该文件并再次运行npm install
。
我能够重现该错误并使用以下设置检查它是否已通过 v3.3.4-rc0 驱动程序解决:
GET /api/todos
,它查询包含一些示例数据的todo
MongoDB 集合本次测试结果如下:
✅ 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 提供数据。 但是仍然存在两个问题:
@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 抛出错误
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 at Timeout.setTimeout [as _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] 超时错误 (timers.js:469:11)
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] 在 tryOnTimeout 时出错 (timers.js:304:5)
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] 在 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
mongodb
最新版本,如下所示
"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
完毕! 谢谢
NODE-2313
@mbroadst哈! 抱歉这个尴尬的名字!
事实证明,我可能说得太早了,也许是考虑到错误出现的随机性。 在我的应用程序冷启动时,连同预期的弃用警告,我现在在日志中看到这个稍微可怕的错误:
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 和可怕的用户体验不时出现错误。 这似乎是一个新问题。
如上所述,设置useUnifiedTopology: false
(或注释掉)的解决方法可防止此问题中的错误,但恢复了弃用警告,现在恢复了上面稍微可怕的 MongoNetworkError。 顺便说一句,这实际上并没有杀死我的应用程序,但确实让我担心它会在某个时候为用户服务。
@bigsee您遇到的MongoNetworkError
并不新鲜,这意味着驱动程序无法与集群建立初始连接(顺便说一句,如果您的应用程序启动和集群启动之间的某种竞争条件导致这,那么统一拓扑在这里也应该有所帮助)。
这个问题的关键是人们遵循使用统一拓扑的指导,当他们这样做时,他们遇到了虚假的超时错误。 v3.3.4-rc0
是为解决该特定问题而发布的,因此当前的指南是使用该版本,该版本应删除弃用通知并纠正人们遇到的虚假超时问题。
我还应该说:这个版本不会阻止 _all_ 超时错误。 该错误是由驱动程序无法初始连接到集群引起的,这表明您的某种配置(连接字符串)或网络错误。 使用统一拓扑,这将显示为MongoTimeoutError
和reason
字段,指示导致初始连接超时的网络错误。
@mbroadst我并不是要在我的上一条评论中暗示MongoNetworkError
是新的,所以如果它是这样读的,我深表歉意。 这是新的`MongoTimeoutError。 希望更清楚,这是我的过程:
useUnifiedTopology: true
- 一切正常MongoTimeoutError
匹配此问题的标题,以及上面显示的堆栈跟踪的前几行useUnifiedTopology: false
解决方法MongoTimeoutError
错误随着应用程序的崩溃而消失。 但是,它最初被弃用警告取代。 然后,稍后,通过设置useUnifiedTopology: false
之前在应用程序中未看到的额外MongoNetworkError
useUnifiedTopology: false
也许,正如你所建议的,这是相关性而不是因果关系。 对我来说就像是一支吸烟枪。 至少应用程序现在没有崩溃。 我只是担心留下一个已弃用的选项。
@bigsee啊! 抱歉,我误读了您的原始评论,这意味着您确认v3.3.4-rc0
错误修复解决了v3.3.3
。 你有机会尝试新版本吗?
这是我在 Mongodb 上的第一次试用,我遇到了这个错误。 通读评论并将我的数据库更改为 v3.3.4-rc0 并且它仍然没有修复错误
弃用警告:不推荐使用当前的服务器发现和监控引擎,并将在未来版本中删除。 要使用新的服务器发现和监控引擎,请将选项 { useUnifiedTopology: true } 传递给 MongoClient 构造函数。
MongoNetworkError:无法连接到服务器 [cluster0-shard-00-00-rhdve.mongodb。 net:27017 ] 第一次连接 [MongoNetworkError: connection 3 to cluster0-shard-00-00-rhdve.mongodb。 净值:27017关闭
在 TLSSocket。
在 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',
错误标签:[数组],
}]
在游泳池。
在 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。
name: 'MongoNetworkError',
错误标签:['TransientTransactionError'],
}
类型错误:无法读取未定义的属性“查找”
在 C:laragonwwwVue-express-mongodbserverroutesapiposts.js:12:26
@Syfon01您遇到的错误是由于某种配置错误,驱动程序正在使用旧拓扑,并且在默认 10 秒后未能与集群建立初始连接。 请检查您的连接字符串和网络配置,并验证您是否能够连接到集群(可能使用mongo
shell)。 如果您仍然遇到问题,请打开jira 票,以便我们可以在那里继续对话,并且不要让查看此 GitHub 问题的人感到困惑
对于遇到此问题的人,如果您使用的是 Mongo Atlas 云实例,请查看您是否在网络访问选项卡中正确指定了您的 IP 地址。
我遇到了这个问题,似乎因为我的 ISP 每次(DHCP)重新连接到网络时都会发出新 IP,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没有任何意义你基本上使用回调函数而不是promise,结果仍然是一样的,唯一的区别是在回调函数中你同时获得了连接和回调函数中的错误您没有记录而不是依赖 .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 地址。
我遇到了这个问题,似乎因为我的 ISP 每次(DHCP)重新连接到网络时都会发出新 IP,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 安装不正确的选项。 现在我可以在没有 Compass 的情况下进行连接,并且一切似乎都有效,只是一开始就做了一次。
我遇到了同样的问题,感谢这个论坛,通过评论 useUnifiedTopology 设置解决了这个问题。 但是后来我取消了这个设置的注释,但现在它仍然可以正常工作......很困惑......
Mongoose v5.7.11 使用了新发布的 MongoDB 驱动程序 3.3.4,所以我打算关闭这个 issue。 如果您收到类似的错误消息,请打开一个新问题并遵循问题模板。
最有用的评论
你好! 我叫马特,是 MongoDB 的司机团队成员。 对于你们一直面临的中断,我们感到非常抱歉,我想就这个问题提供一些更新:
我们正在尝试逐步淘汰我们的传统拓扑类型,结果证明这是一个非常外科手术的过程。 逐步淘汰这些类型将有助于大大减轻驱动程序的维护负担,我们希望这意味着为我们的用户提供更稳定、更高效的驱动程序。 特别是,在引入“统一拓扑”的同时,我们并没有引入连接池的重写,以减少出错的可能性。 事实证明,连接池与拓扑类型的耦合比我们预期的要紧密,因此我们经历了一些回归,尤其是在服务器监控方面。
今天早上我推送了一个v3.3.4-rc0驱动程序,它应该可以解决您遇到的问题。 如果您能试用此版本并报告您的体验,我们将不胜感激。 我已经在NODE-2267上对与此问题相关的每个现有票证发表了评论,但如果您遇到这些问题,请随时在那里打开其他问题。