Jak nakonfigurovat MongoDB Java ovladač MongoOptions pro produkční použití?

Aktualizováno na 2.9:

• autoConnectRetry jednoduše znamená, že se ovladač po neočekávaném odpojení automaticky pokusí znovu připojit k serveru (serverům). V produkčním prostředí obvykle chcete, aby toto nastavení bylo true.

• connectionsPerHost je množství fyzických připojení, které může jedna instance Mongo (je to jediná instance, takže obvykle máte jedno na aplikaci) vytvořit s procesem mongod/mongos. V době psaní tohoto textu ovladač java naváže toto množství spojení nakonec, i když je skutečná propustnost dotazu nízká (v pořadí slov uvidíte statistiku „conn“ v mongostatu stoupat, dokud nedosáhne tohoto čísla na aplikační server).

  Ve většině případů není potřeba toto nastavovat vyšší než 100, ale toto nastavení je jednou z věcí „otestujte a uvidíte“. Pamatujte, že se budete muset ujistit, že jste toto nastavili dostatečně nízko, aby celkový počet připojení k vašemu serveru nepřesáhl

  db.serverStatus().connections.available

  Ve výrobě jich máme aktuálně 40.

• Časový limit připojení . Jak název napovídá, kolik milisekund bude ovladač čekat, než se pokus o připojení přeruší. Nastavte časový limit na něco dlouhého (15-30 sekund), pokud neexistuje reálná, očekávaná šance, že to bude bránit jinak úspěšným pokusům o připojení. Obvykle, pokud pokus o připojení trvá déle než několik sekund, vaše síťová infrastruktura není schopna vysoké propustnosti.

• maxWaitTime . Počet ms, které vlákno bude čekat, než bude připojení dostupné ve fondu připojení, a pokud se tak nestane včas, vyvolá výjimku. Ponechat výchozí.

• socketTimeout . Standardní hodnota časového limitu soketu. Nastavte na 60 sekund (60 000).

• threadsAllowedToBlockForConnectionMultiplier . Multiplikátor pro connectionPerHost, který označuje počet vláken, která mohou čekat na zpřístupnění připojení, pokud je fond aktuálně vyčerpán. Toto je nastavení, které způsobí výjimku "com.mongodb.DBPortPool$SemaphoresOut:Out of semafores to get db connection". Tuto výjimku vyvolá, jakmile tato fronta vláken překročí hodnotu threadsAllowedToBlockForConnectionMultiplier. Pokud je například connectionPerHost 10 a tato hodnota je 5, může před vyvoláním výše uvedené výjimky zablokovat až 50 vláken.

  Pokud očekáváte velké špičky v propustnosti, které by mohly způsobit velké fronty, dočasně zvyšte tuto hodnotu. V tuto chvíli to máme na 1500 přesně z toho důvodu. Pokud zatížení vašeho dotazu trvale převyšuje server, měli byste odpovídajícím způsobem zlepšit situaci v oblasti hardwaru a škálování.

• Předvolby čtení . (AKTUALIZOVÁNO, 2.8+) Používá se k určení výchozí preference čtení a nahrazuje "slaveOk". Nastavte předvolbu čtení pomocí jedné z továrních metod třídy. Úplný popis nejběžnějších nastavení naleznete na konci tohoto příspěvku

