Mongoose: Нет доступного основного сервера

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

Выполнение команды db.runCommand( { replSetGetStatus : 1 } ) при возникновении ошибки приводит к появлению "health" : 1, на всех 3 узлах. Также есть первичный набор "stateStr" : "PRIMARY", на одном из узлов.

Вы подключаетесь, используя ту же строку подключения, используя DNS? Также похоже, что ваше хранилище выровнялось после проблемы, можете ли вы дважды проверить и увидеть, не закончилось ли у вас место на жестком диске на одной из ваших машин?

Вы подключаетесь, используя ту же строку подключения, используя DNS?

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

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

IP-адреса EC2 могут помочь, в зависимости от того, как настроен ваш набор реплик. Можете ли вы показать мне вывод команды rs.status() из оболочки ?

Это 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 days, где я смог запланировать время и показать эту проблему одному из старших инженеров MongoDB, и они не были уверены, в чем проблема. Они упомянули о добавлении набора репликации и максимального размера пула в строку подключения, что, к сожалению, не решило эту проблему.

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

Мы; используем newrelic version 1.24.0 и mongo-express-patch version 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, которые могут способствовать этой проблеме. Я немного погуглил - используете ли вы те же имена DNS для своей строки подключения, что и те, которые указаны в rs.status() ? В соответствии с этим вы можете столкнуться с аналогичными проблемами, если используете другую строку DNS для подключения, чем думает ваш набор реплик.

Эта ошибка возникает при использовании того же DNS в строке подключения, что и атрибут «syncingTo» в rs.status() . Это также происходит при использовании внутреннего IP-адреса ec2 в строке подключения.

Единственное, что я еще не пробовал, это просто установить connectWithNoPrimary на true .

Я бы также попробовал бегать со скидкой mongo-express . Это может вызывать проблемы ...

Мы сталкиваемся с той же проблемой. У нас есть сайт, который испытывает постоянную нагрузку со скоростью около 100 об / мин с пиками в 500-700 об / мин +. Кажется, мы видим это на протяжении всего процесса, даже в относительно спокойные периоды.

Окружающая среда:
Heroku - 75 2x дино - Node.JS 5.1.1
База данных - выделенный кластер MongoLabs M4 - версия 3.0.7

Строка подключения:
mongodb: // _: * _ @ ds043294-a0.mongolab. com: 43294 , ds043294-a1.mongolab. ком: 43294 / heroku_hf8q79dt? replicaSet = rs-ds043294

НПМ:

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 показал на трассировке выше.

Сообщение: основной сервер недоступен
Object.pickServer в /app/node_modules/mongodb-core/lib/topologies/replset.js:860
ReplSet.ReplSet.command в /app/node_modules/mongodb-core/lib/topologies/replset.js:437
ReplSet.ReplSet.command в /app/node_modules/mongodb/lib/replset.js:392
Object.executeКоманда в /app/node_modules/mongodb/lib/db.js:281
Db.Db.command в /app/node_modules/mongodb/lib/db.js:305
Object.wrapped в /app/node_modules/newrelic/lib/instrumentation/mongodb.js:185
Object.findAndModify в /app/node_modules/mongodb/lib/collection.js:2327
Collection.Collection.findAndModify в /app/node_modules/mongodb/lib/collection.js:2265
Object.wrapped в /app/node_modules/newrelic/lib/transaction/tracer/index.js:155
Object.wrappedQuery в /app/node_modules/newrelic/lib/instrumentation/mongodb.js:218
Object.wrapped в [как 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
NodeCollection.NodeCollection.findAndModify в /app/node_modules/mquery/lib/collection/node.js:79
Query.Query._findAndModify в /app/node_modules/mongoose/lib/query.js:1833
Query.Query._findOneAndUpdate в /app/node_modules/mongoose/lib/query.js: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
Object.doNTCallback0 в node.js: 430
process.process._tickCallback в node.js: 359

Мониторинг:

Эта трассировка стека на самом деле говорит мне только, что 1) вы используете новую реликвию (что очень сомнительно, поскольку новая реликвия делает много исправлений обезьяны для драйвера mongodb), и 2) драйвер mongodb думает, что нет первичного доступно, но я не знаю почему.

Попробуйте включить режим отладки драйвера mongodb, добавив replset: { loggerLevel: 'debug' } в параметры подключения, то есть:

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' и опубликую здесь.

Спасибо, дайте мне знать, если вам удастся найти более подробную информацию об ошибке.

Еще один пункт данных: Mongoose запускает событие «переподключение» снова и снова по мере увеличения количества подключений.

Ошибки "Нет доступного основного сервера" обычно вызывают _после__ того, как количество подключений уже начало расти.

Мы тоже столкнулись с этой проблемой. Имея приложение Node, размещенное на Heroku с помощью MongoLab.
На прошлой неделе мы внезапно потеряли соединение с базой данных и продолжали получать сообщение Error no primary server available . Перезапуск нашего приложения решил проблему.
И Heroku, и MonogLab ничего не видели в своих журналах.
Надеюсь, кто-нибудь найдет для этого решение.

Удар - мы видим это на node v4.2.3 mongoose v4.1.5 при большом производственном развертывании. Трудно решить эту проблему, поскольку она:

• не выдает ошибок постоянно, что мешает нам принять меры (перезапустить процесс / удалить узел)
• происходит случайно и, кажется, не коррелирует со статусом реплики mongo

@sansmischevia , ты тоже пользуешься mongolab + heroku?

^ У нас возникла эта проблема при большом производственном развертывании на AWS EC2 с размещенными на сервере серверами mongodb через Cloud Manager.

Здравствуйте,

Мы также хотели бы присоединиться к нам.
Мы запускаем 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 . Мы запускаем набор реплик на экземпляре EC2 внутри частного VPC, наша строка подключения - это частные 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.

