Mongoose: 没有可用的主服务器

目前没有任何进展。 您确定没有mongodb服务器崩溃吗？ 另外，您可以使用外壳保持稳定的连接吗？

在发生错误时运行命令db.runCommand( { replSetGetStatus : 1 } )会在所有3个节点上生成"health" : 1, 。 其中一个节点上还有一个主集"stateStr" : "PRIMARY", 。

您是否使用相同的连接字符串和DNS进行连接？ 在问题发布后，您的存储空间似乎也已排成一排，您是否可以仔细检查一下，看看一台计算机上的硬盘驱动器空间是否用完了？

您是否使用相同的连接字符串和DNS进行连接？

我没有使用相同的连接字符串。 您是否认为使用私有EC2 IP地址可以解决此问题？

不知道是什么原因导致存储空间达到最大值，但是即使在启动新实例之后，仍然没有主服务器的问题仍然存在，因为有足够的可用空间。

EC2 IP地址可能有所帮助，具体取决于副本集的配置方式。 您能告诉我rs.status()从shell的输出吗？

当连接不断增加时，这就是rs.status（）。

{
    "set" : "mongo2",
    "date" : ISODate("2015-12-04T23:39:32.520Z"),
    "myState" : 1,
    "members" : [
        {
            "_id" : 6,
            "name" : "mongo-8.loc.0600.mongodbdns.com:27000",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 444053,
            "optime" : Timestamp(1449272372, 32),
            "optimeDate" : ISODate("2015-12-04T23:39:32Z"),
            "lastHeartbeat" : ISODate("2015-12-04T23:39:32.507Z"),
            "lastHeartbeatRecv" : ISODate("2015-12-04T23:39:31.442Z"),
            "pingMs" : 0,
            "syncingTo" : "mongo-9.loc.0600.mongodbdns.com:27000",
            "configVersion" : 29
        },
        {
            "_id" : 7,
            "name" : "mongo-9.loc.0600.mongodbdns.com:27000",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 444056,
            "optime" : Timestamp(1449272372, 39),
            "optimeDate" : ISODate("2015-12-04T23:39:32Z"),
            "electionTime" : Timestamp(1449097485, 1),
            "electionDate" : ISODate("2015-12-02T23:04:45Z"),
            "configVersion" : 29,
            "self" : true
        },
        {
            "_id" : 8,
            "name" : "mongo-10.loc.0600.mongodbdns.com:27000",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 444053,
            "optime" : Timestamp(1449272371, 111),
            "optimeDate" : ISODate("2015-12-04T23:39:31Z"),
            "lastHeartbeat" : ISODate("2015-12-04T23:39:31.904Z"),
            "lastHeartbeatRecv" : ISODate("2015-12-04T23:39:30.903Z"),
            "pingMs" : 2,
            "syncingTo" : "mongo-8.loc.0600.mongodbdns.com:27000",
            "configVersion" : 29
        }
    ],
    "ok" : 1
}

副本集中没有任何异常。 您是否还有其他相关代码示例，例如，是否有任何对猫鼬连接事件起反应的代码？

另一个值得考虑的潜在问题是，您是否正在使用最新的新遗物代理？ 我会尝试在没有新文物的情况下运行，看看这种情况是否仍会发生，新文物猴子会修补mongodb驱动程序，以便有时可能导致意外行为。

我们一直在输出猫鼬连接事件：

['connecting', 'connected', 'open', 'disconnecting', 'disconnected', 'close', 'reconnected', 'error', 'fullsetup'].forEach(function(name) {
  mongoose.connection.on(name, function() {
    notifySlack('Mongoose event: ' + name);
  });
});

这是一些日志的样子

​[4:30] Mongoose event: fullsetup
​[4:30] Mongoose event: reconnected
​[4:30] Mongoose event: open
​[4:30] Mongoose event: connected
​[4:30] Mongoose event: reconnected
​[4:30] Mongoose event: reconnected
​[4:30] Mongoose event: reconnected
​[4:30] Mongoose event: reconnected
​[4:30] Mongoose event: reconnected
​[4:30] Mongoose event: reconnected
​[4:30] Mongoose event: fullsetup
​[4:30] Mongoose event: connected
​[4:30] Mongoose event: open
​[4:30] 
{
 "err": {
   "name": "MongoError",
   "message": "no primary server available"
 }
}

我本周参加了mongodb的几天活动，在那里我可以安排一些时间并向MongoDB的一位高级工程师展示此问题，他们不确定是什么问题。 他们确实提到将复制集和最大池大小添加到连接字符串中，但不幸的是，该问题尚未解决。

