AKTUALIZACE :Náš článek podpory pro toto téma (v podstatě kopie tohoto příspěvku) se přesunul do našeho dokumentu pro řešení problémů s připojením.
Existuje známý problém, že síť Azure IaaS vynucuje časový limit nečinnosti přibližně třináct minut (empiricky dosažený). Pracujeme s Azure, abychom zjistili, jestli nemůžeme udělat věci uživatelsky přívětivějšími, ale mezitím ostatní uspěli, když nakonfigurovali možnosti ovladače, aby problém vyřešili.
Maximální doba nečinnosti připojení
Nejúčinnějším řešením, které jsme při práci s Azure a našimi zákazníky našli, bylo nastavit maximální dobu nečinnosti připojení pod čtyři minuty. Záměrem je zajistit, aby ovladač recykloval nečinná připojení, než firewall vynutí problém. Například jeden zákazník, který používá ovladač C#, nastavil MongoDefaults.MaxConnectionIdleTime do jedné minuty a vyřešilo to jejich problémy.
MongoDefaults.MaxConnectionIdleTime = TimeSpan.FromMinutes(1);
Samotný kód aplikace se nezměnil, ale nyní v zákulisí ovladač agresivně recykluje nečinná připojení. Výsledek je vidět i v protokolech serveru:během nečinnosti v aplikaci dochází k mnoha výpadkům připojení.
Další podrobnosti o tomto přístupu jsou uvedeny v souvisejícím vláknu mongo-user, SocketException pomocí ovladače C# na Azure.
Zachovat
Problém můžete také obejít tak, že vaše připojení budou méně nečinná pomocí nějakého druhu udržování naživu. To je trochu složitější implementovat, pokud to váš ovladač nepodporuje hned po vybalení, obvykle s využitím TCP Keepalive. Pokud potřebujete spustit svůj vlastní, ujistěte se, že každých pár minut uchopíte každé nečinné připojení z fondu a vydáte nějaký jednoduchý a levný příkaz, pravděpodobně ping.
Zpracování odpojení
K odpojení může čas od času dojít i bez agresivního nastavení brány firewall. Než se pustíte do výroby, musíte si být jisti, že s nimi zacházíte správně.
Nejprve nezapomeňte povolit automatické opětovné připojení. Jak to udělat, se liší ovladač od ovladače, ale když ovladač zjistí, že operace selhala, protože připojení bylo špatné, zapnutí automatického opětovného připojení sdělí ovladači, aby se pokusil znovu připojit.
To ale problém úplně neřeší. Stále máte problém, co dělat s neúspěšnou operací, která spustila opětovné připojení. Automatické opětovné připojení automaticky nezopakuje neúspěšné operace. To by bylo nebezpečné, zvláště pro psaní. Obvykle je tedy vyvolána výjimka a aplikace je požádána, aby ji zpracovala. Často je opakování čtení zbytečné. Ale opakování zápisu by mělo být pečlivě zváženo.
Relace mongo shell níže demonstruje problém. Mongo shell má ve výchozím nastavení povoleno automatické opětovné připojení. Vložím dokument do kolekce s názvem stuff pak najděte všechny dokumenty v této sbírce. Pak jsem nastavil časovač na třicet minut a zkusil jsem to samé najít znovu. Selhalo to, ale shell se automaticky znovu připojil a když jsem se okamžitě pokusil najít, fungovalo to podle očekávání.
% 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") }
Jsme tu, abychom vám pomohli
Samozřejmě, pokud máte nějaké dotazy, neváhejte nás kontaktovat na [email protected] Jsme tu, abychom vám pomohli.