Een handleiding voor ontwikkelaars voor MongoDB-replicasets

MongoDB omvat vaak het werken met een grote set gegevens, waaronder ingesloten arrays en array-objecten. Daarom is het altijd belangrijk om ervoor te zorgen dat de verwerkingssnelheid van uw database zo snel mogelijk is om lees- en schrijfbewerkingen te verbeteren. Bovendien, om gegevensafwijkingen te voorkomen die kunnen ontstaan als gevolg van gegevensinconsistentie, moet u ervoor zorgen dat uw gegevens beter beschikbaar zijn voor het geval u herstel wilt hebben van een hardwarestoring of sommige serviceonderbrekingen. MongoDB biedt daarvoor 2 concepten - ReplicaSets en Sharding.

Replicatie in MongoDB

Master-Slave-replicatie

Dit is een van de oudste technieken die wordt gebruikt om ervoor te zorgen dat gegevens altijd beschikbaar zijn voor gebruikers, zelfs als één systeem uitvalt. Master-Slave-replicatie is echter verouderd in de nieuwste versies van MongoDB vanaf 3.2 en werd daarom vervangen door Replica-sets.

Om deze configuratie te maken, start men 2 mongod-instanties terwijl men ervan uitgaat dat de ene zich in de master-modus bevindt en de andere in de slave-modus.

Om een instantie in de mastermodus te starten, voert u het volgende uit:

mongod --master --port portNumber

De --master opties instrueren mongod om een local.oplog.$main collectie aan te maken waarmee een lijst met bewerkingen in de wachtrij staat die de slaves kunnen toepassen bij het repliceren van de gegevens.

Om een mongod-instantie in slave-modus te starten, voert u gewoon het volgende uit:

mongod --slave --source <masterhostname><:<port>>

Hier moet u de hostnaam en de poort van de hoofdinstantie opgeven voor het argument --source. Dit is een samengevat overzicht van het gebruik van de Master-slave-replicatie en aangezien deze is verouderd, zullen onze interesses uitgaan naar de Replica-sets.

Replica-sets

Dit is een groep MongoDB-processen die bekend staat als mongod-instanties die in feite dezelfde dataset hosten. Het wordt gekenmerkt door een primair knooppunt en verschillende secundaire knooppunten voor het dragen van gegevens. Het primaire knooppunt ontvangt alle schrijfbewerkingen en registreert alle andere wijzigingen in zijn gegevensset in zijn bewerkingslogboek. De secundaire knooppunten, aan de andere kant, repliceren het bewerkingslogboek van de primaire en passen de bewerkingen toe op hun dataset zodat hun datasets de dataset van de primaire weerspiegelen. In eenvoudige bewoordingen kunnen we zeggen dat we machine A als het primaire knooppunt hebben en machine B en C als de secundaire knooppunten. Machine A ontvangt een schrijfbewerking en brengt wijzigingen aan in zijn gegevens en maakt vervolgens een lijst van de aangebrachte wijzigingen. Machines B en C zullen dan bewerkingen kopiëren uit de verstrekte lijst, in dit geval de oplog, en deze uitvoeren zodat de resulterende gegevens hetzelfde zijn als in Machine A.

Zoals eerder vermeld, is het altijd belangrijk om te zorgen voor een hoge beschikbaarheid van gegevens, vooral in de productieomgeving. Replicatie komt van pas door gegevensredundantie te bieden in verschillende Mongod-instanties. In het geval van gegevensverlies, aangezien kopieën van dezelfde gegevens in verschillende databases op meerdere locaties worden opgeslagen, is het gemakkelijk om deze te herstellen in de bestaande.

Met veel actieve instanties worden lees- en schrijfbewerkingen van clients naar verschillende servers gestuurd en daardoor neemt de verwerkingssnelheid toe. De basisstructuur van het replicatieproces wordt hieronder getoond.

