Hoe MongoDB Java-stuurprogramma MongoOptions configureren voor productiegebruik?

Bijgewerkt naar 2.9:

• autoConnectRetry betekent eenvoudigweg dat het stuurprogramma automatisch probeert opnieuw verbinding te maken met de server(s) nadat de verbinding onverwacht is verbroken. In productieomgevingen wil je dit meestal op true zetten.

• connectionsPerHost zijn de hoeveelheid fysieke verbindingen die een enkele Mongo-instantie (het is een singleton, dus je hebt er meestal één per applicatie) kan maken met een mongod/mongos-proces. Op het moment van schrijven zal het java-stuurprogramma dit aantal verbindingen uiteindelijk tot stand brengen, zelfs als de werkelijke querydoorvoer laag is (in volgorde van woorden zul je de "conn" -statistiek in mongostat zien stijgen totdat het dit aantal per app-server bereikt).

  Het is in de meeste gevallen niet nodig om dit hoger dan 100 in te stellen, maar deze instelling is een van die "test het en zie" dingen. Houd er rekening mee dat u ervoor moet zorgen dat u dit laag genoeg instelt, zodat het totale aantal verbindingen met uw server niet groter is dan

  db.serverStatus().connections.available

  In productie hebben we dit momenteel op 40.

• connectTimeout . Zoals de naam al doet vermoeden, wacht het stuurprogramma een aantal milliseconden voordat een verbindingspoging wordt afgebroken. Stel de time-out in op iets lang (15-30 seconden), tenzij er een realistische, verwachte kans is dat dit anders succesvolle verbindingspogingen in de weg staat. Als een verbindingspoging langer dan een paar seconden duurt, is uw netwerkinfrastructuur normaal gesproken niet in staat tot een hoge doorvoer.

• maxWaitTime . Aantal ms dat een thread wacht tot een verbinding beschikbaar komt op de verbindingspool, en genereert een uitzondering als dit niet op tijd gebeurt. Standaard behouden.

• socketTimeout . Standaard socket-time-outwaarde. Stel in op 60 seconden (60000).

• threadsAllowedToBlockForConnectionMultiplier . Multiplier voor verbindingenPerHost die het aantal threads aangeeft dat mag wachten tot verbindingen beschikbaar komen als de pool momenteel is uitgeput. Dit is de instelling die de uitzondering "com.mongodb.DBPortPool$SemaphoresOut:Out of semaforen om db-verbinding te krijgen" veroorzaakt. Deze uitzondering wordt gegenereerd zodra deze threadwachtrij de threadsAllowedToBlockForConnectionMultiplier-waarde overschrijdt. Als de verbindingenPerHost bijvoorbeeld 10 is en deze waarde 5 is, kunnen maximaal 50 threads worden geblokkeerd voordat de bovengenoemde uitzondering wordt gegenereerd.

  Als u grote pieken in de doorvoer verwacht die grote wachtrijen kunnen veroorzaken, verhoogt u deze waarde tijdelijk. Precies om die reden hebben we het op dit moment op 1500. Als uw query-belasting consequent de server overtreft, moet u uw hardware-/schalingssituatie dienovereenkomstig verbeteren.

• readPreference . (UPDATE, 2.8+) Wordt gebruikt om de standaard leesvoorkeur te bepalen en vervangt "slaveOk". Stel een ReadPreference in via een van de klassenfabrieksmethoden. Een volledige beschrijving van de meest voorkomende instellingen vindt u aan het einde van dit bericht

