Mongoose: Jangan sambungkan kembali setelah pemutusan

+1, mengalami 2 pemadaman dalam 5 hari terakhir terkait dengan masalah ini. Solusi saya saat ini adalah membuat proses saya secara eksplisit macet ( process.exit(0) ) ketika acara disconnected dipancarkan. Kemudian, proses dimulai ulang dan koneksi dibuka kembali dengan benar.

Dugaan saya adalah luwak mencoba menyambung kembali, tetapi gagal dalam interval reconnectTries * reconnectInterval , dan acara error tidak dipancarkan karena regresi ini (https://github.com/Automattic/mongoose/pull /4653). Yang saya tidak tahu adalah mengapa luwak/mongo terputus secara acak, saya tidak memiliki perilaku ini sebelumnya.
Hosting mongo apa yang Anda jalankan? mlab?

Kami menghostingnya sendiri di AWS. Sayangnya process.exit(0) bukanlah pilihan bagi kami.

Saya telah menerapkan perubahan di #4653 dan mendapatkan perilaku yang sama. Pemutusan sambungan setelah beberapa jam:

2016-10-27T11:26:42 pid:5276 MONGODB sync_reports_db connected successfully.
2016-10-27T11:26:42 pid:5276 MONGODB sync_reports_db opened successfully.
.... 2 hours later
2016-10-27T13:45:45 pid:5276 MONGODB sync_reports_db disconnected
2016-10-27T13:45:45 pid:5276 MONGODB CLOSE sync_reports_db

Tidak ada acara error yang dipancarkan? (seharusnya, 30 detik setelah disconnected )

Tidak, lihat kode di deskripsi masalah. Kecuali saya melakukan sesuatu yang salah, ada event handler untuk acara error . Faktanya, prosesnya masih berjalan dan luwak belum memicu peristiwa lain.

Kami telah mengalami masalah yang sama dalam beberapa hari terakhir sejak 4.6.5 – pemutusan acak yang menyebabkan proses simpul macet. Tapi tidak ada acara error . Mengembalikan ke 4.5.3 berhasil.

@loris apakah ini terkait dengan https://github.com/Automattic/mongoose/commit/f7ebee0c992c45cdb27ba7f0675556b980cddaad di 4.6.6 ?

@mck Ya, https://github.com/Automattic/mongoose/commit/f7ebee0c992c45cdb27ba7f0675556b980cddaad perbaiki acara error tidak dipancarkan ketika mekanisme coba lagi koneksi mongodb gagal. Namun, saya tidak tahu mengapa pemutusan acak terjadi sejak awal, ada ide @vkarpov15?

fwiw, itu terjadi pada kami 40-50% dari waktu jika kami mencoba melakukan operasi simpan/perbarui (menulis sekitar 650kb)

Ya, saya tidak punya banyak ide bagus. Anda dapat mencoba menelepon close() pada sambungan dan kemudian menelepon kembali connect() sendiri. @loris apakah Anda memiliki pengalaman serupa di mana penyimpanan/pembaruan yang berat tampaknya menyebabkan ini?

Kami juga menghadapi ini. Di salah satu layanan kami, kami mendapatkan acara kesalahan (koneksi N ke ds0XXXXX-a0.mongolab.com:XXXXX habis), diikuti oleh acara terputus. Dan koneksi tidak pernah dibangun kembali. Di layanan lain kami mendapatkan acara terputus setelah permintaan berat pada DB, yaitu menghapus 2 juta catatan. Dan kemudian tidak dapat terhubung kembali (luwak 4.6.6, DB versi 3.0.12).

Itu baru saja terjadi pada kami lagi, beberapa menit yang lalu, menjalankan mongodb di mLab juga (tidak yakin itu terkait). Kami menjalankan kueri yang berat, waktunya habis ( unhandledRejection { MongoError: connection 0 to ds****-a0.mongolab.com:**** timed out } , acara disconnected dipancarkan dengan benar, tetapi tidak ada setelahnya, tidak ada error , tidak ada reconnected dll, dengan demikian server web ini terus berjalan dan menerima permintaan HTTP, tetapi semuanya habis waktu sampai kami memulainya kembali karena terus menjalankan kueri luwak yang disangga dan tidak pernah kembali.

Pengaturan luwak kami (4.6.5 pada node 7.0.0):

const mongoConnectOpts = { reconnectTries: 10, reconnectInterval: 500, socketOptions: { keepAlive: 300000, connectTimeoutMS: 30000 } };
mongoose.connect(process.env.MONGODB_URI, { server: mongoConnectOpts, replset: mongoConnectOpts });
mongoose.connection.on('error', err => {
  console.log({ event: 'mongoose:error', ...err });
  process.exit(0);
});
mongoose.connection.on('connected', () => console.log({ event: 'mongoose:connected' }));
mongoose.connection.on('disconnected', () => console.log({ event: 'mongoose:disconnected' }));
mongoose.connection.on('reconnected', () => console.log({ event: 'mongoose:reconnected' }));

Solusi sementara adalah process.exit(0) juga pada acara disconnected untuk memaksa server web memulai ulang dan menyiapkan koneksi mongodb baru. Ada ide?

Ya, saya pernah mendengar hal semacam ini terjadi dengan mlab sebelumnya. TBH dalam hal ini saya baru saja merusak server dan memulai kembali, jaringan jerawatan yang sangat lambat cenderung menyebabkan masalah bagi driver mongodb dan saya membayangkan debugging ini akan melibatkan koordinasi dengan mlab.

Saya tidak yakin apa yang salah sekarang (luwak, driver mongo, mlab atau heroku), tetapi selama beberapa hari terakhir, menjalankan permintaan web yang mengeksekusi permintaan luwak berat (membutuhkan lebih dari 30 detik untuk merespons) akan memicu permintaan heroku timeout (ini adalah mekanisme di heroku yang timeout setiap permintaan web membutuhkan waktu lebih dari 30 detik). Setelah permintaan web itu habis, permintaan web berikut di server itu yang memerlukan permintaan luwak juga akan habis. Apa masalah sebenarnya adalah bahwa acara ZERO dipicu oleh luwak (tidak ada error , close , disconnected , dll ...), jadi kami tidak memiliki cara untuk mendeteksi pemutusan dan restart server. Inilah cara kami mengatur luwak:

mongoose.Promise = global.Promise;
mongoose.set('debug', process.env.NODE_ENV === 'development');
const mongoConnectOpts = { reconnectTries: 10, reconnectInterval: 500, socketOptions: { keepAlive: 300000, connectTimeoutMS: 30000 } };
mongoose.connect(process.env.MONGODB_URI, { server: mongoConnectOpts, replset: mongoConnectOpts });
mongoose.connection.on('error', err => {
  logfmt.log({ event: 'mongoose:error', ...err });
  process.exit(0);
});
mongoose.connection.on('connected', () => logfmt.log({ event: 'mongoose:connected', uri: _.truncate(process.env.MONGODB_URI) }));
mongoose.connection.on('disconnected', () => {
  logfmt.log({ event: 'mongoose:disconnected' });
  process.exit(0);
});
mongoose.connection.on('close', () => logfmt.log({ event: 'mongoose:close' }));
mongoose.connection.on('reconnected', () => logfmt.log({ event: 'mongoose:reconnected' }));

// Setup Redis cache (Default cache TTL: 60 seconds)
cachegoose(mongoose, { engine: 'redis', client: redisCache }, process.env.NODE_ENV === 'development');

@Ioris dapatkah Anda melihat apakah ini masih terjadi jika Anda menonaktifkan cachegoose?

@vkarpov15 Akan mencoba memeriksa ini tetapi tidak mudah karena bug hanya terjadi pada produksi dan kami tidak dapat menjalankan produksi dengan cache yang dinonaktifkan.
@aartiles @mck- @lushchick apakah kalian menggunakan plugin cache luwak?

Mungkin ini terkait dengan https://github.com/christkv/mongodb-core/issues/148 . Saya telah mengalami masalah serupa ketika anggota replika menjadi tidak tersedia.

Kami tidak menggunakan plugin cache luwak.

Saya masih mencarinya, apa yang bisa saya katakan sejauh ini:

• Saya dapat mereproduksi masalah di mesin lokal saya: Saya memulai loop menjalankan kueri cepat setiap detik dan mencatat hasil, beberapa penundaan kemudian, saya menjalankan kueri berat (seperti kueri yang tidak diindeks pada koleksi sejuta baris). Semua kueri (yang cepat juga) akan dikunci/waktu habis, tidak ada acara luwak yang akan dipecat.
• Masalah muncul di 4.6.5 , menurunkan versi ke 4.6.4 perbaiki masalah (kueri cepat masih dijalankan saat kueri berat sedang berjalan)
• Sepertinya itu tidak ada hubungannya dengan:
  
  
  
  • plugin cache luwak
  
  
  • menjalankan set replika atau tidak
  
  

Saya melakukan lebih banyak penggalian dan masalah datang dengan memutakhirkan ke [email protected] , dan komit kereta di sana adalah https://github.com/mongodb/node-mongodb-native/pull/1418
sepertinya mereka memperbaiki kesalahan ketik, tetapi eventName itu (dengan kesalahan ketik) sedang digunakan oleh beberapa deps

@loris Apakah Anda tahu di mana sisa referensi dengan nama acara yang salah? Saya dapat membuat PR untuk memperbaikinya tetapi saya tidak dapat menemukannya.

@jakesjews Tidak dapat menemukan referensi juga, jadi saya mungkin salah tentang penyebab saya mungkin telah memeriksa versi yang tidak cocok di mesin saya, saya akan menghubungi Anda kembali

Memiliki masalah serupa: kegagalan untuk menyambung kembali setelah terputus. Ini bermanifestasi di klien dengan bergantung pada operasi db luwak (waktu habis melalui buffering operasi).

@jakesjews masalah saya unik untuk set replika juga dan tidak terjadi dengan koneksi simpul tunggal. Melihat lebih ke inti replset.js.

Mengaktifkan debug logging dalam node-mongodb-native untuk melihat apakah koneksi ulang HA berfungsi seperti yang diharapkan.

attemptReconnect for replset with id successful resuming topologyMonitor 1

Meskipun driver node-mongodb-native mengklaimnya berhasil melakukan upayanyaReconnect, luwak tidak akan

Seperti yang disebutkan @loris , process.exit(0) -> restart layanan akan berfungsi (dalam kasus saya) karena masalah ini terkait langsung dengan koneksi ulang ke set replika tetapi sekali lagi tidak ideal.

[email protected]
[email protected]

@mck- Ditemukan sama seperti Anda, menurunkan versi ke 4.5.3 memperbaiki masalah reconnect untuk koneksi replicaset saya.

Saya dapat memutakhirkan sepenuhnya ke 4.5.10 sebelum mulai gagal pada 4.6.0 di mana masalah penyambungan kembali replika terjadi untuk pertama kalinya. Dugaan saat ini adalah bahwa itu mungkin terkait dengan peningkatan ke driver mongodb 2.2.9.

@loris dapatkah Anda memberikan test case Anda sehingga kami dapat mencobanya?

Saya masih melihatnya, saya salah sebelumnya tentang komit perbaikan kesalahan ketik. Sepertinya pelakunya adalah https://github.com/christkv/mongodb-core/pull/146/commits/09caa9d1e5423acd2f8f154f7b7430028e77e57f
Menyediakan kasus uji agak rumit karena hanya terjadi seperti ini:

• luwak 4.6.8 , menghubungkan ke localhost mongodb saya (3.2) dengan pengaturan default
• 2 rute ekspres, satu menjalankan kueri luwak yang berjalan lama (beberapa detik), satu menjalankan kueri luwak yang berjalan cepat (masalah tidak terjadi saat menjalankan kueri luwak secara langsung di node, dengan kasus uji setInterval/setTimeout misalnya, jadi tebakan saya adalah bahwa ini terkait dengan bagaimana koneksi pool ditangani)
• Jika saya menjalankan rute ekspres yang berjalan lama, kemudian mencoba untuk mencapai yang berjalan cepat, yang terakhir akan terus berjalan tanpa kembali
• Menyetel poolSize ke 50 alih-alih yang default, perbaiki masalahnya
• Memeriksa komit sebelumnya dari mongodb-core memperbaiki masalah juga (rute ekspres yang berjalan cepat kembali dalam beberapa ms saat rute yang berjalan lama sedang diproses) (dengan ukuran kumpulan default)
• Jadi saya kira https://github.com/christkv/mongodb-core/pull/146/commits/09caa9d1e5423acd2f8f154f7b7430028e77e57f mengubah sesuatu dalam cara seekor luwak yang berjalan lama dapat menggunakan setiap koneksi yang tersedia di kumpulan

Perbaikan baru saja mendarat di mongo-core yang mungkin memperbaiki masalah ini.

@loris ya meningkatkan ukuran kolam akan membantu. Sepertinya Anda mengalami masalah kereta lambat di mana server mongodb tidak dapat menangani lebih dari poolSize permintaan secara bersamaan. Meningkatkan ukuran kumpulan akan membantu, hanya saja jangan menambahnya terlalu banyak, atau Anda akan mulai melihat masalah kinerja dengan WiredTiger.

Hai,
ada update tentang ini? Saya melihat masalah yang sama, auto_reconnect tidak berfungsi saat menggunakan set replika. Saya baru saja mencoba luwak 4.7.0 dengan mongodb 2.2.11 dan masih belum terhubung kembali. Saya menggunakan mongod versi 3.2.10.

Saya menjalankan semuanya pada satu Host (laptop) dengan tiga contoh mongod yang berjalan pada port yang berbeda dengan direktori database yang berbeda. Sepertinya itu tidak menjadi masalah, tapi saya baru mengenal mongo/luwak/node/javascript. Aplikasi simpul saya dengan luwak juga berjalan di Host yang sama.

Saya dapat mereproduksi ini hanya dengan mematikan semua proses mongod
(launchctl stop mongod01; launchctl stop mongod02; launchctl stop mongod03)
tunggu pesan koneksi tertutup lalu restart (ganti "stop" dengan "start" di perintah launchctl). Aplikasi saya tidak pernah terhubung kembali ke mongo.

Jika saya melakukan tes yang sama dengan satu instance mongod yang tidak dikonfigurasi sebagai set replika, luwak terhubung kembali dengan baik.

senang memberikan log atau mencoba tambalan jika itu membantu.

Setelah melakukan penggalian, saya pikir saya mungkin telah menemukan satu sumber masalahnya. Sepertinya ketika autoreconnect benar buffer koneksi tidak seharusnya menjadi aktif https://github.com/Automattic/mongoose/blob/master/lib/drivers/node-mongodb-native/connection.js#L153 pada koneksi menutup acara. Namun tidak ada lagi properti autoReconnect yang diatur di dalam kelas replset di mongodb-native https://github.com/mongodb/node-mongodb-native/blob/2.2/lib/replset.js sehingga setiap acara dekat dari satu node menyebabkan buffer diaktifkan secara permanen. Saya beruntung dengan komit https://github.com/eflexsystems/mongoose/commit/5ac12727f34b41791f94643b66c8cc88aff4d66a tetapi saya ingin memberikannya lebih banyak waktu untuk melihat apakah itu menyebabkan masalah lain sebelum saya membuat permintaan tarik.

@joeldodson Anda menjelaskan masalah yang sama yang saya alami. Hanya rilis pendahuluan >= 4.6.0 tampaknya mengandung masalah. Saya akan mencoba 4.5.10 sementara itu, telah terhubung kembali ke replset dan koneksi tunggal baik-baik saja untuk saya.

Terima kasih @jakesjews dan @kog13

Saya mencoba 4.5.10 dan luwak terhubung kembali setelah memulai ulang set replika. Namun db.readyState tampaknya tidak dihapus setelah semua instance dalam set replika dihentikan. Kami sedang memeriksanya untuk menentukan apakah akan menolak permintaan apa pun (sehingga mereka tidak mengantri menunggu aplikasi terhubung kembali ke DB). Juga, saya tidak mendapatkan pemberitahuan terputus atau koneksi ditutup dengan 4.5.10.

Saya sudah memiliki logika yang duduk dalam satu lingkaran dengan timer 5 detik untuk mencoba terhubung jika DB tidak tersedia saat aplikasi dimulai. Kami telah mencoba memanggilnya di handler db.on('closed', function(){...}) dan tampaknya berfungsi dengan baik. Kekhawatiran saya adalah apakah mencoba terhubung secara eksplisit akan memiliki konflik dengan logika koneksi ulang apa pun di bawah tenda. Karena reconnect sepertinya tidak terjadi untuk set replika, saya pikir tidak apa-apa. Kami juga menyetel auto_reconnect ke false dalam opsi koneksi untuk server dan replset.

@jakesjews - Saya mencoba tambalan yang Anda sebutkan di atas tetapi masih belum terhubung kembali. Mungkin saya melewatkan sesuatu tetapi sepertinya tambalan itu lebih tentang memastikan acara tutup dibuat dan readyState diperbarui.

Saya senang mencoba tambalan lagi untuk auto_reconnect jika ada yang punya. Saya akan terus menggali juga.

Terima kasih.

@joeldodson selain tambalan di atas, Anda juga harus bergantung pada rilis terbaru pada mongo-core yang memiliki perbaikan untuk memastikan koneksi monitor set replika tetap hidup. Jika Anda mencoba garpu saya, itu seharusnya sudah ada.

Saya pikir saya berada di tempat yang cukup bagus sehubungan dengan batas waktu dan failover sekarang dengan luwak. Jika ada orang lain yang ingin mencobanya, Anda akan ingin menggunakan garpu luwak saya selain mengatur socketTimeout ke 0 di socketOptions.

Alasan untuk mengatur socketTimeout ke 0 adalah karena ada bug di mongo-core yang masih perlu saya laporkan. Masalah ini disebabkan oleh kumpulan koneksi yang menyusut/memperluas secara dinamis. Cara kerja pool adalah setiap kali menambahkan koneksi baru, koneksi akan ditutup setelah 30 detik tidak aktif. Peristiwa batas waktu memicu penghapusan dari kumpulan dan juga menjalankan pemeriksaan yang membandingkan jumlah batas waktu dengan batas 30 upaya koneksi. Ada detak jantung yang berjalan setiap 2 detik dan menghapus jumlah batas waktu tetapi jika 30 atau lebih permintaan diantrekan secara paralel, itu akan menyebabkan semuanya kehabisan waktu di antara detak jantung dan menghancurkan kumpulan koneksi. Untuk saat ini menyetel batas waktu pada koneksi ke 0 mencegah koneksi dipangkas kembali di kumpulan jika tidak aktif dan menghindari masalah. Jika Anda ingin mereplikasi masalah, coba atur ukuran kumpulan koneksi ke sekitar 50 dan jalankan 50 kueri paralel. Setelah itu terjadi kolam akan hancur dalam waktu sekitar 30 detik. Perhatikan bahwa batas waktu tidak memengaruhi detak jantung yang memeriksa kumpulan replika karena memiliki batas waktu sendiri.

Saya benar-benar disibukkan dengan pekerjaan baru-baru ini, jadi saya tidak memiliki kesempatan untuk mengumpulkan semua perubahan ini bersama-sama, tetapi saya berharap untuk segera melakukannya.

Terima kasih sekali lagi @jakesjews. Saya menarik repo luwak dan mongodb-core Anda. Sambungan ulang berhasil. Saya tidak mendapatkan acara 'terhubung' dan 'terhubung kembali' yang saya dapatkan saat menggunakan satu instance Mongo. Juga readyState tampaknya tidak disetel ulang, masih 0 bahkan setelah terhubung kembali.

Saya senang membantu menguji atau mengumpulkan log.

Masih mengalami masalah dengan [email protected]

Ada yang baru tentang hal ini?

Mengalami masalah juga di sini. Harus mengembalikan pemutakhiran versi luwak karena masalah koneksi. Kueri yang membutuhkan waktu beberapa detik saat ini membuat koneksi kami habis, yang sebelumnya tidak demikian.

Masalah ini harus ditangani jika tidak paket tidak dapat digunakan.
Mungkin akan mencoba solusi @jakesjews ketika saya punya waktu. Sampai saat itu menggunakan 4.4.X

Jika masalahnya adalah bug dengan mongo-core, ini sebenarnya bukan masalah dengan luwak. Jika Anda mendapatkan masalah dengan versi terbaru dari luwak, dapatkah Anda mengajukan masalah di repo mongodb-core ?

Sebenarnya ini adalah masalah dengan mongoose karena telah diperbarui bergantung pada versi mongodb-core mengalami masalah. Mungkin mongoose harus dikembalikan ke versi mongodb-core .

@jakesjews Melihat bahwa [email protected] bergantung pada [email protected] , yang pada gilirannya bergantung pada [email protected] , menerapkan perbaikan dari garpu Anda adalah semua yang diperlukan untuk memperbaiki masalah ini dengan tampaknya tidak ada efek samping?

Dan melihat garpu Anda, komit ini sekarang satu-satunya perubahan yang diperlukan untuk PR 4.7.x dan/atau 4.8.x?

@Koslun garpu seharusnya tidak perlu sekarang. Cara mengatasinya cukup banyak hanya mengatur socketTimeout ke 0 untuk database socketOptions sekarang.

Inilah tampilan opsi soket saya sekarang.

    var opts = {
      server: {
        socketOptions: {
          keepAlive: 1,
          socketTimeout: 0
        }
      },
      replSet: {
        socketOptions: {
          keepAlive: 1,
          socketTimeout: 0
        }
    }

@jakesjews Ok, terima kasih atas klarifikasinya yang cepat :).

Apakah Anda tahu di versi mongodb-core mana kami akan melihat perbaikan untuk bug ini? Atau alternatif memiliki masalah, PR atau komit kami dapat melacak?

Adakah pembaruan tentang komentar

Adakah pembaruan untuk masalah ini?

Masalah ini masih terbuka dari 2016 :open_mouth:

Saya bertanya-tanya apakah masalah ini masih dapat terjadi pada luwak 5.x dengan driver mongodb 3.3.4 dan server MongoDB pada versi 4.x? :pemikiran:

Adakah yang tahu, jika reconnectTries disetel ulang saat rekoneksi berhasil.

Contoh Fox, jika reconnectTries diatur ke 30, dan sekali terputus luwak mencoba 5 kali dan koneksi berhasil.
Lain kali koneksi terputus, Apa yang akan menjadi penghitung untuk mencoba lagi?
Apakah akan mencoba menyambung kembali 30 kali?
Atau 25 kali?

@szabolcs-szilagyi ya, tetapi hanya jika Anda tidak menetapkan useUnifiedTopology ke true .

@bhaveshvyas007 ya memang begitu. Berikut kode yang relevan

Untuk anak cucu:

Jika Anda menjalankan Mongoose 5.x tanpa useUnifiedTopology , baca panduan ini untuk mengelola koneksi MongoDB .

Jika Anda menjalankan Mongoose 5.x dengan useUnifiedTopology , masalah ini tidak memengaruhi Anda.