Mongoose: Tidak ada server utama yang tersedia

Tidak ada yang melompat keluar saat ini. Apakah Anda yakin tidak ada server mongodb yang mogok? Selain itu, dapatkah Anda mempertahankan koneksi yang stabil menggunakan shell?

Menjalankan perintah db.runCommand( { replSetGetStatus : 1 } ) saat kesalahan terjadi menghasilkan "health" : 1, pada semua 3 node. Ada juga set utama "stateStr" : "PRIMARY", di salah satu node.

Apakah Anda menghubungkan menggunakan string koneksi yang sama, menggunakan DNS? Juga terlihat seperti penyimpanan Anda rata-rata setelah masalah, dapatkah Anda memeriksa ulang dan melihat apakah Anda telah kehabisan ruang hard drive di salah satu mesin Anda?

Apakah Anda menghubungkan menggunakan string koneksi yang sama, menggunakan DNS?

Saya tidak menggunakan string koneksi yang sama. Menurut Anda, apakah menggunakan alamat IP EC2 pribadi akan menyelesaikan masalah ini?

Tidak yakin apa yang menyebabkan penyimpanan maksimal seperti itu, tetapi bahkan setelah mem-boot instance baru, masalah tanpa server utama masih terjadi dengan banyak ruang yang tersedia.

Alamat IP EC2 dapat membantu, tergantung pada bagaimana set replika Anda dikonfigurasi. Dapatkah Anda menunjukkan kepada saya output rs.status() dari shell ?

Ini adalah rs.status () saat koneksi sedang meningkat.

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

Tidak ada yang luar biasa di set replika. Apakah Anda memiliki contoh kode lain yang relevan, misalnya, apakah Anda memiliki kode yang bereaksi terhadap peristiwa koneksi luwak?

Masalah potensial lainnya yang patut dipertimbangkan, apakah Anda menggunakan agen peninggalan baru yang up-to-date? Saya akan mencoba berjalan tanpa peninggalan baru dan melihat apakah ini masih terjadi, peninggalan monyet baru-menambal pengemudi mongodb sehingga terkadang dapat menyebabkan perilaku yang tidak terduga.

Kami telah mengeluarkan acara koneksi luwak:

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

Seperti inilah tampilan beberapa log

​[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"
 }
}

Saya berada di acara mongodb days minggu ini, di mana saya dapat menjadwalkan beberapa waktu dan menunjukkan masalah ini kepada salah satu insinyur senior di MongoDB, dan mereka tidak yakin apa masalahnya. Mereka memang menyebutkan untuk menambahkan set replikasi dan ukuran kumpulan maksimal ke string koneksi, yang sayangnya belum menyelesaikan masalah ini.

Kami juga mencoba menonaktifkan keep hidup, dan menyetelnya ke nilai yang lebih kecil pada instance, tetapi tampaknya itu juga tidak menyelesaikan masalah ini.

Kami menggunakan newrelic versi 1.24.0 , dan mongo-express-patch versi 0.21.1 . Saya akan mencoba menjalankan tanpa newrelic untuk melihat apakah itu menyelesaikan masalah ini.

Hmm ya, sepertinya luwak terhubung kembali karena suatu alasan. Dapatkah Anda menunjukkan kepada saya hasil dari npm list | grep "mongoose" dan 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]

Untuk apa Anda menggunakan mongodb-core ? Juga, apakah Anda menjalankan dengan mongo-express diaktifkan di prod?

Saat ini tidak menggunakan mongodb-core untuk apa pun. Apakah menurut Anda ketidakcocokan versi antara ketergantungan luwak dapat menyebabkan masalah?

Kami memiliki mongo-express diaktifkan dalam produksi.

Tidak yang saya tahu. Saya hanya mencoba untuk melihat apakah ada koneksi lain ke mongodb yang mungkin berkontribusi pada masalah ini. Saya telah melakukan sedikit googling - apakah Anda menggunakan nama DNS yang sama untuk string koneksi Anda seperti yang muncul di rs.status() ? Menurut ini , Anda mungkin melihat masalah yang serupa jika Anda menggunakan DNS yang berbeda untuk string koneksi dari yang dipikirkan oleh kumpulan replika Anda.

