En utvecklarguide till MongoDB Replica Sets

MongoDB involverar ofta att arbeta med en stor uppsättning data inklusive inbäddade arrayer och arrayobjekt. Därför är det alltid viktigt att se till att din databas bearbetningshastighet är så snabb som möjligt för att förbättra läs- och skrivoperationerna. Dessutom, för att undvika dataavvikelser som kan uppstå på grund av datainkonsekvens, måste du se till att dina data är i ökad tillgänglighet ifall du skulle vilja ha en återställning från en händelse av hårdvarufel eller vissa tjänsteavbrott. MongoDB tillhandahåller två koncept för det ändamålet - ReplicaSets och Sharding.

Replikering i MongoDB

Master-Slave Replication

Detta är en av de äldsta teknikerna som används för att säkerställa att data alltid är tillgänglig för användare även när ett system misslyckades. Master-Slave-replikering är dock utfasad i de senaste versionerna av MongoDB från och med 3.2 och ersattes därför med Replica-uppsättningar.

För att göra den här konfigurationen startar man 2 mongod-instanser medan man anser att den ena är i masterläge och den andra är slavläge.

För att starta en instans i huvudläge, kör:

mongod --master --port portNumber

--master-alternativen instruerar mongod att skapa en local.oplog.$main-samling med vilken en lista med operationer ställs i kö för slavarna att tillämpa vid replikering av data.

För att starta en mongod-instans i slavläge, kör bara:

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

Här måste du ange värdnamnet och porten för masterinstansen till argumentet --source. Detta är en sammanfattad översikt över hur man använder masterslavreplikeringen och eftersom den är utfasad kommer vårt intresse att ligga på replikuppsättningarna.

Replika uppsättningar

Detta är en grupp MongoDB-processer som kallas mongod-instanser som i princip är värd för samma datamängd. Den har en primär nod och flera sekundära noder för att bära data. Den primära noden tar emot alla skrivoperationer och registrerar alla andra ändringar av sin datauppsättning i sin operationslogg. De sekundära noderna, i andra änden, replikerar den primära operationsloggen och tillämpar operationerna på sin datamängd så att deras datamängder återspeglar den primära datamängden. Med enkla ord kan vi säga att vi har maskin A som primärnod och maskin B och C som sekundära noder. Maskin A tar emot en skrivoperation och gör ändringar i sina data och gör sedan en lista över de ändringar som har gjorts. Maskin B och C kommer sedan att kopiera operationer från listan som tillhandahålls, i det här fallet oploggen, och köra dem så att den resulterande datan är densamma som i Maskin A.

Som nämnts tidigare är det alltid viktigt att säkerställa hög tillgänglighet av data, särskilt i produktionsmiljön. Replikering kommer in för att hjälpa till genom att tillhandahålla dataredundans i olika Mongod-instanser. I händelse av dataförlust, eftersom kopior av samma data lagras i olika databaser på flera platser, är det lätt att återställa det i den befintliga.

Med många körande instanser skickas läs- och skrivoperationer från klienter till olika servrar och därför ökar bearbetningshastigheten. Den grundläggande strukturen för replikeringsprocessen visas nedan.

Ibland kanske den primära inte är tillgänglig till exempel på grund av internetavbrott eller tjänstavbrott. I det här fallet kommer replikuppsättningen att nominera en sekundär som primärnod. Så mycket som läsbegärandena i princip görs till den primära, vissa tillfällen kan läsbegäran skickas till sekundärerna, men var försiktig eftersom den returnerade datan kanske inte återspeglar vad som finns i den primära eller snarare informationen kanske inte är uppdaterad.

Arbiters

I fallet med val av ett primärval kommer du att behöva en extra mongod-instans till replikuppsättningen för att lägga till en röst i valprocessen. Denna instans hänvisas till som en arbiter och dess framträdande egenskaper är:

1. Den har inte en kopia av datamängden, och kräver därför inte lika kraftfull hårdvara som de databärande noderna.
2. Kan inte befordras till att bli primär.
3. De har alltid en elektorsröst för att tillåta replikuppsättningar att ha ett ojämnt antal röstberättigade medlemmar utan kostnaden för ytterligare en medlem som replikerar data. Dess avgörande roll är därför att välja en primär nod när den inte är tillgänglig.
4. Det förblir oförändrat.

I motsats till domaren kan andra replikuppsättningar konverteras till primära från sekundära och vice versa.

Asynkron replikering

Replikeringsprocessen sker i två former av datasynkronisering. Först fylls medlemmarna i uppsättningen med fullständiga data i den första synkroniseringen. Den efterföljande replikeringen äger rum för att tillämpa avancerade ändringar på hela datamängden.

