Hur konfigurerar man MongoDB Java-drivrutin MongoOptions för produktionsanvändning?

Uppdaterad till 2.9 :

• autoConnectRetry betyder helt enkelt att föraren automatiskt kommer att försöka återansluta till servern/servrarna efter oväntade frånkopplingar. I produktionsmiljöer vill du vanligtvis att denna inställning ska vara sann.

• connectionsPerHost är mängden fysiska anslutningar en enskild Mongo-instans (det är singleton så du brukar ha en per applikation) kan upprätta till en mongod/mongos-process. I skrivande stund kommer java-drivrutinen att upprätta denna mängd anslutningar så småningom även om den faktiska frågegenomströmningen är låg (i ord kommer du att se "conn"-statistiken i mongostat stiga tills den når detta nummer per appserver).

  Det finns inget behov av att ställa in detta högre än 100 i de flesta fall, men den här inställningen är en av de där "testa och se" sakerna. Observera att du måste se till att du ställer in detta tillräckligt lågt så att det totala antalet anslutningar till din server inte överstiger

  db.serverStatus().connections.available

  I produktion har vi för närvarande detta på 40.

• connectTimeout . Som namnet antyder antal millisekunder väntar föraren innan ett anslutningsförsök avbryts. Ställ in timeout på något långt (15-30 sekunder) om det inte finns en realistisk, förväntad chans att detta kommer att vara i vägen för annars framgångsrika anslutningsförsök. Om ett anslutningsförsök tar längre tid än ett par sekunder är din nätverksinfrastruktur normalt sett inte kapabel till hög genomströmning.

• maxWaitTime . Antal ms en tråd väntar på att en anslutning blir tillgänglig på anslutningspoolen och tar upp ett undantag om detta inte händer i tid. Behåll standard.

• socketTimeout . Standard socket timeout värde. Ställ in på 60 sekunder (60 000).

• threadsAllowedToBlockForConnectionMultiplier . Multiplikator för anslutningar per värd som anger antalet trådar som får vänta på att anslutningar blir tillgängliga om poolen för närvarande är slut. Det här är inställningen som kommer att orsaka undantaget "com.mongodb.DBPortPool$SemaphoresOut:Out of semaphores to get db-anslutning". Det kommer att skapa detta undantag när den här trådkön överskrider värdet för trådarAllowedToBlockForConnectionMultiplier. Till exempel, om anslutningarna PerHost är 10 och detta värde är 5 kan upp till 50 trådar blockeras innan det ovannämnda undantaget kastas.

  Om du förväntar dig stora toppar i genomströmning som kan orsaka stora köer ökar detta värde tillfälligt. Vi har den på 1500 just nu av just den anledningen. Om din frågebelastning konsekvent överskrider servern bör du bara förbättra din hårdvara/skalningssituation i enlighet med detta.

• readPreference . (UPPDATERAD, 2.8+) Används för att fastställa standardinställningen för läs och ersätter "slaveOk". Ställ in en ReadPreference genom en av klassens fabriksmetoder. En fullständig beskrivning av de vanligaste inställningarna finns i slutet av det här inlägget