Soms is de primaire niet beschikbaar, bijvoorbeeld vanwege een internetverbinding of een serviceonderbreking. In dit geval zal de replicaset een secundair nomineren als het primaire knooppunt. Hoezeer de leesverzoeken in principe ook aan de primaire worden gedaan, in sommige gevallen kunnen de leesverzoeken naar de secundairen worden verzonden, maar wees voorzichtig, aangezien de geretourneerde gegevens mogelijk niet weerspiegelen wat er in de primaire staat, of liever gezegd, de gegevens zijn mogelijk niet up-to-date.

Arbiters

In het geval van verkiezing van een voorverkiezing, hebt u een extra mongod-instantie nodig voor de replicaset om een stem toe te voegen aan het verkiezingsproces. Deze instantie wordt een arbiter genoemd en de meest opvallende kenmerken zijn:

Het heeft geen kopie van de dataset, dus vereist niet zo krachtige hardware als de data dragende nodes..
Kan niet worden gepromoveerd om de primaire te worden.
Ze hebben altijd 1 kiesstem, zodat replicasets een oneven aantal stemmende leden kunnen hebben zonder de overhead van een extra lid dat gegevens repliceert. Zijn cruciale rol is daarom het selecteren van een primaire node wanneer deze niet beschikbaar is.
Het blijft ongewijzigd.

In tegenstelling tot de arbiter, kunnen andere replicasets worden omgezet in primaire van secundaire en vice versa.

Asynchrone replicatie

Het proces van replicatie vindt plaats in twee vormen van gegevenssynchronisatie. Eerst worden de leden in de set bij de eerste synchronisatie gevuld met volledige gegevens. De daaropvolgende replicatie vindt plaats om voortschrijdende wijzigingen toe te passen op de gehele dataset.

Bij de eerste synchronisatie worden gegevens van het ene lid van de replicaset naar het andere gekopieerd. Wanneer het proces is voltooid, gaat het lid over naar het secundaire knooppunt.

MongoDB automatische failover

Er kan een serviceonderbreking zijn, zoals een netwerkverbinding, die het gevolg is van het beëindigen van de communicatie tussen de primaire en de secundaire. Als de verbinding langer dan 10 seconden duurt of volledig mislukt, zal de resterende replicaset stemmen voor een lid om de nieuwe primaire te worden. Het secundaire knooppunt dat de meerderheid van de stemmen krijgt, wordt het nieuwe primaire knooppunt.

In versie 3.0 van MongoDB kan een replicaset maximaal 50 leden hebben met 7 stemgerechtigde leden.

Priority Zero Replica Set-leden

Dit zijn secundaire leden die niet kunnen overgaan naar primaire knooppunten en ook geen verkiezing kunnen veroorzaken. De cruciale rollen in de dataset zijn:kopieën van datasets onderhouden, een primair knooppunt kiezen en leesbewerkingen uitvoeren. Ze fungeren als een back-up waar een nieuw lid mogelijk niet onmiddellijk aan toevoegt. Het zal dus de bijgewerkte gegevens opslaan en kan een niet-beschikbaar lid onmiddellijk vervangen.

MongoDB Hidden Replica Set-leden

Dit zijn leden zonder verbinding met de client-applicaties. Ze worden gebruikt voor workloads met andere gebruiksvereisten dan andere secundaire leden. Ze ontvangen alleen het basisreplicatieverkeer tijdens de eerste synchronisatie.

MongoDB vertraagde replicasetleden

Deze kopiëren gegevens uit het oplog-bestand van het primaire knooppunt binnen een bepaalde tijdsduur. Ze weerspiegelen altijd de vertraagde toestand of een eerdere vorm van de set. Ze zijn daarom belangrijk bij het opsporen van fouten en geven een hint over hoe men van die fouten kan herstellen, bijvoorbeeld als er een database is weggevallen. Houd bij het kiezen van de hoeveelheid vertraging rekening met:

De duur moet korter zijn dan de capaciteit van het bewerkingslogboek, dat voor de WiredTiger-, MMAPv1- en In-Memory-opslagengines 50 GB is. Anders kan het vertraagde lid de bewerkingen niet met succes repliceren.
De vertragingsduur moet gelijk zijn aan of iets langer zijn dan de verwachte duur van de onderhoudsperiode.

Configuratie

Dit is een lid met prioriteit nul, het is verborgen en is daarom niet zichtbaar voor aanmeldingen en kan ten slotte deelnemen aan het verkiezingsproces. Om een prioriteit te configureren, laten we zeggen dat u 10 leden in uw replicaset heeft, kunt u een lid op positie n selecteren als lid[n] en de eigenschappen ervan instellen als:

{
    “_id”: <num>, 
    “Host”: <hostname: port>,
    “Priority”: 0,
    “slaveDelay”: <seconds>,
    “Hidden”: true
}

Of door de mongo-shell te gebruiken die op de primaire is aangesloten, kunt u deze opdrachten uitvoeren om het eerste lid van de replicaset als vertraagd in te stellen:

cfg = rs.conf()
cfg.members[0].priority = 0
cfg.members[0].hidden = true
cfg.members[0].slaveDelay = 3600
rs.reconfig(cfg)

Nadat deze configuraties zijn ingesteld, kan de vertraagde secundaire niet een primaire worden en daarom verborgen voor toepassingen. Het lid wordt 1 uur (3600 seconden) vertraagd vanaf de oplogbewerkingen.

Multiplenines Word een MongoDB DBA - MongoDB naar productie brengenLeer over wat u moet weten om MongoDB gratis te implementeren, bewaken, beheren en schalen

Hoe een replicaset starten

In deze handleiding zullen we stap voor stap zien hoe we een replicaset in MongoDB kunnen configureren.

Stel dat je 3 mongodb hebt die je wilt repliceren en dat ze als volgt zijn geconfigureerd:
1. Mongod1.conf draait op poort 27017
2. Mongod2.conf draait op poort 27018
3. Mongod3.conf draait op poort 27019
Zorg ervoor dat u de naam van de replicaset toevoegt, die niet in elk bestand zal veranderen. U kunt dit doen door de optie replSet value toe te voegen aan of te wijzigen in een naam naar keuze.
We kunnen de eerste instantie starten door
. uit te voeren
```
sudo mongod --config /etc/mongo/mongod1.conf
```
Dit is als u geen mongod-running-instantie hebt. Doe vervolgens hetzelfde voor de andere instanties. Om te controleren op actieve instanties in uw machine run
```
ps -ax | grep mongo
```
Je krijgt een lijst zoals deze:
```
4328 ttys000    0:06.15 mongod
4950 ttys001    0:00.00 grep mongo
```
Dit betekent dat de eerste instantie in MongoDB standaard op poort 27017 draait, daarom hebben we deze als de eerste in de lijst. Als u de andere hebt gestart, worden deze ook weergegeven in de lijst met de bijbehorende pad-URL's. Voer deze opdracht uit om verbinding te maken met een instantie in de mongo-shell:
```
mongo  --port port_number i.e mongo  --port 27017.
```
In ons geval moeten we echter verbinding maken met een replicasetnaam, dus moeten we de naam toevoegen aan de opdracht:
```
mongod --replSet replicaSetName --dbpath /usr/local/var/mongo/mongod --port 27017
```
In dit geval onze replicaSetName =“testrep”

Laten we controleren of er een replicaset is ingeschakeld door rs.status()

. uit te voeren

Als je een resultaat krijgt zoals:

{
    "ok" : 0,
    "errmsg" : "not running with --replSet",
    "code" : 76,
    "codeName" : "NoReplicationEnabled"
}

Dan betekent dit dat er geen replicaset is ingeschakeld. Anders als u het resultaat krijgt als

{
    "operationTime" : Timestamp(0, 0),
    "ok" : 0,
    "errmsg" : "no replset config has been received",
    "code" : 94,
    "codeName" : "NotYetInitialized",
    "$clusterTime" : {
        "clusterTime" : Timestamp(0, 0),
        "signature" : {
            "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
            "keyId" : NumberLong(0)
        }
    }
}

