UPPDATERA :Vår supportartikel för detta ämne (i huvudsak en kopia av det här inlägget) har flyttats till vårt anslutningsfelsökningsdokument.
Det finns ett känt problem att Azure IaaS-nätverket upprätthåller en inaktiv timeout på ungefär tretton minuter (empiriskt kommit fram till). Vi arbetar med Azure för att se om vi inte kan göra saker mer användarvänliga, men under tiden har andra haft framgång genom att konfigurera sina drivrutinsalternativ för att lösa problemet.
Max anslutning inaktiv tid
Den mest effektiva lösningen vi har hittat i arbetet med Azure och våra kunder har varit att ställa in den maximala inaktiva tiden för anslutningen under fyra minuter. Tanken är att få föraren att återvinna lediga anslutningar innan brandväggen tvingar fram problemet. Till exempel, en kund som använder C#-drivrutinen ställer in MongoDefaults.MaxConnectionIdleTime till en minut och det löste deras problem.
MongoDefaults.MaxConnectionIdleTime = TimeSpan.FromMinutes(1);
Själva applikationskoden ändrades inte, men nu bakom kulisserna återvinner föraren aggressivt lediga anslutningar. Resultatet kan också ses i serverloggarna:massor av anslutningsstörningar under inaktiva perioder i appen.
Det finns mer information om detta tillvägagångssätt i den relaterade mongo-användartråden, SocketException som använder C#-drivrutinen på azure.
Keepalive
Du kan också komma runt problemet genom att göra dina anslutningar mindre inaktiva med någon form av keepalive. Detta är lite knepigt att implementera om inte din drivrutin stöder det direkt, vanligtvis genom att dra fördel av TCP Keepalive. Om du behöver rulla din egen, se till att ta tag i varje ledig anslutning från poolen varannan minut och utfärda ett enkelt och billigt kommando, förmodligen en ping.
Hantera frånkopplingar
Avbrott kan inträffa då och då även utan en aggressiv brandväggsinstallation. Innan du sätter dig i produktion vill du vara säker på att hantera dem korrekt.
Se först till att aktivera automatisk återanslutning. Hur man gör det varierar från förare till förare, men när föraren upptäcker att en åtgärd misslyckades på grund av att anslutningen var dålig, aktiveras automatisk återanslutning uppmanar föraren att försöka återansluta.
Men detta löser inte problemet helt. Du har fortfarande frågan om vad du ska göra med den misslyckade operationen som utlöste återanslutningen. Automatisk återanslutning försöker inte automatiskt igen misslyckade operationer. Det skulle vara farligt, särskilt för skribenter. Så vanligtvis kastas ett undantag och appen uppmanas att hantera det. Att försöka läsa igen är ofta en självklarhet. Men att försöka skriva igen bör övervägas noggrant.
Mongo shell-sessionen nedan visar problemet. Mongo-skalet har som standard automatisk återanslutning aktiverat. Jag infogar ett dokument i en samling som heter stuff hitta sedan alla dokument i den samlingen. Jag ställde sedan in en timer på trettio minuter och försökte samma fynd igen. Det misslyckades, men skalet anslöts automatiskt igen och när jag omedelbart försökte igen fungerade det som förväntat.
% mongo ds012345.mongolab.com:12345/mydatabase -u *** -p ***
MongoDB shell version: 2.2.2
connecting to: ds012345.mongolab.com:12345/mydatabase
> db.stuff.insert({})
> db.stuff.find()
{ "_id" : ObjectId("50f9b77c27b2e67041fd2245") }
> db.stuff.find()
Fri Jan 18 13:29:28 Socket recv() errno:60 Operation timed out 192.168.1.111:12345
Fri Jan 18 13:29:28 SocketException: remote: 192.168.1.111:12345 error: 9001 socket exception [1] server [192.168.1.111:12345]
Fri Jan 18 13:29:28 DBClientCursor::init call() failed
Fri Jan 18 13:29:28 query failed : mydatabase.stuff {} to: ds012345.mongolab.com:12345
Error: error doing query: failed
Fri Jan 18 13:29:28 trying reconnect to ds012345.mongolab.com:12345
Fri Jan 18 13:29:28 reconnect ds012345.mongolab.com:12345 ok
> db.stuff.find()
{ "_id" : ObjectId("50f9b77c27b2e67041fd2245") }
Vi är här för att hjälpa dig
Naturligtvis, om du har några frågor är du välkommen att kontakta oss på [email protected]. Vi är här för att hjälpa dig.