En udviklervejledning til MongoDB Replica Sets

MongoDB involverer ofte arbejde med et stort sæt data, herunder indlejrede arrays og array-objekter. Derfor er det altid vigtigt at sikre, at din databasebehandlingshastighed er så hurtig som muligt for at forbedre læse- og skriveoperationer. For at undgå dataanomalier, der kan opstå på grund af datainkonsistens, skal du desuden sikre dig, at dine data er i øget tilgængelighed, bare hvis du gerne vil have en genopretning fra en hændelse af hardwarefejl eller nogle tjenesteafbrydelser. MongoDB giver nogle 2 koncepter til det formål - ReplicaSets og Sharding.

Replikering i MongoDB

Master-Slave-replikering

Dette er en af ​​de ældste teknikker, der bruges til at sikre, at data altid er tilgængelige for brugerne, selv når et system fejlede. Master-Slave-replikering er dog forældet i de seneste versioner af MongoDB fra 3.2 og blev således erstattet med replikasæt.

For at lave denne konfiguration starter man 2 mongod-forekomster, mens man overvejer, at den ene er i mastertilstand og den anden er slavetilstand.

For at starte en instans i mastertilstand skal du køre:

mongod --master --port portNumber

--master-optionerne instruerer mongod om at oprette en local.oplog.$main-samling, hvormed en liste over operationer sættes i kø, som slaverne kan anvende til at replikere dataene.

For at starte en mongod-instans i slavetilstand skal du bare køre:

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

Her skal du angive værtsnavnet og porten for masterinstansen til argumentet --source. Dette er en opsummeret oversigt over brugen af ​​Master-slavereplikeringen, og da den er forældet, vil vores interesse være på replikasættene.

Replikasæt

Dette er en gruppe af MongoDB-processer kendt som mongod-instanser, der grundlæggende er vært for det samme datasæt. Det er kendetegnet ved en primær node og flere sekundære noder til at bære data. Den primære node modtager alle skriveoperationer og registrerer alle andre ændringer af sit datasæt i sin operationslog. De sekundære noder i den anden ende replikerer den primære operationslog og anvender operationerne på deres datasæt, således at deres datasæt afspejler den primære datasæt. Med enkle ord kan vi sige, at vi har maskine A som den primære knude og maskine B og C som de sekundære knudepunkter. Maskine A modtager en skriveoperation og foretager ændringer i sine data og laver derefter en liste over de ændringer, der er foretaget. Maskiner B og C vil derefter kopiere operationer fra den angivne liste, i dette tilfælde oploggen, og udføre dem, så de resulterende data er de samme som i Machine A.

Som nævnt før, er det altid vigtigt at sikre høj tilgængelighed af data, især i produktionsmiljøet. Replikering kommer ind for at hjælpe ved at levere dataredundans i forskellige Mongod-forekomster. I tilfælde af datatab, da kopier af samme data er gemt på tværs af forskellige databaser flere steder, er det nemt at gendanne dem i den eksisterende.

Med mange kørende instanser sendes læse- og skriveoperationer fra klienter til forskellige servere, og derfor øges behandlingshastigheden. Den grundlæggende struktur af replikeringsprocessen er vist nedenfor.

Nogle gange er den primære muligvis ikke tilgængelig, f.eks. på grund af internetafbrydelse eller tjenesteafbrydelse. I dette tilfælde vil replikasættet nominere en sekundær til at være den primære knude. Så meget som læseanmodningerne grundlæggende er lavet til den primære, nogle gange kan læseanmodningerne sendes til de sekundære, men vær forsigtig, da de returnerede data muligvis ikke afspejler, hvad der er i den primære, eller rettere, dataene måske ikke er opdaterede.

Dommere

I tilfælde af valg af et primærvalg skal du bruge en ekstra mongod-instans til replikasættet for at tilføje en stemme i valgprocessen. Denne instans omtales som en dommer, og dens fremtrædende træk er:

1. Den har ikke en kopi af datasættet, og kræver derfor ikke så kraftig hardware som de databærende noder.
2. Kan ikke forfremmes til at blive den primære.
3. De har altid 1 valgmandsstemme for at tillade replikasæt at have et ulige antal stemmeberettigede medlemmer uden overhead af et ekstra medlem, der replikerer data. Dens afgørende rolle er derfor at vælge en primær node, når den ikke er tilgængelig.
4. Den forbliver uændret.

I modsætning til dommeren kan andre replikasæt konverteres til primære fra sekundære og omvendt.

Asynkron replikering

Replikationsprocessen foregår i to former for datasynkronisering. Først udfyldes medlemmerne i sættet med fuldstændige data i den indledende synkronisering. Den efterfølgende replikering finder sted for at anvende avancerede ændringer til hele datasættet.

I den indledende synkronisering kopieres data fra et medlem af replikasættet til et andet. Når processen er afsluttet, går medlemmet over i den sekundære node.

MongoDB Automatic Failover

Der kan være en tjenesteafbrydelse som netværksafbrydelse, som kommer med en konsekvens af at afbryde kommunikationen mellem den primære og den sekundære. Hvis afbrydelsen varer mere end 10 sekunder eller mislykkes fuldstændigt, vil det resterende replikasæt stemme for, at et medlem bliver det nye primære medlem. Den sekundære node, der får flertallet af stemmerne, bliver den nye primære.

I version 3.0 af MongoDB kan et replikasæt have op til 50 medlemmer med 7 stemmeberettigede medlemmer.

Priority Zero Replica Set Members

Disse er sekundære medlemmer, der hverken kan gå over til at være primære noder eller udløse et valg. Der er afgørende roller i datasættet at:vedligeholde datasætkopier, vælge en primær node og udføre læseoperationer. De fungerer som en backup, hvor et nyt medlem måske undlader at tilføje med det samme. Det vil således gemme de opdaterede data og kan straks erstatte et utilgængeligt medlem.

MongoDB Hidden Replica Set-medlemmer

Disse er medlemmer uden forbindelse til klientapplikationerne. De bruges til arbejdsbelastninger med forskellige brugskrav fra andre sekundære medlemmer. De modtager kun den grundlæggende replikeringstrafik, der er under den indledende synkronisering.

MongoDB-medlemmer med forsinket replikasæt

Disse kopierer data fra den primære nodes oplog-fil inden for en bestemt varighed. De afspejler altid den forsinkede tilstand eller en tidligere form for sættet. De er derfor vigtige til at opdage fejl og giver et hint om, hvordan man kan komme sig fra de fejl, for eksempel hvis der er en database, der er blevet droppet. Når du vælger størrelsen af ​​forsinkelsen, skal dette tages i betragtning:

1. Varigheden skal være mindre end kapaciteten af ​​operationsloggen, som for WiredTiger-, MMAPv1- og In-Memory-lagringsmotorerne er 50 GB. Ellers kan det forsinkede medlem ikke replikere handlinger.
2. Forsinkelsens varighed skal være lig med eller lidt længere end din forventede varighed af vedligeholdelsesvinduet.

Konfiguration

Dette er et prioritet nul medlem, det er skjult og derfor ikke synligt for ansøgninger og kan endelig deltage i valgprocessen. For at konfigurere en prioritet, lad os sige, at du har 10 medlemmer i dit replikasæt, du kan vælge et medlem på position n som medlem[n] og indstille dets egenskaber som:

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

Eller ved at bruge mongo-skallen, der er forbundet til den primære, kan du køre denne kommando for at indstille det første medlem af replikasættet som et forsinket:

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

Efter indstilling af denne konfiguration kan den forsinkede sekundære ikke blive en primær og derfor skjult for applikationer. Medlemmet vil blive forsinket med 1 time (3600 sekunder) fra oplog-handlingerne.

Sådan starter du et replikasæt

I denne guide skal vi trin for trin se, hvordan vi kan konfigurere et replikasæt i MongoDB.