Kesalahan ini akan terjadi saat menggunakan DNS yang sama dalam string koneksi sebagai atribut "syncingTo" di rs.status() . Ini juga terjadi saat menggunakan IP ec2 internal dalam string koneksi.

Satu-satunya hal yang belum saya coba hanyalah menyetel connectWithNoPrimary menjadi true .

Saya juga akan mencoba menjalankan dengan diskon mongo-express juga. Itu mungkin menyebabkan masalah ...

Kami mengalami masalah yang sama. Kami memiliki situs yang mengalami beban berkelanjutan sekitar 100 RPM dengan puncak pada 500-700 rpm +. Tampaknya kami melihat ini sepanjang proses bahkan selama periode yang relatif cukup.

Lingkungan Hidup:
Heroku - 75 2x dynos - Node.JS 5.1.1
Database - MongoLabs Dedicated Cluster M4 - Versi 3.0.7

String Koneksi:
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
};

Logging:
Kami telah mengaktifkan cukup banyak pemantauan untuk mencoba dan men-debug ini, jadi saya telah menyertakan jejak tumpukan Raygun kami bahkan ini akan membantu debug. _Catatan: _ Ini adalah nomor baris yang sama persis dengan yang ditunjukkan @ChrisZieba pada jejak di atas.

Pesan: tidak ada server utama yang tersedia
Object.pickServer di /app/node_modules/mongodb-core/lib/topologies/replset.js:860
ReplSet.ReplSet.command di /app/node_modules/mongodb-core/lib/topologies/replset.js:437
ReplSet.ReplSet.command di /app/node_modules/mongodb/lib/replset.js:392
Object.executeCommand di /app/node_modules/mongodb/lib/db.js:281
Db.Db.command di /app/node_modules/mongodb/lib/db.js:305
Object.wrapped di /app/node_modules/newrelic/lib/instrumentation/mongodb.js:185
Object.findAndModify di /app/node_modules/mongodb/lib/collection.js:2327
Collection.Collection.findAndModify di /app/node_modules/mongodb/lib/collection.js:2265
Object.wrapped di /app/node_modules/newrelic/lib/transaction/tracer/index.js:155
Object.wrappedQuery di /app/node_modules/newrelic/lib/instrumentation/mongodb.js:218
Object.wrapped di [sebagai findAndModify] (/app/node_modules/newrelic/lib/instrumentation/mongodb.js:188
NativeCollection.NativeCollection. (Anonim dalam fungsi) [sebagai findAndModify] (/app/node_modules/mongoose/lib/drivers/node-mongodb-native/collection.js:136
NodeCollection.NodeCollection.findAndModify di /app/node_modules/mquery/lib/collection/node.js:79
Query.Query._findAndModify di /app/node_modules/mongoose/lib/query.js:1833
Query.Query._findOneAndUpdate di /app/node_modules/mongoose/lib/query.js:1621
tidak diketahui. [anonim] di /app/node_modules/kareem/index.js:156
tidak diketahui. [anonim] di /app/node_modules/kareem/index.js:18
Object.wrapped di /app/node_modules/newrelic/lib/transaction/tracer/index.js:155
Object.doNTCallback0 di node.js: 430
process.process._tickCallback di node.js: 359

Pemantauan:

Jejak tumpukan itu benar-benar hanya memberi tahu saya bahwa 1) Anda menggunakan peninggalan baru (yang sangat dipertanyakan, karena peninggalan baru melakukan banyak penambalan monyet pada pengemudi mongodb), dan 2) pengemudi mongodb berpikir bahwa tidak ada yang utama tersedia, tapi saya tidak yakin mengapa.

Coba aktifkan mode debug driver mongodb dengan menambahkan replset: { loggerLevel: 'debug' } ke opsi koneksi Anda, yaitu:

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

