Mongoose: Mongoose 4.6.2 выдает ошибку «MongoError: в наборе реплик не обнаружено первичного объекта», а 4.4.19 работает нормально.

+1

Можете ли вы подключиться к оболочке mongo?

Я могу подключиться к оболочке mongo. БД работает нормально. Мы находимся в производстве, и многие микросервисы подключены к БД с помощью строки набора реплик.

Однако для новых проектов подключение с использованием строки набора реплик не работает. И мы должны использовать только IP-адрес главного узла. Сначала я подумал, что это проблема версии (4.6.2 против 4.4.19).

Однако недавно мне не удалось подключиться с помощью строки реплики в 4.6.2 ни в новом проекте. В качестве временного решения я решил просто использовать IP-адрес для главного узла (строка подключения только с одним IP-адресом).

Я наблюдаю похожие проблемы. Не могу добавить дополнительных разъяснений или предоставить хороший пример кода.
Но я подозреваю, что это связано с несовместимостью одной из зависимостей.
Впервые я заметил эту проблему, когда обновил другие пакеты (но не mongoose, который в то время был на 4.5.8).

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

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

@adeelzaman Я создал
https://gist.github.com/zoellner/eddd3d40291e150919bb025f452f9054

@adeelzaman Я только что обновил суть выше,

@zoellner Я не могу сказать по этой сути, что является причиной, вы можете нас просветить?

Я обнаружил, что для нас проблема не возникает в Mongoose 4.5.8. Временно мы заблокировали наши репозитории в 4.5.8 Mongoose, чтобы решить эту проблему.

Также я должен упомянуть, что при попытке изолировать проблему я создал новый проект только с одним модулем узла (мангуст) и попытался подключиться к набору реплик с помощью 4.6.0 и получил ту же ошибку.

Так может это не ошибка несовместимости, а ошибка 4.6.0? Я не мог определить причину ошибки. Я планирую изучить это подробнее, когда у меня появится свободное время.

Я только что столкнулся с тем, что, как я уверен, является той же проблемой в 4.6.2 и 4.6.4, я получаю этот вывод для своего подключения к набору реплик, такая же настройка uri конфигурации, как указано выше

Error: Uncaught, unspecified "error" event. ([object Object])
    at NativeConnection.emit (events.js:163:17)
    at /home/projects/xxx/xxx/node_modules/mongoose/lib/connection.js:466:17
    at NativeConnection.Connection.error (/home/projects/xxx/xxx/node_modules/mongoose/lib/connection.js:489:12)
    at /home/projects/xxx/xxx/node_modules/mongoose/lib/connection.js:520:15
    at /home/projects/xxx/xxx/node_modules/mongoose/lib/drivers/node-mongodb-native/connection.js:216:21
    at /home/projects/xxx/xxx/node_modules/mongodb/lib/db.js:229:14
    at .<anonymous> (/home/projects/xxx/xxx/node_modules/mongodb/lib/replset.js:357:9)
    at g (events.js:286:16)
    at emitOne (events.js:96:13)
    at emit (events.js:188:7)
    at Timeout.<anonymous> (/home/projects/xxx/xxx/node_modules/mongodb-core/lib/topologies/replset.js:507:14)
    at tryOnTimeout (timers.js:232:11)
    at Timer.listOnTimeout (timers.js:202:5)

Хм странно. Это почти наверняка проблема с базовым драйвером mongodb, потому что mongoose сам по себе ничего не делает с наборами реплик. Были некоторые проблемы с наборами реплик, которые были исправлены в драйвере mongodb 2.2.11 , он будет обновлен до mongoose 4.6.5 и посмотрим,

+1

@ mo4islona все еще

+1 такая же проблема (тоже в 4.6.5).
Последняя рабочая версия 4.5.9 после этой версии 4.6.0 и более я получаю сообщение об ошибке «в наборе реплик не найден первичный»