1. Lad os sige, at du har 3 mongodb, du vil replikere, og de er konfigureret som følger:
   1. Mongod1.conf kører på port 27017
   2. Mongod2.conf kører på port 27018
   3. Mongod3.conf kører på port 27019

   Sørg for at tilføje replikasætnavnet, som ikke ændres i hver fil. Du kan gøre det ved at tilføje eller ændre værdien for option replSet til et navn efter eget valg.

2. Vi kan starte den første instans ved at køre

   sudo mongod --config /etc/mongo/mongod1.conf

   Dette er, hvis du ikke har nogen mongod kørende instans. Gør derefter det samme for de andre tilfælde. For at tjekke for kørende forekomster i din maskine køre

   ps -ax | grep mongo

   Du får en liste som denne:

   4328 ttys000    0:06.15 mongod
   4950 ttys001    0:00.00 grep mongo

   Dette betyder, at den første instans i MongoDB som standard kører på port 27017, derfor har vi den som den første på listen. Hvis du startede de andre, vil de også blive skitseret på listen med deres tilsvarende sti-urls. For at oprette forbindelse til en instans i mongo-skallen skal du køre denne kommando:

   mongo  --port port_number i.e mongo  --port 27017.

   Men i vores tilfælde er vi nødt til at forbinde med et replikasætnavn, så vi skal tilføje navnet til kommandoen:

   mongod --replSet replicaSetName --dbpath /usr/local/var/mongo/mongod --port 27017

   I dette tilfælde vores replicaSetName ="testrep"

3. Lad os tjekke, om der er et replikasæt aktiveret ved at køre rs.status()

   Hvis du får et resultat som:

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

   Så betyder det, at der ikke er noget replikasæt aktiveret. Ellers hvis du får resultatet som

   {
       "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)
           }
       }
   }

   så betyder det, at replikaen endnu ikke er påbegyndt.

4. rs.initiate()-metoden vil hjælpe os med at starte et nyt replikasæt, og den instans, hvori den startes, bliver vores primære node. Så vi kan starte en i vores tilfælde ved at køre initiate-metoden. rs.initiate().

5. Tjek replikasættets status igen ved at køre rs.status().members. Du skulle nu se noget lignende

   "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" : ""
           }
       ]

   Nå, godt at gå. Vores interesse vil være medlemmers mulighed, da vi kan se, at det er et array med 1 medlem i det. Ved at markere det første medlems stateStr-indstilling i dette tilfælde er det sat til Primary, hvilket betyder, at dette vil fungere som vores primære knude.

6. Tilføj et nyt medlem til replikasættet ved hjælp af dets værtsnavn. Kør

   for at tjekke værtsnavnet på den tilsluttede instans, du vil tilføje

   db.serverStatus().host

   Du vil få noget lignende

   ervername.local:27019

   Så fra PRIMÆR kan du tilføje et andet medlem ved at køre denne kommando i mongo-skallen:

   rs.add("servername.local:27019");

7. Kør statuskommandoen

   rs.status().members

   For at kontrollere, om ændringerne er foretaget.

   Du skulle nu have noget, der ser sådan her ud:

   [
       {
           "_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
       }
   ]

   Vi har nu 2 medlemmer, den ene er en PRIMÆR node og den anden er en SEKUNDÆR node. Du kan tilføje flere medlemmer, men ikke overstige 50. Lad os nu lave en database i instansen på port 27018 som den primære.

   

   Hvis vi afbryder den primære, vil der ske en failover, og da vi kun har 1 primær vil den automatisk blive overført til en sekundær. Hvis vi nu opretter forbindelse til den på port 27019, skulle du få de samme databaser og samlinger med deres dokumenter.

   

   Hvis nu den afbrudte primære node genforbindes, vil den blive tilføjet som en sekundær, da den kopierer operationer fra oploggen af ​​den eksisterende primære.

MongoDB Replica Set Skriv bekymring

