Hvad er kædereplikering?
Når vi taler om replikering, refererer vi til processen med at lave overflødige kopier af data for at opfylde designkriterier for datatilgængelighed. Kædereplikering refererer derfor til den lineære rækkefølge af MongoDB-servere for at danne en synkroniseret kæde. Kæden indeholder en primær node, efterfulgt af sekundære servere arrangeret lineært. Som ordkæden antyder, replikerer serveren tættest på den primære server fra den, mens hver anden efterfølgende sekundær server replikerer fra den foregående sekundære MongoDB-server. Dette er hovedforskellen mellem kædet replikation og normal replikation. Kædet replikering opstår, når en sekundær node vælger sit mål ved hjælp af ping-tid, eller når den nærmeste node er en sekundær. Selvom kædereplikering, som den ser ud, reducerer belastningen på den primære node, kan det forårsage replikationsforsinkelse.
Hvorfor bruge kædereplikering?
Systeminfrastrukturer lider nogle gange af uforudsigelige fejl, der fører til tab af en server og derfor påvirker tilgængeligheden. Replikering sikrer, at uforudsigelige fejl ikke påvirker tilgængeligheden. Replikering tillader yderligere genopretning fra hardwarefejl og serviceafbrydelse. Både kædet og ikke-kædet replikering tjener dette formål med at sikre tilgængelighed på trods af systemfejl. Efter at have fastslået, at replikation er vigtig, kan du spørge, hvorfor du især bruger kædereplikation. Der er ingen præstationsforskel mellem kædet og ikke-kædet replikering i MongoDb. I begge tilfælde, når den primære node svigter, stemmer de sekundære servere for en ny fungerende primær, og derfor påvirkes skrivning og læsning af data ikke i begge tilfælde. Kædet replikering er imidlertid standardreplikeringstypen i MongoDb.
Sådan konfigurerer du en kædereplika
Som standard er kædet replikering aktiveret i MongoDB. Vi vil derfor uddybe processen med at deaktivere kædereplikation. Hovedårsagen til, at kædereplikering kan deaktiveres, er, hvis det forårsager forsinkelse. Fordelen ved kædereplikation er imidlertid overlegen i forhold til efterslæbet, og derfor er det i de fleste tilfælde unødvendigt at deaktivere det. Bare hvis kædereplikering ikke er aktiv som standard, vil følgende kommandoer hjælpe dig med at aktivere.
cfg = rs.config()
cfg.settings.chainingAllowed = true
rs.reconfig(cfg)Denne proces er reversibel. Når tvunget til at deaktivere kædereplikation, følges følgende proces religiøst.
cfg = rs.config()
cfg.settings.chainingAllowed = false
rs.reconfig(cfg)Tips og tricks til kædereplikering
De mest forfærdelige begrænsninger af kædereplikation er replikationsforsinkelse. Replikationsforsinkelse refererer til den forsinkelse, der opstår mellem det tidspunkt, hvor en operation udføres på den primære, og når den samme operation replikeres på den sekundære. Selvom det naturligvis er umuligt, ønskes det altid, at replikationshastigheden er meget høj, da replikationsforsinkelsen er nul. For at undgå eller minimere replikeringsforsinkelse til at være tæt på nul, er det et fornuftigt designkriterie at bruge primære og sekundære værter med de samme specifikationer med hensyn til CPU, RAM, IO og netværksrelaterede specifikationer.
Selvom kædereplikering sikrer datatilgængelighed, kan kædereplikering bruges sammen med journalføring. Journalføring giver datasikkerhed ved at skrive til en log, der jævnligt skylles til disken. Når de to kombineres, skrives tre servere pr. skriveanmodning i modsætning til i kædereplikering alene, hvor kun to servere skrives pr. skriveanmodning.
Et andet vigtigt tip er at bruge w med replikering. Parameteren w styrer antallet af servere, som et svar skal skrives til, før det returnerer succes. Når w-parameteren er indstillet, tjekker getlasterror serverens oplog og venter, indtil det givne antal 'w'-servere har udført handlingen.
Ved at bruge et overvågningsværktøj som MongoDB Monitoring Service (MMS) eller ClusterControl kan du få status for dine replika-knuder og visualisere ændringer over tid. I MMS kan du f.eks. finde replika-forsinkelsesgrafer for de sekundære noder, der viser variationen i replikeringsforsinkelsestid.
Måling af kædereplikeringsydelse
Nu er du klar over, at den vigtigste præstationsparameter for kædereplikering er replikationsforsinkelsestiden. Vi vil derfor diskutere, hvordan man tester for replikationsforsinkelsesperiode. Denne test kan udføres gennem MongoDb shell-scriptet. For at lave en replikationsforsinkelsestest sammenligner vi oploggen for den sidste hændelse på den primære node og oploggen for den sidste hændelse på den sekundære node.
For at kontrollere oplysningerne for den primære node kører vi følgende kode.
db.printSlaveReplicationInfo()Ovenstående kommando vil give information om alle de seneste operationer på den primære knude. Resultaterne skulle fremstå som nedenfor.
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 at have opnået oploggen for den primære, er vi nu interesseret i oploggen for den sekundære node. Følgende kommando vil hjælpe os med at få oploggen.
db.printReplicationInfo()Denne kommando vil give et output med detaljer om oplog størrelse, log længde, tid for oplog første hændelse, tid for oplog sidste hændelse og det aktuelle tidspunkt. Resultaterne vises som nedenfor.
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)Fra oploggen for den primære server fandt den sidste synkronisering sted på Tue Mar 05 2013 07:48:19 GMT-0800 (PST). Fra oploggen for den sekundære server fandt den sidste operation sted på Tue Mar 05 2013 07:48:19 GMT-0800 (PST). Replikationsforsinkelsen var nul, og derfor fungerer vores kædereplikerede system korrekt. Replikeringstidsforsinkelse kan dog variere afhængigt af mængden af ændringer, der skal replikeres.