@ vkarpov15 Да 4.6.5 не работает. Не пробовал 4.5.9, но 4.4.19 работает.

такая же проблема здесь с использованием uri, например

mongodb://user:password<strong i="6">@server1</strong>,server2,server3/database?replicaSet=repname

работает на 4.5.9, но последняя версия выдает ошибки

сегодня я сделал установку на ubuntu 14 с mongoose 4.5.9 и получил ту же ошибку
/node_modules/mongodb/lib/mongo_client.js:225 throw err ^ MongoError: no primary found in replicaset at /node_modules/mongodb-core/lib/topologies/replset.js:628:32 at Server.<anonymous> (test/node_modules/mongodb-core/lib/topologies/replset.js:420:24)

тот же код работал без проблем на Mac OSX

мой uri такой же, как dottodot

Странный. Можете ли вы подтвердить, можете ли вы подключиться с помощью оболочки mongodb, используя этот URI с того же компьютера?

@ vkarpov15 Я могу подключиться с помощью оболочки mongodb, и я могу подключиться с помощью стандартного способа URI

@stampsrule какой стандартный способ URI?

@ vkarpov15

mongodb://user:password<strong i="7">@server</strong>:port/database

Хорошо, так какой код соединения не работает?

У меня аналогичная проблема, я не могу подключиться в mongoose> = 4.6.0. Возврат к 4.5.10 работает. Моя строка подключения выглядит так:

mongodb://username:password<strong i="7">@ip1</strong>:port1,ip2:port2/database?authSource=blah&replicaSet=rs0&ssl=true

Я использую следующие варианты подключения:

{
   replSet: {
      sslValidate: false,
      sslCert: fs.readFileSync(`...`),
      sslKey: fs.readFileSync(`...`),
      sslCA: fs.readFileSync(`...`)
   }
}

Если я определю обработчик ошибок для подключения, например:

 mongoose.connection.on('error', (err) => {
    console.log(err instanceof Error, err)
})

тогда интересно, что err instanceof Error ложно, а результат регистрации err :

 ReplSet {
  domain: null,
  _events: 
   { reconnect: [Function],
     timeout: { [Function: g] listener: [Function] },
     error: { [Function: g] listener: [Function] },
     connect: { [Function: g] listener: [Function: connectHandler] } },
  _eventsCount: 4,
  _maxListeners: undefined,
  id: 1,
  s: 
   { options: 
      { disconnectHandler: [Object],
        cursorFactory: [Object],
        reconnect: false,
        emitError: true,
        size: 5,
        rejectUnauthorized: false,
        cert: <Buffer  ... >,
        key: <Buffer  ... >,
        ca: <Buffer  ... >,
        socketOptions: {},
        setName: 'rs0',
        ssl: true,
        clientInfo: [Object] },
     bson: BSON {},
     Cursor: 
      { [Function: Cursor]
        super_: [Object],
        define: [Object],
        INIT: 0,
        OPEN: 1,
        CLOSED: 2,
        GET_MORE: 3 },
     logger: Logger { className: 'ReplSet' },
     seedlist: [ [Object], [Object] ],
     replicaSetState: 
      ReplSetState {
        domain: null,
        _events: [Object],
        _eventsCount: 3,
        _maxListeners: undefined,
        topologyType: 'ReplicaSetNoPrimary',
        setName: 'rs0',
        set: {},
        id: 1,
        logger: [Object],
        index: 0,
        acceptableLatency: 15,
        heartbeatFrequencyMS: 10000,
        primary: null,
        secondaries: [],
        arbiters: [],
        passives: [],
        ghosts: [],
        unknownServers: [],
        maxElectionId: null,
        maxSetVersion: 0,
        replicasetDescription: [Object] },
     connectingServers: [],
     haInterval: 10000,
     minHeartbeatFrequencyMS: 500,
     disconnectHandler: Store { s: [Object], length: [Getter] },
     index: 0,
     connectOptions: { forceServerObjectId: false, w: 1, promiseLibrary: [Object] },
     debug: false,
     clientInfo: 
      { driver: [Object],
        os: [Object],
        platform: 'Node.js v6.7.0, LE, mongodb-core: 2.0.13' } },
  authProviders: 
   { mongocr: MongoCR { bson: BSON {}, authStore: [] },
     x509: X509 { bson: BSON {}, authStore: [] },
     plain: Plain { bson: BSON {}, authStore: [] },
     gssapi: GSSAPI { bson: BSON {}, authStore: [] },
     sspi: SSPI { bson: BSON {}, authStore: [] },
     'scram-sha-1': ScramSHA1 { bson: BSON {}, authStore: [], id: 0 } },
  initialConnectState: { connect: false, fullsetup: false, all: false },
  state: 'destroyed',
  haTimeoutId: 
   Timeout {
     '0': null,
     _called: true,
     _idleTimeout: -1,
     _idlePrev: null,
     _idleNext: null,
     _idleStart: 1969,
     _onTimeout: null,
     _repeat: null },
  authenticating: false,
  ismaster: null }

