Överväganden för att administrera MongoDB

Nedan finns ett utdrag ur vårt whitepaper "MongoDB Management and Automation with ClusterControl" som kan laddas ner gratis.

Överväganden för att administrera MongoDB

Inbyggd redundans

En nyckelfunktion hos MongoDB är dess inbyggda redundans, i form av replikering. Om du har två eller flera datanoder kan de konfigureras som en replikuppsättning, där all data som skrivs till den primära noden replikeras i nästan realtid till de sekundära noderna,

säkerställer flera kopior av data. I fallet med Primär failover genomför de återstående noderna i replikuppsättningen ett val och befordrar vinnaren till Primär, en process som vanligtvis tar 2-3 sekunder och skriver till replikuppsättningen kan återupptas. MongoDB använder också en journal för snabbare, säkrare skrivningar till servern eller replikuppsättningen, och använder också en "write concern"-metod genom vilken nivån på skrivredundans
konfigureras.

För att manuellt distribuera en replikuppsättning är stegen på hög nivå som följer:

1. Tilldela en enda fysisk eller virtuell värd för varje databasnod och installera MongoDB kommandoradsklient på ditt skrivbord. För en redundant replikuppsättningskonfiguration krävs minst tre noder, varav minst två kommer att vara datanoder. En nod i replikuppsättningen kan konfigureras som en arbiter:detta är en mongod process som bara är konfigurerad för att utgöra ett beslutfört genom att ge en röst i valet av en Primär när så krävs. Data replikeras inte till skiljeprocesser.
2. Installera MongoDB på varje nod. Vissa Linux-distributioner inkluderar MongoDB Community Edition, men tänk på att dessa kanske inte innehåller de senaste versionerna. MongoDB Enterprise är endast tillgängligt genom nedladdning från MongoDB:s webbplats. Liknande funktionalitet som MongoDB Enterprise är också tillgänglig via Percona Server för MongoDB, en drop-in-ersättning för MongoDB Enterprise eller Community Edition.
3. Konfigurera de individuella mongod.conf-konfigurationsfilerna för din replikuppsättning med hjälp av "replikeringsparametern". Om du kommer att använda en nyckelfil för säkerhet, konfigurera denna nu också. Observera att användning av nyckelfilsäkerhet möjliggör också rollbaserad autentisering, så du måste också lägga till användare och roller för att använda servrarna. Starta om mongod-processen på varje server.
4. Säkerställ anslutning mellan noder. Du måste se till att MongoDB replikuppsättningsnoder kan kommunicera med varandra på port 27017, och även att din klient(er) kan ansluta till var och en av replikuppsättningsnoderna på samma port.
5. Använd MongoDB kommandoradsklient, anslut till en av servrarna och kör rs.initiate() för att initiera din replikuppsättning, följt av rs.add() för varje ytterligare nod. rs.conf() kan användas för att visa konfigurationen.

Även om dessa steg inte är lika komplicerade som att distribuera och konfigurera ett MongoDB-delat kluster, eller att dela en relationsdatabas, kan de vara betungande och benägna att göra fel, särskilt i större miljöer.

Skalbarhet

MongoDB kallas ofta för "web scale" databasprogramvara, på grund av dess förmåga att skala horisontellt. Liksom relationsdatabaser är det möjligt att skala MongoDB vertikalt, helt enkelt genom att uppgradera den fysiska värddatorn som den finns på med fler CPU-kärnor, mer RAM, snabbare diskar eller till och med ökad busshastighet. Vertikal skalning har dock sina begränsningar, både vad gäller kostnads-nyttoförhållande och minskande avkastning, och teknisk begränsning. För att ta itu med detta har MongoDB en "auto-sharding"-funktion, som gör att databaser kan delas över många värdar (eller replikuppsättningar, för redundans). Även om sönderdelning också är möjligt på relationsplattformar, såvida det inte är designat för vid start av databasen, kräver detta omfattande omdesign av schema och applikation, såväl som omdesign av klientapplikationer, vilket gör detta till en tråkig, tidskrävande och felbenägen process.

MongoDB-sharding fungerar genom att introducera en routerprocess, genom vilken klienter ansluter till det sönderdelade klustret, och konfigurationsservrar, som lagrar klustrets metadata, platsen i klustret för varje dokument. När en klient skickar en fråga till routerprocessen hänvisar den först till konfigurationsservrarna för att få dokumentens placering, och hämtar sedan frågeresultaten direkt från de individuella servrarna eller
replikuppsättningarna (shards). Klyvning utförs per insamlingsbasis.