• met . (UPDATE, 2.6+) Deze waarde bepaalt de "veiligheid" van het schrijven. Als deze waarde -1 is, worden er tijdens het schrijven geen fouten gerapporteerd, ongeacht netwerk- of databasefouten. WriteConcern.NONE is hiervoor de geschikte voorgedefinieerde WriteConcern. Als w 0 is, zullen netwerkfouten het schrijven doen mislukken, maar mongo-fouten niet. Dit wordt meestal "fire and forget"-schrijfacties genoemd en moet worden gebruikt wanneer prestaties belangrijker zijn dan consistentie en duurzaamheid. Gebruik WriteConcern.NORMAL voor deze modus.

  Als u w instelt op 1 of hoger, wordt het schrijven als veilig beschouwd. Veilige schrijfbewerkingen voeren het schrijven uit en volgen het op met een verzoek aan de server om te controleren of het schrijven is gelukt, of het ophalen van een foutwaarde als dat niet het geval was (met andere woorden, het stuurt een opdracht getLastError() nadat u hebt geschreven). Merk op dat totdat deze opdracht getLastError() is voltooid, de verbinding is gereserveerd. Als gevolg hiervan en het extra commando zal de doorvoer aanzienlijk lager zijn dan schrijven met w <=0. Met een w-waarde van precies 1 garandeert MongoDB dat het schrijven is gelukt (of aantoonbaar is mislukt) op de instantie waarnaar u het schrijven hebt verzonden.

  In het geval van replicasets kunt u hogere waarden gebruiken voor w die MongoDB vertellen om het schrijven naar ten minste "w" -leden van de replicaset te sturen voordat u terugkeert (of beter gezegd, wacht op de replicatie van uw schrijven naar "w" -leden ). U kunt w ook instellen op de tekenreeks "meerderheid" die MongoDB vertelt om het schrijven naar de meerderheid van de leden van de replicaset uit te voeren (WriteConcern.MAJORITY). Normaal gesproken zou u dit op 1 moeten zetten, tenzij u onbewerkte prestaties (-1 of 0) of gerepliceerde schrijfbewerkingen (>1) nodig heeft. Waarden hoger dan 1 hebben een aanzienlijke invloed op de schrijfsnelheid.

• fsync . Duurzaamheidsoptie die Mongo dwingt om na elke schrijfactie naar schijf te spoelen als deze is ingeschakeld. Ik heb nog nooit duurzaamheidsproblemen gehad met betrekking tot een schrijfachterstand, dus we hebben dit op false (de standaardinstelling) in productie.

• j *(NIEUWE 2.7+) *. Boolean dat wanneer ingesteld op waar MongoDB wordt gedwongen te wachten op een succesvolle vastlegging van een journaalgroep voordat hij terugkeert. Als je journaling hebt ingeschakeld, kun je dit inschakelen voor extra duurzaamheid. Raadpleeg http://www.mongodb.org/display/DOCS/Journaling om te zien wat journaling u oplevert (en dus waarom u deze vlag misschien wilt inschakelen).

ReadPreference Met de ReadPreference-klasse kunt u configureren naar welke mongod-instantiequery's worden gerouteerd als u met replicasets werkt. De volgende opties zijn beschikbaar:

• ReadPreference.primary() :Alle leesacties gaan alleen naar het primaire lid van de repset. Gebruik dit als u wilt dat alle query's consistente (de meest recent geschreven) gegevens retourneren. Dit is de standaardinstelling.

• ReadPreference.primaryPreferred() :Alle leesbewerkingen gaan indien mogelijk naar het primaire lid van de repset, maar kunnen secundaire leden opvragen als het primaire knooppunt niet beschikbaar is. Als de primaire niet beschikbaar is, worden de leesbewerkingen uiteindelijk consistent, maar alleen als de primaire niet beschikbaar is.

• ReadPreference.secondary() :Alle leesbewerkingen gaan naar secundaire repset-leden en het primaire lid wordt alleen gebruikt voor schrijven. Gebruik dit alleen als je kunt leven met uiteindelijk consistente lezingen. Extra repset-leden kunnen worden gebruikt om de leesprestaties op te schalen, hoewel er limieten zijn aan het aantal (stemmende) leden dat een repset kan hebben.

• ReadPreference.secondaryPreferred() :Alle reads gaan naar secundaire repset-leden als een van hen beschikbaar is. Het primaire lid wordt uitsluitend gebruikt voor schrijven, tenzij alle secundaire leden niet meer beschikbaar zijn. Afgezien van de terugval naar het primaire lid voor leesbewerkingen, is dit hetzelfde als ReadPreference.secondary().

• ReadPreference.nearest() :Leest naar het dichtstbijzijnde repset-lid dat beschikbaar is voor de databaseclient. Alleen gebruiken als uiteindelijk consistente uitlezingen acceptabel zijn. Het dichtstbijzijnde lid is het lid met de laagste latentie tussen de klant en de verschillende repset-leden. Aangezien drukke leden uiteindelijk een hogere latentie zullen hebben, zou ook automatisch de leesbelasting in evenwicht brengen, hoewel in mijn ervaring secundair (Voorkeur) dit beter lijkt te doen als de latenties van leden relatief consistent zijn.

Opmerking:al het bovenstaande heeft tag-compatibele versies van dezelfde methode die in plaats daarvan TaggableReadPreference-instanties retourneren. Een volledige beschrijving van replicaset-tags vindt u hier:Replica Set-tags