Vad är kedjereplikering?
När vi talar om replikering syftar vi på processen att göra redundanta kopior av data för att uppfylla designkriterier för datatillgänglighet. Kedjereplikering hänvisar därför till den linjära ordningen av MongoDB-servrar för att bilda en synkroniserad kedja. Kedjan innehåller en primär nod, efterföljd av sekundära servrar ordnade linjärt. Som ordkedjan antyder replikerar servern närmast den primära servern från den medan varannan efterföljande sekundär server replikerar från den föregående sekundära MongoDB-servern. Detta är huvudskillnaden mellan kedjad replikering och normal replikering. Kedjereplikering uppstår när en sekundär nod väljer sitt mål med hjälp av pingtid eller när den närmaste noden är en sekundär. Även om kedjereplikering som den ser ut minskar belastningen på den primära noden, kan det orsaka replikeringsfördröjning.
Varför använda kedjereplikering?
Systeminfrastrukturer drabbas ibland av oförutsägbara fel som leder till förlust av en server och därför påverkar tillgängligheten. Replikering säkerställer att oförutsägbara fel inte påverkar tillgängligheten. Replikering tillåter vidare återställning från maskinvarufel och tjänstavbrott. Både kedjad och okedjad replikering tjänar detta syfte att säkerställa tillgänglighet trots systemfel. Efter att ha fastställt att replikering är viktigt, kan du fråga dig varför du använder kedjereplikering i synnerhet. Det finns ingen prestandaskillnad mellan kedjad och okedjad replikering i MongoDb. I båda fallen, när den primära noden misslyckas, röstar de sekundära servrarna för en ny fungerande primär och därför påverkas inte skrivning och läsning av data i båda fallen. Kedjed replikering är dock standardreplikeringstypen i MongoDb.
Hur man ställer in en kedjereplik
Som standard är kedjad replikering aktiverad i MongoDB. Vi kommer därför att utveckla processen för att avaktivera kedjereplikering. Den främsta anledningen till att kedjereplikering kan inaktiveras är om det orsakar fördröjning. Förtjänsten med kedjereplikering är dock överlägsen eftersläpningen och därför är det i de flesta fall onödigt att avaktivera den. Om kedjereplikeringen inte är aktiv som standard, kommer följande kommandon att hjälpa dig att aktivera.
cfg = rs.config()
cfg.settings.chainingAllowed = true
rs.reconfig(cfg)Denna process är reversibel. När man tvingas inaktivera kedjereplikering, följs följande process religiöst.
cfg = rs.config()
cfg.settings.chainingAllowed = false
rs.reconfig(cfg)Tips och knep för kedjareplikering
De mest fruktansvärda begränsningarna av kedjereplikation är replikationsfördröjning. Replikeringsfördröjning hänvisar till fördröjningen som inträffar mellan det att en operation görs på den primära och när samma operation replikeras på den sekundära. Även om det naturligtvis är omöjligt, är det alltid önskvärt att replikationshastigheten ska vara mycket hög i den replikeringsfördröjningen är noll. För att undvika eller minimera replikeringsfördröjningen till nära noll är det ett klokt designkriterium att använda primära och sekundära värdar med samma specifikationer när det gäller CPU, RAM, IO och nätverksrelaterade specifikationer.
Även om kedjereplikering säkerställer datatillgänglighet, kan kedjereplikering användas tillsammans med journalföring. Journalföring ger datasäkerhet genom att skriva till en logg som regelbundet spolas till disken. När de två kombineras skrivs tre servrar per skrivbegäran till skillnad från enbart kedjereplikering där endast två servrar skrivs per skrivbegäran.
Ett annat viktigt tips är att använda w med replikering. Parametern w styr antalet servrar som ett svar ska skrivas till innan det ger resultat. När w-parametern är inställd kontrollerar getlasterror servrarnas oplogg och väntar tills det givna antalet 'w'-servrar har tillämpat operationen.
Genom att använda ett övervakningsverktyg som MongoDB Monitoring Service (MMS) eller ClusterControl kan du få status för dina replikanoder och visualisera förändringar över tid. Till exempel, i MMS, kan du hitta replika fördröjningsgrafer för de sekundära noderna som visar variationen i replikeringsfördröjningstid.
Mäta kedjereplikeringsprestanda
Vid det här laget är du medveten om att den viktigaste prestandaparametern för kedjereplikering är replikeringsfördröjningen. Vi kommer därför att diskutera hur man testar för replikationsfördröjningsperiod. Detta test kan göras genom MongoDb-skalskriptet. För att göra ett replikeringsfördröjningstest jämför vi oploggen för den sista händelsen på den primära noden och oploggen för den senaste händelsen på den sekundära noden.
För att kontrollera informationen för den primära noden kör vi följande kod.
db.printSlaveReplicationInfo()Ovanstående kommando kommer att ge information om alla de senaste operationerna på den primära noden. Resultaten bör visas som nedan.
rs-ds046297:PRIMARY db.printSlaveReplicationInfo()
source: ds046297-a1.mongolab.com:46297
synced To: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
= 7475 secs ago (2.08hrs)
source: ds046297-a2.mongolab.com:46297
synced To: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
= 7475 secs ago (2.08hrs)Efter att ha erhållit oploggen för den primära, är vi nu intresserade av oploggen för den sekundära noden. Följande kommando hjälper oss att skaffa oploggen.
db.printReplicationInfo()Detta kommando ger en utdata med detaljer om oplogstorlek, logglängd, tid för oplogs första händelse, tid för oplogs senaste händelse och aktuell tid. Resultaten visas som nedan.
rs-ds046297:PRIMARY db.printReplicationInfo()
configured oplog size: 1024MB
log length start to end: 5589 secs (1.55hrs)
oplog first event time: Tue Mar 05 2013 06:15:19 GMT-0800 (PST)
oplog last event time: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
now: Tue Mar 05 2013 09:53:07 GMT-0800 (PST)Från oploggen för den primära servern skedde den senaste synkroniseringen på Tis Mar 05 2013 07:48:19 GMT-0800 (PST). Från oploggen för den sekundära servern inträffade den senaste operationen tis 5 mars 2013 07:48:19 GMT-0800 (PST). Replikeringsfördröjningen var noll och därför fungerar vårt kedjereplikerade system korrekt. Replikeringsfördröjningen kan dock variera beroende på mängden ändringar som behöver replikeras.