Hvis MongoDB returnerer et vellykket journalført skriveproblem, vil dataene blive gemt på disken og bliver derfor tilgængelige efter mongod genstarter. For skriveoperationerne er dataene dog kun holdbare, efter at de bliver replikeret og forpligtet til tidsskriftet til fordel for flertallet af det stemmeberettigede medlem af replikasættet.

Nogle data kan være for store til at opdatere eller indsætte, og det kan derfor tage længere tid end forventet, før dataene bliver replikeret i andre medlemmer. Af denne grund er det tilrådeligt at redigere writeConcern-konfigurationerne for at tage højde for den varighed, inden for hvilken en operation skal udføres. Standard writeConcern-konfigurationerne dikterer, at replikasættet kun kræver bekræftelse fra det primære medlem. Et standardskriveproblem bekræfter kun skriveoperationer for den primære, men kan tilsidesættes for at kontrollere skriveoperationer på nogle replikasætmedlemmer ved at specificere skriveproblemet for en specifik skriveoperation. For eksempel:

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

Skriveindstillingen i dette tilfælde dikterer, at operationen først skal returnere et svar, efter at det er blevet spredt til den primære og mindst 2 sekundære, eller hvis den timeout efter 3,6 sekunder.

Konfiguration af skriveproblemer for MongoDB

Indstillingen MongoDB getLastErrorDefaults giver os parametrene til at ændre standardindstillingerne for skriveproblemer i replikasættets konfiguration. Dette indebærer, at operationen skal være gennemført hos de fleste af de stemmeberettigede medlemmer, før resultatet returneres.

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

Timeoutværdien vil forhindre blokering af skriveoperationer, det vil sige, hvis der skal være 5 medlemmer til at anerkende skriveproblemet, men der desværre er 4 eller færre medlemmer i replikasættet, vil operationen blokere, indtil alle medlemmerne er tilgængelige. Ved at tilføje timeout-tærsklen vil operationsblokeringen blive kasseret efter denne varighed.

Replikeringsblokering

Blokering af en operation, især når alle medlemmerne er blevet replikeret, sikrer, at der ikke spildes mere tid på at vente på, at et andet replikasæt-medlem er tilgængeligt for at returnere et svar. MongoDB getLastError-kommandoindstillingen dikterer, hvordan replikeringsopdateringen udføres ved hjælp af den valgfri "w"-attribut.

For eksempel denne forespørgsel

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

kræver, at blokeringen sker, indtil N antal medlemmer har replikeret den sidste skriveoperation. Hvis N er tilgængelig eller er mindre end 2, vil forespørgslen blive returneret. Ellers, hvis værdien for N er lig med 2, vil masteren svarende til den primære, kun reagere, efter at 1 af dens slaver er blevet replikeret til den sidste operation.

wtimeout parameter er grundlæggende at indstille tiden i millisekunder, hvorefter getLastError-kommandoen vil timeout og returnere en fejl, før den sidste mulighed er blevet replikeret.

Så meget som at blokere på en eller anden måde er fordelagtigt, har det nogle gange en begrænsning. Det sænker læseoperationerne markant, især hvis du indstiller "w"-værdien til at være for stor. Jeg vil anbefale, at du indstiller "w"-værdien til enten 2 eller 3 for forbedret sikkerhed og effektivitet.

Læs præference i MongoDB

Dette er dybest set den tilstødende rute, hvormed klientens læseoperationer udføres til replikasættet. Standard MongoDB-opsætningen konfigurerer læseoperationerne til den primære, fordi det er den med den seneste version af det dokument, du henter. Som nævnt før er den største fordel ved at udnytte replikasættet at forbedre ydeevnen af ​​vores databasesystem. Det er derfor tilrådeligt at distribuere læseoperationerne til mange sekundære medlemmer for at reducere latens for applikationer, som ikke nødvendigvis kræver opdaterede data. Der er dog mere afgørende grunde til, at du også bør bruge den primære som din grundlæggende præference:

1. Opretholdelse af datatilgængelighed under failover.
2. For geografisk distribuerede applikationer vil den primære levere lokale læsninger til klienter i det samme datacenter.
3. For ikke at påvirke frontend-applikationerne, især dem, der kører systemoperationer.

