Vår senaste version av ClusterControl förvandlar några av de mest besvärliga MongoDB-uppgifterna till ett jobb på bara 15 sekunder. Nya funktioner har lagts till för att ge dig mer kontroll över ditt kluster och utföra topologiändringar:
- Konvertera en MongoDB-replikuppsättning till ett delat MongoDB-kluster
- Lägg till och ta bort skärvor
- Lägg till shard-routrar i ett shardt MongoDB-kluster
- Stäng ner eller frys en nod
- Nya MongoDB-rådgivare
Vi kommer att beskriva dessa tillagda funktioner på djupet nedan.
Konvertera en MongoDB ReplicaSet till en Sharded MongoDB-kluster
Eftersom de flesta MongoDB-användare börjar med en replicaSet för att lagra sin databas, är detta den mest använda typen av kluster. Om du råkar stöta på skalningsproblem kan du skala denna replikuppsättning genom att antingen lägga till fler sekundärer eller skala ut genom att skära. Du kan konvertera ett befintligt replicaSet till ett fragmenterat kluster, men detta är en lång process där du lätt kan göra fel. I ClusterControl har vi automatiserat den här processen, där vi automatiskt lägger till Configservers, shard-routrar och aktiverar sharding.
För att konvertera en replicaSet till ett fragmenterat kluster kan du helt enkelt trigga det via rullgardinsmenyn för åtgärder:
Detta öppnar en dialog i två steg om hur man konverterar detta till en skärva. Det första steget är att definiera var Configserver och shard-routrar ska distribueras till:
Det andra steget är var data ska lagras och vilka konfigurationsfiler som ska användas för Configserver och shard-router.
Efter att fragmentmigreringsjobbet har avslutats visar klusteröversikten nu shards istället för replicaSet-instanser:
Efter konvertering till ett fragmenterat kluster kan nya shards läggas till.
Lägg till eller ta bort delar från ett delat MongoDB-kluster
Lägga till skärvor
Eftersom en MongoDB-shard tekniskt sett är en replicaSet, innebär att lägga till en ny shard även utplaceringen av en ny replicaSet. Inom ClusterControl distribuerar vi först en ny replicaSet och lägger sedan till den i det sönderdelade klustret.
Från ClusterControl-gränssnittet kan du enkelt lägga till nya skärvor med en tvåstegsguide, som öppnas från rullgardinsmenyn för åtgärder:
Här kan du definiera topologin för den nya skärvan.
När den nya skärpan har lagts till i klustret kommer MongoDB-shardroutern att börja tilldela nya bitar till den, och balanseraren kommer automatiskt att balansera alla bitar över alla skärvor.
Ta bort skärvor
Att ta bort shards är lite svårare än att lägga till shard, eftersom detta innebär att data flyttas till de andra shards innan du tar bort själva shard. För all data som har delas över alla skärvor kommer detta att vara ett jobb som utförs av MongoDB-balanseraren.
Men alla icke-skärvade databaser/samlingar, som tilldelats denna shard som sin primära shard, måste flyttas till en annan shard och göra sin nya primära shard. För den här processen måste MongoDB veta vart dessa icke-delade databaser/samlingar ska flyttas.
I ClusterControl kan du helt enkelt ta bort dem via rullgardinsmenyn för åtgärder:
Detta gör att du kan välja fragmentet som du vill ta bort och fragmentet du vill migrera eventuella primära databaser till:
Jobbet som tar bort fragmentet kommer sedan att utföra liknande åtgärder som beskrivits tidigare:det kommer att flytta alla primära databaser till den angivna sharden, aktivera balanseringen och sedan vänta på att den ska flytta all data från sharden.
När all data har tagits bort kommer den att ta bort fragmentet från användargränssnittet.
Lägga till ytterligare MongoDB Shard-routrar
När du börjar skala ut din applikation med ett MongoDB sharded kluster kan du upptäcka att du är i behov av ytterligare shard-routrar.
Att lägga till ytterligare MongoDB shard-routrar är en mycket enkel process med ClusterControl, öppna bara dialogrutan Lägg till nod från rullgardinsmenyn för åtgärder:
Detta kommer att lägga till en ny shard-router till klustret. Glöm inte att ställa in rätt standardport (27017) på routern.
Stopp ner server
Om du vill utföra underhåll på den primära noden i en replicaSet är det bättre att först "trappa ner" den på ett graciöst sätt innan du tar den offline. Att kliva ner en primär betyder i princip att värden slutar vara primär och blir sekundär och inte är berättigad att bli primär för ett visst antal sekunder. Noderna i MongoDB replicaSet med rösträtt kommer att välja en ny primär med den nedtrappade primära exkluderad under det angivna antalet sekunder.
I ClusterControl har vi lagt till nedtrappningsfunktionen som en åtgärd på nodersidan. För att gå ner, välj helt enkelt detta som en åtgärd från rullgardinsmenyn:
Efter att ha ställt in antalet sekunder för avgång och bekräftelse, kommer primärvalet att avgå och en ny primärval väljs.
Frys en nod
Denna funktion liknar steg ned-kommandot:detta gör att en viss nod inte är berättigad att bli primär under ett visst antal sekunder. Det betyder att du kan förhindra att en eller flera sekundära noder blir primära när du kliver ner den primära, och tvinga en viss nod att bli den nya primära på detta sätt.
I ClusterControl har vi lagt till frysnodsfunktionaliteten som en åtgärd på nodersidan. För att frysa en nod, välj helt enkelt detta som en åtgärd från rullgardinsmenyn:
Efter att ha ställt in antalet sekunder och bekräftat kommer noden inte att vara kvalificerad som primär under det angivna antalet sekunder.
Nya MongoDB-rådgivare
Rådgivare är miniprogram som ger råd om specifika databasfrågor. Vi har lagt till tre nya rådgivare för MongoDB. Den första beräknar replikeringsfönstret, den andra övervakar replikeringsfönstret och den tredje kontrollerar om det finns databaser/samlingar som inte är delade.
MongoDB Replication Lag Advisor
Replikeringsfördröjning är mycket viktigt att hålla ett öga på, om du skalar ut läsningar genom att lägga till fler sekundärer. MongoDB kommer bara att använda dessa sekundärer om de inte ligger för långt efter. Om sekundären har replikeringsfördröjning riskerar du att leverera inaktuella data som redan har skrivits över på den primära.
För att kontrollera replikeringsfördröjningen räcker det att ansluta till den primära och hämta dessa data med kommandot replSetGetStatus. I motsats till MySQL håller den primära reda på replikeringsstatusen för sina sekundärer.
Vi har implementerat den här kontrollen i en rådgivare i ClusterControl, för att säkerställa att din replikeringsfördröjning alltid kommer att övervakas.
MongoDB Replication Window Advisor
Precis som replikeringsfördröjningen är replikeringsfönstret ett lika viktigt mått att titta på. Fördröjningsrådgivaren informerar oss redan om antalet sekunder en sekundär nod är bakom primär/master. Eftersom oploggen är begränsad i storlek medför följande risker att ha slavfördröjning:
- Om en nod släpar för långt efter kanske den inte kan komma ikapp längre eftersom de transaktioner som krävs för att komma ikapp inte längre finns i den primära oploggen.
- En eftersläpande sekundär nod är mindre gynnad i ett MongoDB-val för en ny primär. Om alla sekundärer släpar efter i replikeringen kommer du att ha ett problem och en med minst fördröjning kommer att göras till primär.
- Sekundärer som ligger efter är mindre gynnade av MongoDB-drivrutinen när man skalar ut läsningar med MongoDB, det lägger också till en högre arbetsbelastning på de återstående sekundärerna.
Om vi skulle ha en sekundär nod som släpar efter med några minuter (eller timmar), skulle det vara användbart att ha en rådgivare som informerar oss om hur mycket tid vi har kvar innan vår nästa transaktion kommer att tas bort från oploggen. Tidsskillnaden mellan den första och sista posten i oploggen kallas replikeringsfönstret. Detta mått kan skapas genom att hämta de första och sista objekten från oploggen och beräkna skillnaden mellan deras tidsstämplar.
I MongoDB-skalet finns det redan en funktion tillgänglig som beräknar replikeringsfönstret åt dig. Men den här funktionen är inbyggd i kommandoradsskalet, så alla externa anslutningar som inte använder kommandoradsskalet kommer inte att ha denna inbyggda funktion. Därför har vi skapat en rådgivare som vakar över replikeringsfönstret och varnar dig om du överskrider en förinställd tröskel.
MongoDB un-sharded Databases and Collections Advisor
Icke-delade databaser och samlingar kommer att tilldelas en standard primär shard av MongoDB shard-routern. Detta innebär att databasen eller samlingen är begränsad till storleken på denna primära shard, och om den skrivs till i stora volymer, kan den använda allt återstående diskutrymme på en shard. När detta händer kommer skärpan uppenbarligen inte längre att fungera. Därför är det viktigt att övervaka alla befintliga databaser och samlingar, och skanna konfigurationsdatabasen för att verifiera att de har aktiverats för delning.
För att förhindra att detta händer har vi skapat en odelad databas och insamlingsrådgivare. Den här rådgivaren skannar varje databas och samling och varnar dig om den inte har klippts.
ClusterControl förbättrade MongoDB-underhållbarheten
Vi har tagit ett stort steg genom att lägga till alla förbättringar av ClusterControl för MongoDB replicaSets och sharded kluster. Detta förbättrar användbarheten för MongoDB avsevärt och gör att DBA, sysops och devops kan underhålla sina kluster ännu bättre!