Wat is kettingreplicatie?
Als we het hebben over replicatie, verwijzen we naar het proces van het maken van redundante kopieën van gegevens om te voldoen aan ontwerpcriteria voor de beschikbaarheid van gegevens. Ketenreplicatie verwijst daarom naar de lineaire volgorde van MongoDB-servers om een gesynchroniseerde keten te vormen. De keten bevat een primaire node, gevolgd door lineair gerangschikte secundaire servers. Zoals de woordketen suggereert, repliceert de server die zich het dichtst bij de primaire server bevindt, ervan, terwijl elke andere volgende secundaire server repliceert van de voorgaande secundaire MongoDB-server. Dit is het belangrijkste verschil tussen geketende replicatie en normale replicatie. Geketende replicatie vindt plaats wanneer een secundair knooppunt zijn doel selecteert met behulp van ping-tijd of wanneer het dichtstbijzijnde knooppunt een secundair is. Hoewel kettingreplicatie, zoals het lijkt, de belasting op het primaire knooppunt vermindert, kan het replicatievertraging veroorzaken.
Waarom kettingreplicatie gebruiken?
Systeeminfrastructuren hebben soms te maken met onvoorspelbare storingen die leiden tot het verlies van een server en daardoor van invloed op de beschikbaarheid. Replicatie zorgt ervoor dat onvoorspelbare storingen de beschikbaarheid niet beïnvloeden. Replicatie maakt verder herstel van hardwarestoringen en serviceonderbrekingen mogelijk. Zowel geketende als ontketende replicatie dienen om de beschikbaarheid te garanderen ondanks systeemstoringen. Als je hebt vastgesteld dat replicatie belangrijk is, kun je je afvragen waarom ketenreplicatie in het bijzonder wordt gebruikt. Er is geen prestatieverschil tussen geketende en ontketende replicatie in MongoDb. In beide gevallen, wanneer het primaire knooppunt faalt, stemmen de secundaire servers voor een nieuwe werkende primaire en daarom wordt het schrijven en lezen van gegevens in beide gevallen niet beïnvloed. Geketende replicatie is echter het standaard replicatietype in MongoDb.
Een kettingreplica instellen
Geketende replicatie is standaard ingeschakeld in MongoDB. We gaan daarom dieper in op het proces van het deactiveren van kettingreplicatie. De belangrijkste reden waarom kettingreplicatie kan worden uitgeschakeld, is als het vertraging veroorzaakt. De verdienste van kettingreplicatie is echter superieur aan de vertragingsfout en daarom is het in de meeste gevallen deactiveren niet nodig. Voor het geval kettingreplicatie niet standaard actief is, zullen de volgende commando's u helpen bij het activeren.
cfg = rs.config()
cfg.settings.chainingAllowed = true
rs.reconfig(cfg)Dit proces is omkeerbaar. Wanneer gedwongen om kettingreplicatie te deactiveren, wordt het volgende proces religieus gevolgd.
cfg = rs.config()
cfg.settings.chainingAllowed = false
rs.reconfig(cfg)Tips en trucs voor kettingreplicatie
De meest vreselijke beperking van kettingreplicatie is replicatievertraging. Replicatievertraging verwijst naar de vertraging die optreedt tussen het moment waarop een bewerking wordt uitgevoerd op de primaire en wanneer dezelfde bewerking wordt gerepliceerd op de secundaire. Hoewel het natuurlijk onmogelijk is, is het altijd gewenst dat de replicatiesnelheid zeer hoog is in die replicatievertraging nul is. Om replicatievertraging te voorkomen of te minimaliseren tot bijna nul, is het een verstandig ontwerpcriterium om primaire en secundaire hosts te gebruiken met dezelfde specificaties wat betreft CPU, RAM, IO en netwerkgerelateerde specificaties.
Hoewel ketenreplicatie de beschikbaarheid van gegevens garandeert, kan ketenreplicatie samen met journaal worden gebruikt. Journaling biedt gegevensbeveiliging door te schrijven naar een logboek dat regelmatig naar de schijf wordt gewist. Wanneer de twee worden gecombineerd, worden er drie servers geschreven per schrijfverzoek, in tegenstelling tot alleen ketenreplicatie, waarbij slechts twee servers per schrijfverzoek worden geschreven.
Een andere belangrijke tip is het gebruik van w met replicatie. De parameter w bepaalt het aantal servers waarnaar een antwoord moet worden geschreven voordat het succes wordt geretourneerd. Wanneer de w-parameter is ingesteld, controleert de getlasterror de oplog van de servers en wacht totdat het opgegeven aantal 'w'-servers de bewerking heeft toegepast.
Met behulp van een monitoringtool zoals MongoDB Monitoring Service (MMS) of ClusterControl kunt u de status van uw replicaknooppunten verkrijgen en wijzigingen in de loop van de tijd visualiseren. In MMS kunt u bijvoorbeeld replica-vertragingsgrafieken van de secundaire knooppunten vinden die de variatie in replicatievertragingstijd laten zien.
De prestaties van ketenreplicatie meten
U weet inmiddels dat de belangrijkste prestatieparameter van kettingreplicatie de vertragingstijd van de replicatie is. We zullen daarom bespreken hoe we de replicatievertragingsperiode kunnen testen. Deze test kan worden gedaan via het MongoDb-shellscript. Om een replicatievertragingstest uit te voeren, vergelijken we de oplog van de laatste gebeurtenis op het primaire knooppunt en de oplog van de laatste gebeurtenis op het secundaire knooppunt.
Om de informatie voor het primaire knooppunt te controleren, voeren we de volgende code uit.
db.printSlaveReplicationInfo()De bovenstaande opdracht geeft informatie over alle recente bewerkingen op het primaire knooppunt. De resultaten zouden er als volgt uit moeten zien.
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)Nadat we de oplog voor het primaire knooppunt hebben verkregen, zijn we nu geïnteresseerd in de oplog voor het secundaire knooppunt. Het volgende commando zal ons helpen de oplog te verkrijgen.
db.printReplicationInfo()Deze opdracht levert een uitvoer met details over de oplog-grootte, de loglengte, de tijd voor de eerste oplog-gebeurtenis, de tijd voor de laatste oplog-gebeurtenis en de huidige tijd. De resultaten verschijnen zoals hieronder.
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)Van de oplog van de primaire server vond de laatste synchronisatie plaats op di 05 maart 2013 07:48:19 GMT-0800 (PST). Vanaf de oplog van de secundaire server vond de laatste bewerking plaats op di 05 maart 2013 07:48:19 GMT-0800 (PST). De replicatievertraging was nul en daarom werkt ons ketenrepliceerde systeem correct. De vertraging van de replicatie kan echter variëren, afhankelijk van het aantal wijzigingen dat moet worden gerepliceerd.