MongoDB er en NoSQL-database, der bruger JSON-lignende dokumenter med dynamiske skemaer. Når du arbejder med databaser, er det altid godt at have en beredskabsplan, hvis en af dine databaseservere svigter. Sidebar, du kan reducere chancerne for at det sker ved at udnytte et smart administrationsværktøj til dit WordPress-websted.

Det er derfor, det er nyttigt at have mange kopier af dine data. Det reducerer også læseventetiderne. Samtidig kan det forbedre databasens skalerbarhed og tilgængelighed. Det er her, at replikering kommer ind i billedet. Det er defineret som praksis med at synkronisere data på tværs af flere databaser.

I denne artikel vil vi dykke ned i de forskellige fremtrædende aspekter af MongoDB replikering, som f.eks. dens funktioner og mekanisme, for blot at nævne et par stykker.

Hvad er replikering i MongoDB?

I MongoDB udfører replikasæt replikering. Dette er en gruppe af servere, der vedligeholder det samme datasæt gennem replikering. Du kan endda bruge MongoDB-replikering som en del af belastningsbalancering. Her kan du distribuere skrive- og læseoperationer på tværs af alle instanser, baseret på brugssituationen.

Hvad er et MongoDB-replikasæt?

Hver instans af MongoDB, der er en del af et givet replikasæt, er et medlem. Hvert replikasæt skal have et primært medlem og mindst ét sekundært medlem.

Det primære medlem er det primære adgangspunkt for transaktioner med replikasættet. Det er også det eneste medlem, der kan acceptere skriveoperationer. Replikation kopierer først den primære oplog (operationslog). Derefter gentages de loggede ændringer på de sekundære datasæt i de respektive datasæt. Derfor kan hvert replikasæt kun have ét primært medlem ad gangen. Forskellige primære, der modtager skriveoperationer, kan forårsage datakonflikter.

Normalt forespørger programmerne kun det primære medlem om skrive- og læseoperationer. Du kan udforme din opsætning til at læse fra et eller flere af de sekundære medlemmer. Asynkron dataoverførsel kan medføre, at sekundære noders læsning af sekundære nodepunkter serverer gamle data. Derfor er et sådant arrangement ikke ideelt for alle anvendelsestilfælde.

Funktioner i replikasæt

Den automatiske failover-mekanisme adskiller MongoDB’s replikasæt fra konkurrenterne. Hvis der ikke er en primær node, vælges der en ny primær node ved et automatisk valg blandt de sekundære nodepunkter.

MongoDB Replica Set vs MongoDB Cluster

Et MongoDB replikasæt vil oprette forskellige kopier af det samme datasæt på tværs af replikasætnoderne. Det primære formål med et replikasæt er at:

  • Tilbyde en indbygget backup-løsning
  • Øge tilgængeligheden af data

En MongoDB-klynge er en helt anden boldgade. Den fordeler dataene på mange nodepunkter via en shard-nøgle. Denne proces fragmenterer dataene i mange stykker, der kaldes shards. Derefter kopieres hver shard til en anden node. En klynge har til formål at understøtte store datasæt og operationer med høj gennemløbshastighed. Den opnår dette ved at skalere arbejdsbyrden horisontalt.

Her er forskellen mellem et replikasæt og en klynge i lægmandstermer:

  • En klynge fordeler arbejdsbyrden. Den gemmer også datafragmenter (shards) på mange servere.
  • Et replikasæt duplikerer datasættet fuldstændigt.

MongoDB giver dig mulighed for at kombinere disse funktionaliteter ved at lave en sharded cluster. Her kan du replikere hver shard til en sekundær server. Dette gør det muligt for en shard at tilbyde høj redundans og datatilgængelighed.

Vedligeholdelse og opsætning af et replikasæt kan være teknisk krævende og tidskrævende. Og at finde den rigtige hosting-tjeneste? Det er en helt anden hovedpine. Med så mange muligheder derude er det let at spilde timer på at undersøge, i stedet for at opbygge din virksomhed.

Lad mig give dig en kort beskrivelse af et værktøj, der gør alt dette og meget mere, så du kan vende tilbage til at knuse det med din service/dit produkt.

Kinsta’s Applikation Hosting-løsning, som er betroet af over 55.000 udviklere, kan du komme i gang med den i kun 3 enkle trin. Hvis det lyder for godt til at være sandt, så er her nogle flere fordele ved at bruge Kinsta:

  • Nyd bedre ydeevne med Kinstas interne forbindelser: Glem dine problemer med delte databaser. Skift til dedikerede databaser med interne forbindelser, der ikke har nogen begrænsninger for antal forespørgsler eller antal rækker. Kinsta er hurtigere, mere sikker og vil ikke fakturere dig for intern båndbredde/trafik.
  • Et funktionssæt, der er skræddersyet til udviklere: Skaler din applikation på den robuste platform, der understøtter Gmail, YouTube og Google Search. Du kan være sikker på, at du er i de sikreste hænder her.
  • Nyd uovertrufne hastigheder med et datacenter efter eget valg: Vælg den region, der fungerer bedst for dig og dine kunder. Med over 25 datacentre at vælge imellem sikrer Kinsta’s 260+ PoP’er maksimal hastighed og global tilstedeværelse for dit websted.

Prøv Kinsta’s applikationshostingløsning gratis i dag!

Hvordan fungerer replikering i MongoDB?

