Kā novērst MongoDB tīkla noildzes kļūdu Mongoose savienojumā

Svarīgākais risinājums ir pārstāt uzskatīt katru Mongoose noildzi par noildzes iestatījumu problēmu. Ziņa, piemēram, MongoServerSelectionError: connection timed out, parasti nozīmē, ka MongoDB draiveris nespēja atlasīt izmantojamu serveri pirms serverSelectionTimeoutMS beidzās. MongoDB pašreizējā problēmu novēršanas dokumentācija kā biežus cēloņus min tīkla savienojamību, Atlas IP piekļuves ierobežojumus, DNS SRV kļūmes un TLS konfigurāciju. Noildzes palielināšana var likt lietojumprogrammai gaidīt ilgāk, nemaz nepalabojot nevienu no šiem nosacījumiem.

Izmantojiet šādu secību: 1) identificējiet, kura noildze neizdevās, 2) pierādiet, ka lietojumprogrammas resursdators var sasniegt MongoDB, 3) koriģējiet savienojuma virkni vai vidē specifisko adresi un 4) pielāgojiet noildzes vērtības tikai tad, kad savienojamība ir zināma kā darbspējīga. Tālāk dotajos piemēros tiek izmantoti mūsdienu Mongoose savienojuma modeļi un pašreizējā MongoDB draivera uzvedība, kas dokumentēta 2026. gada septembrī.

Vispirms ziniet, ar kādu noildzi saskaraties

Mongoose zemāk izmanto MongoDB Node.js draiveri, tāpēc vienā savienojuma konfigurācijā var parādīties vairāki dažādi noildzes iestatījumi. Tie nenozīmē vienu un to pašu.

Mongoose pašreizējā savienojumu dokumentācija norāda, ka serverSelectionTimeoutMS noklusējuma vērtība ir 30 sekundes un attiecas gan uz sākotnējo mongoose.connect(), gan uz vēlākām darbībām, kurām jāatlasa serveris. MongoDB Node.js draivera savienojuma opciju dokumentācija atšķir šo vērtību no connectTimeoutMS un socketTimeoutMS.

Servera atlases noildze ir simptoms, kas vispirms jāklasificē; kļūdas detaļas un pamatcēlonis ir noderīgāki nekā tūlītēja 30 sekunžu ierobežojuma palielināšana.

1. darbība: iegūstiet precīzu Mongoose kļūdu un tās pamatcēloni

Sāciet ar minimālu savienojumu un reģistrējiet pietiekami daudz informācijas, lai atšķirtu DNS, autentifikācijas, TLS un sasniedzamības kļūmes:

import mongoose from 'mongoose';

try {
  await mongoose.connect(process.env.MONGODB_URI, {
    serverSelectionTimeoutMS: 5000
  });

  console.log('MongoDB connected');
} catch (err) {
  console.error(err);
  console.error('Reason:', err.reason);
  process.exit(1);
}

Augstāk minētā 5 sekunžu vērtība ir diagnostikas izvēle, nevis ražošanas ieteikums katram izvietošanai. Mongoose norāda, ka serverSelectionTimeoutMS samazināšana var sniegt ātrāku atgriezenisko saiti, taču tas īpaši brīdina pret to nejaušu samazināšanu repliku kopām, jo noklusējuma 30 sekunžu logs var palīdzēt darbībām izturēt vēlēšanas un kļūmju pārslēgšanos. Mongoose biežāk iesaka īsākas vērtības atsevišķam MongoDB vai serverless izpildlaikiem, kur ātra kļūme ir noderīga.

Meklējiet tādas norādes kā:

• getaddrinfo ENOTFOUND — DNS nosaukumu nevar atrisināt.
• ECONNREFUSED — kaut kas aktīvi noraidīja TCP savienojumu, bieži vien tāpēc, ka resursdatorā/portā nekas neklausās.
• ETIMEDOUT — savienojuma mēģinājums netika pabeigts laikā, bieži vien tāpēc, ka satiksme tiek filtrēta, nepareizi maršrutēta vai galamērķis nav pieejams.
• TLS vai sertifikāta teksts — izpētiet sertifikāta uzticamību, resursdatora nosaukuma atbilstību, protokola atbalstu vai TLS konfigurāciju.
• Autentifikācijas kļūdas err.reason iekšienē — labojiet akreditācijas datus vai authSource, nevis mainiet tīkla noildzes.