我们还尝试禁用了保持活动状态，并在实例上将其设置为较小的值，但这似乎也无法解决。

我们正在使用newrelic版本1.24.0和mongo-express-patch版本0.21.1 。 我将尝试在没有newrelic的情况下运行，以查看是否可以解决此问题。

嗯，确实看起来是猫鼬由于某种原因重新连接了。 您能告诉我npm list | grep "mongoose"和npm list | grep "mongo"吗？

$ npm list | grep "mongoose"
├─┬ [email protected]

$ npm list | grep "mongo"
├─┬ [email protected]
│ ├─┬ [email protected]
│ │ ├─┬ [email protected]
├─┬ [email protected]
├─┬ [email protected]
│ ├─┬ [email protected]
│ │ ├── [email protected]

您正在将mongodb-core用于什么？ 另外，您是否在产品中启用了mongo-express ？

当前未使用mongodb-core进行任何操作。 您是否认为猫鼬依赖项之间的版本不匹配可能会导致问题？

我们确实在生产中启用了mongo-express 。

从来没听说过。 我只是想看看是否有其他连接到mongodb可能会导致此问题。 我已经做了一些谷歌搜索-您是否为连接字符串使用与rs.status()中显示的DNS名称相同的DNS名称？ 据此，如果您使用与副本集所认为的不同的DNS作为连接字符串，则可能会遇到类似的问题。

当在连接字符串中使用与rs.status()的“ syncingTo”属性相同的DNS时，将发生此错误。 当在连接字符串中使用内部ec2 IP时，也会发生这种情况。

我还没有尝试过的唯一事情就是将connectWithNoPrimary为true 。

我也尝试使用mongo-express折扣运行。 那可能导致问题...

我们遇到了同样的问题。 我们有一个站点正在承受约100 RPM的持续负载，峰值在500-700 rpm +。 似乎我们在整个过程中都看到了这一点，即使是在相当长的一段时间内。

环境：
Heroku-75 2x dynos-Node.JS 5.1.1
数据库-MongoLabs专用集群M4-版本3.0.7

连接字符串：
mongodb：// _： * _ @ ds043294-a0.mongolab。 com：43294 ，ds043294-a1.mongolab。 com：43294 / heroku_hf8q79dt？replicaSet = rs-ds043294

NPM：

npm list | grep "mongoose"
├─┬ [email protected]
├── [email protected]
├── [email protected]
├─┬ [email protected]

Connection.js

// Mongoose import
var mongoose = require('mongoose');
var options = {
    server: {
        socketOptions: {
            keepAlive: 1,
            poolSize: 10,
            connectTimeoutMS: 30000,
            socketTimeoutMS: 30000
        }
    },
    replset: {
        socketOptions: {
            keepAlive: 1,
            poolSize: 10,
            connectTimeoutMS: 30000,
            socketTimeoutMS: 30000
        }
    }
};

mongoose.connect((process.env.MONGOLAB_URI || "mongodb://localhost/test"), options, function(error) {
    if (error) {
        console.log(error);
    }
});

module.exports = {
    mongoose: mongoose
};

正在记录：
我们已经启用了大量监视以尝试对此进行调试，因此我将Raygun堆栈跟踪包括在内，即使这将有助于调试。 _注意：_这与@ChrisZieba在上面的跟踪中显示的行号

消息：没有主服务器可用
/app/node_modules/mongodb-core/lib/topologies/replset.js中的Object.pickServer：860
/app/node_modules/mongodb-core/lib/topologies/replset.js中的ReplSet.ReplSet.command：437
/app/node_modules/mongodb/lib/replset.js中的ReplSet.ReplSet.command：392
/app/node_modules/mongodb/lib/db.js中的Object.executeCommand：281
/app/node_modules/mongodb/lib/db.js中的db.db.command：305
Object.wrapped在/app/node_modules/newrelic/lib/instrumentation/mongodb.js:185中
/app/node_modules/mongodb/lib/collection.js中的Object.findAndModify：2327
/app/node_modules/mongodb/lib/collection.js中的Collection.Collection.findAndModify：2265
Object.wrapped在/app/node_modules/newrelic/lib/transaction/tracer/index.js:155中
/app/node_modules/newrelic/lib/instrumentation/mongodb.js中的Object.wrappedQuery：218
Object.wrapped在[as findAndModify]中（/app/node_modules/newrelic/lib/instrumentation/mongodb.js:188
NativeCollection.NativeCollection。（在函数中匿名）[如findAndModify]（/app/node_modules/mongoose/lib/drivers/node-mongodb-native/collection.js:136
/app/node_modules/mquery/lib/collection/node.js中的NodeCollection.NodeCollection.findAndModify：79
/app/node_modules/mongoose/lib/query.js中的Query.Query._findAndModify：1833
/app/node_modules/mongoose/lib/query.js中的Query.Query._findOneAndUpdate：1621
未知。[匿名]在/app/node_modules/kareem/index.js:156中
未知。[匿名]在/app/node_modules/kareem/index.js:18中
Object.wrapped在/app/node_modules/newrelic/lib/transaction/tracer/index.js:155中
node.js中的Object.doNTCallback0：430
node.js中的process.process._tickCallback：359