dan betekent dit dat de replica nog niet is gestart.

De methode rs.initiate() helpt ons een nieuwe replicaset te starten en de instantie waarin deze wordt gestart, wordt ons primaire knooppunt. Dus we kunnen er in ons geval een starten door de methode initiëren uit te voeren. rs.initiate().

Controleer de status van de replicaset opnieuw door rs.status().members uit te voeren. Je zou nu iets als

. moeten zien

"members" : [
        {
            "_id" : 0,
            "name" : "localhost:27018",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 577,
            "optime" : {
                "ts" : Timestamp(1535301271, 1),
                "t" : NumberLong(1)
            },
            "optimeDate" : ISODate("2018-08-26T16:34:31Z"),
            "syncingTo" : "",
            "syncSourceHost" : "",
            "syncSourceId" : -1,
            "infoMessage" : "could not find member to sync from",
            "electionTime" : Timestamp(1535301265, 1),
            "electionDate" : ISODate("2018-08-26T16:34:25Z"),
            "configVersion" : 1,
            "self" : true,
            "lastHeartbeatMessage" : ""
        }
    ]

Goed om te gaan. Onze interesse zal de optie voor leden zijn, zoals we kunnen zien, is het een array met 1 lid erin. Als u de stateStr-optie van het eerste lid aanvinkt, is deze in dit geval ingesteld op Primair, wat betekent dat dit zal fungeren als ons primaire knooppunt.

Voeg een nieuw lid toe aan de replicaset met behulp van de hostnaam. Om te controleren op de hostnaam van de verbonden instantie die u wilt toevoegen, uitvoeren
```
db.serverStatus().host
```
Je krijgt zoiets als
```
ervername.local:27019
```
Dus vanaf de PRIMARY kun je een ander lid toevoegen door deze opdracht in de mongo-shell uit te voeren:
```
rs.add("servername.local:27019");
```

Voer de statusopdracht uit

rs.status().members

Om te controleren of de wijzigingen zijn aangebracht.

Je zou nu iets moeten hebben dat er zo uitziet:

[
    {
        "_id" : 0,
        "name" : "localhost:27018",
        "health" : 1,
        "state" : 1,
        "stateStr" : "PRIMARY",
        "uptime" : 11479,
        "optime" : {
            "ts" : Timestamp(1535312183, 1),
            "t" : NumberLong(1)
        },
        "optimeDate" : ISODate("2018-08-26T19:36:23Z"),
        "syncingTo" : "",
        "syncSourceHost" : "",
        "syncSourceId" : -1,
        "infoMessage" : "",
        "electionTime" : Timestamp(1535301265, 1),
        "electionDate" : ISODate("2018-08-26T16:34:25Z"),
        "configVersion" : 2,
        "self" : true,
        "lastHeartbeatMessage" : ""
    },
    {
        "_id" : 1,
        "name" : "127.0.0.1:27019",
        "health" : 1,
        "state" : 2,
        "stateStr" : "SECONDARY",
        "uptime" : 15,
        "optime" : {
            "ts" : Timestamp(1535312183, 1),
            "t" : NumberLong(1)
        },
        "optimeDurable" : {
            "ts" : Timestamp(1535312183, 1),
            "t" : NumberLong(1)
        },
        "optimeDate" : ISODate("2018-08-26T19:36:23Z"),
        "optimeDurableDate" : ISODate("2018-08-26T19:36:23Z"),
        "lastHeartbeat" : ISODate("2018-08-26T19:36:26.302Z"),
        "lastHeartbeatRecv" : ISODate("2018-08-26T19:36:27.936Z"),
        "pingMs" : NumberLong(0),
        "lastHeartbeatMessage" : "",
        "syncingTo" : "localhost:27018",
        "syncSourceHost" : "localhost:27018",
        "syncSourceId" : 0,
        "infoMessage" : "",
        "configVersion" : 2
    }
]

