Hvordan konfigureres MongoDB Java-driver MongoOptions til produktionsbrug?

Opdateret til 2.9 :

• autoConnectRetry betyder ganske enkelt, at driveren automatisk vil forsøge at genoprette forbindelsen til serveren/serverne efter uventede afbrydelser. I produktionsmiljøer ønsker du normalt, at dette sæt skal være sandt.

• forbindelserPerHost er mængden af ​​fysiske forbindelser en enkelt Mongo-instans (det er singleton, så du har normalt en pr. applikation) kan etablere til en mongod/mongos-proces. I skrivende stund vil java-driveren etablere denne mængde forbindelser til sidst, selvom den faktiske forespørgselsgennemstrømning er lav (i orden vil du se "conn"-statistikken i mongostat stige, indtil den rammer dette tal pr. app-server).

  Der er ingen grund til at sætte dette højere end 100 i de fleste tilfælde, men denne indstilling er en af ​​de "test det og se" ting. Bemærk, at du skal sørge for at indstille dette lavt nok, så det samlede antal forbindelser til din server ikke overstiger

  db.serverStatus().connections.available

  I produktion har vi i øjeblikket dette på 40.

• connectTimeout . Som navnet antyder antal millisekunder, vil driveren vente, før et forbindelsesforsøg afbrydes. Indstil timeout til noget langt (15-30 sekunder), medmindre der er en realistisk, forventet chance for, at dette vil være i vejen for ellers vellykkede forbindelsesforsøg. Normalt, hvis et forbindelsesforsøg tager længere tid end et par sekunder, er din netværksinfrastruktur ikke i stand til høj gennemstrømning.

• maxWaitTime . Antal ms en tråd vil vente på, at en forbindelse bliver tilgængelig på forbindelsespuljen, og rejser en undtagelse, hvis dette ikke sker i tide. Behold standard.

• socketTimeout . Standard socket timeout værdi. Indstil til 60 sekunder (60000).

• threadsAllowedToBlockForConnectionMultiplier . Multiplikator for forbindelserPerHost, der angiver antallet af tråde, der må vente på, at forbindelser bliver tilgængelige, hvis puljen i øjeblikket er opbrugt. Dette er den indstilling, der vil forårsage undtagelsen "com.mongodb.DBPortPool$SemaphoresOut:Ud af semaforer for at få db-forbindelse". Det vil kaste denne undtagelse, når denne trådkø overstiger værdien for trådeAllowedToBlockForConnectionMultiplier. Hvis f.eks. forbindelsesPerHost er 10, og denne værdi er 5, kan op til 50 tråde blokere, før den førnævnte undtagelse kastes.

  Hvis du forventer store spidsbelastninger i gennemløbet, der kan forårsage store køer, øges denne værdi midlertidigt. Vi har den på 1500 i øjeblikket af netop den grund. Hvis din forespørgselsbelastning konsekvent overstiger serveren, bør du bare forbedre din hardware/skaleringssituation i overensstemmelse hermed.

• readPreference . (OPDATERET, 2.8+) Bruges til at bestemme standard læsepræference og erstatter "slaveOk". Konfigurer en ReadPreference gennem en af ​​klassens fabriksmetode. En komplet beskrivelse af de mest almindelige indstillinger kan findes i slutningen af ​​dette indlæg