Ini akan mencatat banyak data debug driver ke stdout dan membantu kami mencari tahu apa yang salah. Dapatkah Anda mengambil data ini sekitar saat kesalahan "Tidak ada server utama yang ditemukan"?

Terima kasih @ vkarpov15 ,

Kami telah menambahkan itu dan akan melaporkan kembali segera setelah kami memicu yang lain.

Bersulang,
Roy

Saya tidak berpikir newrelic adalah masalah di sini. Kami mencoba berjalan tanpa itu dan masalah ini terus berlanjut. Akan mengumpulkan beberapa data log dari loggerLevel: 'debug' dan memposting di sini.

Terima kasih, beri tahu saya jika Anda berhasil mengetahui detail selengkapnya tentang kesalahan tersebut.

Poin data lain: Mongoose memicu peristiwa "terhubung kembali" berulang kali saat jumlah koneksi meningkat.

Kesalahan "tidak ada server utama yang tersedia" biasanya memicu _setelah_ jumlah koneksi sudah mulai naik.

Kami juga pernah mengalami masalah ini. Dengan memiliki aplikasi Node yang dihosting di Heroku dengan MongoLab.
Minggu lalu kami tiba-tiba kehilangan koneksi dengan database dan terus mendapatkan pesan Error no primary server available . Memulai ulang aplikasi kami menyelesaikan masalah.
Baik Heroku dan MonogLab tidak melihat apa pun di log mereka.
Saya berharap seseorang menemukan solusi untuk ini.

Benjolan - kami melihat ini di node v4.2.3 mongoose v4.1.5 pada penerapan produksi besar. Sulit untuk memperdebatkan masalah ini karena:

• tidak error secara konsisten yang mencegah kita untuk mengambil tindakan (proses restart / pengambilan node)
• terjadi secara acak dan tampaknya tidak terkait dengan status replset mongo

@sansmischevia apakah kamu juga menggunakan mongolab + heroku?

^ Kami mengalami masalah ini dalam penerapan produksi besar di AWS EC2 dengan server mongodb yang dihosting sendiri melalui Cloud Manager.

Halo,

Kami juga ingin ikut serta.
Kami menjalankan node v0.12.8 , mongo v2.6.11 dengan 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]

Seringkali dapat direproduksi selama operasi yang memasukkan database, yang melibatkan banyak kueri. Aplikasi kami tampaknya tidak terpengaruh setelah ini terjadi. Tidak ada kesalahan dalam mongo log dan set replika tiga node kami berfungsi dengan baik selama ini.

Kami akan mencoba loggerLevel: 'debug' dan melaporkan kembali.

@ vkarpov15 kami berada di mongolab replsets + ec2 secara langsung

Saya juga mengalami masalah ini di mongolab.

Kami juga mengalami masalah ini di MongoLab dan Modulus.

lihat di https://jira.mongodb.org/browse/NODE-622 dan jika ada yang dapat memberikan satu set log lengkap yang akan sangat membantu sehingga kami dapat mereproduksinya.

Akan berpadu di sini, kami tidak menggunakan luwak, tetapi klien MongoDB asli. Mendapatkan kesalahan no primary server available sini. Kami menjalankan kumpulan replika pada instance EC2 di dalam VPC pribadi, string koneksi kami adalah alamat IP pribadi dari instance tersebut. MongoDB v3.0.3 . Menurut saya ini terjadi ketika ada permintaan yang tinggi, karena secara umum kesalahan tidak terjadi.

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

Sepertinya ada perbaikan untuk ini di rilis driver mendatang: NODE-622

Tidak pernah terlalu dini untuk hadiah! :)

Versi tetap telah diterbitkan di NPM https://www.npmjs.com/package/mongodb.

Saya dapat mengonfirmasi bahwa kami tidak lagi menerima kesalahan. : tada:

PR untuk mongodb 2.1.2 di sini: https://github.com/Automattic/mongoose/pull/3712