We hebben nu 2 leden, één is een PRIMAIRE knoop en de andere is een SECUNDAIRE knoop. U kunt meer leden toevoegen, maar niet meer dan 50. Laten we nu een database maken in de instantie op poort 27018 als de primaire.

Als we de primaire verbinding verbreken, zal er een failover plaatsvinden en aangezien we slechts 1 primaire hebben, wordt deze automatisch overgezet naar een secundaire. Als we nu verbinding maken met die op poort 27019, zou je dezelfde databases en verzamelingen met hun documenten moeten krijgen.

Als het niet-verbonden primaire knooppunt nu opnieuw wordt verbonden, wordt het als secundair toegevoegd omdat het bewerkingen kopieert van de oplog van het bestaande primaire knooppunt.

MongoDB Replica Set Schrijfprobleem

Als MongoDB een succesvol gejournaliseerd schrijfprobleem retourneert, worden de gegevens op de schijf opgeslagen en komen ze beschikbaar nadat Mongod opnieuw is opgestart. Voor de schrijfbewerkingen zijn de gegevens echter pas duurzaam nadat ze zijn gerepliceerd en zijn vastgelegd in het tijdschrift in het voordeel van de meerderheid van het stemgerechtigde lid van de replicaset.

Sommige gegevens zijn mogelijk te groot om bij te werken of in te voegen, waardoor het langer dan verwacht kan duren voordat de gegevens in andere leden zijn gerepliceerd. Om deze reden is het raadzaam om de writeConcern-configuraties aan te passen aan de duur waarbinnen een bewerking moet worden uitgevoerd. De standaard writeConcern-configuraties schrijven voor dat de replicaset alleen bevestiging van het primaire lid vereist. Een standaard schrijfprobleem bevestigt alleen schrijfbewerkingen voor de primaire, maar kan worden overschreven om schrijfbewerkingen op sommige replicasetleden te controleren door het schrijfprobleem voor een specifieke schrijfbewerking op te geven. Bijvoorbeeld:

db.books.insert({name: “James”,place: “Beijing”},{writeConcern: {w: 3, wtimeout: 3600}})

De schrijfoptie schrijft in dit geval voor dat de bewerking alleen een reactie moet retourneren nadat deze is verspreid naar de primaire en ten minste 2 secundairen of als er een time-out optreedt na 3,6 seconden.

Het schrijfprobleem voor MongoDB configureren

De optie MongoDB getLastErrorDefaults geeft ons de parameters voor het wijzigen van de standaardinstellingen voor schrijven in de replicasetconfiguratie. Dit houdt in dat de bewerking in de meeste stemgerechtigde leden moet zijn voltooid voordat het resultaat wordt geretourneerd.

cfg = rs.conf()
cfg.settings = {},
cfg.settings.getLastErrorDefaults = {w: “majority”, wtimeout: 3600}
rs.reconfig(cfg)

De time-outwaarde voorkomt dat schrijfbewerkingen worden geblokkeerd, dat wil zeggen, als er 5 leden zouden moeten zijn om het schrijfprobleem te erkennen, maar er helaas 4 of minder leden in de replicaset zijn, wordt de bewerking geblokkeerd totdat alle leden beschikbaar zijn. Door de time-outdrempel toe te voegen, wordt de bewerkingsblokkering na deze duur opgeheven.

Replicatie blokkeren

Het blokkeren van een bewerking, vooral wanneer alle leden zijn gerepliceerd, zorgt ervoor dat er geen tijd meer wordt verspild aan het wachten tot een ander lid van de replicaset beschikbaar is om een antwoord te retourneren. De opdrachtoptie MongoDB getLastError bepaalt hoe de replicatie-update wordt uitgevoerd met behulp van het optionele "w" -kenmerk.

Bijvoorbeeld deze zoekopdracht

db.runCommand({getLastError: 1, w: N, “wtimeout”: 5000});