Некоторые другие подробности:

• Используется мангуст 4.6.8 , но проблема, похоже, относится к 4.6.2 и выше
• mongoose.connection.readyState - это 2 при попытке подключения, затем 0 при сбое подключения
• Хотя я включил отладку, вывода нет
• Использование узла 6.7.0

используйте [email protected] , последняя версия не работает. у меня была такая же проблема (набор реплик).

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

@dustywusty Нет, это не так. Один IP-адрес для каждого члена набора реплик.

У меня эта проблема возникает с 4.6.0 и новее, 4.5.10 для меня последняя рабочая версия.

Пожалуйста, просмотрите, похожа ли эта проблема на - https://github.com/Automattic/mongoose/issues/4834

Я использую последнюю версию и зарегистрировал self.s.replicaSetState во время ошибки и обнаружил следующее:
topologyType: 'ReplicaSetNoPrimary', setName: 'rs0', set: { 'mongo1:27017': { type: 'Unknown', electionId: null, setName: null, setVersion: null }, 'mongo2:27017': { type: 'PossiblePrimary', setVersion: null, electionId: null, setName: null }, 'mongo3:27017': { type: 'Unknown', electionId: null, setName: null, setVersion: null }, 'database4ca:27017': { type: 'RSSecondary', electionId: undefined, setName: 'rs0', setVersion: 5 }, 'mongoarb:27017': { type: 'Unknown', electionId: null, setName: null, setVersion: null } },

являются ли нулевые значения причиной ошибки?

это была 100% проблема, когда я вставил mongo1.example. com: 27017 он не сможет подключиться, хотя IP-адрес работает. когда я решил проблему с URL-адресом и заменил свой URI mongodb: // URL-адресами, все сработало.

увидел комментарий @ wparsons-360insights и попробовал его. Подтверждение того, что точно такое же соединение с базой данных для набора реплик работает в 4.5.10, но не в 4.7.1

Привет,

Я столкнулся с той же проблемой.

мангуст ":" ^ 4.7.6 "

config:
config.mongoose = {
uri: " mongodb: // Appinv-db : 27017, Appinv-db1: 27017, Appinv-db2: 27017, Appinv-db3: 27017 / nexgtv_16? replicaSet = rs0",
// uri: " mongodb: // localhost / nexgtv_16 ",
параметры: {
db: {native_parser: true},
REPLESET: {
// auto_reconnect: false,
бассейнРазмер: 10,
socketOptions: {
keepAlive: 1000,
connectTimeoutMS: 30000
},
reconnectInterval: 2000, // По умолчанию 1000 мс
reconnectTries: 60 // По умолчанию 30
},
server: {
бассейнРазмер: 5,
socketOptions: {
keepAlive: 1000,
connectTimeoutMS: 30000
},
reconnectInterval: 2000, // По умолчанию 1000 мс
reconnectTries: 60 // По умолчанию 30
}
}
}