I MongoDB sender du skriveoperationer til den primære server (node). Den primære tildeler operationerne på tværs af sekundære servere og replikerer dataene.

Dette er et flowdiagram over, hvordan replikering fungerer i MongoDB, for 3 noder (1 primær, 2 sekundær)
Illustration af MongoDB-replikeringsprocessen (Billedkilde: MongoDB)

Tre typer af MongoDB-noder

Af de tre typer MongoDB-nodes er der to, der er blevet nævnt før: primære og sekundære nodepunkter. Den tredje type MongoDB-node, der er praktisk under replikering, er en arbiter. Arbiternoden har ikke en kopi af datasættet og kan ikke blive en primær node. Når det er sagt, deltager arbiteren dog i valget af primærnoder.

Vi har tidligere nævnt, hvad der sker, når den primære node går ned, men hvad nu hvis de sekundære nodes bidte i støvet? I det scenarie bliver den primære nodes sekundær, og databasen bliver utilgængelig.

Valg af medlemmer

Valgene kan finde sted i følgende scenarier:

  • Initialisering af et replikasæt
  • Tab af forbindelse til den primære node (som kan registreres ved hjælp af hjerteslag)
  • Vedligeholdelse af et replikasæt ved hjælp af metoderne rs.reconfig eller stepDown
  • Tilføjelse af en ny node til et eksisterende replikasæt

Et replikasæt kan have op til 50 medlemmer, men kun 7 eller færre kan stemme i et valg.

Den gennemsnitlige tid, før en klynge vælger en ny primær vælger, bør ikke overstige 12 sekunder. Valgalgoritmen vil forsøge at have den sekundære med den højeste prioritet til rådighed. Samtidig kan medlemmer med en prioritetsværdi på 0 ikke blive primære og deltager ikke i valget.

Dette er et diagram, der viser en sekundær node, der bliver en primær i MongoDB efter valget.
Sekundær node bliver primær (Billedkilde: Medium)

Den skriftlige bekymring

Af hensyn til holdbarheden har skriveoperationer en ramme til at kopiere dataene i et bestemt antal nodes. Du kan endda tilbyde feedback til klienten med dette. Denne ramme er også kendt som “write concern” Den har datagivende medlemmer, der skal kvittere for en write concern, før operationen vender tilbage som vellykket. Generelt har replikasættene en værdi på 1 som en write concern. Det er således kun det primære sæt, der skal bekræfte skrivningen, før der returneres en bekræftelse af skrivehensyn.

Du kan endda øge antallet af medlemmer, der er nødvendige for at bekræfte skriveoperationen. Der er ikke noget loft over det antal medlemmer, du kan have. Men hvis antallet er højt, skal du tage højde for en høj latenstid. Det skyldes, at klienten skal vente på bekræftelse fra alle medlemmerne. Du kan også indstille skrivehensynet for “flertallet”. Dette beregner mere end halvdelen af medlemmerne efter at have modtaget deres bekræftelse.

Læsepræference

For læseoperationer kan du nævne læsepræferencen, som beskriver, hvordan databasen dirigerer forespørgslen til medlemmerne af replikasættet. Generelt modtager den primære node læseoperationen, men klienten kan angive en læsepræference for at sende læseoperationer til sekundære nodes. Her er mulighederne for læsepræferencen:

  • primaryPreferred: Normalt kommer læseoperationerne fra den primære node, men hvis denne ikke er tilgængelig, trækkes dataene fra de sekundære nodes.
  • primary: Alle læseoperationer kommer fra den primære node.
  • secondary: Alle læseoperationer udføres af de sekundære nodepunkter.
  • nærmeste: Her dirigeres læseforespørgslerne til den nærmeste tilgængelige node, som kan registreres ved at køre kommandoen ping. Resultatet af læseoperationer kan komme fra et hvilket som helst medlem af replikasættet, uanset om det er den primære eller den sekundære node.
  • secondaryPreferred: Her kommer de fleste læseoperationer fra de sekundære noddepunkter, men hvis ingen af dem er tilgængelige, tages dataene fra den primære noddepunkt.

Datasynkronisering af replikeringssæt

For at opretholde ajourførte kopier af det delte datasæt replikerer eller synkroniserer sekundære medlemmer af et replikasæt data fra andre medlemmer for at opretholde opdaterede kopier af det delte datasæt.

MongoDB udnytter to former for datasynkronisering. Initial synkronisering for at fylde nye medlemmer med det fulde datasæt. Replikation for at udføre løbende ændringer i det komplette datasæt.

Oprindelig synkronisering

Under den indledende synkronisering kører en sekundær node kommandoen init sync for at synkronisere alle data fra den primære node til en anden sekundær node, der indeholder de nyeste data. Derfor udnytter den sekundære node konsekvent tailable cursor -funktionen til at forespørge de seneste oplogposter i local.oplog.rs-samlingen for den primære node og anvender disse operationer i disse oplogposter.

Fra MongoDB 5.2 kan indledende synkroniseringer være baseret på filkopiering eller logiske.

Logisk synkronisering

Når du udfører en logisk synkronisering, vil MongoDB:

  1. Udvikler alle samlingsindekser, efterhånden som dokumenterne kopieres for hver samling.
  2. Duplikerer alle databaser undtagen den lokale database. mongod scanner hver samling i alle kildedatabaser og indsætter alle data i sine duplikker af disse samlinger.
  3. Udfører alle ændringer i datasættet. Ved at udnytte oploggen fra kilden opgraderer mongod sit datasæt til at skildre replikasættets aktuelle tilstand.
  4. Udvinder de nyligt tilføjede oplogposter under datakopieringen. Sørg for, at målmedlemmet har tilstrækkelig diskplads i den lokale database til midlertidigt at gemme disse oplogposter i denne datakopieringsfase.