监控：

该堆栈跟踪实际上仅告诉我：1）您正在使用新的文物（这是非常有问题的，因为新的文物对mongodb驱动程序做了很多猴子补丁），以及2）mongodb驱动程序认为没有主要的可用，但我不确定为什么。

尝试通过在连接选项中添加replset: { loggerLevel: 'debug' }来启用mongodb驱动程序的调试模式，即：

var options = {
    server: {
        socketOptions: {
            keepAlive: 1,
            poolSize: 10,
            connectTimeoutMS: 30000,
            socketTimeoutMS: 30000
        }
    },
    replset: {
        loggerLevel: 'debug',
        socketOptions: {
            keepAlive: 1,
            poolSize: 10,
            connectTimeoutMS: 30000,
            socketTimeoutMS: 30000
        }
    }
};

这会将大量驱动程序调试数据记录到stdout，并帮助我们找出问题所在。 发生此“未找到主服务器”错误时，是否可以捕获这些数据？

谢谢@ vkarpov15 ，

我们已添加了该内容，并将在触发另一个事件后立即报告。

干杯，
罗伊

我认为newrelic不是这里的问题。 我们尝试在没有它的情况下运行，此问题仍然存在。 将从loggerLevel: 'debug'收集一些日志数据并在此处发布。

谢谢，让我知道您是否能够捕获有关该错误的更多详细信息。

另一个数据点：当连接数增加时，猫鼬会反复触发“重新连接”事件。

通常，“无主服务器可用”错误会触发_after_连接计数已经开始上升。

我们也遇到了这个问题。 通过MongoLab在Heroku上托管了一个Node应用。
上周，我们突然失去了与数据库的连接，并不断收到Error no primary server available消息。 重新启动我们的应用程序解决了该问题。
Heroku和MonogLab都没有在他们的日志中看到任何东西。
我希望有人能找到解决方案。

颠簸-在大型生产部署中，我们在node v4.2.3 mongoose v4.1.5上看到了这一点。 很难解决这个问题：

• 不会始终出错，这会阻止我们采取措施（重新启动流程/取出节点）
• 随机发生，似乎与mongo replset状态无关

@sansmischevia您

^我们在通过Cloud Manager在具有自托管mongodb服务器的AWS EC2上进行大规模生产部署时遇到了此问题。

您好，

我们也想插话。
我们正在运行node v0.12.8 ， mongo v2.6.11和mongoose v4.1.11 。

$ npm list | grep "mongo"
├─┬ [email protected]
│ └─┬ [email protected]
│   ├─┬ [email protected]
├─┬ [email protected] 
│ ├─┬ [email protected]
│ │ ├─┬ [email protected]
└─┬ [email protected]
  └─┬ [email protected]
    ├─┬ [email protected]

$ npm list | grep "mongoose"
├─┬ [email protected]

它通常可以在为数据库添加种子的操作期间进行重现，涉及许多查询。 发生这种情况后，我们的应用程序似乎不受影响。 mongo日志中没有错误，并且我们的三节点副本集在此期间运行正常。

我们将尝试loggerLevel: 'debug'并回报。

@ vkarpov15我们直接在mongolab replsets + ec2上

我也在mongolab上遇到了这个问题。

我们还在MongoLab和Modulus上遇到此问题。

看看https://jira.mongodb.org/browse/NODE-622 ，如果有人可以提供一整套日志，那将是非常有帮助的，因此我们可以对其进行复制。