Связь:
mongoose.connect (config.mongoose.uri, config.mongoose.options);

Ошибка:
MongoError: соединение 3 с Appinv-db3: 27017 закрыто
в Function.MongoError.create (/etc/scripts/push-notifications/node_modules/mongodb-core/lib/error.js:29:11)
в Socket.(/etc/scripts/push-notifications/node_modules/mongodb-core/lib/connection/connection.js:198:22)
в Socket.g (events.js: 291: 16)
в emitOne (events.js: 96: 13)
в Socket.emit (events.js: 188: 7)
в TCP._handle.close [как _onclose] (net.js: 498: 12)
ошибка подключения: {MongoError: в наборе реплик не найден первичный объект
в /etc/scripts/push-notifications/node_modules/mongodb-core/lib/topologies/replset.js:659:32
на сервере.(/etc/scripts/push-notifications/node_modules/mongodb-core/lib/topologies/replset.js:442:24)
на Server.g (events.js: 291: 16)
в emitOne (events.js: 96: 13)
на Server.emit (events.js: 188: 7)
в Object.cb (/etc/scripts/push-notifications/node_modules/mongodb-core/lib/topologies/server.js:259:55)
при подключении.(/etc/scripts/push-notifications/node_modules/mongodb-core/lib/connection/pool.js:243:32)
в Connection.g (events.js: 291: 16)
в emitTwo (events.js: 106: 13)
в Connection.emit (events.js: 191: 7)
в Socket.(/etc/scripts/push-notifications/node_modules/mongodb-core/lib/connection/connection.js:197:12)
в Socket.g (events.js: 291: 16)
в emitOne (events.js: 96: 13)
в Socket.emit (events.js: 188: 7)
в TCP._handle.close [как _onclose] (net.js: 498: 12)
name: 'MongoError',
message: 'в наборе реплик не найден первичный объект'}

Пожалуйста, предложите любое решение

Возникла аналогичная проблема с mLab на heroku с репликой в ​​uri, исправленной с помощью версии 4.5.10

Мы также сталкиваемся с этой проблемой, но недавнее обновление MongoDB 3.0 -> 3.4, похоже, позволяет стабильно работать самой последней версии mongoose.

(Не уверен, связано ли это с 4.7.8 или 3.4 или их комбинацией)

У меня была такая же проблема.
Добавление имен хостов членов наборов реплик (например, они находятся в файле хостов реплики) в файл хостов веб-серверов устранило проблему для меня.