Nosacījums: ja kļūda jau norāda, ka autentifikācija neizdevās, izlaidiet ugunsmūra pielāgošanu, līdz akreditācijas dati un autentifikācijas datubāze ir pareizi. Tīkla noildze un noraidīta pieteikšanās ir dažādas kļūmes klases.

2. darbība: pierādiet tīkla, Atlas IP piekļuves un DNS sasniedzamību no tā paša izpildlaika

Veiciet savienojamības testus no tās pašas mašīnas, konteinera, VM, serverless funkcijas vai Kubernetes poda, kur darbojas Node.js process. Testēšana no jūsu klēpjdatora nav pietiekama, ja ražošanas vide darbojas citur.

Atlas gadījumā pārliecinieties, ka lietojumprogrammas reālais izejas IP ir atļauts; vietējai izvietošanai pārliecinieties, ka MongoDB process patiešām klausās paredzētajā interfeisā un portā.

Ja izmantojat MongoDB Atlas

Atlas pieņem klienta savienojumus tikai no adresēm, kuras atļauj projekta IP piekļuves saraksts. MongoDB to dokumentē IP piekļuves saraksta pārvaldībā. Pārliecinieties, ka ir norādīts lietojumprogrammas vides publiskais izejas IP, nevis tikai jūsu personīgā darbstacijas IP.

MongoDB servera atlases noildzes problēmu novēršanas rokasgrāmata arī iesaka pārbaudīt izejošo TCP savienojamību ar MongoDB portā 27017, kā arī ugunsmūrus, drošības grupas, tīkla ACL, VPN un starpniekserverus.

Piemēram, no Linux vai macOS varat testēt konkrētu Atlas mezglu vai pašpārvaldītu resursdatoru ar:

nc -vz your-mongodb-host.example.com 27017

Windows PowerShell aptuvens TCP sasniedzamības tests ir:

Test-NetConnection your-mongodb-host.example.com -Port 27017

Veiksmīgs TCP tests nepierāda, ka autentifikācija vai TLS izdosies, bet neizdevies TCP tests nozīmē, ka Mongoose noildzes pielāgošana ir priekšlaicīga.

Ja jūsu URI izmanto mongodb+srv://

SRV savienojuma virkne ir atkarīga no DNS SRV ierakstiem. MongoDB pašreizējie problēmu novēršanas soļi iesaka pārbaudīt SRV meklēšanu no klienta vides:

nslookup -type=SRV _mongodb._tcp.cluster-name.mongodb.net

Ja SRV vaicājums neizdodas, apstipriniet resursdatora nosaukumu un DNS konfigurāciju. MongoDB dokumentē nesRV mongodb:// savienojuma virkni kā iespējamu apvedceļu, ja vide nevar atrisināt SRV ierakstus, taču šo standarta savienojuma virkni vajadzētu iegūt no Atlas vai jūsu izvietošanas konfigurācijas, nevis izgudrot mezglu nosaukumus. Skatiet Atlas savienojumu problēmu novēršanu.

Pareizā diagnostikas secība pārbauda adresi un tīkla ceļu, pirms uzskata noildzes vērtības par pamatcēloni.

3. darbība: labojiet URI videi, kurā patiešām darbojas Node.js

Sintaktiski derīga MongoDB URI joprojām var norādīt uz nepareizu vietu. Pārbaudiet shēmu, resursdatora nosaukumu, portu, datubāzes nosaukumu, repliku kopas prasības, autentifikācijas avotu un to, vai resursdatora nosaukums ir nozīmīgs no lietojumprogrammas tīkla nosaukumu telpas viedokļa.

Vietējs Node.js un vietējs MongoDB

Mongoose pašlaik iesaka vietējam MongoDB izmantot 127.0.0.1, nevis localhost:

await mongoose.connect('mongodb://127.0.0.1:27017/myapp');

Iemesls ir Node.js 18 un jaunāki: Mongoose norāda, ka Node.js var atrisināt localhost uz IPv6 ::1, savukārt vietējā MongoDB instance var klausīties tikai IPv4. Mongoose arī dokumentē { family: 4 } kā opciju, kad IPv6-prioritāta atrisināšana padara savienojuma mēģinājumus lēnus:

await mongoose.connect('mongodb://localhost:27017/myapp', {
  family: 4
});