I den första synkroniseringen kopieras data från en medlem av replikuppsättningen till en annan. När processen är klar övergår medlemmen till den sekundära noden.

MongoDB Automatic Failover

Det kan finnas ett tjänstavbrott som nätavbrott som kommer med en konsekvens av att kommunikationen mellan primär och sekundär avbryts. Om frånkopplingen är mer än 10 sekunder eller misslyckas helt, kommer den återstående replikuppsättningen att rösta för att en medlem ska bli den nya primära. Den sekundära noden som får majoriteten av rösterna blir den nya primära.

I version 3.0 av MongoDB kan en replikuppsättning ha upp till 50 medlemmar med 7 röstberättigade medlemmar.

Priority Zero Replica Set Members

Dessa är sekundära medlemmar som varken kan övergå till att vara primära noder eller utlösa ett val. Det avgörande rollerna i datamängden är att:underhålla datamängdskopior, välja en primär nod och utföra läsoperationer. De fungerar som en backup där en ny medlem kanske misslyckas med att lägga till omedelbart. Den kommer alltså att lagra den uppdaterade informationen och kan omedelbart ersätta en otillgänglig medlem.

MongoDB Hidden Replica Set Members

Dessa är medlemmar utan koppling till klientapplikationerna. De används för arbetsbelastningar med andra användningskrav än andra sekundära medlemmar. De tar bara emot den grundläggande replikeringstrafiken som är under den första synkroniseringen.

MongoDB Delayed Replica Set Members

Dessa kopierar data från den primära nodens oploggfil inom en viss tidsperiod. De återspeglar alltid det fördröjda tillståndet eller en tidigare form av uppsättningen. De är därför viktiga för att upptäcka fel och ger en fingervisning om hur man kan återhämta sig från de felen, till exempel om det finns en databas som har tappats. Vid val av förseningsmängd bör detta beaktas:

1. Längden bör vara kortare än kapaciteten för operationsloggen, som för lagringsmotorerna WiredTiger, MMAPv1 och In-Memory är 50 GB. Annars kan den fördröjda medlemmen inte replikera operationer.
2. Fördröjningens varaktighet bör vara lika med eller något längre än dina förväntade underhållsperioder.

Konfiguration

Detta är en noll-prioritetsmedlem, den är dold och är därför inte synlig för ansökningar och kan slutligen delta i valprocessen. För att konfigurera en prioritet, låt oss säga att du har 10 medlemmar i din replikuppsättning, kan du välja en medlem på position n som medlem[n] och ställa in dess egenskaper som:

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

Eller genom att använda mongoskalet som är anslutet till det primära kan du köra dessa kommandon för att ställa in den första medlemmen av replikuppsättningen som en fördröjd:

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

Efter att ha ställt in dessa konfigurationer kan den fördröjda sekundära inte bli en primär och därför dold från applikationer. Medlemmen kommer att försenas med 1 timme (3600 sekunder) från oplogoperationerna.

Hur startar ett replikset

I den här guiden ska vi se steg för steg hur vi kan konfigurera en replikuppsättning i MongoDB.

1. Låt oss säga att du har 3 mongodb som du vill replikera och de är konfigurerade enligt följande:
   1. Mongod1.conf körs vid port 27017
   2. Mongod2.conf körs vid port 27018
   3. Mongod3.conf körs vid port 27019

   Se till att lägga till replikuppsättningens namn som inte kommer att ändras i varje fil. Du kan göra det genom att lägga till eller ändra alternativet replSet-värdet till ett valfritt namn.

2. Vi kan starta den första instansen genom att köra

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

   Detta är om du inte har någon mongod-körningsinstans. Gör sedan samma sak för de andra instanserna. För att kontrollera om det finns körande instanser i din maskinkör

   ps -ax | grep mongo

   Du kommer att få en lista så här:

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

   Detta betyder att den första instansen i MongoDB som standard körs på port 27017, därför har vi den som den första i listan. Om du startade de andra, kommer de också att visas i listan med deras motsvarande sökvägsadresser. För att ansluta till en instans i mongo-skalet, kör det här kommandot:

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

   Men i vårt fall måste vi ansluta till ett replikuppsättningsnamn så vi måste lägga till ithe-namnet till kommandot:

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

   I det här fallet vår replicaSetName ="testrep"

3. Låt oss kontrollera om det finns någon replikuppsättning aktiverad genom att köra rs.status()

   Om du får ett resultat som:

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

   Då betyder det att ingen replikuppsättning är aktiverad. Annars om 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)
           }
       }
   }

   då betyder det att repliken inte är initierad ännu.