vereist dat de blokkering plaatsvindt totdat N aantal leden de laatste schrijfbewerking hebben gerepliceerd. Als N beschikbaar is of kleiner is dan 2, wordt de query geretourneerd. Anders, als de waarde voor N gelijk is aan 2, zal de master die gelijk is aan de primaire, pas reageren nadat 1 van zijn slaves is gerepliceerd naar de laatste bewerking.

De wtimeout parameter is eigenlijk om de tijd in milliseconden in te stellen waarna de opdracht getLastError een time-out zal geven en een fout zal retourneren voordat de laatste optie is gerepliceerd.

Hoewel blokkeren op de een of andere manier voordelig is, heeft het soms een beperking. Het vertraagt de leesbewerkingen aanzienlijk, vooral als u de "w" -waarde te groot instelt. Ik raad je aan om de "w"-waarde in te stellen op 2 of 3 voor meer veiligheid en efficiëntie.

Leesvoorkeur in MongoDB

Dit is in feite de aangrenzende route waarmee de leesbewerkingen van de client naar de replicaset worden uitgevoerd. De standaard MongoDB-setup configureert de leesbewerkingen naar de primaire omdat dit degene is met de nieuwste versie van het document dat u ophaalt. Zoals eerder vermeld, is het grootste voordeel van het exploiteren van de replicaset het verbeteren van de prestaties van ons databasesysteem. Het is dus raadzaam om de leesbewerkingen over veel secundaire leden te distribueren om de latentie te verminderen voor toepassingen die niet noodzakelijk actuele gegevens nodig hebben. Er zijn echter meer cruciale redenen waarom u ook de primaire zou moeten gebruiken als uw basisvoorkeur:

Beschikbaarheid van gegevens behouden tijdens de failover.
Voor geografisch gedistribueerde applicaties levert de primaire lokale leesbewerkingen voor klanten in hetzelfde datacenter.
Niet om de front-end-applicaties te beïnvloeden, vooral niet die met systeembewerkingen.

Mongo.setReadPref() Methode

Deze methode is in feite bedoeld om te definiëren hoe de client alle query's naar leden van de replicaset zal routeren. Er zijn 2 argumenten nodig, modus en tagSet.

Het modusargument specificeert de leesvoorkeur die primair, primairVoorkeur, secundair, secundairVoorkeur of dichtstbijzijnde kan zijn.

De tagSet-modus specificeert de aangepaste leesvoorkeur. U kunt ze ook specificeren als een array van objecten. Een voorbeeld van de opstelling is:

db.getMongo().setReadPref('primaryPreferred',
                          [ { "dc": "east", "use": "production" },
                            { "dc": "east", "use": "reporting" },
                            { "dc": "east" },
                            {}
                          ] )

Wat hier gebeurt, is dat, als de klant probeert toegang te krijgen tot de eerste tag en het verzoek niet doorgaat, hij wordt gekozen voor de tweede leesvoorkeur.

Voorkeursmodi lezen

Primair:dit definieert dat alle leesbewerkingen die van een bepaalde replicaset worden gelezen, primair zijn en de standaard leesmodus met voorkeur is.
PrimaryPreferred:als alleen de primaire niet beschikbaar is, kunnen de leesbewerkingen worden uitgevoerd vanaf de secundairen.
Secundair:alle leesbewerkingen worden uitgevoerd vanaf de secundaire leden van de replicaset.
SecondaryPreferred:als er alleen geen secundaire beschikbaar is, kunnen de leesbewerkingen worden uitgevoerd vanaf de primaire.
Dichtstbijzijnde:lid met de minste netwerklatentie wordt geselecteerd voor de leesbewerking, ongeacht het type.

Tagsets en hun configuratie

Dit zijn opties waarmee u kunt modelleren zoals u wilt dat uw schrijf- en leesvoorkeur eruitziet. Ze worden opgeslagen in het configuratieobject van de replicaset. Als je rs.conf().members uitvoert, krijg je dit object terug:

