MongoDB-distribution i produktion kan bara fungera om rätt distributionsmönster följs. Att distribuera en replikuppsättning i en enda värd garanterar inte den höga tillgängligheten för data. Att hantera big data kräver omfattande forskning och optimala implementeringar, antingen genom att kombinera de tillgängliga alternativen eller välja den med högst lovande fördelar.
Isättningsmönster för MongoDB inkluderar:
- Replikuppsättningar för tre medlemmar
- Replika uppsättningar fördelade över två eller flera datacenter.
Replikuppsättningar med tre medlemmar
replikering är en skalningsstrategi för MongoDB som förbättrar datatillgängligheten. En replikuppsättning innefattar:
- En primär nod:ansvarig för alla skrivgenomströmningsoperationer och kan även läsas från.
- Sekundära noder:Kan endast användas för läsoperationer men kan väljas till primär om den befintliga misslyckas. De hämtar sina datauppdateringar från en oplogg som genereras av den primära medlemmen i uppsättningen.
- Arbiter. Används för att underlätta valet av ett primärval om det finns ett jämnt antal replikuppsättningsmedlemmar. Den innehåller ingen kopia av data.
Fördelar med en replikuppsättning kan endast uppnås med ett minsta antal av tre medlemmar med följande arkitektur:
Primär-sekundär-sekundär
Detta är det mest rekommenderade eftersom det har en större feltolerans och tar itu med begränsningarna med att lägga till en tredje databärande medlem, såsom kostnad.
Denna distribution kommer alltid att tillhandahålla två fullständiga kopior förutom den primära informationen, vilket säkerställer hög tillgänglighet. Ett misslyckande med den primära kommer att utlösa replikuppsättningen för att välja en ny primär och visningsoperationen kommer att återupptas som vanligt. Om den gamla primära blir levande kommer den att kategoriseras som en sekundär medlem.
Under valprocessen signalerar medlemmarna till varandra genom ett hjärtslag och det pågår inga skrivoperationer under denna tid
Efter valprocessen antar vi att arkitekturen ska reformeras som:
Primär-sekundär-Arbiter
Detta säkerställer att replikuppsättningen förblir tillgänglig även om den primära eller sekundära är otillgänglig genom att underlätta valprocessen för en sekundär till en primär. Skiljemän har ingen kopia av data och kräver därför färre resurser för att hantera.
En begränsning med denna distribution är; ingen redundans eftersom det bara finns två databärande medlemmar:primära och sekundära. Detta resulterar i en lägre feltolerans.
Feltolerans bör kunna säkerställa:
- Skrivtillgänglighet: majoriteten av röstande replikuppsättningsmedlemmar behövs för att behålla eller välja den primära som är ansvarig för skrivoperationerna.
- Dataredundans:skrivning kan bekräftas av flera medlemmar för att undvika återställning
Primär-sekundär-Arbiter-konfigurationen stöder endast skrivtillgänglighetsaspekten så att om en enskild medlem av uppsättningen inte är tillgänglig, kan en primär fortfarande bibehållas.
Men underlåtenhet att stödja den andra aspekten resulterar i vissa operativa konsekvenser om den sekundära medlemmen blir otillgänglig:
- Det kommer inte att finnas någon aktiv replikering, särskilt om sekundären är offline länge. När sekundären är offline för länge kan den falla av oploggen och tvinga en att synkronisera om den under omstart.
- Dataredundans kommer att saboteras och tvingar endast den nuvarande primära skrivoperationen att erkännas.
- Alternativ för majoritet med oro kommer inte att tillhandahålla de senaste uppgifterna till de anslutna applikationerna och interna processer. Detta är fallet när din konfiguration förväntar sig att skrivningar för att begära majoritetsbekräftelse och därför blockeras tills majoriteten av databärande medlemmar är tillgängliga.
- Chunkmigrering mellan shards kommer också att äventyras om replikuppsättningen är en del av ett sharded kluster.
- Tryck på WiredTiger-lagringsmotorns cache om återställningar inträffar och majoriteten av commit-punkten inte kan flyttas fram.
För att undvika dessa konsekvenser kan man välja en primär-sekundär-sekundär konfiguration eftersom den ökar feltoleransen.
Obs:Feltolerans uppstår inte bara vid fel, utan även vissa systemoperationer såsom mjukvaruuppgradering och normalt underhåll kan tvinga en medlem att vara otillgänglig en kort stund.
Replika uppsättningar fördelade över två eller flera datacenter
Hög tillgänglighet kan höjas till en annan nivå genom att distribuera replikuppsättningsmedlemmar över geografiskt distinkta datacenter. Detta tillvägagångssätt kommer att öka redundansen förutom att säkerställa hög feltolerans om något datacenter skulle bli otillgängligt.
Om alla medlemmar finns i ett enda datacenter är replikuppsättningen känslig för datacenterfel som nätverkstransienter och strömavbrott.
Det är tillrådligt att ha minst en medlem i ett alternativt datacenter, använd ett udda antal datacenter och välj en fördelning av medlemmar som kommer att erbjuda majoritet för val eller åtminstone tillhandahålla en kopia av uppgifterna i händelse av misslyckande.
Konfigurationen bör säkerställa att om något datacenter går ner, förblir replikuppsättningen skrivbar eftersom de återstående medlemmarna kan hålla ett val.
Distribuera din data över åtminstone tre datacenter.
Medlemmar kan vara begränsade till resurser eller ha nätverksbegränsningar vilket gör dem olämpliga att bli primära i händelse av failover. Du kan konfigurera dessa medlemmar att inte bli primära genom att ge dem prioritet 0.
Medlemmar i ett datacenter kan ha högre prioritet än andra datacenter för att ge dem röstprioritet så att de kan välja primära före medlemmar i andra datacenter.
Alla medlemmar i replikuppsättningen bör kunna kommunicera med varandra.
Slutsats
replikeringsfördelar kan höjas till en mer lovande status genom att fördela medlemmarna över ett antal datacenter. Detta ökar i huvudsak feltoleransen förutom att säkerställa dataredundans. Replica Set-medlemmar när de är fördelade över två eller flera datacenter ger fördelar jämfört med ett enda datacenter, till exempel:
Om ett av datacentren går ner är data fortfarande tillgänglig för läsning till skillnad från för en enskild datacenterdistribution.
Skrivåtgärder kan fortfarande bekräftas när ett datacenter med minoritetsmedlemmar går ner.
Läsfunktioner kan fortfarande vara möjliga om datacentret med majoritetsberättigade medlemmar går ner till skillnad från fallet med ett enda datacenter.