rs.conf();
{
    "_id" : "cwreplset0",
    "version" : 348189,
    "protocolVersion" : NumberLong(1),
    "members" : [
        {
            "_id" : 0,
            "host" : "cwmongo1:27017",
            "arbiterOnly" : false,
            "buildIndexes" : true,
            "hidden" : false,
            "priority" : 2,
            "tags" : {

            },
            "slaveDelay" : NumberLong(0),
            "votes" : 1
        },
        {
            "_id" : 1,
            "host" : "cwmongoArbiter:27017",
            "arbiterOnly" : true,
            "buildIndexes" : true,
            "hidden" : false,
            "priority" : 1,
            "tags" : {

            },
            "slaveDelay" : NumberLong(0),
            "votes" : 1
        },
        {
            "_id" : 2,
            "host" : "cwmongo2:27017",
            "arbiterOnly" : false,
            "buildIndexes" : true,
            "hidden" : false,
            "priority" : 1,
            "tags" : {

            },
            "slaveDelay" : NumberLong(0),
            "votes" : 1
        }
    ],
...

cwmongo1 /etc/hosts:
127.0.0.1   cwmongo1
XXX cwmongo2
XXX cwmongoArbiter

cwmongo2 /etc/hosts:
127.0.0.1   cwmongo2
XXX cwmongo1
XXX cwmongoArbiter

cwmongoArbiter /etc/hosts:
127.0.0.1   cwmongoArbiter
XXX cwmongo2
XXX cwmongo1

webservers /etc/hosts:

XXX cwmongo1
XXX cwmongo2

К моему удивлению, проблема исправлена ​​с параметром replicaSet в mLab MONGODB_URI после обновления до последней версии 4.8.1 .

учитывая комментарий @dazwiafl , возможно ли, что ошибка возникает, когда «хост» в конфигурации набора реплик на сервере mongodb не совпадает с именами серверов в строке подключения? Например, когда используются пользовательские (внутренние) DNS-имена или IP-адреса?
Просматривая предыдущие комментарии, похоже, что это касается всех, кто упомянул свои имена хостов.
В этом случае # 4834 на самом деле будет той же проблемой, что и @flipflopapp.
РЕДАКТИРОВАТЬ: # 3634 также может быть связано

Подтверждение того, что mongoose 4.8.1 работает для нас (с mongodb 3.4.2) тогда и только тогда, когда мы используем полные (внешние) имена DNS в строке подключения.

Ранее мы использовали внутреннее DNS-имя (которое преобразовывалось в частный IP-адрес EC2 в нашем VPC). Это не работает, если имена хостов в rs.conf () установлены на имена внешних DNS.
Я не тестировал все конфигурации, но моя интуиция на данный момент подсказывает мне, что версия mongoose / mongodb на самом деле не имеет значения.
Эта проблема должна быть решена при использовании полных имен DNS.

@zoellner У меня аналогичная установка, когда я подключаюсь к mongo через частную сеть, поэтому внешнего доступа нет, так как же это обойти? Раньше я мог просто подключиться, используя частные IP-адреса. Я пытался найти ответ, но без особого успеха.

Я внес некоторые изменения в инфраструктуру, чтобы разрешить «внешний доступ» (только для серверов, которым он нужен). Не идеальное решение, но будет работать некоторое время, пока не будет лучшего способа. Я думаю, что это действительно проблема, которую нужно поднять с людьми из mongodb, чтобы лучше справиться с этим довольно распространенным сценарием.

@dottodot У вас должна быть возможность установить sslAllowInvalidCertificates и sslAllowInvalidHostnames на стороне клиента и настроить самоподписанный сертификат для использования localhost или 127.0.0.1 для FQDN. Это работает для меня с IP-адресами в качестве поля хоста в наборе реплик, и я все еще получаю доступ к хостам через имя хоста, которое не соответствует имени хоста хоста или FQDN, установленному в сертификате. Однако я не тестировал использование IP-адресов в mongo uri для доступа к кластеру. Если это будет полезно для вас, я могу проверить это ...

Есть ли какое-либо решение этой проблемы для mongoose v4.8.4?

4.5.10 и 4.4.12 для меня проблему не решают. Запуск набора реплик вычислений Google с именем набора реплик rs0.

У меня была такая же проблема с использованием обновления v4.6.5 до v4.8.5, проблема была решена без изменения конфигурации.

Просто попробовал 4.8.5 не повезло :(

Как вы подключаетесь к набору реплик?

Мы используем:

mongodb://root:[email protected]:27017,mongo1.dev.domain.com:27017,mongo2.dev.domain.com:27017/main?replicaSet=rs0&authSource=admin

Я где-то читал, что требуется передать только первичный адрес, а 2 вторичных адреса не нужны. Это правда? Спасибо.

Попробуй это. ВНИМАНИЕ, что нет необходимости подключаться к арбитру монго, только 2 реплики:

mongoose.connect ("mongodb: //mongo1.dev.domain.com,mongo2.dev.domain.com/main? replicaSet = rs0 & authSource = admin", {
пользователь: 'MONGO_USERNAME',
передать: 'MONGO_PASSWORD'
});

Если это НЕ сработает, то у вас есть проблемы с конфигурацией реплики, например, возможно, порт mongo, к которому вы подключаетесь, закрыт.

Загляните в это сообщение об ошибке при подключении к mongo RS в Kubernetes StatefulSet. Не удалось квалифицировать имена DNS в строке подключения с именем SS и получить сообщение «Нет основной ошибки».

Итак, для SS с именем mongo «mongo-0» должно было быть «mongo-0.mongo». Ошибка ушла.

@edgarmarkosov Мы не

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

@wayofthefuture "Я где-то читал, что первичный серверов ".
У вас есть источник. Bcos это не сработало для меня, ни какое-либо обходное решение, предложенное здесь. Я застрял в той же ситуации, что и op. : /

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

@wayofthefuture согласился, мы планируем это, но еще не сделали.

Можно подтвердить эту проблему на 4.9.0.

Запуск mongo в Kubernetes с 3 узлами в контроллере репликации. Мой сервер node, использующий mongooose, подключается к моему кластеру mongo в другом пространстве имен.

Если мой nodeserver и кластер mongo находятся в одном пространстве имен (разрешение DNS не требуется), он работает.

Смог разобраться в проблеме благодаря более конкретным сообщениям об ошибках с последними обновлениями драйверов (теперь с использованием mongoose 4.9.2). Проблема заключалась в том, что мангуст пытался подключиться к каждому хосту, указанному в конфигурации набора реплик монго, вместо того, чтобы использовать хосты, которые я указал в своей строке подключения мангуста. И поскольку мой сервер узла и кластер mongo работают в разных пространствах имен, мой сервер узла не смог разрешить DNS для этих узлов.

Не могли бы вы объяснить, что вы сделали для решения проблемы? Мой кластер Mongo также работает в отдельном пространстве имен. Спасибо.

@wayofthefuture Я не уверен, что сделал это наилучшим образом, но я только что отредактировал файл /etc/hosts на моем хосте, где работает сервер узла.

Так, например, предположим, что хосты, указанные в вашей конфигурации набора реплик, - это db1.example.com и db2.example.com . Но тогда по какой-то причине (например, конфигурация брандмауэра) хост, на котором работает ваш сервер узла, не может разрешить эти два имени хоста. Итак, в строке конфигурации подключения мангуста вы используете разные имена хостов или IP-адреса (например, 10.0.0.1 и 10.0.0.2 ). В этом случае вы можете отредактировать файл /etc/hosts (на том же хосте, что и сервер узла), включив в него строки:

10.0.0.1 db1.example.com
10.0.0.2 db2.example.com

По крайней мере, это была моя проблема - я не уверен, что это применимо и к вашей ситуации. Странно, что другая версия драйвера mongo может вызвать такую ​​проблему. В любом случае, надеюсь, что это поможет.

Подтвердите ту же ошибку:
Ошибка соединения Mongoose по умолчанию: MongoError: в наборе реплик не найдено первичного объекта.

Использование мангуста 4.9.3. и докер сочинить. Не уверен, что докер имеет какое-то отношение к этому, но возврат к 4.5.10 решил проблему.

Пожалуйста, может кто-нибудь серьезно изучить эту проблему, поскольку она возникла 7 месяцев назад, и у нее нет другого решения, кроме как вернуться к 4.5.10.

@asabhaney Вы правы ... теперь он пытается подключиться к внутренним IP-адресам каждого узла кластера. Мне это все еще кажется ошибкой, потому что, если я укажу доменное имя со статическим IP-адресом, он должен использовать этот статический IP-адрес, а не пытаться использовать внутренний IP-адрес в другой подсети. Исправление / etc / hosts - это решение, но похоже на временное исправление более серьезной проблемы, верно? Спасибо.

Мне интересно, является ли это основной проблемой с собственным драйвером mongodb? Я также вижу проблемы с подключением к наборам реплик через Heroku. Это просто бомбежка, когда не удается найти праймериз.

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

+1 Возврат на v4.5.10 работает.

Версии узлов протестированы против

v7.7.3
v7.10.0
лтс / бор

Версии Mongoose протестированы и завершились неудачно с сообщением "Не найдено первичных данных"

5.6.2
5.7.0
5.8.5

Версии Mongo

3,2
2,6

Воспроизводимость

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

Есть ли какие-либо указания, с которых можно даже начать искать способы устранения этой ошибки?

Связана ли эта проблема с https://github.com/Automattic/mongoose/issues/4517? Хотя эта проблема отмечена как закрытая, я не уверен, была ли проблема решена. В более новых версиях все еще есть эта проблема.

Я подтвердил, что эта ошибка существует для Azure CosmosDB с помощью версии драйвера 4.9.10. Он также существует для драйвера 4.5.10 с CosmosDB, если вы не укажете &readPreference=secondary в конце строки подключения - тогда он работает нормально.

@dtzar справедливое предупреждение, поддержка CosmosDB / DocumentDB в настоящее время не является целью для мангуста. Если вы решите использовать мангуст с этими dbs, вы сами по себе.

Проблема все еще существует в Mongoose 4.10.2.

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

@wayofthefuture вы имеете в виду CosmosDB? Я также понял, что подключение к CosmosDB работает через Mongoose 4.5.10, если в конце убрать & replicaset = globaldb.

Проблема все еще существует в Mongoose 4.10.2.
Есть обновления?

Насколько я могу судить, эта проблема больше не присутствует в последней версии Mongoose при подключении к CosmosDB с использованием MongoDB API, если вы указываете строку подключения в следующем формате:

mongodb://myservername:[email protected]:10255/mydbname?ssl=true&replicaSet=globaldb

Очень важно , чтобы вызвать тот факт , что mydbname не присутствует по умолчанию в Azure портала и должен быть вставлен или иначе соединение не будет с указанным вопросом выше. Неважно, какое значение вы укажете для mydbname, но оно должно быть там.

Попробуйте исправить имя хоста сервера mongodb в /etc/hosts , например:

1.2.3.4 mdb01 mdb01.example.com
1.2.3.5 mdb02 mdb02.example.com
1.2.3.6 mdb03 mdb03.example.com

Надеюсь на эту помощь!

Использование V. 4.11.5 на Heroku. -Поначалу у меня были те же проблемы, я исправил это, просто добавив replicaSet в строку подключения:

mongodb://user:[email protected],mongolayer.com/database?replicaSet=database

Обратите внимание, что значение, переданное как replicaSet совпадает с именем базы данных. Я не пробовал использовать разные имена.

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

Решение:

    options.replset = {
      socketOptions: {
        connectTimeoutMS: 60000, 
        keepAlive: 120
      }
    };

настройка / etc / hosts у меня работает

Я думаю, вы можете открыть соединение компаса и кластера во вкладке веб и выбрать соединение с компасом, и приложение компаса автоматически обнаружит соединение :)

Я получаю ту же ошибку в узле 8. Узел 6 работает нормально. Любые идеи?

Ошибка: не удается определить состояние сервера.
в canCheckoutReader (PATH_TO / node_modules / connect-mongo / node_modules / mongodb / lib / mongodb / connection / server.js: 779: 12)
в Server.checkoutReader (PATH_TO / node_modules / connect-mongo / node_modules / mongodb / lib / mongodb / connection / server.js: 793: 16)
в Cursor.nextObject (PATH_TO / node_modules / connect-mongo / node_modules / mongodb / lib / mongodb / cursor.js: 748: 48)
в Collection.findOne (PATH_TO / node_modules / connect-mongo / node_modules / mongodb / lib / mongodb / collection / query.js: 162: 10)
в PATH_TO / node_modules / connect-mongo / lib / connect-mongo.js: 223: 18
в MongoStore._get_collection (PATH_TO / node_modules / connect-mongo / lib / connect-mongo.js: 156: 21)
в MongoStore.get (PATH_TO / node_modules / connect-mongo / lib / connect-mongo.js: 222: 10)
в сеансе (PATH_TO / node_modules / express-session / index.js: 367: 11)
в Layer.handle [как handle_request] (PATH_TO / node_modules / express / lib / router / layer.js: 82: 5)
в trim_prefix (PATH_TO / node_modules / express / lib / router / index.js: 269: 13)
в PATH_TO / node_modules / express / lib / router / index.js: 236: 9
в Function.proto.process_params (PATH_TO / node_modules / express / lib / router / index.js: 311: 12)
в PATH_TO / node_modules / express / lib / router / index.js: 227: 12
в Function.match_layer (PATH_TO / node_modules / express / lib / router / index.js: 294: 3)
в следующий (PATH_TO / node_modules / express / lib / router / index.js: 188: 10)
в cookieParser (PATH_TO / node_modules / cookie-parser / index.js: 48: 5)

Версия узла
v6.13.0 -> РАБОТАЕТ
v8.10.0 -> Выдает эту ошибку. Поддерживает ли мангуст Node8?

список npm | grep мангуст
├─┬ [email protected]
│ ├── [email protected]

список npm | grep mongodb
│ └── [email protected] посторонний
├─┬ [email protected] недействителен
│ └── [email protected] посторонний
│ ├─┬ [email protected]
│ │ └─┬ [email protected]

Mongoose подключается к Mongos через порт 26000. Я могу подключиться к Mongodb с помощью Robomongo.

@sravzpublic, пожалуйста, внимательно посмотрите на трассировку стека, она показывает, что ошибка связана с connect-mongo и не имеет ничего общего с mongoose. FWIW, мангуст поддерживает узел 8.

Мы тоже сталкиваемся с этим в Mongoose 5.2.12 ( намного новее, чем указано здесь ) на NodeJS 6.x - У нас еще не было слишком много времени, чтобы вникнуть в это: /

У меня эта проблема возникает на «мангусте»: «^ 5.4.19», и я привел примеры в открытом стеке здесь: https://stackoverflow.com/questions/55637808/mongoerror-no-mongos-proxy-available-when -соединение-к-реплике-набору. Вызывает беспокойство то, что эта проблема, кажется, остается открытой в течение длительного времени, даже после обновления версии. Хм....

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

Я столкнулся с этой проблемой на узле 8, я обновился до узла 10, и у меня есть эти пакеты, и я изменил свою логику подключения mongodb на ниже. Это сработало.

кот package.json | grep mongo
"connect-mongo": "^ 2.0.1",
"mongodb": "> = 3.0.4",
"мангуст": "> = 5.0.11",

узел -v
Версия 10.4.1

db.version ()
3.4.15

config.db = mongodb://user:pass<strong i="14">@host</strong>:26000/dbname?ssl=true

// Get Mongoose to use the global promise library
mongoose.Promise = global.Promise;
var db = mongoose.connect(config.db, {
    auto_reconnect: true,
    socketTimeoutMS: 0,
    connectTimeoutMS: 0
  },
  function (err) {
    if (err) {
      console.error(chalk.red('Could not connect to MongoDB!' + err));
      console.log(chalk.red(err));
    }
  });

// When successfully connected
mongoose.connection.on('connected', function () {
 };

// If the connection throws an error
mongoose.connection.on('error', function (err) {
  console.log('Mongoose default connection error: ' + err);
});

// When the connection is disconnected
mongoose.connection.on('disconnected', function () {
  console.log('Mongoose default connection disconnected');
});

process.on('SIGINT', function () {
  mongoose.connection.close(function () {
    console.log('Mongoose default connection disconnected through app termination');
    process.exit(0);
  });
});

Я думаю, что проблема в хосте: (cluster0-shard-00-00-vmyny.mongodb.net) используйте основной.

Я собираюсь закрыть это, похоже, проблема связана с connect-mongo, а не с мангустом.