[
    {
        "_id" : 0,
        "host" : "localhost:27018",
        "arbiterOnly" : false,
        "buildIndexes" : true,
        "hidden" : false,
        "priority" : 1,
        "tags" : {
            
        },
        "slaveDelay" : NumberLong(0),
        "votes" : 1
    },
    {
        "_id" : 1,
        "host" : "127.0.0.1:27019",
        "arbiterOnly" : false,
        "buildIndexes" : true,
        "hidden" : false,
        "priority" : 1,
        "tags" : {
            
        },
        "slaveDelay" : NumberLong(0),
        "votes" : 1
    }
]

Zoals je kunt zien, heeft elk lid het kenmerk 'tags'.

Het belangrijkste verschil tussen leesvoorkeuren en schrijfproblemen is dat de eerste rekening houdt met de waarde van een tag bij het selecteren van een lid om van te lezen, terwijl de laatste dat niet doet.

Laten we zeggen dat een tag die is ingesteld voor een leesbewerking is ingesteld op:

{ "disk": "ssd", "use": "reporting" }

Een lid in de replicaset moet aan deze tags voldoen voordat de leesbewerking kan worden uitgevoerd. Dus om te zeggen, een configuratie als deze

{ "disk": "ssd", "use": "reporting", "rack": "a" }

zal aan de vraag voldoen, terwijl deze

{ "disk": "ssd", "use": "production", "rack": "k" }

zal niet voldoen aan de vraag.

Tags toevoegen aan een setreplica

Voor uw geselecteerde lid in een replicaset kunt u tagsets toevoegen met behulp van de rs.conf()-methode in MongoDB.

Stel dat u een lid heeft geselecteerd op positie 1 van uw replicasetarray, u kunt als volgt tagsets toevoegen.

conf = rs.conf()
conf.members[0].tags = { "dc": "NYK", "use": "production"  }
conf.members[1].tags = { "dc": "LON", "use": "reporting"  }
conf.members[2].tags = { "use": "production"  }
rs.reconfig(conf)

Implementatiepatronen voor MongoDB-replicaset

Geografisch gedistribueerde replicaset - Verbetert de redundantie van gegevens naast het beschermen van gegevens tegen fouten zoals stroomuitval. De actieve instanties bevinden zich op meerdere locaties.
Replicaset met drie leden - de basisstandaardarchitectuur voor een replicaset.
Replicaset met vier of meer leden - Maakt een grotere redundantie van gegevens mogelijk en ondersteunt ook een bredere distributie van leesbewerkingen in de replicaset.

MongoDB Replica Set Deployment Tuning-technieken

Een ideale replicaset vereist een goed opgezette architectuur met ten minste 3 leden voor een productiesysteem. Met deze implementatiestrategieën kunt u een geweldige replicaset maken.

Gebruik vertraagde en verborgen leden om speciale functies zoals rapportage en back-up te ondersteunen.
Maak het aantal uitgezonden leden altijd oneven. Zoals we hierboven hebben besproken, is een oneven aantal leden vereist bij het kiezen van een voorverkiezing. Zorg er daarom voor dat je een oneven aantal hebt en zo niet, dan kun je altijd een arbiter toevoegen.
Voor leesintensieve implementaties moet u de belasting verdelen. U moet daarom leesbewerkingen distribueren naar de secundaire om de leesprestaties te verbeteren. Trouwens, als de gegevens met de tijd groeien, kun je meer leden toevoegen en ze distribueren, maar onthoud dat je het zo moet configureren dat het belangrijkste ontwerp is om de primaire te kiezen.
Houd altijd rekening met fouttolerantie. Dit bepaalt in feite hoeveel leden op een bepaald moment niet beschikbaar kunnen zijn en hoeveel er overblijven om het verkiezingsproces van een voorverkiezing te ondersteunen. Als u geen primary heeft, accepteert de replicaset helaas geen schrijfbewerkingen.
Voeg nieuwe leden toe aan de bestaande replicaset voordat er vraag naar is.
Gebruik tagsets voor replicasets om ervoor te zorgen dat alle bewerkingen worden gerepliceerd in specifieke datacenters. U kunt deze tags ook gebruiken in routering voor de leesbewerkingen voor specifieke implementatiemachines.
Plaats de meeste van je leden op één locatie om de tegenslag te vermijden die het gevolg is van netwerkpartitionering. Netwerkpartitionering kan het resultaat zijn van verbroken communicatie tussen datacenters, waardoor het replicatieproces en het proces van het kiezen van een primaire worden belemmerd.
Om veiligheidsredenen, verspreid je leden geografisch naast het verborgen houden van je leden. Je kunt de prioriteit van minimaal 2 of 3 leden op nul zetten om te voorkomen dat ze primair worden gemaakt.
Gebruik logboeken om gegevensverlies te beschermen dat kan leiden tot zoiets als een stroomstoring. Dit zorgt ervoor dat gegevens naar de schijf worden geschreven in het geval van plotseling afsluiten.