Mongo.setReadPref() Metode

Denne metode er grundlæggende at definere, hvordan klienten vil dirigere alle forespørgsler til medlemmer af replikasættet. Det kræver 2 argumenter, mode og tagSet.

Modusargumentet angiver læsepræferencen, som enten kan være primær, primærforetrukken, sekundær, sekundærforetrukken eller nærmeste.

TagSet-tilstanden angiver den tilpassede læsepræference. Du kan også angive dem som en række objekter. Et eksempel på opsætningen vil være:

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

Det, der sker her, er, at hvis klienten forsøger at få adgang til det første tag, og anmodningen ikke går igennem, vil de blive valgt til den anden læsepræference.

Læs præferencetilstande

• Primær:dette definerer, at alle læseoperationer, der læses fra et givet replikasæt, er primære og er standard præferencelæsetilstand.
• PrimaryPreferred:Hvis kun den primære ikke er tilgængelig, kan læsehandlingerne udføres fra de sekundære.
• Sekundær:Alle læsehandlinger udføres fra de sekundære medlemmer af replikasættet.
• Sekundært foretrukken:Hvis kun der ikke er nogen sekundær tilgængelig, kan læsehandlingerne udføres fra den primære.
• Nærmeste:Medlem med mindst netværksforsinkelse er valgt til læsehandlingen uanset dets type.

Tagsæt og deres konfiguration

Dette er muligheder, der gør dig i stand til at modellere, som du ønsker, at din skrivebekymring og læsepræference skal se ud. De er gemt i replikasættets konfigurationsobjekt. Hvis du kører rs.conf().members, vil du få dette objekt returneret:

[
    {
        "_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
    }
]

Som du kan se, har hvert medlem tags-attribut.

Den største forskel mellem læsepræferencer og skrivebekymring er, at førstnævnte tager værdien af ​​et tag i betragtning, når man vælger et medlem at læse fra, mens sidstnævnte ikke gør det.

Lad os sige, at et tag sæt til en læsehandling er indstillet til:

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

Et medlem i replikasættet skal opfylde disse tags for at læseoperationen kan gennemføres. Derfor for at sige, en konfiguration som denne

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

vil tilfredsstille forespørgslen, mens denne

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

vil ikke opfylde forespørgslen.

Tilføjelse af tags til en sæt replika

For dit valgte medlem i et replikasæt kan du tilføje tagsæt ved hjælp af rs.conf()-metoden i MongoDB.

Lad os sige, at du har valgt et medlem i position 1 i dit replikasæt, du kan tilføje tagsæt som følger.

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)

Implementeringsmønstre for MongoDB Replica Set

1. Geografisk distribueret replikasæt - Forbedrer redundans af data udover at beskytte data mod fejl såsom strømsvigt. De kørende forekomster er placeret flere steder.
2. Replikasæt med tre medlemmer - den grundlæggende standardarkitektur for et replikasæt.
3. Replikasæt med fire eller flere medlemmer - Muliggør en bredere redundans af data og understøtter også en bredere fordeling af læseoperationer i replikasættet.

MongoDB Replica Set Deployment Tuning Techniques

Et ideelt replikasæt vil kræve en veloplagt arkitektur med mindst 3 medlemmer til et produktionssystem. Disse implementeringsstrategier hjælper dig med at aktivere et fantastisk replikasæt.