Når den første synkronisering er afsluttet, overgår medlemmet fra STARTUP2 til SECONDARY .

Første synkronisering baseret på filkopiering

Lige fra starten kan du kun udføre dette, hvis du bruger MongoDB Enterprise. Denne proces kører den indledende synkronisering ved at duplikere og flytte filerne på filsystemet. Denne synkroniseringsmetode kan i nogle tilfælde være hurtigere end logisk indledende synkronisering. Husk på, at filkopibaseret indledende synkronisering kan føre til unøjagtige tællinger, hvis du kører count()-metoden uden et forespørgselsprædikat.

Men denne metode har også sin del af begrænsninger:

  • Under en filkopibaseret indledende synkronisering kan du ikke skrive til den lokale database for det medlem, der synkroniseres. Du kan heller ikke køre en sikkerhedskopi på det medlem, der synkroniseres til, eller det medlem, der synkroniseres fra.
  • Når MongoDB udnytter den krypterede lagringsmotor, bruger MongoDB kildenøglen til at kryptere destinationen.
  • Du kan kun køre en indledende synkronisering fra ét givet medlem ad gangen.

Replikering

Sekundære medlemmer replikerer data konsekvent efter den første synkronisering. Sekundære medlemmer duplikerer oploggen fra deres synkronisering fra kilden og udfører disse operationer i en asynkron proces.

Sekundære medlemmer er i stand til automatisk at ændre deres synkronisering fra kilden efter behov på grundlag af ændringer i ping-tiden og status for andre medlemmers replikering.

Streaming-replikation

Fra MongoDB 4.4 sender synkronisering fra kilder en kontinuerlig strøm af oplogposter til deres synkroniserende sekundære enheder. Streaming replikation reducerer replikationsforsinkelsen i netværk med høj belastning og høj latenstid. Det kan også:

  • Mindske risikoen for at miste skriveoperationer med w:1 på grund af primær failover.
  • Mindske stoleness for læsninger fra sekundære filer.
  • Reducere ventetiden på skriveoperationer med w:“majority” og w:>1. Kort sagt, enhver skriveopgave, der kræver ventetid på replikering.
Multithreaded replikation

MongoDB plejede at skrive operationer i batches gennem flere tråde for at forbedre samtidigheden. MongoDB grupperer batcherne efter dokument-id, mens hver gruppe af operationer anvendes af en anden tråd.

MongoDB udfører altid skriveoperationer på et givet dokument i den oprindelige skriveorden. Dette blev ændret i MongoDB 4.0.

Fra MongoDB 4.0 vil læseoperationer, der var rettet mod sekundære filer og er konfigureret med et læsesikringsniveau på “majority” eller “local”, nu læse fra et WiredTiger-snapshot af dataene, hvis læsningen sker på en sekundær fil, hvor replikeringssatserne anvendes. Læsning fra et øjebliksbillede garanterer en konsistent visning af dataene og gør det muligt at læse samtidigt med den igangværende replikering uden at have brug for en lås.

Derfor behøver sekundære læsninger, der har brug for disse læsesorgensniveauer, ikke længere at vente på, at replikationsbatches anvendes, og kan håndteres, når de modtages.

Sådan oprettes et MongoDB-repliksæt

Som tidligere nævnt håndterer MongoDB replikation gennem replikasæt. I løbet af de næste par afsnit vil vi fremhæve et par metoder, som du kan bruge til at oprette replikasæt til dit brugsscenarie.

Metode 1: Oprettelse af et nyt MongoDB-repliksæt på Ubuntu

Før vi går i gang, skal du sikre dig, at du har mindst tre servere, der kører Ubuntu 20.04, med MongoDB installeret på hver server.

For at oprette et replikasæt er det vigtigt at angive en adresse, hvor hvert replikasætmedlem kan nås af de andre i sættet. I dette tilfælde har vi tre medlemmer i sættet. Selv om vi kan bruge IP-adresser, anbefales det ikke, da adresserne kan ændres uventet. Et bedre alternativ kan være at bruge de logiske DNS-hostnavne, når replikasæt konfigureres.

Vi kan gøre dette ved at konfigurere underdomænet for hvert replikationsmedlem. Selv om dette kan være ideelt for et produktionsmiljø, vil dette afsnit skitsere, hvordan man konfigurerer DNS-opløsning ved at redigere hver servers respektive hosts-filer. Denne fil giver os mulighed for at tildele læsbare værtsnavne til numeriske IP-adresser. Hvis din IP-adresse ændres, skal du således blot opdatere hosts-filerne på de tre servere i stedet for at omkonfigurere replikasættet fra bunden!

For det meste er hosts gemt i mappen /etc/. Gentag nedenstående kommandoer for hver af dine tre servere:

sudo nano /etc/hosts

I ovenstående kommando bruger vi nano som vores teksteditor, men du kan bruge en hvilken som helst teksteditor, som du foretrækker. Efter de første par linjer, som konfigurerer localhost, skal du tilføje en post for hvert medlem af replikasættet. Disse poster har form af en IP-adresse efterfulgt af et menneskeligt læsbart navn efter eget valg. Du kan navngive dem, som du vil, men sørg for at være beskrivende, så du kan skelne mellem hvert enkelt medlem. I denne vejledning vil vi bruge nedenstående hostsnavne:

  • mongo0.replset.member
  • mongo1.replset.member
  • mongo2.replset.member

