För vilken databas som helst är lastbalanseringen av alla förfrågningar som kommer från klienter en viktig och grundläggande mekanism för att säkerställa skalbarhet. En korrekt lastbalanseringslösning fördelar alla klientförfrågningar jämnt över alla databasresurser. Om databasklustret inte skyddas med en korrekt lastbalanseringslösning, kommer din databas inte att kunna hantera ökad trafikbelastning på den.
Lyckligtvis tillhandahåller MongoDB inbyggt stöd för lastbalansering av hög trafik genom att stödja horisontell skalning genom skärning. Du kan distribuera data från dina samlingar över flera servrar med sharding. Du kan också lägga till nya servrar/maskiner till ditt kluster för att hantera den ökade trafiken på databasen. Du kan följa den här guiden för att konvertera ditt MongoDB-replikkluster till ett fragmenteringskluster.
I den här artikeln kommer vi att lära oss om beteendet hos balanseringsprocessen som körs i MongoDB-delade kluster och hur man ändrar dess beteende. MongoDB-balanseringsprocessen tar hand om att fördela dina samlingar jämnt över skärvorna. Till exempel, om en shard av ditt kluster innehåller för många bitar av din sharded-samling, kan just den shard få mer trafik jämfört med andra shards. Därför balanserar balanseringsprocessen delarna av samlingarna ordentligt över skärvorna. I de flesta av MongoDB-distributionerna är standardkonfigurationerna för balanseringsprocessen tillräckliga för normala operationer. Men i vissa situationer kanske databasadministratörer vill ändra standardbeteendet för denna process. Om du vill ändra standardbeteendet för balanseringsprocessen för behov på applikationsnivå eller driftkrav kan du följa den här guiden.
Låt oss börja med några grundläggande kommandon för att få lite information om balanseringsprocessens status och status.
Balansstatusstatus
Detta kommando kontrollerar om balanseringen är aktiverad eller tillåten att köra eller inte. Om balanseringsprocessen inte körs kommer detta kommando att returnera false. Detta kommer inte att kontrollera om balanseringsprocessen körs eller inte.
sh.getBalancerState()Aktivera balanseringsprocessen
Om balanseringen inte är aktiverad som standard kan du aktivera den genom att köra följande kommando. Det här kommandot startar inte balanseringsprocessen men det aktiverar processen och säkerställer att chunkbalansering inte blockeras när balanseringsprocessen körs nästa gång.
sh.enableBalancing(<collection_name/namespace>)Inaktivera balanseringsprocessen
Balanseringsprocessen körs när som helst som standard. Därför, om du vill inaktivera balanseringsprocessen under en viss tidsperiod kan du använda följande kommando. Ett idealiskt scenario för att använda det här kommandot är när du tar en säkerhetskopia av din databas.
sh.stopBalancer()Se till att balanseringsprocessen är stoppad innan du tar säkerhetskopian. Om processen är aktiverad när du tar säkerhetskopian av databasen, kan du få en inkonsekvent kopia av din databas. Detta kan hända när balanseringsprocessen flyttar några bitar över skärvorna för lastbalansering under säkerhetskopieringsprocessen.
Du kan också inaktivera balanseringen på vissa specifika samlingar genom att tillhandahålla hela namnområdet för en samling som en parameter med följande kommando.
sh.disableBalancing("<db_name>.<collection_name>")Balancer körningsstatus
Detta kommando kontrollerar om balanseringsprocessen körs eller inte. Den kontrollerar också om den aktivt hanterar skärningsbitarna eller inte. Returnerar sant om processen körs annars returnerar falskt.
sh.isBalancerRunning()Standardkonfigurationer för chunkstorlek
Som standard är chunkstorleken i alla MongoDB sharded-kluster 64 MB. För de flesta scenarierna är detta tillräckligt bra för att migrera eller dela de sönderdelade bitarna. Men ibland innebär den normala migreringsprocessen fler I/O-operationer än vad din hårdvara kan bearbeta. I dessa typer av situationer kanske du vill minska storleken på bitar. Du kan göra det genom att köra följande uppsättning kommandon.
use config
db.settings.save( { _id:"chunksize", value: <sizeInMB> } )Om du ändrar standardstorleken för bitstorleken i det sönderdelade klustret, tänk på följande
- Du kan endast ange chunkstorleken mellan 1 och 1024 MB
- Automatisk delning sker endast vid infogning eller uppdatering
- Lägre bitstorlekar kommer att leda till mer tid under delningsprocessen.
Schemalägg balansering för en specifik tid
När din databasstorlek är enorm kan balanserings- eller migreringsprocesser påverka den övergripande prestandan för din databas. Därför är det klokt att schemalägga balanseringsprocessen under ett specifikt tidsfönster när belastningen på databasen är mycket mindre. Du kan använda följande kommandon för att ställa in tidsfönstret för balanseringsprocessen.
use config
db.settings.update({ _id : "balancer" }, { $set : { activeWindow : { start : "<start-time>", stop : "<stop-time>" } } }, true )Exempel
Följande kommando kommer att ställa in tidsfönstret från 1:00 till 5:00 för att balanseringsprocessen ska köras.
db.settings.update({ _id : "balancer" }, { $set : { activeWindow : { start : "01:00", stop : "05:00" } } }, true )Se till att den givna tidsramen är tillräcklig för en fullständig balanseringsprocess.
Du kan också ta bort alla befintliga tidsfönster för balanseringsprocessen genom att köra följande kommando.
db.settings.update({ _id : "balancer" }, { $unset : { activeWindow : true } })Förutom ovanstående kommandon kan du också ändra replikeringsbeteendet medan du utför chunk-migreringsprocessen genom att använda parametern _secondaryThrottle. Du kan också använda egenskapen _waitForDelete med moveChunk-kommandot för att tala om för balanseringsprocessen att vänta på den aktuella migreringens raderingsfas innan du börjar med den nya chunk-migreringsfasen.
Slutsats
Förhoppningsvis kommer detta att vara allt du behöver medan du ändrar standardbeteendet för MongoDB-balanseringsprocessen. Balansering är en mycket viktig aspekt av alla MongoDB sharded kluster. Så om du känner till balanseringsprocessen i detalj, blir det mycket enkelt att ändra standardbeteendet för balanseringsprocessen enligt dina behov och användningsfall.