Het operatielogboek (Oplog)

De oplog houdt een overzicht bij van de masterbewerkingen die op de slaves moeten worden toegepast. Het wordt opgeslagen in een database met de naam local in de collectie oplog.$main. Het wordt gemaakt wanneer u voor de eerste keer een lid van een replicaset start. Aan de bovenzijde is de oplog beperkt tot een grootte van 50 GB voor alle opslag-engines. De oplog-grootte kan worden gewijzigd vanuit een standaardinstelling. Als deze grootte bijvoorbeeld binnen 24 uur gebruik wordt bereikt, kunnen de secundairen er gedurende deze tijd niet gemakkelijk van kopiëren en kunnen ze uiteindelijk helemaal niet kopiëren. U kunt de grootte van de oplog wijzigen met de optie replSetResizeOplog, d.w.z.

db.database({replSetResizeOplog:1, size: 16384})

Als u de grootte van deze oplog wilt verkleinen, zal dit ertoe leiden dat sommige gegevens worden verwijderd. De belangrijkste impact hiervan in de replicaset is dat leden die met dit knooppunt zijn gesynchroniseerd, oud worden. U moet deze leden dus opnieuw synchroniseren.

Werklastpatronen waarvoor een grote Oplog-maat nodig is

Update naar meerdere documenten tegelijk. De meervoudige updatebewerkingen moeten worden vertaald naar een afzonderlijke bewerking om de resultaten over de knooppunten te verbeteren. Deze operatie zal een enorme ruimte van de oplog-ruimte in beslag nemen.
Aanzienlijk aantal interne updates. Dit gebeurt over het algemeen bij het bijwerken van gegevens van documenten, waardoor dit document niet noodzakelijk groter wordt. De database zal een groot aantal bewerkingen opnemen in de oplog, waardoor deze groter wordt.
Verwijderingen zijn gelijk aan dezelfde hoeveelheid gegevens als invoegingen. Dit gebeurt wanneer u een hoeveelheid gegevens probeert te verwijderen die (bijna) gelijk is aan de hoeveelheid gegevens die u invoegt. Deze operatie heeft de neiging de grootte van de oplog te vergroten.

Conclusie

Replicatie is een belangrijk aspect van databases dat ontwikkelaars moeten begrijpen. Het zorgt voor een verhoogde beschikbaarheid van data. Uw MongoDB-server kan bijvoorbeeld uitvallen door een stroomstoring, maar u wilt toch dat uw klanten toegang hebben tot zijn gegevens. Als u gegevens op een andere server hebt gerepliceerd, kunnen uw klanten toegang blijven krijgen tot gegevens vanaf deze server als de primaire server uitvalt. Bovendien is er een verhoogde taakverdeling, zodat in plaats van dat alle gebruikers toegang hebben tot één enkele server, we de nadelen hebben gezien van het bedienen van verkeer van secundaire replica's.