Masih melihat kesalahan ini setelah memutakhirkan luwak ke 4.3.4 , yang menggunakan inti mongo 2.1.2 . https://jira.mongodb.org/browse/NODE-622 telah dibuka kembali

+1 Saya baru saja melihat ini terjadi di server produksi kami juga. Saya tidak melihat pola mengapa. Menggunakan node 4.2.4 dengan luwak 4.3.4 dan mongodb 3.0.8. Saya menggunakan layanan MMS mongodb untuk memantau cluster saya dan saya tidak melihat peringatan apa pun selama saya mendapatkan: MongoError: tidak ada server utama yang tersedia

@ amit777 Dapatkah Anda

Chris, ini pasti terjadi selama operasi tulis, meskipun menurut saya beban kami tidak terlalu berat. Kami memiliki beberapa node dalam sebuah cluster di mana setiap node akan menulis secara independen ke mongo.

Inilah cara kami terhubung:

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();

Saya juga baru menyadari log mongod saya terisi sangat cepat dengan pesan koneksi dan pemutusan koneksi:

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)

Berikut adalah beberapa info tambahan yang dapat membantu untuk men-debug .. Saya mulai berpikir mungkin ada beberapa bug yang berhubungan dengan penggabungan koneksi. Setelah saya memulai ulang proses node saya, saya melihat banyak koneksi baru muncul di mongod.log. Kemudian setelah sekitar satu menit, saya melihat banyak pesan koneksi akhir di mongod.log.

Sepertinya koneksi / putuskan menguat lebih cepat dan lebih cepat dari waktu ke waktu, (meskipun saya masih mencoba mengonfirmasi itu).

situasi khas yang menyebabkan ini adalah sesuatu seperti.

Replicaset berisi host yang tidak dapat diselesaikan oleh driver. Saat driver terhubung, ia menggunakan replicaset sebagai sumber kanonik untuk semua koneksi. Sambungan ulang akan menggunakan alamat tersebut. Mereka HARUS dapat dipecahkan oleh pengemudi.

Anda juga harus menghindari penggunaan alamat IP karena mereka adalah sumber dari banyak masalah seperti ini, gunakan nama host yang memenuhi syarat (tidak ada nama pendek)

@christkv jika OS dapat menyelesaikan host (yaitu dengan melakukan ping), apakah ini berarti pengemudi juga harus dapat menyelesaikannya?

seharusnya ya, tetapi Anda selalu dapat menggunakan port nama host telnet untuk memeriksa.

ya, saya bisa melakukan telnet ke host dan port .. (semua host database memiliki entri / etc / hosts di server aplikasi).

Setelah aplikasi kita dimulai dan kumpulan koneksi dibuat, haruskah ada pemutusan dan koneksi ulang jika tidak ada masalah jaringan? Atau apakah ada batas waktu koneksi normal dan sambungkan kembali yang akan saya lihat di log mongodb?