• w . (UPPDATERAD, 2.6+) Detta värde bestämmer "säkerheten" för skrivningen. När detta värde är -1 kommer skrivningen inte att rapportera några fel oavsett nätverks- eller databasfel. WriteConcern.NONE är den lämpliga fördefinierade WriteConcern för detta. Om w är 0 kommer nätverksfel att göra att skrivfelet misslyckas men mongo-fel kommer inte att göra det. Detta kallas vanligtvis "eld och glöm" skriver och bör användas när prestanda är viktigare än konsekvens och hållbarhet. Använd WriteConcern.NORMAL för detta läge.

  Om du ställer in w till 1 eller högre anses skrivningen vara säker. Säkra skrivningar utför skrivningen och följer upp den med en förfrågan till servern för att säkerställa att skrivningen lyckades eller hämtar ett felvärde om det inte gjorde det (med andra ord, det skickar ett getLastError()-kommando efter att du skrivit). Observera att tills detta getLastError()-kommando är klart är anslutningen reserverad. Som ett resultat av det och det extra kommandot kommer genomströmningen att vara betydligt lägre än skrivningar med w <=0. Med ett w-värde på exakt 1 garanterar MongoDB att skrivningen lyckades (eller verifierbart misslyckades) på den instans du skickade skrivningen till.

  När det gäller replikuppsättningar kan du använda högre värden för w som säger till MongoDB att skicka skrivningen till åtminstone "w"-medlemmar i replikuppsättningen innan du returnerar (eller mer exakt, vänta på replikeringen av din skrivning till "w"-medlemmar ). Du kan också ställa in w till strängen "majority" som säger till MongoDB att utföra skrivningen till majoriteten av replikuppsättningens medlemmar (WriteConcern.MAJORITY). Vanligtvis bör du ställa in detta till 1 om du inte behöver rå prestanda (-1 eller 0) eller replikerade skrivningar (>1). Värden högre än 1 har en betydande inverkan på skrivkapaciteten.

• fsync . Hållbarhetsalternativ som tvingar mongo att spola till disken efter varje skrivning när det är aktiverat. Jag har aldrig haft några hållbarhetsproblem relaterade till en skriveftersläpning så vi har detta på false (standard) i produktionen.

• j *(NY 2.7+) *. Boolean som när den är inställd på true tvingar MongoDB att vänta på en framgångsrik journalföringsgrupps commit innan han återvänder. Om du har aktiverat journalföring kan du aktivera detta för ytterligare hållbarhet. Se http://www.mongodb.org/display/DOCS/Journaling för att se vad journalföring ger dig (och därmed varför du kanske vill aktivera denna flagga).

ReadPreference Klassen ReadPreference låter dig konfigurera till vilka mongod-instanser frågor dirigeras om du arbetar med replikuppsättningar. Följande alternativ är tillgängliga:

• ReadPreference.primary() :Alla läsningar går endast till den repet primära medlemmen. Använd detta om du vill att alla frågor ska returnera konsekventa (senast skrivna) data. Detta är standard.

• ReadPreference.primaryPreferred() :Alla läsningar går till den repset primära medlemmen om möjligt men kan fråga sekundära medlemmar om den primära noden inte är tillgänglig. Som sådan om den primära blir otillgänglig blir läsningarna så småningom konsekventa, men bara om den primära är otillgänglig.

• ReadPreference.secondary() :Alla läsningar går till sekundära repet-medlemmar och den primära medlemmen används endast för skrivningar. Använd detta endast om du kan leva med konsekventa läsningar. Ytterligare repset-medlemmar kan användas för att skala upp läsprestanda även om det finns gränser för antalet (röstande) medlemmar en repset kan ha.

• ReadPreference.secondaryPreferred() :Alla läsningar går till sekundära repet-medlemmar om någon av dem är tillgänglig. Den primära medlemmen används uteslutande för att skriva om inte alla sekundära medlemmar blir otillgängliga. Annat än återgången till den primära medlemmen för läsningar är detta samma som ReadPreference.secondary().

• ReadPreference.nearest() :Läsningar går till närmaste repset-medlem som är tillgänglig för databasklienten. Använd endast om konsekventa läsningar är acceptabla. Den närmaste medlemmen är den medlem med lägst latens mellan klienten och de olika repetmedlemmarna. Eftersom upptagna medlemmar så småningom kommer att ha högre latenser bör detta balanserar också läsbelastningen automatiskt, även om sekundär (föredragen) enligt min erfarenhet verkar göra det bättre om medlemmarnas fördröjningar är relativt konsekventa.

Obs:Alla ovanstående har taggaktiverade versioner av samma metod som returnerar TaggableReadPreference-instanser istället. En fullständig beskrivning av replikuppsättningstaggar finns här:Replikuppsättningstaggar