4. Metoden rs.initiate() hjälper oss att starta en ny replikuppsättning och instansen inom vilken den initieras blir vår primära nod. Så vi kan initiera en i vårt fall genom att köra initieringsmetoden. rs.initiate().

5. Kontrollera replikuppsättningens status igen genom att köra rs.status().members. Du bör nu se något liknande

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

   Bra att gå. Vårt intresse kommer att vara medlemsalternativet, eftersom vi kan se att det är en array med 1 medlem i den. Om du markerar den första medlemmens stateStr-alternativ i det här fallet är den inställd på Primary vilket betyder att detta kommer att fungera som vår primära nod.

6. Lägg till en ny medlem till replikuppsättningen med dess värdnamn. Kör

   för att leta efter värdnamnet för den anslutna instansen som du vill lägga till

   db.serverStatus().host

   Du kommer att få något liknande

   ervername.local:27019

   Så från PRIMÄR kan du lägga till ytterligare en medlem genom att köra detta kommando i mongo-skalet:

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

7. Kör statuskommandot

   rs.status().members

   För att kontrollera om ändringarna har gjorts.

   Du bör nu ha något som ser ut så här:

   [
       {
           "_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 medlemmar, en är en PRIMÄR nod och den andra är en SEKUNDÄR nod. Du kan lägga till fler medlemmar men inte överstiga 50. Låt oss nu skapa en databas i instansen på port 27018 som primär.

   

   Om vi ​​kopplar bort den primära kommer en failover att ske och eftersom vi bara har 1 primär kommer den automatiskt att övergå till en sekundär. Om vi ​​nu ansluter till den på port 27019 bör du få samma databaser och samlingar med deras dokument.

   

   Om nu den frånkopplade primära noden återansluts kommer den att läggas till som en sekundär när den kopierar operationer från oploggen för den befintliga primära.

MongoDB Replica Set Skriv oro

Om MongoDB returnerar ett lyckat journaliserat skrivproblem, kommer data att lagras på disken och blir därför tillgänglig efter att mongod startat om. Men för skrivoperationerna är data varaktiga först efter att de har replikerats och överförts till tidskriften till förmån för majoriteten av den röstberättigade medlemmen i replikuppsättningen.

Vissa data kan vara för stora för att uppdatera eller infoga, och därför kan det ta längre tid än förväntat för data att replikeras i andra medlemmar. Av denna anledning är det tillrådligt att redigera writeConcern-konfigurationerna för att ta hänsyn till den tid inom vilken en operation ska utföras. De förinställda writeConcern-konfigurationerna dikterar att replikuppsättningen endast kräver bekräftelse från den primära medlemmen. Ett standardskrivproblem bekräftar endast skrivoperationer för den primära men kan åsidosättas för att kontrollera skrivoperationer på vissa replikuppsättningsmedlemmar genom att specificera skrivproblemet för en specifik skrivoperation. Till exempel:

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

Skrivalternativet i det här fallet dikterar att operationen ska returnera ett svar först efter att det har spridits till den primära och minst 2 sekundära eller om den tar slut efter 3,6 sekunder.

Konfigurera skrivproblemet för MongoDB

Alternativet MongoDB getLastErrorDefaults ger oss parametrarna för att ändra standardinställningarna för skrivproblem i replikuppsättningens konfiguration. Detta innebär att operationen måste vara klar hos de flesta av de röstberättigade medlemmarna innan resultatet returneras.

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

Timeout-värdet kommer att förhindra blockering av skrivoperationer, det vill säga om det ska finnas 5 medlemmar för att bekräfta skrivproblemet men tyvärr finns det 4 eller färre medlemmar i replikuppsättningen, kommer operationen att blockeras tills alla medlemmar är tillgängliga. Genom att lägga till timeout-tröskeln kommer operationsblockeringen att kasseras efter denna varaktighet.

Replikeringsblockering

Blockering av en operation, särskilt när alla medlemmar har replikerats, säkerställer att ingen mer tid går till spillo på att vänta på att en annan replikuppsättningsmedlem ska vara tillgänglig för att returnera ett svar. MongoDB getLastError kommandoalternativ dikterar hur replikeringsuppdateringen görs med hjälp av det valfria "w"-attributet.

Till exempel den här frågan

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

kräver att blockeringen sker tills N antal medlemmar har replikerat den senaste skrivoperationen. Om N är tillgängligt eller är mindre än 2 kommer frågan att returneras. Annars, om värdet för N är lika med 2, svarar masterns ekvivalent med den primära, först efter att en av dess slavar har replikerats till den senaste operationen.

wtimeout parametern är i princip att ställa in tiden i millisekunder efter vilken getLastError-kommandot kommer att timeout och returnera ett fel innan det sista alternativet har replikerats.

Så mycket som att blockering på något sätt är fördelaktigt, har det ibland en begränsning. Det saktar avsevärt ner läsoperationerna, särskilt om du ställer in "w"-värdet för att vara för stort. Jag skulle rekommendera att du ställer in "w"-värdet till antingen 2 eller 3 för förbättrad säkerhet och effektivitet.

Läsinställningar i MongoDB

Detta är i princip den intilliggande vägen med vilken klientläsoperationerna görs till replikuppsättningen. Standardinställningen för MongoDB konfigurerar läsoperationerna till den primära eftersom det är den med den senaste versionen av dokumentet du hämtar. Som nämnts tidigare är den största fördelen med att utnyttja replikuppsättningen att förbättra prestandan hos vårt databassystem. Det är därför tillrådligt att distribuera läsoperationerna till många sekundära medlemmar för att minska latensen för applikationer som inte nödvändigtvis kräver uppdaterad data. Det finns dock mer avgörande skäl till varför du också bör använda den primära som din grundläggande preferens:

1. Upprätthålla datatillgänglighet under failover.
2. För geografiskt distribuerade applikationer kommer den primära att tillhandahålla lokala läsningar för klienter i samma datacenter.
3. För att inte påverka front-end-applikationerna, särskilt de som kör systemoperationer.

Mongo.setReadPref() Metod

Denna metod är i grunden för att definiera hur klienten ska dirigera alla frågor till medlemmar av replikuppsättningen. Det tar 2 argument, mode och tagSet.

Mode-argumentet anger läspreferensen som antingen kan vara primär, primärPrefererad, sekundär, sekundärPrefererad eller närmast.

TagSet-läget anger den anpassade läspreferensen. Du kan också ange dem som en array av objekt. Ett exempel på installationen är:

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

Vad som händer här är att om klienten försöker komma åt den första taggen och begäran inte går igenom, kommer de att väljas till den andra läspreferensen.

Läsinställningar

• Primär:detta definierar att alla läsoperationer som läses från en given replikuppsättning är primära och är standardinställningsläsläget.
• PrimaryPreferred:Om bara den primära inte är tillgänglig kan läsoperationerna göras från sekundärerna.
• Sekundär:alla läsoperationer görs från de sekundära medlemmarna i replikuppsättningen.
• SecondaryPreferred:om det bara inte finns någon sekundär tillgänglig kan läsoperationerna göras från den primära.
• Närmast:medlem med minsta nätverkslatens väljs för läsoperationen, oavsett typ.

Tagguppsättningar och deras konfiguration

Det här är alternativ som gör att du kan modellera hur du vill att din skrivoro och läspreferens ska se ut. De lagras i replikuppsättningens konfigurationsobjekt. Om du kör rs.conf().members kommer du att få detta objekt returnerat:

[
    {
        "_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 varje medlem tags-attribut.

Den största skillnaden mellan läsinställningar och skrivproblem är att den förra tar hänsyn till värdet av en tagg när man väljer en medlem att läsa från medan den senare inte gör det.

Låt oss säga att en tagguppsättning för en läsoperation är inställd på:

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

En medlem i replikuppsättningen måste uppfylla dessa taggar för att läsoperationen ska gå igenom. Därför att säga, en konfiguration som denna

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

kommer att tillfredsställa frågan medan den här

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

kommer inte att tillfredsställa frågan.

Lägga till taggar i en uppsättningsreplika

För din valda medlem i en replikuppsättning kan du lägga till tagguppsättningar med metoden rs.conf() i MongoDB.

Låt oss säga att du har valt en medlem i position 1 i din replikuppsättning, du kan lägga till tagguppsättningar enligt följande.

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önster för MongoDB Replica Set

1. Geografiskt distribuerad replikuppsättning - Förbättrar redundans för data förutom att skydda data mot fel som strömavbrott. De körande instanserna finns på flera platser.
2. Replikuppsättning med tre medlemmar - den grundläggande standardarkitekturen för en replikuppsättning.
3. Replikuppsättning med fyra eller fler medlemmar - möjliggör en bredare redundans av data och stöder även en bredare distribution av läsoperationer i replikuppsättningen.

MongoDB Replica Set Deployment Tuning Techniques

En idealisk replikuppsättning kräver en väl utformad arkitektur med minst 3 medlemmar för ett produktionssystem. Dessa distributionsstrategier hjälper dig att möjliggöra en fantastisk replikuppsättning.

1. Använd fördröjda och dolda medlemmar för att stödja dedikerade funktioner som rapportering och säkerhetskopiering.
2. Gör alltid antalet utplacerade medlemmar udda. Som vi har diskuterat ovan kommer ett udda antal ledamöter att krävas för att välja en primärval. Se därför till att du har ett udda nummer och om inte kan du alltid lägga till en domare.
3. För lästunga distributioner måste du balansera belastningen. Du kommer därför att behöva distribuera läsningar till sekundären för att förbättra läsprestandan. Dessutom, när data växer med tiden kan du lägga till fler medlemmar och distribuera dem, men kom ihåg att du måste konfigurera den på ett sådant sätt att den viktigaste designen är att välja den primära.
4. Tänk alltid på feltolerans. Detta avgör i princip hur många medlemmar som kan vara otillgängliga vid en given tidpunkt och hur många som kommer att finnas kvar för att upprätthålla valprocessen i ett primärval. Om du inte har en primär, accepterar replikuppsättningen tyvärr inte någon skrivoperation.
5. Lägg till nya medlemmar till den befintliga replikuppsättningen innan efterfrågan uppstår.
6. Använd replikuppsättningstaggar för att säkerställa att alla operationer replikeras vid specifika datacenter. Du kan också använda dessa taggar i routing för läsoperationerna för specifika distributionsmaskiner.
7. Distribuera de flesta av dina medlemmar på en plats för att undvika det bakslag som kommer att uppstå från nätverkspartitionering. Nätverkspartitionering kan vara resultatet av frånkopplad kommunikation mellan datacenter, vilket hindrar replikeringsprocessen och processen att välja en primär.
8. Av säkerhetsskäl, fördela dina medlemmar geografiskt förutom att göra några dolda. Du kan ställa in minst 2 eller 3 medlemmars prioritet till noll för att förhindra att de blir primära.
9. Använd journalföring för att skydda dataförlust som kan leda till något som strömavbrott. Detta säkerställer att data skrivs till disken i händelse av plötslig avstängning.

Operationsloggen (Oplog)

Oploggen upprätthåller ett register över masteroperationerna som ska tillämpas på slavarna. Den lagras i en databas som heter local i oplog.$main collection. Den skapas när du startar en replikuppsättningsmedlem för första gången. På den övre gränsen är oploggen begränsad till en storlek på 50 GB för alla lagringsmotorer. Oplogstorleken kan ändras från en standardinställning. Om denna storlek uppnås till exempel inom 24 timmars drift, kommer sekundärerna inte att kunna kopiera från den under denna tid bekvämt och kan sluta med att de inte kopierar alls. Du kan ändra storleken på oploggen med alternativet replSetResizeOplog, dvs.

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

Om du ska minska storleken på den här oploggen kommer det att resultera i att en del data tas bort. Kärneffekten av detta i replikuppsättningen är att medlemmar som synkroniseras med denna nod blir inaktuella. Därför måste du synkronisera om dessa medlemmar.

Arbetsbelastningsmönster som skulle kräva en stor Oplog-storlek

1. Uppdatera till flera dokument samtidigt. De multipla uppdateringsoperationerna måste översättas till en individuell operation för att förbättra resultaten över noderna. Denna operation kommer att använda ett stort utrymme av oplogutrymmet.
2. Betydligt antal uppdateringar på plats. Detta händer vanligtvis när man uppdaterar data i dokument, vilket inte nödvändigtvis ökar storleken på detta dokument. Databasen kommer att registrera ett stort antal operationer till oploggen och ökar därmed dess storlek.
3. Raderingar motsvarar samma mängd data som infogar. Detta händer när du försöker radera en mängd data (nästan) lika med mängden data du infogar. Denna operation tenderar att öka storleken på oploggen.

Slutsats

Replikering är en viktig aspekt av databaser som utvecklare måste förstå. Det säkerställer ökad tillgänglighet av data. Din MongoDB-server kan gå ner, till exempel på grund av ett strömavbrott, men du vill fortfarande att dina klienter ska få tillgång till dess data. Om du har replikerat data på en annan server kommer dina klienter att kunna fortsätta att komma åt data från den om den primära servern misslyckas. Dessutom finns det en ökad lastbalansering så att istället för att alla användare har tillgång till en enda server har vi sett avvägningarna med att betjäna trafik från sekundära repliker.