在这里，我们不会使用猫鼬，而是使用本机MongoDB客户端。 在这里得到同样的no primary server available错误。 我们正在私有VPC内的EC2实例上运行副本集，我们的连接字符串是实例的私有IP地址。 MongoDB v3.0.3 。 在我看来，当查询的吞吐量很高时就会发生这种情况，因为通常情况下不会发生该错误。

            serverOpts = {
                server: {
                    sslValidate: false,
                    sslCA: ca,
                    socketOptions: {
                        connectTimeoutMS: 30000,
                        socketTimeoutMS: 180000
                    }
                },
                replSet: {
                    connectWithNoPrimary: false,
                    sslValidate: false,
                    sslCA: ca,
                    socketOptions: {
                        connectTimeoutMS: 30000,
                        socketTimeoutMS: 180000
                    }
                }
            };

看起来在即将发布的驱动程序版本中有此修复程序： NODE-622

礼物永远都还为时过早！ :)

固定版本已发布在NPM https://www.npmjs.com/package/mongodb上。

我可以确认我们不再收到该错误。 ：tada：

mongodb 2.1.2的PR在这里： https :

在使用mongo core 2.1.2升级mongoose到4.3.4之后仍然看到此错误。 https://jira.mongodb.org/browse/NODE-622已重新打开

+1我刚刚也注意到我们的生产服务器上也发生了这种情况。 我看不出任何原因。 将节点4.2.4与mongoose 4.3.4和mongodb 3.0.8一起使用。 我使用mongodb的MMS服务来监视群集，并且在收到以下消息期间没有看到任何警报：MongoError：没有可用的主服务器

@ amit777您可以发布连接字符串和选项吗？ 另外，这是否发生在异常繁重的工作量中，例如，对数据库的大量写入？

克里斯，这肯定是在写操作期间发生的，尽管我不会说我们的负担特别重。 我们在集群中有几个节点，每个节点将独立地写入mongo。

这是我们的连接方式：

var mongoose = require('mongoose');
var mongodb = {};

var connect = function () {
mongodb.db = "mongodb://node1:27017,node2:27017,node3:27017/myapp";
mongodb.dbOptions = {
      "db": {"native_parser": true},
      "replSet": {
        "rs_name": "mongocluster",
        "socketOptions": { "keepAlive": 1, "connectTimeoutMS": 30000, "socketTimeoutMS": 60000 }
        }
    };
  mongoose.connect(config.get('mongodb.db'), config.get('mongodb.dbOptions'));
};
connect();

我还刚刚注意到，我的mongod日志很快就被连接和断开连接消息填充满了：

2016-01-13T13:32:15.418-0500 I NETWORK  [conn91700536] end connection 192.168.1.50:33189 (5558 connections now open)
2016-01-13T13:32:15.418-0500 I NETWORK  [conn91700534] end connection 192.168.1.50:33187 (5558 connections now open)
2016-01-13T13:32:15.418-0500 I NETWORK  [conn91700540] end connection 192.168.1.50:33193 (5557 connections now open)
2016-01-13T13:32:15.418-0500 I NETWORK  [conn91700538] end connection 192.168.1.50:33191 (5558 connections now open)
2016-01-13T13:32:15.418-0500 I NETWORK  [conn91700542] end connection 192.168.1.50:33195 (5557 connections now open)
2016-01-13T13:32:15.418-0500 I NETWORK  [conn91700532] end connection 192.168.1.50:33185 (5556 connections now open)
2016-01-13T13:32:15.419-0500 I NETWORK  [conn91700533] end connection 192.168.1.50:33186 (5552 connections now open)
2016-01-13T13:32:15.419-0500 I NETWORK  [conn91700535] end connection 192.168.1.50:33188 (5552 connections now open)
2016-01-13T13:32:15.419-0500 I NETWORK  [conn91700537] end connection 192.168.1.50:33190 (5552 connections now open)
2016-01-13T13:32:15.419-0500 I NETWORK  [conn91700541] end connection 192.168.1.50:33194 (5551 connections now open)
2016-01-13T13:32:15.419-0500 I NETWORK  [conn91700543] end connection 192.168.1.50:33196 (5551 connections now open)
2016-01-13T13:32:15.419-0500 I NETWORK  [conn91700539] end connection 192.168.1.50:33192 (5552 connections now open)
2016-01-13T13:32:15.548-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36754 #91705950 (5548 connections now open)
2016-01-13T13:32:15.549-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36755 #91705951 (5549 connections now open)
2016-01-13T13:32:15.550-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36756 #91705952 (5550 connections now open)
2016-01-13T13:32:15.550-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36757 #91705953 (5551 connections now open)
2016-01-13T13:32:15.550-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36758 #91705954 (5552 connections now open)
2016-01-13T13:32:15.551-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36760 #91705955 (5553 connections now open)
2016-01-13T13:32:15.551-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36759 #91705956 (5554 connections now open)
2016-01-13T13:32:15.551-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36762 #91705957 (5555 connections now open)
2016-01-13T13:32:15.551-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36761 #91705958 (5556 connections now open)
2016-01-13T13:32:15.553-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36763 #91705959 (5557 connections now open)
2016-01-13T13:32:15.553-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36764 #91705960 (5558 connections now open)
2016-01-13T13:32:15.554-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36765 #91705961 (5559 connections now open)