Masalahnya adalah tidak mungkin menghubungkan hal-hal ini untuk mencoba memahami dan mereproduksi masalah tanpa kumpulan log lengkap (lihat komentar terakhir saya di https://jira.mongodb.org/browse/NODE-622)

jika Anda tidak memiliki cukup operasi di jendela waktu tunggu soket untuk menjalankan semua koneksi, kumpulan akan menutup dan menyambung kembali. jadi jika Anda memiliki jendela 30 detik dan 10 koneksi tetapi hanya 5 operasi itu akan menyebabkan acara menghubungkan kembali setiap 30 detik.

Apakah akan menutup semua koneksi ke kolam? atau hanya koneksi yang belum dilakukan? Jika kami melakukan semua koneksi dalam 30 detik, apakah pemeriksaan yang sama akan dilakukan dalam jendela 30 detik berikutnya?

Saya akan mencoba untuk mendapatkan log yang Anda minta di tiket mongodb .. terima kasih telah membantu.

Semua. Jika Anda berhasil menjalankan semua koneksi di kumpulan di jendela socketTimeout node.js tidak akan timeout soket dan mereka tidak akan menutup memaksa pool menghubungkan kembali.

Tip banyak koneksi hanya berguna jika Anda memiliki banyak operasi yang berjalan lambat secara paralel, jika tidak, Anda lebih cocok dengan kumpulan yang lebih kecil karena MongoDB menggunakan utas per soket yang berarti bahwa ribuan koneksi memerlukan lebih banyak memori yang dialokasikan di server dan akan menyebabkan lebih banyak sakelar konteks CPU.

Revisi besar berikutnya dari mongodb-core akan mengubah pool menjadi berkembang serta beberapa perubahan mendasar lainnya untuk meminimalkan masalah kereta lambat. Namun itu beberapa bulan lagi dan mungkin akan terikat dengan pekerjaan MongoDB 3.4.

Apakah Anda melihat kemungkinan / kemungkinan bahwa pemutusan / penyambungan kembali dalam jumlah besar sewaktu-waktu dapat menyebabkan masalah tidak ada server utama yang tersedia?

ya karena akan ada periode singkat di mana mungkin tidak ada server di set

@christkv Saya telah menunggu hingga hal ini terjadi lagi untuk mengirimi Anda log di tiket lainnya. Cluster kami sebenarnya telah stabil selama beberapa minggu terakhir dan kami belum melihat kesalahan ini.

@ChrisZieba lucu bagaimana hal itu sepertinya selalu terjadi lol: +1: Saya akan membiarkan tiketnya terbuka di jira untuk saat ini dan lihat apa yang bisa kita temukan.

@christkv Hai Christian, saya hanya ingin tahu apakah Anda memiliki petunjuk tentang solusi jika lalu lintas lebih rendah. Saya berpikir untuk hanya mengurangi ukuran kolam serta meningkatkan batas waktu.

jika itu membantu orang lain, saya mencabut socket timeout serta meningkatkan keepAlive menjadi 200 dan juga mengurangi poolsize menjadi 3 .. saya tampaknya memiliki lebih sedikit memutuskan / menyambung kembali .. namun hal itu kadang-kadang masih terjadi.

Jika itu membantu siapa pun, kami menghapus hampir semua pengaturan luwak, termasuk socketTimeout dan connectionTimeout dan keepAlive dan koneksi mulai stabil. PoolSize kami adalah 200.
Saya tidak yakin itu pendekatan yang disarankan tetapi berhasil sekarang. Kami masih memantaunya untuk memastikannya berlaku.

luwak v4.4.2
Simpul 4
Mongo 3.0

Apakah Anda memiliki banyak operasi yang lambat? jika tidak, saya rasa Anda tidak akan melihat perbedaan antara kumpulan 20 soket vs 500.

Maaf ... 200. Memperbaiki komentar.

Dan ya, Anda benar. Kami tidak merasakan banyak perbedaan tetapi kami lebih memilih ukuran kolam lebih besar daripada lebih kecil.

Masalah sebenarnya dengan saat koneksi tetap terbuka dan tidak tertutup. Ini biasanya terjadi sampai kami menghapus semua pengaturan waktu tunggu luwak dan keepAlive. Saya bertanya-tanya mengapa ini ditangani oleh mongoose / mongo-driver dan tidak membiarkan OS melakukannya?

Well 2.1.7 dan yang lebih tinggi memiliki kolam yang didesain ulang untuk menghindari hal ini. Jika Anda mengeset socketTimeout 0 Anda mendelegasikannya ke os tetapi itu mungkin sebanyak 10 menit koneksi hang.

Baik. menarik. Jadi sekarang setelah saya menghapus pengaturan keepAlive dan socketTimeout, apa pengaturan defaultnya?

itu tergantung, tidak yakin apakah luwak mengatur pengaturan tertentu sebagai default. jika Anda menggunakan metode MongoClient.connect pada driver, waktu yang dibutuhkan adalah 30 detik untuk koneksi dan waktu tunggu soket habis.

Kami menggunakan connect tetapi ketika kami mengatur 30 detik koneksi secara manual mulai menumpuk.

Nah dengan 500 koneksi Anda membutuhkan setidaknya 500 ops di dalam periode socketTimeout untuk menjaga pool tetap terbuka, jika tidak maka akan menutup dan memaksa koneksi ulang. Ini berubah di 2.1.7 namun karena kumpulan adalah model yang tumbuh / menyusut.

Saya mengalami masalah yang sama dengan mongodb 3.2.6 dan luwak 4.3.4. Ada bantuan dalam hal ini?

@ 15astro coba hapus pengaturan socketTimeout dan connectionTimeout dan lihat apakah itu membantu.

@refaelos Ok..akan mencobanya..Saya mencoba dengan keepAlive = 6000 tetapi tidak membantu. Hanya ingin tahu bagaimana menghapus socketTimeout dan connectionTimeout akan membantu?

Ya, kami mencobanya dengan nilai yang berbeda dan hanya ketika kami sepenuhnya menghapus pengaturan ini, semuanya mulai bekerja dengan baik.

@refaelos : Saya tidak berhasil menghapus pengaturan ini. Ada hal lain yang saya lewatkan?

@ 15ast tidak ada manusia. Maaf. Beginilah tampilan pengaturan kami hari ini:

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

  }