• w . (OPDATERET, 2.6+) Denne værdi bestemmer "sikkerheden" for skrivningen. Når denne værdi er -1, vil skrivningen ikke rapportere nogen fejl uanset netværks- eller databasefejl. WriteConcern.NONE er den passende foruddefinerede WriteConcern til dette. Hvis w er 0, vil netværksfejl få skrivefejlen til at mislykkes, men mongo-fejl vil ikke. Dette omtales typisk som "fire and forget" skriver og bør bruges, når ydeevne er vigtigere end konsistens og holdbarhed. Brug WriteConcern.NORMAL til denne tilstand.

  Hvis du indstiller w til 1 eller højere, betragtes skrivningen som sikker. Sikker skrivning udfører skrivningen og følger den op af en anmodning til serveren for at sikre, at skrivningen lykkedes eller henter en fejlværdi, hvis den ikke gjorde det (med andre ord, den sender en getLastError()-kommando, efter du har skrevet). Bemærk, at indtil denne getLastError()-kommando er fuldført, er forbindelsen reserveret. Som et resultat af det og den ekstra kommando vil gennemløbet være væsentligt lavere end skrivninger med w <=0. Med en w-værdi på præcis 1 garanterer MongoDB, at skrivningen lykkedes (eller verificerbart mislykkedes) på den instans, du sendte skrivningen til.

  I tilfælde af replikasæt kan du bruge højere værdier for w, som beder MongoDB om at sende skrivningen til mindst "w" medlemmer af replikasættet, før du vender tilbage (eller mere præcist, vent på replikeringen af ​​din skrivning til "w" medlemmer ). Du kan også indstille w til strengen "majority", som fortæller MongoDB at udføre skrivningen til flertallet af replikasætmedlemmer (WriteConcern.MAJORITY). Typisk bør du indstille dette til 1, medmindre du har brug for rå ydeevne (-1 eller 0) eller replikerede skrivninger (>1). Værdier højere end 1 har en betydelig indflydelse på skrivegennemstrømningen.

• fsync . Holdbarhedsindstilling, der tvinger mongo til at skylle til disk efter hver skrivning, når den er aktiveret. Jeg har aldrig haft nogen holdbarhedsproblemer relateret til en skriveefterslæb, så vi har denne på false (standard) i produktionen.

• j *(NYT 2.7+) *. Boolean, der, når den er sat til true, tvinger MongoDB til at vente på en vellykket journaliseringsgruppeforpligtelse, før den vender tilbage. Hvis du har journalføring aktiveret, kan du aktivere dette for yderligere holdbarhed. Se http://www.mongodb.org/display/DOCS/Journaling for at se, hvad journalføring giver dig (og dermed hvorfor du måske ønsker at aktivere dette flag).

ReadPreference ReadPreference-klassen giver dig mulighed for at konfigurere til hvilke mongod-instanser forespørgsler dirigeres til, hvis du arbejder med replikasæt. Følgende muligheder er tilgængelige:

• ReadPreference.primary() :Alle læsninger går kun til det gengivne primære medlem. Brug dette, hvis du kræver, at alle forespørgsler returnerer konsistente (de senest skrevne) data. Dette er standarden.

• ReadPreference.primaryPreferred() :Alle læsninger går til det gengivne primære medlem, hvis det er muligt, men kan forespørge på sekundære medlemmer, hvis den primære node ikke er tilgængelig. Som sådan, hvis den primære bliver utilgængelig, bliver læsninger til sidst konsistente, men kun hvis den primære er utilgængelig.

• ReadPreference.secondary() :Alle læsninger går til sekundære gentagelsesmedlemmer, og det primære medlem bruges kun til skrivning. Brug kun dette, hvis du kan leve med ensartede læsninger. Yderligere gentagelsesmedlemmer kan bruges til at skalere læseydelsen op, selvom der er grænser for antallet af (stemmer)medlemmer, en gentagelse kan have.

• ReadPreference.secondaryPreferred() :Alle læsninger går til sekundære gentagelsesmedlemmer, hvis nogen af ​​dem er tilgængelige. Det primære medlem bruges udelukkende til at skrive, medmindre alle sekundære medlemmer bliver utilgængelige. Bortset fra tilbagefaldet til det primære medlem for læsninger er dette det samme som ReadPreference.secondary().

• ReadPreference.nearest() :Aflæsninger går til det nærmeste gentagelsesmedlem, der er tilgængeligt for databaseklienten. Brug kun, hvis ensartede læsninger er acceptable. Det nærmeste medlem er det medlem med den laveste latenstid mellem klienten og de forskellige repet-medlemmer. Da travle medlemmer i sidste ende vil have højere latenser bør dette balancerer også automatisk læsebelastning, selvom efter min erfaring ser det ud til, at sekundær (Foretrukken) gør det bedre, hvis medlemsforsinkelser er relativt konsistente.

Bemærk:Alle ovenstående har tag-aktiverede versioner af den samme metode, som returnerer TaggableReadPreference-forekomster i stedet. En komplet beskrivelse af replika sæt tags kan findes her:Replika sæt tags