Я могу подтвердить, что мы больше не получаем ошибку. : тада:

PR для mongodb 2.1.2 здесь: https://github.com/Automattic/mongoose/pull/3712

Эта ошибка по-прежнему отображается после обновления mongoose до 4.3.4 , который использует ядро ​​mongo 2.1.2 . https://jira.mongodb.org/browse/NODE-622 открыт повторно

+1 Я только что заметил, что это происходит и на нашем производственном сервере. Я не понимаю, почему. Использование узла 4.2.4 с mongoose 4.3.4 и mongodb 3.0.8. Я использую службы MMS mongodb для мониторинга своего кластера, и я не видел никаких предупреждений в то время, когда я получаю: 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.

Похоже, что соединение / отключение со временем усиливается все быстрее (хотя я все еще пытаюсь это подтвердить).

типичная ситуация, вызывающая это, выглядит примерно так.

Replicaset содержит хосты, которые не могут быть разрешены драйвером. Когда драйвер подключается, он использует набор реплик в качестве канонического источника для всех подключений. Повторные подключения будут использовать эти адреса. Они ДОЛЖНЫ быть разрешены драйвером.

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

@christkv, если ОС может разрешить хосты (т. е. выполнив команду ping), значит ли это, что драйвер тоже должен разрешить?

он должен быть да, но вы всегда можете использовать порт имени хоста telnet для проверки.

да, я могу подключиться по telnet к хосту и порту .. (все хосты базы данных имеют записи / etc / hosts на серверах приложений).

Должны ли когда-либо быть отключены и повторно подключены после запуска нашего приложения и создания пула подключений, если нет проблем с сетью? Или есть нормальный тайм-аут и повторное подключение, которое я увижу в журналах mongodb?

проблема в том, что невозможно сопоставить эти вещи, чтобы попытаться понять и воспроизвести проблему без полного набора журналов (см. мой последний комментарий на https://jira.mongodb.org/browse/NODE-622)

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

Он закроет все подключения к пулу? или только те связи, которые не были осуществлены? Если мы выполним все соединения в течение 30 секунд, будет ли такая же проверка выполняться в следующем 30-секундном окне?

Я постараюсь получить журналы, которые вы запрашиваете, в тикете mongodb .. Спасибо за помощь.

Все. Если вам удастся выполнить все соединения в пуле в окне socketTimeout, node.js не будет тайм-аут сокетов, и они не будут закрывать принудительное повторное подключение пула.

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

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

Считаете ли вы возможным / вероятным, что огромное количество отключений / повторных подключений может периодически вызывать проблему отсутствия доступного основного сервера?

да, так как будет короткий период, когда в наборе может не быть серверов

@christkv Я ждал, пока это снова не повторится, чтобы отправить вам журналы в другом билете. Наш кластер действительно был стабильным в течение последних нескольких недель, и мы не видели этой ошибки.

@ChrisZieba, забавно, как это всегда, кажется, происходит lol: +1: Я пока оставлю заявку в jira и посмотрю, что мы сможем выяснить.

@christkv Привет, Кристиан, мне просто интересно, есть ли у вас какие-либо советы по обходным путям в случае низкого трафика. Я думал просто уменьшить размер пула, а также увеличить таймауты.

если это поможет кому-то еще, я удалил тайм-аут сокета, а также увеличил keepAlive до 200, а также уменьшил размер пула до 3 .. Кажется, у меня намного меньше отключений / повторных подключений .. однако это все еще иногда случается.

Если это кому-то поможет, мы удалили почти все настройки мангуста, включая socketTimeout, connectionTimeout и keepAlive, и соединения стали стабильными. Размер нашего бассейна - 200.
Я не уверен, что это рекомендуемый подход, но сейчас он работает. Мы все еще следим за ним, чтобы убедиться, что он работает.

мангуст v4.4.2
Узел 4
Монго 3.0

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

Извините ... это 200. Исправил комментарий.

И да, ты прав. Мы не ощущаем большой разницы, но мы предпочитаем размер пула больше, чем меньше.

Настоящая проблема с тем, когда соединения продолжают открываться и не закрываются. Раньше это происходило, пока мы не удалили все настройки mongoose timeout и keepAlive. Интересно, почему они обрабатываются mongoose / mongo-driver и не позволяют ОС делать это?

В скважине 2.1.7 и выше имеется переработанный пул, позволяющий избежать этого. Если вы установите socketTimeout 0, вы делегируете его операционной системе, но это может быть до 10 минут зависания соединений.

ОК. интересно. Итак, теперь, когда я удалил настройки keepAlive и socketTimeout, каковы настройки по умолчанию?

это зависит, не уверен, установил ли мангуст какие-то конкретные настройки по умолчанию. если вы используете метод MongoClient.connect в драйвере, это 30 секунд для тайм-аутов подключения и сокетов.

Мы действительно используем connect но когда мы устанавливаем 30 секунд вручную, соединения начинают накапливаться.

Что ж, при 500 подключениях вам нужно как минимум 500 операций в течение периода socketTimeout, чтобы пул оставался открытым, в противном случае он закроется и вызовет повторное подключение. Однако это изменится в 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
      }
    }

  }

В моем случае это было связано с отсутствием привязки IP к имени в / etc / hosts.

Если вы настроили набор реплик с именами вместо IP-адресов и у вас есть что-то вроде этого в / etc / hosts узлов MongoDB:

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 и передает его ОС для разрешения. Если ОС ничего не знает о mongodb-2gb-fra1-03 , она выдает ошибку «Нет доступного основного сервера».

Надеюсь, это поможет.

@adriank да, это правильно, он основывает свои соединения на тех, которые он получает из конфигурации

@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" }