Dalam kasus saya itu terkait dengan kurangnya IP untuk mengikat nama di / etc / hosts.

Jika Anda telah menyiapkan set replika dengan nama alih-alih IP dan Anda memiliki sesuatu seperti ini di / etc / hosts dari node 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

Kemudian Anda juga perlu memasukkannya ke / etc / hosts dari semua server aplikasi Anda.

Saya pikir node-mongo terhubung sesuai dengan apa pun yang saya masukkan ke URI, tetapi bukan itu masalahnya.

Tampaknya node-mongo terhubung dengan IP atau nama dari Mongo URI, lalu mendapatkan nama host anggota replika lainnya dari node MongoDB pertama yang merespons permintaan. Ini mendapat misalnya mongodb-2gb-fra1-03 dan meneruskannya ke OS untuk diselesaikan. Jika OS tidak tahu apa-apa tentang mongodb-2gb-fra1-03 , itu melempar "Kesalahan tidak ada server utama yang tersedia".

Semoga membantu.

@adriank ya itu benar itu mendasarkan itu koneksi dari yang mendapat kembali dari konfigurasi replicaset. Alasannya adalah ini adalah sumber kebenaran kanonik tentang replika set. Ini juga mengapa semua alamat dalam konfigurasi replicaset harus dapat diatasi oleh driver agar driver dapat melakukan failover dengan benar dan agar dapat mendeteksi server yang ditambahkan dan dihapus dari set. Driver sebelumnya tidak menerapkan spesifikasi SDAM dan di mana lebih longgar. Namun ini akan menyebabkan masalah di lingkungan produksi.

@christkv Namun ini adalah mimpi buruk untuk alat seperti MongoSpector kami. Karena itu, kami mengalami masalah saat menghubungkan secara aman ke lebih dari satu replika dari satu host. DigitalOcean menghasilkan nama secara otomatis menjadi tetesan yang hampir tidak ada yang berubah dan efeknya adalah banyak klien memiliki mongodb-2gb-fra1-01 sebagai UTAMA mereka. :) Saya harap kita bisa menemukan sesuatu.

Kami melacak tiket server di sini https://jira.mongodb.org/browse/SERVER-1889. Saya ingin hal seperti ini menjadi mungkin.

Kami juga harus mengajukan tiket ke DigitalOcean yang menunjukkan kesalahan yang mereka buat dan bagaimana hal itu memengaruhi pengguna mereka.

dengan cara Anda dapat menghapus dan menambahkan kembali anggota replicaset dengan nama baru mereka menjadi ips

Memiliki masalah serupa, setelah sekitar 12-24 jam terhubung, kami mendapatkan kesalahan "Tidak ada server utama yang tersedia"

Memulai ulang biasanya memperbaiki masalah.

koneksi:
{ "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" }