En kritiskt viktig parameter här, för prestationsändamål, är "shard key", ett indexerat fält eller sammansatt fält som finns i varje dokument i en samling. Det är detta som definierar skrivfördelningen över skärvor av en samling. Som sådan kan en dåligt vald skärvnyckel ha en mycket skadlig effekt på prestandan. Till exempel kan en rent tidsseriebaserad shard-nyckel resultera i att alla skrivningar går till en enda nod under längre tidsperioder. En hashad shard-nyckel kan emellertid, även om den fördelar skrivningar jämnt över shards, påverka läsprestandan eftersom en resultatuppsättning hämtas från många noder.

Arbiters

En MongoDB-arbiter är en mongod-process som har konfigurerats för att inte fungera som en datanod, utan att endast tillhandahålla funktionen att rösta när en replikuppsättning Primär ska väljas, för att bryta banden och skydda sig mot en delad röst. En skiljedomare får inte bli Primär, eftersom den inte innehar en kopia av data eller accepterar skrivningar. Även om det är möjligt att ha mer än en arbiter i en replikuppsättning, rekommenderas det i allmänhet inte.

Försenade replikuppsättningsmedlemmar

Medlemmar av fördröjda replikuppsättningar lägger till en extra nivå av redundans och upprätthåller ett tillstånd som ligger ett fast antal sekunder efter Primären. Eftersom försenade medlemmar är en "rullande säkerhetskopia" eller en löpande "historisk" ögonblicksbild av datamängden, kan de hjälpa till att återhämta sig från olika typer av mänskliga fel.

Försenade medlemmar är "dolda" replikuppsättningsmedlemmar, osynliga för klientapplikationer och kan därför inte frågas direkt. De kanske inte heller blir primära under normala operationer och måste konfigureras om manuellt om de ska användas för att återställa från fel.

Säkerhetskopiering

Säkerhetskopiering av en replikuppsättning eller ett fragmenterat kluster utförs via kommandoradsverktyget "mongodump". När den används med parametern --oplog skapar detta en dump av databasen som innehåller en oplog, för att skapa en ögonblicksbild av en mongod-instanss tillstånd. Genom att använda mongorestore med parametern --replayOplog kan du sedan helt återställa datatillståndet vid den tidpunkt då säkerhetskopieringen slutfördes, vilket undviker inkonsekvens.

För mer avancerade säkerhetskopieringskrav finns ett tredjepartsverktyg som heter "mongodbconsistent-backup" - även kommandoradsbaserat - tillgängligt som ger helt konsekventa säkerhetskopior av fragmenterade kluster, en komplicerad procedur med tanke på att shardade databaser är fördelade över flera värdar.

Övervakning

Det finns ett antal kommersiella verktyg, både officiella och inofficiella, tillgängliga på marknaden för att övervaka MongoDB. Dessa verktyg är i allmänhet enstaka produkthanteringsverktyg, med fokus uteslutande på MongoDB. Många fokuserar bara på vissa specifika aspekter, såsom samlingshantering i en befintlig MongoDB-arkitektur, eller på säkerhetskopior eller på distribution. Utan ordentlig planering kan detta leda till en situation där en mängd ytterligare verktyg måste distribueras och hanteras i din miljö.

Kommandoradsverktygen som tillhandahålls med MongoDB, "mongotop" och "mongostat" kan ge en detaljerad bild av din miljös prestanda och kan användas för att diagnostisera problem. Dessutom kan MongoDB:s "mongo" kommandoradsklient också köra "rs.status()" - eller i ett delat kluster "sh.status() - för att se status för replikuppsättningar eller kluster och deras medlemsvärdar. Kommandot "db.stats()" returnerar ett dokument som adresserar lagringsanvändning och datavolymer, och deras är ekvivalenter för samlingar, såväl som andra anrop för att komma åt många interna mätvärden.

Sammanfattning

Detta har varit en kort sammanfattning av överväganden för att administrera MongoDB. Även på en så hög nivå bör det omedelbart vara uppenbart att även om det är möjligt att administrera en replikuppsättning eller ett fragmenterat kluster från kommandoraden med hjälp av tillgängliga verktyg, skalas detta inte i en miljö med många replikuppsättningar eller med en stor produktion skuren klunga. I medelstora till stora miljöer som omfattar många värdar
och databaser blir det snabbt omöjligt att hantera allt med kommandoradsverktyg och skript. Även om interna verktyg och skript kan utvecklas för att distribuera och underhålla miljön, ökar detta bördan av att hantera ny utveckling, revisionskontrollsystem och processer. En enkel uppgradering av en databasserver kan bli en komplex process om verktygsändringar krävs för att stödja nya
databasserverversioner.

Men utan interna verktyg och skript, hur automatiserar och hanterar vi MongoDB-kluster? Ladda ner whitepaper för att lära dig hur!