Izmantojiet family: 4 tikai tad, ja IPv4/IPv6 atrisināšanas ceļš patiešām ir problēma. Ja jūsu MongoDB izvietošana pareizi atbalsta IPv6, IPv4 piespiešana nav nepieciešama.

Node.js Docker konteinerā

Ja lietojumprogramma atrodas konteinerā, localhost attiecas uz šo konteineru, nevis automātiski uz MongoDB resursdatorā vai citā konteinerā. Izmantojiet MongoDB pakalpojuma/konteinera resursdatora nosaukumu kopīgā Docker tīklā vai platformai specifisko resursdatora adresi, ja MongoDB darbojas resursdatorā.

Piemēram, ar Compose pakalpojumu ar nosaukumu mongo:

MONGODB_URI=mongodb://mongo:27017/myapp

Nosacījums: šis piemērs attiecas tikai tad, ja konteineri kopīgo tīklu un MongoDB pakalpojums patiešām ir nosaukts mongo. Nekopējiet resursdatora nosaukumu nesaistītā izvietošanā.

Atlas

Izmantojiet Atlas ģenerēto savienojuma virkni jūsu draiverim, saglabājiet mongodb+srv:// resursdatoru precīzi, URL kodējiet rezervētās rakstzīmes lietotājvārdos vai parolēs, kad nepieciešams, un pārbaudiet, vai datubāzes lietotājs eksistē paredzētajā projektā.

Ja veidojat savienojumu ar pašpārvaldītu repliku kopu, repliku kopas ziņotajiem resursdatoru nosaukumiem arī jābūt sasniedzamiem no klienta. Sēklas resursdators var būt sasniedzams, bet vēlākā servera atlase joprojām var neizdoties, jo repliku kopas locekļi reklamē resursdatoru nosaukumus, kurus lietojumprogramma nevar atrisināt vai maršrutēt.

4. darbība: pielāgojiet noildzes tikai pēc tam, kad savienojums ir izdevies

Kad DNS atrisinās, tīkla ceļš darbojas, serveris ir pieejams un URI ir pareizs, noildzes pielāgošana kļūst jēgpilna.

Mongoose nodod ar noildzi saistītās savienojuma opcijas pamatā esošajam MongoDB draiverim, taču katra opcija kontrolē citu posmu; lielākas vērtības nevajadzētu izmantot, lai slēptu bojātu ceļu vai nepieejamu serveri.

Konservatīvs piemērs lietojumprogrammai, kas vēlas 10 sekunžu sākotnēju kļūmes signālu, varētu izskatīties šādi:

await mongoose.connect(process.env.MONGODB_URI, {
  serverSelectionTimeoutMS: 10000,
  connectTimeoutMS: 10000
});

Vai 10 sekundes ir piemērotas, ir atkarīgs no izvietošanas. Kompromiss ir vienkāršs:

Attiecībā uz socketTimeoutMS, pašreizējā MongoDB Node.js draivera dokumentācija izmanto noklusējuma vērtību 0, kas nozīmē, ka nav ligzdas neaktivitātes noildzes. MongoDB iesaka, ja izlemjat to iestatīt, izvēlēties vērtību, kas ir aptuveni divas līdz trīs reizes garāka nekā lēnākā paredzētā darbība. Šis iestatījums attiecas uz ligzdām, kas jau ir izveidojušas savienojumu, tāpēc tas nav galvenais risinājums sākotnējai servera atlases noildzei.

Nekopējiet vecas Mongoose savienojuma opcijas pašreizējā projektā

Daudzos vecākos piemēros joprojām ir useNewUrlParser, useUnifiedTopology, keepAlive vai keepAliveInitialDelay. Pašreizējais Mongoose neprasa vecos parsera/topoloģijas ieslēgšanas iestatījumus, un Mongoose dokumentē keepAlive kā pēc noklusējuma iespējotu kopš Mongoose 5.2 un novecojušu kā savienojuma opciju kopš 7.2.

Mūsdienīgs pamats ir apzināti mazs:

import mongoose from 'mongoose';

await mongoose.connect(process.env.MONGODB_URI);

Pievienojiet savienojuma opcijas, jo jūsu videi tās ir nepieciešamas, nevis tāpēc, ka tās parādījās pirms pieciem gadiem rakstītā fragmentā.

Ko darīt, ja savienojums darbojas, bet vaicājumi vēlāk beidzas ar noildzi?