这是一些有助于调试的其他信息。我开始认为可能存在一些与连接池有关的错误。 重新启动节点进程后，在mongod.log中看到一堆新连接。 然后大约一分钟后，我在mongod.log中看到了一堆末端连接消息。

似乎连接/断开连接随着时间的推移越来越快地放大（尽管我仍在尝试确认这一点）。

造成这种情况的典型情况是类似的。

复制副本包含驱动程序无法解析的主机。 驱动程序连接时，它将副本集用作所有连接的规范源。 重新连接将使用这些地址。 它们必须由驾驶员解决。

您还应该避免使用IP地址，因为它们是许多此类问题的根源，请使用完全限定的主机名（无短名称）

@christkv（如果操作系统能够解析主机）（即通过执行ping操作）），这是否意味着驾驶员也应该能够解决？

应该可以，但是您始终可以使用telnet主机名端口进行检查。

是的，我能够远程登录到主机和端口..（所有数据库主机在应用程序服务器上都有/ etc / hosts条目）。

在我们的应用程序启动并创建连接池之后，如果没有网络问题，是否应该断开连接并重新连接？ 还是在mongodb日志中会看到正常的连接超时和重新连接？

问题在于，如果没有完整的日志，就不可能将这些内容关联起来以试图理解和重现该问题（请参阅我对https://jira.mongodb.org/browse/NODE-622的最后评论）

如果套接字超时窗口中没有足够的操作来执行所有连接，则该池将关闭并重新连接。 因此，如果您有一个30秒的窗口和10个连接，但只有5个操作，则每30秒将导致一次重新连接事件。

会关闭与该池的所有连接吗？ 还是只有尚未行使的联系？ 如果我们在30秒内进行所有连接，在接下来的30秒窗口中是否将执行相同的检查？

我将尝试获取您在mongodb票证中请求的日志。.感谢您的协助。

所有。 如果您设法在socketTimeout窗口中使用池中的所有连接，则node.js不会使套接字超时，并且它们也不会关闭，从而迫使池重新连接。

提示：只有在并行运行许多缓慢运行的操作时，大量连接才有用，否则，您更适合使用较小的池，因为MongoDB每个套接字使用一个线程，这意味着成千上万个连接需要在服务器上分配更多的内存，并且导致更多的CPU上下文切换。

mongodb-core的下一个主要修订版将更改池，使其不断增长，并进行其他一些基本更改以最大程度地减少慢速火车问题。 但是，那已经过去了几个月，并且可能会与MongoDB 3.4工作捆绑在一起。

您是否看到可能/可能大量断开/重新连接会间歇性地导致主服务器不可用的问题？

是的，因为在很短的一段时间内，该集中可能没有任何服务器

@christkv我一直在等到这种情况再次发生，才能向您发送其他票证中的一些日志。 在过去的几周中，我们的集群实际上一直稳定，并且没有看到此错误。

@ChrisZieba有趣的是，这总是怎么发生的大声笑：+1：我现在

@christkv克里斯蒂安，您好，如果您对流量减少的情况有任何解决方法的建议，我很好奇。 我当时只是想减小池的大小以及增加超时时间。

如果它对其他人有帮助，我删除了套接字超时，并将keepAlive增加到200，并将poolsize减小到了3。我似乎断开/重新连接的次数减少了很多。但是它仍然偶尔发生。

如果可以帮助任何人，我们几乎删除了所有猫鼬设置，包括socketTimeout和connectionTimeout以及keepAlive，连接开始变得稳定。 我们的poolSize是200。
我不确定这是推荐的方法，但现在可以使用。 我们仍在对其进行监控，以确保其成立。

猫鼬v4.4.2
节点4
蒙哥3.0

您是否有大量的慢速操作？ 如果您不这样做，我认为您不会注意到20个插槽与500个插槽之间的任何区别。

抱歉...是200。已修复评论。

是的，你是对的。 我们没有太大的区别，但是我们希望池的大小大于或小于。