1. Brug forsinkede og skjulte medlemmer til at understøtte dedikerede funktioner såsom rapportering og backup.
2. Gør altid antallet af udsendte medlemmer ulige. Som vi har diskuteret ovenfor, kræves der et ulige antal medlemmer ved valg af en primær. Sørg derfor for at have et ulige tal, og hvis ikke, kan du altid tilføje en dommer.
3. For læsetunge implementeringer skal du afbalancere belastningen. Du vil derfor blive bedt om at distribuere læsninger til den sekundære for at forbedre læseydelsen. Desuden, når dataene vokser med tiden, kan du tilføje flere medlemmer og distribuere dem, men husk, at du skal konfigurere det på en sådan måde, at det vigtigste design er at vælge det primære.
4. Overvej altid fejltolerance. Dette afgør grundlæggende, hvor mange medlemmer der kan være utilgængelige på et givet tidspunkt, og hvor mange der vil være tilbage for at opretholde valgprocessen i et primærvalg. Hvis du ikke har en primær, vil replikasættet desværre ikke acceptere nogen skriveoperation.
5. Tilføj nye medlemmer til det eksisterende replikasæt, før der opstår efterspørgsel.
6. Brug tagsæt med replikasæt til at sikre, at alle operationer replikeres i specifikke datacentre. Du kan også bruge disse tags i routing til læseoperationerne for specifikke implementeringsmaskiner.
7. Indsæt de fleste af dine medlemmer på ét sted for at undgå det tilbageslag, der vil opstå fra netværksopdeling. Netværkspartitionering kan være resultatet af afbrudt kommunikation mellem datacentre, og dermed hindre replikeringsprocessen og processen med at vælge en primær.
8. Af sikkerhedsmæssige årsager skal du fordele dine medlemmer geografisk udover at gøre nogle skjulte. Du kan indstille mindst 2 eller 3 medlemmers prioritet til nul for at undgå at gøre dem til primære.
9. Brug journalføring for at beskytte datatab, der kan resultere i noget som et strømsvigt. Dette sikrer, at data bliver skrevet til disken i tilfælde af pludselig nedlukning.

Operationsloggen (Oplog)

Oploggen vedligeholder en registrering af masteroperationerne, der skal anvendes på slaverne. Det er gemt i en database kaldet local i oplog.$main collection. Det oprettes, når du starter et replikasætmedlem for første gang. På den øvre grænse er oploggen begrænset til en størrelse på 50 GB for alle lagringsmotorer. Oplog-størrelsen kan ændres fra en standardindstilling. Hvis denne størrelse nås for eksempel inden for 24 timers drift, vil sekundærerne ikke være i stand til at kopiere fra den i denne varighed komfortabelt og kan ende med slet ikke at kopiere. Du kan ændre størrelsen på oploggen ved at bruge muligheden replSetResizeOplog, dvs.

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

Hvis du skal reducere størrelsen af ​​denne oplog, vil det resultere i, at nogle data bliver fjernet. Kernevirkningen af ​​dette i replikasættet er, at medlemmer, der er synkroniseret til denne node, bliver forældede. Du bliver derfor nødt til at synkronisere disse medlemmer igen.

Workload-mønstre, der ville kræve en stor Oplog-størrelse

1. Opdater til flere dokumenter på én gang. De flere opdateringsoperationer skal oversættes til en individuel operation for at forbedre resultaterne på tværs af knudepunkterne. Denne operation vil bruge en stor del af oplog-rummet.
2. Betydende antal opdateringer på stedet. Dette sker generelt, når opdatering af data i dokumenter ikke nødvendigvis øger størrelsen af ​​dette dokument. Databasen vil registrere et stort antal operationer til oploggen og dermed øge dens størrelse.
3. Sletninger svarer til den samme mængde data som indsættelser. Dette sker, når du forsøger at slette en mængde data (næsten) svarende til den mængde data, du indsætter. Denne operation vil have en tendens til at øge størrelsen af ​​oploggen.

Konklusion

Replikering er et vigtigt aspekt af databaser, som udviklere skal forstå. Det sikrer øget tilgængelighed af data. Din MongoDB-server kan gå ned, for eksempel på grund af en strømafbrydelse, men du vil stadig gerne have, at dine klienter får adgang til dens data. Hvis du har replikeret data på en anden server, vil dine klienter være i stand til at fortsætte med at få adgang til data fra den, hvis den primære server fejler. Desuden er der øget belastningsbalancering, så vi i stedet for at alle brugere har adgang til én enkelt server, har set afvejningen ved at betjene trafik fra sekundære replikaer.