Med disse værtsnavne vil dine /etc/hosts-filer ligne følgende markerede linjer:

Dette er et snapshot af /etc/hosts-filerne, der indeholder værtsnavnene sammen med IP-adressen.
Værtsnavne Illustration

Gem og luk filen.

Når vi har konfigureret DNS-opløsningen for replikasættet, skal vi opdatere firewallreglerne, så de kan kommunikere med hinanden. Kør følgende ufw -kommando på mongo0 for at give mongo1 adgang til port 27017 på mongo0:

sudo ufw allow from mongo1_server_ip to any port 27017

I stedet for parameteren mongo1_server_ip skal du indtaste din mongo1-serverens faktiske IP-adresse. Hvis du har opdateret Mongo-instansen på denne server til at bruge en anden port end standardporten, skal du også sørge for at ændre 27017 til at afspejle den port, som din MongoDB-instans bruger.

Tilføj nu en anden firewallregel for at give mongo2 adgang til den samme port:

sudo ufw allow from mongo2_server_ip to any port 27017

I stedet for parameteren mongo2_server_ip skal du indtaste din mongo2-serverens faktiske IP-adresse. Opdater derefter firewallreglerne for dine to andre servere. Kør følgende kommandoer på mongo1-serveren, og sørg for at ændre IP-adresserne i stedet for parameteren server_ip, så de afspejler IP-adresserne for henholdsvis mongo0 og mongo2:

sudo ufw allow from mongo0_server_ip to any port 27017
sudo ufw allow from mongo2_server_ip to any port 27017

Til sidst skal du køre disse to kommandoer på mongo2. Igen skal du sørge for, at du indtaster de korrekte IP-adresser for hver server:

sudo ufw allow from mongo0_server_ip to any port 27017
sudo ufw allow from mongo1_server_ip to any port 27017

Dit næste skridt er at opdatere hver MongoDB-instans’ konfigurationsfil for at tillade eksterne forbindelser. For at tillade dette skal du ændre konfigurationsfilen på hver server, så den afspejler IP-adressen og angiver replikasættet. Selv om du kan bruge enhver foretrukken teksteditor, bruger vi igen nano teksteditor. Lad os foretage følgende ændringer i hver mongod.conf-fil.

På mongo0:

# network interfaces
net:
port: 27017
bindIp: 127.0.0.1,mongo0.replset.member# replica set
replication:
replSetName: "rs0"

På mongo0: På mongo1:

# network interfaces
net:
port: 27017
bindIp: 127.0.0.1,mongo1.replset.member
replication:
replSetName: "rs0"

På mongo2:

# network interfaces
net:
port: 27017
bindIp: 127.0.0.1,mongo2.replset.member
replication:
replSetName: "rs0"
sudo systemctl restart mongod

Dermed har du aktiveret replikering for hver serveres MongoDB-instans.

Du kan nu initialisere replikasættet ved hjælp af metoden rs.initiate(). Denne metode skal kun udføres på en enkelt MongoDB-instans i replikasættet. Sørg for, at replikasættets navn og medlem svarer til de konfigurationer, du tidligere har foretaget i hver konfigurationsfil.

rs.initiate(
  {
    _id: "rs0",
    members: [
      { _id: 0, host: "mongo0.replset.member" },
      { _id: 1, host: "mongo1.replset.member" },
      { _id: 2, host: "mongo2.replset.member" }
    ]
  }
)

Hvis metoden returnerer “ok”: 1 i output, betyder det, at replikasættet blev startet korrekt. Nedenfor er et eksempel på, hvordan output skal se ud:

 "ok": 1,
  "$clusterTime": {
    "clusterTime": Timestamp(1612389071, 1),
    "signature": {
      "hash": BinData(0, "AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
      "keyId": NumberLong(0)
    }
  },
  "operationTime": Timestamp(1612389071, 1)
}

Shut Down MongoDB Server

Du kan lukke en MongoDB-server ned ved at bruge metoden db.shutdownServer(). Nedenfor er syntaksen for det samme. Både force og timeoutsecs er valgfrie parametre.

db.shutdownServer({
  force: <boolean>,
  timeoutSecs: <int>
})

Denne metode kan mislykkes, hvis mongod-replikasætmedlemmet kører visse operationer som indeksopbygninger. For at afbryde operationerne og tvinge medlemmet til at lukke ned, kan du indtaste den boolske parameter force til true.

Genstart MongoDB med –replSet

For at nulstille konfigurationen skal du sørge for, at alle ndoes i dit replikasæt er stoppet. Slet derefter den lokale database for hver node. Start den igen med flaget –replSet, og kør rs.initiate() på kun én mongod-instans for replikasættet.

mongod --replSet "rs0"

rs.initiate() kan tage et valgfrit replikasætkonfigurationsdokument, nemlig:

  • Indstillingen Replication.replSetName eller —replSet til at angive replikasætnavnet i feltet _id.
  • Arrayet “members”, som indeholder et dokument for hvert replikasætmedlem.

Metoden rs.initiate() udløser et valg og vælger et af medlemmerne til at være det primære.

Tilføj medlemmer til replikasættet