Tā ir cita problēma. Ja mongoose.connect() izdodas un lietojumprogramma vēlāk karājas vaicājumu laikā, izpētiet darbības latentumu, savienojuma kopiena spiedienu, servera slodzi, indeksus un ligzdas vai darbības noildzes. MongoDB pašreizējais Node.js draiveris atdala:

• serverSelectionTimeoutMS — piemērota servera atrašana.
• connectTimeoutMS — viena TCP savienojuma izveide.
• socketTimeoutMS — neaktivitāte izveidotā ligzdā.
• maxTimeMS — ierobežo, cik ilgi servera darbība var ilgt, kad tā sasniedz MongoDB.

Ja neizdodas tikai gari vaicājumi, serverSelectionTimeoutMS palielināšana, visticamāk, neatrisinās īsto problēmu.

Ātra diagnostika pēc kļūmes nosacījuma

Ražošanai draudzīgs savienojuma modelis

Uzglabājiet noslēpumus ārpus avota koda, skaidri lieciet palaišanai neizdoties, ja datubāze nav pieejama, un reģistrējiet pietiekami daudz detaļu diagnostikai, nedrukājot akreditācijas datus:

import mongoose from 'mongoose';

export async function connectDatabase() {
  const uri = process.env.MONGODB_URI;

  if (!uri) {
    throw new Error('MONGODB_URI is not set');
  }

  try {
    await mongoose.connect(uri, {
      serverSelectionTimeoutMS: 30000,
      connectTimeoutMS: 30000
    });

    console.log('MongoDB connected');
  } catch (err) {
    console.error('MongoDB connection failed:', err.message);
    console.error('Server selection reason:', err.reason);
    throw err;
  }
}

Šīs 30 sekunžu vērtības atbilst pašreizējām dokumentētajām noklusējuma vērtībām, tāpēc tās var izlaist, ja politikas skaidrošana nepalīdz jūsu darbībām. Svarīgākā daļa nav skaitļi; svarīgi ir zināt, kāpēc cita skaitliskā vērtība būtu labāka jūsu izvietošanai.

Gala pārbaudes saraksts

• Iegūstiet pilnu kļūdu un pārbaudiet err.reason.
• Apstipriniet, ka MongoDB izvietošana darbojas un ir pieejama.
• Veiciet DNS un TCP testus no tās pašas vides kā Node.js process.
• Atlas gadījumā pārbaudiet, vai lietojumprogrammas izejas IP ir IP piekļuves sarakstā.
• Priekš mongodb+srv:// pārbaudiet SRV DNS atrisināšanu.
• Vietējam MongoDB mēģiniet 127.0.0.1, ja localhost atrisinās uz nelietojamu IPv6.
• Docker vai Kubernetes gadījumā izmantojiet resursdatora nosaukumu, kas ir derīgs šajā tīkla nosaukumu telpā.
• Labojiet TLS vai autentifikācijas kļūdas, nevis maskējiet tās ar lielāku noildzi.
• Pielāgojiet serverSelectionTimeoutMS, connectTimeoutMS vai socketTimeoutMS tikai tam posmam, ko tie patiešām kontrolē.
• Pēc labojuma pārbaudiet, vai lietojumprogramma konsekventi izveido savienojumu no reālās izvietošanas vides, nevis tikai no izstrādātāja klēpjdatora.

Secinājums

Ja Mongoose ziņo par MongoDB tīkla noildzi, vispirms pierādiet, ka draiveris var atklāt un sasniegt piemērotu MongoDB serveri. Atlas IP ierobežojumi, ugunsmūri, DNS SRV atrisināšana, nepareizi konteinera resursdatoru nosaukumi, IPv4/IPv6 neatbilstības, nepieejami MongoDB procesi un TLS konfigurācija var likt 30 sekunžu noildzei izskatīties pēc problēmas, lai gan taimeris tikai ziņo par kļūmi.

Izmantojiet noildzes iestatījumus, lai definētu, cik ilgi jūsu lietojumprogrammai jāgaida zināmai labai sistēmai, nevis lai kompensētu bojātu savienojuma ceļu. Kad tīkla sasniedzamība un URI ir pareizi, tad izvēlieties noildzes vērtības, kas atbilst jūsu pieejamības modelim, kļūmju pārslēgšanas uzvedībai un paredzētajai darbības latentumam.