• w . (AKTUALIZOVÁNO, 2.6+) Tato hodnota určuje "bezpečnost" zápisu. Když je tato hodnota -1, zápis nebude hlásit žádné chyby bez ohledu na chyby sítě nebo databáze. WriteConcern.NONE je pro to vhodný předdefinovaný WriteConcern. Pokud w je 0, pak chyby sítě způsobí selhání zápisu, ale chyby mongo nikoli. To se obvykle označuje jako zápisy „vypal a zapomeň“ a mělo by se používat, když je výkon důležitější než konzistence a trvanlivost. Pro tento režim použijte WriteConcern.NORMAL.

  Pokud nastavíte w na 1 nebo vyšší, zápis je považován za bezpečný. Bezpečné zápisy provádějí zápis a následují po něm požadavek na server, aby se ujistil, že zápis byl úspěšný, nebo načte chybovou hodnotu, pokud se tak nestalo (jinými slovy, po zápisu odešle příkaz getLastError()). Všimněte si, že dokud není tento příkaz getLastError() dokončen, připojení je rezervováno. V důsledku toho a dodatečného příkazu bude propustnost výrazně nižší než u zápisů s w <=0. S hodnotou w přesně 1 MongoDB zaručuje, že zápis byl úspěšný (nebo prokazatelně selhal) na instanci, do které jste zápis odeslali.

  V případě sad replik můžete použít vyšší hodnoty pro w, které říkají MongoDB, aby poslal zápis alespoň „w“ členům sady replik, než se vrátíte (nebo přesněji, počkejte na replikaci vašeho zápisu do „w“ členů ). Můžete také nastavit w na řetězec "majority", který říká MongoDB, aby provedl zápis do většiny členů sady replik (WriteConcern.MAJORITY). Obvykle byste toto měli nastavit na 1, pokud nepotřebujete hrubý výkon (-1 nebo 0) nebo replikované zápisy (>1). Hodnoty vyšší než 1 mají značný vliv na propustnost zápisu.

• fsync . Možnost trvanlivosti, která nutí mongo k vyprázdnění disku po každém zápisu, když je povoleno. Nikdy jsem neměl žádné problémy s trvanlivostí související s nevyřízenými zápisy, takže to máme ve výrobě na false (výchozí).

• j *(NOVINKA 2.7+) *. Logická hodnota, která když je nastavena na true, nutí MongoDB čekat na úspěšné potvrzení skupiny žurnálu, než se vrátí. Pokud máte povoleno žurnálování, můžete to povolit pro další trvanlivost. Podívejte se na http://www.mongodb.org/display/DOCS/Journaling, kde zjistíte, co vám žurnálování přináší (a tedy proč byste měli chtít povolit tento příznak).

Předvolby čtení Třída ReadPreference vám umožňuje konfigurovat, do kterých instancí mongodu jsou směrovány dotazy, pokud pracujete se sadami replik. K dispozici jsou následující možnosti:

• ReadPreference.primary() :Všechna čtení jdou pouze primárnímu členu repset. Toto použijte, pokud požadujete, aby všechny dotazy vracely konzistentní (nejnověji zapsaná) data. Toto je výchozí nastavení.

• ReadPreference.primaryPreferred() :Pokud je to možné, všechna čtení přejdou na primárního člena repset, ale mohou se dotazovat na sekundární členy, pokud primární uzel není dostupný. Pokud se tedy primární stane nedostupným, čtení se nakonec stane konzistentním, ale pouze v případě, že primární není dostupné.

• ReadPreference.secondary() :Všechna čtení přejdou na sekundární členy opakování a primární člen se používá pouze pro zápis. Použijte to pouze tehdy, pokud můžete žít s nakonec konzistentním čtením. Další členy repsetu lze použít ke zvýšení výkonu čtení, i když existují omezení počtu (hlasujících) členů, které může mít repset.

• ReadPreference.secondaryPreferred() :Všechna čtení přejdou na sekundární členy opakování, pokud je některý z nich dostupný. Primární člen se používá výhradně pro zápisy, pokud nebudou všichni sekundární členové nedostupní. Kromě záložního primárního člena pro čtení je to stejné jako ReadPreference.secondary().

• ReadPreference.nearest() :Čtení přejde na nejbližšího člena repset dostupného databázovému klientovi. Používejte pouze tehdy, jsou-li přijatelné konzistentní čtení. Nejbližší člen je člen s nejnižší latencí mezi klientem a různými repsetovými členy. Vzhledem k tomu, že zaneprázdnění členové budou mít nakonec vyšší latence, mělo by to také automaticky vyvažuje zatížení čtení, ačkoli podle mých zkušeností se zdá, že sekundární (preferovaný) to dělá lépe, pokud jsou latence členů relativně konzistentní.

Poznámka:Všechny výše uvedené mají verze stejné metody s povolenými značkami, které místo toho vracejí instance TaggableReadPreference. Úplný popis značek sady replik lze nalézt zde:Značky sady replik