Hvis du vil tilføje medlemmer til sættet, skal du starte mongod-instanser på forskellige maskiner. Start derefter en mongo-klient og brug kommandoen rs.add().

Kommandoen rs.add() har følgende grundlæggende syntaks:

rs.add(HOST_NAME:PORT)

For eksempel,

Antag, at mongo1 er din mongod-instans, og at den lytter på port 27017. Brug Mongo-klientkommandoen rs.add() til at tilføje denne instans til replikasættet.

rs.add("mongo1:27017")

Først når du har forbindelse til den primære node, kan du tilføje en mongod-instans til replikasættet. Du kan kontrollere, om du har forbindelse til den primære, ved at bruge kommandoen db.isMaster().

Fjern medlemmer

For at fjerne et medlem kan vi bruge rs.remove()

For at gøre det skal du først lukke den mongod-instans, du ønsker at fjerne, ned ved hjælp af den db.shutdownServer() metode, som vi diskuterede ovenfor.

Derefter skal du oprette forbindelse til replikasættets nuværende primære. For at bestemme den aktuelle primære skal du bruge db.hello(), mens du har forbindelse til et medlem af replikasættet. Når du har fundet den primære, skal du køre en af følgende kommandoer:

rs.remove("mongodb-node-04:27017")
rs.remove("mongodb-node-04")
This is a snapshot of the output after carrying out the rs.remove() command.
Ovenstående billede viser, at node er blevet fjernet fra replikasættet med succes. (Billedkilde: Bmc)

Hvis replikasættet skal vælge en ny primær, kan MongoDB afbryde shell’en kortvarigt. I dette scenarie vil den automatisk genforbinde igen. Den kan også vise en fejl DBClientCursor::init call() failed error, selv om kommandoen lykkes.

Metode 2: Konfigurering af et MongoDB-repliksæt til implementering og test

Generelt kan du konfigurere replikasæt til testning enten med RBAC aktiveret eller deaktiveret. I denne metode vil vi opsætte replikasæt med adgangskontrol deaktiveret for at distribuere det i et testmiljø.

Først skal du oprette mapper for alle de instanser, der er en del af replikasættet, ved hjælp af følgende kommando:

mkdir -p /srv/mongodb/replicaset0-0  /srv/mongodb/replicaset0-1 /srv/mongodb/replicaset0-2

Denne kommando vil oprette mapper for tre MongoDB-instanser replicaset0-0, replicaset0-1 og replicaset0-2. Start nu MongoDB-instanserne for hver af dem ved hjælp af følgende sæt kommandoer:

For Server 1:

mongod --replSet replicaset --port 27017 --bind_ip localhost,<hostname(s)|ip address(es)> --dbpath /srv/mongodb/replicaset0-0  --oplogSize 128

For Server 2: For Server 1: For Server 2:

mongod --replSet replicaset --port 27018 --bind_ip localhost,<hostname(s)|ip address(es)> --dbpath /srv/mongodb/replicaset0-0  --oplogSize 128

For Server 3:

mongod --replSet replicaset --port 27019 --bind_ip localhost,<hostname(s)|ip address(es)> --dbpath /srv/mongodb/replicaset0-0  --oplogSize 128

Parameteren –oplogSize bruges til at forhindre, at maskinen bliver overbelastet i testfasen. Den er med til at reducere den mængde diskplads, som hver disk bruger.

Opret nu forbindelse til en af instanserne ved hjælp af Mongo-skallen ved at oprette forbindelse ved hjælp af nedenstående portnummer.

mongo --port 27017

Vi kan bruge kommandoen rs.initiate() til at starte replikeringsprocessen. Du skal erstatte parameteren hostname med dit systemnavn.