真正的问题在于连接何时保持打开而不是关闭。 直到我们删除所有猫鼬超时和keepAlive设置之前，这种情况一直发生。 我想知道为什么这些都是由mongoose / mongo-driver处理而不让OS来做？

2.1.7及更高版本中的池经过了重新设计，可以避免这种情况。 如果将socketTimeout设置为0，则将其委托给os，但这可能会挂起10分钟的连接。

行。 有趣。 因此，既然我删除了keepAlive和socketTimeout设置，默认设置是什么？

这取决于，不确定猫鼬是否将任何特定设置设置为默认设置。 如果在驱动程序中使用MongoClient.connect方法，则连接和套接字超时均为30秒。

我们确实使用connect但是当我们手动设置30秒时，连接开始堆积。

如果有500个连接，则在socketTimeout周期内至少需要500个操作才能保持池打开，否则它将关闭并强制重新连接。 但是，由于池是一个增长/缩小的模型，因此在2.1.7中发生了变化。

我在mongodb 3.2.6和mongoose 4.3.4中遇到相同的问题。 有什么帮助吗？

@ 15astro尝试删除socketTimeout和connectionTimeout ，看是否有帮助。

@refaelos好的..会尝试的。.我尝试了keepAlive = 6000，但这没有帮助。 只是想知道删除socketTimeout和connectionTimeout什么帮助？

是的，我们尝试使用不同的值，只有当我们完全删除这些设置后，它才能开始正常工作。

@refaelos ：我发现删除这些设置没有运气。 还有其他我想念的东西吗？

@ 15astro没有人。 抱歉。 这是我们今天的设置：

mongo   : {
    uri    : process.env.MNG_URL || 'mongodb://localhost/myDB',
    options: {
      user   : process.env.MNG_USER,
      pass   : process.env.MNG_PASS,
      replset: {
        poolSize: 200
      }
    }

  }

在我的情况下，这与/ etc / hosts中IP到名称绑定的缺乏有关。

如果您使用名称而不是IP设置了副本集，并且在MongoDB节点的/ etc / hosts中具有以下内容：

10.10.10.10 mongodb-2gb-fra1-02 10.10.10.11 mongodb-2gb-fra1-01 10.10.10.12 mongodb-2gb-fra1-03

然后，您还需要将其放在所有应用程序服务器的/ etc / hosts中。

我认为node-mongo根据我在URI中输入的内容进行连接，但事实并非如此。

似乎node-mongo通过IP或名称从Mongo URI连接，然后从响应请求的第一个MongoDB节点获取其他副本成员的主机名。 例如，它将获取mongodb-2gb-fra1-03并将其传递给OS进行解析。 如果OS对mongodb-2gb-fra1-03一无所知，则会引发“错误，没有可用的主服务器”。

希望能有所帮助。

@adriank是的，这是正确的，它基于它从副本集配置返回的连接的连接。 原因是，这是有关副本集的标准真理。 这也是为什么副本集配置中的所有地址都必须由驱动程序解析的原因，以使驱动程序正确地进行故障转移，并使其能够检测正在添加到集合中或从集合中删除的服务器。 以前的驱动程序没有实现SDAM规范，并且松懈得多。 但是，这将在生产环境中引起问题。

@christkv但是，这对于像我们的MongoSpector这样的工具来说是一场噩梦。 因此，我们无法从一台主机安全地连接到多个副本。 DigitalOcean自动将名称生成为几乎没有任何更改的液滴，其结果是许多客户端将mongodb-2gb-fra1-01作为其主要帐户。 :)我希望我们能解决一些问题。

我们在这里https://jira.mongodb.org/browse/SERVER-1889跟踪服务器票证

我们还应该向DigitalOcean提交票证，指出他们所犯的错误及其对用户的影响。

顺便说一下，您可以删除并重新添加新名称为ips的副本集成员

有一个类似的问题，在连接大约12-24小时后，我们收到错误消息“无主服务器可用”

重新启动通常可以解决该问题。

连接：
{ "url": "mongodb://user:password@cluser-shard-00-00, cluser-shard-00-01, cluster-shard-00-02/settings?ssl=true&replicaSet=primarycluster-shard-0&authSource=admin&retryWrites=true", "options": { "db": { "w": 1, "wtimeout": 3000, "fsync": true }, "authSource": "admin", "server": { "poolSize": 3, "socketOptions": { "autoReconnect": true, "keepAlive": 60000, "connectTimeoutMS": 7000, "socketTimeoutMS": 15000 } } }, "password": "password", "username": "username" }