rs conf = {

  _id: "replicaset0",

  members: [

    {  _id: 0,  host: "<hostname>:27017},

    {  _id: 1,  host: "<hostname>:27018"},

    {  _id: 2,  host: "<hostname>:27019"}

   ] }

Du kan nu sende konfigurationsobjektfilen som parameter for initiate-kommandoen og bruge den på følgende måde:

rs.initiate(rsconf)

Og der har du det! Du har med succes oprettet et MongoDB-repliksæt til udviklings- og testformål.

Metode 3: Omdannelse af en standalone-instans til et MongoDB-repliksæt

MongoDB giver sine brugere mulighed for at omdanne deres standalone-instanser til replikasæt. Mens standalone-instanser for det meste bruges til test- og udviklingsfasen, er replikasæt en del af produktionsmiljøet.

For at komme i gang, skal vi lukke vores mongod-instans ned med følgende kommando:

db.adminCommand({"shutdown":"1"})

Genstart din instans ved at bruge parameteren –repelSet i din kommando til at angive det replikasæt, du vil bruge:

mongod --port 27017 – dbpath /var/lib/mongodb  --replSet replicaSet1 --bind_ip localhost,<hostname(s)|ip address(es)>

Du skal angive navnet på din server sammen med den unikke adresse i kommandoen.

Opret forbindelse til shell’en med din MongoDB-instans, og brug initiate-kommandoen til at starte replikeringsprocessen og konvertere instansen til et replikasæt med succes. Du kan udføre alle de grundlæggende operationer som f.eks. tilføjelse eller fjernelse af en instans ved hjælp af følgende kommandoer:

rs.add(“<host_name:port>”)
rs.remove(“host-name”)

Du kan desuden kontrollere status for dit MongoDB-repliksæt ved hjælp af kommandoerne rs.status() og rs.conf().

Metode 4: MongoDB Atlas – et enklere alternativ

Replikering og sharding kan arbejde sammen for at danne noget, der kaldes en sharded cluster. Mens opsætning og konfiguration kan være ret tidskrævende, om end ukompliceret, er MongoDB Atlas et bedre alternativ end de førnævnte metoder.

Det automatiserer dine replikasæt, hvilket gør processen nem at implementere. Den kan implementere globalt shardede replikasæt med få klik, hvilket muliggør disaster recovery, nemmere administration, datalokalitet og multiregionale implementeringer.

I MongoDB Atlas skal vi oprette klynger – de kan enten være et replikasæt eller en sharded klynge. For et bestemt projekt er antallet af nodes i en klynge i andre regioner begrænset til i alt 40 nodes.

Dette udelukker de gratis eller delte klynger og Google cloud-regionerne, der kommunikerer med hinanden. Det samlede antal nodes mellem to regioner skal overholde denne begrænsning. Hvis der f.eks. er et projekt, hvor f.eks:

  • Region A har 15 nodepunkter.
  • Region B har 25 nodes
  • Region C har 10 nodes

Vi kan kun tildele 5 nodes mere til region C, da,

  1. Region A+ Region B = 40; opfylder begrænsningen om, at 40 er det maksimalt tilladte antal nodes.
  2. Region B+ Region C = 25+10+5 (yderligere nodes tildelt C) = 40; opfylder begrænsningen om, at 40 er det maksimalt tilladte antal nodes.
  3. Region A+ Region C = 15+10+5 (yderligere nodes tildelt C) = 30; opfylder begrænsningen om, at 40 er det maksimalt tilladte antal nodes.

Hvis vi tildeler 10 nodes mere til region C, så region C får 20 nodes, er region B + region C = 45 nodess. Dette ville overskride den givne begrænsning, så du kan muligvis ikke oprette en klynge med flere regioner.

Når du opretter en klynge, opretter Atlas en netværkscontainer i projektet for cloududbyderen, hvis den ikke var der tidligere. Hvis du vil oprette en replikasætklynge i MongoDB Atlas, skal du køre følgende kommando i Atlas CLI:

atlas clusters create [name] [options]

Sørg for at angive et beskrivende klyngenavn, da det ikke kan ændres, efter at klyngen er oprettet. Argumentet kan indeholde ASCII-bogstaver, tal og bindestreger.

Der er flere muligheder for klyngeoprettelse i MongoDB baseret på dine krav. Hvis du f.eks. ønsker kontinuerlig cloud-backup for din klynge, skal du indstille --backup til true.

Håndtering af replikeringsforsinkelse

Replikeringsforsinkelse kan være ret afskrækkende. Det er en forsinkelse mellem en operation på den primære og anvendelsen af denne operation fra oplog til den sekundære. Hvis din virksomhed beskæftiger sig med store datasæt, forventes en forsinkelse inden for en vis tærskel. Nogle gange kan eksterne faktorer dog også bidrage og øge forsinkelsen. For at få gavn af en opdateret replikering skal du sikre dig, at:

  1. Du dirigerer din netværkstrafik i en stabil og tilstrækkelig båndbredde. Netværkslatens spiller en stor rolle i forhold til at påvirke din replikation, og hvis netværket ikke er tilstrækkeligt til at imødekomme replikationsprocessens behov, vil der opstå forsinkelser i replikationen af data i hele replikasættet.
  2. Du har en tilstrækkelig diskgennemstrømning. Hvis filsystemet og diskenheden på den sekundære ikke er i stand til at skylle data til disken lige så hurtigt som den primære, vil den sekundære have svært ved at følge med. Derfor behandler de sekundære nodes skriveforespørgsler langsommere end den primære node. Dette er et almindeligt problem i de fleste systemer med flere lejere, herunder virtualiserede instanser og implementeringer i stor skala.
  3. Du anmoder om en skrivebekræftelse skrivebekræftelse efter et interval for at give sekundære nodepunkter mulighed for at indhente den primære, især når du ønsker at udføre en bulk load-operation eller dataindlæsning, der kræver et stort antal skrivninger til den primære nodepunkt. De sekundære enheder vil ikke være i stand til at læse uploggen hurtigt nok til at følge med i ændringerne; især ikke med ubekræftede skriveinteresser.
  4. Du identificerer de kørende baggrundsopgaver. Visse opgaver som f.eks. cronjobs, serveropdateringer og sikkerhedskontroller kan have uventede virkninger på netværks- eller diskforbruget og forårsage forsinkelser i replikeringsprocessen.

Hvis du er usikker på, om der er en replikeringsforsinkelse i dit program, skal du ikke bekymre dig – i næste afsnit diskuteres fejlfindingsstrategier!

Fejlfinding af MongoDB replikasæt

Du har opsat dine replikasæt med succes, men du bemærker, at dine data er inkonsistente på tværs af serverne. Dette er stærkt alarmerende for store virksomheder, men med hurtige fejlfindingsmetoder kan du finde årsagen eller endda rette op på problemet! Nedenfor er angivet nogle almindelige strategier til fejlfinding af replikasæt-implementeringer, som kan være nyttige:

Kontroller replikatstatus

Vi kan kontrollere replikasættets aktuelle status og status for hvert medlem ved at køre følgende kommando i en mongosh-session, der er forbundet med et replikasætets primære.

 rs.status()

Kontroller replikationsforsinkelsen

Som tidligere omtalt kan replikationsforsinkelse være et alvorligt problem, da det gør “forsinkede” medlemmer uegnet til hurtigt at blive primære og øger muligheden for, at distribuerede læseoperationer vil være inkonsistente. Vi kan kontrollere den aktuelle længde af replikationsloggen ved at bruge følgende kommando:

rs.printSecondaryReplicationInfo()

Dette returnerer værdien syncedTo, som er det tidspunkt, hvor den sidste oplogpost blev skrevet til den sekundære for hvert medlem. Her er et eksempel til at demonstrere det samme:

source: m1.example.net:27017
    syncedTo: Mon Oct 10 2022 10:19:35 GMT-0400 (EDT)
    0 secs (0 hrs) behind the primary
source: m2.example.net:27017
    syncedTo: Mon Oct 10 2022 10:19:35 GMT-0400 (EDT)
    0 secs (0 hrs) behind the primary

Et forsinket medlem kan vises som 0 sekunder bagud i forhold til det primære, når inaktivitetsperioden på det primære er større end members[n].secondaryDelaySecs -værdien.

Test af forbindelserne mellem alle medlemmer

Hvert medlem af et replikasæt skal kunne oprette forbindelse med alle andre medlemmer. Sørg altid for at verificere forbindelserne i begge retninger. For det meste forhindrer firewallkonfigurationer eller netværkstopologier normale og nødvendige forbindelser, hvilket kan blokere replikering.

Lad os f.eks. antage, at mongod-instansen binder sig til både localhost og hostname “ExampleHostname”, som er forbundet med IP-adressen 198.41.110.1:

mongod --bind_ip localhost, ExampleHostname

For at oprette forbindelse til denne instans skal fjernklienter angive værtsnavnet eller IP-adressen for at oprette forbindelse til denne instans:

mongosh --host ExampleHostname
mongosh --host 198.41.110.1

Hvis et replikasæt består af tre medlemmer, m1, m2 og m3, der bruger standardport 27017, skal du teste forbindelsen som nedenfor:

På m1:

mongosh --host m2 --port 27017
mongosh --host m3 --port 27017

På m2:

mongosh --host m1 --port 27017
mongosh --host m3 --port 27017

På m3:

mongosh --host m1 --port 27017
mongosh --host m2 --port 27017

Hvis en forbindelse i en hvilken som helst retning mislykkes, skal du kontrollere din firewallkonfiguration og omkonfigurere den, så den tillader forbindelserne.

Sikring af sikker kommunikation med nøglefilgodkendelse

Som standard er nøglefilsautentificering i MongoDB baseret på den saltet udfordringssvarsautentificeringsmekanisme (SCRAM). For at gøre dette skal MongoDB læse og validere brugerens angivne legitimationsoplysninger, der omfatter en kombination af brugernavn, adgangskode og den godkendelsesdatabase, som den specifikke MongoDB-instans er bekendt med. Dette er den nøjagtige mekanisme, der bruges til at autentificere brugere, der angiver en adgangskode, når de opretter forbindelse til databasen.

Når du aktiverer autentificering i MongoDB, aktiveres RBAC (Role-Based Access Control) automatisk for replikasættet, og brugeren tildeles en eller flere roller, som bestemmer deres adgang til databasens ressourcer. Når RBAC er aktiveret, betyder det, at kun den gyldige autentificerede Mongo-bruger med de relevante rettigheder vil kunne få adgang til ressourcerne på systemet.

Nøglefilen fungerer som en delt adgangskode for hvert medlem i klyngen. Dette gør det muligt for hver mongod-instans i replikasættet at bruge indholdet af nøglefilen som den delte adgangskode til at autentificere andre medlemmer i implementeringen.

Kun de mongod-instanser, der har den korrekte nøglefil, kan deltage i replikasættet. En nøgles længde skal være mellem 6 og 1024 tegn og må kun indeholde tegn i base64-sættet. Bemærk, at MongoDB fjerner whitespace-tegn, når nøgler læses.

Du kan generere en nøglefil ved hjælp af forskellige metoder. I denne vejledning bruger vi openssl til at generere en kompleks 1024-vilkårlig tegnstreng til brug som en delt adgangskode. Derefter bruges chmod til at ændre filtilladelser til kun at give læsetilladelser til filens ejer. Undgå at gemme nøglefilen på lagringsmedier, der let kan afbrydes fra den hardware, der er host for mongod-instanserne, f.eks. et USB-drev eller en netværkstilsluttet lagerenhed. Nedenfor er kommandoen til at generere en nøglefil:

openssl rand -base64 756 > <path-to-keyfile>
chmod 400 <path-to-keyfile>

Derefter kopieres nøglefilen til hvert replikasætmedlem. Sørg for, at den bruger, der kører mongod-instanserne, er ejer af filen og kan få adgang til nøglefilen. Når du har gjort ovenstående, skal du lukke alle medlemmer af replikasættet ned, begyndende med de sekundære. Når alle sekundære enheder er offline, kan du gå videre og lukke den primære ned. Det er vigtigt at følge denne rækkefølge for at forhindre potentielle rollbacks. Luk nu mongod-instansen ned ved at køre følgende kommando:

use admin
db.shutdownServer()

Når kommandoen er kørt, vil alle medlemmer af replikasættet være offline. Genstart nu hvert medlem af replikasættet med adgangskontrol aktiveret.

For hvert medlem af replikasættet skal du starte mongod-instansen med enten konfigurationsfilen security.keyFile eller kommandolinjeindstillingen --keyFile.

Hvis du bruger en konfigurationsfil, skal du indstille

  • security.keyFile til nøglefilens sti, og
  • replication.replSetName til replikasættets navn.
security:
  keyFile: <path-to-keyfile>
replication:
  replSetName: <replicaSetName>
net:
   bindIp: localhost,<hostname(s)|ip address(es)>

Start mongod-instansen ved hjælp af konfigurationsfilen:

mongod --config <path-to-config-file>

Hvis du bruger kommandolinjeindstillingerne, skal du starte mongod-instansen med følgende indstillinger:

  • –keyFile indstillet til stien til nøglefilen, og
  • –replSet indstillet til navnet på replikasættet.
mongod --keyFile <path-to-keyfile> --replSet <replicaSetName> --bind_ip localhost,<hostname(s)|ip address(es)>

Du kan inkludere yderligere indstillinger, hvis det er nødvendigt for din konfiguration. Hvis du f.eks. ønsker, at fjernklienter skal oprette forbindelse til din implementering, eller hvis dine implementeringsmedlemmer kører på forskellige værter, skal du angive –bind_ip. Du kan finde flere oplysninger under Ændringer af kompatibilitetskompatibiliteten for bindinger til lokale hosts.

Derefter skal du oprette forbindelse til et medlem af replikasættet via localhost-grænsefladen. Du skal køre mongosh på den samme fysiske maskine som mongod-instansen. Denne grænseflade er kun tilgængelig, når der ikke er oprettet nogen brugere til implementeringen, og den lukker automatisk efter oprettelsen af den første bruger.

Vi starter derefter replikasættet. Fra mongosh skal du køre metoden rs.initiate():

rs.initiate(
  {
    _id: "myReplSet",
    members: [
      { _id: 0, host: "mongo1:27017" },
      { _id: 1, host: "mongo2:27017" },
      { _id: 2, host: "mongo3:27017" }
    ]
  }
)

Som tidligere nævnt vælger denne metode et af medlemmerne til at være det primære medlem af replikasættet. For at finde det primære medlem skal du bruge rs.status(). Opret forbindelse til det primære medlem, før du fortsætter.

Opret nu brugeren administrator. Du kan tilføje en bruger ved hjælp af metoden db.createUser(). Sørg for, at brugeren som minimum skal have rollen userAdminAnyDatabase på admin-databasen.

Følgende eksempel opretter brugeren “batman” med rollen userAdminAnyDatabase på administratordatabasen:

admin = db.getSiblingDB("admin")
admin.createUser(
  {
    user: "batman",
    pwd: passwordPrompt(), // or cleartext password
    roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
  }
)

Indtast den adgangskode, der blev oprettet tidligere, når du bliver bedt om det.

Dernæst skal du godkende dig som brugeradministrator. Det skal du gøre ved at bruge db.auth() til at godkende. For eksempel:

db.getSiblingDB(“admin”).auth(“batman”, passwordPrompt()) // eller en klartekstadgangskode

Alternativt kan du forbinde en ny mongosh-instans til det primære replikasætmedlem ved hjælp af parametrene -u <username>, -p <password> og --authenticationDatabase.

mongosh -u "batman" -p  --authenticationDatabase "admin"

Selv hvis du ikke angiver adgangskoden i kommandolinjefeltet -p, beder mongosh om adgangskoden.

Til sidst skal du oprette klyngeadministratoren. Rollen clusterAdmin giver adgang til replikationsoperationer, f.eks. konfiguration af replikasættet.

Lad os oprette en klyngeadministratorbruger og tildele rollen clusterAdmin i admin-databasen:

db.getSiblingDB("admin").createUser(
  {
    "user": "robin",
    "pwd": passwordPrompt(),     // or cleartext password
    roles: [ { "role" : "clusterAdmin", "db" : "admin" } ]
  }
)

Indtast adgangskoden, når du bliver bedt om det.

Hvis du ønsker det, kan du oprette yderligere brugere for at tillade klienter og interagere med replikasættet.

Og voila! Du har aktiveret nøglefilsautentifikation med succes!

Oversigt

Replikering har været et vigtigt krav, når det gælder databaser, især i takt med at flere virksomheder skalerer op. Det forbedrer i høj grad systemets ydeevne, datasikkerhed og tilgængelighed. Når vi taler om ydeevne, er det centralt for din WordPress-database at overvåge ydeevneproblemer og rette dem i tide og utide, for eksempel med Kinsta APM, Jetpack og Freshping for at nævne nogle få.

Replikering hjælper med at sikre databeskyttelse på tværs af flere servere og forhindrer dine servere i at lide under tunge nedetider(eller endnu værre – at miste dine data helt). I denne artikel dækkede vi oprettelsen af et replikasæt og nogle tips til fejlfinding sammen med vigtigheden af replikering. Bruger du MongoDB-replikering til din virksomhed, og har det vist sig at være nyttigt for dig? Lad os vide det i kommentarfeltet nedenfor!

Jeremy Holcombe Kinsta

Indholds- og marketingredaktør hos Kinsta, WordPress webudvikler og indholdsforfatter. Ud over alt WordPress nyder jeg stranden, golf og film. Jeg har også problemer med høje mennesker ;).